loft

Loft

形が整うまで鋼板を切らないでください。 船大工は船体の線図を実寸大で描き、鋼板を一枚でも切る前に形を整えます。Loft は設計上の問いにも同じ順序を適用します。言葉を尽くしても答えが出ないとき、つまり、もっともらしい答えが二つあり、どちらも議論だけでは反証できないときは、手軽に実行できる成果物を作り、船長に反応してもらい、その反応を判断に反映します。

役割の取り決め。 クルーが成果物を作り、船長の仕事は反応することだけです。その反応がそのまま判断になります。成果物は見極めるための道具であり、納品物に先行して着手するためのものではありません。

Loft を行うタイミング

• 設計上の問いが文章のまま停滞しているとき。言い換えを繰り返しても、まだ決着できない場合（「パスページはどのような見た目にすべきか」「この状態モデルでよさそうか」など）
• ナビゲーターのマップに loft チケットがあるとき
• 仕様に関する議論が「まず見てみないとわからない」に至ったとき

次の場合は Loft を行わないでください。

• リポジトリの根拠を調べるか、船長に尋ねれば答えられる問いの場合（それは聞き取りであり、Loft ではありません）
• 目指す先そのものが不明確な場合（それは霧です — /oh-my-claudecode:ask-navigator）
• 答えがすでに ADR にある場合（決着済みの判断を再び Loft にかけないでください）
• 「設計上の問い」が実際にはバグの場合（それはデバッガーの管轄です）

分岐を選ぶ

問いの内容に応じて選びます。分岐を間違えると、成果物全体が無駄になります。

ロジック分岐 — モデルは正しいか？

状態、ビジネスルール、データの形、アルゴリズムに関する問いの場合（「再受験時にロック解除状態が戻ってしまうか」「このリデューサーは境界条件でも機能するか」など）：

1. 判断の核となる部分、つまり状態機械、リデューサー、スキーマ、アルゴリズムを、純粋なモジュールとして切り出します。DOM、I/O、フレームワークは使いません。形が確定したら、そのまま実際のコードベースに移せるように記述します。
2. シナリオごとにボタンを一つ置いた、クリック操作できる単一の HTML シェルで包みます。難しい境界ケースを順にたどり、クリックするたびに状態全体を表示します。
3. 確認後、そのモジュールはそのまま移せる状態になります。Loft の後、ローンチを通じて実作業に移します。Loft の最中は main に手を加えず、シェルはブランチに残します。

UI 分岐 — どのような見た目にすべきか？

形や配置に関する問いの場合（「ステップとカードのどちらがよいか」「進捗はどこに表示するか」など）：

1. 一つのルートに、構造の異なる三つのバリエーションを用意します。情報設計、ナビゲーションモデル、情報密度を変えます。スタイルだけが異なるバリエーションでは何もわかりません。見た目を変えただけの三案は、ただの壁紙です。
2. ページ上の切り替え機能でバリエーションを切り替えます。可能であれば既存のプロダクトに組み込み、整然とした架空の三行ではなく、実際のデータ密度でデザインに負荷をかけます。
3. 確認後、判断を引き継ぎ、なぜその見た目になったのかを記録するものとして、バリエーションはブランチに残します。

規律

• 実行コマンドは一つだけにします。リポジトリにすでにある、もっとも簡単なサーブ用コマンドを使います。file:// でモジュールの CORS が問題になる場合は、モジュールをシェルにインライン化します。数秒で読み込めるようにし、リポジトリにすでにある以上のビルド手順は追加しません。
• 永続化、テスト、抽象化は行わず、ハッピーパス以外のエラーハンドリングも追加しません。成果物は出荷したいとは思わないものにしてください。この規則は、その状態を保つためにあります。
• 最初の形には異論が出るものと考えます。同じセッション内にブランチ上で修正します。船長が最終的な形を確認した時点で判断が確定します。誰も異論を唱えない成果物は、たいてい誰も抱えていなかった問いに答えています。
• 成果物にかける時間は、作成に数分、判断に一度のセッションだけです。本番コードへと膨らみ始めたら中止してください。その作業はローンチの取り組みであり、Loft ではありません。このスキルが防ごうとしている失敗は、サンクコストです。
• 一度の Loft で答える問いは一つです。問いが二つなら Loft も二回です。ただし、実際には一つの問いを二つだと思っていた場合を除きます。

回答を確定させる

成果物は着地点ではなく、証拠です。キャプテンが反応したら、次のとおり進めてください。

1. 決定事項を、それが記録されるべき場所に残します。場所は Issue のコメント、spec の Implementation Decisions、または保留中の決定事項メモのいずれかです。キャプテン自身の言葉と、その理由を1行で記載します。散文よりも正確な断片（reducer、状態機械、スキーマなど）は、loft されたものであることを明記したうえで、そこにインラインで含めて構いません。
2. 成果物を loft/<name> ブランチへ push します。このブランチは決してマージしません。決定の「理由」が問題になったときに、将来の読者が参照できる一次情報源として残します。
3. 成果物の内容を main に取り込むことはありません。ロジック側の分岐では、確定したモジュールを launch を通じて本格的な作業として取り込み直します。UI 側の分岐では、決定事項をもとに実際のページをゼロから作り直します。

スコープと非目標

• Loft が生成するのは回答であり、成果物ではありません。ランタイム、状態ファイル、常時稼働するものは一切作りません。
• デバッグは行いません（debugger の役割ではありません）。未知の領域の調査は行いません（/oh-my-claudecode:ask-navigator の役割です）。また、自身の回答を自分で承認することはありません。受け入れを決められるのはキャプテンの反応だけです。
• Seam の承認を代替するものではありません。loft された UI は形を示すだけであり、そのテストシームは引き続き C2 で承認を受ける必要があります。

完了の定義

キャプテンが反応し、回答が決定の所在する場所に置かれ、成果物がそのブランチに存在していること。そして、成果物の一行たりとも main に入っていないこと。