Implement

Implement the work described by the user in the spec or tickets. If they are referenced by path, read them fully first. 進入本流程時先把適用標準階段（1. Preflight → 2. Work the frontier → 3. Close out）建進待辦清單；如果某步驟因本批條件不適用或已有核准豁免而跳過，保留該項並標註 skip: <原因>（指回原流程決定），不得將待辦清單的 skip 當成新的測試或審查豁免來源。

1. Preflight, then ask everything at once

Someone handing you a ticket set usually intends to walk away. Every question asked after they do costs them a context switch and costs you the run, so front-load all of it: probe first, then put every open question in a single round.

先分清每票的測試義務與本批的測試模式。 核准票上的 Tests: required|waived 決定是否需要測試；舊 TDD: 欄位仍可讀，但不能拿票上的 required 當成新一批已選 TDD。先從 context、同批仍有效的 started manifest 或 Verification Log 找本批已批准的模式；續接沿用、不逐票重問，已結束的另一批選擇不沿用。如果本批有 required 票而尚未選模式，就先繼續下方預檢，再在同一輪問；答案前不建立 started manifest、不載入 TDD 正文、不實作或派工。未開工的退出仍用既有 not-started --reason <preflight-only|prerequisite-blocked|user-deferred>。

Probe what the tickets say they need. Each ticket's Needs: field names the environment, credentials, or human action its acceptance items depend on — probe each one cheaply (nc -z the port, gcloud auth list, one throwaway API call, ls the config file) instead of assuming, and add whatever the repo's own test commands imply.

When Needs: names nREPL or another shared daemon, a listening port is discovery only. Before reusing or starting it, verify the owner PID, process cwd, build identity, and a real runtime probe that proves the daemon loaded the intended worktree's code. A mismatch means the prerequisite is not ready; do not start a second copy and let the next eval attach to whichever runtime wins.

When a ticket's acceptance explicitly requires browser E2E, the implementation owner makes that checkpoint reproducible before browser handoff: establish the required test data, account state, feature flags, permissions, integrations, and service state instead of leaving the browser runner to improvise prerequisites through unrelated UI flows. Prefer existing setup facilities. If a new test-only setup capability is necessary, keep it inaccessible in production, explicitly gated to approved test environments, authenticated where appropriate, narrowly scoped, and safe to call repeatedly. It must not create a production backdoor, weaken production authorization, or encode the behavior under test. Tickets without browser E2E acceptance skip this branch. 如果本批任務是「換底層技術／重構但要求畫面或終端輸出維持一模一樣」，就在動手改碼前讀 ~/.claude/references/verification-recipes-and-probes.md 的「視覺零漂移基準鎖定」先鎖定改前基準。如果本票驗收需要實機操作（CLI、TUI、背景服務或 UI），就只檢查本票驗收實際會用到的既有配方與前置環境（不巡檢與本票無關的其他配方）；當目標 repo 完全沒有可重用驗收配方時，才在下方唯一一輪提問順便詢問是否初始化第一套最小配方。如果本批規格或票具有具體交錯順序風險與待證不變量（多步狀態機、跨 session 搶鎖、超時與重試交錯）且 Testing Decisions 尚未記錄層級選擇，就在下方唯一一輪提問順便詢問要跑「簡單版（有限狀態巡檢）」或「完整版（數學模型窮舉與反例圖）」，詳見 ~/.claude/references/verification-recipes-and-probes.md 的「狀態與併發兩層核驗」。

Report as:

✅ <prereq> — probe passed
⚠️ <prereq> — YOUR ACTION: <exact command or click>
   why I can't: <sudo / GUI / interactive auth / secret entry>

If the session's usage window is already heavily used, list it as a warning prereq with the number, so they can decide whether to start now.

