launch

Launch

Launch は造船所の出荷工程です。ミッション概要から、出荷・検証済みの変更に至るまでを担います。検証可能性の境界に立ちます。つまり、エージェントは、繰り返し実行でき、証拠によって妥当性を確認できるすべての作業を継続的に実行し、人間はシステムでは判断できないこと、または失敗した場合のコストが大きいことを判断します。 目標は自動化を最大化することではなく、検証可能な作業を最大限委任し、人間の時間を人間にしかできない判断だけに使うことです。

各ステップに検証可能性のテストを適用します。これを間違えた場合、システムは検出できますか？ 自動的にやり直すか、ロールバックできますか？ 両方とも「はい」ならエージェントに委任します。唯一の答えがない、システムが判断できない、または間違えた場合のコストが大きいなら人間が判断します。

Launch は造船所が存在することを前提とし、存在しない場合は実行を拒否します。造船所のゲートは、ドキュメントの言語を解決する前、提供された仕様を読み取る前に、すべての呼び出しで最初に実行されます。

• ドライドックの --check 監査を完全に実行します — サーフェスの欠落、CONTEXT.md のフロントマターにおける documentLanguage の欠落または無効、存在しないパス、コード内で使われていない用語集の用語、一度も参照されていない標準を確認します。これが唯一の基準です。Launch は独自の施設一覧を別途作成しません。
• 対応が必要な確度の高い指摘があれば、実行をハードブロックします。 該当する指摘をすべて原文のまま列挙し、/oh-my-claudecode:drydock を示し、実行は開始されておらず、成果物も生成されていないと明記して停止します。明示的なオーバーライドがない限り、いずれの指摘もブロック対象として扱います。
• 限定的なオーバーライド（明示的な意図がある場合のみ）： 確度の低い指摘、ドライドックのレポートで誤検知と明示的に分類された指摘、またはユーザーが明示的に宣言した一時的な使い捨てリポジトリに限り、呼び出しごとにユーザーが意図を明示した場合のみオーバーライドできます。オーバーライドでは、対象の指摘または使い捨ての対象範囲を明示する必要があり、確度の高い対応可能な指摘を暗黙に無視してはなりません。汎用のバイパスフラグはありません。
• 現在の監査契約： --check の機械的なサブセットは実行可能です。node scripts/shipyard-audit.mjs [repoRoot] は、確度の高いクラス（サーフェスの欠落、documentLanguage タグの欠落または無効、CLAUDE.md 内の存在しないパス、プロジェクトスキルのトリガーの有無、文書化された語彙に含まれる意図ステータス）をチェックし、共有の重要度／確度／対応要否の語彙に沿った JSON 形式の指摘を出力します。終了コード 0 = 問題なし、1 = 確度の高い対応可能な指摘ありです。ゲートはこの終了コードを使用します。0 なら実行を許可し、1 なら指摘を原文のまま列挙してブロックします。ヒューリスティックなクラス（コード内で使われていない用語集の用語、一度も参照されていない標準）はドライドックの文章による監査に残ります。これらは仕組み上、確度が低く、オーバーライドのルールに変更はありません。
• 監査に問題がない（または確度の低い指摘、誤検知、一時的な対象範囲が明示的にオーバーライドされている）場合、実行を許可します。 その時点で、すべての記録用スロット（CONTEXT.md、docs/adr/、docs/business/）と施設のサーフェスがすでに存在している必要があります。Launch は判断が確定するたびに記録を埋めますが、スロットを作成することはありません。
• ルールのエントリーポイントは CLAUDE.md です。造船所のマップに代替物は認められません。

境界

人間によるチェックポイント（重要な 20%）	エージェントによる継続的な実行（機械的な 80%）
C1 ミッション概要を作成する（目的＋範囲）	事実調査とリポジトリの調査、自己主導で実施
C2 受け入れ基準＋テストシームの一覧を承認する	インタビューの準備：先行する質問を推奨回答とともにまとめて提示
C3 チケットへの分解を承認する（粒度、ブロック関係）	仕様とチケットの作成、機械的な検証（独立性、実証可能性、1 つのコンテキストに収まること）
C4 実行中に生じた取り消せない判断に回答する（まとめて非同期で）	合意済みのシームに沿った TDD 実装、ビルド、テスト、リグレッション
C5 完了レポートを受け入れる。Open Assumptions と行ごとの堆積物リストで異議を唱える	コードレビュー、変更全体の検証、チームの先行作業のスケジューリング、記録一式の作成

