loop-graph

loop-graph — さまよい続けるループではなく、エージェントノードのグラフ

モジュール境界

これは共有コンパイラーであり、目標固有のワークフローではありません。グラフの構造、5つのランタイムアーティファクトのスキーマ、汎用的なインタビューの仕組み、ホストへの引き継ぎを担います。特定用途向けのプリセットが担うのは、North Star、証明、インタビューの質問、推奨する作業形態、メソッドのガード、ノブ、スラッグのみです。テンプレートを分岐させたり、ランタイムノードを追加したりすることはありません。

コードのクリーンアップには../loop-converge/SKILL.md、要件の実装には../loop-deliver/SKILL.md、エビデンスに基づくソリューションの選定には../loop-research/SKILL.mdを使用してください。このスキルを直接使うのは、カスタムパックが本当に必要な場合に限ります。正確な契約はdocs/preset-contract.mdに記載されています。

機能とその理由

「本番環境で使える状態にする」「ベースラインを上回る精度にする」「移行を完了する」といった漠然とした長期的な依頼を、多数のラウンドを通じて仕様から逸脱しない小さなエージェントノードのグラフに変換します。

• 実行ノード — 単一のスコアボードに沿って、ラウンドごとに作業を進めます。
• 監督ノード — 実行ノードのコンテキストの外側から作業を監査し（共通基準に照らして完了済みとの申告を再検証）、逸脱が積み重なる前に軌道を修正します。

ループではなくグラフにする理由：長期タスクに取り組むエージェントは、逸脱したコンテキストの内側にいるため、スコープの拡大を正当化し、未完了の作業を「完了」と呼んでしまいます。ノード間のやりとりは、永続的で検査可能な状態（台帳、Gitツリー、指示ファイル）だけを介して行い、汚染された共有コンテキストは使いません。

各ノードは独自のタイマーで実行され、他のノードを起動することはありません。 実行ノードが起動し、ウォームコンテキストで検証済みのラウンドをいくつか完了して終了します。監督ノードはより遅い周期で起動し、監査して修正を追記し、終了します。修正は、実行ノードが次に起動したときに反映されます。独立した2つの時計と1つのファイル経由の接続だけで、ディスパッチも、再開プロンプトも、稼働状態プロトコルもありません。そのため、起動を待ち続けて実行が停止することもありません。

構築されるグラフ

        ┌─────────────┐   reads / rewrites   ┌──────────────┐
        │  EXECUTOR    │ ───────────────────▶ │              │
        │  node        │ ◀─────────────────── │  ledger.md   │  ← single scoreboard
        │ (own timer)  │                      │ (shared state)│
        └─────────────┘                      └──────────────┘
              ▲                                      ▲
              │ reads each round                     │ reads only (never writes it)
              │                                      │
        ┌───────────────┐   appends corrections ┌──────────────────┐
        │ directives.md │ ◀──────────────────── │   SUPERVISOR     │  ← separate context,
        └───────────────┘                       │ node (own timer) │     slower cadence
                                                 └──────────────────┘
                                                     │ checkpoint-commits clean work
                                                     │ escalates human-only calls
                                                     ▼
                                                   git / you

短いインタビューから作成される5つのライブアーティファクト：

1. executor.md — 実行プロンプト：1つのタスクブック、1つの周期、肥大化を防ぐルール、停止条件、越えてはならない一線。
2. ledger.md — 両ノードが参照する唯一のスコアボード。実行ノードが毎ラウンド書き換えます。
3. directives.md — 範囲を限定した一方向の修正キュー。現在のSTANDINGロックと、まだ取り込まれていない番号付き修正で構成されます。取り込み済みの修正は、順次コールドアーカイブに移されます。
4. ops.md — すべてのコールドノードが従う、正確なコンテキストの索引とゲートです。該当する場合は、現在の環境、データ、ホストのライフサイクルに関する事実も記載します。事実はタイムラインとしてではなく、その場で更新します。
5. supervisor.md (任意) — スケジュールに従って実行される監督プロンプト。完了済みとの申告を独立して再検証し、合格したものをチェックポイントコミットし、保留中の項目を判断し、指示ファイルを介して逸脱を修正したり計画を調整したりします。

