workflow-start

ワークフローの開始

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

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

明示的な spec-superflow のリクエスト、または既存の変更にのみ使用してください。通常のコーディングに spec ワークフローは不要です。

再開

SSF resume <change-dir> --json を一度実行してください。状態、引き継ぎ、チェックポイント、現在の計画の検査をまとめて行います。後続のすべての操作には、返された絶対パス change.path を使用してください。復旧時に、古いソースコピーから記録されたワークツリーへリダイレクトされる場合があります。next_action に従ってください。結果の診断を除き、各コンポーネントのコマンドをすべて繰り返さないでください。続行がブロックされていても、再試行の指示ではありません。再実行する前に、指定された原因を解決してください。次のアクションに関連する成果物のみを読み取ってください。

• debugging：計画が古くても、まず診断してください。診断中に実行可能なウェーブをディスパッチしないでください。
• closing：論理的には完了しています。記録された隔離状態で物理的な完了がまだ保留中の場合は、既存のマージ承認を条件として、残りのアクションを release-archivist に依頼してください。それ以外の場合は停止してください。
• abandoned：停止してください。
• 引き継ぎが ready の場合は、SSF handoff resolve でレビューが必要です。active の引き継ぎはブロック要因ではありません。古いチェックポイントは履歴であり、現在の証拠ではありません。
• Full 計画が見つからない、または古い場合、実装はブロックされますが、調査は可能です。有効な short path と Tweak には計画は不要です。

更新確認（SSF runtime check-update）は任意であり、キャッシュされ、ブロック要因にはなりません。復旧の前提としてネットワークアクセスを必須にしないでください。

新しいリクエスト

リクエストとリポジトリから範囲とリスクを推定してください。CLI の項目を質問票に変えてはいけません。変更名が changes/ 配下の安全な単一相対パスセグメントであることを確認し、そのディレクトリのみを作成してください。すでに与えられている承認は再利用してください。成果物が存在することから承認を推定してはいけません。

モード選択の質問をせず、次の2つのパスのみを提示してください。

• Direct：明確に依頼された変更で、検証範囲が限定されている場合です。同じターン内に SSF workflow start <dir> --path direct --scope "<requested outcome and bounds>" を実行してください。計画パック、推奨の受領記録、実行計画は不要です。影響を受けるテストまたはチェックを使用してください。該当する場合、--verification に tdd/new-test/bounded を記録できます。タスク数とファイル数は目安であり、厳格な上限ではありません。
• Planned：挙動やアーキテクチャが不確かな場合、またはユーザーが計画を求めている場合です。proposal.md（範囲、受け入れ条件、リスク）と tasks.md（順序付きタスクと検証方法）をまとめて作成してください。情報が必要な場合にのみ specs/design を追加してください。共有インターフェースは、実際のコードに照らして一度確認してください。承認を得るため、具体的な計画を1つ提示してください。その計画をすでに対象としている承認は再利用してください。その後、SSF workflow start <dir> --path planned --confirm --reason "<existing approval>" を実行してください。CLI が実行計画を生成し、executing に進みます。contract-builder、手書きの契約、DP-0〜DP-4 の手順、実行に関する推奨は不要です。デフォルトは native + final です。明示的な委任がある場合にのみ --mode sdd を追加してください。

追加の質問をせずに build-executor へ進んでください。通常のデバッグは executing のまま行います。範囲を変更する場合は、影響を受ける計画セクションを更新し、実際の再承認を得たうえで planned start を一度だけ再実行してください。中間状態をたどらないでください。意味に関わらない修正には、レビュー履歴を維持したまま、理由を記録して execution resync を使用できます。

完了には SSF workflow complete <dir> --verification-command "<required check command>" を使用します。チェックは一度だけ実行され、失敗も保持されます。Planned 作業では、現在のレビューと完了済みタスクも必要です。既存の delta specs がある場合は同期が必要です。ユーザーは workflow complete --accept-risk --confirm --reason "<decision and remaining issues>" により、既知のリスクを明示的に受け入れられます。この操作は accepted-risk を記録しますが、合格とは記録せず、統合も許可しません。

レガシー変更

進行中のレガシー変更を自動的に変換したり、記録済みの証跡を破棄したりしないでください。記録された義務を再開してください。Full／legacy Hotfix では、コントラクトビルダーや従来の承認／レビューゲートがまだ必要な場合があります。旧 Quick／Tweak／Lightweight／direct Hotfix では、既存の証跡を使用してください。該当する旧判断についてのみ docs/decision-points.md を読み、すべてのタスクで読む必要はありません。レガシーの移行が不明確な場合に限り、SSF runtime asset read docs/state-machine.md を使用してください。レガシーでは、SSF state init を SSF workflow recommend より先に実行してください。推奨されていない選択肢を選ぶ場合は、承認が必要です。レガシーの Quick／direct Hotfix では、workflow accept --verification を使用し、終了前に test_result: pass を保存してください。移植可能なタイムスタンプには SSF state set <change-dir> dp_0_timestamp now を使用してください。

フェーズごとの引き継ぎに関する質問をせず、承認済みの内部作業を続行してください。どのパスでも、現在のタスクのソースと証跡のみを読み取ってください。進捗報告は短い段落を1つだけにしてください。新たに重要な判断が必要な場合に限って質問し、承認済みの作業について「続けますか？」とは尋ねないでください。