Then one question round. 停點回報順序（中途與收尾同用）：沿用 context 的呈現規則，先重建已批准的功能目標，再說已做／未做與卡點，最後列選項；每個選項說清驗證能證明什麼、仍未驗證什麼，以及是否新增行為或維護責任，不把文字契約檢查當成真實派工證據。尚未執行的驗證明列為未驗證，不以預計的 trial 或新增程式填成已證實。 Ask for the base execution mode — Inline or Subagent-Driven (a fresh worker per frontier ticket, parallel where blocking edges allow; the default for 3+ tickets). In the same question round, also ask about any ticket the plan marked best-of-N and any acceptance criterion whose wording you would otherwise guess at. Ask them together, not one at a time as you reach them. 同一輪再問本批尚未取得答案的測試模式：a. 原 TDD（tdd）／b. 回歸收尾（regression-closeout）；不預設、不從 required 代選、不在核票或每票再問。若真人已明確選了本批模式或這是同批續接，就沿用該選擇、不重問；同批舊 started manifest 缺模式欄時相容為原 TDD，不當成新一批的預設。若 context 已載入完整 TDD 正文，就在這一輪說清回歸收尾不能復用該 context 作 Inline 執行：用只接收所選路線的 fresh worker 或新 session；不宣稱能卸載舊指令，也不把選模式當成另起 Herdr 的授權。全部票都已批准 waived 時沒有測試路線要執行，省略此題、沿舊 CLI 相容值，不宣稱真人選過 TDD。

State the degradation policy before they leave, so their silence later isn't ambiguous: name which failures you will route around and record (a tool disconnects, an optional check can't run, one verification path breaks while another reaches the same fact) and which will genuinely stop you (a required credential expires, a gate ticket's answer contradicts the spec's premise). Unattended means route-around-and-record is the default and stalling is the exception — an agent that halts on the first broken tool has spent their absence doing nothing.

取得同一輪的答案後，依序接以下選路步驟，再開始 frontier：

1. 將本批已批准模式、覆蓋票號與真人選擇原話追加既有 Verification Log（OpenSpec 用 tasks.md；scratch 用本批首票），讓續接有來源；同批有效紀錄不重寫。全 waived 的批次記「沒有測試路線適用」，不偽造模式選擇。
2. Create the decision manifest after the approved breakdown and testing choice are in context and before dispatch. Use the session and run IDs injected by the TDD gate, then run node ~/.claude/skills/implement/scripts/tdd-policy.mjs init --session <session> --run <run> --tickets <approved-ticket-set> --testing-mode <tdd|regression-closeout>. Scratch 用完整 .scratch/<feature>/issues/ 目錄，不能只傳單票；OpenSpec 用 openspec/changes/<change>/tasks.md。每票仍須有 required 與非空 seam，或 waived 與已批准封閉理由；錯誤豁免回既有核票，不在 implement 自補。若本 run 已有 started manifest，就 validate 並沿用，不再次 init 或默默改模式；新 run 的續接用真正的新身分、沿用同批真人選擇，不冒用舊 session/run。全 waived 批次可省略模式旗標使用舊相容值。
3. 只有 testing_mode=tdd 且有 required 票時，才在本次 arming 後、Inline／dispatch 前真正 invoke Skill(tdd) 一次並確認 matching result 成功。若選 regression-closeout 且有 required 票，就在 Inline／dispatch 前讀 回歸收尾配方，不 invoke 完整 TDD skill、不讀它的 SKILL.md。全部票 waived 時不載入任何測試配方。配方只按已選路線載入，不把兩套詳細步驟一起交給 worker。

For a Git-backed implementation, record feature_base_sha 在第一筆 feature commit 前。 Keep it stable for the whole run; post-implement architecture comparison uses this base rather than guessing from the final diff.

Done when: every ⚠️ is resolved or explicitly waived, every question in the round is answered, 本批模式有真人來源或全票已批准 waived、decision manifest validates、只載入所選路線且需要的真實 Skill(tdd) 呼叫已成功，feature_base_sha is recorded when Git applies, every shared daemon matches the intended worktree by PID／cwd／build identity plus a real runtime probe before dispatch, and every ticket with browser E2E acceptance has reproducible state established before browser handoff. Do not re-ask per ticket; run to the end.

