projecta-rrr 1.18.10 → 1.19.1

package/CHANGELOG.md

@@ -4,6 +4,38 @@ All notable changes to RRR will be documented in this file.
 
 Format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
+## [1.19.1] - 2026-02-11
+
+### Fixed
+
+- **Install failure** - Postinstall script referenced wrong path for `register-mcp.js` (`rrr/scripts/` instead of `scripts/`)
+
+## [1.19.0] - 2026-02-05
+
+### Added
+
+- **Auto-Capture Observation Logger** - PostToolUse hook that automatically captures file creates/deletes, test results, git commits, and decision signals to `.planning/observations-YYYY-MM-DD.jsonl` with daily rotation and 1MB limit
+- **Progressive STATE.md Disclosure** - Compact ~30 token state index loaded on session start; full STATE.md only on explicit resume (saves context budget)
+- **SessionStart Auto-Resume Hook** - Handles Claude Code's `source` field (startup/resume/compact/clear) for automatic context restoration
+- **Native Context Window Metrics** - 4-level fallback (HUD state > env var > cached file > estimation) with pressure levels integrated into drift detection
+- **Timeline-Aware Session Queries** - `since`/`until` filters for session search with ISO dates, relative words ("yesterday"), and durations ("3d", "2w")
+- **Complexity-Adaptive Routing** - `/rrr:mvp` auto-detects task complexity (SMALL/MEDIUM/LARGE) and routes to appropriate workflow depth
+- **Configurable Git Branching** - `git_branching` strategy (none/phase/milestone) in config.json with squash-on-complete option
+- **`/rrr:think` Command** - 4 structured thinking models: first-principles, inversion (pre-mortem), pareto (80/20), five-whys (root cause)
+- **TeammateTool / Hidden Swarm Embedding** - File-based team coordination mirroring Claude Code's hidden TeammateTool API with spawnTeam/write/broadcast/cleanup primitives, team-aware executor for wave parallelization, and GA migration path with transport swap
+- **Session Forking Guidance** - Documented session forking as preferred overnight method with fallback to traditional Jarvis
+
+### Changed
+
+- `/rrr:mvp` now includes complexity detection preamble before routing
+- `/rrr:execute-phase` supports team coordination for multi-plan waves
+- `/rrr:execute-plan` creates git branches when `git_branching` is configured
+- `/rrr:complete-milestone` handles branch merge and optional squash cleanup
+- `/rrr:discuss-phase` offers optional thinking model integration
+- `/rrr:overnight` uses session forking with 10-min hook timeout
+- Resume workflow uses compact-first progressive disclosure approach
+- Memory store includes context pressure signals in drift detection
+
 ## [1.18.10] - 2026-02-03
 
 ### Added

package/bin/install.js

@@ -1412,6 +1412,27 @@ function install(isGlobal) {
       });
       console.log(`  ${green}✓${reset} Configured cache stats hook`);
     }
+
+    // Configure SessionStart hook for auto-resume context
+    const sessionStartCommand = isGlobal
+      ? '$HOME/.claude/hooks/rrr-session-start.sh'
+      : `${localDirName}/hooks/rrr-session-start.sh`;
+
+    const hasSessionStartHook = settings.hooks.SessionStart.some(entry =>
+      entry.hooks && entry.hooks.some(h => h.command && h.command.includes('rrr-session-start'))
+    );
+
+    if (!hasSessionStartHook && hookFileExists(claudeDir, 'rrr-session-start.sh')) {
+      settings.hooks.SessionStart.push({
+        hooks: [
+          {
+            type: 'command',
+            command: sessionStartCommand
+          }
+        ]
+      });
+      console.log(`  ${green}✓${reset} Configured auto-resume hook (SessionStart)`);
+    }
   }
 
   // PATCH-01: Configure PostToolUse hook for drift detection
@@ -1447,6 +1468,37 @@ function install(isGlobal) {
     }
   }
 
