Launch

Launch は何をしますか？

Launch は Shipyard のデリバリ実行です。ミッション概要から出荷され検証された変更までを実行します。これは検証可能性の境界上に位置します — エージェントは繰り返し可能であり、証拠によって許容可能であるすべてのものを継続的に実行し、人間はシステムが判断できないもの、または高コストで失敗するものだけを決定します。 目標は最大限の自動化ではなく、検証可能な作業の最大限の委譲であり、人間の時間は人間だけが下せる判断にのみ費やされます。

すべてのステップに適用される検証可能性テスト: これを間違って行った場合、システムはそれを検出できますか？自動的にやり直すかロールバックできますか？ 両方とも「はい」→エージェント。固有の回答がない、システムが判断できない、または間違えるとコストが高い→人間。

Launch は Shipyard が存在することを前提とし、存在しなければ実行を拒否します。ヤードゲートは、ドキュメント言語の解決前、および指定された仕様の読み取り前に、すべての呼び出しの最初のアクションです:

• 完全な drydock --check 監査を実行 — 不足しているサーフェス、欠落または無効な CONTEXT.md フロントマター documentLanguage、デッドパス、コードで使用されていない用語集エントリ、参照されていない標準。これが唯一の基準です: Launch は独自のファシリティインベントリを実行しません。
• アクション可能/高確信度の所見は実行をハードブロック: そのような所見をすべてそのままリストし、/oh-my-claudecode:drydock を指摘し、実行が開始されておらず成果物も生成されていないことを述べ、停止します。明示的なオーバーライドがなければ、すべての所見をブロックとして扱います。
• 狭いオーバーライド (明示的な意図のみ): 低確信度の所見、drydock レポートで偽陽性として明示的に分類された所見、またはユーザーが明示的に宣言したスクラッチ/使い捨てリポジトリは、意図的かつ呼び出しごとのユーザー意図によってのみオーバーライドできます。オーバーライドは所見または使い捨てスコープを指定しなければならず、高確信度のアクション可能な所見を黙って飲み込んではなりません。一般的なバイパスフラグはありません。
• 現在の監査の制限: 現時点では --check はスキル指示チェックリストであり、機械可読な所見/重大度コントラクトや実行可能ファイルはありません。重大度の分類は、構造化コントラクトが存在するまで drydock レポートの文言に依存します。機械可読な所見/重大度終了コントラクトが意図されたフォローアップです。ゲートの文言は、機械的に何に依存でき、何に依存できないかについて正直であり続けます。
• クリーンな監査 (または明示的にオーバーライドされた低確信度/偽陽性/スクラッチスコープ) は実行を許可します。 すべてのペーパートレイルスロット (CONTEXT.md, docs/adr/, docs/business/) とファシリティサーフェスはその時点ですでに存在しています。Launch は決定が固まるにつれてペーパートレイルを埋めますが、スロットを作成することはありません。
• ルールエントリは CLAUDE.md です — Shipyard マップは代替を認識しません。

境界

人間のチェックポイント (重要な 20%)	エージェントの継続的実行 (機械的な 80%)
C1 ミッション概要を作成 (目的 + スコープ)	事実調査とリポジトリ探索、セルフサービス
C2 受け入れ基準 + テストシームリストを承認	面接準備: 推奨回答付きのフロンティア質問をバッチ化
C3 チケット分解を承認 (粒度、ブロッキングエッジ)	仕様とチケットのドラフト作成、機械的検証 (独立性、実証可能性、単一コンテキストへの適合)
C4 実行中に発生する不可逆的な決定に回答 (バッチ、非同期)	合意されたシームでの TDD 実装、ビルド、テスト、リグレッション
C5 完了レポートを受け入れる; オープンアサンプションと行ごとの堆積物リストで拒否権を行使	コードレビュー、変更全体の検証、チームフロンティアスケジューリング、ペーパートレイル全体

チェックポイント間でパイプラインがアイドル状態になることはありません。エージェントは、保留中の人間の回答に依存しないすべてのフロンティアチケットを常に処理し続けます。

ライフサイクルポスチャー

