build-executor

ビルドエグゼキューター

同梱ランタイム

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

workflow_variant が planned の場合は、生成された実行プランと現在のタスクのみを読み込んでください。承認はすでにプランに含まれています。コードを編集する前に SSF isolate <change-dir> を実行してください。デフォルトではフィーチャーブランチを使用します。コントラクト、推奨事項、DP-4 は不要です。それ以外のパスでは、まずワークフローのレシートを読み込んでください。Full／legacy Hotfix では承認済みの実行コントラクトが必要です。リンクされた要件／設計は、現在のタスクに関するものだけを読み込んでください。Quick／direct Hotfix／Tweak では、範囲を限定したリクエストと検証戦略を使用します。Lightweight では、レシートに記載された対象を絞ったレビューと検証の要件に従います。

事前確認

Legacy Full／Hotfix では、編集前に SSF isolate <change-dir> を実行し、返された絶対パスのチェックアウトをすべてのコマンドで使用してください。デフォルトでは現在のチェックアウト内のフィーチャーブランチを使用します。ユーザーが --worktree を明示的に選択した場合にのみ、ワークツリーを作成してください。失敗した場合は保護対象ブランチでの編集を中止し、既存の分離状態を維持して初期化の失敗原因を調査してください。Direct パスでは分離も物理的な完了処理も不要です。

Legacy Full では DP-3 の承認に従ってください。記録がない場合でも、ユーザーが会話内でこの正確なコントラクトを明示的に承認しているなら、その既存の決定を記録して続行してください。未確認の動作や変更された動作について承認を推測してはならず、変更されていない内容について同じ承認を再度求めてはなりません。最新のプランがあり、ガードを通過した場合にのみ executing に移行してください。すでに executing の場合は移行を省略してください。

まずネイティブ方式を選択

ネイティブ方式では、現在のエージェントが継続して実装します。永続化されるモードは inline です。タスク数、ファイル数、ウェーブ数を理由に委任してはなりません。batch-inline は互換性のある逐次実行方式です。ユーザーがこの変更での委任を明示的に選択し、かつ独立してスコープを設定できる作業に具体的な利点がある場合にのみ、SDD を選択してください。ツールの利用可能性、タスクの多さ、長いコンテキスト、または一般的な実装承認は、いずれもサブエージェントの使用を許可する理由にはなりません。レビュアーや探索用のサブエージェントも同様です。

Legacy プランのみ（新しい planned 変更にはすでにプランがあります）：

SSF execution recommend <dir> --wave <id>:serial:<task,...>[:<dependencies>] --json
SSF execution plan <dir> --mode inline --review-policy final --confirm --reason "<authorized choice>" --wave <id>:serial:<task,...>[:<dependencies>]

ユーザーがすでに選択したモードを再利用してください。推奨されていない選択をする場合は --acknowledge-recommendation を追加してください。新しい Native プランではレビューのデフォルトは final、SDD では wave です。明示的にリスク境界を設定する場合は --review-policy wave を使用できます。レビュー方針が設定されていない古いプランでは、引き続きウェーブレビューが必要です。モードとレビューの粒度は別々のものです。

不確実な点、中断、修復状況を確認するには SSF execution show <dir> --json を使用してください。編集のたびに形式的に実行する必要はありません。Native のウェーブにおける依存関係は完了済みタスクです。チェック済みタスクを、全範囲の最終レビューの代わりにしてはなりません。

範囲を限定した事前確認

最初の編集前に、承認済みタスクが依存する共有のプロデューサー／コンシューマーインターフェースとテストのエントリーポイントだけを確認してください。指定されたシンボル、ペイロードのフィールド、受け入れテストを特定できることを確認します。不一致は既存の進捗記録に記載し、承認済みの動作の範囲内で実装の詳細を解決してください。不一致の解決によって動作、スコープ、権限、または外部への影響が変わる場合に限り、質問してください。この確認のために探索用エージェントを派遣したり、別のプランニングパックを作成したりしないでください。

実装ループ

1. タスクを依存関係の順に実装します。Full／legacy Hotfix では、動作に関する回帰テストを失敗させ、RED を確認してから最小限の修正を行い、GREEN を確認します。ドキュメントの変更では、架空の単体テストを作成せず、フォーマット、リンク、ビルドのチェックを使用します。
2. タスクごとに影響を受けるテストを実行し、適切な境界で統合テストを実行して、最終的なコードの状態で必要な完全チェックを一度実行します。コード、環境、コマンドが一致する場合に限り、既存の結果を再利用します。変更があれば、影響を受ける証拠は無効になります。
3. 完了したタスクに印を付け、結果、ファイル／コミット、検証、次のアクション、未解決のリスクを簡潔に記録した進捗項目を追記します。小さなタスクごとにタスクブック、納品レポート、チェックポイントを作成しないでください。中断や長時間の作業からの復旧に必要な場合は、SSF checkpoint save を保存します。
4. 承認済みのタスクの間で許可を求めずに続行します。タスクが保留中であることやレビューが残っていることを理由に、コントローラーのターンを終了しないでください。既存の承認を再利用し、次の承認済みタスクについて「続けますか？」と尋ねないでください。進捗状況は簡潔に伝え、自律的なバックグラウンド実行を約束しないでください。

