clarify-decisions

意思決定の明確化

これは再利用可能なインタビュープロトコルであり、パイプラインのステージではありません。親の下にネストされている場合は、その会話とチェックリストの中で進めます。単独で使う場合は、共通理解に至るまでインタビューを主導します。チェックリストの管理にはTodosに従います。負債や誤ったアーキテクチャにつながり得る、明示されていない前提はすべて洗い出し、決定します。先導語：open set、territory、card、problem lock、criteria、coverage map、close package。マップ（プロンプト、計画、既知の情報）は、テリトリー（コードベース、ランタイム、ユーザー、履歴）ではありません。

鉄則 — チャネル

EVERY QUESTION IS INLINE CHAT WITH FULL CONTEXT.
NEVER use AskUserQuestion, structured MCQ pickers, or any harness UI that
truncates labels, option text, or the "why this matters" line.

結果をそぎ落とす選択式の質問は、別のインタビューです。ハウススタイル、権限、期限、名目上は長い説明欄があることも例外にはなりません。

鉄則 — オープンセット（固定ラウンドなし）

THERE IS NO FIXED ROUND COUNT.
NEVER "Question k of N", "last of 5", or "we budgeted four cards".
Stop only when the open set is empty of judgment calls that change
architecture, data, auth/security, UX flow, or implementation scope —
AND, when the production-coverage gate is ON, judgment calls on
reliability, failure, and operate, with no coverage-map cell Missing
without an owner.

オープンセット＝未決定の、影響範囲が大きい未知事項＋直近の回答によって生じた分岐＋ユーザーの確定がまだ必要な親の既知の未知事項＋（カバレッジがONの場合）担当者がいない「Missing」のカバレッジセル。基本ルール：回答のたびに必ずオープンセットを再計算し、次のカードに進むか、クローズパッケージに進みます。「再計算」への他の言及はすべて、ここを指します。事前に列挙したToDoは更新し続けるマップであり、ノルマではありません。新たに生じた分岐を追加し、解決済みの項目を削除し、影響範囲の大きい項目が残っている間は決してクローズしません。切迫度によって変わるのは進捗を報告するタイミングであり、明示されていない意思決定が存在するかどうかではありません。Todos：ネストされている場合、競合するリストは作りません。親のチェックリスト内で進め、クローズパッケージが確認されるまでインタビュー項目を進行中のままにします。オープンセットの進捗はその項目の進捗であり、別のチャネルではありません。単独の場合、意思決定領域の更新し続けるオープンセットリストを使ってもかまいません。ただし、メッセージごとにカードは1つだけとし、回答のたびに再計算します。また、親スキルがすでに進行中なら、決して2つ目のチャネルを開きません。

本番カバレッジゲート（適用条件）

ON／OFFの判定基準。ONの場合はproduction-coverage.md（マップ、範囲、クローズ時のスロット7～10）を読み込み、それに従います。OFFの場合は読み込みません。権限やチャットの雰囲気によってゲートが切り替わることはありません。開始時のマップを作る前に一度だけ判定します（文書化された方針、ブリーフのフラグ、または運用／ローンチの対象範囲が変わった場合にのみ再確認します）。次の3つすべてに当てはまる場合のみONです。

1. 方針の区分 — 文書化されたDeliveryの意図がProductionで、LifecycleがCut Released／Scaling／Maintenance（親またはdocs/agents/project.md）であること。
2. 全経路のインタビュー — 親がこのインタビューをtier 0またはbriefと指定していないこと。
3. 対象範囲の条件 — 運用／ローンチの対象範囲（アラート、ロールバック、SLO、オンコール、デプロイ／引き継ぎ、新たな障害ドメイン）があること、またはユーザー／親が運用・信頼性のカバレッジを明示的に求めていること。

それ以外はOFFです。方針が明記されていない場合、MVP · Run Spike · Research · Learning、LifecycleがIdea · Early · Active developmentの場合、条件に該当せず外観・文言・色を整えるだけの場合、文書化された区分と条件を満たさず「SREの習慣を身につける」という会話だけの場合も含みます。OFFの場合、カバレッジマップ全体を省略します。reliability／failure／operateの範囲も設けません。クローズ時にスロット7～10を省略します。中核となるクローズ時のスロット4～6（Success、Boundaries、Spine）と課題の確定は引き続き適用されます。