実行ディレクトリ — 固定で、実行ごとに1つ。 上記のすべてをリポジトリのルート（複数リポジトリの実行ではワークスペースのルート）にある.longgraph/<YYYY-MM-DD-slug>/に配置し、実行中のローテーション用にarchive/サブディレクトリを設けます。新しい実行では、必ずテンプレートから.longgraph/…を新規作成してください。以前の実行のファイルを転用したり編集したりしてはいけません。古いプロンプトへのパッチはトークンを浪費し、古い目標へ誘導する残存テキストを残してしまいます。古いディレクトリには手を加えずに残します（それ自体がアーカイブです）。今も有効な内容を新しい台帳の開始時点のスナップショットにまとめ、引き続き有効なSTANDING指示を引き継ぎます。データポリシーで禁止されていない限り、実行ディレクトリをコミットしてください。グラフが依存する永続状態だからです。

ランタイム契約IDはlonggraph.loop-graph.*です。

不変条件：スコアボードは台帳のみです。各ラウンドで独立して検証可能な作業項目を1つ（まとまりのある作業セットでも可）扱い、検証してから台帳を更新します。監督ノードはdirectives.mdを介してのみ誘導します（一方向の接続）。台帳を編集することも、実行ノードのコンテキストを共有することもありません。

使用するタイミング

• タスクが何度も繰り返され、ユーザーが各回に付き添うことができません。
• 「完了」を検証できます（テスト、ゲート、メトリクスなど）。グラフが自ら確認できる完了条件が必要です。
• スコープの拡大、「完了したように見える」だけの作業、契約のひそかな変更や基準の引き下げといった、現実的なリスクがあります。

一度きりの編集や、成功するたびに人間の判断が必要な場合には使用しないでください。その場合はそう伝え、通常のタスクを提案してください。

言語

ユーザーの言語でヒアリングし、成果物内の文章（目標、メモ、譲れない条件）にもその言語を使用してください。ファイルをツールで扱いやすく保つため、構造上のキーワード、見出し、フィールド名はテンプレートのとおりにしてください。

プリセットスキルから呼び出された場合

兄弟関係にあるオーサリングスキル（たとえば loop-converge）がプリセットパックを割り当ててから、ここに引き継ぐことがあります。パックは preset contract に従います。以下の項目については、すでに回答済みとして扱ってください。

• North Star と証明 — パックに検証可能な成果の確認方法が明記されていない場合を除き、この質問は省略してください。
• Supervisor — パックで必須とされている場合は必須です。省略するかどうかを尋ねないでください。
• Method guards — パックのガードを PROJECT_SPECIFIC_METHOD_GUARDS として追加してください。
• Knob overrides — デフォルト値ではなく、パックの数値を使用してください。
• 推奨する構成 — 調査の結果、実質的に異なる構成が必要だと判断されない限り、パックの分解案（マイルストーン、または全体にわたる実行の場合はローテーション）を A として提示してください。
• 成果物で重視する点 — パックで必要とされる情報を、共通の ledger.md、ops.md、directives.md、executor、supervisor の各セクションにまとめてください。別のランタイムテンプレートやスコアボードは作成しないでください。

引き続きワークスペースを調査してください。オーナーへの質問は引き続き最大3つです。パックが割り当てられている場合、通常はスコープ、権限、起動モードについて質問します。引き続き、このスキルの templates/ から生成してください。テンプレートセットを2つ目として作成したり、3つ目のランタイムノードを作成したりしないでください。プリセットスキルは、生成されたノードを実行しません。

実行方法

ステップ1 — 調査してからヒアリングします。 質問する前に、ワークスペースと現在のシステム／ツールのコンテキストを調べてください。現在のオーサリングホスト、プロジェクトルート、リポジトリ、ブランチ、変更状態、リポジトリの指示、想定されるゲート、明示された目標や制約を推測してください。システムコンテキストからすでに特定できる場合、クライアントやホストが何かをユーザーに尋ねてはいけません。このセッションで何かを変更する前に、変更状態のベースラインを記録してください。移動、アーカイブ、生成、削除するものはすべて、開始時のスナップショットに自分が作成したパスを列挙しない限り、オーナーの未コミット作業と区別できなくなります。オーサリング時の調査は副作用のないものにしてください。スクラッチ出力は新しい実行のエビデンスディレクトリに直接出力し、可能な場合はツールのキャッシュを抑制し、既知の成果物をこのセッションで作成した場合は引き継ぎ前に削除してください。オーサリング実行によって、プロダクトのパスにオーナーの作業を装うキャッシュを残してはいけません。