2. Work the frontier

A ticket is on the frontier when all its "Blocked by" tickets are done. Repeat until no tickets remain.

如果要首次形成實作要求、改派／重派／換方案，或接受會增加範圍的 review 建議，就在自己修改或派工前讀 ~/.claude/rules/common/dispatch-and-verify.md 的「Main scope 差額檢查」並套用；完成後再走下方共同 recipe。Inline 與 Subagent-Driven 都適用，不以 main 自寫的 ticket 或驗收條件替新增範圍授權。

Common per-ticket recipe (Inline and Subagent-Driven): preserve the approved required|waived test obligation；controller 與 worker 都不能把 required 改成 waived 或自行改本批模式。required 票只用開工時選定的配方與已批准 seam；waived 票保留封閉理由，不新增測試或宣稱做過測試。TDD 與回歸收尾的詳細指令不放在這份共用正文，也不由 worker 重選。Stop 仍是提示型、從不攔回合：它只提醒需要 TDD 呼叫的批次缺真實 Skill(tdd)，不證明 required 測試已補齊、測試品質或任何執行順序。Run typechecking regularly and single test files regularly. Tick the ticket's acceptance checkboxes as they pass. Anything noticed-but-not-blocking goes to the Verification Log (openspec: the change's tasks.md; scratch: the ticket file) as a Minor finding — do not chase it mid-ticket.

When a criterion turns out to be wrong — the behaviour it demands can't happen, already happens elsewhere, or would break something — record the verdict plus its evidence in the Verification Log, correct the spec's wording, and tick the item as resolved-by-correction. Leave the code alone: code bent to satisfy a wrong criterion passes the ticket and ships the defect, and the next reader inherits a spec that still asserts the wrong thing. 如果這個修正需要使用者拍板，就在提出選項前套用 Step 1 的「停點回報順序」，不先改掉需核准的驗收或範圍。

Inline mode: apply the recipe to the next frontier ticket yourself, ticket by ticket. For each ticket:

1. Before touching it, record ticket_base_sha with git rev-parse HEAD. If it was not recorded, use the parent of this ticket's first commit.
2. After its code, tests, and commit, and before editing its **Status:** or starting the next ticket, run the ticket-level YAGNI review once: python3 ~/.claude/hooks/ticket-yagni-runner.py --manual --session "$CLAUDE_CODE_SESSION_ID" --ticket NN --ticket-file <absolute ticket path> --worktree <repo root> --base <ticket_base_sha>. Inline has no worker, so nothing reviews the ticket automatically, and the Status gate denies until this verdict exists. The runner diffs ticket_base_sha against the current working tree, so running it after the next ticket starts pulls that ticket's changes into this one; if the next ticket has already started, pass a temporary detached worktree at this ticket's last commit as --worktree instead of the shared tree, and remove it afterwards.
3. When the verdict lists kill／demote items, apply the cuts yourself, run only the tests that existed at ticket_base_sha plus this ticket's acceptance checks, and commit the cuts before the next ticket so its base starts clean; a test you wrote for a removed item goes with it. One verdict per ticket: the trimmed result is not reviewed again. A runner error or an empty-diff skip is recorded in the Verification Log and not retried with different arguments; the gate lets the Status edit through in both cases.
4. Change the ticket's **Status:** through Edit on the ticket file.