チェックポイントの合間にパイプラインが停止することはありません。エージェントは、人間からの回答待ちに依存しない先行チケットすべてで作業を続けます。

ライフサイクルの方針

Launch は OMC の既存のライフサイクルに対するステートレスな構成であり、独自のランタイム状態機械は持ちません。

• Team はタスクのステータス、遷移、キャンセル、ランタイムのクリーンアップを管理します。Launch は Team の契約の範囲外でこれらを変更しません。
• 正規の plan → execute → review → verify の各サーフェスは、それぞれ既存のライフサイクル動作を担います。Launch が作成するアーティファクトは .omc/specs/<feature-slug>/、CONTEXT.md、docs/adr/、docs/business/ に限られます。また、Phase 5 の表で指定されたセディメントスロットに書き込むのは、C5 の承認後に限られます。
• Launch に自動再開機能はありません。中断後はアーティファクトと現在の Team のステータスを読み直します。ただし、担当する Team のライフサイクルがサポート対象の終了／クリーンアップ境界に達した後、新たに明示的な Launch の呼び出しが行われた場合にのみ続行します。人による承認を推測したり、in_progress のタスクを再実行したりしてはいけません。
• 不明瞭な取り組みはナビゲーターの管轄です。フォグゲートによって /oh-my-claudecode:ask-navigator に誘導された場合、その実行は開始されていません。アーティファクトも部分的な状態もありません。セッション間で引き継がれるのはナビゲーターのマップのみであり、Launch はナビゲーターが返すミッションブリーフからのみ再開します。
• Launch は、独自の承認レシート、リビジョンカウンター、リプレイログ、キャンセル経路、ロールバック機構、クリーンアップライフサイクルを追加しません。

このスキルにおける永続性の主張はすべて、ディスク上のファイルに関するものであり、隠れたランタイムに関するものではありません。

Phase 0 — エントリー

実行は、ヤードのゲートを問題なく通過した場合に限り、このフェーズに到達します。提示された仕様を読んだり、Phase 1 に入ったりする前に、drydock document-language contract に従ってドキュメントの言語を決定します。言語の決定順序（明示的な人間の選択が最優先。それ以外は CONTEXT.md のフロントマターにある documentLanguage タグ。それ以外は CLAUDE.md、次に README.md からの、信頼度の高い推定が一致した場合）、中国語の文字体系の判定ルール（zh-Hans ／ zh-Hant）、および一度だけ質問する条件（証拠がない、混在している、矛盾している、信頼度が低い、明示値が無効、または文字体系が曖昧な場合は、まとめて一度質問し、決して推測しない）については、/oh-my-claudecode:drydock の shipyard-document-language-contract ブロックのみを唯一の基準とします。Launch 固有の要件：解決した正規化済みタグは、Launch が作成する成果物より前に CONTEXT.md に保存します。そうすることで、新たに明示的に呼び出された場合でも、会話の隠れた状態に頼らずタグを読み取れます。人間がこれらの成果物を読み、管理します。エージェントは言語に依存しません。

散文、人間向けのラベル、ローカライズ可能なスカラー値のみをローカライズします。パス、スラッシュコマンド、フラグ、コードフェンス、プレースホルダー、フロントマターのキーと機械的な意味を持つ値、YAML／JSON のキー、ライフサイクルトークン（plan、execute、review、verify）、ステータス列挙値（pending、in_progress、completed、failed、ready-for-agent）、ID、チケットの blockedBy、公開 Team の blocked_by、およびすべてのパーサー／制御トークンは、バイト単位で変更しません。言語別の参照表記は相互排他的です。選択した表記を1つだけ出力し、見出しやラベルを二言語で重複させてはいけません。