未解決のオーナー判断事項だけを含む、簡潔な質問を最大3つまとめて提示してください。回答案を提案し、オーナーに設計を任せないでください。残っている事項が3つを超える場合は、目標と証明、安全性に関する権限、起動モードの順に優先し、その他は推測するか保留してください。実行が安全でなくなるか、検証できなくなる場合に限り、追加質問をしてください。

1. 北極星と証明。依頼から確認可能な成果がすでに明らかな場合を除きます。簡潔な推奨文を1つ提示します。
2. 権限。すでに明記されていない場合に限ります。推奨する既定値は、ローカルでの編集と検証は許可し、プッシュ、破壊的な git 操作、本番環境やリモート環境の変更、シークレットや実データの露出、上限のない支出、受け入れ基準の引き下げは禁止です。実行にコミットが必要な場合に限り、コミットを許可するか確認します。従量課金制の作業や高額な作業を実行する場合は、実際の数値を ops.md に記載します。「予算超過」はオーナーのみが判断する条件であり、予算が宣言されていなければ強制できません。各ゲートにかかるコストが、金額、所要時間、リスクのどれなのかを明示します。時間だけがコストのゲートは、制限するのではなくまとめて実行します。作業領域全体に手が届かなくなる上限は、予算の形をしたスコープ判断であり、スコープの回答に含めるものです。
3. マイルストーン。大きく異なる分割方法が2つある場合に限ります。推奨するフェーズ分割と終了判定をAとして提示し、成果やリスクが変わる場合に限りBも提示します。目標が1つなら、マイルストーンについて質問しません。メインの作業を進めるうえで障害を取り除く最小の範囲を最初に置くよう、順序を決めます。大規模なイネーブリングリファクタリングを納品マイルストーンより前に置くと、リスクが集中し、その後にあるすべての検証が遅れます。そのようなマイルストーンは、障害を取り除く範囲と、メインの作業と並行して進める残りの範囲に分け、メインの作業の前には置きません。
4. 起動モード。ユーザーがすでに選択している場合を除きます。A（推奨）— 検出された Codex または Claude Code のホスト上で、両方の実行ノードを作成します。B — コピーしてすぐ使えるプロンプトのみを出力します。対象ホストを尋ねるのは、Bの場合、またはユーザーが明示的に複数ホストでの実行を求めた場合に限ります。

調査で確認できる場合は、リポジトリのパス、ブランチ、ホスト、テストコマンド、禁止事項、実行頻度を尋ねません。調査後もゲートが不足している、または曖昧な場合は、妥当な範囲で最小限のコマンドを提案し、A/Bの選択肢を1つだけ尋ねます。長期間にわたるループグラフ実行では、既定でスーパーバイザーを含めます。その価値に本当に疑問がある場合に限り、スーパーバイザーを省略するか確認します。

監督対象の各マイルストーン境界について、昇格監査の対象範囲と終了判定を正確に明示します。実行が頻繁にブロックされることを前提にしてください。オーナーの判断、入力不足、依存関係の未解決、監査中のマイルストーンに備え、実行者が作業を早々に終わらせることなく、常に着手可能な項目を選べるよう、負債・ギャップ登録簿に、実在する独立した作業を十分に登録しておきます。

作業対象を見つける必要がある場合は、リストではなく手法を仕込んでください。 対象項目を発見しながら進める実行（デッドコード、重複、テストカバレッジの欠落、古い設定など）では、何度も巡回するツリーを1つのコンテキストウィンドウで見渡すことになります。そのため、手書きの候補リストが実行の上限になり、実行者はそのリストを処理して完了を報告してしまいます。検出器、補充ノルマ（N件を解決したら、少なくともN件を発見）、対象全体を巡回する方法を ops.md と台帳にまとめ、実測したベースラインとともに、手法を登録簿に仕込んでおきます。終了判定は、キューが空であることではなく、検出器による新たな走査でしきい値を下回る件数しか見つからない状態が、全体走査で2回連続することとします。各実行の成果量の下限も設け、ラウンド数ではなく生産性によって実行の終了を判断します。オーナーのみが判断する項目のリスト（一般的な項目：DDL／スキーマ、認証情報／リモート環境／実データの露出、予算超過、指標基準の引き下げ、凍結された契約、プッシュ）を明確にします。それ以外はすべて、スーパーバイザー自身が判断します。