Subagent-Driven mode: dispatch one worker per frontier ticket, routed per the implementation-class dispatch discipline already in context. The controller is the only committer: every worker prompt forbids commits and requires git add -N -- . && git diff --binary HEAD so tracked, binary, and new files all reach the controller as a patch; integrate without cherry-pick, merge, or other commit-producing commands. If the user requested a commit, the controller leaves the default branch before dispatch or integration. Parallel workers each use an isolated git worktree; if isolation is unavailable, run frontier tickets sequentially in the shared tree. A worktree isolates tracked files only — not external caches, shared daemons, ports, or services; before parallel dispatch, give each worker a separate cache location or serialize the tickets that touch the same daemon. Each worker prompt must state 既有流程續作狀態：implement before embedding the ticket file's absolute path, the full ticket text, the source ticket's required decision and seam or its approved waived reason, 本批已批准的 testing_mode、回歸保護範圍與唯一所選配方，the common per-ticket recipe, the repo's test commands, this commit rule, and the instruction not to edit ticket status or the shared Verification Log. The ticket path slot takes an absolute path — starting at /, shaped <worktree>/.scratch/<feature>/issues/NN-*.md — because a repo-relative path reads the same to a human but resolves to nothing for the hook that consumes it. The controller stays lean and is their only writer: dispatch, collect, integrate worker changes, tick acceptance boxes, and append worker-reported Minor findings. Do NOT add per-ticket review rounds between controller and worker — the quality gate is step 3 plus the PR layer. The one exception is the hook-delivered ticket-yagni verdict, and it is handled without a new review round: name the ticket as Ticket NN in every worker dispatch description so the PostToolUse hook can register the worker, and keep the absolute ticket path in that prompt so the hook can pin which NN-*.md you mean — ticket numbers repeat across feature directories, and without the path the review resolves nothing and the gate lets the ticket close unreviewed; change a ticket's **Status:** only through Edit on the ticket file, because the PreToolUse gate reads that edit and denies until the verdict exists. When a [ticket-yagni] system reminder lists kill／demote items, send that list with SendMessage to the same worker (not a new worker, not a reviewer), let it apply the cuts, then run only the tests that existed at dispatch_base_sha plus the ticket's acceptance checks; a red test the worker wrote for a removed item is deleted with the item, not used to restore it. One verdict per worker: the trimmed re-delivery is not reviewed again, and a pending deny from the gate means wait for the wake-up, not poll.

Transport baseline: Before the first worker, pre-create every sibling worktree for the same frontier from one dispatch_base_sha, record each canonical worktree path, and never let active workers share a physical workspace. If worktree creation fails, stop new dispatch and join or cancel every started worker; when it is safe to continue, the controller completes the frontier sequentially, otherwise mark it blocked. Shared-tree fallback stays controller-owned: no writing worker and no patch to apply. Each isolated worker returns a dispatch-bound minimum patch provenance with the canonical worktree path, dispatch_base_sha, changed-file evidence, and the patch file path. The controller treats the exact patch as authoritative, recomputes changed files from the patch, verifies the canonical worktree and dispatch base, and does not treat a later same frontier patch with the same base as stale merely because an earlier patch was integrated; that later patch remains not stale until its own checks fail. During an exclusive integration window, verify the target tree and dirty state, then run git apply --check before formal apply in ticket order. On check／apply failure, leave the target workspace unchanged, mark the ticket blocked, and preserve in the Verification Log the failure, patch, provenance, expected/current SHA, exit/stderr, and before/after status. Dirty target does not start parallel transport; cache, daemon, port, and service isolation failures serialize the affected tickets. This remains a prompt-level contract only; no deterministic helper, hook, gate, worker commit, or merger.

如果使用者已在本 session 打過 /pi-on，就在下方 control loop 的 dispatch 前 invoke pi-subtask 核對 session 選路；沒打過就沿原 loop，不問要不要啟用 pi。若該 session 已授權 pi，沿該入口以外部 pi 執行同一票，保留上方已選測試模式、測試義務、worktree、patch provenance、票 Status 與 main-only commit 合約；native Agent 的 SendMessage／TaskOutput 位置換成同 pi job 的 call／status，每回合以 background Bash handle 記 workerTaskId。首交接 pi-deliver，YAGNI 裁剪回同 job、不重審返工；不能因換執行器降低驗收。未授權或有具體不相容項就沿原 loop，記例外。

Subagent-Driven control loop:

1. Before dispatching each worker, append both control clauses to its prompt:
   • Do not call Agent yourself. If you need a fresh agent or reviewer, return NEEDS_DELEGATION: <role> — <bounded task> alongside whatever else you have finished, and keep working on anything that does not depend on it. A worker never creates its own child Agent.
   • If a tool call is denied by a hook or permission boundary, do not retry it. Return BLOCKED: <denied action> unless a safe path that does not use that tool exists; when using the safe path, report the fallback to the controller before continuing.