• ほかの作業に入る前に、簡単なセルフチェックをします。ブリーフには目的、スコープの境界、対象外事項が示されていますか？2つ以上欠けている場合は、その旨を伝えて、ブリーフを1回明確化するよう求めます。曖昧なブリーフでパイプラインを実行すると、曖昧さが確信ありげな出力に変わってしまいます。
• Fog gate：明確化の後、ナビゲーターのフォグテストを適用します。Q1：目的地を1文で述べられますか（この取り組みがたどり着くべき仕様、決定、変更）？ Q2：まだ回答できないとしても、最初の3つの決定事項を今、具体的に述べられますか？ どちらかの答えが「いいえ」なら、実行は開始しません。そのことを明確に伝え、成果物は作成されていないと明記し、/oh-my-claudecode:ask-navigator を推奨して停止します（造船所のナビゲーターは、霧の中での進路を決定チケットの地図として作成し、ミッションブリーフを返します）。残っている質問と、すでに決まった用語があれば引き継ぎます。これにより、ナビゲーターの W1 で同じ質問を繰り返さずに済みます。
• Map check：提示された仕様を読んだり、Phase 1 に入ったりする前に、未完了の navigator:map（トラッカーのラベル、または .omc/wayfinder/ 配下）がないか確認します。未完了のものがあり、この呼び出しで新しいブリーフが提示されていない場合は、その地図上の次の決定を進めるために /oh-my-claudecode:ask-navigator を推奨して停止します。未完了のものがあり、新しいブリーフが提示されている場合は、続行前に質問を1つします。未完了の地図を続けるか、新しい取り組みを始めるかを確認します。
• 仕様のパスが提示された場合 → 仕様を読み、Phase 2 に進みます。
• ミッションブリーフ → Phase 1。受理済みの意図（docs/intents/<slug>/intent.md、status: accepted、最新ラウンド。詳しくは /oh-my-claudecode:intent を参照）は有効なミッションブリーフです。5つのセクションに目的、スコープ、未解決の質問が含まれています。
• 単一箇所の修正 → execute に引き継ぎ、終了します。

Phase 1 — 収束（人間が決定し、エージェントが準備）

デザインツリープロトコルを使ってインタビューを進めます。決定事項とその依存関係をマッピングし、フロンティアラウンドで進めます。現在質問可能な質問をすべてまとめて1ラウンドにし、番号を付け、それぞれに推奨回答を示します。人間が回答すると、ツリーが再構成されます。その後、フロンティアを再計算します。事実は常にサブエージェントがリポジトリの証拠から調べます。人間には、どれだけ調査しても決着がつかないことだけを尋ねます。 理解のリセット。 決定事項を署名のために提示する前に、造船所独自の語彙、つまり CONTEXT.md で定義されている用語を使い、借用した専門用語は使わずに、平易な技術文で短い段落にまとめて言い直してください。船長が理解できない言い直しは、推測で先に進めるのではなく、決定事項を未解決の状態に戻します。言われたことではなく理解したことに署名することが、誤解を土台にしてしまうのを防ぐ方法です。同じ規律は、会話の途中でメッセージが伝わらなかった場合にも役立ちます。送った内容について船長の返信に誤解が見られたら、会話を続ける前に、誤解を一つずつ解消できるよう、CONTEXT.md の語彙を使って、より短く平易な表現で再送してください。誤解を重ねると、異なる二つの会話が同じスレッドを共有することになります。

各項目が確定した時点で記録する文書：

• ドメイン用語 → リポジトリのルートにある CONTEXT.md（用語ごとに1項目）
• ADR の基準を満たす決定事項（覆すのが難しく、文脈なしでは意外で、実質的なトレードオフがあるもの） → docs/adr/NNNN-<slug>.md
• 収束の過程で明らかになったビジネスルールと背景 → docs/business/（ビジネス上の疑問ごとに1記事を作成し、冒頭の段落で重要な理由を述べる）

提案を提示する前に、過去に同じ概念が却下されていないか、記録文書（ADR、docs/business/）を確認してください。概念が類似する提案を再度出す場合、何が変わったかを明示する必要があります。明示しなければ却下します。却下された案に新しい名前を付けても、新しい案にはなりません。

