solution-space

/solution-space

確定する前に、候補となる解決策を検討します。最初にうまくいったアイデアを擁護するのが落とし穴です。

解決策の検討は、もっともらしさを基準に進めます。考えられるすべての選択肢を完璧に網羅するのではなく、次のアクションを選べる程度に筋の通ったストーリーを作ります。詳細を加えるのは、それによって推奨内容が変わる場合だけです。

使用するタイミング

• 問題が定義されており、複数のアプローチが有効な場合
• コーディングを始めようとしている場合
• パッチやフラグが増え続けている場合
• 最初のアイデアに固執していると感じる場合

スキップする場合： まだ問題を明確にしている段階です。最初に /problem-statement を使用してください。

必要に応じたリファレンス

選択肢の影響が大きい場合、互いに似すぎている場合、または推奨内容に自信を持ちすぎていると感じる場合に限り、references/depth.md を読み込みます。

プロセス

ステップ 1：問題の枠組みを確認する

「解決する問題は、次のとおりです：[問題の記述]。制約となる条件は：[制約]。前提とするストーリーは：[もっともらしい枠組み]。成功の兆候は：[指標]。」

これを明確に言えない場合は、/problem-statement に戻ってください。枠組みが不明確なまま、詳細を加えて補おうとしてはいけません。

## Problem Weave が存在する場合は、候補となる S&T のステップと充足グループを確認します。これらは仮説として扱い、あらかじめ選ばれた作業とは見なしません。推奨内容で各ステップを選択、却下、または保留できるよう、ID を維持してください。

ステップ 2：候補を挙げる

評価する前に、実質的に異なる候補を 3～4 個挙げます。明白な選択肢、現状維持が現実的な場合はその選択肢、そして視点を変える選択肢を少なくとも 1 つ含めます。たとえば、応急処置、局所最適、枠組みの見直し、再設計などです。

ステップ 3：判断を左右する違いだけを評価する

採点する前に、判断基準、重要な前提、そして選択肢を早い段階で除外する制約を明示します。そのうえで、候補を積極的に絞り込みます。

各候補について、次の問いに答えます。

1. 明示された問題を解決しますか？
2. どの枠組みを前提としていますか？
3. 実装または保守にかかる主なコストは何ですか？
4. どのような二次的な問題や将来の選択肢を生み出しますか？

二次的な問題、隠れた前提、またはもっともらしい別の枠組みを挙げた候補については、/execute の用語を使って、そのリスクを解消する方法を決めます：証拠により解消、根拠を示して受容、または 発動。証拠により解消する項目ごとに、チェックで失敗させるべき、魅力的だが誤ったパッチ、または局所最適を明示します。挙げたリスクを引き継ぎ時に消してはなりません。

ステップ 4：解釈に幅があるか確認する

選択肢の集合が、同じ枠組みを別の装いで並べただけになっていないか確認します。どの選択肢が現行の枠組みを前提とし、どれがそれを検証するのか、また失敗から何が分かるのかを明示します。

すべての候補が同じ隠れた枠組みを共有している場合は、異なる枠組みの候補を 1 つ作るか、/problem-statement に戻ってください。

ステップ 4.5：リスク解消計画を作成する

推奨する前に、不確実性をアクションに変えます。重要な前提、もっともらしい別の枠組み、中止や方針転換のトリガーそれぞれについて、予定する対応を 1 つ選びます：敵対的チェックによる証拠により解消、スコープ外であるか人間またはドメインの判断が必要なため根拠を示して受容、または証拠が選択したアプローチを無効にする場合の発動。

敵対的チェックでは、最初にうまくいったアイデア、魅力的な応急処置、または局所最適に失敗させ、特定したリスクを残さないようにできなければなりません。懸念しているパッチもチェックに通ってしまう場合、それはリスク解消チェックではありません。チェックを強化するか、/problem-statement に戻ってください。

この選択を /execute に先送りしてはなりません。選択した案が、今すぐ、または実行中に低コストでモデルチェックできるもっともらしい別の枠組みを無視することに依存している場合は、引き継ぎに敵対的チェックを追加します。重要な前提について信頼できる証拠を得る方法がない場合は、枠組みの準備ができていないため、/problem-statement に戻ってください。