• 重要なクリティカルパス上の判断は、今すぐ事前に確定します。 プロジェクトを調査し、必要な証拠の基準を自分で下書きしてください。オーナーに基準の策定を求めてはいけません。次を提示します。A（推奨） 下書きした継続的な承認を受け入れる、B アクションをオーナーの判断待ちにする、そして実際に該当する場合に限り、C 明確に異なる安全な代替案を提示する。それぞれの結果を平易な言葉で説明し、1文字の返信を受け付けます。承認された基準は、STANDING 指示として記述します。ケースごとに人間の判断が本当に必要な場合に限り、その判断をブロッキング状態にします。
• オーナーの判断 UX はランタイムの契約です。 以降、オーナーへのエスカレーションにはすべて、以下の判断カード形式を使用する必要があります。オーナーが内部記号を理解したり、経緯を再構成したり、解決策を提案したりする必要があってはいけません。

Decision needed: <one plain-language sentence>
Why now: <what is blocked and what happens if we wait>
Recommendation: A — <choice> (<one-sentence reason>)
A (Recommended) — <outcome and main tradeoff>
B — <outcome and main tradeoff>
C — <only when genuinely distinct; otherwise omit>
Reply with: A / B / C

相互排他的な選択肢は最大3つにします。証拠が別の選択肢を明確に支持していない限り、最も安全で元に戻せる選択肢を最初に提示します。技術的な証拠は、その結果が何を意味するかに置き換えます。パス、コマンド、専門用語は、選択肢の後に任意の Technical note として記載します。最後に「どう思いますか？」と尋ねたり、オーナーに選択肢Dを考えさせたりしてはいけません。回答がなければ、変更を加えない安全な状態で実行を保留します。

ホストと実行間隔。 システムコンテキストと呼び出し可能なツールから、現在の作成ホストを推定します。直接起動するプランナーとしてサポートされているのは Codex と Claude Code です。A が選択された場合は、検出したホストに両方のランタイムノードを配置し、そのホストのリファレンスだけを読み込みます。他のホストの構文を尋ねたり表示したりしてはいけません。B または明示的なクロスホスト要求が選択された場合は、選択されたノードごとに1つのリファレンスを読み込みます。

• Claude Code
• Codex
• Grok Build
• Cursor
• shell / cron

無関係なホストのリファレンスは読み込まないでください。選択されたリファレンスに、機能の確認、ノードの作成、各ノードが自身のタイマーを開始および停止する方法が定められています。他のホストでは準備済みのプロンプトを実行できますが、直接作成がサポートされているのは Codex と Claude Code だけです。

実行間隔を2つ設定します。タイマーはノードが再び起動することを保証しますが、作業のペースは決めません。EXEC_INTERVAL は、1回の実行が終了した後にエグゼキューターが戻るまでの時間です。実行自体ではなく実行間隔によって作業量が決まるわけではないため、短く設定します。SUP_INTERVAL はその3～4倍にし、長時間の実行中にスーパーバイザーが何度か監査できるよう、位相をずらします。

実行回数に合わせてマイルストーンを縮めるのではなく、実行に合わせてマイルストーンの規模を決めます。 1ラウンドは引き続き、独立して検証できる1つの作業項目です。その項目は、同じ動作上の主張、書き込み範囲、ゲートを共有する、関連する一連の作業をまとめた最大の単位でもかまいません。実行の境目では毎回、コンテキストを一から導出し直す必要があります。そのため、1回の実行でマイルストーン全体を進め、区切り、つまりマイルストーンの完了点か収束ラウンドの完了点で終えるようにします。したがって、コンテキストコストを実質的に左右するのはマイルストーンの粒度です。エグゼキューターが1回のウォーム実行で完了できそうにないマイルストーンは分割する必要があります。また、FIRE_ROUND_CAP が終了させるのはその実行だけであり、ラン全体ではありません。

コンテキストは説明文にするのではなく、コンパイルします。 ホスト向けプロンプトは、ランタイム Markdown を指す1行のポインターにします。作成時に、正確なファイル名、シンボルや見出し、証拠のパス、限定的なゲートを記載した ops.md のコンテキスト索引を作成します。すべての Current スライスと修正では、それらの ID を参照します。ランタイムノードは、ホットな状態と参照された行だけを読み込みます。ワークスペースをスキャンしたり、権威ある文書全体を開き直したり、ソースの文章を言い換えて記載したりしてはいけません。スーパーバイザーは、永続化されたウォーターマーク以降の差分を監査し、昇格時やチェックポイント時、または限定的なゲートでは不十分な場合に限り、完全なゲートを実行します。