用語集の点検は面談中に行い、後回しにはしません。CONTEXT.md の用語と衝突する用語はその場で問い直し、曖昧な用語は、明確で固有の名前が一つに定まるまで掘り下げます。ビジネス上の関係は具体的なシナリオで検証し、システムの挙動に関する主張はコードと照合します。矛盾があれば、見過ごさずに議題に挙げます。面談で必要なのに用語集にない用語も、それ自体が発見事項です。この船で新たに作られた言葉なら撤回し、用語集に本当の抜けがあるなら、今すぐ項目を追加します。

ここで収束しないのは失敗ではなく、通常の作業です。未解決の事項が残るなら、順位を付けて提示してください。これが C2 の入力であり、エラーではありません。未解決の事項自体を正確に述べられない場合（霧テストの Q2 に不合格の場合）、目的地そのものが未確定であり、これは C2 の権限を超えています。停止し、確定済みの内容（CONTEXT.md の語彙、回答済みの質問）を記録し、/oh-my-claudecode:ask-navigator を推奨して終了してください。パイプラインが目的地を作り出すことは決してありません。

ロフトへの迂回。 正確に述べられるものの、文章では決着がつかず、説明するより実際に見たりクリックしたりする必要がある未解決の事項（UI の見た目や、状態モデルがしっくりくるかどうかなど）には、質問を重ねるのではなく成果物で回答します。「loft」と指定して Skill ツールを呼び出し、船長の反応を得て、その反応を面談に反映してください。ロフトで作成した成果物が C2 の入力です。船長は、説明された内容ではなく、自分で見たものに署名します。

ハーバーからのブリーフ。 /oh-my-claudecode:harbor から引き継いだミッションブリーフには、署名済みの決定事項と、そのリンクおよび適用条件が含まれています。これらは決定済みとして扱い、変更のないビジネス目標を再度質問しないでください。証拠の収集後にコードが変更されている場合（新しい head、変更された base）は、影響を受ける技術的証拠を再検証してください。署名済みブリーフの範囲を超える新たな実装内容には、引き続き個別の承認が必要です。 合意済みの決定によるエグジット。 この起動が、決定ツリーがすでに詰められている会話から来た場合（すべての未解決の論点に回答済みで、語彙と決定がすでに確定している。ライブのインタビュー、決定用アンケート、またはハンドオフ成果物によって確定）、フェーズ1は合意監査に縮約されます。セッションで確定した内容を読み取り、確定した各決定を、それが挙げる根拠に照らして検証し、上記の理解リセットとして全体を一度だけ復唱し、スペックを直接起草します。確定済みの質問を再度行うことはありません。ただし、フォグゲートとC2は引き続き実行を制御します。インタビューを省略しても、署名を省略することはありません。合意の品質は仮定するのではなく必ず検証します。復唱で不合格となった確定済みの決定は再度開かれ、インタビューはそこから再開されます。

フェーズ2 — スペック統合（エージェントが起草 → C2が承認）

.omc/specs/<feature-slug>/spec.md を統合します。ミッションが承認済みのインテントである場合は、インテントスキルの4ステップの契約に従います。承認済みインテント（最新ラウンド）を読み、既存のコードベースと組み合わせ、ルールの柱（CLAUDE.md + docs/standards/ + docs/business/）に従い、すべての疑義とルールの衝突を一覧化して、スペックの「確認待ち」セクションに段階分けして記載します。インテントの未解決の質問は、確認待ちの状態を保ったままスペックにそのまま引き継ぎます。

# <Feature> Spec
## Problem
## Solution
## User Stories        (numbered, each with testable acceptance criteria)
## Implementation Decisions
## Testing Decisions   (external behavior only)
## Out of Scope