+  // Configure PostToolUse hook for observation logger (auto-capture key events)
+  const observationLoggerCommand = isGlobal
+    ? '$HOME/.claude/hooks/rrr-observation-logger.sh'
+    : `${localDirName}/hooks/rrr-observation-logger.sh`;
+
+  if (bashStatus.available && hookFileExists(claudeDir, 'rrr-observation-logger.sh')) {
+    if (!settings.hooks) {
+      settings.hooks = {};
+    }
+    if (!settings.hooks.PostToolUse) {
+      settings.hooks.PostToolUse = [];
+    }
+
+    const hasObservationHook = settings.hooks.PostToolUse.some(entry =>
+      entry.hooks && entry.hooks.some(h => h.command && h.command.includes('rrr-observation-logger'))
+    );
+
+    if (!hasObservationHook) {
+      settings.hooks.PostToolUse.push({
+        matcher: '*',
+        hooks: [
+          {
+            type: 'command',
+            command: observationLoggerCommand
+          }
+        ]
+      });
+      console.log(`  ${green}✓${reset} Configured observation logger hook (PostToolUse)`);
+    }
+  }
+
   // Configure UserPromptSubmit hook for intent classification (smart drift detection)
   const classifyIntentCommand = isGlobal
     ? '$HOME/.claude/hooks/rrr-classify-intent.sh'

package/commands/rrr/complete-milestone.md

@@ -100,14 +100,55 @@ Output: Milestone archived (roadmap + requirements), PROJECT.md evolved, git tag
    - Add "Next Milestone Goals" section
    - Archive previous content in `<details>` (if v1.1+)
 
-7. **Commit and tag:**
+7. **Merge branches (if git branching was used):**
+
+   Check config.json for `git_branching` setting:
+
+   ```bash
+   GIT_BRANCHING=$(node -e "try { const c = require('./.planning/config.json'); console.log(c.git_branching || 'none'); } catch(e) { console.log('none'); }" 2>/dev/null)
+   SQUASH=$(node -e "try { const c = require('./.planning/config.json'); console.log(c.squash_on_complete ? 'true' : 'false'); } catch(e) { console.log('false'); }" 2>/dev/null)
+   ```
+
+   **If `git_branching` is `phase` or `milestone`:**
+
+   a. List all RRR branches:
+   ```bash
+   git branch --list 'rrr/*'
+   ```
+
+   b. For each RRR branch:
+   - Ensure we are on the main/default branch
+   - Merge or squash-merge based on `squash_on_complete`:
+     ```bash
+     DEFAULT_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@' || echo "main")
+     git checkout "$DEFAULT_BRANCH"
+
+     if [ "$SQUASH" = "true" ]; then
+       git merge --squash "$BRANCH_NAME"
+       git commit -m "feat: merge ${BRANCH_NAME} (squashed)"
+     else
+       git merge "$BRANCH_NAME" --no-edit
+     fi
+     ```
+
+   c. Clean up merged branches:
+   ```bash
+   git branch -d "$BRANCH_NAME"
+   echo "[RRR] Merged and deleted branch: $BRANCH_NAME"
+   ```
+
+   d. Present summary of merged branches to user for confirmation.
+
+   **If `none`:** Skip this step entirely.
+
+8. **Commit and tag:**
 
    - Stage: MILESTONES.md, PROJECT.md, ROADMAP.md, STATE.md, archive files
    - Commit: `chore: archive v{{version}} milestone`
    - Tag: `git tag -a v{{version}} -m "[milestone summary]"`
    - Ask about pushing tag
 
-8. **Offer next steps:**
+9. **Offer next steps:**
    - `/rrr:discuss-milestone` — thinking partner, creates context file
    - Then `/rrr:new-milestone` — update PROJECT.md with new goals
 

package/commands/rrr/discuss-phase.md

@@ -62,6 +62,39 @@ Phase number: $ARGUMENTS (required)
 - Scope expansion (roadmap defines scope)
 </process>
 
