implement

Files (15)

• LICENSE
• README.md
• SKILL.md
• implement-flow.svg
• regression-closeout.md · references/
• tdd-policy.mjs · scripts/
• architecture-visual-gate-contract.test.sh · scripts/tests/
• matt-tdd-gate.test.sh · scripts/tests/
• preflight-contract.test.sh · scripts/tests/
• review-implement-handoff-contract.test.sh · scripts/tests/
• review-reception-contract.test.sh · scripts/tests/
• tdd-policy.test.mjs · scripts/tests/
• testing-mode-contract.test.mjs · scripts/tests/
• transport-contract.test.sh · scripts/tests/
• worker-guardrails-contract.test.sh · scripts/tests/

SKILL.md (first lines)

<!-- 本檔在契約測試底下：bash ~/.claude/skills/implement/scripts/tests/preflight-contract.test.sh && bash ~/.claude/skills/implement/scripts/tests/review-reception-contract.test.sh && bash ~/.claude/skills/implement/scripts/tests/review-implement-handoff-contract.test.sh && bash ~/.claude/skills/implement/scripts/tests/architecture-visual-gate-contract.test.sh && bash ~/.claude/skills/implement/scripts/tests/worker-guardrails-contract.test.sh && bash ~/.claude/skills/implement/scripts/tests/transport-contract.test.sh && bash ~/.claude/skills/implement/scripts/tests/review-dispatch-principles-contract.test.sh && bash ~/.claude/commands/tests/failure-mode-loop-contract.test.sh -->

<!-- 本檔在契約測試底下：python3 ~/.claude/commands/tests/test_verification_recipe_grafts.py -->

<!-- 本檔在契約測試底下：node ~/.claude/skills/implement/scripts/tests/testing-mode-contract.test.mjs -->

# 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, 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.

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 前讀 [回歸收尾配方](/skills/implement/references/regression-closeout.md)，不 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.

如果 main 準備新派工，就在下方 control loop 的 dispatch 前 invoke `pi-subtask` 核對 session 選路。若該 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，不新增全站地圖。 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` 不算滿足底線（可以並用）；沒有程式碼改動的收尾不觸發底線。 如果既有 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. 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
   4. wrapper 成功後驗證 wrapper receipt、artifact path／存在、base/head SHA、最終 `head_sha`；receipt 缺失／無效、artifact 缺失、source receipt drift、base/head/final-head mismatch → closeout `BLOCKED`，不得啟動 adapter。
   5. 驗證全過才啟動唯一一支 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。

From GGGODLIN/gggodlin-cc-harness, MIT.

More from GGGODLIN/gggodlin-cc-harness