コンテキストから妥当な範囲で判断し、前提を明示します。本当にユーザーの判断が必要な事項（データポリシー、DB アクセス、基準を下げることなど）は、レッドライン、継続的な承認（下書きした推奨案を選択肢として提示）、または owner-blocked 項目にします。事前に判断できない場合に限り、owner-blocked にしてください。オーナーに整理されていない問題をそのまま渡してはいけません。

ステップ2 — 生成： templates/ から新しい .longgraph/<YYYY-MM-DD-slug>/ を生成します。

• 常に用意するもの：executor.md、ledger.md、directives.md、ops.md、archive/。 supervisor.md は選択された場合にのみ追加します。
• すべてのプレースホルダーを置き換え、ガイダンスコメントを削除します。パスは実行ディレクトリ内に収めます。
• ホスト起動プロンプトは、参照先とホストのプリミティブだけにします。動作は executor.md／supervisor.md に記述し、引き継ぎプロンプトに重複して書かないでください。すべての起動プロンプトで重要なのは、次の2点です。読み取り、従うこと。作成を指示する動詞は使わないこと（「セットアップする」「作成する」「執筆する」「計画する」といった表現は、何かを作る許可と解釈され、新しいノードが新たな実行を作成してしまいます）。そして 「どのスキルも読み込まない」こと。名前やパスでスキルを照合するホストは、ノードが自身のファイルを開く前に作成スキルを注入する可能性があるためです。
• /loop が使えるすべてのホストで、オーナー向けに貼り付けるのは /loop の1行です。 形式： /loop {{INTERVAL}} Execute the existing runtime node at {{PATH}}. Do not load any skill. 実行頻度、タイマー ID の記録、自動停止、鮮度の確認は TIMER_STEP またはノードファイルに記述し、オーナーに追加手順（「この ID を ops.md に書く」「その後、スケジュールタスクを作成する」など）を求めないでください。Codex には /loop がありません。オーナー向けの貼り付けは、読み取り、従うことを指示する簡潔な1行にします。オーナーが明示的に求めた場合にのみ、スケジュールタスクや自動化の作成について触れてください。Codex でタイマーを設定するのは、コンパイル済みの TIMER_STEP です。
• 最初の台帳スライスを書く前に、ops.md の Context インデックスをコンパイルします。各行には、いつ読むか、正確なソース参照先、正確な検証方法を記載します。台帳の Current slice とすべての指令には、該当する行を引用させます。
• パラメーターを調整します。調整しない場合は、FIRE_ROUND_CAP=8、CONVERGE_EVERY=5、NET_LINE_CAP=400、KEEP_ROUNDS=5、OPEN_DIRECTIVE_CAP=8、STANDING_CAP=12、GAP_CAP=12、FILE_LINE_CAP=200 を使用します。終了条件のない実行では、FIRE_OUTPUT_FLOOR（終了前に各 fire が完了させる項目数または純増行数）と YIELD_FLOOR（実行を終了状態にできるスイープあたりの発見数の下限）も追加します。
• 永続的な各セクションには上限を設け、実際に発動するルールでローテーションさせます。 上限に対する件数でローテーションします。KEEP_ROUNDS を超えたラウンドと、折りたたみ済みのウォーターマーク以下にある修正は archive/ に移します。STANDING とギャップレジスターには上限を設けて、その場で書き換えます。ライブファイルはどれも FILE_LINE_CAP 行を超えないようにします。固定シャードサイズや遅延するマイルストーンなど、到達するとは限らない境界を基準にしたルールは、ルールがないのと同じです。ノードが読み取りを途中で打ち切り、最新の項目を見落とすまで、ファイルは増え続けます。毎ラウンド再読するファイルが増える一方であることは、スタイルの問題ではなく欠陥です。
• 選択したリファレンスをもとに TIMER_STEP を記述します。ノードに設定、記録、停止すべきものが何もない場合に限り、削除します。ノードが自分のタイマー ID を書き込む、または自分のタスクを削除する必要があるなら、起動行に /loop の実行間隔があることを理由に TIMER_STEP を削除してはいけません。タスク、セッション、自動化の ID を ops.md に入力するようオーナーに求めないでください。ホスト固有の情報は汎用テンプレートではなく、リファレンスに記述します。
• executor が読み取り専用のサブタスクを起動する可能性がある場合は、ホストで利用できる低コストのモデル階層を ops.md の FANOUT_TIER として指定します。ホストに低コストの並列実行階層がない場合は、このセクションを削除します。読み取り専用の調査担当には低コストの階層を使い、executor 自体には使いません。
• templates/handoff.md はチャットの応答としてのみ出力します。これは表示用テンプレートであり、実行時アーティファクトではありません。実行ディレクトリに handoff.md を保存しないでください。supervisor が選択されていない場合は、そのセクションと To steer 行を削除します。
• ホットファイルは簡潔に保ちます。現在の状態、未解決の行、最近のラウンド、未消費の指令のみを残します。