+<thinking_models>
+**Optional: Apply thinking model during discussion**
+
+After step 5 (deep-dive areas) and before step 6 (write CONTEXT.md), offer structured analysis if the discussion revealed complex architectural decisions:
+
+```
+---
+
+Noticed some meaty decisions in this discussion. Want to apply a thinking model?
+
+| Model | Good For |
+|-------|----------|
+| `/rrr:think first-principles` | Strip assumptions, rebuild approach |
+| `/rrr:think inversion` | Pre-mortem: what could go wrong? |
+| `/rrr:think pareto` | Cut scope to the essential 20% |
+| `/rrr:think five-whys` | Dig into root cause of a design question |
+
+Or skip and proceed to CONTEXT.md.
+
+---
+```
+
+**When to offer:**
+- At least one gray area involved architecture or technology choice
+- Discussion surfaced significant trade-offs
+- User expressed uncertainty about approach
+
+**When to skip (just proceed):**
+- All gray areas were UI/UX/content (not architectural)
+- Discussion was quick and clear
+- User has strong opinions already
+</thinking_models>
+
 <success_criteria>
 - Gray areas identified through intelligent analysis
 - User chose which areas to discuss

package/commands/rrr/execute-phase.md

@@ -100,6 +100,50 @@ Phase: $ARGUMENTS
    **If script not found:**
    - Log warning, continue without preflight
 
+1.7. **Git branching (if configured)**
+
+   Check config.json for `git_branching` setting:
+
+   ```bash
+   GIT_BRANCHING=$(node -e "try { const c = require('./.planning/config.json'); console.log(c.git_branching || 'none'); } catch(e) { console.log('none'); }" 2>/dev/null)
+   ```
+
+   **If `git_branching` is `phase`:**
+   - Create and checkout branch for this phase:
+   ```bash
+   PHASE_NUM=$ARGUMENTS
+   PHASE_SLUG=$(basename "$PHASE_DIR" | sed "s/^${PHASE_NUM}-//")
+   BRANCH_NAME="rrr/phase-${PHASE_NUM}-${PHASE_SLUG}"
+
+   if ! git rev-parse --verify "$BRANCH_NAME" >/dev/null 2>&1; then
+     git checkout -b "$BRANCH_NAME"
+     echo "[RRR] Created branch: $BRANCH_NAME"
+   else
+     git checkout "$BRANCH_NAME" 2>/dev/null || echo "[RRR] Already on branch: $BRANCH_NAME"
+   fi
+   ```
+
+   **If `git_branching` is `milestone`:**
+   - Branch is created at milestone level (by execute-plan or new-milestone)
+   - Ensure we are on the milestone branch if it exists
+
+   **If `none` (default):** No branching, continue on current branch.
+
+1.8. **Team coordination (if configured)**
+
+   Check config.json for `team_coordination` setting:
+
+   ```bash
+   TEAM_COORD=$(node -e "try { const c = require('./.planning/config.json'); console.log(c.team_coordination !== false ? 'true' : 'false'); } catch(e) { console.log('true'); }" 2>/dev/null)
+   ```
+
+   **If `true` (default):** Team coordination enabled for multi-plan waves.
+   - Load team libraries: `rrr/lib/team-coord.js` and `rrr/lib/team-executor.js`
+   - Team coordination only activates for waves with 2+ plans
+   - Single-plan waves always skip team coordination (zero overhead)
+
+   **If `false`:** Team coordination disabled. Execute with original hub-and-spoke pattern.
+
 2. **Discover plans**
    - List all *-PLAN.md files in phase directory
    - Check which have *-SUMMARY.md (already complete)
@@ -133,11 +177,69 @@ Phase: $ARGUMENTS
    - If user chooses to skip: Mark plan as skipped, continue to next
    - If user chooses to continue: Proceed with execution
 
-   **5b. Execute plans:**
+   **5b. Team setup (if multi-plan wave and team_coordination enabled):**
+
+   For waves with 2+ plans when `TEAM_COORD=true`:
+
+   ```javascript
+   // Using rrr/lib/team-executor.js
+   const team = prepareWaveTeam(phaseNum, waveNum, planIds, planPaths, projectRoot);
+   // team is null for single-plan waves (zero overhead)
+   ```
+
+   This creates `.planning/teams/phase-{N}-wave-{W}/` with:
+   - `config.json` — team members, status
+   - `messages/{agent-id}/` — per-agent inbox dirs
+   - `messages/broadcast/` — group messages
+   - `state.json` — team lifecycle state
+
+   Shared file detection: parse each plan's `## Files Modified` section,
+   find files appearing in 2+ plans. These require coordination.
+
+   **5c. Execute plans:**
    - For each plan, inject `<skills>` block into executor prompt