最初のカードの前に行うマップ

親の Knowns、Blindspot、およびスキャンダイジェストがあれば読み込みます（例：.skills/<CODE>/{knowns,scan}.md または _pending-<slug> 相当のファイル）。Coverage ON または OFF（OFF の場合は、どのゲート部分で失敗したか）を示してから、短い思考パートナーマップを提示します。

1. 確定事項 — 固定された方針、譲れない条件、ダイジェストの事実。
2. カバレッジマップ — ON の場合のみ（production-coverage.md にある表とセルの作成手順）。
3. 影響範囲の大きい未解決事項 — ON：そのファイルの Missing／Partial セル。OFF：アーキテクチャ／データ／認証／UX／スコープの分岐のみ。
4. 解決方法 — 判断が必要な項目はカードにします。事実確認には reference／run-spike／research を使います。盲点には教えてから質問します。Operate パスは ON の場合のみ使います（production-coverage.md を参照）。

確定事項が誤っている場合に限り、訂正を促します。最初のカードは、条件を満たす場合は Problem lock、そうでなければ影響範囲が最も大きい未解決事項です（ON の場合は、Missing のカバレッジセルを優先します）。親ですでにマップが提示されている場合は、繰り返さないでください。ただし、ON の場合は回答後もカバレッジを更新します。

Problem lock（選好カードの前に）

このルールの適用箇所です。 他のセクションではここを参照するだけにします。分岐（必ずどちらか一方を選択）： （Observed・Desired・Non-goals をそれぞれ含む）代替の問題文を 2～4 個、1 枚のカードに収められる場合は、その problem-lock カードを提示します。ユーザーに複数ラウンドにわたる問題ツリーの検討や基礎知識の説明がまだ必要な場合（症状と解決策の形が絡み合っている、両立しない課題が二つ以上ある、または各選択肢についてこの3項目を正直に書けない場合）は、ユーザーに /work-the-problem を実行するよう案内します（呼び出してはいけません。このスキルには disable-model-invocation が設定されています）。どちらの場合も、解決策の形を選ぶメニューは提示しないでください。

Problem-lock カードは、親の knowns に解決策の形をした Assumptions（名前の挙がった API、フラグ、マージ、または「単に X を実行する」など）が示されている または 望ましい結果／成功の指標が示されていない場合に、かつ上記の分岐でカード作成が選ばれた場合に作成します。Question カードの作成手順を使います。Thread の This card には problem lock を記載します。本文では、選択した問題文について次の3項目をすべて確定しなければなりません（選択肢は代替の 問題文 であり、実装ではありません）。

• Observed — 誰が困っているか／現状で何が事実か
• Desired — 完了時に観測可能な結果（「動く」ではありません）
• Non-goals — 意図的に対象外とすること

解決する項目：known-unknown（問題文）。経験豊富なユーザーの「理屈は抜きで API の選択肢だけ決める」、スタンドアップの時間制限、「別のスキルに回さないで」という要望があっても、このセクションを省略してはいけません。

質問カード（毎ターン）

メッセージごとに決定する項目は1つだけです。すべてのスロットが必須です。最初のカードでは card-recipe.md（スロットの展開、Shape、推奨の根拠）を読み込みます。親から確認済みの実例が提供されていない場合は、example.md を読み込みます。 機能作業で隣接領域、重複、再利用が関わる場合は、最初のカードを作成する前に feature-retrieval.md を読み込みます。それ以外の場合は読み込みません。