2. Dispatch the background worker and record its workerTaskId. Immediately launch a main-session background Bash reminder and record the returned background-task handle as reminderTaskId: Bash(run_in_background=true): sleep 1200; printf 'WORKER-WATCHDOG worker=<workerTaskId> ACTION=inspect-once\n' If the worker finishes first, cancel the reminder with TaskStop({task_id: reminderTaskId}).
3. If the worker returns NEEDS_DELEGATION, cancel its current reminderTaskId. The controller owns every delegated Agent call: dispatch the bounded task, collect its result, then resume the original worker through SendMessage. Treat that resumed turn as a new background dispatch: record the returned workerTaskId, return to step 2, and create a fresh reminderTaskId.
4. When the reminder finishes first, inspect the worker once with TaskOutput({task_id: workerTaskId, block: false, timeout: 1000}). Verified new progress means let the worker continue and immediately arm a fresh reminderTaskId per step 2: a clean check says the worker was alive twenty minutes ago, not that it will stay alive, and a worker that stalls after one passing check has no other scheduled observer — the next look only happens because you scheduled it now. An explicit blocked state or no verifiable progress means TaskStop({task_id: workerTaskId}). Elapsed time alone must not automatically stop a worker.

Done when: every worker prompt contains the NEEDS_DELEGATION and BLOCKED: clauses, and every background worker has non-empty workerTaskId／reminderTaskId handles for a 20-minute progress check that is re-armed on every continue decision, so no live worker is ever left without a scheduled next look.

Done when: every ticket's acceptance criteria are checked, or explicitly parked with a reason in the Verification Log.

3. Close out

In order:

