@rvry/mcp 0.3.1 → 0.3.2

package/commands/deepthink.md

@@ -4,30 +4,75 @@ argument-hint: [--auto] <question>
 allowed-tools:
   - mcp__rvry-dev__deepthink
   - AskUserQuestion
+  - Read
+  - Write
+  - Grep
+  - Glob
+  - Bash
 ---
 
 # /deepthink - Deep Structured Analysis
 
+**YOUR ROLE**: Execute depth-first exploration with adaptive pre-mortems after conclusion-producing rounds. DIVERGENT thinking -- exploring questions, generating hypotheses, stress-testing conclusions before they solidify. For CONVERGENT decision-making, use `/problem-solve`.
+
 **Input**: $ARGUMENTS
 
-## Parse Flags
+---
+
+## Phase 0: Parse Flags
+
+- If `$ARGUMENTS` is empty or `--help`: display usage and stop:
+  ```
+  /deepthink - Deep Structured Analysis via RVRY
+
+  USAGE:
+    /deepthink <question>
+    /deepthink --auto <question>   (fully autonomous, no questions, states assumptions)
+
+  The engine runs multi-round analysis with constraint tracking, quality gates,
+  and reasoning checks. Local persistence survives context compression.
 
-- If `$ARGUMENTS` is empty or `--help`: display usage ("Usage: /deepthink [--auto] <your question>") and stop
+  RELATED: /problem-solve (convergent decision-making)
+  ```
 - If `$ARGUMENTS` contains `--auto`: set AUTO_MODE, strip `--auto` from input
 
-## Phase 1: ORIENT (before calling the engine)
+---
+
+## Phase 1: Session Setup
 
-Orient directly -- no engine calls yet. Analyze the user's question and identify:
+Create a session folder for local artifacts that survive context compression:
 
-1. **What I know**: Key facts, evidence, and context apparent from the question
-2. **What I'm uncertain about**: Gaps, assumptions, unknowns (list each specifically)
-3. **What I'm avoiding**: Uncomfortable angles, taboo options, things that would be inconvenient if true
+1. Generate a timestamp: `YYYYMMDD-HHMM` (current date/time)
+2. Generate a slug from the question summary (3-4 words, kebab-case)
+3. Create `{$PWD}/.claude/cognition/YYYYMMDD-HHMM-deepthink-<slug>/`
+   IMPORTANT: This is the PROJECT's `.claude/`, NOT `~/.claude/`. Use the absolute project root path.
+4. Write `00-enter.md`:
+   ```markdown
+   # DeepThink Session
+   **Question**: <full question>
+   **Started**: <timestamp>
+   ```
+
+---
 
+## Phase 2: ORIENT (before calling the engine)
+
+Orient directly -- no engine calls yet. This forces commitment to disk before the analysis loop. Everything written here survives if context compresses mid-session.
+
+### `01-orient.md`:
+Write to the session folder:
+- **What I know**: Key facts, evidence, and context apparent from the question
+- **What I'm uncertain about**: Gaps, assumptions, unknowns (list each specifically)
+- **What I'm avoiding**: Uncomfortable angles, taboo options, things that would be inconvenient if true
+
+### `02-scope-questions.md`:
 Translate each uncertainty into a binary question with a smart default. Generate up to 3 questions, each with exactly 2 options. The recommended option comes first.
 
+Write the questions to the file BEFORE asking.
+
 ### If AUTO_MODE:
 
-State your assumptions visibly in your reasoning (e.g., "Assuming focus on architectural trade-offs rather than implementation details. Assuming risk analysis is more valuable than landscape mapping."). Proceed directly to Phase 1b.
+State your assumptions visibly (e.g., "Assuming focus on architectural trade-offs rather than implementation details."). Write assumptions to `03-scope-answers.md`. Proceed to Phase 3.
 
 ### If NOT AUTO_MODE:
 