すべてを起草したうえで、C2 で停止します。人間の承認のために、受け入れ基準とテストシームの一覧を提示します。ミッションが承認済みのインテントである場合、C2の提示にはインテント向けのチェックリストも含めます。スペックは依然としてインテントの元の課題を解決しているか、引き継がれた未解決の質問がすべて考慮されているか、高リスク項目について承認前にテックリードへの相談が必要か、を確認します。シームはリポジトリの根拠と、ディープモジュールの原則（公開インターフェース、既存のテストシーム、深さの分析。語彙は docs/standards/architecture.md に初期値として用意されています）によって選定されます。人間がリストを確認または修正します。人間が承認していないシームにはテストを書きません。各シームの項目には境界クラスを宣言します。インプロセス、ローカルで代替可能、所有されたリモート（本番用とテスト用の2つのアダプターを持つポート）、または真の外部（注入された代替物）のいずれかです。テストの方法は、このクラスによって決まります。

入札ルール。 インターフェースの形そのものが争点になっている場合（妥当な設計が2つあり、どちらも話し合いでは決められない場合）、C2は、テーブルに載っている唯一の案に署名するのではなく、代替案同士の間で署名します。候補となる形を並列のサブエージェントで起草し、それぞれ異なる重点を置きます（最小のインターフェース表面・最も広い将来への適合性・最も一般的な呼び出し元にとって最も滑らかな既定経路・最もクリーンな境界横断アダプター）。深さ、局所性、シームの配置の観点で比較しながら並べて提示し、キャプテンがいずれかを選ぶか、ハイブリッドを組み合わせます。

耐久性ゲート（エージェントが強制し、承認は不要）：スペックとチケットには契約を記載し、座標は記載しません。ファイルパスや行番号は含めません。決定を散文よりも的確に表現する断片（ステートマシン、リデューサー、スキーマ）は例外であり、その出所を明記します（通常はループ）。

テストに関する決定によって孤立したテストを処理します。シームが深化または置換される場合、古いインターフェースに固定されていたテストもそれとともに廃止されます。新しいテストは新しいインターフェースに対してのみ記述します。テストに関するルール自体は docs/standards/process.md に初期値として用意されています。

フェーズ 3 — チケットの分解（エージェントが下書き → C3 が承認）

.omc/specs/<feature-slug>/tickets/ の下に、垂直スライスとして分割します。

• NN-slug.md：チケットごとに 1 ファイルを作成し、依存関係の順に並べ、それぞれに blockedBy: [ids] を宣言します
• 各チケットはすべてのレイヤーにまたがり、単独で実演でき、新しいコンテキスト 1 つに収まるようにします
• ブロッキングエッジは、依存関係を左右する宣言です：チケットには、何を待つのか――どの決定、成果物（仕様、ADR、loft の結果）、または他のチケットを待つのか――を記載します。チケット番号だけでは不十分です。この宣言は C3 の判断材料です。ここで粒度を誤ると、すべての依存関係の割り当てが誤り、待機対象が宣言されていないチケットは、フロンティア上で適切にスケジュールできません。
• 大規模なリファクタリングは拡張・縮小の手順で進めます。新しい形式を追加し、段階的に移行してから古い形式を削除します。各段階を 1 つのチケットにします

まず、エージェント側で機械的な検証（独立性、実演可能性、コンテキストへの適合性）を実行します。次に C3 で、粒度、ブロッキングエッジ、マージや分割の提案を提示し、人間の承認を得ます。承認されるまで反復します。すべてのチケットに ready-for-agent を設定します。C3 の基準は、新しい作業者が質問を返さずにどのチケットにも着手できることです。質問が必要なチケットがあれば、その欠陥は作業者ではなく仕様に差し戻します。

統合配線のルール：すべての垂直スライスに、それぞれの配線とスモークアサーションを含めます。出力をマウント、提供、またはインポートするものがないスライスは、完了ではありません。どのスライスも単独では担当しないスライス間の接続部分（ルートのマウント、静的ファイルの提供、エントリーポイントの配線）には、フロンティアの最後の項目として明示的な統合チケットを作成します。

フェーズ 4 — フロンティアを実行する

フロンティアとは、すべてのブロッカーが完了しているチケットの集合です。

スカウトパス。 2 つ以上のチケットで共有する調査は、ディスパッチ前に一度だけ行います。調査サブエージェントが共有の疑問を解決し、.omc/specs/<feature-slug>/notes/ の下にメモを記録します。チケットではメモへのポインターを参照し、作業者はポインターを参照して、メモですでに解決済みの内容を再調査しません。1 つのチケットだけで必要な疑問は、そのチケット内に記載します。