1. Radius — architecture · data · auth/security · UX flow · polish-diff。Coverage が ON の場合は、reliability · failure · operate も含みます。
2. Thread — ここまでに確定したこと · このカード · この後も未確定のこと（名前を挙げ、「5つ中3つ」のような表現は使いません）。
3. Territory — リポジトリの事実に基づきます。ここで作業を妨げる盲点を明らかにし、創作せず、読み取れることをユーザーに思い出してもらうよう求めません。
4. Question — 決定事項を平易な言葉で示します。
5. Why it matters — 影響範囲の説明のみ（回答が変わると何を書き換えることになるか）。評価基準はスロット7です。
6. Closes — known-unknown · unknown-known · blindspot-confirm。
7. Criteria (graders) — 影響範囲の大きい項目では必須です（polish-diff のみ省略可）。選択肢の上に、合否を判定する評価基準を1～2つ、名前付きで記載します。推奨では、評価基準を名前で引用する必要があります。
8. Options (2–4) — 得られるもの、負担するもの、問題が起きる可能性、より適合する条件を示します。ラベルだけでは選択肢になりません。 Shape — architecture または data では、すべての選択肢で必須です。呼び出し元から見える違い（シグネチャ、型、カラム、ルート、ペイロード）を6行以内で示し、本文は含めません。成果物の名前を文章中で挙げるだけでは Shape になりません。「選択肢1と同じだが……」も該当しません。
9. Recommendation — 選択 · 決定的な要因 · 次点 · 受け入れるトレードオフ · 確信度／根拠の不足 · 再検討のきっかけ（観測可能なもの。「要件が変わったら」はきっかけになりません）。
10. 停止。 待機します。未確定事項を再計算し、次のカードに進むか、パッケージを締めくくります。

表示順：Radius → Thread → Territory → Question → Why it matters → Closes → Criteria → Options → Recommendation → Stop

順序とカバレッジ

• 影響範囲の大きいものを先に扱います。 ユーザーが最初に仕上げを話題にした場合でも、仕上げより先にアーキテクチャ、データ、パブリック API、認証／セキュリティ、UX フロー、スコープを扱います。
• Coverage が ON の場合の順序：production-coverage.md（Missing を Partial より先に扱います）。未確定事項がなくなったら停止します。事実は Territory に記載し、人が決めることだけをカードにします。
• 互換性に関する義務。 docs/agents/project.md の Project posture（記載された行。なければ Lifecycle から導出：Idea / Early / Active development → None、Cut Released / Scaling / Maintenance → External）を確認します。None の場合、architecture または data のカードにおける選択肢と推奨では、何も取り残さない単一の形状にします。None で並行カラム、同期トリガー、v2 という名前、非推奨化期間を設けるのは不備です。Internal／External の場合、これらのコストを第一級の要素として扱います。提供の意図によって品質基準は決まりますが、互換性に関する判断は変わりません。
• チーム規模。 Roster または Workflow の規模が上書きされている場合は、そのセクションからパッケージを作成します。チームについて創作してはいけません。

インタビューのみです。盲点：親のリストを引き継ぎます。課題：Problem lock に従います。スコープの分解：親に返します。既知の未知情報：参照資料／run-spike／research を示し、その後に結果カードを1つ作成します。

パッケージを締めくくる（必須）

未解決の高影響な判断事項がなくなったら、親に制御を戻す前、または共通認識があると主張する前に、次を出力します。

1. 決定事項の表 — 行：影響範囲 · トピック · 決定事項（ユーザーの言葉） · 解消された未知の分類。
2. 制約ブロック — そのまま貼り付けられるロック（最初にアーキテクチャとデータ、Coverage が ON の場合は次に信頼性／障害／運用、最後にポリッシュの差分）。影響範囲の小さい回答が、影響範囲の大きいロックと矛盾する場合は明示します。
3. 変更可能性の高い領域 — 実装上の現実的な制約によって変更される可能性が最も高いロック（データモデル、型インターフェース、UX フロー）。機械的なリファクタリングは埋もれたままにし、ここで再質問しないでください。
4. 成功／完了のシグナル — 「完了」を意味する観測可能な指標を1～3個示します（requirements.md／NFR に貼り付け可能なもの）。Journey の確認を行った場合は、CUJ に沿った観測可能な指標を優先します。「動作する」「認識が一致している」ではありません。
5. 境界 — 対象外（実施しないこと）と 動作を維持する対象（ガード／変更しない動作）。2～4個の箇条書きだけでも構いません。problem-lock の非目標と、該当する場合は (guard) 形式のロックを基にします。
6. Spine への影響 — docs/architecture/（または同等の ARCH spine）が存在する場合：Respects: ARCH-N… · none · または challenges（ADR が必要）。存在しない場合：none — no architecture spine。ARCH ID を捏造しないでください。 7～10. Coverage の最終確認 · 所有する未知事項 · 受け入れるリスク · 運用性への影響 — Coverage が ON の場合は必須です。手順は production-coverage.md のみを参照してください。OFF の場合は省略します。
7. 明示的な確認 — これが共通認識でしょうか。このパッケージに対する肯定的な回答のみが確認として扱われます。

