build

這是 Octopus 的 build 管線（SDD 後半段）。你（主對話）擔任 Core 編排。

設計原則：全自主、不中途等人，但看得到進度。TPM 已在拍板停點放行過，執行中一律「保守預設＋留痕」跑到底；同時 Builder 每完成一條 task 你就即時轉呈一則 task 回報（單向，不等回覆），TPM 隨行看得懂每條 task 對應的 code——這守住「理解 vs 盲簽」邊界，跑完不必回頭補看。

步驟

0. 入口閘門（確定性檢查，先做）

1. CLI：Bash 跑 openspec --version。失敗 → 停，請使用者先安裝（指令以官方 README 為準：github.com/Fission-AI/OpenSpec）。
2. run-marker：把當下 ISO 時間戳寫進目標 repo 的 .claude/.octopus-arena/.run（目錄不存在先建立）——守門 hook 只在 marker 有效期間生效。本管線於步驟 4 呈報告前刪除。

marker 是本管線的責任，任何出口都要清：marker 寫入後，每一條提早結束的路徑（下方的停下、拒絕，或執行中被使用者喊停）都必須先刪除 .run 再回話。漏刪會讓守門殘留到 TTL（4 小時）到期，期間使用者日常的 merge／主幹 commit 會被 branch-guard 誤攔。

解析 change（給名稱就找 openspec/changes/<name>/）：

• 找不到 → 停，Bash 跑 openspec list --changes（或 Glob openspec/changes/*/）列出現有 change 供確認；位於 changes/archive/ → 拒絕（已歸檔結案，要改版請開新 change）
• Read .openspec.yaml 的 octopus.status：
  • Locked → 直接續跑
  • Draft → 停下請 TPM 拍板（不自動鎖定）：依 ${CLAUDE_PLUGIN_ROOT}/commands/spec.md 步驟 3 的格式呈現完整包（proposal 摘要＋待拍板決策卡＋tasklist），等使用者回 OK；拍板後照 spec.md 步驟 4 用 Edit 標 Locked ＋追記 Arena，再續跑。他不拍板就停在這裡，正常結束（記得刪 marker）
  • Implemented → 拒絕：「此 change 已 merge。tasks 未全完成者屬結案追蹤（完成後 archive），要再動 code 請開新 change」
  • 缺 octopus.status → 停：「change 缺狀態欄位，請先跑 /octopus:init 補登或親手標註」

1. 取得 tasks

Read 同目錄 tasks.md（/octopus:spec 已連 change 一起產出）。 若缺檔（手建的 change）→ 啟動 architect（窄入口：補產 tasks.md）補產，不停等確認，繼續往下。

用主對話的 todo 清單登記全部 tasks——這是 TPM 的進度條，每條回報後勾銷。

2. 實作（Builder 逐 task 派工）

這是「進度可見契約」的當前實作（設計文件 §5.2）：逐條派工讓每次 agent 返回帶一條回報，Core 才能即時轉呈——因為 Claude Code 的 subagent 輸出在它返回前你看不到。Builder 本身是純執行層（不管派工節奏），逐條是**你（Core）**的編排選擇。

用 Agent 工具啟動 builder：給 change 路徑＋完整 tasks＋指定第一條未完成 task。它自驗狀態、建 feature branch（feat/<change-name>）、只做那一條、勾 tasks.md、返回 task 回報。

每次收到回報後：

1. 即時轉呈使用者（task 回報原文——做了什麼／code 導讀／自主決定／測試），單向呈現，不停等回覆；todo 清單勾銷該條
2. 用 SendMessage 對同一個 builder 指派下一條 task（不要重開新 agent——context 連貫是逐條派工的前提）
3. 全部做完 → 取得最終變更摘要

3. 審查與自動修復迴圈（Reviewer ⇄ Builder）

用 Agent 工具啟動 reviewer（branch、主幹、change 路徑）取得驗收報告。

• 有 P1 → 把 P1 清單用 SendMessage 轉回同一個 builder 修，修完重審——自動迴圈，不請示
• 迴圈上限 3 輪：仍有 P1 → 不停下來空等裁決，帶著「修不掉的 P1 與原因」直接進下一步收尾，報告如實標紅、不建議 merge