implement

計画は細かく分け、一度に1つのスライスだけを進めます。スライスとは、観測可能な動作に対する最小の変更です。docs/specs/<slug>.md に仕様書がある場合は、その受け入れ基準を計画として使います。基準を1つずつ進めてください。差分では、仕様書の非目標で除外されているものを変更してはいけません。仕様書に ## Open decisions セクションが残っている場合、それはドラフトです。drill に差し戻してください。仕様書がなく、計画も確定していないリクエストは、まず drill に送ります。ファストパスでは、計画を1文で提示します。

1. 最初のテストの前に、タスクリストを作成します。仕様書がある場合は、受け入れ基準ごとに1項目を追加します。仕様書がない場合は、スライスごとに1項目を追加します。次に verify を追加し、作業が UI、公開インターフェース、名前、またはドキュメントに関する場合は rubric も追加します。3項目未満のリストは作成しないでください。作業をコミットしたら、各項目を完了にします。項目をスキップする場合は、完了にしたうえで、その項目のテキストに skip: <reason> を追加します。基準をスキップしてはいけません。未完了のままにしてください。
2. 未完了のスライスのうち最小のものを選び、このセッションで手順3〜7を実行します。ユーザーがスライスをワーカーに割り当てるよう依頼した場合は、implement スキルを実行するサブエージェントを起動します。サブエージェントは1つのスライスに対して手順3〜5を実行します。その差分を確認し、ここで手順6と7を実行してください。
3. そのスライスで失敗するテストを書きます。テストは実装の詳細ではなく、インターフェースを通して行ってください。失敗するテストを書けない場合、テスト対象のインターフェースが間違っています。テストではなく、計画を修正してください。
4. テストを通すために必要最小限のコードを書きます。
5. テストが通っている間だけ、リファクタリングします。周囲のコードのスタイルに合わせてください。
6. 差分で、他のコードが使用しているシンボルを削除または改名する場合は、ゲートの前に blast-radius.md に記載された確認を行います。また、他のモジュール、保存データ、または外部の呼び出し元が依存する契約を差分で変更する場合も、同様に確認してください。
7. verify スキルを読み、そのスライスに対してゲートを実行します。エビデンス記録に基づいてコミットします。
8. 残りのスライスがなくなるまで、手順2に戻ります。

ルール：