1. 回歸收尾批次先依已載入配方補齊 required 票的已確認回歸範圍、跑最近單一測試並寫結果；有缺口就仍未達驗收，不進最後 review。原 TDD 批次依自己的 reference 完成；全 waived 保留原理由。兩路到這裡才合流，不先 review 再補未審過的測試。Run the full test suite once — a red suite blocks everything after, fix first.
2. Run tdd-policy validate for the current session run and include the preserved decision manifest path and testing_mode in the Done conditions. A successful Stop clears the TDD pending marker but leaves a started manifest for this closeout check; do not consume it here. This confirms the recorded batch mode and every ticket's required／waived decision；不是人類選擇或測試品質的機器證明，也不證明測試已留下或執行順序，實際產物與測試結果仍要核對。
3. 如果本次新增或改動的功能已有可重用驗證配方，就在清理與收尾寫回前讀 ~/.claude/references/verification-recipes-and-probes.md 的「驗證配方維護」並照做；只維護本次受影響的既有文件／trajectory／Verification Log，不新增全站地圖。如果本次驗收包含效能或延遲宣稱、換底層視覺零漂移比對、或已選定的狀態與併發兩層核驗，就在判 PASS 前讀 ~/.claude/references/verification-recipes-and-probes.md 對應的「效能宣稱核驗」「視覺零漂移基準鎖定」或「狀態與併發兩層核驗」並照做。 Write back what the tickets learned, not just what they built. Any acceptance item that was spike- or verification-shaped (its output is an answer to an open question, not code) has its conclusion written into the spec/design, and its verdict — including "the ticket's own premise was wrong" — recorded in the Verification Log. Done when every such acceptance item has either a written-back conclusion or a parked reason; a conclusion that exists only in this conversation counts as not done, since the next session reads the spec, not the transcript.
4. Review the work with /code-review, or with a reviewer subagent whose model you pin explicitly. 如果本次收尾含程式碼改動，就在派這一步審查前讀 ~/.claude/references/review-dispatch-principles.md：不論走哪一條路，都至少派一個語言 reviewer 並審完分到的每個檔，只跑 /code-review 不算滿足底線（可以並用）；沒有程式碼改動的收尾不觸發底線。 如果本次收尾含程式碼改動，就在這一步審查結果彙整進收尾報告前讀 ~/.claude/references/verification-recipes-and-probes.md 的「程式碼品質簡單版」並照做：本次函式的 CRAP 與對全 repo 的結構重複各查一次，命中項逐一選處理方式，有命中時收尾回報只問一次要不要跑 /deep-check；不擋 commit、不另開 review 輪。 如果既有 review 的安全結論依賴尚未證明的行為事實，就在該核驗裁決前讀 ~/.claude/references/verification-recipes-and-probes.md 的「安全假設 probe」，把適用段交給同一個 reviewer 或在既有核驗內完成；不另開 review 輪。 Whichever route, hand the reviewer the failure-mode probe table (~/.claude/references/failure-mode-taxonomy.md) as one review lens with the ticket text beside it. 每個抓到失敗模式的 finding 先對票的驗收清單：對得上標 Acceptance-miss，對不上標 Failure-miss: Fn；兩種標記都寫進 Verification Log（Acceptance-miss — <驗收項> → <實際>／Failure-miss: Fn — <condition → symptom>）；append 到探針表放在 step 5 判定 finding 成立之後（見該步），不在這裡，因為被推翻的 finding 不該進只增不減的登記區。拿不到票的驗收清單（票檔缺失）時，finding 保留並註明「缺驗收依據」，不標記、不 append。Why the tags: on 33 real tickets, 9 of 12 post-ship failure modes were caught exactly here; Acceptance-miss 另抓「票有列、實作沒做」這種更嚴重的漏。這兩個標記是回流機制（每日 channel 計數、/trial-review 消費）唯一認的訊號；a finding without one is invisible to that loop. Do not invoke the built-in code-review workflow directly (Workflow({name: "code-review"})): it pins no model, so every finder and verifier inherits the main-session model, and its verify phase spawns one agent per distinct finding location with no cap and no batching — so the fan-out width, and which model pays for it, are both unknowable before launch. /code-review itself decides inline-vs-workflow from the session's effort level; that decision is the point of calling it.
5. Receive the review before changing code. Collect every reviewer result from the current review round before acting. If every reviewer reports no findings, do not invoke receiving-code-review; continue to step 6. On the first review round with one or more findings after the current Skill(implement) invocation, invoke Skill(receiving-code-review) once and ensure its matching tool result succeeds before triaging or implementing any suggestion. Later review rounds in the same implement run reuse the loaded method instead of invoking it again. A later Skill(implement) invocation starts a new run and may load receiving-code-review once for that run. Apply the method to the complete finding set: verify each claim against the codebase, separate whether the finding is real from whether its proposed fix is right, and record the verdict plus action in the Verification Log. 判定成立的帶標記 finding（Acceptance-miss／Failure-miss: Fn）在同一步、判定成立後 append 一行到 ~/.claude/references/failure-mode-taxonomy.md 的「案例登記」區：用 >>、七欄照該檔格式、發現於填 implement-review；被推翻的不 append。這是編號步驟內的動作，Inline 與 Subagent-Driven 兩種模式都由主 session 寫。 This reception step does not change the current severity or scope policy. Fix only the findings that policy permits, one at a time, then run focused verification for the affected behavior; among fixes that satisfy the accepted criteria and current severity or scope policy, prefer deleting, narrowing, or reusing existing mechanisms, and when adding new state, synchronization, or retries is the smallest valid fix, state the contract it preserves and why a narrower option is insufficient. Do not start a new full review solely because findings were fixed.
6. Invoke Skill(auto-choice) on this run's work and wait for its matching tool result: it writes the choices ledger beside the spec and changes no code, so the Step 10 handback cites a traced ledger instead of a recollection. Then commit only when the user explicitly requested it; before committing, ensure the current branch is not the repo's default branch, creating a task-appropriate branch when needed. 完成後接 Step 7（review-implement handoff）。

