fix: harden restart QA DAG assertions

content/docs/developer-testing.mdx

@@ -119,6 +119,8 @@ It is staged as:
 5. `09 E2E`: full Playwright on Linux, macOS, and Windows only for `main` validation and manual dispatches.
 6. `10 Release Candidate`: unsigned desktop release-candidate packages with `--publish never`, only for `main` validation and manual dispatches.
 
+The QA DAG keeps verdict sequences exact. Its restart-follow-up fixture accepts a consecutive repeated `changes_requested` verdict only when a durable recovery event identifies a completed coding invocation between the prior and repeated verdicts and another repair completes before the next verdict. Late or unpaired recovery events, repeated terminal verdicts, reordered outcomes, and unexplained coding completions fail the lane.
+
 The main branch ruleset still includes historical context names from older CI numbering and matrix definitions. Compatibility aggregate jobs emit those names only after the corresponding current backend, dashboard, audit, package, orchestration, 18-shard E2E, or desktop release-candidate gate succeeds. They preserve branch-protection compatibility without replacing any current validation job and can be removed once a repository administrator cleans up the obsolete ruleset entries.
 
 `Playwright Diagnostics`, `Release Candidate Diagnostics`, and `Mockup Sprint Diagnostics` are manual-only rerun workflows. A PR cannot be merged with red CI.

docs-web/content/docs/developer-testing.mdx

@@ -129,6 +129,8 @@ It is staged as:
 5. `09 E2E`: full Playwright on Linux, macOS, and Windows only for `main` validation and manual dispatches.
 6. `10 Release Candidate`: unsigned desktop release-candidate packages with `--publish never`, only for `main` validation and manual dispatches. Every native row installs its finished `.deb`, NSIS `.exe`, or DMG app, starts the installed copy with isolated state, and requires packaged backend and renderer readiness plus a clean exit before upload.
 
+The QA DAG keeps verdict sequences exact. Its restart-follow-up fixture accepts a consecutive repeated `changes_requested` verdict only when a durable recovery event identifies a completed coding invocation between the prior and repeated verdicts and another repair completes before the next verdict. Late or unpaired recovery events, repeated terminal verdicts, reordered outcomes, and unexplained coding completions fail the lane.
+
 The main branch ruleset still includes historical context names from older CI numbering and matrix definitions. Compatibility aggregate jobs emit those names only after the corresponding current backend, dashboard, audit, package, orchestration, 18-shard E2E, or desktop release-candidate gate succeeds. They preserve branch-protection compatibility without replacing any current validation job and can be removed once a repository administrator cleans up the obsolete ruleset entries.
 
 `Playwright Diagnostics`, `Release Candidate Diagnostics`, and `Mockup Sprint Diagnostics` are manual-only rerun workflows. Desktop diagnostics invoke Electron Builder directly with an explicit platform target and `--publish never`, preventing CI auto-detection from turning an artifact-only validation into a publish attempt. A PR cannot be merged with red CI.

docs-web/developer/testing.md

@@ -129,6 +129,8 @@ It is staged as:
 5. `09 E2E`: full Playwright on Linux, macOS, and Windows only for `main` validation and manual dispatches.
 6. `10 Release Candidate`: unsigned desktop release-candidate packages with `--publish never`, only for `main` validation and manual dispatches. Every native row installs its finished `.deb`, NSIS `.exe`, or DMG app, starts the installed copy with isolated state, and requires packaged backend and renderer readiness plus a clean exit before upload.
 
+The QA DAG keeps verdict sequences exact. Its restart-follow-up fixture accepts a consecutive repeated `changes_requested` verdict only when a durable recovery event identifies a completed coding invocation between the prior and repeated verdicts and another repair completes before the next verdict. Late or unpaired recovery events, repeated terminal verdicts, reordered outcomes, and unexplained coding completions fail the lane.
+
 The main branch ruleset still includes historical context names from older CI numbering and matrix definitions. Compatibility aggregate jobs emit those names only after the corresponding current backend, dashboard, audit, package, orchestration, 18-shard E2E, or desktop release-candidate gate succeeds. They preserve branch-protection compatibility without replacing any current validation job and can be removed once a repository administrator cleans up the obsolete ruleset entries.
 
 `Playwright Diagnostics`, `Release Candidate Diagnostics`, and `Mockup Sprint Diagnostics` are manual-only rerun workflows. Desktop diagnostics invoke Electron Builder directly with an explicit platform target and `--publish never`, preventing CI auto-detection from turning an artifact-only validation into a publish attempt. A PR cannot be merged with red CI.

docs/development/mockup-sprint-pentest.md

@@ -128,7 +128,7 @@ The current runner covers:
 - Parallel task execution through `parallel-independent`, which fans out independent tasks before an aggregate task.
 - Dirty local checkout finalization through `dirty-checkout-final-merge`, which leaves an uncommitted visible checkout before orchestration and verifies LOCAL final merge preserves that work.
 - Sprint-completion merge conflict repair through `completion-merge-conflict`, which waits for a running `task_coding` provider invocation before mutating the default branch. This places the mutation after sprint preflight and workspace preparation but during the fixture task's built-in delay, so the final LOCAL sprint merge deterministically invokes the mockup merge-conflict worker instead of racing feature-branch synchronization or worker-branch publication. The fixture synchronizes a checked-out default worktree after its detached mutation and requires a completed `merge_conflict` invocation, preventing stale-index dirty-work false positives or silent clean-merge passes.
