@@ -32,6 +32,7 @@ For features with background jobs, polling, retries, cancellation, or shutdown:
 - Preserve completed historical results, but visibly mark them stale when their snapshot, plan revision, assignment, or referenced code no longer matches.
 - When polling updates one part of the screen, update only that state. Preserve scroll position unless the user was already following the bottom.
 - While a request is in flight, do not disable the control that has keyboard focus; disabling it drops focus to the page. Mark it `aria-disabled`, ignore repeat activation with an in-flight guard, and test that focus stays on the control after the response.
+- When a background update (a poll, a reload, an answer) hides or removes the control that has keyboard focus, move focus to a named fallback that is still shown and not `disabled` (an `aria-disabled` control qualifies) once the update has set every control's final state, and test that focus lands there for each way the control can be hidden. Decide a focusable control's visibility once per update: hiding it and showing it again blurs it.
 - When a row or control's visual selection determines the current content or input, expose the same state with the appropriate accessibility attribute, such as `aria-current` or `aria-selected`, and test it across navigation.
 
 ## Required race regressions
@@ -53,6 +54,8 @@ Every reproduced race requires a failing-before and passing-after regression. As
 
 A race regression must assert that the interleaving it names actually happened (for example which abort stopped which stage, or that a deadline fired before a release) before it uses the outcome as evidence. Otherwise machine load can turn it into a test of a different order that still passes.
 
+A check that an event changed nothing (a late answer, a stale poll, a reload read earlier) must first prove the page handled that event, then read the state once: wait for a render or a state the event causes, or for a request the page sends only after handling it, and hold any later answer that could repair the state before the read. A fixed wait, the network response alone, or a retrying assertion on a state that already held before the event is not that proof: a page that handles the event late, or wrongly, then passes. A check that nothing is sent after an event can only be made over a window: wait longer than the shortest delay after which the page would send it, and say so beside the check.
+
 ## Review readiness
 
 - Before requesting or re-requesting an automated Copilot review, self-review the full current diff, fix every issue found, and repeat the self-review and fix cycle until a complete pass finds no new issues. Re-run the relevant validation after fixes, then complete the mandatory independent-agent review loop below before requesting Copilot review.
 
@@ -144,9 +144,11 @@ components:
 | Token | Meaning | Icon and word |
 |---|---|---|
 | `success` | OK: passed, in scope, approved | ✓ plus a word such as "OK" or "Passed" |
