ロフト

ロフト (Loft)

形が整うまで鋼材を切るな。 船大工は一枚の板を切る前に、船体のラインを実寸大でロフト（描き出し）、その曲線が滑らかであることを確認する。ロフトは設計上の疑問に対しても同じ順序を適用する。つまり、言葉が尽き、複数のもっともらしい答えが言葉では検証できなくなったとき、安価で実行可能なアーティファクトを構築し、船長に反応させ、その反応を決定に組み込む。

役割の契約。 クルーはアーティファクトを構築し、船長の唯一の仕事は反応することであり、その反応こそが決定である。アーティファクトは「見るための道具」であり、成果物への先行スタートでは決してない。

ロフトを使用するタイミング

• 設計上の疑問が散文（プローズ）で行き詰まっている場合：繰り返し言い換えても解決できない（「パスページはどう見えるべきか」「この状態モデルは正しいか」など）
• ナビゲータマップに loft チケットがある場合
• 仕様の議論が「実際に見てみないとわからない」に達した場合

以下の場合にはロフトを使用しないこと：

• リポジトリの証拠から答えられる、または船長に尋ねることで答えられる場合（それはインタビューであり、ロフトではない）
• 目的地自体が不明確な場合（それは霧（フォグ）であり、/oh-my-claudecode:ask-navigator を使用する）
• 答えがすでにADR（アーキテクチャ決定記録）に存在する場合（確定した決定を再ロフトしない）
• 「設計上の疑問」が実際にはバグである場合（それはデバッガの管轄である）

フォークの選択

質問の内容に基づいて選択する。間違ったフォークを選ぶと、アーティファクト全体が無駄になる。

ロジックフォーク — モデルは正しいか？

状態、ビジネスルール、データ構造、アルゴリズムに関する質問（「アンロックはリテイク時に後退するか？」「このリデューサは境界条件を保持するか？」）の場合：

1. 意思決定の中核となる部分（ステートマシン、リデューサ、スキーマ、アルゴリズム）を純粋なモジュールとして分離する。DOM、I/O、フレームワークは含めない。形が確認されたら、そのまま実際のコードベースに移行できるように記述する。
2. それを単一のクリック可能なHTMLシェルでラップする。シナリオごとに1ボタン、トリッキーなエッジケースを順に実行し、すべてのクリック後に完全な状態が表示されるようにする。
3. モジュールが持ち上げる（lift）準備ができたことが確認されたら、それは起動（launch）を通じて実際の作業として再びコードベースに組み込まれる。ロフト自体の間は、main ブランチは変更されず、シェルはブランチ上に残されたままになる。

UIフォーク — どのように見えるべきか？

形状と配置に関する質問（「ステップ形式かカード形式か」「進行状況はどこに表示すべきか」）の場合：

1. 一つのルートに対して、構造が異なる三つのバリアントを作成する。情報設計、ナビゲーションモデル、密度が異なる。スタイリングのみが異なるバリアントは何の答えももたらさない。三つの異なる壁紙にすぎない。
2. ページ上にバリアントを切り替えるスイッチャーを配置し、可能な限り既存の製品に埋め込む。これにより、3つの整然としたダミーデータではなく、実際のデータ密度がデザインをストレステストする。
3. 確認後、決定のみが移行し、バリアントはなぜこのような見た目になったのかの記録としてブランチ上に残される。

規律

• 実行するコマンドは一つだけにすること。リポジトリ内で最もシンプルな既存のサーブコマンドを使用する。file:// モジュールのCORS問題が発生する場合は、モジュールをシェルにインライン化する。数秒でロードされ、リポジトリがすでに持っている以上のビルドステップは不要。
• 永続化、テスト、抽象化、エラーハンドリングは通常のパス以外不要。アーティファクトは出荷したくないものであるべきであり、ルールはその状態を維持するために存在する。
• 最初の形状には議論が生じることを想定する。同じセッション内でブランチ上で修正する。船長が最終的な形状を確認したことが決定であり、誰も議論しないアーティファクトは、通常、誰も抱いていなかった質問に答えている。
• アーティファクトの全寿命は、構築に数分、判断に1セッションである。もしもプロダクションコードに成長し始めたら、そこで止める。その作業はロフトではなく、起動（launch）の取り組みである。埋没費用（サンクコスト）こそ、このスキルが防止しようとしている障害モードである。
• 1回のロフトで答えられる質問は1つだけである。2つの質問は2回のロフトが必要であり、あるいは、実際には2つだった1つの質問である。

答えの折りたたみ

アーティファクトは証拠であり、着地点ではない。船長が反応したとき：

1. 決定が属する場所（イシューコメント、仕様の「実装の決定」セクション、または保留中の決定メモ）に、船長自身の言葉と「なぜ」の1行を添えて決定を記録する。散文よりも正確な断片（リデューサ、ステートマシン、スキーマ）は、ロフト済みとマークしてインライン化してもよい。
2. アーティファクトを loft/<name> ブランチにプッシュする。これは決してマージされない。将来の読者が決定の「なぜ」を知りたいときに開くことができる一次ソースとして残る。
3. アーティファクトの内容は一切 main ブランチには取り込まれない。ロジックフォークの場合、確認されたモジュールは起動（launch）を通じて実際の作業として再びコードベースに組み込まれる。UIフォークの場合、実際のページは決定から新たに構築される。

スコープと非目標

• ロフトは答えを生成するのであり、成果物ではない。ランタイム、ステートファイル、常時稼働するものは一切生成しない。
• 診断（デバッガ）は行わず、霧（フォグ）を地図化せず（/oh-my-claudecode:ask-navigator）、自身の答えを承認しない（船長の反応のみが唯一の承認である）。
• シーム承認を代替するものではない。ロフトされたUIは形状を示すものであり、そのためのテストシームはC2で依然として承認される。

完了の定義

船長が反応し、答えが決定の属する場所に配置され、アーティファクトはそのブランチ上に存在し — そしてアーティファクトのコードは一行も main ブランチに含まれていないこと。