diff --git a/csaxs_bec/bec_ipython_client/plugins/flomni/AI_docs/TOMO_QUEUE_COMMAND_JOBS_PLAN.md b/csaxs_bec/bec_ipython_client/plugins/flomni/AI_docs/TOMO_QUEUE_COMMAND_JOBS_PLAN.md
index d988eb2..5c61195 100644
--- a/csaxs_bec/bec_ipython_client/plugins/flomni/AI_docs/TOMO_QUEUE_COMMAND_JOBS_PLAN.md
+++ b/csaxs_bec/bec_ipython_client/plugins/flomni/AI_docs/TOMO_QUEUE_COMMAND_JOBS_PLAN.md
@@ -391,6 +391,15 @@ doesn't expose, so the snapshot is still a complete `_TOMO_QUEUE_PARAM_NAMES` se
 Gate "Done" on the same busy signal `TomoParamsWidget` already computes (tomo heartbeat
 OR BEC scan-queue status).
 
+**Implemented as designed, eventually.** The first GUI iteration shipped "Done" (named
+`Submit` in the actual widget) as a soft warn — a Yes/Cancel confirmation dialog while
+busy, not a block — because there was no "Add to queue" path yet for an in-progress
+edit, and blocking Submit outright with nowhere else to put those edits would have been
+a pure regression. A later pass added `TomoParamsWidget.add_edited_to_queue()` (a new
+"Add to queue" button next to Submit, visible only in edit mode) that assembles the job
+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.
+
 ### 6.2 No in-place row editing
 
 Editing a queued job = **delete it, add a new one, reorder into place**. One
diff --git a/csaxs_bec/bec_ipython_client/plugins/flomni/AI_docs/TOMO_QUEUE_GUI_TESTING.md b/csaxs_bec/bec_ipython_client/plugins/flomni/AI_docs/TOMO_QUEUE_GUI_TESTING.md
index 3d97b9b..c74dcfa 100644
--- a/csaxs_bec/bec_ipython_client/plugins/flomni/AI_docs/TOMO_QUEUE_GUI_TESTING.md
+++ b/csaxs_bec/bec_ipython_client/plugins/flomni/AI_docs/TOMO_QUEUE_GUI_TESTING.md
@@ -9,11 +9,15 @@ session/chat.
 validated**. It compiles, imports cleanly, and its non-Qt-rendering logic
 (dynamic form building, step ordering, idempotent-default computation, job
 dict assembly) was exercised with a scripted fake-client smoke test.
-Section 3 (baseline regression) items 1–4 have been clicked through against
-a live session and passed; item 5 (opening the queue dialog) onward, and
-everything in sections 4–6a — including the sort-mode reorder buttons and
-row tooltips added after the first pass — have **not** been clicked through
-yet. That's what this document is for. Companion docs:
+Section 3 (baseline regression) items 1–3 have been clicked through against
+a live session and passed. **Item 4 needs re-testing** — it passed against
+the *old* Submit behaviour (a Yes/Cancel confirmation dialog while busy),
+which has since been replaced with a hard block plus a new "Add to queue"
+button (section 1 item 8); the step-4 instructions below already describe
+the new behaviour. Item 5 onward, and everything in sections 4–6a —
+including the sort-mode reorder buttons and row tooltips added after the
+first pass — have **not** been clicked through yet. That's what this
+document is for. Companion docs:
 `TOMO_QUEUE_COMMAND_JOBS_PLAN.md` section 6 (the design this implements),
 `TOMO_QUEUE_TESTING.md` (Steps 1 & 2, already sim-validated).
 
@@ -74,6 +78,20 @@ support on top of it:
    columns like Type/Exp (s)/Step (µm), which now auto-fit their content
    instead. The "Added at" column was dropped — that value is still in the
    row tooltip (item 6).
+8. **"Add to queue" while editing, and a real Submit block.** Edit mode now
+   shows an **"Add to queue"** button next to Submit. It packages the
+   current (possibly unsubmitted) form fields as a new `pending` tomo job
+   and writes only `tomo_queue` — never the live param vars — so it's
+   always allowed, scan running or not (plan section 6.1). `Submit` is now
+   a real hard block while the beamline is busy instead of a Yes/Cancel
+   confirmation dialog, since there's finally somewhere else to put an
+   in-progress edit. `flomni.py` also got a small, unrelated robustness fix
+   in the same pass: `tomo_scan()`/`scilog_last_ptycho_scans()`/the
+   alignment-scan scilog entry now go through a new `_scilog_write()`
+   helper that tolerates scilog being disabled instead of raising
+   `RuntimeError` and pausing the whole queue over a logging side effect
+   (mirrors the existing enabled-check already used for the PDF report
+   entry).
 
 ---
 
@@ -106,8 +124,14 @@ file is exactly how a regression sneaks in.
    field reverts to the last-submitted value, not your edit.
 4. Start a real (or fast/sim) tomo scan from the CLI
    (`flomni.tomo_scan()`), then open the widget while it's running. Confirm
-   the busy banner appears with a reason. Try **Submit** — confirm you get
-   the "scan appears to be running" confirmation dialog, not a silent write.
+   the busy banner appears with a reason and now says Submit is blocked.
+   Click **Edit**, change a value, click **Submit** — confirm it's refused
+   outright (a plain warning dialog, no Yes/Cancel choice) and nothing gets
+   written (`flomni.<param>` in the CLI still shows the old value). Then
+   click **"Add to queue"** instead — confirm it prompts for a label, adds a
+   new `pending` tomo job with your edited values (check via
+   `flomni.tomo_queue_show()` or the queue dialog), and does **not** change
+   any live param (`flomni.<param>` still shows the pre-edit value).
 5. Click **☰ Queue control…**. Confirm the dialog opens and the table
    reflects the current `tomo_queue` (including anything you added earlier
    via CLI in prior testing sessions).
@@ -242,15 +266,14 @@ Worth knowing before you file something as broken:
   `_queue_action_move()` is still the actual safety boundary regardless
   (two-layer validation, plan section 3.3), so this is a UX gap, not a
   safety gap.
-- **`Done` is a soft warn, not a hard block, while a scan runs** (existing
-  pre-Step-3 behaviour, not something this iteration touched). The plan's
-  section 6.1 literally says "must be blocked"; the actual implementation
-  allows submitting with a confirmation dialog instead, on the reasoning
-  that some live params (e.g. counting time) safely take effect on the next
-  projection while others are already baked into the current run's
-  trajectory. Worth a deliberate decision (keep as documented nuance, or
-  tighten to match the plan literally) rather than silently "fixing" — flag
-  it if a real submit-while-running mistake actually happens during testing.
+- **Resolved: `Submit` is now a hard block while the beamline is busy**,
+  matching plan section 6.1 literally instead of the earlier soft-warn
+  confirmation dialog. The gap that made the soft warn tempting in the first
+  place -- wanting to prepare a parameter set while a scan runs -- is now
+  covered by a new **"Add to queue"** button that appears next to Submit in
+  edit mode: it packages the current (possibly unsubmitted) form fields as
+  a new `pending` tomo-queue job and writes only to `tomo_queue`, never the
+  live param vars, so it's always allowed. See test step 4 in section 3.
 - **No automated widget tests.** `pytest-qt` isn't a dependency of this
   repo, so there's no `qtbot`-driven test suite here — the smoke test that
   validated the builder's logic (dynamic fields, step ordering, idempotent