forge

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

運用上の不変条件

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

ドメイン評価基準

入力と準備状況

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

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

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

実装と検証

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

状態

• 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 経由）。

実行プロトコル

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