-- CI-sized QA DAG orchestration through `ci-qa-dag`, a deterministic graph that covers task QA pass, task QA decline, follow-up file creation on the recovered worker branch, a second task QA pass, sprint QA, and final repository assertions. It records a bounded status trace, proves observations survive each forced restart, and requires current completed/pass review summaries plus merged task and completed sprint status. This scenario is the default no-secret GitHub Actions orchestration lane.
+- CI-sized QA DAG orchestration through `ci-qa-dag`, a deterministic graph that covers task QA pass, task QA decline, follow-up file creation on the recovered worker branch, a second task QA pass, sprint QA, and final repository assertions. It records a bounded status trace, proves observations survive each forced restart, and requires current completed/pass review summaries plus merged task and completed sprint status. QA outcome sequences remain exact by default. The restart follow-up fixture alone permits a repeated consecutive `changes_requested` verdict when a durable `qa_followup_provider_completion_recovered` event identifies a completed invocation between the prior and repeated verdicts and another completed repair runs before the next verdict. Late or unpaired recovery events, repeated terminal verdicts, reordered verdicts, and unexplained extra coding completions still fail. This scenario is the default no-secret GitHub Actions orchestration lane.
 - Large-DAG orchestration through `large-dag-stress`, a heavy 129-task graph with 96 leaf tasks, 24 batch joins, 6 group joins, a final manifest, and a validation task. This scenario is excluded from default `all` runs and included by `--scenario pentest`.
 - Runtime restart recovery by restarting the isolated compiled-runtime server during active project runs with `--restart-every-ms` and `--restart-count`; polling tolerates transient API failures while the server is down, requires a successful status observation on both sides of each completed restart, and then validates terminal sprint/task/review state after recovery. Restart-interrupted task-coding runs are refunded from the coding guardrail exactly once, preventing a restart storm from parking otherwise healthy tasks at the attempt cap.
 - Sprint completion by polling the compiled runtime until tasks and sprints reach terminal statuses.

docs/development/testing-and-quality.md

@@ -279,7 +279,7 @@ Set `CODEUX_E2E_OPENROUTER_MODEL` only when validating a different OpenRouter mo
 
 ### Mockup Sprint Orchestration Policy
 
-The credential-free mockup sprint orchestration gate is part of `.github/workflows/ci.yml`. Its `08 Orchestration / <runtime> DAG` job is a shared OS matrix that runs after the shared build artifact is available and runs for `dev`, `main`, and manual validation. Linux runs `pnpm run test:orchestration:ci-dag:run`, so the deterministic QA DAG executes through Docker-backed provider workspaces without provider secrets and without rebuilding the app. It covers task QA pass, a QA-declined task resumed on its worker branch, sprint QA, a sprint-level final-merge `ci_fix` invocation, and final repository validation. The lane asserts the repair artifact reaches the default branch, the CI-fix invocation is completed without a task id, completed coding tasks are not spuriously redispatched, status reads bracket every forced restart, completed review summaries are current, task merges are terminal, and the sprint finishes completed.
+The credential-free mockup sprint orchestration gate is part of `.github/workflows/ci.yml`. Its `08 Orchestration / <runtime> DAG` job is a shared OS matrix that runs after the shared build artifact is available and runs for `dev`, `main`, and manual validation. Linux runs `pnpm run test:orchestration:ci-dag:run`, so the deterministic QA DAG executes through Docker-backed provider workspaces without provider secrets and without rebuilding the app. It covers task QA pass, a QA-declined task resumed on its worker branch, sprint QA, a sprint-level final-merge `ci_fix` invocation, and final repository validation. The lane asserts the repair artifact reaches the default branch, the CI-fix invocation is completed without a task id, completed coding tasks are not spuriously redispatched, status reads bracket every forced restart, completed review summaries are current, task merges are terminal, and the sprint finishes completed. QA histories use exact verdict sequences unless the restart-follow-up fixture explicitly allows a consecutive repeated intermediate verdict and durable evidence proves the recovered completion occurred between the two verdicts plus a later repair completed before the next verdict. Extra terminal verdicts, reordered outcomes, late or unpaired recovery events, and unexplained coding completions remain failures.
 
 The macOS and Windows entries in the same `08 Orchestration` matrix run `pnpm run test:orchestration:ci-dag:electron:run` on `dev`, `main`, and manual validation. Those jobs install the cached Electron binary, rebuild native dependencies, launch `dist/electron/main.js`, wait for the embedded Code UX server, and run the host-execution mockup fixture through the same QA and final-merge CI-repair DAG. GitHub-hosted Windows and macOS runners do not provide Docker job containers, so the native Electron entries validate desktop orchestration and host-backed CI-fix worktrees while Ubuntu remains the Docker-backed orchestration gate.
 

scripts/e2e/mockup-sprint-pentest-scenarios.mjs

@@ -1283,6 +1283,7 @@ export const SCENARIOS = [
               "qa-dag-pass": { outcomes: ["pass"] },
               "qa-dag-follow-up": {
                 outcomes: ["changes_requested", "pass"],
+                allowRepeatedIntermediateOutcomes: true,
                 requireFollowUp: true,
                 requireSameWorkerBranch: true,
               },
@@ -1351,6 +1352,7 @@ export const SCENARIOS = [
               "qa-dag-pass": { outcomes: ["pass"] },
               "qa-dag-follow-up": {
                 outcomes: ["changes_requested", "pass"],
+                allowRepeatedIntermediateOutcomes: true,
                 requireFollowUp: true,
                 requireSameWorkerBranch: true,
               },