Launch は OMC の既存のライフサイクルに対するステートレスな構成です — 独自のランタイムステートマシンを所有しません:

• チームはタスクステータス、遷移、キャンセル、ランタイムクリーンアップを所有します。Launch は Team のコントラクト外でこれらを変更することはありません。
• 正規の plan → execute → review → verify サーフェスは、既存のライフサイクル動作を所有します。Launch が作成する成果物は .omc/specs/<feature-slug>/、CONTEXT.md、docs/adr/、docs/business/ に限定されます。さらに、C5 承認後にのみ、フェーズ 5 の表に記載された堆積物スロットに限定されます。
• Launch に自動再開機能はありません。中断後は成果物と現在の Team ステータスを再読み込みしますが、所有する Team ライフサイクルがサポートされている終了/クリーンアップ境界に達した後でのみ、新しい明示的な Launch 呼び出しを通じて続行します。人間の承認を推測したり、in_progress タスクを再実行したりしないでください。
• 霧のかかった取り組みはナビゲーターの管轄です: フォグゲートが /oh-my-claudecode:ask-navigator にルーティングする場合、実行は開始されません — 成果物も部分的な状態もありません。ナビゲーターのマップがセッションをまたいで状態を伝達する唯一のキャリアです。Launch はナビゲーターが返すミッション概要からのみ再開します。
• Launch は独自の承認受領書、リビジョンカウンター、再生ログ、キャンセルパス、ロールバックメカニズム、またはクリーンアップライフサイクルを追加しません。

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

フェーズ 0 — エントリ

実行がこのフェーズに到達するのは、クリーンなヤードゲートを通過した場合のみです。指定された仕様を読み取ったりフェーズ 1 に入る前に、ドキュメント言語を解決します。現在の呼び出しにおける明示的な人間の選択が優先されます。そうでない場合は、CONTEXT.md フロントマターの正確な安定キー documentLanguage から有効な BCP-47 スタイルのタグを読み取ります。それもない場合は、CLAUDE.md 次いで README.md から満場一致の高確信度の推論を必要とします。永続化されたベアまたは地域のみの中国語タグはスクリプトがあいまいであり、その権限階層で 1 回質問する必要があり、推論によってバイパスしてはなりません。欠落、混合、競合、低確信度、無効な明示的、またはスクリプトがあいまいな中国語の証拠は、1 回のバッチ化された言語質問を必要とします。推測しないでください。中国語は明示的な zh-Hans または zh-Hant スクリプトタグに解決する必要があります。zh-Hans-* は簡体字コンパニオンを選択し、zh-Hant-* は繁体字コンパニオンを選択し、完全な正規化タグは永続化されます。解決された正規化タグを、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 回のシャープニングパスを依頼してください — ソフトなブリーフでパイプラインを実行すると、あいまいさが自信に満ちた出力に変換されます。
• フォグゲート: シャープニングパスの後、ナビゲーターのフォグテストを適用します — Q1: 宛先を 1 文で述べられますか (この取り組みが進むべき道を見つけている仕様、決定、または変更)? Q2: 最初の 3 つの決定を今すぐ正確に述べられますか (まだどれも答えられなくても)? どちらかの答えが「いいえ」→ 実行は開始されません: その旨を明確に述べ、成果物が生成されなかったことを記し、/oh-my-claudecode:ask-navigator (Shipyard のナビゲーターは霧を決定チケットのマップとしてチャート化し、ミッション概要を返します) を推奨し、停止します。残りの質問とすでに確定した語彙を引き渡し、ナビゲーターの W1 がそれらを再度質問しないようにします。
• マップチェック: 指定された仕様を読み取ったりフェーズ 1 に入る前に、開いている navigator:map (トラッカーラベル、または .omc/wayfinder/ 以下) を探します。それが存在し、この呼び出しが新しいブリーフを提供しない場合 → /oh-my-claudecode:ask-navigator を推奨してそのマップの次の決定に取り組み、停止します。存在し、新しいブリーフが提供される場合 → 1 つの質問をします — 開いているマップを続けるか、新しい取り組みを開始するか — 続行する前に。
• 仕様パスが指定された → それを読み取り、フェーズ 2 にジャンプ。
• ミッションブリーフ → フェーズ 1。
• 単一点修正 → execute にハンドオフして終了。

