implement

implement - 実装ステージ

不変条件

• 実装ファイルを変更する前に、承認済みのタスクドキュメントが必要です。
• タスクドキュメントを主たるスコープ契約として扱います。
• ユーザーの承認なしにスコープを広げないでください。
• プロバイダー固有のモデル切り替えコマンドに依存しないでください。
• 自動化のエントリーポイントは implement auto のみです。
• タスクドキュメントに未解決の BLOCKING 判断が記載されている場合、作業を開始しないでください。停止し、その判断と選択肢を引用してユーザーに確認してください。
• プロジェクトの AGENTS.md で独自の担当宣言やトラッカーの規約（たとえば「プッシュ済みのブランチが担当を示す。開始時に TASKS.md を編集しない」）が定められている場合は、以下のトラッカー更新よりそちらに従ってください。
• 両方の状態遷移時（開始時の Planned → In Progress、終了時の In Progress → Testing）に TASKS.md を更新し、引き継ぎ前にトラッカーを読み直して行が移動したことを確認してください。トラッカーが古いままだと、後続のセッションやヘッドレスセッションが停止します。

ランタイムアダプターでは、このステージがスラッシュコマンド、メニューアクション、または自然言語のスキル呼び出しとして公開される場合があります。移植可能なステージ名は implement です。

引数の処理

• {ID} または {task-name} はタスクドキュメントを指定します。
• auto は実装後の ship までの自動化チェーンを有効にします。
• --tier fast|balanced|deep は、アクティブなランタイムがティアルーティングをサポートしている場合に限り、タスクドキュメントの推奨を上書きできます。

ユーザーがプロバイダー固有のモデル名を求めた場合、コアワークフローの意味ではなく、アダプターレベルの設定として扱ってください。

ワークフロー

1. AGENTS.md を読みます。
2. LEARNINGS.md が存在する場合は読みます。
3. TASKS.md またはタスクファイル名からタスク ID を特定します。
4. docs/task/{ID}-{task-name}.md を 最新の統合ブランチから読みます（先にフェッチしてください）。ローカルのコピーや古いコピーには、決定事項やスコープに関する注記が反映されていない場合があります。
5. タスクがレビュー済みで、実装が承認されており、未解決の BLOCKING 判断がないことを確認します。どちらかが不明確な場合は、停止して確認してください。
6. Coordination を読みます。同じファイルを変更するタスクが進行中の場合は、指定されたルール（待機する、またはそのブランチと同期する）に従い、Implementation Notes に記録してください。
7. タスクドキュメントに記載されたファイルのみ読みます。ただし、依存関係が欠けていて実装を妨げる場合を除きます。
8. TASKS.md でタスクを In Progress に移動し、Planned から行を削除します。
9. ベースラインを記録します： 変更前にマージ前の受け入れチェックを実行し、値をタスクドキュメントの Baseline に記録します。変更前にすでに合格しているチェックでは、変更を検証できません。その場合は、先に失敗するように書き換えるか、理由を記録してください。
10. 実装手順を ループで適用します。各手順の後に、その手順が影響する範囲で最も限定的なチェックを実行し、期待どおりの結果が得られてから次に進みます。すべてのチェックを最後までまとめて実行しないでください。
11. マージ前の受け入れチェックと非回帰チェックをすべて実行し、ベースラインと比較します。
12. 引き継ぎ前に（また、統合ブランチとの同期後にも）統合ブランチからタスクドキュメントを読み直します。開始後にスコープや判断が変わっていた場合は、調整するか停止して確認してください。古い計画のまま完了しないでください。
13. 実際に変更した内容の Operator Steps を含めて、タスクドキュメントに Implementation Notes を追記します（計画の一覧をそのまま転記せず、差分からデプロイ対象を再計算してください）。
14. TASKS.md でタスクを Testing に移動し、In Progress から行を削除します。
15. TASKS.md を読み直し、タスクの行が Testing にあり、Planned と In Progress にはないことを確認します。行が想定したセクションにない場合は移動が漏れているため、引き継ぎ前に編集してください。
16. 手動モードでは停止し、simplify に引き継ぎます。
17. 自動モードでは、移植可能な自動化チェーンを続行します。

ループのルール

• 観測していない結果を主張しないでください。「動作するはずです」「正しく見えます」、またはビルドが成功したことは、動作に関する基準の根拠にはなりません。実行したチェックとその出力を報告するか、チェックを実行していないと伝えてください。
• **再試行するたびに、何かを変えてください。**失敗したチェックを再試行する前に、今回何が異なるのか（新たな仮説、修正、追加データ）を書き留めてください。何も変わらない場合は、繰り返さずに停止して確認を求めてください。
• 失敗した試行を記録してください（何を試し、チェックで何が示されたか）。次のセッションで同じ試行を繰り返さないよう、Implementation Notes に記録します。
• **チェックに合格させるために、チェックを緩めないでください。**チェックが誤っている場合は、根拠を示しながら、別の手順として説明したうえで修正してください。

読み取りのルール

デフォルトで以下を読みます。

• AGENTS.md
• 存在する場合は LEARNINGS.md
• タスク文書
• File Changes に記載されたファイル

コードベース全体を広く調査することは避けてください。タスク文書に必要なコンテキストが不足している場合は、特定のシンボル、ファイル、ルート、またはコマンドを対象に検索し、その理由を Implementation Notes に記録してください。

実装メモ

タスク文書に次のセクションを追記します。

## Implementation Notes

### What Changed
- {Summary}

### Files Changed
- `{path}` - {reason}

### Deviations From Plan
- {None, or describe with rationale}

### Verification Run
- `{command}` - PASS | FAIL | SKIPPED ({reason}) (baseline: {value} → now: {value})

### Attempts That Failed
- {What was tried, what the check showed, why it was dropped; or "None"}

### Operator Steps
- {Migrations, deploys (incl. importers of changed shared modules), config, or "None: merge is enough"}

自動チェーン

implement auto {ID} として呼び出された場合は、実装後に続行します。

1. simplify {ID}
2. test {ID}
3. document {ID}
4. ship {ID}

ランタイムがバックグラウンドワーカーまたはサブエージェントに対応している場合、アダプターは各ステージを分離されたワーカーで実行できます。対応していない場合は、現在のセッションでステージを順番に実行します。各ステージでは、タスク文書またはレポートファイルに永続的な詳細を記録する必要があります。

同じテストまたは品質上の問題について、修正と再試行を3サイクル行ったら停止し、ブロッカーをユーザーに報告してください。各サイクルでは、ループのルール（何かを変更すること、試行を記録すること）に従う必要があります。

引き継ぎ

手動モードの出力：

Implementation complete for task {ID}
Task status: Testing
Next stage: simplify {ID}

自動モードの出力では、到達した最終ステージとブロッカーを要約します。