• ベースブランチにいる場合は、最初のテストの前に新しいブランチを推奨し、ユーザーに確認します。ベースブランチとは、リモート HEAD が指しているブランチです。新しいブランチには、仕様のスラッグ、または一文の計画を短くしたスラッグを付けます。ユーザーがそう指示した場合に限り、ベースブランチで作業します。ユーザーの指示を推測してはいけません。すでにフィーチャーブランチにいるセッションは、そのままのブランチで作業します。
• 一度に実装するのは一つだけです。自分の判断で、未完了の作業を新しいタスクに持ち越してはいけません。仕上げて取り込む、一部を取り込む、後で作業できるようブランチに残す、のいずれかを提案します。どれにするかはユーザーに選んでもらいます。作業を終了するのは land のみです。
• 失敗するテストが存在する前に、本番コードを書いてはいけません。唯一の例外は、テストで操作できないホスト内部でのみ効果を持つ接続処理です。例として、プラグインのエントリーポイントやフレームワークへの登録があります。その証明には verify を通じたエンドツーエンドの実行を使い、ソースコードに対する正規表現や文字列の照合は使いません。
• モジュールまたはエクスポートされた型を追加する最初のスライスに着手する前に、shape first に従って形を決めます。スケッチは、動作のない not implemented スタブのみを含む1つのコミットです。したがって、スタブは、それらを実装する失敗テストより先に作成します。
• スライスの最初のテストを書く前に、そのスライスが失敗する可能性を列挙します。発生しそうなものと、データ、金銭、アクセス、呼び出し元との契約の破綻を招くものをテストします。その他の可能性はコミットメッセージに記載します。テストの規模は変更に合わせます。1行の修正には回帰テストを1つ用意し、新しいテスト基盤は作りません。
• スライス内では、そのスライスを検証するテストだけを実行し、スイート全体は実行しません。スライスのゲートはステップ7まで待ち、規模は verify で判断します。仕様で宣言されたフェーズ内では、ゲートは outcome-oriented execution に従います。同様の編集が続く場合は、sequence verifiable units に従います。
• 各テストについて、変更を2種類想定して確認します。動作が壊れたときはテストが失敗し、内部実装だけを変更したときはテストが通る必要があります。アサーションがモック、呼び出し、またはエラーメッセージを検証している場合は、test behavior, not implementation を読みます。アサーションが対象の出力とリテラル値を明確に比較していない場合も、同じ資料を読みます。ソースコードに対する grep や文字列の照合では、動作を何も証明できません。テスト対象の動作で失敗するまでは、スライスは完了ではありません。
• すべての差分をそのスライスに限定します。変更する各行はスライスに属するか、スライスで変更するファイルの不要なコードを削除するものでなければなりません。
• 何かを追加する前に、次の4つの質問をこの順番で確認します。これは存在する必要がありますか？標準ライブラリまたはプラットフォームが対応できますか？すでに存在する依存関係で対応できますか？1行で済みますか？ファイル、レイヤー、依存関係、またはパラメーターを追加する前に、laziness protocol と subtract before you add を読みます。ラッパー、レイヤー、または状態を追加するのは、minimize reader load のテストに合格した場合だけです。テストコードについても、4つの質問を確認します。新しいものを書く前に、スライスの一環として既存のフェイク、フィクスチャー、またはヘルパーを拡張します。
• 機械的な作業にはツールを作り、ツールに作業をさせます。機械的な作業とは、連続した編集、移行、生成ファイルの作成、またはデータの分析です。最初の手作業による編集の前に、build the lever を読みます。
• スライスのロジックが状態を保持する場合や、形状に応じて分岐する場合は、先にデータの形を定義します。スライスで後続のスライスが共有する型を作成する場合も同様です。そのロジックを書く前に、model the domain と foundational thinking を読みます。
• 型安全なコードを保ちます。キャストや、型チェッカーを回避するその他の方法は使いません。型やシグネチャーを設計するときは、type-system discipline を読みます。
• I/O 境界でデータを検証し、内部では信頼します。設定値は入力です。コードで設定値を構築する箇所で検証し、不正な値は最初に使う箇所ではなく、その場で拒否します。検証、エラー処理、アダプター、または設定コードを書くときは、boundary discipline を読みます。失敗を隠す暗黙のフォールバックは使いません。
• ネットワーク越しのすべての呼び出しにタイムアウトを設定します。呼び出し元が再試行できる書き込みには、すべてべき等性キーを付与します。状態を書き込み、二度実行される可能性があるコマンド、起動処理、スケジューラー、またはループについては、make operations idempotent を読みます。
• 2つの操作が同じデータにアクセスする場合は、一度に1つずつ実行します。または、await の前にデータを確保し、処理中として印を付けます。その後、await の後に、それ以前に読み取ったすべての条件を再確認します。2回目の確認だけでは、課金や送信が二重に実行されるのを防げません。2つのアクターが同じファイル、キー、またはデータに書き込める場合は、separate before serializing shared state を読みます。
• コンポーネントの状態を変更できるのは、そのコンポーネント自身の操作だけです。呼び出し元が状態を変更できる参照を渡してはいけません。呼び出し元が参照を保持している間に変化する可能性のある状態への参照も渡してはいけません。コンポーネントの状態を公開する前に、minimize reader load を読みます。
• 変更によって使われなくなったものは削除します。まだ呼び出し元が存在する API を置き換える新しい API を書く前に、migrate callers, then delete legacy APIs を読みます。スライスで変更するファイルでは、追加する前に不要なコードも削除します。不要なコードとは、どの呼び出し元も使わない関数、インポート、パラメーター、およびどの呼び出し元も到達しない分岐です。古くなったフラグや、境界ですでに行った検証を重ねて行うバリデーターも含みます。コードを繰り返すコメントや、回避策を正当化するコメントも含みます。非目標によって範囲外とされた不要なコードは残します。他のファイルにある不要なコードには印を付けますが、削除はしません。
• コードを繰り返したり、回避策を説明したりするコメントは書きません。回避策は原因を修正するか、型、lint ルール、またはテストで制約を表します。コードだけでは表せない内容に限り、コメントを残します。たとえば、ブラウザーの癖、ベンダーのバグ、プロトコル要件など、プロジェクトでは制御できない動作です。
• UI を構築するスライスでは、プロジェクトに DESIGN.md がある場合、タイポグラフィ、色、間隔の指定に従います。
• 各スライスのコミットメッセージは、リポジトリの規約に従い、1行で書きます。規約を確認するには、直近の git log を読みます。規約がない場合は、小文字の命令形を使います。基準は仕様 ID ではなく、その内容で示します。変更だけでなく、その理由も記載します。ステージングするのは特定のファイルだけとし、git add . は使いません。
• スライス内で発生したバグや予期しない失敗は、debug スキルに引き継ぎます。パッチで症状を隠してはいけません。
• スライス内でユーザーが決めるべき事項を推測してはいけません。作業を止め、決定事項を明示して、ユーザーの回答を待ちます。受け入れ基準、非目標、または公開インターフェイスが変わる場合、その決定はユーザーが行います。ユーザーの権限が必要な場合や、取り消せない場合も同様です。その他の、実行して判断できる事項はすべて、never block on the human に従って実行し、決定します。
• 同じスライスで3回失敗したら、ループを止めます。基準、試したこと、最後のエラーをユーザーに報告します。
• 最後のスライスをコミットしたら、verify スキルを読み、その指示に従います。作業が完了したと伝える前に必ず行います。UI、公開インターフェイス、名前、またはドキュメントについては、rubric スキルも読み、その指示に従います。作り手が自分のセンスを評価してはいけません。