スロット4～6は常に必須です。スロット7～10は Coverage が ON の場合のみ必須です。次のような発言は確認に該当しません：「ほかに質問はありますか？」、「認識は一致しているので、表は省略しましょう」、「要件を書き始めてください」、「信頼性は後で NFR にします」、儀式を省略するよう求める上位者からの圧力、または沈黙。行の訂正があれば編集して再確認します。確認によって新たな高影響の分岐や Missing セルが生じた場合は、カードに戻ります。確認が得られるまで、何も実行しないでください — 本番コードの作成、スキャフォールディング、計画の実行は禁止です。（用語がインタビュー中に確定した場合、define-domain による用語集／CONTEXT.md の更新は受動的な副作用として許可されます。）

もっともらしい言い訳

考え	実際
「チームの慣例では、リードがピッカーを使うよう言っていた」	チャネルは鉄則です。インラインカードを1つだけ使います。
「評価基準は明確だから、1行の推奨で十分」	選択肢の中から選んだ案が次点案より優れている理由、トレードオフ、証拠の不足、再検討の条件を示します。
「成功条件は Why に入れる／条件を長々と書かない」	Why は影響範囲です。Criteria は Options より上に置く独立した評価基準です。
「4つの領域を終えた／5問中3問目まで来たらパッケージ化する」	未解決の項目がなくなった時点が終了です。
「ユーザーは最初にボタンの色を聞いた」	まず影響範囲です。アーキテクチャ、データ、認証の後にポリッシュを扱います。
「認識は一致している／上位者が要件を書けと言った」	共通認識とは、パッケージと肯定的な回答です。
「安価な方法が指定された／理念の話は飛ばして API の選択肢を決める」	解決策に沿った前提はロックではありません。問題のロックに従ってください。
「成功／境界／Spine は後工程で扱う」	ここでは締めくくりのスロット4～6が必須です。
「別の場所に誘導しないで。スキル名を挙げれば実行したことになる」	/work-the-problem と明記してください。自動的に実行してはいけません。
「安全のため追加的に変更する／None のリポジトリに v2 の名前を付ける」	互換性の義務が None の場合は、形状は1つです。v2 という名前、並行する列、または非推奨期間は欠陥です。
「信頼性は後で扱う／マップは省略する」	Coverage が ON の場合、Missing セルは未解決のままです。行を追加する場合は card-recipe.md を参照してください。

危険信号 — 立ち止まり、ターンを書き直す

• AskUserQuestion または切り詰められたMCQツールを呼び出す
• メッセージ内にユーザーに向けた疑問符が複数ある（選択肢テキスト内の例を除く）
• Thread、Territory、Why、Closes、選択肢の影響、高い影響範囲のCriteria、または推奨理由のいずれかが欠けたカード
• Problem lock の適用中に、カードを提示せず、または /work-the-problem に言及せず、選好や解決策のメニューを提示する
• 高い影響範囲が残っているのに「Question k of N」と記載する、または件数に言及して締めくくる
• アーキテクチャ／データ／認証（またはCoverageがONの場合はR/F/O）が未解決なのに、見た目の差分を先に提示する
• Success、Boundaries、またはSpine touchが欠けたクローズパッケージ、あるいは「合意しました」を確認として扱う
• マップ／スロット7～10を提示せずにCoverageをONにする、またはゲートの一部でも失敗しているのにCoverageをONにする
• Compat obligation None のときに、v2 という名前、並行する列、同期トリガー、または非推奨化の猶予期間を提示する
• /work-the-problem を自動的に呼び出す、SLO-N／TB-N／THR-NのIDを捏造する、Owned unknownsをAccepted risksに統合する