7. After the local commit succeeds, invoke Skill(review-implement) and wait for its matching tool result.

   The review-implement skill is the canonical owner of the fixed user-facing preface, axis question, recommendation, Scope／YAGNI mapping, WAIVED／BLOCKED／PASS status, and report schema. It also owns the model matrix, selected <model, axis> seats, and resolved-model attribution for this stage. Follow review-implement Step 1 verbatim as the sole user-facing SSOT rather than duplicating those details in implement. After the matching tool result succeeds, do not wait for an axis answer: the stage runs its Opus seats on its own recommendation, and Fable seats stay unselected without a user choice, so an unanswered selection never stops closeout; wait for the stage's terminal outcome.

   Keep final push／PR handback／archive／completed 宣告 behind the terminal outcome: a stage whose Opus seats have not returned keeps implement at implementation-complete / review-pending until the terminal outcome is recorded, and that wait is for reviewers, not for a user answer; a BLOCKED outcome also stops closeout; continue only for PASS or an explicitly recorded WAIVED outcome. A skip completes only after the waiver is recorded, and never claim review PASS. A skip received after Opus seats were dispatched is handled by the stage under its Step 8, not re-decided here. Implement must carry the selected seats and resolved models from the stage report forward; it must not assume a fixed Fable seat.

   A BLOCKED Run may continue only through an accepted-obligation repair loop; final shipping／closeout remains prohibited, and other BLOCKED decisions or scope expansion wait under the stage contract.

   For each accepted repair obligation returned by the stage, implement owns the bounded loop: run focused verification first.

   If focused verification fails, do not commit or run a targeted recheck; return the same finding-ID within the existing per-root-cause correction budget and keep Run BLOCKED.

   After focused verification passes, follow the existing commit policy to create a new stable commit and head_sha; do not change that policy. A working-tree-only repair stays BLOCKED without rechecking.

   Only after the stable commit, Main performs a read-only targeted recheck against the original finding ID and acceptance evidence; it cannot add findings, dispatch a reviewer, or start a new axis selection. A failed recheck returns the same ID within budget. Ask the top-level user only for budget exhaustion or scope expansion; until the decision, do not expand, commit, or recheck, while independent obligations may continue and dependent obligations wait.

   After all accepted obligations' targeted rechecks pass, run the final full suite against the new head_sha; a red suite keeps Run BLOCKED. Do not automatically start a full review after a targeted recheck; a new round requires the user's explicit invocation through the same stage entry.

   The handoff report must provide review target base_sha／head_sha; an uncommitted target-scope is BLOCKED and must not be reviewed as a moving working tree. Done when the stage terminal outcome is recorded: PASS additionally requires a stable target, passing targeted rechecks for all accepted obligations, and the final-suite result; WAIVED requires its explicit waiver. A BLOCKED handoff stops closeout. 完成後接 Step 8。