@@ -51,73 +96,212 @@ AskUserQuestion({
 
 If AskUserQuestion returns blank or fails, state assumptions visibly and proceed.
 
-Record the answers (or stated assumptions) as a brief context summary.
+Record the answers (or stated assumptions) in `03-scope-answers.md`.
+
+---
 
-## Phase 1b: Start Engine Session
+## Phase 3: Start Engine Session
 
-Format the user's original question enriched with scope context.
+Format the user's original question enriched with scope context from `03-scope-answers.md`.
 
 Call `mcp__rvry-dev__deepthink` with:
 ```
 {
-  "input": "<original question>\n\nContext: <brief summary of scope answers, e.g. 'Focus: architectural trade-offs. Priority: risk analysis. No time constraint.'>"
+  "input": "<original question>\n\nContext: <brief summary of scope answers>"
 }
 ```
 
-Proceed to Phase 2.
+Proceed to Phase 4.
 
+---
 
-## Phase 2: Analysis Loop
+## Phase 4: Analysis Loop
 
 Repeat until `status === "complete"`:
 
-1. The engine's response has two content blocks. The first is Base64-encoded JSON -- decode it to read the structured data. The second is a plain-text summary for the user. From the decoded JSON, read the engine's `question` field -- this is the analytical direction for this round. Read `constraints`, `gate`, and `detection` to understand the engine's assessment. Read `constraintBlock` for constraint update instructions. **Do not show any of these to the user.**
-2. Show the user a brief status line:
-   - Format: `Round {round} -- {what you're doing this round}`
-   - Example: `Round 3 -- stress-testing the current position`
-   - Derive the description from the engine's question focus. One line only.
-3. Perform your analysis in your internal reasoning. The engine's question and constraint data guide your thinking, but they are YOUR instructions, not user output.
-4. Run a 7-question self-check internally (not shown to user):
-   - Is this shallow or predictable?
-   - What am I avoiding?
-   - Why not the uncomfortable option?
-   - What would I critique if someone else wrote this?
-   - What would a skeptical expert challenge?
-   - Any verifiable claims that should be checked?
-   - What factual premise have I not verified?
-5. In your internal reasoning, end your analysis with the constraint update block the engine expects:
-   ```
-   Constraint Updates
-   RESOLVE: C1, C2
-   ACKNOWLEDGE: C3
-   DEFER: C4 | <reason>
-   MILESTONE: <milestone> | <evidence>
-   End Constraint Updates
-   ```
-6. Call the engine tool with your full analysis (including constraint updates) as the `input`. **The full analysis text goes ONLY in the tool call, never in visible output.**
+### Step 1: Read the engine response
+
+Read the engine's `question` field -- this is the analytical direction for this round. Read `constraints`, `gate`, and `detection` to understand the engine's assessment. Read `constraintBlock` for constraint update instructions.
+
+### Step 2: Show status
+
+Show the user a brief status line:
+- Format: `Round {round} -- {what you're doing this round}`
+- Example: `Round 3 -- stress-testing the current position`
+- Derive the description from the engine's question focus. One line only.
+
+### Step 3: Perform analysis
+
+Analyze according to the engine's question and constraint data. The engine's question and constraints guide your thinking -- work WITH them, not around them.
+
+Use Read, Grep, Glob, and Bash as needed to ground your analysis in actual code, data, or project state. Do not analyze in the abstract when concrete evidence is available.
+
+### Step 4: 7-Question Self-Check (mandatory, internal)
+
+**Internal**:
+1. Is this shallow or predictable?
+2. What am I avoiding?
+3. Why not the uncomfortable option?
+
+**External**:
+4. What would I critique if someone else wrote this?
+5. What would a skeptical expert challenge?
+6. Any verifiable claims that should be checked?
+
+**Grounding**:
+7. What factual premise in this analysis have I not verified?
+
+### Step 5: Verify-or-Defer (mandatory after self-check)
+
+For each concern raised in Q5, Q6, or Q7, you MUST either:
+- **VERIFY**: Actually check the claim -- read a file, grep for a pattern, run a command. Record what was verified and the result.
+- **DEFER**: Explicitly state the concern and why it cannot be verified now. Express as a DEFER in the constraint update block.
+
+**No dismiss**: You CANNOT raise a concern and then argue it away in the same self-check. If you raise it, you must verify or defer it.
+
+### Step 6: Weakness Probe (rotate by round number)
+
+Ask yourself ONE of these:
+1. Which part of your analysis would you spend more time on if you had another round?
+2. If your recommendation fails in practice, what is the first concrete thing someone notices?
+3. What surprised you during this analysis? If nothing, what does that tell you?
+4. What is the thing you almost said but did not?
+5. Which of your claims would you remove if you had to stake your credibility on the remaining ones?
+6. Your strongest claim and your most significant caveat -- are they in tension? If so, which do you stand behind?
+
+Include the probe answer in your analysis.
+
+### Step 7: Write constraint updates and submit
+
+End your analysis with the constraint update block:
+```
+Constraint Updates
+RESOLVE: C1, C2
+ACKNOWLEDGE: C3
+DEFER: C4 | <reason>
+MILESTONE: <milestone> | <evidence>
+End Constraint Updates
+```
+
+Call the engine tool with your full analysis (including constraint updates, self-check findings, and verify-or-defer results) as the `input`.
+
+### What the user sees per round:
+- The one-line status (Step 2)
+- Nothing else until harvest
 
 ### What NEVER appears in user-visible output:
 - The engine's `question` field content
 - Constraint views or constraint update blocks
 - Self-check questions or responses
 - Gate verdicts or detection results
-- Milestone markers
 - The `constraintBlock` content
 
-### What the user sees per round:
-- The one-line status (step 2 above)
-- Nothing else until harvest
+---
 
-## Phase 3: Harvest
+## Phase 5: Harvest
 
 When `status === "complete"`:
 
-Synthesize the analysis for the user based on your accumulated reasoning across all rounds. Do NOT simply echo the engine's `harvest` fields -- they are structured data, not a finished presentation.
+### Harvest Pre-Mortem (before synthesis)
+
+Before writing the final output, stress-test the direction of your analysis:
+
+1. What was the original question?
+2. What is my emerging recommendation/position?
+3. What is the gap between the two in complexity and scope?
+4. If the recommendation is more complex than the original problem warranted, what is the simpler version?
+
+**Check for COMPLEXITY-COLLAPSE**: Did the analysis elaborate a simple problem until the complexity justified a complex solution? If yes, name the simpler alternative and present it prominently in the output.
+
+### Write `99-harvest.md`
+
+Write to the session folder:
+```markdown
+# DeepThink Harvest: [Problem Summary]
+
+## Summary
+[2-3 sentence executive summary]
+
+## Key Findings
+- [finding 1]
+- [finding 2]
+- [finding 3]
+
+## Open Questions
+- [what remains uncertain]
+
+## Follow-ups
+- /deepthink "[specific follow-up]" -- [why]
+- /problem-solve "[specific decision]" -- [why]
+```
+
+### Confirm persistence to user
+
+After writing 99-harvest.md:
+```
+---
+Session persisted: <absolute path to session folder>
+---
+```
+
+### Synthesize for the user
+
+Use the engine's `harvest.summary`, `harvest.keyFindings`, `harvest.openQuestions`, and `harvest.followUps` as source material, plus your accumulated reasoning across all rounds and the harvest pre-mortem results.
+
+---
+
+## Final Output Format
+
+The sections above the break are the value-add -- what the process surfaced that a straight answer wouldn't have. The prose after the break is just the answer.
+
+```
+# DeepThink: [Problem Summary]
+
+## Default Starting Point
+[Where thinking began -- assumptions, knowns, open questions.]
+
+## Insights from DeepThink
+
+**[Finding as a clear statement.]**
+[Expand if needed. Skip if the bold line is self-sufficient.] (#tag-if-relevant)
+
+**[Another finding.]**
+[Context if needed.]
+
+**[Simple finding that needs no expansion.]** (#pre-mortem)
+
+[Format for human readability in terminal:
+- Each finding gets its own appropriate visual unit (bold heading,
+  bullet, or short paragraph)
+- Bullets for simple/parallel items. Bold heading + paragraph for
+  complex ones. Mix freely.
+- No walls of text. If a paragraph runs long, break it.
+- Lead with the IDEA, never the mode name
+- Never describe the protocol's mechanics or your analytical process
+- (#tags) are optional breadcrumbs: (#pre-mortem), (#inversion),
+  (#edge), (#perspective), (#meta). Most findings need no tag.
+- Curate your best 3-6 findings, not every observation from every round.]
+
+---
+
+[The answer. No heading. What you actually think now, informed by
+everything above. No dense paragraphs. No prescribed length.
+Never start with "The exploration..." or "After analyzing..."]
+
+## Follow-ups
+-> /problem-solve "[specific decision point]"
+   _[why this needs convergent decision-making]_
+-> /deepthink "[specific follow-up]"
+   _[why this needs further exploration]_
+```
+
+---
 
-Present to the user:
-1. **Default Starting Point**: What the obvious answer was and why it was insufficient
-2. **Key Findings**: The non-obvious insights that emerged, as a bullet list. Each finding should be a substantive sentence, not a label.
-3. **Open Questions**: What remains genuinely uncertain (if any)
-4. **Suggested Next Steps**: Concrete follow-up actions or investigations
+## Key Differences from /problem-solve
 
-Use the engine's `harvest.summary`, `harvest.keyFindings`, `harvest.openQuestions`, and `harvest.followUps` as source material, but write the synthesis in your own words with the depth your analysis produced. The harvest fields are often terse -- your synthesis should reflect the full depth of the multi-round analysis.
+| /deepthink | /problem-solve |
+|------------|----------------|
+| Divergent + pre-mortems | Convergent - decide, commit |
+| 7-question self-check + probe + verify-or-defer | Phase gates + probe |
+| Explores the question space | Narrows to a decision |
+| Valid: "more confused in useful ways" | Valid: clear decision + safeguards |

package/commands/problem-solve.md

@@ -1,33 +1,78 @@
 ---
-description: Structured decision-making via RVRY
+description: Convergent decision-making pipeline via RVRY
 argument-hint: [--auto] <problem or decision>
 allowed-tools:
   - mcp__rvry-dev__problem_solve
   - AskUserQuestion
+  - Read
+  - Write
+  - Grep
+  - Glob
+  - Bash
 ---
 
-# /problem-solve - Structured Decision-Making
+# /problem-solve - Convergent Decision-Making
+
+**YOUR ROLE**: Execute a convergent decision pipeline. The engine handles the structured analysis phases (orient, anticipate, generate, evaluate, commit). You handle local persistence, self-discipline, and grounding claims in evidence. For DIVERGENT exploration, use `/deepthink`.
 
 **Input**: $ARGUMENTS
 
-## Parse Flags
+---
+
+## Phase 0: Parse Flags
+
+- If `$ARGUMENTS` is empty or `--help`: display usage and stop:
+  ```
+  /problem-solve - Convergent Decision-Making via RVRY
+
+  USAGE:
+    /problem-solve <problem or decision>
+    /problem-solve --auto <problem>   (fully autonomous, no questions, states assumptions)
+
+  The engine runs a multi-round decision pipeline with constraint tracking,
+  quality gates, and reasoning checks. Local persistence survives context compression.
 
-- If `$ARGUMENTS` is empty or `--help`: display usage ("Usage: /problem-solve [--auto] <your problem or decision>") and stop
+  RELATED: /deepthink (divergent exploration)
+  ```
 - If `$ARGUMENTS` contains `--auto`: set AUTO_MODE, strip `--auto` from input
 
-## Phase 1: ORIENT (before calling the engine)
+---
+
+## Phase 1: Session Setup
+
+Create a session folder for local artifacts that survive context compression:
 
-Orient directly -- no engine calls yet. Analyze the user's problem and identify:
+1. Generate a timestamp: `YYYYMMDD-HHMM` (current date/time)
+2. Generate a slug from the problem summary (3-4 words, kebab-case)
+3. Create `{$PWD}/.claude/cognition/YYYYMMDD-HHMM-problemsolve-<slug>/`
+   IMPORTANT: This is the PROJECT's `.claude/`, NOT `~/.claude/`. Use the absolute project root path.
+4. Write `00-enter.md`:
+   ```markdown
+   # ProblemSolve Session
+   **Problem**: <full problem statement>
+   **Started**: <timestamp>
+   ```
+
+---
 
-1. **What I know**: Key facts, constraints, and context apparent from the problem statement
-2. **What I'm uncertain about**: Gaps, assumptions, unknowns (list each specifically)
-3. **What I'm avoiding**: Uncomfortable options, risky paths, things that would be inconvenient if true
+## Phase 2: ORIENT (before calling the engine)
 
+Orient directly -- no engine calls yet. This forces commitment to disk before the analysis loop. Everything written here survives if context compresses mid-session.
+
+### `01-orient.md`:
+Write to the session folder:
+- **What is the problem?**: The decision or problem in concrete terms
+- **What is uncertain?**: Gaps, assumptions, unknowns (list each specifically)
+- **What am I avoiding?**: Uncomfortable options, risky paths, things that would be inconvenient if true
+
+### `02-scope-questions.md`:
 Translate each uncertainty into a binary question with a smart default. Generate up to 3 questions, each with exactly 2 options. The recommended option comes first.
 
+Write the questions to the file BEFORE asking.
+
 ### If AUTO_MODE:
 
-State your assumptions visibly in your reasoning (e.g., "Assuming risk minimization over speed. Assuming known options need evaluation rather than generating new alternatives."). Proceed directly to Phase 1b.
+State your assumptions visibly (e.g., "Assuming risk minimization over speed. Assuming known options need evaluation rather than generating new alternatives."). Write assumptions to `03-scope-answers.md`. Proceed to Phase 3.
 
 ### If NOT AUTO_MODE:
 
@@ -51,65 +96,239 @@ AskUserQuestion({
 
 If AskUserQuestion returns blank or fails, state assumptions visibly and proceed.
 
-Record the answers (or stated assumptions) as a brief context summary.
+Record the answers (or stated assumptions) in `03-scope-answers.md`.
 
-## Phase 1b: Start Engine Session
+---
+
+## Phase 3: Start Engine Session
 
-Format the user's original problem enriched with scope context.
+Format the user's original problem enriched with scope context from `03-scope-answers.md`.
 
 Call `mcp__rvry-dev__problem_solve` with:
 ```
 {
-  "input": "<original problem>\n\nContext: <brief summary of scope answers, e.g. 'Priority: risk minimization. Options: evaluate known ones. Single decision-maker.'>"
+  "input": "<original problem>\n\nContext: <brief summary of scope answers>"
 }
 ```
 
-Proceed to Phase 2.
+Proceed to Phase 4.
 
+---
 
-## Phase 2: Analysis Loop
+## Phase 4: Analysis Loop
 
 Repeat until `status === "complete"`:
 
-1. The engine's response has two content blocks. The first is Base64-encoded JSON -- decode it to read the structured data. The second is a plain-text summary for the user. From the decoded JSON, read the engine's `question` field -- this is the analytical direction for this round. Read `constraints`, `gate`, and `detection` to understand the engine's assessment. Read `constraintBlock` for constraint update instructions. **Do not show any of these to the user.**
-2. Show the user a brief status line:
-   - Format: `Round {round} -- {what you're doing this round}`
-   - Example: `Round 3 -- stress-testing the current position`
-   - Derive the description from the engine's question focus. One line only.
-3. Perform your analysis in your internal reasoning. The engine's question and constraint data guide your thinking, but they are YOUR instructions, not user output.
-4. In your internal reasoning, end your analysis with the constraint update block the engine expects:
-   ```
-   Constraint Updates
-   RESOLVE: C1, C2
-   ACKNOWLEDGE: C3
-   DEFER: C4 | <reason>
-   MILESTONE: <milestone> | <evidence>
-   End Constraint Updates
-   ```
-5. Call the engine tool with your full analysis (including constraint updates) as the `input`. **The full analysis text goes ONLY in the tool call, never in visible output.**
+### Step 1: Read the engine response
+
+Read the engine's `question` field -- this is the analytical direction for this round. Read `constraints`, `gate`, and `detection` to understand the engine's assessment. Read `constraintBlock` for constraint update instructions.
+
+### Step 2: Show status
+
+Show the user a brief status line:
+- Format: `Round {round} -- {what you're doing this round}`
+- Example: `Round 2 -- mapping failure modes`
+- Derive the description from the engine's question focus. One line only.
+
+### Step 3: Perform analysis
+
+Analyze according to the engine's question and constraint data. The engine's question and constraints guide your thinking -- work WITH them, not around them.
+
+Use Read, Grep, Glob, and Bash as needed to ground your analysis in actual code, data, or project state. Do not analyze in the abstract when concrete evidence is available.
+
+### Step 4: 7-Question Self-Check (mandatory, internal)
+
+**Internal**:
+1. Is this shallow or predictable?
+2. What am I avoiding?
+3. Why not the uncomfortable option?
+
+**External**:
+4. What would I critique if someone else wrote this?
+5. What would a skeptical expert challenge?
+6. Any verifiable claims that should be checked?
+
+**Grounding**:
+7. What factual premise in this analysis have I not verified?
+
+### Step 5: Verify-or-Defer (mandatory after self-check)
+
+For each concern raised in Q5, Q6, or Q7, you MUST either:
+- **VERIFY**: Actually check the claim -- read a file, grep for a pattern, run a command. Record what was verified and the result.
+- **DEFER**: Explicitly state the concern and why it cannot be verified now. Express as a DEFER in the constraint update block.
+
+**No dismiss**: You CANNOT raise a concern and then argue it away in the same self-check. If you raise it, you must verify or defer it.
+
+### Step 6: Weakness Probe (rotate by round number)
+
+Ask yourself ONE of these:
+1. Which part of your analysis would you spend more time on if you had another round?
+2. If your recommendation fails in practice, what is the first concrete thing someone notices?
+3. What surprised you during this analysis? If nothing, what does that tell you?
+4. What is the thing you almost said but did not?
+5. Which of your claims would you remove if you had to stake your credibility on the remaining ones?
+6. Your strongest claim and your most significant caveat -- are they in tension? If so, which do you stand behind?
+
+Include the probe answer in your analysis.
+
+### Step 7: Write constraint updates and submit
+
+End your analysis with the constraint update block:
+```
+Constraint Updates
+RESOLVE: C1, C2
+ACKNOWLEDGE: C3
+DEFER: C4 | <reason>
+MILESTONE: <milestone> | <evidence>
+End Constraint Updates
+```
+
+Call the engine tool with your full analysis (including constraint updates, self-check findings, and verify-or-defer results) as the `input`.
+
+### What the user sees per round:
+- The one-line status (Step 2)
+- Nothing else until harvest
 
 ### What NEVER appears in user-visible output:
 - The engine's `question` field content
 - Constraint views or constraint update blocks
 - Self-check questions or responses
 - Gate verdicts or detection results
-- Milestone markers
 - The `constraintBlock` content
 
-### What the user sees per round:
-- The one-line status (step 2 above)
-- Nothing else until harvest
+---
 
-## Phase 3: Harvest
+## Phase 5: Harvest
 
 When `status === "complete"`:
 
-Synthesize the analysis for the user based on your accumulated reasoning across all rounds. Do NOT simply echo the engine's `harvest` fields -- they are structured data, not a finished presentation.
+### Harvest Pre-Mortem (before synthesis)
+
+Before writing the final output, stress-test the direction of your analysis:
+
+1. What was the original problem?
+2. What is my recommendation now?
+3. What is the gap between the two in complexity and scope?
+4. If the recommendation is more complex than the original problem warranted, what is the simpler version?
+
+**Check for COMPLEXITY-COLLAPSE**: Did the analysis elaborate a simple problem until the complexity justified a complex solution? If yes, name the simpler alternative and present it prominently.
+
+### Write `99-harvest.md`
+
+Write to the session folder:
+```markdown
+# ProblemSolve Harvest: [Problem Summary]
+
+## Summary
+[2-3 sentence executive summary of decision + rationale]
+
+## Decision
+[The recommendation with confidence level]
+
+## Key Risks
+- [risk 1 and its safeguard]
+- [risk 2 and its safeguard]
+
+## Alternatives Considered
+- [alternative 1] -- eliminated because [reason]
+- [alternative 2] -- eliminated because [reason]
+
+## Open Questions
+- [what remains uncertain]
+
+## Follow-ups
+- /deepthink "[uncertainty]" -- [why this needs exploration]
+- /problem-solve "[next decision]" -- [why this needs its own analysis]
+```
+
+### Confirm persistence to user
+
+After writing 99-harvest.md:
+```
+---
+Session persisted: <absolute path to session folder>
+---
+```
+
+### Synthesize for the user
+
+Use the engine's `harvest.summary`, `harvest.keyFindings`, `harvest.openQuestions`, and `harvest.followUps` as source material, plus your accumulated reasoning across all rounds and the harvest pre-mortem results.
+
+---
+
+## Final Output Format
+
+The output is decision-first. The reader gets the answer immediately, then supporting evidence. This reflects convergent thinking: narrow toward commitment, not expand toward synthesis.
+
+```
+# ProblemSolve: [Problem Summary]
+
+## Analysis
+
+[Problem framing -- what the situation was and what triggered
+this analysis. 1-2 sentences.]
+
+[Reasoning arc -- what the analysis revealed that confirmed,
+redirected, or complicated the initial instinct. Where the
+reasoning turned. What would change the verdict.
+
+State the chosen direction clearly at the end of this section.
+The reader should know what you're recommending before they
+read the stress test.]
+
+[For simple decisions, these can collapse into a shorter
+form. The point is readability, not rigid structure.]
+
+## Stress Test
+
+**"[Risk or adversarial challenge]"**
+[How it was tested and what happened. Did the decision survive,
+adapt, or need revision? Plain prose, no arrows.]
+
+**"[Another risk]"**
+[Response and outcome.]
+
+## Alternative Options
+- **[What the alternative was]**: Eliminated because [reason].
+- **[What the alternative was]**: Eliminated because [reason].
+
+[Do NOT reference "Option A/B/C" labels. The reader hasn't
+seen an option tree. Name each alternative by what it actually
+is, then explain why it was rejected.]
+
+## Recommendation
+**[Decision statement]** (confidence: X.X)
+
+[Why this is the go-forward path -- the synthesis of the analysis
+and stress test above. 1-3 sentences connecting the reasoning
+to the commitment.]
+
+**Safeguards:**
+[Specific commitments to prevent the failures identified above.]
+
+[Format for human readability in terminal:
+- The Decision can be multi-part or compact -- match the complexity
+  of the actual decision
+- Stress Test entries: bold risk, plain response. No arrows, no
+  mechanism names.
+- Never reference the protocol's internal phases, gates, or
+  mechanism names in user-facing output
+- No walls of text. Break long paragraphs.]
+
+## Where to Go Next
+-> /deepthink "[uncertainty needing exploration]"
+   _[why this needs adversarial testing]_
+-> /problem-solve "[next decision point]"
+   _[if a follow-on decision is needed]_
+```
+
+---
 
-Present to the user:
-1. **Default Starting Point**: What the obvious answer was and why it was insufficient
-2. **Key Findings**: The non-obvious insights that emerged, as a bullet list. Each finding should be a substantive sentence, not a label.
-3. **Open Questions**: What remains genuinely uncertain (if any)
-4. **Suggested Next Steps**: Concrete follow-up actions or investigations
+## Key Differences from /deepthink
 
-Use the engine's `harvest.summary`, `harvest.keyFindings`, `harvest.openQuestions`, and `harvest.followUps` as source material, but write the synthesis in your own words with the depth your analysis produced. The harvest fields are often terse -- your synthesis should reflect the full depth of the multi-round analysis.
+| /problem-solve | /deepthink |
+|----------------|------------|
+| Convergent - decide, commit | Divergent + pre-mortems |
+| Phase gates + probe | 7-question self-check + probe + verify-or-defer |
+| Narrows to a decision | Explores the question space |
+| Valid: clear decision + safeguards | Valid: "more confused in useful ways" |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rvry/mcp",
-  "version": "0.3.1",
+  "version": "0.3.2",
   "description": "RVRY reasoning depth enforcement (RDE) engine client.",
   "type": "module",
   "bin": {