tracer-implement

実装

合意した動作を、リポジトリに固有の変更を最小限に抑えて実現します：短い計画と承認 → 実装 → レビュー → 必要に応じて修正 → 検証と報告。マージ、PR の作成、別のレビュー ワークフローの実行はせず、フィーチャーブランチ上で停止します。ブランチを完了する選択肢までの作業には /tracer-autopilot を使用します。

範囲と簡潔さ

受け入れ要件とユーザーによる明示的な決定は必ず守ります。プランナーが生成したコード、クラス境界、仕組みは提案にすぎません。同じ要件を既存のコマンドやライブラリで満たせる場合は、簡素化してください。アプローチを変更した場合は記録し、受け入れ要件、明示的な決定、または重大な安全上の制限が変わる場合に限り確認してください。

ユーザーが明示的に選択していないカスタムパーサー、汎用プロセスランナー、権限評価機構、並行実行の保証、または永続化された復旧機構を導入する前に、具体的な必要性とより簡単な代替案を説明し、確認してください。安全な再実行が可能だからといって、並行実行や自動クラッシュ復旧が必要とは限りません。必須のデータ／セキュリティ保護策は維持し、ひそかに弱めず、トレードオフを明示してください。

まとまりのある変更では、通常はコントローラー自身を使い、実装コンテキストを1つにすることを基本とします。複数のファイルやコミットがあるからといって、複数のエージェントが必要になるわけではありません。委任するのは、名前を付けられる調査タスク、または引き継ぎコストを上回るメリットがある、切り分け可能な実装単位に限ります。追加作業では同じコンテキストを再利用してください。ヘルパーは結果を返し、別のエージェントを起動しません。

1. ワークスペースと証拠の計画

1. ブランチとワーキングツリーを確認します。既存のフィーチャーブランチにとどまります。main または master 上にいる場合は /tracer-worktrees に従います。detached HEAD または所有者が不明確な場合は確認してください。無関係な変更は保持します。
2. ワークフローの成果物を書き込む前に、.tracer/ が無視されることを確認します。必要な ignore ルールがあれば、ベースを記録する前にコミットしてください。
3. 新規実行では、開始時の SHA を .tracer/implement/progress.md に記録します。再開時は、その台帳を読み、Git と照合して、範囲、ベース、コミット、実行中のワーカー、保存済みレポートを確認してから、未完了のステップを続けます。最初からやり直すのではなく、既存の作業を復旧してください。ベースが無効な場合や、説明のつかない変更がある場合は確認してください。
4. 変更した動作と重大な失敗経路を確認できる、最小限のチェックを選びます。利用可能な場合は、関連する既存テストをベースラインとして実行します。無関係なテストスイートの失敗は作業指示ではありません。その失敗を報告してください。ベースラインの失敗により今回の変更を評価できない場合は確認が必要です。

原則として、対象を絞ったテストを実行します。リポジトリのポリシーで必要な場合、ユーザーが求めた場合、または影響範囲から妥当な場合に限り、全テストスイートや広範な型チェックを実行します。その場合は理由を説明してください。それ以外の場合は、広範な検証を CI またはユーザーに委ねることを報告してください。既存のテストがない新機能では、リポジトリ全体のベースラインではなく、失敗する受け入れテストが必要です。

台帳は簡潔に保ちます：範囲、変更しないベース、承認済みの計画、実装コミット／コンテキスト、レビューと修正の状況、確認済みの HEAD／ツリー、証拠、懸念事項、結果を記録します。委任前に作業中であることを記し、ワーカー ID を保存します。レビュー／修正の完了済み予算は、再開後も維持されます。一般的な「続けて」というメッセージでもリセットされません。

完了条件： ワークスペース、再開地点、ベース、そして相応の検証方法が把握できていること。

2. 簡潔な計画と承認

.tracer/implement/plan.md に、まとまりのある動作ごとに通常は数項目の箇条書きで記述します。

# <Feature> Task Plan

**Goal:** observable outcome.
**Source:** request, ticket, or spec.
**Acceptance and limits:** required behavior and material safety boundaries.
**Approach:** existing commands/modules to reuse; proposed new mechanisms.
**Verification:** focused commands and the behavior they establish.

### Task 1: <coherent behavior>
- Files: exact affected paths.
- Change: smallest approach; only interfaces needed to coordinate work.
- Check: observable success and material failure behavior.

タスクは1つでもかまいません。フレームワークのレイヤーではなく、まとまりのある動作ごとにタスクをグループ化します。計画段階でテストや実装を先に書かず、実装時にコードを書きます。受け入れ条件に影響する曖昧さは解消し、通常の、元に戻せる細部は実装時の判断に委ねます。