8. Architecture visual candidate gate. This gate is independent of review-implement;不得修改 review-implement 的 scope／YAGNI axes 或 waiver 語意。
   1. 依已接受的 spec／tickets、穩定 feature_base_sha..head_sha、最終 diff 判斷邊界。領域／部署／信任／資料所有權邊界改變，或 component／service／module／package／process 之間的跨邊界連線新增、移除、改道或 protocol 改變，才是 candidate；API／schema／config／retry／lifecycle 不能單獨觸發。否則記 not-applicable、reason、diff evidence、head_sha，接 Step 9。candidate 僅顯示 a. 產生 actual delta b. 這次不用；top-level human 回答前不啟動 Archify 或 Plannotator。
   2. no response = 0 次 Archify invoke、0 次 Plannotator invoke，closeout BLOCKED。b 記 waived 人類決策、reason、feature_base_sha、最終 head_sha，接 Step 9；不啟動 Plannotator，維持產圖前 waiver 語意。 🔌 接線點：架構圖產生與審批 — 見 WIRING.md
   3. wrapper 成功後驗證 wrapper receipt、artifact path／存在、base/head SHA、最終 head_sha；receipt 缺失／無效、artifact 缺失、source receipt drift、base/head/final-head mismatch → closeout BLOCKED，不得啟動 adapter。
   4. 驗證全過才啟動唯一一支 adapter background task：Bash(run_in_background=true): node ~/.claude/scripts/plannotator-review.mjs actual-delta <wrapper-receipt> <head_sha>。記錄 adapterTaskId、wrapper receipt identity 與 head_sha；Plannotator 取代舊 terminal artifact verdict，先呈現 artifact 與 wrapper receipt。
   5. Bash 回報 running in background 或 moved to background 代表 adapter task 仍在執行，不是 adapter timeout。adapter task 還是 live 時不得啟動第二支、不得讀未完成 receipt，也不得要求 top-level human 用 user shell 重跑；若收到重跑要求，回覆現有瀏覽器審閱仍在等待，繼續等同一支 task。等 harness task-notification 明確回報 completed 或 failed，不主動輪詢；通知後只用 Read 讀 output file 一次，接受唯一 final JSON 的 receipt path。task failed、final JSON 缺失／重複或 receipt path 不唯一都維持 closeout BLOCKED。
   6. 只有 Adapter exit 0 且唯一 receipt decision=approved、transition=accepted 綁同一最終 head_sha，才寫 accepted outcome；保存 adapter receipt path、feedback、最終 head_sha 到 visual decision／closeout handoff。
   7. 記錄 visual decision accepted 並允許 shipping。Approve with Notes 仍算 accepted，保存 notes 不阻擋。Shipping 另要求 clean tree、最新 review-implement terminal outcome、最新 adapter visual decision receipt 全都綁同一最終 head_sha。
   8. Adapter exit 1 且 decision=annotated、transition=classification-required 時，保存 feedback、維持 closeout BLOCKED；top-level human 只分類 artifact-inaccurate 或 architecture-rejected，agent 不得猜測。classification no-answer 仍 BLOCKED。
   9. artifact-inaccurate 只能用同一組 feature_base_sha／head_sha 重生圖並重跑 wrapper／adapter，不修改 code、不建立新 commit。architecture-rejected 回到 implement；code change 建立新 commit，使先前的 review-implement Run 與 visual decision 同時失效，兩道 gate 都重跑。
   10. dismissed、adapter timeout、gate-error、無效或缺少 result、result／artifact／source-receipt／head drift 與其他 adapter／receipt 錯誤都維持 closeout BLOCKED；Bash 把 live task 移入 background 不算 adapter timeout。不會變成 waiver 或 accepted，並保留 receipt identity。整合 rollback 移除 Plannotator adapter／runtime 變更與 receipts，保留既有 Archify trial evidence；rollback script 與 fixture 由 Ticket 05 完成。只有 not-applicable、waived 或有 evidence 的 accepted adapter outcome 才算完成，其餘維持 BLOCKED。完成後接 Step 9。
9. Follow the repo's own close-out conventions already in context (openspec repos: validate + the PR-bound archive flow). 完成後接 Step 10。
10. For a started implement run in either testing mode, consume the preserved decision manifest only after Step 7 has terminal PASS／explicit WAIVED and Steps 8–9 are complete; a consume failure blocks handback, while BLOCKED／unanswered paths keep the manifest. A not-started manifest was already consumed by its successful Stop. Before declaring closeout blocked or waiting for another owner, reuse /git-closeout as the ground truth and record three independent checks: raw gate deny, fresh remote merge-tree, and local dirty 與部署路徑的交集. Human-controlled PR merge or a remote conflict can be the blocker; unrelated local main dirtiness cannot. 只有交集非空才等待 local dirty owner. 如果收尾仍有待拍板選項，就在回報前套用 Step 1 的「停點回報順序」。 Then hand back in a fixed shape, so someone who was away can read the run without replaying it: what shipped and the evidence for each claim; what you decided on their behalf and why (cite the Step 6 auto-choice presentation and its ledger link rather than rewriting it); what you did not do; what still needs their call. Anything that only exists in the transcript is something they have to go hunting for. 完成後 closeout 結束。