新しい直接変更／計画済み変更では、実行中に発生した通常の不具合を診断します。再現し、原因を追跡し、修正して検証してください。別の状態遷移、タスクレポート、デバッグ台帳を作成しないでください。同じ問題が新たな有効なアプローチなしに未解決のまま残る場合に限り、エスカレーションしてください。既存の legacy 変更では debugging に移行して、bug-investigator を使用できます。想定どおりの RED はテストの証拠であり、予期しない不具合ではありません。スコープ変更では Full を specifying に巻き戻し、契約のずれでは bridging に巻き戻します。短縮パスでは契約を作り上げず、リスクの記録を更新してください。

テストの証拠の選定に迷う場合は、SSF runtime asset read skills/build-executor/writing-good-tests.md を読んでください。

レビュー

Native の final では、現在の実行担当者が、実装と必須テストの後に全範囲を一度レビューし、仕様への準拠とコード品質を確認します。レビュアーのサブエージェントを起動しないでください。コードをコミットし、レポートを実際の Git 範囲にひも付けます。次のコマンドで記録してください。

SSF execution review <dir> --wave final --base <base-sha> --head <head-sha> --report .superpowers/sdd/reviews/final.md --verdict <pass|fail>

wave では、計画された各ウェーブにつき一度レビューし、final の代わりにその ID を使用します。依存関係のある作業には、最新の合格レシートが必要です。SDD では、ユーザーが委任を許可しているため、各ウェーブにつきレビュアーのサブエージェントを一つ使用できます。タスクごとのレビューと最終レビューを重複して追加しないでください。Critical／Important の指摘には、失敗 → 対象を絞った修正 → 一度の対象を絞った再レビュー → 合格、の順で対応します。

再試行する前に、CLI の修復ステータスを確認してください。修復状態ファイルは決して編集しないでください。新しい計画では、レビュー不合格時に安定した --issue <finding-id> を記録し、同じ未解決の不具合には同じ ID を使用します。その issue での失敗が3回に達した場合は、人間による判定が必要です。別の指摘には同じ上限を適用しません。legacy の計画では記録済みの集計上限を維持します。SSF execution adjudicate <dir> --wave <id> --decision allow-review --confirm --reason <text> は、レビューをもう一度行うことのみを許可し、合格を意味するものではありません。以前のレビューのヘッドを維持し、修正範囲が連続するようにしてください。最終レビューでは、最終スナップショットを認定するため、必要に応じて修正分を加えた元の全範囲を再レビューします。

オプションの SDD

SDD が選択された場合にのみディスパッチ資料を読み込みます。レビュー担当者向けプロンプトは、ウェーブがレビュー段階に達した場合にのみ読み込みます。

• SSF runtime asset read skills/build-executor/implementer-prompt.md
• SSF runtime asset read skills/code-reviewer/code-reviewer-prompt.md

タスクの目的、対象を限定したファイル、インターフェース、関連する要件 ID、テストコマンドのみを送信します。焦点を絞った修正では、同じ実装担当者を再利用します。入れ子の委任や、計画一式の繰り返しは行いません。密接に関連する小規模なタスクはまとめます。プラットフォームがサポートしている場合に限り、独立した作業を並行してディスパッチします。それ以外の場合は制約を報告し、順次実行します。

プロファイル：mechanical、standard、strong、review。各ロールにつき一度だけ SSF runtime config --resolve-model <profile> で解決します。サポートされている場合は、設定されたモデルを渡します。configured: false の場合はホストのモデルを継承します。モデルを独自に指定したり、実行を妨げたりしてはいけません。ブロックされた作業を再試行するのは、新たな証拠、コンテキスト、または戦略がある場合に限ります。3 回試みても解決しない場合は、DP-5 を使用します。

計画の修正と完了

意味的な変更を伴わない計画の修正には、修復チェーンが開いている間も含め、SSF execution resync <dir> --confirm --reason <text> を使用します。履歴と失敗回数は引き続き有効です。意味的なスコープ変更には再承認と execution revise が必要です。改訂時に、承認済みのモードを維持することも変更することもできます。古いレシートは履歴として残りますが、変更されたスコープや新しい最終スナップショットを自動的に証明するものではありません。

完了前に、契約上の義務、テスト、計画で定められたレビュー方針を満たしてください。必要に応じて batches_completed を記録します。新たな直接変更または計画済みの変更では、最終検証コマンドを指定して workflow complete を使用します。レガシー変更は release-archivist に引き継ぎます。マージ、プッシュ、公開には、それぞれ既存の個別の承認が必要です。

Quick／直接 Hotfix では、対象を限定した検証後に test_result: pass を永続化します。Hotfix では、元の症状が解消されたことを示す必要があります。DP-4、実行計画、ウェーブレシート、DP-6、DP-7 は不要です。Lightweight ではさらに、レシートで求められる対象を絞ったレビューと、合格したコマンドを永続化します。

Quick では、レシートに永続化された検証戦略に従います。Tweak では TDD を省略します。Full とレガシー Hotfix では RED → GREEN → REFACTOR を実施します。