forge

forge — 変更セットの実装と検証

運用上の不変条件

• 承認済みの範囲とクリーンな置き換え：承認済みの変更セットと必要な連鎖的変更を実装し、その解決策によって直接置き換えられる旧ロジック、不要なヘルパー、古いテストを積極的に削除します。実装と検証が DONE に達したら、関連する一時的なスクラッチ成果物（.agents/scratch/）と一時ワークツリーを削除します。無関係な作業は維持し、便乗的なリファクタリングは行いません。
• 方針への忠実性：合意済みの方針の範囲内で実装上の誤りを修正します。成功のために方針、契約、リスク、または影響範囲の大幅な変更が必要になった場合は、変更を止めます。代替設計を選ぶのではなく、再設計が必要な点を報告します。
• 検証の完全性：すべての受け入れ基準と必須チェックに合格するまで DONE としません。失敗の証拠と既存の編集を保持し、黙って元に戻したり、アサーションを弱めたりしません。
• 安全なロールバック：ローカルコミットを取り消す際は、ステージングインデックス内の未コミット差分を保持するため、git reset --soft HEAD~1 を使用します。
• 環境とシークレットの隔離：シークレットファイル（.env*、*.key、*.pem）を調べたり変更したりしてはいけません。テストの実行とリンターの呼び出しは .agents/environment.md に基づいて行います。
• 納品の境界：実装と検証について、提案するコミットメッセージを添えて報告します。コミット、マージ、公開は、このスキルの完了範囲に含めません。

領域別の基準

入力と準備状況

承認済みの変更セットツリー、受け入れ基準、制約、および解決策を裏付ける証拠または該当する公式リファレンスを受け取ります。タスクまたは監査に埋め込まれた変更セットも有効な入力であり、事前に /changeset を呼び出す必要はありません。

現在のチェックアウト、呼び出し元、契約、ベースラインチェック、および裏付けとなる証拠を調べます。公式リファレンスは、この環境における主要な仕組みを裏付けるものでなければなりません。一般的なドキュメントへのリンクだけでは、統合の証拠にはなりません。合意済みの方針を広げずに、対象ファイルの計画を整合させます。

編集前に、プロジェクトのルールと受け入れ基準に基づいて必要な検証を決定します。無関係なベースラインの失敗は明示します。範囲外の修正なしでは必須チェックに合格できない場合は、UNRESOLVED と報告します。DONE に到達するために、失敗したチェックを除外して必須チェックのセットを変更してはいけません。

構築と検証

• [CREATE]、[MOVE]、[UPDATE]、[DELETE] を依存関係に沿って並べ、呼び出し元とインターフェースの整合性を保ちます。
• バグ修正では正確な失敗状態のベースラインを確立します。機能追加では、実装前に合意済みの受け入れ基準を網羅します。動作を維持する変更では、浅いテストを作り出すのではなく、既存の有意義なチェックを使用します。
• 最小限の実装を適用し、該当する型チェック、リンター、対象を絞ったテスト、および影響を受けるサブシステムのチェックを実行します。
• 範囲内であれば、通常のコンパイラー、リンター、テストの失敗を修正し続けます。実装ミス、無効な設計上の前提、無関係なベースラインの失敗を区別します。
• 合意済みの対象範囲外の動作を維持できる場合に限り、インポート、シグネチャ、呼び出し元の更新を小規模な連鎖的変更として扱います。新たな所有権、スキーマの意味論、または大幅な範囲拡大が必要な場合は、再設計が必要です。
• 追跡対象の作業では、設定されたタスクのライフサイクルに従います。編集前に着手可能な作業を取得し、必須検証が完了した後にのみ完了としてマークします。依存関係のゲートを維持します。タスクの追跡は、実行の承認に代わるものではありません。
• 検証済みの完了時に、関連するスクラッチ成果物（.agents/scratch/）と一時ワークツリーを削除します。

状態

• STAGED：既存の変更セットは準備できていますが、実行の承認がまだありません。
• IN_PROGRESS：設計変更が必要なブロッカーはなく、実装を進めています。これは進捗状態であり、通常の修正を中止する理由ではありません。
• DONE：承認された範囲について、実装、受け入れ基準、および必要な検証がすべて完了しています。
• UNRESOLVED：古くなった設計や証拠、必要な検証を実施できないこと、または合意した方針を超える変更などのブロッカーにより、期待される結果を達成できません。

正式な出力仕様

# Implementation Report: <Scope> · <STAGED | IN_PROGRESS | DONE | UNRESOLVED>

<Short-to-medium conclusion and material delta; repo-relative file pointers.>

Verification: <Executed checks and results; identify blocked or baseline failures.>
Remaining: <Blocker, redesign decision, or unfinished work; omit if none.>
Checkout: <Partial edits retained when unresolved; omit if no partial edits.>

Commit message: <Include only when DONE.>
<type>(<scope>): <observable change>
<Brief implementation detail and why it matters.>

振り分け

• 未解決の要件により合意した結果を達成できない → （/clarify 経由）。
• 結果を達成するために方針の変更が必要 → （/architect-decision 経由）。
• 方針は確定したままで、ファイルへの影響を踏まえて再ステージングが必要 → （/changeset 経由）。
• ツールチェーンの不足またはテスト用データストアの障害により検証できない → （/env-doctor 経由）。

実行プロトコル

1. 準備状況を確認します。方針または必要な変更セットがない場合は、UNRESOLVED を報告し、設計またはステージングに引き継ぎます。承認だけが不足している場合は、STAGED を報告し、編集せずに停止します。具体的な範囲についてすでに与えられている承認は尊重します。
2. 評価基準に従って実装と検証を行います。重大なブロッカーが発生した場合は、変更を停止し、証拠と部分的な編集を保持して UNRESOLVED を報告します。それ以外の場合は DONE まで進めます。
3. レポートとコミットメッセージを提出します。設計変更は当初の実装範囲に含めません。