+   - If team exists (multi-plan wave): inject `<team_context>` block with team name, agent ID, peer IDs, shared files
    - Spawn `rrr-executor` for each plan in wave (parallel Task calls)
    - Wait for completion (Task blocks)
-   - Verify SUMMARYs created
+
+   **5d. Post-wave team analysis (if team exists):**
+
+   After all executors in wave complete:
+
+   1. **Read team messages** (for logging/debugging):
+      ```javascript
+      const { messages } = collectTeamMessages(team);
+      // Log: "[RRR] Wave {W}: {N} team messages exchanged"
+      ```
+
+   2. **Detect file conflicts** (same file modified by 2+ agents):
+      ```javascript
+      const conflicts = detectFileConflicts(team, summaryPaths);
+      ```
+
+   3. **If conflicts detected:** Present conflict resolution UI:
+      ```
+      ── FILE CONFLICT DETECTED ──────────────────────────
+
+      File: {file_path}
+      Modified by: {agent-1}, {agent-2}
+
+      {agent-1} changes: {summary from team messages}
+      {agent-2} changes: {summary from team messages}
+
+      ────────────────────────────────────────────────────
+      > Select: merge-both / keep-{agent-1} / keep-{agent-2} / manual
+      ────────────────────────────────────────────────────
+      ```
+
+      Use AskUserQuestion for conflict resolution if any non-expected conflicts exist.
+
+   4. **Cleanup team:**
+      ```javascript
+      cleanupWaveTeam(team); // Archives to .planning/teams/archived/
+      ```
+
+   5. **Verify SUMMARYs created**
    - Proceed to next wave
 
 6. **Aggregate results**
@@ -374,22 +476,56 @@ After user runs `/rrr:plan-phase {Z} --gaps`:
 </offer_next>
 
 <wave_execution>
-**Parallel spawning:**
+**Parallel spawning with team coordination:**
+
+**Step 1: Prepare team (multi-plan waves only)**
+
+For waves with 2+ plans when `team_coordination` is enabled:
+
+```javascript
+// From rrr/lib/team-executor.js
+const team = prepareWaveTeam(phaseNum, waveNum, planIds, planPaths, projectRoot);
+// Returns null for single-plan waves (zero overhead)
+
+// Build team context for each executor
+const teamBlock = buildTeamPromptBlock(team, planId);
+// Returns '' for null teams
+```
+
+**Step 2: Spawn executors**
 
 Spawn all plans in a wave with a single message containing multiple Task calls.
-Include the `<skills>` block loaded in step 4 for each plan:
+Include the `<skills>` block loaded in step 4 and `<team_context>` block for each plan:
 
 ```
-Task(prompt="Execute plan at {plan_01_path}\n\n{skills_01_block}\n\nPlan: @{plan_01_path}\nProject state: @.planning/STATE.md", subagent_type="rrr-executor")
-Task(prompt="Execute plan at {plan_02_path}\n\n{skills_02_block}\n\nPlan: @{plan_02_path}\nProject state: @.planning/STATE.md", subagent_type="rrr-executor")
-Task(prompt="Execute plan at {plan_03_path}\n\n{skills_03_block}\n\nPlan: @{plan_03_path}\nProject state: @.planning/STATE.md", subagent_type="rrr-executor")
+Task(prompt="Execute plan at {plan_01_path}\n\n{skills_01_block}\n\n{team_context_01}\n\nPlan: @{plan_01_path}\nProject state: @.planning/STATE.md", subagent_type="rrr-executor")
+Task(prompt="Execute plan at {plan_02_path}\n\n{skills_02_block}\n\n{team_context_02}\n\nPlan: @{plan_02_path}\nProject state: @.planning/STATE.md", subagent_type="rrr-executor")
+Task(prompt="Execute plan at {plan_03_path}\n\n{skills_03_block}\n\n{team_context_03}\n\nPlan: @{plan_03_path}\nProject state: @.planning/STATE.md", subagent_type="rrr-executor")
 ```
 
-Where `{skills_XX_block}` is the `<skills>` content containing skill SKILL.md files specific to that plan.
+Where:
+- `{skills_XX_block}` is the `<skills>` content containing skill SKILL.md files specific to that plan
+- `{team_context_XX}` is the `<team_context>` block from `buildTeamPromptBlock()` (empty for single-plan waves)
+
+All executors run in parallel. Task tool blocks until all complete.
+
+**Step 3: Post-wave analysis (multi-plan waves only)**
 