フェーズ 1 — 収束 (人間が決定、エージェントが準備)

設計ツリープロトコルで面接を実行します: 決定とその依存関係をマッピングし、次にフロンティアラウンドで作業します — 現在質問可能なすべての質問を 1 つのラウンドにバッチ化し、番号を付け、それぞれに推奨回答を付けます。人間が回答します。ツリーは再形成されます。フロンティアを再計算します。事実は常にサブエージェントによってリポジトリの証拠からセルフサービスされます — 人間は、どんな量の探索でも解決できないことだけを尋ねられます。

各項目が確定した時点で作成されるペーパートレイル:

• ドメイン語彙 → リポジトリルートの CONTEXT.md (用語ごとに 1 エントリ)
• ADR テストに合格する決定 (元に戻すのが難しい、コンテキストなしでは驚くべき、実際のトレードオフ) → docs/adr/NNNN-<slug>.md
• 収束中に発見されたビジネスルールと背景 → docs/business/ (ビジネス質問ごとに 1 記事、導入段落でそれが重要である理由を述べる)

ここでの非収束は通常の作業であり、失敗ではありません: フロンティアが空にならない場合は、残りの質問をランク付けして提示します — これは C2 への入力であり、エラーではありません。残りの質問自体を正確に述べることができない場合 (フォグテスト Q2 失敗)、宛先自体が確定しておらず、それは C2 の権限を超えています: 停止し、すでに確定したもの (CONTEXT.md の語彙、回答済みの質問) を記録し、/oh-my-claudecode:ask-navigator を推奨して終了します — パイプラインは宛先を発明しません。

ロフト迂回。 正確ではあるが散文では解決できない残りの質問 — それは説明されるのではなく、見られたりクリックされたりする必要がある (UI の見た目、ステートモデルが適切かどうか) — は、さらなる質問ではなく成果物で回答されます: Skill ツールを "loft" で呼び出し、キャプテンが反応し、その反応を面接に折り返します。ロフトされた成果物は C2 への入力です。キャプテンは説明されたものではなく、見たものに署名します。

ハーバーブリーフ。 /oh-my-claudecode:harbor によって引き渡されたミッションブリーフには、署名された決定とリンクと適用条件が含まれています: それらを既に行われたものとして消費します — 変更されていないビジネス目標を再度質問しないでください。証拠が収集されてからコードが移動した場合 (新しいヘッド、変更されたベース)、影響を受ける技術的証拠を再検証します。署名されたブリーフを超える新しい実装スコープは、依然として独自の承認を必要とします。

フェーズ 2 — 仕様合成 (エージェントがドラフト → C2 が承認)

.omc/specs/<feature-slug>/spec.md を合成:

# <機能> 仕様
## 問題
## 解決策
## ユーザーストーリー        (番号付き、それぞれテスト可能な受け入れ基準あり)
## 実装決定
## テスト決定   (外部動作のみ)
## 対象外

すべてをドラフトし、C2 で停止します: 人間の承認のために受け入れ基準とテストシームリストを提示します。シームはリポジトリの証拠と深いモジュール規律 (パブリックインターフェース、既存のテストシーム、深さ分析) によって選択されます。人間がリストを確認または修正します — 人間が承認していないシームにはテストがありません。

永続性ゲート (エージェントが強制、承認不要): 仕様とチケットはコントラクトを保持し、座標は保持しません — ファイルパスや行番号はありません。決定を散文よりも適切にエンコードするフラグメント (ステートマシン、リデューサー、スキーマ) は例外であり、その起源 (通常はロフト) を述べます。

フェーズ 3 — チケット分解 (エージェントがドラフト → C3 が承認)

.omc/specs/<feature-slug>/tickets/ 以下に垂直スライスに分割:

• NN-slug.md、チケットごとに 1 ファイル、依存関係順、それぞれが blockedBy: [ids] を宣言
• 各チケットはすべてのレイヤーを横断し、独立して実証可能であり、1 つの新しいコンテキストに適合
• 広範なリファクタリングは拡張-縮小方式で行う: 新しい形式を追加、バッチで移行、古いものを削除 — 各バッチが 1 つのチケット