-| `warning` | Attribution warning, stale | ! plus a word such as "Stale" or "Ambiguous" |
+| `warning` | Attribution warning, stale, or a step that did not finish normally | ! plus a word such as "Stale" or "Ambiguous" ("Stopped" for a cancelled merge step, "Unknown" when GitHub's merge outcome is not known) |
 | `error` | Scope or test failure, blocker, unplanned | ✕ plus a word such as "Fail" or "Unplanned" |
-| `neutral-status` | Not applicable | – plus "N/A" |
+| `neutral-status` | Not applicable | – plus "N/A" (or "Skipped" for a step that was not needed) |
+| `neutral-status` | Not started yet (a step that is waiting) | ○ plus "Waiting" |
+| `text` | In progress (a step that is running) | ● plus "Running" |
 
 - `success` is much lighter than `error`. This lets red-green color-blind users still tell them apart by brightness. Never rely on hue alone.
 - **Contrast (checked 2026-09-22):** every text and status color is at least 5.0:1 on every surface. Body text is 14.6:1 on `surface`.
@@ -174,7 +176,7 @@ components:
 | 1280–1439px | The conversation pane collapses to a tab. The plan list narrows to 208px |
 | Below 1280px | A notice asks for a wider window |
 
-**Frame:** a 44px app bar (the shared menu, design review D13), then a 48px review strip (issue, PR, revision, progress, blockers), then full-height panes. Panes can be resized and collapsed.
+**Frame:** a 44px app bar (the shared menu, design review D13), then a 48px review strip (issue, PR, revision, progress, blockers), then, while a merge job runs and until the review reloads, the merge step bar, then full-height panes. Panes can be resized and collapsed.
 
 **Rhythm:** a 4px base grid. Rows are 32px. Pane padding is 12px. Space between sections is 16px or 24px. Keep density tight inside lists and give the code pane the most room.
 
@@ -257,3 +259,7 @@ There are no shadows and no glows. Depth comes from the surface brightness steps
 | 2026-09-22 | The serif "second voice" for the user's own words was not adopted | The user chose variant B. Two faces are enough |
 | 2026-09-22 | Logo: terminal-prompt mark (`>_`) in a rounded square, in `text` color | Taken from the approved review-screen mockup. It was left out of the first HTML screen and restored at the user's request |
 | 2026-09-22 | Contrast-checked values kept instead of values extracted from the mockup image | The extracted values (for example error #DA1E28) failed contrast on dark surfaces |
+| 2026-10-21 | Two progress marks for the merge step list: ○ "Waiting" in `neutral-status` and ● "Running" in `text` | Steps that have not started or are under way are not outcomes, so they take no outcome color. Approved by the user (PR #194) |
+| 2026-10-21 | The not-applicable mark also reads "Skipped" for a merge step that was not needed | Same meaning as N/A, worded for a step. Part of the step list the user approved (PR #194) |
+| 2026-10-21 | The warning mark also reads "Stopped" (a cancelled merge step) and "Unknown" (GitHub's merge outcome not known) | Both mean "look at this, it did not finish normally". Approved by the user (PR #194) |
+| 2026-10-21 | While a merge job runs, and after it ends until the review reloads, a step bar sits between the review strip and the panes | It shows the merge step list and Cancel merge without replacing the review strip's merge control. Approved by the user (PR #194) |
@@ -2,7 +2,7 @@
 
 Review agent-made Git changes one plan item at a time. The approved plan lists each item's files and acceptance checks; the review engine shows which item produced each change and flags foreign or overlapping work.
 
-**Status:** the plan/linking library, SQLite store, local review screen, Plans screen (plan import, plus agent drafts and suggestions with revision-bound Apply; drafts and suggestions need a configured `github` review, not the demo), opt-in code-writing runner, durable local rebase, exact-head plan command checks, and the one-click merge job are implemented. Run `npm run demo` and open its private local URL. Ask, planning and the runner use Claude Code inside locked-down containers; Codex is refused because it reads code only by running commands ([why](docs/implementation/agent-isolation.md#codex-is-refused-in-every-phase)). They need Docker, plus `CLAUDE_CODE_OAUTH_TOKEN` (from `claude setup-token`). Startup builds the agent image, which can take a few minutes. A configured GitHub review can merge only after the guarded exact-head gate passes. The agent container, vendor-only network, credential-free command-check profile, and Claude/Codex adapters are described in [agent isolation](docs/implementation/agent-isolation.md). With a runner, the **Merge PR** button pushes the rebased head, waits for its required checks, and hands that exact pair to the guarded merge ([merge handoff](docs/implementation/merge-handoff.md)). The paired human review experiment was cancelled before results were recorded and no longer blocks roadmap work; optional future validation is tracked in [#19](https://github.com/codeabovelab/codeboost/issues/19).
+**Status:** the plan/linking library, SQLite store, local review screen, Plans screen (plan import, plus agent drafts and suggestions with revision-bound Apply; drafts and suggestions need a configured `github` review, not the demo), opt-in code-writing runner, durable local rebase, exact-head plan command checks, and the one-click merge job (with its step list and a **Cancel merge** button) are implemented. Run `npm run demo` and open its private local URL. Ask, planning and the runner use Claude Code inside locked-down containers; Codex is refused because it reads code only by running commands ([why](docs/implementation/agent-isolation.md#codex-is-refused-in-every-phase)). They need Docker, plus `CLAUDE_CODE_OAUTH_TOKEN` (from `claude setup-token`). Startup builds the agent image, which can take a few minutes. A configured GitHub review can merge only after the guarded exact-head gate passes. The agent container, vendor-only network, credential-free command-check profile, and Claude/Codex adapters are described in [agent isolation](docs/implementation/agent-isolation.md). With a runner, the **Merge PR** button pushes the rebased head, waits for its required checks, and hands that exact pair to the guarded merge ([merge handoff](docs/implementation/merge-handoff.md)). The paired human review experiment was cancelled before results were recorded and no longer blocks roadmap work; optional future validation is tracked in [#19](https://github.com/codeabovelab/codeboost/issues/19).
 
 ## Development