-All three run in parallel. Task tool blocks until all complete.
+```javascript
+// Collect team messages for logging
+const { messages } = collectTeamMessages(team);
+// Log: "[RRR] Wave {W}: {N} team messages exchanged"
+
+// Check for file conflicts
+const conflicts = detectFileConflicts(team, summaryPaths);
+// If conflicts: present resolution UI via AskUserQuestion
+
+// Archive team
+cleanupWaveTeam(team);
+```
 
 **No polling.** No background agents. No TaskOutput loops.
+**Single-plan waves:** Skip all team logic. Zero overhead. Same as before.
 </wave_execution>
 
 <checkpoint_handling>

package/commands/rrr/execute-plan.md

@@ -168,6 +168,50 @@ Plan path: $ARGUMENTS
    - "Review plan first" → display plan summary, ask again
    - "Cancel" → exit without executing
 
+0.7. **Git branching (if configured)**
+
+   Check config.json for `git_branching` setting:
+
+   ```bash
+   GIT_BRANCHING=$(node -e "try { const c = require('./.planning/config.json'); console.log(c.git_branching || 'none'); } catch(e) { console.log('none'); }" 2>/dev/null)
+   ```
+
+   **If `git_branching` is `phase`:**
+   - Extract phase number and slug from plan path
+   - Check if branch `rrr/phase-{N}-{slug}` already exists
+   - If not: create and checkout the branch
+   ```bash
+   PHASE_NUM=$(basename "$(dirname "$ARGUMENTS")" | cut -d'-' -f1)
+   PHASE_SLUG=$(basename "$(dirname "$ARGUMENTS")" | sed "s/^${PHASE_NUM}-//")
+   BRANCH_NAME="rrr/phase-${PHASE_NUM}-${PHASE_SLUG}"
+
+   if ! git rev-parse --verify "$BRANCH_NAME" >/dev/null 2>&1; then
+     git checkout -b "$BRANCH_NAME"
+     echo "[RRR] Created branch: $BRANCH_NAME"
+   else
+     git checkout "$BRANCH_NAME" 2>/dev/null || echo "[RRR] Already on branch: $BRANCH_NAME"
+   fi
+   ```
+
+   **If `git_branching` is `milestone`:**
+   - Extract milestone version from ROADMAP.md
+   - Check if branch `rrr/{version}-{slug}` already exists
+   - If not: create and checkout the branch
+   ```bash
+   MILESTONE_VER=$(grep -E "^## Current Milestone:" .planning/ROADMAP.md 2>/dev/null | sed 's/.*: *\(v[0-9.]*\).*/\1/' || echo "vX.X")
+   PHASE_SLUG=$(basename "$(dirname "$ARGUMENTS")" | sed 's/^[0-9]*-//')
+   BRANCH_NAME="rrr/${MILESTONE_VER}-${PHASE_SLUG}"
+
+   if ! git rev-parse --verify "$BRANCH_NAME" >/dev/null 2>&1; then
+     git checkout -b "$BRANCH_NAME"
+     echo "[RRR] Created branch: $BRANCH_NAME"
+   else
+     git checkout "$BRANCH_NAME" 2>/dev/null || echo "[RRR] Already on branch: $BRANCH_NAME"
+   fi
+   ```
+
+   **If `none` (default):** No branching, continue on current branch.
+
 1. **Validate plan exists**
    - Confirm file at $ARGUMENTS exists
    - Error if not found: "Plan not found: {path}"

package/commands/rrr/mvp.md

@@ -1,17 +1,67 @@
 ---
 name: rrr:mvp
-description: One-command router - detects project state and tells you exactly what to run next
+description: One-command router - detects project state, estimates complexity, and tells you exactly what to run next
 ---
 
 <objective>
-Detect project state and provide the exact next command to run.
+Detect project state, estimate task complexity, and provide the exact next command to run.
 
 Do NOT execute any commands yourself. Just detect and route.
 </objective>
 
