@hanzlaa/rcode 3.6.16 → 4.1.0

package/rihal/workflows/discuss.md

@@ -1,227 +0,0 @@
-# Workflow: rihal-discuss
-
-<purpose>
-Orchestrate a single-agent quick sync session. This is the lightweight alternative to council — one agent, one round, conversational tone, no mandatory artifact. Feels like texting one colleague, not calling a board meeting.
-</purpose>
-
-<output_format>
-Lightweight — no full banner. Open with one-line header:
-```
-◆ Spawning {agent-id}...
-```
-Agent response opens with header: `🧭 **Sadiq (صادق) — Director of Strategy:**`.
-No closure banner (discuss is lightweight). End with optional Next Up if the user should escalate: `Want to convene full council? /rihal-council <question>`.
-</output_format>
-
-<required_reading>
-@.rihal/references/output-format.md
-</required_reading>
-
-<process>
-## Step 0 — Usage check
-
-If `$ARGUMENTS` is empty or contains only `--help` or `-h`:
-- Print the usage block below
-- STOP — do not proceed to Step 1, do not read any reference files
-
-**Usage:**
-```
-/rihal-discuss [agent-name] <question>
-```
-
-**Examples:**
-```
-/rihal-discuss sadiq should I pivot this idea?
-/rihal-discuss waleed what stack should I use for a multi-tenant SaaS?
-/rihal-discuss what's the kill criterion for this project?
-/rihal-discuss fatima is this release ready to ship?
-```
-
-Only after the user provides arguments, proceed to Step 0.5.
-
-## Step 0.5 — Detect strategic decisions (redirect to council)
-
-Run two checks in parallel — classifier AND panel scorer top-1. Either signal triggers the redirect.
-
-```bash
-TYPE=$(node .rihal/bin/rihal-tools.cjs classify-question "$ARGUMENTS" 2>/dev/null | grep -o '"type": *"[^"]*"' | cut -d'"' -f4)
-TOP_AGENT=$(node .rihal/bin/rihal-tools.cjs select-panel "$ARGUMENTS" --top 1 2>/dev/null | grep -o '"panel": *\["[^"]*"' | cut -d'"' -f4)
-```
-
-**Redirect to council if EITHER condition holds:**
-
-1. `question_type` is `market`, `discovery`, or `greenfield`
-2. Top-scoring agent is `mariam` or `hussain-pm` (these signal market/scope intent — better answered by a council)
-
-The classifier can mistype overloaded words like "launch", but the panel scorer uses richer keyword tables (Mariam owns dubai/uae/affiliate/launch/business). Combining both signals catches more cases.
-
-If either condition holds:
-
-```
-⚠ Strategic / market decisions benefit from multiple perspectives.
-
-/rihal-discuss is single-agent. For "should we" questions across domains, use:
-
-/rihal-council $ARGUMENTS
-```
-
-Only proceed past this step if both checks pass — question is tactical or single-domain (codebase, team, release, design) AND top agent is sadiq/waleed/fatima.
-
-After Step 0.5 confirmation, proceed to load references by Reading:
-- `.rihal/references/council-protocol.md` (agent conventions and response format)
-
-<available_agent_types>
-Use these exact `subagent_type` values when calling the Agent tool:
-
-- `rihal-sadiq` — 🧭 Sadiq (Strategy)
-- `rihal-waleed` — 🏗️ Waleed (CTO)
-- `rihal-fatima` — 🛡️ Fatima (QA)
-- `rihal-mariam` — 📣 Mariam (Marketing)
-- `rihal-hussain-pm` — 📋 Hussain-PM (Product)
-</available_agent_types>
-
-## Step 1 — Initialize
-
-Call the helper binary to parse arguments and resolve the agent:
-
-```bash
-INIT_JSON=$(node .rihal/bin/rihal-tools.cjs init discuss "$ARGUMENTS")
-```
-
-Parse the JSON for:
-
-- `agent_id` — resolved agent id (may be `null` if first token wasn't a known agent)
-- `question` — the cleaned question text (with agent name stripped if it was the first token)
-- `config` — `{ user_name, project_name, language, mode }` from `.rihal/config.yaml`
-- `paths` — `{ state, planning_root, sessions_dir, ... }`
-- `question_type` — classification result
-- `installed_agents` — list of installed agent ids
-
-## Step 2 — Resolve agent
-
-**If `agent_id` is not null:** use it directly. The init command already identified the first token as a known agent.
-
-**If `agent_id` is null:** auto-route to the best agent by calling:
-
-```bash
-node .rihal/bin/rihal-tools.cjs select-panel "$QUESTION" --top 1
-```
-
-Use the first (and only) agent in the returned `panel` array.
-
-Print: `💬 Discussing with {agent display name}...`
-
-Display name mapping:
-- `sadiq` → `🧭 Sadiq (Strategy)`
-- `waleed` → `🏗️ Waleed (CTO)`
-- `fatima` → `🛡️ Fatima (QA)`
-- `mariam` → `📣 Mariam (Marketing)`
-- `hussain-pm` → `📋 Hussain-PM (Product)`
-
-## Step 3 — Optional codebase scan
-
-**Only run this if `question_type` is `codebase`, `team`, or `release`.**
-
-```bash
-test -f .rihal/config.yaml && cat .rihal/config.yaml
-test -f README.md && head -30 README.md
-git log --oneline -5 2>/dev/null
-```
-
-Produce a 3-5 line "Context" summary from the output.
-
-**Skip this step entirely** for `market`, `discovery`, `greenfield`, and `design` question types — they don't need codebase context for a quick discuss.
-
-## Step 4 — Spawn single agent
-
-Spawn the resolved agent via the Agent tool with this prompt:
-
-```
-You are being spawned for a quick Rihal discuss session.
-
-## The user's question
-{question}
-
-## Context
-{the summary from Step 2, or "No codebase context needed for this question type." if skipped}
-
-## Session metadata
-- Project: {config.project_name}
-- User: {config.user_name}
-- Communication language: {config.language}
-
-## Instructions
-This is a quick discuss session — one round, conversational tone. Be direct and concise.
-Scale your response to the substance — a simple question gets a short answer.
-Start your reply with your icon + name header.
-```
-
-Use `subagent_type` = `rihal-{agent_id}` (e.g., `rihal-sadiq`).
-
-## Step 5 — Print response verbatim
-
-Print the agent's response exactly as returned. No orchestrator note, no round labeling, no summarization. This is a conversation, not a formal session.
-
-## Success Criteria
-
-- [ ] Single agent selected and spawned (Sadiq, Waleed, Fatima, Mariam, or Hussain-PM)
-- [ ] Agent response printed verbatim to user
-- [ ] If guided mode and user saves: artifact written to `.planning/council-sessions/discuss-{date}-{slug}.md`
-- [ ] Session recorded in `state.json` via rihal-tools.cjs
-
-## Step 6 — Offer to save (guided mode only)
-
-**If `config.mode === 'guided'`:** ask the user via AskUserQuestion:
-
-```
-Save this discussion? [y/N]
-```
-
-**If yes:** write a minimal artifact to `{paths.sessions_dir}/discuss-{YYYY-MM-DD}-{slug}.md`:
-
-```markdown
-# Discuss — {short question summary}
-
-**Date:** {ISO date}
-**Agent:** {agent display name}
-**Project:** {config.project_name}
-
-## Question
-{original question}
-
-## Response
-{verbatim agent response}
-```
-
-Create `{paths.sessions_dir}` with `mkdir -p` if needed. The `{slug}` is a lowercase-hyphenated slug of the first 6 words of the question.
-
-Print: `💾 Discussion saved: .planning/council-sessions/discuss-{date}-{slug}.md`
-
-Append footer:
-```
-─── ~10K tokens · {duration}s · 1 agent ───
-```
-
-(Use estimation from `.rihal/references/response-style.md#session-cost-footer`)
-
-**If no, or `config.mode === 'yolo'`:** skip saving entirely.
-
-## Step 7 — Update state
-
-```bash
-node .rihal/bin/rihal-tools.cjs state record-session
-```
-
-This records the discuss session in `.rihal/state.json` as `last_session`.
-
-## On Error
-
-- **Empty arguments:** print usage block and stop (Step 0).
-- **Question redirects to council:** print redirect message (Step 0.5).
-- **state.json missing or corrupted:** continue without error — session artifact is mandatory, state tracking is optional.
-- **`rihal-tools.cjs` not found:** tell the user to run `npx @hanzlaa/rcode install` (or `rcode install` if installed globally).
-- **No installed agents:** print "No agents installed. Run `npx @hanzlaa/rcode install`."
-- **Agent id not in installed list:** print available agents and ask the user to pick one.
-- **Agent returns empty response:** print "Agent responded empty. Check question clarity and retry."
-
-</process>

package/rihal/workflows/do.md

@@ -1,434 +0,0 @@
-<purpose>
-Analyze freeform text from the user and route to the most appropriate Rihal command. This is a dispatcher — it never does the work itself. Match user intent to the best command, confirm the routing, and hand off.
-</purpose>
-
-<required_reading>
-@.rihal/references/auto-init-guard.md
-@.rihal/references/output-format.md
-@.rihal/references/verb-dictionary.md
-@.rihal/references/dispatch-banner.md
-Read all files referenced by the invoking prompt's execution_context before starting.
-</required_reading>
-
-<process>
-
-<step name="auto_init_check">
-Run the auto-init guard from `@.rihal/references/auto-init-guard.md` before anything else.
-If the project is not initialized, complete the inline init flow, then continue.
-</step>
-
-<step name="parse_args">
-Extract `$ARGUMENTS`, detect `--auto` flag, and check config mode:
-
-```bash
-AUTO_MODE=false
-QUESTION="$ARGUMENTS"
-if [[ "$ARGUMENTS" == *"--auto"* ]]; then
-  AUTO_MODE=true
-  QUESTION=$(echo "$ARGUMENTS" | sed 's/--auto[[:space:]]*//' | xargs)
-fi
-# Also auto-dispatch in yolo mode
-CONFIG_MODE=$(node .rihal/bin/rihal-tools.cjs config-get mode 2>/dev/null || echo "guided")
-if [[ "$CONFIG_MODE" == "yolo" ]]; then
-  AUTO_MODE=true
-fi
-```
-</step>
-
-<step name="persona_shortcut" priority="first-match">
-**Recognize `@persona CODE` shortcuts as the deterministic API surface.**
-
-Every Rihal persona file has a Capabilities table listing 2-3-letter codes (Waleed: ADR/RV/TS/FZ/KS · Hussain-PM: CP/VP/EP/CE/CS/IR/CC · Mariam: MR/ICP/GTM/POS/LP · Fatima: TS/RG/EC/RR/RP/FT · Hanzla: DS/IS/BF/RF/KA/CR · Sadiq: KC/OC/PT/MT/KS · Dalil: SC/MC/RF/TS · Khattat / Munaffidh / Bahith / Muhaqqiq similarly).
-
-Match if `$QUESTION` starts with `@<persona> <CODE>` or `@<persona>:<CODE>` — case-insensitive on persona, codes uppercase. Examples:
-
-- `@hussain CP` → dispatch to Hussain-PM with capability `CP` (Create PRD via interview)
-- `@waleed ADR` → dispatch to Waleed with capability `ADR` (write an ADR)
-- `@fatima RG` → dispatch to Fatima with capability `RG` (release-gate review)
-- `@dalil SC --topic "Sentry"` → dispatch to Dalil with capability `SC` (lightweight scan, topic phrase passed)
-
-**Persona-name aliases** (lowercased, common nicknames):
-| Alias | Resolves to | Agent file |
-|---|---|---|
-| `sadiq`, `strategy`, `director` | Sadiq | rihal-sadiq |
-| `waleed`, `cto`, `architect` | Waleed | rihal-waleed |
-| `hussain`, `hussain-pm`, `pm` | Hussain | rihal-hussain-pm |
-| `mariam`, `marketing` | Mariam | rihal-mariam |
-| `fatima`, `qa` | Fatima | rihal-fatima |
-| `hanzla`, `dev`, `engineer` | Hanzla | rihal-hanzla |
-| `dalil`, `scout`, `mapper` | Dalil | rihal-codebase-mapper |
-| `khattat`, `planner` | Khattat | rihal-planner |
-| `munaffidh`, `executor` | Munaffidh | rihal-executor |
-
-**Behavior:**
-
-1. Parse the persona alias and CODE.
-2. Read the persona's agent file at `.claude/agents/{agent-id}.md` (or `.claude/agents/{agent-id}.local.md` if it exists — local overrides take precedence).
-3. Look up the CODE in the Capabilities table. If found, the table row's "Skill / workflow" column tells you which sub-command to invoke; pass the rest of `$QUESTION` (after the shortcut) as arguments.
-4. If the CODE is not in that persona's Capabilities table, print:
-   ```
-   Persona '{persona}' has no capability '{CODE}'. Available codes:
-   {list from the persona's Capabilities table}
-   ```
-   And stop. Do not fall back to fuzzy intent matching — the user used the deterministic API, honour it.
-5. Dispatch directly via the routing banner. Skip greenfield_guard / external_data_guard / explicit_intent_check / route — the user already chose the persona AND the action. The persona itself can still refuse internally if its preconditions aren't met.
-
-**This is the deterministic API surface.** Power users (and other agents in council follow-ups) can invoke specific capabilities without re-reading triggers or risking fuzzy match. It's the cheapest way to get repeatable behaviour out of the persona system.
-
-**Edge cases:**
-
-- `@waleed` (no code) → dispatch to Waleed with no capability hint; persona uses its default workflow.
-- `@nobody CP` (unknown persona) → fail loud: list known personas, exit.
-- `CP @hussain` (code first) → reorder; do not match. The `@persona CODE` order is canonical.
-- `@hussain CP fix the auth bug` → dispatch with `CP` and pass `fix the auth bug` as argument context.
-
-If this step does NOT fire (no `@` prefix), continue to validate.
-</step>
-
-<step name="validate">
-**Check for input.**
-
-If `$QUESTION` is empty, present the main menu via AskUserQuestion:
-
-```
-What would you like to do?
-
-— Talk —
-1. Quick chat with one expert (/rihal-discuss)
-2. Convene the council (/rihal-council)
-3. Discuss an unlocked phase (/rihal-discuss-phase)
-
-— Plan & build —
-4. Plan a phase (/rihal-plan)
-5. Execute a phase (/rihal-execute)
-6. Sprint planning (/rihal-sprint-planning)
-7. Execute a sprint (/rihal-execute-sprint)
-8. Break milestone into epics & stories (/rihal-create-epics-and-stories)
-9. Implement a story (/rihal-dev-story)
-
-— Status & recovery —
-10. Check progress (/rihal-progress)
-11. Check sprint status (/rihal-sprint-status)
-12. Auto-advance to next step (/rihal-next)
-13. Debug an issue (/rihal-debug)
-14. Resume paused work (/rihal-resume-work)
-
-— Other —
-15. Add a note (/rihal-note)
-16. Something else — describe it
-0.  Cancel — exit without running anything
-```
-
-If user picks 1-15, invoke that command. If 16, capture text and continue. If 0 (or empty / Esc), print `Cancelled.` and STOP — do not fall through to project-state survey.
-</step>
-
-<step name="check_project">
-**Check if project exists + state survey.**
-
-Detect PRD / epics with glob — projects use either singular files (`.planning/prd.md`) OR per-milestone directories (`.planning/prds/v1.8.md`). Closes #377 — false 'create-prd first' redirects on multi-milestone repos.
-
-```bash
-INIT=$(node ".rihal/bin/rihal-tools.cjs" state load 2>/dev/null || echo '{"ok":false,"error":"state_load_failed"}')
-HAS_PRD=$( ( ls .planning/prd.md .planning/PRD.md .planning/prds/*.md .planning/milestones/*/PRD.md 2>/dev/null | head -1 ) && echo true || echo false)
-HAS_EPICS=$( ( ls .planning/epics.md .planning/EPICS.md .planning/epics/*.md .planning/milestones/*/EPICS.md 2>/dev/null | head -1 ) && echo true || echo false)
-PHASE_COUNT=$(node ".rihal/bin/rihal-tools.cjs" progress init 2>/dev/null | python3 -c "import sys,json;print(json.load(sys.stdin).get('phase_count',0))" 2>/dev/null || echo 0)
-HAS_PHASES=$([ "$PHASE_COUNT" -gt 0 ] && echo true || echo false)
-
-# State-aware milestone detection (#374) — used by explicit_intent_check
-ACTIVE_MILESTONE=$(grep -m1 '^## Current Milestone' .planning/PROJECT.md 2>/dev/null | sed 's/^## Current Milestone[: ]*//' | xargs)
-LAST_SHIPPED_VERSION=$(grep -m1 -oE 'v[0-9]+\.[0-9]+' .planning/MILESTONES.md 2>/dev/null | head -1)
-```
-
-These flags drive the greenfield guard AND the explicit_intent_check below. `.planning/` existing alone is not enough — we need to know whether the methodology chain has actually run (PRD → milestone → epics → phases) AND which milestone is currently open.
-</step>
-
-<step name="greenfield_guard" priority="first-match">
-**Block methodology inversion.**
-
-Some routes ASSUME upstream artifacts exist. If they don't, dispatching to them inverts the chain (the autonomous-bypass pattern that produced the interpos disaster — issue #220 + #219).
-
-Apply this guard BEFORE the routing table below:
-
-| Intent contains... | AND state shows... | Then re-route to... | Why |
-|--------------------|---------------------|----------------------|-----|
-| "draft phases", "all phases", "build all phases", "groom phases", "auto mode" + "phases" | `HAS_PRD=false` | `/rihal-create-prd` first | Phases need a PRD foundation. Without one, the autonomous flow hallucinates requirements. |
-| "execute phase", "build phase N", "run phase N" | `HAS_PHASES=false` OR SPRINT.md missing for phase N | `/rihal-plan N` first (or `/rihal-create-prd` if no PRD) | Can't execute what hasn't been planned. |
-| "sprint planning", "plan the sprint" | `HAS_EPICS=false` | `/rihal-create-epics-and-stories` first | Sprints draw stories from epics. No epics = no stories to schedule. |
-| "create stories", "epics" | `HAS_PRD=false` | `/rihal-create-prd` first | Epics decompose a milestone. Milestone needs PRD. |
-| "create milestones", "roadmap" | `HAS_PRD=false` | `/rihal-create-prd` first | Roadmap is derived from PRD success metrics. |
-
-When the guard fires, print a clear message:
-
-```
-⚠ Cannot {requested action}: missing prerequisite — {what's missing}.
-
-Re-routing to: /rihal-{prerequisite-command}
-Once that completes, re-run your original request.
-```
-
-Then dispatch to the prerequisite command instead of the originally-matched route.
-
-The guard never silently rejects intent — it always either dispatches to a sensible alternative OR explicitly tells the user what flag overrides it (e.g. `--skip-prerequisites` for the rare legitimate use case).
-</step>
-
-<step name="external_data_guard" priority="first-match">
-**Block code-only routing when the actionable signal lives in an external system.**
-
-Some tasks reference systems whose data is NOT in the repo — observability platforms, issue trackers, analytics, and product dashboards. A pure codebase scan can map *instrumentation* but cannot classify *what is actually firing*. Routing such requests to `/rihal-scan` or `/rihal-map-codebase` without first establishing a data source produces theoretical output (violates the codebase-first rule).
-
-**External-data signals** — match if `$QUESTION` contains any of:
-
-- Observability: `sentry`, `datadog`, `new relic`, `newrelic`, `bugsnag`, `rollbar`, `honeycomb`, `grafana`, `prometheus`, `splunk`, `cloudwatch`
-- Analytics: `google analytics`, ` GA4`, `mixpanel`, `amplitude`, `posthog`, `heap`
-- Issue/support: `linear`, `jira`, `zendesk`, `intercom`, `freshdesk`, `pagerduty`
-- Product/CRM: `stripe dashboard`, `hubspot`, `salesforce`
-
-**Action verbs** — match if `$QUESTION` contains any of: `audit`, `clean up`, `cleanup`, `classify`, `triage`, `review errors`, `noisy`, `top errors`, `which errors`, `production errors`, `dashboard`.
-
-If BOTH a system signal AND an action verb match, fire the guard. Ask via AskUserQuestion BEFORE choosing a route:
-
-```
-The task involves {detected system} — the actionable data lives there, not in the repo.
-A codebase scan alone will only show instrumentation, not which errors are firing.
-
-How should we access the external data?
-
-1. MCP/API access available — pull the data and analyze it
-2. I'll paste the top errors / dashboard export manually
-3. Codebase-only scan is fine — I just want the instrumentation map
-4. Cancel — let me reformulate
-```
-
-Then route accordingly:
-- **Option 1:** Continue to `route` step but tag the chosen command with a note to use the external data source. If no Rihal command natively reads the external system, route to `/rihal-discuss` and have the agent guide MCP/API setup.
-- **Option 2:** Route to `/rihal-discuss` so the user can paste data into a focused conversation, OR `/rihal-note` to capture, then re-run.
-- **Option 3:** Continue to `route` step normally (likely `/rihal-scan` or `/rihal-map-codebase`) but display a clear caveat: *"Output will be an instrumentation map only — it cannot classify which errors are noisy vs critical."*
-- **Option 4:** Stop. Print the original input back so the user can rephrase.
-
-Skip this guard when `AUTO_MODE=true` AND the input explicitly contains `--codebase-only` or `instrumentation map` — those signal the user already accepted the limitation.
-</step>
-
-<step name="explicit_intent_check" priority="first-match">
-**Honor explicit user verbs — skip ambiguity prompts when intent is unambiguous.**
-
-When the user uses a literal create/make/start verb paired with a scope-noun (milestone, phase, story, epic, sprint, plan, PRD, roadmap, council), dispatch IMMEDIATELY. Do not present a multi-route ambiguity menu. The user already chose.
-
-This was a real bug: `/rihal-do "milestone bnao aur ... list down karo"` triggered an ambiguity prompt offering new-milestone vs add-phase vs create-epics-and-stories — even though the user literally said "milestone bnao" (= "create a milestone" in Roman Urdu). That second-guessing wasted the user's time and broke trust.
-
-**Verb + scope detection — sourced from `@.rihal/references/verb-dictionary.md`.**
-
-Match if `$QUESTION` contains any verb from §Create or §Add (English + Roman Urdu/Hindi + Arabic transliteration — full list lives in the dictionary file, do not duplicate here). Pair with a scope noun to determine the route.
-
-The full mapping is in the dictionary's "Scope nouns" table. Pre-conditions enforced by this workflow:
-
-| Scope noun | Direct route | Pre-condition (this workflow only) |
-|---|---|---|
-| milestone | `/rihal-new-milestone` | none — methodology chain assumed when greenfield_guard cleared |
-| phase | `/rihal-add-phase` | HAS_PHASES OR HAS_PRD true |
-| story | `/rihal-create-story` | HAS_EPICS true |
-| epic | `/rihal-create-epics-and-stories` | HAS_PRD true |
-| sprint | `/rihal-sprint-planning` | HAS_EPICS true |
-| PRD | `/rihal-create-prd` | none |
-| roadmap | `/rihal-new-milestone` | HAS_PRD true |
-| council | `/rihal-council` | none |
-| plan (verb) | `/rihal-plan` | HAS_PHASES true |
-
-**Behavior:**
-1. If both a verb AND a scope-noun match, fire this step.
-2. Skip the ambiguity-handling logic in the `route` step entirely.
-3. Apply the state-aware redirect rules below.
-4. Print the routing banner with `Reason: explicit user verb — "{matched verb}" + "{matched noun}"` plus any state-redirect explanation.
-5. Dispatch immediately.
-
-**State-aware redirects (closes #374):**
-
-The naive route is "user said milestone bnao → dispatch new-milestone". But if a milestone is already active, that violates the one-active-milestone convention and triggers a second prompt downstream. Apply these state-aware overrides BEFORE dispatching:
-
-| Verb + scope | State signal | Redirect | Banner message |
-|---|---|---|---|
-| create + milestone | `$ACTIVE_MILESTONE` is non-empty AND user did NOT pass `--force-new-milestone` | `/rihal-add-phase` | `$ACTIVE_MILESTONE is active — adding as a phase to it instead of opening a new milestone. Override: add `--force-new-milestone` to the original input.` |
-| create + milestone | No active milestone | `/rihal-new-milestone $NEXT_VERSION` (auto-derived from `$LAST_SHIPPED_VERSION` + 0.1) | `Auto-versioned $NEXT_VERSION based on last shipped $LAST_SHIPPED_VERSION.` |
-| create + phase | `$HAS_PHASES=false` AND `$HAS_PRD=false` | `/rihal-create-prd` | greenfield_guard already covers this; this row is for completeness. |
-| create + story | `$HAS_EPICS=false` | `/rihal-create-epics-and-stories` (greenfield_guard) | likewise. |
-
-**Auto-version computation when no milestone is active:**
-
-```bash
-# Parse last shipped version (e.g. "v1.7"), bump minor by default
-if [ -n "$LAST_SHIPPED_VERSION" ]; then
-  MAJOR=$(echo "$LAST_SHIPPED_VERSION" | sed -E 's/v([0-9]+)\.[0-9]+/\1/')
-  MINOR=$(echo "$LAST_SHIPPED_VERSION" | sed -E 's/v[0-9]+\.([0-9]+)/\1/')
-  NEXT_VERSION="v${MAJOR}.$((MINOR + 1))"
-else
-  NEXT_VERSION="v1.0"
-fi
-```
-
-Pass `$NEXT_VERSION` as the dispatch arg. The user is NOT prompted to pick a version — the workflow just chose the right one based on history.
-
-**Edge case — multiple scope-nouns in one input** (e.g. "milestone bnao aur usmy phase 1 banao"): take the OUTER/PARENT scope. "Milestone bnao aur usmy phase X" → state-aware-redirect kicks in. If active milestone exists → `/rihal-add-phase` (the inner phase becomes the dispatched action directly). If not → `/rihal-new-milestone $NEXT_VERSION` (the dispatched workflow will create phase 1 internally).
-
-**Edge case — verb without scope-noun** (e.g. "kuch karo", "do something"): do NOT fire this step. Fall through to the normal routing table which can ask for clarification.
-
-**Edge case — explicit override via flag** (`--force-new-milestone`, `--force-new`): bypasses the active-milestone redirect. Use sparingly — usually for emergency hotfix tracks that genuinely need a parallel milestone.
-
-If this step fires, skip the route-step's ambiguity prompt entirely and proceed to display + dispatch.
-</step>
-
-<step name="route">
-**Match intent to command.**
-
-(Run only after greenfield_guard, external_data_guard, AND explicit_intent_check have all cleared without dispatching.)
-
-Evaluate `$QUESTION` against these routing rules. Apply the **first matching** rule:
-
-| If the text describes... | Route to | Why |
-|--------------------------|----------|-----|
-| Starting a new project, "set up", "initialize" | `/rihal-new-project` | Needs full project initialization |
-| Mapping or analyzing an existing codebase | `/rihal-map-codebase` | Codebase discovery |
-| A bug, error, crash, failure, or something broken | `/rihal-debug` | Needs systematic investigation |
-| Validate an idea, "working backwards", "press release", "PRFAQ", "is this worth building" | `/rihal-prfaq` | Stress-test concept before committing sprint capacity |
-| Brainstorm, generate ideas, "explore options", "what could we do" | `/rihal-brainstorm` | Structured ideation before planning |
-| Audit code quality, "review changes", "karpathy", "check my diff", "too complex" | `/rihal-code-review --karpathy` | 4-principle code audit against recent diff |
-| Walk through a change, "checkpoint", "explain this diff", "human review" | `/rihal-checkpoint-preview` | Human-in-the-loop diff walkthrough |
-| Exploring, researching, comparing, or "how does X work" | `/rihal-research-phase` | Domain research before planning |
-| Scope unclear, conflicting UIs/options, "which one", "better UX", "still have confusion", "how should X look", brainstorming vision | `/rihal-discuss-phase` | Decisions not yet locked — gather before planning |
-| A complex task: refactoring, migration, multi-file architecture, system redesign | `/rihal-add-phase` | Needs a full phase with plan/build cycle |
-| Planning a specific phase, "plan phase N" | `/rihal-plan` | Direct phase-level planning |
-| "Sprint planning", "plan the sprint", "next sprint", "what's in this sprint" | `/rihal-sprint-planning` | Sprint-level scope/capacity planning |
-| Executing a sprint, "run the sprint", "start sprint", "work on sprint" | `/rihal-execute-sprint` | Sprint execution with wave batching |
-| Sprint status, "how is the sprint going", "sprint board", "sprint progress" | `/rihal-sprint-status` | Current sprint state |
-| "Create milestones", "plan milestones", "create roadmap", "what milestones do I need", "break project into milestones" | `/rihal-new-milestone` | Roadmap-level planning — designs M1..Mn from the PRD. Do NOT route to `create-epics-and-stories`; that skill decomposes a single milestone into epics |
-| Break milestone into epics/stories, "create stories", "user stories", "epics" | `/rihal-create-epics-and-stories` | Milestone → epic → story decomposition (assumes roadmap already exists) |
-| Create a single story, "add story", "write a story for X" | `/rihal-create-story` | Single story addition |
-| Implement a story, "work on story", "dev story", "build story" | `/rihal-dev-story` | Story-level implementation |
-| Find gaps in milestone plans, "gaps in plans", "missing plan", "unplanned phases" | `/rihal-plan-milestone-gaps` | Identify and fill planning gaps |
-| Executing a phase, "build phase N", "run phase N", "implement phase" | `/rihal-execute` | Direct phase execution request |
-| `/rihal-phase <number>` where number matches an existing phase dir | `/rihal-execute <N>` | User mistyped phase instead of execute — detect bare integer + existing dir, route to execute |
-| Running all remaining phases automatically | `/rihal-autonomous` | Full autonomous execution |
-| A review or quality concern about existing work | `/rihal-verify-work` | Needs verification |
-| "Council", "discuss strategy", "should we" | `/rihal-council` | Multi-agent strategic discussion |
-| List plans across phases, "all plans", "show plans" | `/rihal-list-plans` | Cross-phase plan table |
-| Checking progress, status, "where am I", "board" | `/rihal-progress` | Status check |
-| Resuming work, "pick up where I left off" | `/rihal-resume-work` | Session restoration |
-| A note, idea, or "remember to..." | `/rihal-note` | Capture for later |
-| Adding tests, "write tests", "test coverage" | `/rihal-add-tests` | Test generation |
-| Completing a milestone, shipping, releasing | `/rihal-complete-milestone` | Milestone lifecycle |
-| Drift / out-of-date / "verify docs vs code" / "audit feature docs" / "fill out existing PRD/epics/stories" | `/rihal-feature-drift` | Detects PRD↔epics↔stories↔code drift; --fix patches trivial items |
-| General audit / re-audit / extend / fill out / expand an existing artifact | `/rihal-audit` | Unified audit entry — picks artifact type and re-runs |
-| A specific, actionable, small task (add feature, fix typo, update config) | `/rihal-quick` | Self-contained, single executor |
-| Market/discovery/greenfield question (from classify) | `/rihal-council` | Needs multi-perspective discovery |
-
-If no rule matches, fall back to the classifier:
-
-```bash
-CLASSIFY=$(node ".rihal/bin/rihal-tools.cjs" classify-question "$QUESTION")
-```
-
-Parse `type` from JSON — map codebase/team/release → `/rihal-discuss`; market/discovery/greenfield → `/rihal-council`; drift → `/rihal-feature-drift`. Default: `/rihal-discuss`.
-
-**No-route exit (issue #458):** If neither the routing table nor the classifier yields a confident match, you MUST STOP. Print this disambiguation menu via AskUserQuestion and wait:
-
-```
-I can't route this cleanly. Pick one:
-  1. /rihal-add-phase — if it's a new phase
-  2. /rihal-plan — if scope is clear, jump to plan
-  3. /rihal-discuss-phase — if you want to think through it first
-  4. /rihal-audit — if you want to extend an existing audit/plan
-  5. Describe more specifically what you want
-```
-
-Do NOT execute the work yourself. Do NOT run grep, find, Read, Bash, or Write to "investigate before routing." If you feel the urge to investigate, the dispatcher contract has already failed — STOP and ask.
-
-**Requires `.planning/` directory:** All routes except `/rihal-new-project`, `/rihal-map-codebase`, `/rihal-help`, `/rihal-discuss`, `/rihal-council`. If the project doesn't exist and the route requires it, suggest `/rihal-new-project` first.
-
-**Ambiguity handling:** If the text could reasonably match multiple routes, ask the user via AskUserQuestion with the top 2-3 options. Prefer `discuss-phase` over `plan`/`add-phase` when scope-uncertainty signals are present ("confusion", "not sure", "which one", "better way", "how should", ≥2 conflicting UIs/options mentioned).
-
-Example:
-
-```
-"Refactor the auth system" could be:
-1. /rihal-add-phase — Full planning cycle (recommended for multi-file refactors)
-2. /rihal-discuss-phase — Gather decisions first (recommended if scope is fuzzy)
-3. /rihal-quick — Quick execution (if scope is small and clear)
-
-Which approach fits better?
-```
-</step>
-
-<step name="display">
-**Show the routing decision.**
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- RIHAL ► ROUTING
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Input: {first 80 chars of $QUESTION}
-Scope: {one-line scope summary}
-Routing to: {chosen command}
-Reason: {one-line why}
-```
-</step>
-
-<step name="dispatch">
-**Invoke the chosen command via the Skill tool — do NOT just print it as text.**
-
-CRITICAL: The dispatch step is an *action*, not a *display*. You must call the `Skill` tool with `skill: "rihal-{command}"` (and `args:` for any arguments). Printing the slash-command in a code block, in a banner, or in a "Dispatching..." message is NOT dispatch — it is just text rendering, and the routed command will never run. Past failure: model emitted the dispatch banner three times in a row without ever invoking the Skill tool, then stalled.
-
-Canonical form: skills are namespaced with a hyphen, e.g. `rihal-discuss-phase`, `rihal-plan`, `rihal-status`. The colon form `rihal:discuss-phase` is NOT used in this project (avoided for cross-IDE compatibility) — do not display it to users or pass it to the Skill tool.
-
-Rules:
-- One Skill tool call per `/rihal-do` invocation. Never emit the same dispatch banner twice.
-- Do NOT print `/rihal-{command}` inside a fenced code block as your "action" — that is display-only.
-- The routing banner from the `display` step is the ONLY user-facing summary of the dispatch. After it, the very next thing you do is the Skill tool call.
-
-If `AUTO_MODE` is true OR routing is unambiguous:
-1. Confirm the routing banner has been shown once (from the `display` step).
-2. Immediately call the Skill tool: `Skill(skill: "rihal-{command}", args: "{arguments}")`.
-3. Stop. The dispatched command handles everything from here.
-
-Otherwise (ambiguous, non-auto), use AskUserQuestion to confirm:
-
-```
-Based on your request, I'd use: /rihal-{command} {arguments}
-
-1. Yes, run it
-2. Pick a different route
-3. Cancel
-```
-
-On "Yes" → call Skill tool as above. On "Pick a different route" → restart routing. On "Cancel" → stop.
-
-If the chosen command expects a phase number and one wasn't provided in the text, extract it from context or ask via AskUserQuestion BEFORE the Skill call.
-</step>
-
-</process>
-
-<guardrails>
-**Hard prohibitions during /rihal-do execution (issue #458):**
-
-- MUST NOT call Bash, Read, Grep, Glob, Write, or Edit tools. The dispatcher does not investigate, read code, or write files. Period.
-- MUST NOT spawn Task / Agent / subagents. Dispatch is a Skill tool call to a routed command — nothing else.
-- MUST NOT "do a quick check" before routing. If you feel the urge to grep or read a file to "figure out the right route," the dispatcher contract has already failed — STOP and use the no-route exit.
-- The ONLY tools allowed inside /rihal-do are: AskUserQuestion (for disambiguation), Skill (for dispatch), and the one Bash call to the classifier (`classify-question`). Nothing else.
-- If the user's input doesn't match any route and the classifier is ambiguous: invoke the no-route exit menu. Do not "be helpful" by executing the work yourself.
-
-Why this is hard: do.md is a router. The moment it does work, two failure modes appear: (a) the work is duplicated when the user re-invokes the proper command, or (b) the work happens in the wrong context with the wrong subagent and produces inferior output. Both are worse than a 1-second routing prompt.
-</guardrails>
-
-<success_criteria>
-- [ ] Input validated (not empty)
-- [ ] Intent matched to exactly one Rihal command
-- [ ] Ambiguity resolved via user question (if needed)
-- [ ] Scope-uncertainty signals steer to `/rihal-discuss-phase` over planning routes
-- [ ] Project existence checked for routes that require it
-- [ ] Routing decision displayed before dispatch (exactly once)
-- [ ] Command invoked via the Skill tool — NOT printed as text
-- [ ] Dispatch banner not repeated (single emission only)
-- [ ] No work done directly — dispatcher only
-- [ ] No Bash/Read/Grep/Write/Edit/Task tool calls during execution (only AskUserQuestion + Skill + classifier Bash)
-- [ ] On no-route, exit cleanly with the disambiguation menu — never silently fall through to inline work
-</success_criteria>
-</content>
-</invoke>