/solution-space
Explore candidate solutions before committing. The trap is defending the first workable idea.
Sits between Problem Statement and Implementation. You have the problem framed; now map approaches before picking one.
When to Use
- Problem is understood — you have a clear problem statement
- Multiple approaches viable — not obvious which path is best
- About to start coding — pause and explore first
- Patches accumulating — third config flag for the same bug
- Attached to first idea — that's the warning sign
Skip when: Still clarifying the problem. Use /problem-statement first.
The Local Maximum Trap
Exploration is cheap. The failure mode is defending the first solution that works.
Signs you're stuck on a local maximum:
- First solution is the only one considered
- Explaining why alternatives won't work before trying them
- Acting as crafter (defending) rather than editor (filtering)
- Implementation details discussed before approaches compared
The Escalation Ladder
Not all problems need redesigns. The ladder finds the right altitude.
Level 1: Band-Aid Fix
Patch the symptom. Fine under deadline pressure; toxic as habit. *Signal: "This will break again"* *Example: Null check. Catch exception. Hardcode edge case.*
Level 2: Local Optimum
Optimize within current assumptions. Classic refactor trap — improves what exists without questioning it. *Signal: "Cleaner but the same shape"* *Example: Extract method. Add parameter. Refactor for readability.*
Level 3: Reframe
Question the problem statement. Different framing yields different solutions, often revealing the actual constraint. *Signal: "What if the problem is..."* *Example: "We need faster cache invalidation" becomes "Why do we cache this at all?"*
Level 4: Redesign
Change the system so the problem doesn't exist. Problems dissolve rather than get solved. *Signal: "With this change, we wouldn't need to..."* *Example: Instead of fixing sync conflicts, make the data flow unidirectional.*
The Process
Step 1: State the Problem (Confirm)
"The problem we're solving is: [statement]. The key constraint is: [constraint]. The critical assumption is: [assumption]. Success looks like: [outcome or signal]."
If you can't state this clearly, go back to /problem-statement. Start from explicit constraints and assumptions, not fuzzy recollection.
Step 2: Generate Candidates (Breadth)
List at least 3-4 candidates before evaluating any:
## Candidate Solutions
### Option A: [Name]
- Approach: [Brief description]
- Level: [Band-Aid / Local Optimum / Reframe / Redesign]
- Trade-off: [Main cost]
### Option B: [Name]
...Rules:
- No evaluation yet — generation only
- Include at least one approach from a higher level than your instinct
- Include the "obvious" solution even if you don't like it
- Include status quo when it's a real option — sharpens comparison, makes cost of inaction explicit
- Maximize variance early; breadth is exploratory fuel
With RNA MCP: If oh_search_context is available, call it with problem statement + active outcome + phase: "solution-space" before generating candidates. Surface relevant metis — prior evaluations, approaches tried, recurring patterns. Human selects what to carry; selected metis informs the candidate list. This prevents proposing solutions already tried and rejected.
Step 3: Evaluate Trade-offs (Depth)
Before scoring, define the scoring function: what matters most, which constraints eliminate early, how user value is recognized. Then prune aggressively.
With RNA MCP: If oh_search_context is available, call it with the active outcome to surface applicable guardrails. These are constraints that rule options out before evaluation, not trade-offs — fold confirmed guardrails as hard constraints. Do not auto-apply metis as constraints; surface it and let the human decide weight.
For each candidate:
- Does it solve the stated problem? (Not a related problem)
- Does it increase user value or produce more output?
- How does it score against key constraints and success signal?
- Implementation cost? (Time, complexity, risk)
- Maintenance cost? (Ongoing burden)
- Second-order effects? (New problems created)
- Future optionality? (Options enabled or closed)
Step 4: Recommend with Reasoning
## Recommendation
**Approach:** [Selected option]
**Level:** [Band-Aid / Local Optimum / Reframe / Redesign]
**Why this one:**
- [Reason 1]
- [Reason 2]
**Why not the others:**
- Option A: [Reason rejected]
- Option B: [Reason rejected]
**Known trade-offs we're accepting:**
- [Trade-off 1]
- [Trade-off 2]Step 5: Check for Local Maximum
- Did I defend my first idea or explore?
- Is there a higher-level approach I dismissed too quickly?
- Am I optimizing the wrong thing?
Landing on the first idea after exploration is fine. The danger is never looking.
Output Format
## Solution Space Analysis
**Problem:** [One sentence]
**Key Constraint:** [The binding constraint]
**Critical Assumption:** [The assumption that most threatens this recommendation if false]
**Success Signal:** [What later phases should verify]
**Scoring Function:** [How options are compared/pruned, including user-value criteria]
If Critical Assumption is blank, the recommendation is untested. Every non-trivial recommendation depends on something that could be wrong. Name it.
### Candidates Considered
| Option | Level | Approach | Trade-off |
|--------|-------|----------|-----------|
| A | [Level] | [Brief] | [Cost] |
| B | [Level] | [Brief] | [Cost] |
| C | [Level] | [Brief] | [Cost] |
### Evaluation
**Option A: [Name]**
- Solves stated problem: [Yes/Partially/No]
- Implementation cost: [Low/Medium/High]
- Maintenance burden: [Low/Medium/High]
- Second-order effects: [Description]
[Repeat for each option]
### Recommendation
**Selected:** Option [X] - [Name]
**Level:** [Band-Aid / Local Optimum / Reframe / Redesign]
**Ladders back to:** [the higher-level objective or outcome this recommendation serves]
**Tactic justification:** [why this is a good tactic for that objective under current constraints]
**Rationale:** [Why this approach fits the constraints]
**Accepted trade-offs:**
- [Trade-off 1]
- [Trade-off 2]
### Execution Contract
**Preserve:**
- [criterion or behavior later phases must preserve]
- [criterion or behavior later phases must preserve]
**Verify later via:**
- [signal `/execute` and `/ship` should be able to check]
### Readiness Gate
**Ready to deepen because:** [why this is ready to move from exploration into execution]
**Invalidated if:** [what evidence or discovery would make this direction wrong]
**Stop/Pivot if:** [what signal should cause us to halt or return to solution-space]
### Needs Human Verification
Claims or decisions in this recommendation that the model cannot self-check:
- [assumption that needs independent confirmation before commitment]
- [one-way decision that should not proceed on model confidence alone]
This section routes questions to the real human checkpoint (PR review, stakeholder approval, manual verification) rather than pretending an inline model field can substitute for independent judgment.
### Implementation Notes
[Any specific considerations for the selected approach]If this recommendation involves a one-way or hard-to-reverse decision (architecture, public API, data model, external commitment), invoke /dissent before moving to /execute. Cheap exploration means the cost of challenge is low; the cost of an unchallenged wrong commitment is not.
Session Persistence
If session name provided (/solution-space auth-refactor): reads/writes .oh/auth-refactor.md directly. If no session name provided (/solution-space): offer to save with suggested name from git branch or problem being solved.
Reads: existing session file; prior outputs — Aim, Problem Statement, Problem Space — to understand constraints. Writes: solution space analysis so /execute can reuse selected approach, critical assumption, success signal, scoring function, execution contract, and readiness gate:
## Solution Space
**Updated:** <timestamp>
[solution space analysis and recommendation]Position in Framework
Comes after: /problem-statement (need a framed problem to evaluate against). Leads to: /execute to implement, or /dissent to challenge the recommendation. Can loop back to: /problem-statement (if exploration reveals the problem is mis-framed).