contract-builder

コントラクトビルダー

バンドルされたランタイム

以下の CLI 行を実行する前に、先頭の SSF を node "<plugin-root>/scripts/spec-superflow.mjs" に置き換えてください。<plugin-root> は、このファイルの 2 階層上にある絶対ディレクトリです。SSF をそのまま実行したり、PATH 上の ssf を呼び出したりしないでください。

レガシー互換性のみ：新たに計画する変更では、proposal.md + tasks.md を使用し、SSF workflow start --path planned を実行してください。それらについてコントラクトを生成したり、2 回目の承認を求めたりしないでください。残りの手順は、既存のレガシー変更にのみ適用されます。

計画アーティファクトを、単一の実行ハンドシェイクである execution-contract.md に変換します。SSF runtime asset read templates/execution-contract.md でベースラインを読み込みます。

生成前に、.spec-superflow.yaml（特に dp_0_decisions）、proposal.md、specs/、design.md、tasks.md を読み込み、その後 SSF runtime asset read docs/artifact-contract.md で docs/artifact-contract.md を読み込みます。

コントラクトを記述する前に bridging に移行してください。すでにその状態にある場合は、移行をスキップしてください。設定された仕様／設計の省略ルールに従ってください。要件の全文をコピーするのではなく、要件 ID とタスク ID を参照し、スコープ、義務、テスト、レビュー方針を維持してください。

アーティファクトの言語

dp_0_decisions から artifact_language=<concrete-language> を読み取ります。解決された値および承認済みの計画アーティファクトと同じ言語で execution-contract.md を生成してください。必須のスキーマキーワードとコード識別子はそのまま保持してください。言語の一貫性は、説明文と見出しに適用されます。具体的なアーティファクト言語が指定されていない、またはまだ auto の場合、推測したり暗黙的に英語を既定値にしたりせず、コントラクトを記述する前に workflow-start に戻してください。

アーティファクトの対応付け

ソース	抽出する内容
proposal.md → ## Why + ## What Changes	インテントロック（問題 + スコープ）
proposal.md → ## Scope > ### Out of Scope	スコープ境界
specs/ → 各 ### Requirement:	承認済み要件、シナリオ、テスト義務
design.md → ## Decisions	アーキテクチャ、インターフェース、依存関係の制約
tasks.md → 番号付きタスクグループ	実行バッチ、完了定義、レビューのタイミング

クロスチェック：要件の網羅性

最終確定する前に：

1. specs/ のすべての SHALL／MUST を列挙します
2. それぞれが承認済みの動作に反映され、テスト義務があり、少なくとも 1 つのバッチに含まれていることを確認します
3. 対応付けられていない要件をエスカレーションルールに記録します
4. バッチ間の依存関係を記載します

コントラクトの構成

承認済みの動作、対象外、制約、バッチ、テスト義務、レビューチェックポイント、計画に差し戻す条件が明確になるようにします。計画の詳細を繰り返すより、簡潔にまとめてください。

承認モデル（DP-3）

ドラフト作成後、引き継ぎルールを要約し、曖昧な点を特定し、対応付けられていない要件を明示します。このコントラクトを正確に対象とする明示的な承認がすでにある場合はそれを再利用します。そうでない場合は、未決の計画上の判断と既定の Native 実行の選択肢と併せて、一度だけ承認を求めます。スコープへの承認だけでは、提示されていないコントラクトの承認にはなりません。同じ内容のコントラクトについて、ユーザーに 2 回承認を求めないでください。承認後：

SSF state set <change-dir> dp_3_result "approved: <summary>"
SSF state set <change-dir> dp_3_timestamp now
SSF state rebuild <change-dir>

承認後に状態を進めます：

SSF state transition <change-dir> approved-for-build

DP-3 は必須のゲートです。この記録がない限り、実装を行ってはいけません。

古いコントラクトの検出

次の場合は更新してください：proposal のスコープが変更された、specs の要件が変更された、design の制約が変更された、tasks のバッチが大幅に変更された、またはコントラクトがインテントと一致しなくなった。

ホットフィックスモード

レガシーのホットフィックスに限り、最小限のコントラクトを生成します：インテントロック（1 文）、タスクリスト（番号付き）、承認ゲート（DP-3）。スコープ境界、ビルドルール、レビューチェックポイント、テスト証跡は省略します。それでも DP-3 の承認は必要です。クイック直接実行と直接インシデントのホットフィックスでは、このスキルを呼び出しません。代わりに署名済みレシートを使用し、test_result: pass で完了します。

ガードレール

• 曖昧さが残っている場合は、実装に進まないでください
• ユーザーに代わって契約を承認しないでください
• 計画ドキュメントが完成しているように見えても、契約を省略しないでください
• 対応付けられていない要件を明示してください。黙って除外しないでください

生成後

承認済みの契約は、保護された遷移の前に、上記の DP-3 シーケンスで state rebuild によって記録されます。これは Full とレガシーの Hotfix に適用されます。未承認のコンテンツ変更を抑制するためだけにハッシュを更新しないでください。

例外処理

• 解析エラー：該当するファイルとセクションを明示してください。spec-writer の再実行を提案してください。
• ファイルの欠落：欠落している成果物をすべて列挙してください。spec-writer に差し戻してください。
• ユーザーによる中断：再開時にすべての成果物を読み直し、コンテンツを比較して契約が古くなっていないか確認してください。
• 検証失敗：エスカレーションルールと承認サマリーで、対応付けられていない要件を明示してください。