ワーカー指示書テンプレート

ハーネスv6とv7 §3-1に従い、山括弧の欄を具体化して投入する。

対象・変更・所有範囲

• 課題 / 目的: 〈issue IDと期待する挙動〉
• 作業場所 / branch / 比較元SHA: 〈指定値〉。編集可能なファイル: 〈列挙〉。
• まず作業ツリーを確認し、未コミット変更があれば触らず報告する。git手順: 〈認可したコマンド〉。
• 参照する仕様・証跡 / 不変条件 / 触らない範囲: 〈パスと節、互換性の条件〉。
• 読む分冊（AGENTS.md 本体の分冊索引から触るパスに合う docs/invariants/….md を列挙。該当なしは「該当なし」）: 〈分冊パス, …〉。
• memory（コーディネーターが索引と AGENTS.md 節名を grep した結果・v7 §3-1）: 検索語 〈語, …〉／参照 〈memory 名, …〉 または 該当なし。当たった記述は上の欄へ写す（ワーカーは memory を読めない）。
• 実行環境の確認: 〈手順を渡す経路 / TTY の有無 / シェル〉。分かっている場合は前提として手順へ書く。

分岐と裁定

分岐	裁定	根拠
〈分岐〉	〈既決の判断〉	[実測] コマンド・SHA / [仕様] 一次資料の節 / [仮説] 検証方法から選ぶ

仮説はレビュー指示で必ず検証対象にする。仕様が沈黙したら既存の共通制約へ寄せ、fail-closedに裁定し根拠を報告する。 推測値を仕様値と認定しない。判断必須の依存作業は回答まで保留する。

受入条件

1. 〈正常系 / 異常系 / 境界の契約と観測可能な期待値〉。
2. pnpm verify 全緑（install / lint / arch / typecheck / test / build / semgrep / gitleaks）。
3. migration変更時はdocker proof全流し、全psql exit 0・[NG]=0。業務フローを跨ぐ変更は9ステップの業務シナリオとS1、歯の実証。
4. 変異表を最低3本: 変異 / 期待 / 赤の実測（コマンド・RC・検査名）/ 復元後の緑。赤くならない変異も所見に残す。
5. 未検査の象限: 契約ごとの正常系 / 異常系 / 境界の不足と理由を報告書へ書く。
6. 〈追加ゲート、commit / pushの認可先、PR作成後のCI確認の担当〉。PR作成はコーディネーター。

質問と報告

• questionはworker_doneより前に送り回答を待つ。コマンド・ID・capabilityは注入preambleを使う。
• preambleのaskを優先し、timeout / 切断は同じmessage IDのask --resumeで待つ。未着だけで承認・失敗完了にしない。
• send --type questionはOrcaの質問であり、OpenCodeのTUI question（deny）と区別する。
• 待てなくても既存制約で安全に裁定できる範囲だけ進め、「未回答のまま裁定した分岐」を列挙する。判断必須の作業は保留。
• 報告書: 〈指定パス〉。file:line・実測コマンドとRC・変異表・未検査の象限・残課題・pushしたSHA。
• bdは一切操作しない。秘密値を仕様書・報告書・チャットへ書かない。
• 報告書の後、直前のfollow-upをcheckし、preambleのworker_doneを1回だけ送る。終了後はidle。