problem-space

/problem-space

解決策が存在する地形を把握します。目的、制約、システム、前提、そして地図が間違っていると証明するものを整理します。

問題空間は解決策空間に先行します。コードに早く飛びつくと、間違ったものをすばやく作ってしまいます。

使用するタイミング

• 実装前に新しい作業を始めるとき
• 障害やパッチが繰り返し発生するとき
• 見積もりが大きく外れているとき
• 制約が軽視されているとき

スキップする場合： 問題を十分に理解しており、実行段階にあるとき。

問題空間のプロセス

ステップ 1：目的を明確にする

「私たちは［成果］を最適化しています。」

成功を示す行動の変化、指標、または解消される問題を明示します。機能は目的ではありません。

ステップ 2：制約を整理する

固定条件として扱われているものを列挙します。

Constraint: [boundary]
Type: [hard | soft | assumed]
Reason: [why it exists]
Questioning: [could this be false?]

厳格な制約は曲げられません。柔軟な制約や仮定に基づく制約は、問い直すことができます。実装が簡単に思えるからといって、実際の制約を無視してはいけません。

ステップ 3：地形を特定する

判断を変える地形だけを記録します。

• 関連するシステム
• 影響を受けるユーザー／運用担当者／下流システム
• 間違った場合の影響範囲
• 先例やローカルなメティス

RNA/OH コンテキストツールを利用できる場合は、ガードレールやメティスを出典情報付きの候補として提示します。何を引き継ぐかは人間が選択します。

ステップ 4：状況モデルを構築する

目的、地形、制約、前提、証拠の質、未解決の疑問を結び付けます。判断に影響しない事実はノイズです。

ステップ 5：地図に負荷をかける

隠れた前提を明らかにします。X-Y の不一致がないか確認します。フレームストレスの兆候、つまり制約、地形、前提、先例が間違っていたことを示す証拠を明示します。

制約、前提、未解決の疑問が暗黙のままであれば、/solution-space に進む準備はできていません。

出力形式

## Problem Space

**Scope:** [what area this covers]

### Objective
[Outcome, not feature]

### Constraints
| Constraint | Type | Reason | Question? |
|------------|------|--------|-----------|
| [boundary] | hard/soft/assumed | [why] | [could this be false?] |

### Terrain
- **Systems:** [what's involved]
- **Stakeholders:** [who's affected]
- **Blast radius:** [what breaks if wrong]
- **Precedents/metis:** [existing local knowledge]

### Situation Model
- **Explains:** [why these elements matter]
- **May hide:** [blind spots]
- **Evidence quality:** [observed / inferred / assumed]

### Assumptions and Open Questions
- [assumption or unknown] — [risk if false / when to answer]

### Frame-Stress Signals
- [evidence that should trigger problem-space revision]

### Ready for Solution Space?
[yes/no] - [why or what's missing]

セッションの引き継ぎ

セッションファイルを使用している場合は、以前の Aim を読み、その後 ## Problem Space を置き換えるか追記します。後続フェーズでは、明示的な制約、前提、証拠の質、フレームストレスの兆候、未解決の疑問を引き継ぎます。