エージェント側の機械的検証が最初に実行されます (独立性、実証可能性、コンテキスト適合)。次に C3: 粒度、ブロッキングエッジ、提案されたマージ/分割を人間の承認のために提示します。承認されるまで繰り返します。すべてのチケットを ready-for-agent としてマークします。

統合配線ルール: すべての垂直スライスは、独自の配線とスモークアサーションを含みます — 出力を何もマウント、提供、またはインポートしないスライスは完了していません。単一のスライスが所有しないクロススライスシーム (ルートマウント、静的提供、エントリポイント配線) は、最後のフロンティア項目として明示的な統合チケットを取得します。

フェーズ 4 — フロンティアの実行

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

並列 (デフォルト、2 以上のチケット)。 チケットをチームにハンドオフ: 各チケットはチームタスクになり、blockedBy エッジは引き継がれます — チームのクレームメカニズムはフロンティアタスクのみを選択します。N 個のワーカーを起動します。各ワーカーは C2 で承認されたシームで TDD 規律を用いて実装し、/oh-my-claudecode:minimal-code-discipline を作成時規律として適用します (オプトインのまま)。チケットは、レビュアーによって宣言された差分のコードレビューに合格した後にのみクローズされます — 実装者が自己承認することはありません。

シリアル (単一チケット、または --serial)。 一度に 1 つのチケットをエグゼキューターサブエージェントに委任します。同じレビューゲート。

2 軸レビューゲート。 クロージングレビューは 2 つの軸に沿って並行して実行され、別々に報告されます — 決してマージされたりクロスランク付けされたりしません。なぜなら、変更は一方の軸に合格し、もう一方の軸に失敗する可能性があるからです (標準に準拠しているが動作が間違っている、忠実だが規約に違反している)。レビュアーは、いずれかの軸が不合格になった場合、チケットを不合格にします:

• 標準軸 — 一致する docs/standards/ ボリュームに対する差分、および判断のみのスメルベースライン (文書化されたリポジトリ標準はベースラインをオーバーライドします。ツールがすでに強制しているものはスキップされます)。これは、標準サーフェスが参照され続けることを保証する常設コンシューマーです。
• 仕様軸 — このチケットの 受け入れ基準に対する差分 (仕様はチケットが分解された元の総元帳です。これは、基準がどこから来たのかをトレースし、密輸されたスコープを裁定するためにのみ参照されます — どのチケットにも属さない動作は仕様軸では失敗します)。

フェーズ 5 — 完了 (終了 + C5)

フロンティアが空になり、すべてのチケットが completed になったら、人間に完了レポートを提示します。レポートには以下を含めます:

• 実装されたものの要約
• オープンアサンプション (行ったが検証できなかった仮定)
• 行ごとの堆積物リスト: 解決されなかった質問、将来の作業のための未処理項目、現在の変更では対応されなかったエッジケース。これらは CONTEXT.md の堆積物スロット (まだ存在しない場合は作成) に書き込まれます: "# Sediment\n\n## Open Assumptions\n...\n## Per-line sediment"
• チームフロンティアスケジューリング: これらの堆積物項目をいつ、どのチケットとして取り上げるべきかの推奨

C5: 人間が受け入れるか、オープンアサンプションまたは堆積物リストで拒否権を行使します。受け入れられると、Launch は docs/adr/ と docs/business/ のペーパートレイルを確定し、CONTEXT.md 堆積物スロットを更新し、終了します。

拒否権が行使された場合、人間が決定した変更を加えてフェーズ 4 に戻ります。

環境

• OMC_PROJECT_ROOT — Shipyard プロジェクトルートへのパス (設定されている場合)
• CLAUDE.md — ルールエントリ (Shipyard マップが認識する唯一のもの)
• CONTEXT.md — 永続化されたコンテキスト (語彙、決定、堆積物)
• .omc/ — Shipyard 成果物ディレクトリ
• docs/ — ドキュメントディレクトリ