統合トポロジー。 作業者の出力は、作業者の稼働終了後も存続する 1 つの場所に集約します。フェーズ 4 の開始時に統合ブランチを作成し、PR プラットフォーム上では、仕様とすべてのチケットを参照するドラフト PR として開きます。作業者のブランチは、そのチケットの 2 軸レビューゲートを通過した後に限り、チームのマージ調整（checkMergeConflicts → mergeWorkerBranch）を経てマージします。C5 の検証は統合先で実行します。これは Team の契約の範囲内です。ブランチはトポロジーであり、新しい起動ステートマシンではありません。

修正ルール。 2 軸レビューで見つかった問題は、単一の修正作業者が修正し、同じゲートで再審査を受けます。レビュアーは判断を行い、修正はしません。実装者が自ら承認することもありません。

並列（デフォルト、チケット 2 件以上）。 チケットをチームに渡します。各チケットはチームのタスクになり、blockedBy エッジは引き継がれます。チームのタスク取得メカニズムが、フロンティア上のタスクだけを選択します。N 人の作業者を起動します。各作業者は、C2 で承認された接続部分において TDD の規律に従って実装し、記述時の規律として /oh-my-claudecode:minimal-code-discipline を適用します（これは引き続きオプトインです）。チケットを完了とするのは、レビュアーが宣言したコードレビューに差分が合格した後だけです。実装者が自ら承認することはありません。

逐次（チケット 1 件、または --serial）。 エグゼキューターのサブエージェントに、一度に 1 件ずつチケットを委任します。レビューゲートは並列の場合と同じです。

2 軸レビューゲート。 完了時のレビューは、2 つの軸に沿って並行して実施し、それぞれ別個に報告します。変更は一方の軸に合格してもう一方で不合格になることがあるため、決して統合したり、相互に順位付けしたりしません（標準には準拠していても動作が誤っている場合、忠実に実装されていても規約に違反する場合があります）。どちらか一方の軸で不合格となった場合、レビュアーはチケットを不合格とします。

• 標準軸（Standards axis） — 対応する docs/standards/ の各巻との差分、および判断を要する項目のみを対象とした臭い（smell）ベースラインのチェックです。文書化されたリポジトリ標準はベースラインより優先されます。ツールがすでに強制しているものはスキップします。これは標準の各サーフェスへの参照を維持する常設の消費者です。
• 仕様軸（Spec axis） — このチケットの受け入れ基準との差分です（仕様はチケットが分解された元となる全体の台帳であり、基準の出所をたどる目的と、どのチケットalso要求していない混入スコープ（smuggled scope）について判断する目的でのみ参照されます）。対象は、欠落している、または部分的な要件、誰も求めていない挙動、そして実装済みに見えるものの誤っているように見える要件です。各指摘には出典の行を引用します。

C4 — 実行中に生じる判断。 並列の Team ワーカーが ADR のテストに該当する判断に遭遇した場合、その判断に依存する変更の前に停止し、質問（選択肢、推奨案、可逆性の注記）を、失敗した遷移の error フィールドおよび .omc/specs/<feature-slug>/decisions-pending.md に記録したうえで、Team がサポートする in_progress → failed の遷移を経て終了します。これは Launch の終端的な結果です。この呼び出しからタスクを再オープンしたり、実行中の後継タスクを作成したり、強制的にクリーンアップしたり、別の Team を開始したりしてはいけません。失敗したタスクと判断用アーティファクトへのポインタを付けて、ブロッカーを報告します。

後続の明示的な Launch 呼び出しでは、まず所有する Team のライフサイクルが終端状態にあり、その所有者のサポートする方法でクリーンアップ済みであることを要求します。次に、保留中の C4 の質問をすべてまとめて人間に提示し、回答を判断ログ/ADR に記録し、実行を開始する前にチケットのフロンティアを再構築します。すべてのチケットの依存関係はディスパッチの前に宣言されます。Team タスク API でタスクを作成する際、チケットの blockedBy メタデータは、数値のタスク ID を使って公開されている Team の blocked_by フィールドに対応付けられます。Team の既存のタスク ID による依存関係解決が、先行タスクの早すぎる要求（claim）を拒否し、依存先は先行タスクが完了した後にのみ実行可能になります。チームリードは、明示的に Team ワーカーとして登録されていないタスクを要求しません。Launch は要求済みタスクの依存関係を動的に変更することはなく、C4 の後に自動的な再ディスパッチを約束することもありません。