ステップ 3 — オーナーにワークフローを調べさせずに引き渡します。 ユーザーがすでに選択していない場合にのみ、次の選択肢を提示します。

• A（推奨）— ここで両方のノードを作成。検出されたホストが Codex または Claude Code の場合に選択します。
• B — プロンプトのみ。オーナーが別の場所で起動する場合に選択します。

「ファイルを生成しました」で終わらせないでください。次に行う具体的なアクションと、すぐにコピーできるプロンプトを提示して終えます。

• ここで両方のノードを作成してください： ユーザーの A の選択を、対象範囲内の 2 つのランタイムセッションを作成する許可として扱います。選択されたリファレンスに記載された順序どおりに、機能を確認して作成プロトコルに従ってください。現在のプロジェクト／チェックアウトを使い、ホストをまたぐプロンプトを作成したり、ワークツリーへ黙って切り替えたりしないでください。両方のノードが起動したことを確認し、それぞれの ID、両方の実行間隔、停止方法を報告してください。確認をもう一度求めないでください。
• プロンプトのみ： 完成した templates/handoff.md を保存せずにチャットに表示してください。開くセッション／タスク／プロセスの数、各プロンプトの貼り付け先、自動的に続行される内容、停止方法、進め方の指示方法を明記してください。ホスト ID を書き込むようオーナーに求めたり、コンパイル済みノードがすでに所有するタイマーを作成させたりしないでください。
• {{PLACEHOLDER}} のテキストを残したり、オーナーに単に「ループを開始」するよう伝えたりしないでください。実行者と監督者のコンテキストは分離してください。利用可能な場合は、安価で高速な実行者と強力な監督者を使用してください。

これを機能させるルール（テンプレートに組み込み済み）

• ledger.md は、単一で範囲が限定されたスコアボードです。実行者が書き込み、監督者は書き込みません。
• 1 ラウンドにつき、独立して検証可能な作業項目を 1 つ扱います。実装し、検証し、記録します。 関連する作業セットは、1 つの動作上の主張、書き込み対象、ゲートを共有します。無関係な作業は 分けて扱います。脇道の課題は後で対応するよう登録します。
• 各ノードはタイマーを 1 つ所有し、自分だけを起動します。ブロックされた作業は、その実行を終了せずに、登録済みのレーンへ移します。
• 監督者が監査する永続状態に基づいて収束を促します。コストの高いバッチ処理はパイロットで試し、新たな表面領域を追加する前に、実際の利用者を確保します。
• 宣言された実際の対象セットで、再現可能な証拠のみを数えます。
• 確認可能なオーナー判断は事前承認し、真に例外的な判断は、推奨案を示した A／B／C の選択肢として提示します。
• 監督者のコンテキストを分離します。監督者は再検証し、指示を通じてのみ進め方を示し、終了状態になったら自身のタイマーを停止します。

このスキルのファイル

• templates/ — ホストに依存しないランタイム成果物と、チャット専用の起動プロンプトテンプレートです。
• references/ — ホストごとに個別に読み込む、小さなファイルです。
• methodology.md — 詳細な解説です（各ルールが必要な理由と、防止する失敗モード）。
• examples/add-tests-to-cli/ — 汎用的で、手順をすべて示した例です。
• examples/migrate-blob-storage/ — より詳細な実例です。マイルストーン、コホートパイロット、実際に機能する監督者の指示、および監督者が監査してリリースするまでブロックする、スキップできないマイルストーンゲートを取り上げています。