目標、アプローチ、タスクの順序、必要に応じて委任先、確認項目を示します。独自のインフラストラクチャと安全性・復旧の保証は明示してください。タスク名だけではアーキテクチャの承認にはなりません。レビューは1回、修正は最大1回にまとめて行い、修正があった場合は修正箇所のみを再確認することも説明します。承認を待ち、その記録を残します。

完了条件： ユーザーがタスク数だけでなく、実際のアプローチと検証範囲を承認していること。

3. 実装

同じコンテキストで計画に沿って作業します。新しい動作や修正した動作には、対象を絞ったレッド／グリーンテストを使用し、適切な場合は既存の確認項目も実行します。ドキュメントのみの変更では、関連する検証を行い、実行時テストをでっち上げる必要はありません。あらゆる仮定上のパターンではなく、観測可能な要件と重大な失敗経路をテストします。実質的に異なる動作を低コストで網羅できる場合は、パラメーター化したケースを追加します。

新しい抽象化を増やすより、既存の機能を優先します。アプローチに承認済みの範囲を大幅に超える仕組みが必要になり始めたら、いったん止め、構築に着手する前に、より小さな代替案を提案します。大がかりな設計を最後まで仕上げてから、懸念点を報告してはいけません。

リポジトリの規約に従って、まとまりのある変更をコミットします。変更した動作と範囲を一度セルフチェックし、重大な不具合を修正して、任意の強化項目は懸念事項として記録します。コミットと対象を絞った確認結果を台帳に記録します。

委任が妥当な場合は、scripts/task-brief で関連するタスクを抽出し、implementer-prompt.md を使用します。元の受け入れ要件と制限事項をブリーフとあわせて渡します。返された差分、コミット、根拠を検証します。報告だけでは証明になりません。タスクの境界が、新しいエージェントを必須にするわけではありません。

完了条件： 合意した動作が実装され、対象を絞った確認に合格し、実装の根拠が記録されていること。

4. レビューと任意の修正

現在の HEAD を固定し、合意した範囲全体に対して scripts/review-package BASE HEAD を一度実行します。1 回のレビューには ticket-reviewer-prompt.md を使用し、可能であれば独立した読み取り専用のレビュアー 1 名に依頼します。委任できない場合、または委任が過剰な場合は、インラインでレビューします。

到達可能なトリガー、違反している要件、現在の影響（誤った動作、セキュリティ／データ損失、無言の失敗、または必須の動作の不具合をテストで検出できないこと）がそろった指摘のみを受け入れます。見栄えの改善や推測に基づく強化は、作業指示ではなく懸念事項として記録します。合意した要件との重大な矛盾については確認を求めます。レビューと対応方針を .tracer/implement/review-1.md に保存します。

• 受け入れた修正がない場合： 検証を完了して報告します。2 回目のレビューや終了確認エージェントは不要です。
• 受け入れた修正がある場合： fixer-prompt.md を使用し、できれば既存の実装コンテキスト内で、受け入れた指摘の全件を 1 回の修正作業で解決します。指摘 ID、変更内容、対象を絞った結果を .tracer/implement/repair-report.md に保存します。コードを変更した場合は、修正箇所と影響を受ける動作のみを再確認し、できれば元のレビュアーのコンテキストで行って、.tracer/implement/review-2.md に保存します。すべての修正が阻まれ、何も変更されなかった場合は、形式だけの再確認を行わず、「要対応」として報告します。

予算は、委任作業とインライン作業を含む、合意した範囲全体に適用されます。初回レビューは 1 回まで、修正作業は 1 回まで、修正が行われた場合の修正箇所のみの再確認は 1 回までです。補助担当者がレビューや修正作業を開始することはできません。再確認後は未解決の作業を報告して停止します。ユーザーから明示的に新たな許可があった場合に限り、予算を拡張できます。懸念事項を新たな実装タスクにしてはいけません。

完了条件： レビュー指摘に対応方針が示され、修正があった場合は修正箇所のみの再確認が行われていること、または未解決の作業が記録されていること。

5. 最終的な証跡と報告

合意したチェックを最終 HEAD と追跡対象ツリーの状態に対して検証します。同じ状態に対してすでに完了している証跡は再利用し、変更後は影響を受けるチェックを再実行します。対象を絞ったテストに合格しても、フルスイートを実行したとは主張しません。

目標、コミット、レビュー結果（および再確認の結果または省略状況）、修正内容、延期した懸念事項、検証上の制約、保持したブランチを報告します。次の区分を使用します。

• 実装済み： 必須の動作が検証され、対応可能な指摘や懸念事項が残っていません。
• 懸念ありで実装済み： 必須の動作は検証済みで、残っているのは妨げにならない懸念事項のみです。
• 要対応： タスク、必須チェック、対応可能な指摘、または重要なスコープ判断が未解決、あるいは検証できていません。

結果を記録簿に保存して終了します。追加の監査、証明ワークフロー、ブランチの仕上げは含まれません。