+<complexity_routing>
+**For initialized projects, auto-select workflow depth based on task scope:**
+
+Before routing to `/rrr:progress`, analyze the user's request (if they described a task) using these heuristics:
+
+| Signal | Estimated Files | Route |
+|--------|----------------|-------|
+| 1-2 files, <50 lines changed | 1-2 | Direct edit (skip planning) |
+| 3-5 files, single concern | 3-5 | `/rrr:plan-phase` (lightweight) |
+| 6+ files or cross-cutting | 6+ | `/rrr:discuss-phase` then full cycle |
+| Bug report / error trace | varies | `/rrr:debug` |
+| "what's next" / no specific ask | 0 | `/rrr:progress` |
+
+**Detection heuristic (applied to user's request text):**
+- Parse for file count signals ("update the config" = 1 file, "refactor auth system" = many)
+- Single-file keywords: "fix typo", "update version", "change the title", "edit the"
+- Multi-file keywords: "component", "endpoint", "page", "feature", "add a new"
+- Large-scope keywords: "system", "module", "refactor", "migrate", "overhaul", "across"
+- Bug keywords: "broken", "error", "crash", "not working", "fails"
+- Progress keywords: "what's next", "status", "where was I"
+
+**Uses `rrr/lib/scope-classifier.js` — `estimateComplexity(text)` for classification.**
+</complexity_routing>
+
 <behavior>
 1. **Check for existing RRR initialization:**
    - If `.planning/STATE.md` exists → project is already initialized
+
+   **1a. If user described a specific task (not just running `/rrr:mvp`):**
+   Apply complexity routing to their request:
+
+   ```
+   ## RRR Project State
+
+   **Status:** Initialized
+   **Task complexity:** [SMALL | MEDIUM | LARGE | DEBUG | PROGRESS]
+   **Estimated scope:** [N] file(s)
+
+   **Next command:** `/rrr:...`
+
+   [Explanation based on complexity level:]
+   - SMALL (1-2 files): "This looks like a small change. You can edit directly — no planning needed."
+   - MEDIUM (3-5 files): "This is a focused feature. Quick planning will keep it clean."
+   - LARGE (6+): "This is cross-cutting work. Discussing the approach first will save time."
+   - DEBUG: "This looks like a bug. Let's diagnose it."
+   - PROGRESS: [show progress]
+
+   ---
+
+   Want me to run it now?
+   ```
+
+   **1b. If no specific task described (just `/rrr:mvp` with no context):**
    - Route: Tell user to run `/rrr:progress`
    - Offer: "Want me to run `/rrr:progress` for you now?"
 

package/commands/rrr/overnight.md

@@ -119,8 +119,76 @@ The script will detect if you run it inside Claude Code and prompt to confirm.
 ```
 </behavior>
 
+<session_forking>
+## Session Forking (Claude Code v2.1+)
+
+**When available**, session forking is the preferred method for overnight runs:
+
+### Detection
+
+Check if session forking is available:
+```bash
+# Session forking is available if Claude Code >= 2.1
+claude --version 2>/dev/null | grep -E "^[2-9]\.[1-9]" && echo "Session forking available"
+```
+
+### How to use
+
+Instead of running Jarvis in a new terminal, fork the current session:
+
+```bash
+# Fork current session for overnight execution
+# The forked session inherits all context from the parent
+claude session fork --name "jarvis-overnight-$(date +%Y%m%d)"
+```
+
+**Benefits of session forking over new terminal:**
+- Forked session inherits parent context (STATE.md loaded, codebase mapped)
+- No cold-start penalty for context loading
+- Parent session can resume independently
+- Forked session can be monitored: `claude session list`
+
+### Fork detection (for hooks)
+
+If a session was forked, the hooks should detect it and load parent context:
+```bash
+# Check if this is a forked session
+if [ -n "$CLAUDE_PARENT_SESSION" ]; then
+  echo "[RRR] Forked session detected. Loading parent context..."
+  # Parent context is automatically available via fork
+fi
+```
+
+### Fallback
+
+If session forking is not available (Claude Code < 2.1), use the traditional Jarvis approach:
+- Open separate terminal
+- Run `bash scripts/jarvis.sh`
+</session_forking>
+
+<extended_timeout>
+## Extended Hook Timeout (Claude Code v2.1+)
+
+Claude Code v2.1 increased the hook timeout from 60 seconds to 10 minutes.
+
+**Impact on overnight preflight:**
+- Jarvis preflight can now run comprehensive checks without timeout risk
+- Previously constrained to lightweight checks (file existence, quick stats)
+- Now can include: full test suite smoke test, dependency audit, git integrity check
+
+**Recommended preflight additions (when 10-min timeout available):**
+```bash
+# Extended preflight checks (only if timeout >= 600s)
+npm test --bail 2>/dev/null          # Quick smoke test
+npm audit --audit-level=high 2>/dev/null  # Security audit
+git fsck --no-dangling 2>/dev/null   # Git integrity
+```
+
+These checks are skipped automatically if the hook detects the 60s timeout constraint.
+</extended_timeout>
+
 <constraints>
 - Do NOT run jarvis.sh from this command
 - Only provide guidance and instructions
-- Always recommend running in a separate terminal
+- Always recommend running in a separate terminal (or session fork if available)
 </constraints>

package/commands/rrr/think.md

@@ -0,0 +1,94 @@
+---
+name: rrr:think
+description: Apply structured thinking models for architecture decisions, risk assessment, scope cuts, and root cause analysis
+argument-hint: "<model> [context]"
+allowed-tools: [Read, Glob, Grep, Bash, AskUserQuestion]
+---
+
+<objective>
+Apply a structured decision framework to analyze a problem, decision, or design question.
+
+Available models:
+- `first-principles` -- Break down to fundamentals, rebuild. For architecture decisions.
+- `inversion` -- "What would make this fail?" For risk assessment.
+- `pareto` -- What 20% of work delivers 80% of value? For scope cuts.
+- `five-whys` -- Chain of "why?" to find root cause. For debugging and design decisions.
+
+Output: Structured analysis following the selected model's framework.
+</objective>
+
+<behavior>
+
+## 1. Parse arguments
+
+Extract model name from $ARGUMENTS. If no model specified, present selector:
+
+```
+## /rrr:think -- Structured Decision Frameworks
+
+Select a thinking model:
+
+| Model | Best For | Command |
+|-------|----------|---------|
+| First Principles | Architecture decisions, "how should we build this?" | `/rrr:think first-principles` |
+| Inversion | Risk assessment, "what could go wrong?" | `/rrr:think inversion` |
+| Pareto (80/20) | Scope cuts, "what's the minimum viable work?" | `/rrr:think pareto` |
+| 5 Whys | Root cause analysis, "why does this keep happening?" | `/rrr:think five-whys` |
+
+Provide context after the model name:
+`/rrr:think inversion should we use JWT or sessions for auth?`
+```
+
+## 2. Load thinking model template
+
+Load the appropriate template from `rrr/templates/thinking-models/{model}.md`.
+
+## 3. Gather context
+
+If context was provided in $ARGUMENTS, use it directly.
+
+If no context provided, ask:
+```
+What problem, decision, or question should we analyze?
+
+Provide as much context as you have -- what you're building, constraints, options you're considering.
+```
+
+Also load relevant project context:
+- @.planning/STATE.md (current position)
+- @.planning/ROADMAP.md (if exists, for scope awareness)
+- Recent SUMMARY.md files (for established patterns/decisions)
+
+## 4. Execute thinking model
+
+Follow the template's structured steps to produce analysis.
+
+**Key rules:**
+- Stay within the model's framework (don't mix models)
+- Ground analysis in project-specific context, not generic advice
+- Reference actual code, files, and decisions where applicable
+- Produce actionable output, not abstract philosophy
+
+## 5. Present output
+
+Format analysis using the model template's output structure.
+
+End with:
+```
+---
+
+**Model used:** {model-name}
+**Next step:** {actionable recommendation}
+
+Want to apply another model to this same question? `/rrr:think {different-model}`
+```
+
+</behavior>
+
+<constraints>
+- Do NOT execute any commands or modify files
+- Analysis only -- the user decides what to do with the output
+- If the question is too vague, ask for specifics before analyzing
+- Keep output focused and actionable (not academic)
+- Maximum output: ~500 lines (keep it digestible)
+</constraints>