implement-task

タスクの実装

Spec フォルダーからタスクを正確に1つ作成します。タスクファイルには、作業範囲、受け入れ基準、検証契約が定義されています。単独実行ではライフサイクル全体を担当します。Roundfix Daemon に割り当てられたターンでは、Daemon による検証と決着に向けて、実装完了可能な作業を引き渡します。

タスクの割り当てを受けた時点で、ユーザー、ループ、Daemon のいずれからの割り当てであっても、着手の許可を得たことになります。 直ちに開始してください。あいさつ、計画への承認を求める質問、「開始」の指示を待つことは不要です。実装前に一時停止できるのは、要件が矛盾している場合、または単独実行のステータスが古い in_progress のままである場合のみです。

実行モード

単独実行と Roundfix Daemon に割り当てられたターンでは、同じタスクの作業範囲、結果、証拠の要件を共有しますが、決着を担当する主体は異なります。

• 単独実行では、エージェントがタスクのステータスを更新し、## Verification に記載されたすべてのコマンドを実行し、新しい証拠に基づいてタスクを決着させ、ユーザーからコミットの許可を得ている場合にのみコミットします。
• Roundfix Daemon に割り当てられたターンでは、Daemon がタスクステータスの唯一の更新者です。エージェントはステータスを編集したり、宣言された ## Verification コマンドを実行したり、最終判定を主張したり、コミットしたりしてはなりません。実装と、実施した重点チェックの証拠を ## Result に記録し、実装完了可能な作業を引き渡します。その後、Daemon が宣言された検証を記載どおりにすべて実行してから、決着させます。
• Daemon による検証コマンドが失敗した場合、同じエージェントセッション内で1回の検証フィードバック修正ターンを行う前に、検証キャパシティが解放されます。エージェントは実装を修正し、## Result を更新し、必要に応じて重点チェックを実行してから、宣言された検証を実行したりステータスを決着させたりせずに、再度引き渡します。

in_progress の状態で届いた Daemon 割り当てのタスクは、新たに開始してください。作業対象のロックにより、稼働中のエージェントが所有していないことが保証されています。再開方法を尋ねたり、ステータスを正規化または決着させたりしないでください。

1. 読み込み

割り当てられた task_NN.md を読み、単独実行で Task のステータスを in_progress に変更する前に、Project Constraint の事前確認を実行します。

1. 完了済みまたはアーカイブ済みのレガシー Spec は、制約の強制的な補完の対象外です。その成果物をバイト単位で変更せずに保ち、再実行や書き換えはせず停止します。
2. 有効な Spec では、PRD と存在するすべての TechSpec に完全な Project Constraints セクションが必要です。各セクションでは、該当する場合は識別子の戦略、認証と HTTP、有効な ADR の義務、ツール権限の所在を記載し、該当しない場合はその理由を記載する必要があります。また、各項目について有効な docs/agents/ のソースパスが必要です。項目、理由、ソースのいずれかが欠けている場合は、Task のステータスを変更せずに停止します。
3. 割り当てられた Task が、リポジトリのツール設定、スクリプト、ignore ファイル、プラグイン宣言、バージョン固定を新規作成、編集、名前変更、移動、削除するかどうかを判断します。ツール変更の承認は、Task の割り当て、セットアップの承認、汎用的な実装依頼から推定できません。
4. ツール関連の Task を開始するには、明示的なメンテナーの承認と、PRD および存在するすべての TechSpec に記載された、リポジトリ相対パスによる正確かつ範囲が限定されたファイル一覧が必要です。変更の許可リストは、その正確なパスと、割り当てられた Task ファイル自体のみです。承認がない場合や内容が一致しない場合は、Task を保留のままにして実行を停止します。
5. 作業を開始する前に git status --short を実行し、既存の変更パスを記録します。それらは引き続きユーザーの管理下にあり、この Task の変更として数えることはできません。

事前確認の後、単独実行では status を確認します。

