docs(flomni): record 6c-6e pass results and document the add-to-queue warning

GUI test checklist: sections 6c/6d/6e (items 37-52) all passed
real-session testing, including the stale-"running" override fixing
an actual stuck job found live -- status line and section 1 items
updated. New section 6f (items 53-55) for the "Add current params to
queue" mid-edit warning, plus section 1 item 13.

Plan doc section 6.1: records the second live-vs-unsaved-edit
confusion (a second window, not just the panel's own button) and why
it's a warning, not a block, unlike Submit.

User manual: new paragraph distinguishing the params panel's "Add to
queue" from the queue window's "Add current params to queue", and
when the warning fires.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

csaxs_bec/bec_ipython_client/plugins/flomni/AI_docs/TOMO_QUEUE_COMMAND_JOBS_PLAN.md

@@ -505,6 +505,22 @@ a pure regression. A later pass added `TomoParamsWidget.add_edited_to_queue()` (
 dict from the current form fields — exactly per this section's "must assemble the job
 dict itself" rule — and only then did `submit_params()` become the intended hard block.
 
+**The same live-vs-unsaved-edit confusion has two doors, not one.** Found at the
+beamline: `TomoQueueDialog.add_to_queue()` (the "Add current params to queue" button
+in the *separate* ☰ Queue control… window) *also* reads live vars via
+`self._load_params()`, same as `tomo_queue_add()` always did — it was never updated to
+know the params panel might have an unsubmitted edit open. An operator who edits a
+value, doesn't click the panel's own "Add to queue", and instead reaches for the queue
+window's button gets the stale pre-edit values queued with no indication anything's
+off — the exact trap this section's "must assemble the job dict itself" rule was
+written to avoid, just reachable from a second window that rule didn't originally
+cover. Fixed with a warning (not a block, unlike Submit): `TomoQueueDialog.add_to_queue()`
+now checks `self.parent()._edit_mode` and, if set, confirms before proceeding, naming
+the panel's own "Add to queue" as the correct button. A warning rather than a hard
+block because queuing the live params while an unrelated edit happens to be open
+elsewhere is still legitimate — unlike Submit's case, there's no live-scan-perturbation
+risk here, just a wording/expectation mismatch worth flagging rather than forbidding.
+
 ### 6.2 No in-place row editing
 
 Editing a queued job = **delete it, add a new one, reorder into place**. One

csaxs_bec/bec_ipython_client/plugins/flomni/AI_docs/TOMO_QUEUE_GUI_TESTING.md

@@ -12,11 +12,11 @@ gaps (all fixed, see section 6c below): a confusing duplicate row-number
 column, `tomo_parameters()`/the queue table/scilog/the PDF report/the
 progress-ring label not showing an active hook at all, and a clarification
 that `unregister_at_each_angle_hook()` doesn't clear `at_each_angle_hook`
-(confirmed expected, now documented). **Sections 6c, 6d, and 6e are new and
-not yet clicked through** — 6c is the fixes above, 6d is the new "Load into
-editor" feature (reuse a queued job's settings as a new edit), 6e is a
-declined-scan/stuck-queue incident found live at the beamline and its fix
-(CLI-side sim-verified; the GUI delete/clear override itself is not).
+(confirmed expected, now documented). **Sections 6c, 6d, and 6e have now also
+been clicked through and pass** (37–52), including the stale-`running`
+delete override, which fixed an actual stuck job found live at session
+start. **Section 6f is new and not yet clicked through** — a warning added
+after 6e's testing surfaced one more mixed-surface confusion (see below).
 Companion docs:
 `TOMO_QUEUE_COMMAND_JOBS_PLAN.md` section 6 (the design this implements),
 `TOMO_QUEUE_TESTING.md` (Steps 1 & 2, already sim-validated).
@@ -141,8 +141,16 @@ support on top of it:
     stuck at `running` with no live process. And delete/clear on a
     `running` row now check `tomo_progress`'s heartbeat: stale or missing
     offers a "proceed anyway?" override instead of refusing forever; a
-    fresh heartbeat still blocks outright. See section 6e below — not yet
-    click-tested.
+    fresh heartbeat still blocks outright. Click-tested (section 6e) and
+    passing — the staleness override fixed an actual stuck job found live.
+13. **Warn before "Add current params to queue" mid-edit.** That button
+    (in the ☰ Queue control… window) reads live global vars, not the
+    params panel's in-progress edit -- a second place the same
+    live-vs-unsaved-edit confusion as item 8 could bite, since it's a
+    different window from the panel's own (correct) "Add to queue"
+    button. Now warns and names the correct button before proceeding if
+    the panel is mid-edit; no warning if it isn't. See section 6f below —
+    not yet click-tested.
 
 ---
 
@@ -451,6 +459,25 @@ forever with the GUI unable to delete it.
     status guard there at all) — useful as a fallback even without the
     GUI open.
 
+## 6f. Test plan — new: warn before "Add current params to queue" mid-edit
+
+Found during 6e testing — a second confusion between the two "add to queue"
+buttons living on two different windows.
+
+53. Click **Edit** in the params panel, change a value, but do **not**
+    click Submit or the panel's own "Add to queue" yet. Open **☰ Queue
+    control…** and click **"Add current params to queue"** (the button in
+    that window, not the panel). Confirm a warning dialog appears naming
+    the live-vs-unsaved-edit mismatch and pointing at the panel's own "Add
+    to queue" button, before anything is queued.
+54. From that dialog, click **Cancel** — confirm nothing was added to the
+    queue. Click the button again and this time confirm **Yes** — confirm
+    it queues the **live** (pre-edit) values, not your in-progress edit,
+    exactly as the warning said it would.
+55. With the params panel **not** in edit mode, click "Add current params
+    to queue" — confirm it queues normally with **no** warning (only
+    fires when an edit is actually in progress).
+
 ## 7. Known limitations of this first iteration (by design, not bugs)
 
 Worth knowing before you file something as broken:

docs/user/ptychography/flomni.md

@@ -367,6 +367,14 @@ as if you'd just clicked Edit. Nothing is written yet — review or tweak the fi
 then Submit (writes live, blocked while the beamline is busy) or "Add to queue" (always
 allowed) as usual. If you already had an edit in progress, it asks before discarding it.
 
+**GUI: two different "Add to queue" buttons.** The params panel's own **"Add to
+queue"** (visible in edit mode) queues whatever you've typed, unsubmitted. The ☰
+Queue control… window's **"Add current params to queue"** is a different button on a
+different window — it always queues the *live* parameters, regardless of any edit
+open in the panel. If you have an unsaved edit open and click the queue window's
+button instead of the panel's, it warns and names the correct one before proceeding,
+since it would otherwise queue your last-submitted values, not what you just typed.
+
 #### Command jobs — reconfiguring the beamline between scans
 
 In addition to tomogram jobs, the same queue can hold **command jobs**: an ordered