直列 C4（--serial）。 実行者は、判断に依存する変更の前に停止し、完了を主張せずに質問を返します。人間への質問は、バッチの境界で記録して解決し、その後、記録された回答と残りの受け入れ基準を持つ新しい実行者の後継を開始します。中断された実行者のコンテキストを再生したり再開したりしてはならず、Team が有効でない場合に Team タスクを作り出してはいけません。

繰り返される失敗による停止。 3 回の修復試行を経てもなお残る同一の検証失敗は、人間向けの根本原因の仮説を添えて、そのレーンを停止させます。これは、C4 のバッチ処理を即座に中断させる唯一の条件です。

フェーズ 5 — クローズアウト（エージェントが報告 → C5 が承認）

• すべてのチケットが証拠付きで終了状態になったら、変更全体を対象に verify を実行します

• 作業記録を整合させます。CONTEXT.md が正確であること、ADR が完成していること、実装によって新たに判明したことがあれば仕様を更新します

• yard を再チェックします。drydock --check 監査を再実行します。開始時から新たに見つかった項目は yard drift として報告し、/oh-my-claudecode:drydock へのリンクを添えます

• 堆積物の確認 — この船は yard に何を教えたかを答えます。 まず 構造化された振り返りを行います。何を構築したか（出荷したスコープをスライスごとに 1 行で）、何が壊れたか（明らかになったすべての失敗：三振の根本原因、verify の指摘事項）、何が教訓になったか（C4 の回答、レビューでの却下、および今回参照したソースマップの解決事項や先送りされた堆積物の記述）、そして環境によって妨げられたこと（道案内の摩擦、遅すぎる、または遅れて実行されたチェック、推測を強いられた標準の不足、何もしなかったツール、必要以上にアクセスしにくかった情報）を確認してから、回答してください。すべての教訓について、以下のスロット表に照らして lesson → slot → intended change の形式で提案するか、理由を明示して却下してください。教えることが何もない船は、"no new lessons" とそのまま記さなければなりません。この要件は無回答を防ぐものであり、空の回答を防ぐものではありません。回答するために教訓を捏造することも、質問を飛ばすのと同じ違反です。教訓の一覧は Open Assumptions とともに完了レポートに含め、各行を個別に拒否できるようにします。承認された教訓は受け入れ後にのみ各スロットへ記録し、レポートには記録先のファイルパスをそれぞれ記載します。教訓をスロットに書き込む前に、Skill ツールで agent-doc-discipline を呼び出し、そのルールを適用してください。スキルの検証チェックリストに合格して初めて、堆積物の確認は完了です。

  教訓の種類	スロット
  実行中に確定した用語と境界	CONTEXT.md の用語集
  チェック可能な動作ルール（理由も記載）	該当する巻の docs/standards/（アーキテクチャ／データ／プロセス）
  最も頻繁に違反された規約（薄いエントリーの基準）	CLAUDE.md 本文 — 提案のみ
  変更が難しい決定	docs/adr/（C4 の回答はすでにここに記録されます）
  除外した方針（概念と却下理由）	docs/adr/（却下も決定です。重要なのは理由です）
  ビジネスルール／背景情報	docs/business/
  UI パターン／コンポーネントの契約	design-system/
  再利用可能な技術・作法	.omc/skills/（skillify ゲートを通す）
  繰り返し必要となる自動化／連携	scripts/ または .mcp.json
  適合するスロットがない	理由を明示して却下