• pending → status: in_progress に設定して続行します。
• in_progress → 前回のセッションが Task の途中で終了した可能性があります。作業ツリーと git のログを調べて部分的な作業を確認し、見つかった内容を報告して、二重に作業を進めずに今後の進め方を確認します。
• completed / failed → 停止して報告します。再実行には人間による明示的な判断が必要です。

Daemon が割り当てたターンでは、ステータスは Daemon の管理下にあるものとして扱い、編集せずに続行します。

• Task の References に指定された _prd.md と _techspec.md のセクションに加え、CONTEXT.md（コード名とテスト名にはその用語を使用）および参照されている ADR を読みます。
• 要件が互いに矛盾している場合（Task と spec、spec と ADR の間など）は、停止して矛盾を報告します。推測で進めると、spec の不備を実装に埋め込むことになります。

2. 計画

• Requirements と Acceptance Criteria からチェックリストを作成します。

• 変更前のシグナルを記録し、Task がまだ完了していないことを証明します。失敗するテスト、欠けている動作、404 などです。開始時点で失敗している状態がなければ、自分の変更によって成功に変わったことを証明できません。

• Characterization Task では、Task が定めた範囲内で実際の境界を使用します。 割り当てられた Task が Characterization Task の場合、指定された外部サーフェスを操作し、実際の挙動を記録します。偽物、モック、フィクスチャ、推測した挙動で代用してはいけません。その記録は、後続の Task が信頼できる境界の証拠です。

  境界にアクセスする前に、Task に対象と、アクセス先がその対象であることが明記されているか確認します。読み取りのみを行うか、Task が作成する隔離されたインスタンスを使用します。対象に対して Task が許可した認証情報のみを使用し、キャンセルを尊重し、Task が失敗した場合でも作成したものは削除します。実際の境界への書き込みは、Task がその書き込みを明示的に許可している場合に限られます。境界の挙動を記録することは、境界を変更する権限にはなりません。何が証明できるかにかかわらず、許可されていない書き込みは対象外です。Task に対象や範囲が指定されていない場合は、自分で選ばずに停止して報告します。

3. 実装

• 対象範囲内にとどまってください。PRD の「対象外」とタスクのスコープは壁であり、提案ではありません。別のタスクに属する作業は、この差分に含めず、後続対応のメモに記載してください。
• ジェネレーターや担当スキル記録コマンドなど、要件に指定されたコマンドは、Verification で同じテストを実行する場合でも作業の一部です。その出力を手書きしてはいけません。
• TechSpec で指定された接合点で、まずテストを書いてください（事前に合意済みです。新たな接合点を追加するにはユーザーの承認が必要です）。型チェックと対象を絞ったテストをこまめに実行し、全テストスイートはゲートのために残しておいてください。
• 根本原因だけに対処してください。リンターや型チェックの抑制、エラーの握りつぶし、タイミング調整によるハックは禁止です。回避策でタスクを完了させた場合は、バグを起票してください。
• 承認済みのツール作成タスクでは、変更を加える前に毎回、対象パスを変更許可リストと照合してください。_tasks.md やその他の Task ファイルは編集しないでください。必要なパスが承認に含まれていない場合は、リストを拡大せずに停止し、Spec の改訂を依頼してください。

4. 単独検証 — ゲート

単独実行では、証拠を以下の順に揃えてから、最終ステータスを設定します。

1. Task の ## Verification セクションにあるすべてのコマンドを、記載どおりに実行します。
2. 現在の実行モードでローカル完了の証拠が必要な場合は、リポジトリの検証パイプライン（make verify、またはこのリポジトリで文書化されているビルド／リンター／型チェック／テストに相当するコマンド）を実行します。
3. Acceptance Criteria を一つずつ確認します。それぞれに、このセッションで得られた新しい証拠が必要です。コマンド出力、成功したテスト名、観察された動作などが証拠になります。スイートが成功していても、そのスイートで確認されていない基準の証拠にはなりません。