ステップ 5：推奨する

現在の制約下で十分に妥当と思われるアプローチを選択します。推奨するものが一方通行の決定（アーキテクチャ、公開 API、データモデル、外部へのコミットメント）である場合は、/execute の前に /dissent を実行してください。

Problem Weave がある場合は、選択したアプローチを S&T のステップに対応付けます。

• 推奨に必要なステップのみを selected とします。
• 反証された戦術を rejected、不要だが依然として妥当な戦術を deferred とします。
• 親ステップ、充足グループ、担当者、レビューのトリガー、受け入れたトレードオフを保持します。
• 必須の親ステップまたは兄弟の充足セットが存在しない状態で子ステップを選択する場合は、その不足を明示します。
• 選択したステップ ID のみを /oh-plan に渡します。候補ステップと保留中のステップは、計画対象外のまま表示しておきます。

出力形式

## Solution Space

### Solution Space Analysis

**Problem:** [One sentence]
**Key Constraint:** [The binding constraint]
**Working Story:** [The plausible frame that makes this recommendation sensible]
**Success Signal:** [What later phases should verify]
**Decision Criteria:** [What matters most and how options were compared]
**Critical Assumptions:** [Premises the selected approach depends on]

### Candidates Considered
| Option | Level | Approach | Main Trade-off |
|--------|-------|----------|----------------|
| A | [Band-Aid / Local Optimum / Reframe / Redesign] | [Brief] | [Cost] |
| B | [Level] | [Brief] | [Cost] |
| C | [Level] | [Brief] | [Cost] |

### Interpretive Variety Check
- Same frame or different frames? [brief answer]
- Current-frame test: [which option most assumes/tests the current frame]
- Failure would teach: [what failure would mean and where learning routes]

### Risk Retirement Plan
| Risk / Assumption / Alternate Frame | Planned Disposition | Tempting Patch This Must Fail | Required Evidence or Rationale | Stop/Pivot If |
|-------------------------------------|---------------------|-------------------------------|--------------------------------|---------------|
| [Named uncertainty] | [Retired by evidence / Accepted with rationale / Triggered] | [wrong-but-plausible local patch, or "N/A — accepted/triggered"] | [adversarial test/check/rationale/human decision] | [trigger] |

### Recommendation
**Selected:** Option [X] - [Name]
**Level:** [Band-Aid / Local Optimum / Reframe / Redesign]

**Rationale:** [Why this approach is plausible enough under current constraints]

**Accepted trade-offs:**
- [Trade-off 1]
- [Trade-off 2]

### S&T Selection
| Step ID | Disposition | Parent | Sufficiency group | Why this disposition | Owner | Review trigger |
|---|---|---|---|---|---|---|
| [id] | [selected/rejected/deferred] | [root/id] | [group id] | [connection to recommendation/evidence] | [role] | [when to reassess] |

**Selected-step sufficiency:** [why the selected set covers the chosen strategy, or the explicit gap that blocks planning]

### Execution Handoff
- Preserve: [criterion or behavior later phases must preserve]
- Verify via: [signal `/execute` and `/ship` should be able to check]
- Decision criteria: [comparison basis `/execute` should preserve]
- Critical assumptions: [premises to monitor during execution]
- Accepted trade-offs: [costs consciously accepted]
- Risk retirement checks: [planned disposition plus adversarial tests/inspections/rationales required for every named risk or alternate frame; each evidence check names the tempting patch it must fail]
- Invalidated if: [what evidence would make this direction wrong]
- Stop/pivot triggers: [conditions that require pause, escalation, or strategy change]
- Needs human verification: [claim or decision the model cannot self-check, or "none"]

セッションの引き継ぎ

セッションファイルを使用している場合は、Aim、Problem Statement、Problem Space、および任意の Problem Weave を読み取り、## Solution Space を置換または追記します。

• /execute では、選択したアプローチ、作業中のストーリー、成功シグナル、基準、前提、トレードオフ、リスク解消のチェック、無効化シグナル、中止／方向転換のトリガー、S&T の処置を再利用します。
• /oh-plan が受け取るのは、selected の S&T ステップ ID とその系譜のみです。