Best possible solution:

Keep the Docker shell scripts authoritative and land the QA wrappers after either a representative wrapper lane is run in Docker/Testbox or maintainers intentionally accept wrapper-only validation for this cleanup.

Do we have a high-confidence way to reproduce the issue?

Not applicable; this PR is QA evidence wiring around existing Docker lanes rather than a reported runtime bug. Source inspection verifies the catalog and script-runner paths that would exercise the new scenarios.

Is this the best way to solve the issue?

Yes, this is an appropriate owner-boundary fix: QA Lab gets thin scenario wrappers while the existing Docker shell scripts remain authoritative. A representative wrapper run would reduce the only material proof gap before merge.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against b01e6127d96c.

Label changes:

• add P3: This is low-risk maintainer QA automation cleanup with no direct user runtime behavior change.
• add merge-risk: 🚨 automation: The diff changes QA Lab proof automation by adding script-dispatched Docker scenarios, and the posted evidence did not run the heavy Docker lanes through that new wrapper.
• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The PR is authored by a repository member and has the maintainer label, so the external-contributor real behavior proof gate does not apply; the PR body still lists catalog/lint/type evidence and notes the Docker lanes were not run.

Label justifications:

• P3: This is low-risk maintainer QA automation cleanup with no direct user runtime behavior change.
• merge-risk: 🚨 automation: The diff changes QA Lab proof automation by adding script-dispatched Docker scenarios, and the posted evidence did not run the heavy Docker lanes through that new wrapper.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The PR is authored by a repository member and has the maintainer label, so the external-contributor real behavior proof gate does not apply; the PR body still lists catalog/lint/type evidence and notes the Docker lanes were not run.

PR surface:

Other +255. Total +255 across 7 files.

What I checked:

• Repository policy read: Root AGENTS.md and scripts/AGENTS.md were read fully; their review, QA scenario, YAML-only scenario, and script-wrapper guidance shaped this review. (AGENTS.md:1, b01e6127d96c)
• PR diff surface: The PR adds six scenario YAML files plus scripts/qa/docker-e2e-lane.ts, with fixed lane names mapped to existing Docker shell entrypoints. (scripts/qa/docker-e2e-lane.ts:8, c563c6f171d4)
• Current main does not already contain the wrappers: No matching docker-release/update/upgrade QA scenario files or docker-e2e-lane dispatcher exist on current main, so the PR is still adding unique work. (b01e6127d96c)
• Catalog discoverability: Current QA Lab recursively discovers nested qa/scenarios/**/*.yaml except index.yaml, so new runtime scenario files do not need a separate index entry. (extensions/qa-lab/src/scenario-catalog.ts:421, b01e6127d96c)
• Script scenario contract: Script scenarios run through node --import tsx with expanded args, and the runner can produce fallback script-test evidence when a script does not write producer evidence. (extensions/qa-lab/src/test-file-scenario-runner.ts:153, b01e6127d96c)
• Existing Docker lane aliases: Current package scripts already expose the update-channel-switch, update-migration, update-restart-auth, and upgrade-survivor Docker lanes with the same core env contracts the dispatcher mirrors. (package.json:1848, b01e6127d96c)

Likely related people:

• RomneyDa: GitHub history shows recent main-branch QA catalog, coverage ID, suite runtime, and taxonomy-profile work in the same area, and this PR author also appears in that merged history. (role: recent QA scenario and coverage contributor; confidence: high; commits: 438f208a7666, 63b13ea837fe, e12cf72b17b8; files: extensions/qa-lab/src/scenario-catalog.ts, docs/concepts/qa-e2e-automation.md)
• vincentkoc: GitHub history shows repeated recent maintenance of upgrade-survivor Docker scripts and the script scenario runner robustness paths this PR depends on. (role: recent Docker E2E and upgrade-survivor contributor; confidence: high; commits: e7f2b125f628, 0f67474251f6, cc3d346c1564; files: scripts/e2e/upgrade-survivor-docker.sh, scripts/e2e/lib/upgrade-survivor/run.sh, extensions/qa-lab/src/test-file-scenario-runner.ts)
• Solvely-Colin: Merged history credits Solvely-Colin with adding script-backed evidence scenario support, the QA Lab path used by the new dispatcher. (role: script-backed QA evidence introducer; confidence: medium; commits: 591313e80a5e; files: extensions/qa-lab/src/scenario-catalog.ts, extensions/qa-lab/src/test-file-scenario-runner.ts)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.