承認済みのツール作成タスクではすべて、最後の編集後に変更ファイルの事後確認を実行してください。取得済みのベースラインを git status --short および git diff --name-only と比較し、ステージ済み、未ステージ、未追跡のパスを考慮します。新たに変更されたパスはすべて、承認済みの正確なパス、または割り当てられた Task ファイルのいずれかでなければなりません。それ以外のパスが見つかった場合は、それ以上変更を加えず、status: failed に設定し、## Result にスコープ外のパスを記録して、復旧できるようワークツリーをそのまま残してください。

限定的な検証から広範な主張はできません。誠実に根本原因への対処を試みても単独チェックが失敗した場合は、status: failed に設定し、試した内容を ## Result に記録して報告してください。黙って「ほぼ完了」とするより、スケジューラーが再試行できる明確な失敗の方が望ましいです。

5. 単独記録

Task ファイルに ## Result セクションを追加し、変更点（ファイル一覧ではなく動作の説明）、実行したコマンドとその結果、各受け入れ基準の証拠、判明したフォローアップ事項を記録します。証拠で裏付けられる Subtasks と Acceptance Criteria のチェックボックスにチェックを入れます。status: completed に設定します。

_tasks.md には絶対に触れないでください。ここで管理するのはグラフの構造であり、進捗ではありません。

6. 単独コミット

• ユーザーから明示的に承認されている場合にのみコミットしてください。
• このタスクのファイルだけをステージしてください（最初に git status --short を実行し、無関係な変更は含めないでください）。
• タスクごとにコミットは1つとし、Conventional Commits 形式を使い、追跡可能性のために本文へタスク ID を記載してください（spec: <slug> / task_02）。
• タスク内からプッシュしたり、PR を作成したりしないでください。公開は別途、明示的に行う操作です。

7. デーモンから割り当てられた作業の引き継ぎ

1. 編集する前に、割り当てられた Task、PRD、TechSpec、CONTEXT.md、有効な ADR、および範囲が限定されたコンテキストパスを読みます。
2. 割り当てられた範囲のみを実装します。_tasks.md、別の Task ファイル、または許可されたツーリングの許可リスト外のパスは、決して編集しないでください。
3. 必要に応じて作業中に、変更対象のパッケージに限って実装に関する確認を実行します。Task の ## Verification セクション、リポジトリで選択された Verification、その差分 Verification、またはテストスイート全体に含まれるコマンドは実行しないでください。デーモンが完了時に、宣言された Verification とリポジトリの Verification を実行します。
4. すべての受け入れ基準について、実装内容と実施した確認の証拠を ## Result に追記または更新します。まだ実行されていないデーモンによる Verification の証拠は使用しないでください。
5. Task のステータスを編集したり、completed、failed、Verification の合格、コミット準備完了、または納品を宣言したりせず、実装可能な状態で作業を引き渡します。
6. コミット、プッシュ、プルリクエストの作成は決して行わないでください。デーモンが宣言された Verification を実行し、Task の最終ステータスを記録して、Task のコミットを担当します。

アンチパターン

• 「動作するはず」という理由で completed にすること — ステータス欄は、機械が再確認しない前提で読み取ります。
• テストを弱めたり、スキップしたり、削除したりして、失敗を解消すること。
• 作業中に見つけた「ついでの修正」をすること — それは範囲外の追加作業です。
• セッション開始時の古い出力で再検証すること。証拠は最後の編集より後のものでなければなりません。
• 他の Task のファイルやステータスを編集すること。
• デーモンから割り当てられた作業中に、宣言された Verification を実行すること、Task のステータスを編集すること、最終判定を宣言すること、またはコミットすること。

フィクスチャ値

credential-assignment Secret Pattern は、大文字の名前が API_KEY、TOKEN、SECRET、PASSWORD のいずれかで終わり、その後に代入があり、文字と数字の両方を含む20文字以上の値が続く場合に一致します。文字のみのフィクスチャ値、または20文字未満の値は、このパターンに一致しません。他の Secret Pattern も引き続き適用されます。テストファイルに例外はありません。