• 薄いエントリーの上限： CLAUDE.md 本文に記載できる重要なエントリーは最大 5 件です。ソースチェックリストによって同じ違反が今回の実行中に少なくとも 2 回確認された場合、またはキャプテンが重要と判断した場合に限り、教訓は薄いエントリーの基準を満たします。エントリーは最近昇格したものから順に並べます。最も古いエントリーは決定論的に最後に記載されます。上限を超える昇格を提案する場合は、同じ提案内でそのエントリーを正確に 1 件降格し、本文全体を docs/standards/ に戻してください。削除せず、階層を変更するだけです。肥大化は出荷ごとに再調整するものであり、意図的に --check の指摘対象にはしません。

• 完了レポートに実行回数を記載します。完了したチケット数、明らかになった C4 の決定数、三振による停止数、提案した堆積物の行数を、テレメトリーシステムや状態ファイルを使わず、レポート本文に事実として記載します

• 完了レポートを作成します。出荷したスコープ、検証の証拠、作業記録の保存先、yard drift の指摘事項（あれば）、堆積物の一覧（各行を拒否可能）、および人間が拒否したい可能性の高さで順位付けした Open Assumptions を含めます

• プラットフォームが PR でレビューされ、フェーズ 4 でドラフト PR を作成した場合は、レポートの証拠とリンクされた ADR に基づいて /oh-my-claudecode:pr に従い PR の本文を作成し、C5 の承認後にのみ PR をレビュー可能な状態にします

コンテキストの衛生管理

• フェーズ 1〜3 は、途切れのない 1 つのコンテキストウィンドウで実行し、フェーズの境界でのみ圧縮します（HUD の高水位がその合図です）。
• ディスクが一次情報源であり、会話の記憶は二次情報源です。 続行する場合を除き、境界での操作はすべて一次情報源を二次情報源に変換します。そのため、境界を越えた後は、ディスク上の成果物を読み直し、記憶した状態から続行しないでください。
• 境界での 4 つの選択肢： 続行する（コンテキストにまだ余裕があり、汚染されていない）→ ディスクから再開する（フェーズが完了した）→ 引き継ぐ（内容ではなく参照先）→ 圧縮する（限界が近く、フェーズの境界にいる）。最初に条件を満たすものを選びます。
• 長時間のヘッドレス実行では、オーケストレーターが稼働状況を確認できるよう、--output-format stream-json（または定期的な進捗マーカー）を優先します。プレーンテキストモードでは、ターンが終了するまで何も出力されません。
• フェーズ 4 は、設計上、チケットごとに新しいコンテキストで実行します（チームのワーカーまたはサブエージェントを使用）。
• 引き継ぎでは、内容ではなく参照先を渡します。引き継ぎ文書に含めるのは 3 つだけです。参照先（資料と決定事項の場所。複製は不可）、次の作業（次のフェーズで行うことと、呼び出すスキル）、注意事項（すでに除外された禁止事項。認証情報は伏せる）。圧縮が避けられない場合は、次のフェーズに必要な情報が要約に残るよう、指示も添えて渡します。
• 予定されたセッションの引き継ぎ：コンテキスト予算、予定された境界、意図的な中断などの理由で、作業の途中でセッションを終える必要がある場合、実行の他の成果物とともに、内容を圧縮した引き継ぎ成果物を作成します。記録するのは、確定したこと（参照先付きの決定事項）、未解決のこと（未解決の問い）、実行の状態のみです。それ以外は記録しません。生のトランスクリプトやチャット履歴は含めません。次のセッションは、記憶からではなく、この成果物から状況を把握します。これはナビゲーターの地図が従う再把握ルールと同じです。引き継ぎは、以下のクラッシュ復旧の先回り版です。前者は計画された移行を、後者は途中で終了したセッションを扱います。
• セッションが実行の途中で終了した場合は、成果物を保持して停止します。後から明示的に呼び出された場合も、管理元である Team のライフサイクルが、サポート対象の終了／クリーンアップ境界に達した後に限り、続行できます。実行時の状態については、引き続き Team が正とします。

完了の定義

すべてのチケットが証跡付きで終了しており、変更全体の検証が問題なく、文書化された経緯が整合し、レポートが出力されていること。さらに、エージェントが人に代わって行ったすべての決定について、記録された場所を 1 つの参照先で示せること。