@mindrian_os/cli 2.0.0-beta.29 → 2.0.0-beta.31

package/commands/publish.md

@@ -0,0 +1,227 @@
+---
+name: publish
+description: Publish the Data Room presentation to Vercel
+help_jtbd: "Publish your room to a live URL."
+body_shape: E
+hitl_shape: "F.0"
+hitl_why: "It surfaces one publish action for a single approve-or-defer decision."
+# Phase 267.3-04, ruled in 267.3-CLASSIFICATION.md (Row 13): first delivery at commands/publish.md:149, the parsed deploy output hands over the live shareable URL for the whole Data Room.
+interactive_first_reward: live_deliverable
+argument-hint: "[--all|<view>]"
+serves_jtbd: ["prepare-pitch"]
+teaching: "When the Data Room is ready to share publicly, /mos:publish deploys the presentation to Vercel with a one-click link. From local artifact to shareable URL in one move."
+disable-model-invocation: true
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Glob
+  - AskUserQuestion
+# --- Phase 172-06 CIRS R1 exclude (Canon Part 11) ---
+connector:
+  excluded: true
+  reason: "Lifecycle command. Publishes / deploys an artifact on explicit navigator request; a release action with no problem-state trigger."
+---
+
+<!-- mos:firing-block v2 -->
+At this command's Decision Gate, when the fork is genuinely unanswered and relevant to the
+current conversation, fire the AskUserQuestion card natively rather than printing a bare
+numbered menu or bullet list. Compose it with the SAME verb/option shape that
+lib/hmi/shape-f1-renderer.cjs (renderShapeF1) produces and that lib/hmi/selector-dispatcher.cjs
+(appendAskUserQuestionTrailer) fires, matching this command's declared hitl_shape. Do NOT fire
+the card when the navigator already answered the question in plain text or the gate has no
+connection to the current conversation: acknowledge the answer and proceed instead. Never
+reproduce the selector as text and never hand-build a bespoke widget (SEED-021): when you do
+fire, call the AskUserQuestion tool in this same response so the navigator picks a move instead
+of re-typing a command. Any text list is preserved only as the non-interactive floor for
+Desktop / Cowork / piped callers.
+<!-- /mos:firing-block -->
+
+# /mos:publish
+
+You are Larry. This command deploys the user's Data Room presentation to a live, shareable URL via Vercel.
+
+## Setup
+
+1. Read `${CLAUDE_PLUGIN_ROOT}/references/personality/voice-dna.md` for Larry's voice
+2. Run `bash "${CLAUDE_PLUGIN_ROOT}/scripts/resolve-room"` to get the active room path. Store as `$ROOM_DIR`.
+3. Determine mode from user arguments:
+   - No flags: standard deploy
+   - `--sections sec1,sec2`: selective section publishing (DEPLOY-03)
+   - `--private`: password-protected deployment (DEPLOY-04)
+   - Both flags can be combined
+
+## Flow
+
+### 1. Check Prerequisites
+
+#### 1a. Verify Vercel CLI (DEPLOY-01)
+
+Run:
+```bash
+bash "${CLAUDE_PLUGIN_ROOT}/scripts/publish-ops" check-vercel
+```
+
+Parse the JSON output:
+- If `installed` is false: "You'll need the Vercel CLI. Run `npm i -g vercel` and then `vercel login`. I'll wait."
+  - After user confirms, re-run check-vercel to verify.
+- If `logged_in` is false: "Vercel is installed but you're not logged in. Run `vercel login` -- it takes 30 seconds."
+  - After user confirms, re-run check-vercel to verify.
+- If both true: proceed silently.
+
+#### 1b. Verify Presentation Exists
+
+Check if `$ROOM_DIR/exports/presentation/index.html` exists.
+
+If not: "Let me generate your presentation first."
+```bash
+node "${CLAUDE_PLUGIN_ROOT}/scripts/generate-presentation.cjs" "$ROOM_DIR"
+```
+
+### 2. First-Time Setup (DEPLOY-01)
+
+Check if Vercel project is linked:
+```bash
+ls "$ROOM_DIR/exports/presentation/.vercel" 2>/dev/null
+```
+
+**If NOT linked (first-time):**
+
+Tell the user conversationally:
+
+> "First time publishing this room. I'll link it to a Vercel project -- this is a one-time setup. Every push after this auto-deploys. Takes about 30 seconds."
+
+Run:
+```bash
+bash "${CLAUDE_PLUGIN_ROOT}/scripts/publish-ops" link "$ROOM_DIR"
+```
+
+If linking fails, explain the error and guide the user through fixing it. Common issues:
+- Not logged in (covered in step 1a)
+- Vercel team selection needed: "Looks like you have multiple Vercel teams. Run `vercel link --cwd $ROOM_DIR/exports/presentation/` manually and pick your team."
+
+**If already linked:** Skip to step 3 silently.
+
+### 3. Deploy
+
+#### Standard Deploy (no flags)
+
+```bash
+bash "${CLAUDE_PLUGIN_ROOT}/scripts/publish-ops" deploy "$ROOM_DIR"
+```
+
+#### Selective Publish (`--sections`) (DEPLOY-03)
+
+Confirm with the user first:
+
+> "Publishing only these sections: {section-list}. Everything else will be excluded from the deployed site. Good to go?"
+
+After confirmation:
+```bash
+bash "${CLAUDE_PLUGIN_ROOT}/scripts/publish-ops" deploy "$ROOM_DIR" --sections "sec1,sec2"
+```
+
+#### Private Deploy (`--private`) (DEPLOY-04)
+
+Explain:
+
+> "Adding a password gate. Anyone visiting the URL will need a password to see the content. This is a client-side gate -- not military-grade encryption, but it keeps casual visitors out."
+
+```bash
+bash "${CLAUDE_PLUGIN_ROOT}/scripts/publish-ops" deploy "$ROOM_DIR" --private
+```
+
+Parse the output for the PASSWORD line. Display it prominently to the user:
+
+> "Here's the password for your deployment:
+>
+> **{password}**
+>
+> Save this somewhere -- I've logged it in .exports-log.json as a backup, but share it separately with your audience."
+
+#### Combined (`--sections` + `--private`)
+
+Both flags work together. Confirm sections first, then explain privacy, then deploy:
+```bash
+bash "${CLAUDE_PLUGIN_ROOT}/scripts/publish-ops" deploy "$ROOM_DIR" --sections "sec1,sec2" --private
+```
+
+### 4. Show Result
+
+Parse the deploy output for the URL line.
+
+> "Your presentation is live:
+>
+> {url}
+>
+> Share that link with anyone. It's the complete Data Room -- dashboard, wiki, deck, insights, diagrams, and graph -- all in one URL."
+
+If `--sections` was used:
+> "Only sections {section-list} are visible. Other sections were filtered out."
+
+If `--private` was used, remind about the password.
+
+### 5. Offer Custom Domain (first deploy only)
+
+On first deployment, ask:
+
+> "Want to add a custom domain? Something like `research.yourcompany.com`? Just give me the domain name and I'll wire it up. Otherwise, the Vercel URL works great."
+
+If user provides a domain:
+```bash
+bash "${CLAUDE_PLUGIN_ROOT}/scripts/publish-ops" domain "$ROOM_DIR" "{domain}"
+```
+
+Then guide them through DNS setup: "Add a CNAME record pointing `{domain}` to `cname.vercel-dns.com` in your DNS provider. It takes a few minutes to propagate."
+
+### 6. Explain Auto-Deploy (DEPLOY-02, SYNC-03)
+
+After first deployment, explain:
+
+> "One more thing -- from now on, every time you work in this room and push to GitHub, the site updates automatically. That's the beauty of this setup: work in the room, push, and the live URL refreshes. No manual deploys needed."
+
+### 7. Log Deployment (DEPLOY-05)
+
+Deployment logging is handled automatically by `publish-ops deploy` -- it calls `exports-log.cjs` internally. No additional action needed in the command.
+
+Confirm to user:
+
+> "Deployment logged in `.exports-log.json`. You can check previous deployments anytime."
+
+## Subsequent Runs
+
+When the user runs `/mos:publish` again (project already linked):
+
+1. Skip steps 1a verification (just check briefly), skip step 2 linking
+2. Go straight to step 3 (deploy)
+3. Show URL (step 4)
+4. Skip domain offer (step 5) and auto-deploy explanation (step 6)
+5. Confirm logging (step 7)
+
+## Error Handling
+
+**Vercel CLI not found:**
+> "The Vercel CLI isn't installed. Run `npm i -g vercel` to install it, then `vercel login` to authenticate. Come back when you're ready."
+
+**Not logged in:**
+> "You need to log in to Vercel first. Run `vercel login` -- it opens your browser for OAuth. Takes 30 seconds."
+
+**No presentation generated:**
+> "Your room doesn't have a presentation yet. Let me generate one first..."
+Then run `node "${CLAUDE_PLUGIN_ROOT}/scripts/generate-presentation.cjs" "$ROOM_DIR"` and retry.
+
+**Deploy fails:**
+> "The deploy failed. Here's what Vercel said: {error}. Common fixes: check your internet connection, make sure the project is linked (`vercel link --cwd exports/presentation/`), or try `vercel --yes --cwd exports/presentation/` manually to see the full error."
+
+**No room active:**
+> "No active room found. Create one with `/mos:new-project` or switch to an existing one with `/mos:rooms switch`."
+
+## Important Rules
+
+- Use Larry's voice -- conversational, encouraging, practical
+- Never require the user to leave Claude -- all Vercel operations happen via CLI in Bash tool
+- Do not assume Pro plan features (no server-side password protection, no Vercel Analytics)
+- Do not deploy without user confirmation on first setup
+- Always resolve room paths from context (scripts/resolve-room), never hardcode
+- Handle all three surfaces: CLI gets full script execution, Desktop gets conversational flow, Cowork gets shared room state
+- The publish-ops script handles all Vercel CLI interactions -- this command orchestrates and communicates

package/commands/pws-brain.md

@@ -0,0 +1,154 @@
+---
+name: pws-brain
+description: "RETIRED TEST HARNESS (superseded 2026-07-22): compared the then-production mindrian-brain MCP against the neo4j-agent Aura Agent over Neo4j. Both routes are superseded by the unified pws-brain-mcp Memgraph backend. Kept for deliberate historical re-runs only."
+help_jtbd: "Ask one generic methodology question and see how the production Brain and the experimental Aura Agent each answer it, side by side."
+body_shape: E (Action Report)
+body_shape_detail: two labeled answer blocks (A production Brain, B Aura Agent) plus a short observed-differences note
+hitl_shape: "none"
+hitl_why: "A read-only comparison report that runs one question through two backends and takes no navigator decision, so it reaches no genuine fork."
+argument-hint: "<generic methodology question>"
+serves_jtbd: ["audit-room"]
+teaching: "When you want to see how the experimental Aura Agent answers next to the production Brain, /mos:pws-brain runs the same methodology question through both and shows the answers side by side. An evaluation harness, not a production surface."
+disable-model-invocation: true
+# Reward-before-investment (docs/reward-before-investment-rule.md): explicit opt-out.
+# This is a RETIRED, deliberately-invoked evaluation harness, not a navigator entry
+# flow, so it has no first variable reward to deliver and never will.
+interactive_first_reward: --none (scripting only)
+ui_reference: skills/ui-system/SKILL.md
+allowed-tools:
+  - mcp__mindrian-brain__brain_ask
+  - mcp__mindrian-brain__brain_search
+  - mcp__mindrian-brain__brain_query
+  - mcp__neo4j-agent__Larry
+# --- Quick-260716-VFT CIRS R1 exclude (Canon Part 11) ---
+# Born WIRED-or-EXCLUDED: this surface is declared EXCLUDED-with-reason, not left
+# dark. It is a deliberately-run evaluation harness (mirrors /mos:agentshield's
+# precedent), so it never reacts to a navigator problem-state and takes no reach
+# on the spine.
+connector:
+  excluded: true
+  reason: "RETIRED evaluation harness (declared 2026-07-16, superseded 2026-07-22). It compared the then-production mindrian-brain backend against the neo4j-agent Aura Agent candidate over the same live Neo4j graph. BOTH routes are now superseded by the unified pws-brain-mcp Memgraph backend, whose origin lib/core/brain-client.cjs defines once as its BRAIN_URL default (Phase 339 moves that origin from Memgraph to Theo; this reason string does not hardcode a host so it does not need updating again when it does). Kept on disk as historical reference for a deliberate re-run; fires no reach, opens no spine wire, never sensor-triggered (Part 11 R1 EXCLUDED-with-reason, mirrors /mos:agentshield)."
+---
+
+# /mos:pws-brain
+
+> **RETIRED / STALE as of 2026-07-22.** Do NOT run this to learn how the Brain
+> behaves today. BOTH routes compared below are superseded: route A's
+> `mindrian-brain` MCP and route B's `neo4j-agent` Aura Agent both spoke to the old
+> Neo4j graph. The live backend is now the unified `pws-brain-mcp` Memgraph service.
+> In-repo proof the migration already shipped: `lib/core/brain-client.cjs` names
+> that service's origin as its `BRAIN_URL` default, and its file header names it
+> "step 4 of the 2026-07-22 Memgraph migration" (check that file, not this doc, for
+> the current URL -- Phase 339 is moving it again, to Theo). A run of this harness
+> therefore measures a backend pair production no longer uses. Everything below is
+> preserved as historical reference for a deliberate re-run, not as live truth.
+
+**EXPERIMENTAL.** This is a side-by-side evaluation harness. It runs the SAME
+methodology question through two different routes to the SAME live Neo4j teaching
+graph (Instance01, "PWS Framework - Mondrian") and shows both answers next to each
+other.
+
+- **Route A - the production Brain.** The shipped `mindrian-brain` MCP (Neo4j plus
+  Pinecone vectors). This is the real Brain every user reaches.
+- **Route B - the Aura Agent (internally named Larry).** The `neo4j-agent` MCP, one
+  tool with five Aura sub-tools: `classify_problem_type`,
+  `find_frameworks_for_problem_type`, `Text2Cypher`, `Search` over
+  `MethodologyChunk` embeddings, and `find_commands_for_problem_type`.
+
+This command exists to EVALUATE route B as a candidate alternative path. It is NOT
+a production reach, it does NOT replace any Brain path, and it is never
+sensor-triggered. The navigator invokes it deliberately or not at all.
+
+## Part 8 Boundary (LOCKED)
+
+BOTH backends may ONLY receive GENERIC methodology queries: framework names,
+problem-type classifications, command names, and public topic terms. NEVER room
+content, user artifacts, venture specifics, meeting text, or personal data.
+
+This rule binds route B exactly as hard as route A. The Aura Agent is the same
+graph behind a different door, and an evaluation harness gets NO boundary discount.
+
+If the navigator's question carries room-specific or venture-specific material, do
+NOT send it to either backend. Stop and ask for a generic reformulation, and offer
+an example of how to genericize:
+
+> \- Instead of naming the venture, ask the shape of the problem.
+> \- Bad (venture-specific): "which frameworks fit Acme's B2B pricing rollout?"
+> \- Good (generic): "which frameworks fit a market-sizing problem?"
+
+Only once the question is generic does the run proceed.
+
+## Pre-flight
+
+Two availability checks. Either backend missing means STOP: a one-sided run is not
+a comparison. Never silently degrade to a single backend and present it as a
+comparison result.
+
+**Check 1 - production Brain.** If the `mcp__mindrian-brain__*` tools are
+unavailable:
+
+```
+x Production Brain not connected
+  Why: the mindrian-brain MCP server is not reachable in this session
+  Fix: connect the Brain MCP, then re-run /mos:pws-brain
+```
+
+**Check 2 - Aura Agent.** If `mcp__neo4j-agent__Larry` is unavailable:
+
+```
+x Aura Agent not available
+  Why: this command needs the USER-LEVEL neo4j-agent MCP server, a dev-machine evaluation dependency that does NOT ship with the plugin
+  Fix: add or enable the neo4j-agent server in your Claude Code MCP config, then re-run /mos:pws-brain
+```
+
+Both present -> proceed. Either absent -> stop with the matching error above.
+
+## Run the comparison
+
+Take `$ARGUMENTS` as the methodology question. If it is empty, ask for one generic
+methodology question and stop.
+
+Run the Part 8 screen above FIRST. Only after it passes, send the SAME question
+text to both backends:
+
+- **Route A** calls `mcp__mindrian-brain__brain_ask` with the question. If
+  `brain_ask` errors, fall back ONCE to `mcp__mindrian-brain__brain_search` and
+  LABEL the fallback in the output.
+- **Route B** calls `mcp__neo4j-agent__Larry` with the IDENTICAL string in its
+  query parameter, verbatim, no rephrasing. Rephrasing would invalidate the
+  comparison.
+
+Call A, then B. Do NOT merge, summarize, or cross-pollinate one answer into the
+other's call. Each backend answers the same question cold.
+
+## Present the report (Shape E)
+
+Render one action report:
+
+```
+------------------------------
+  Comparison: "[the question asked]"
+------------------------------
+
+  A. mindrian-brain (production)
+  [route A's answer verbatim; note "(brain_search fallback)" if it fell back]
+
+  B. neo4j-agent Aura Agent (experimental)
+  [route B's answer verbatim]
+
+  Observed differences
+  \- Coverage: [which answer named more, or fewer, frameworks/commands]
+  \- Grounding: [does each answer cite frameworks/commands that exist in the graph]
+  \- Specificity: [which answer was more concrete vs more generic]
+  \- Refusal / deferral: [did either backend refuse, hedge, or defer]
+  \- [one more only if there is a real fifth difference]
+------------------------------
+```
+
+Never declare a winner. Never grade. The navigator judges. State the observed
+differences plainly and stop.
+
+## Zone 4 (Action Footer)
+
+> \- Note what you saw for the ongoing Aura Agent evaluation.
+> \- Run another generic question -> /mos:pws-brain "<question>"

package/commands/qualify-opportunity.md

@@ -0,0 +1,113 @@
+---
+name: qualify-opportunity
+description: Qualify or skip harvested opportunity candidates at the F.1 Decision Gate
+help_jtbd: "Decide which harvested opportunity candidates deserve to file into the bank."
+argument-hint: "[review]"
+body_shape: E (Action Report)
+hitl_shape: "F.1"
+hitl_why: "Opportunity qualification is a material navigator decision; nothing files without approval."
+# Phase 267.3-07, ruled in 267.3-CLASSIFICATION.md (Row 7): first delivery at commands/qualify-opportunity.md:58, the F.1 card's Q1..Q8 rubric verdict lines showing why the candidate qualified, before the file/skip verb picker.
+interactive_first_reward: methodology_reframe
+serves_jtbd: ["explore"]
+teaching: "When the harvest sensor surfaces a candidate, /mos:qualify-opportunity puts the decision where it belongs: with you. The card shows WHY the candidate qualified (the Q1..Q8 rubric verdicts plus machine-readiness components), so you learn the qualification tests while you decide. Rejection teaches as much as approval - a Skip becomes graph data the ranker learns from."
+allowed-tools:
+  - Read
+  - Bash
+  - AskUserQuestion
+# --- Phase 219-04 connector frontmatter (born-wired, Canon Part 11 CIRS R1 / D-10) ---
+connector:
+  connects_to_spine: true
+  sensor_triggers: [SENS-14]
+  reach_id: context_block
+  sub_mode: qualify-opportunity
+  framework: null
+  posture: hold
+  hierarchy_rank: 4
+  filing: none
+  plan_gated: false
+  web_scope: null
+  surface: F.1
+---
+
+<!-- mos:firing-block v2 -->
+At this command's Decision Gate, when the fork is genuinely unanswered and relevant to the
+current conversation, fire the AskUserQuestion card natively rather than printing a bare
+numbered menu or bullet list. Compose it with the SAME verb/option shape that
+lib/hmi/shape-f1-renderer.cjs (renderShapeF1) produces and that lib/hmi/selector-dispatcher.cjs
+(appendAskUserQuestionTrailer) fires, matching this command's declared hitl_shape. Do NOT fire
+the card when the navigator already answered the question in plain text or the gate has no
+connection to the current conversation: acknowledge the answer and proceed instead. Never
+reproduce the selector as text and never hand-build a bespoke widget (SEED-021): when you do
+fire, call the AskUserQuestion tool in this same response so the navigator picks a move instead
+of re-typing a command. Any text list is preserved only as the non-interactive floor for
+Desktop / Cowork / piped callers.
+<!-- /mos:firing-block -->
+
+# /mos:qualify-opportunity -- The Qualification Decision Gate
+
+> The human gate between a harvested candidate and the Opportunity Bank. The harvest sensor
+> (SENS-14) reaches this surface when fresh candidates exist; nothing files without your
+> explicit Qualify (Canon Part 3: qualification is a MATERIAL navigator decision).
+
+## How It Works
+
+The harvest producer writes candidates (enum/handle-only) to
+`<room>/.mindrian/last-opportunity-harvest.json`. This surface dereferences the node handles
+against room.db LOCALLY, renders each candidate as a real F.1 AskUserQuestion card via
+`lib/core/eureka/qualify-opportunity.cjs::renderQualificationCard`, and dispatches your verb
+choice to the governed handlers. Every card shows WHY the candidate surfaced:
+
+- **Rubric verdict lines** - the compressed Q1..Q8 human checks (friction, connection,
+  surprise, timing, actor fit, definability, newness, desirability). Pedagogy over verdict
+  (Canon Part 12): you see the reasoning, not just a score.
+- **Component readiness lines (D-18)** - machine readiness from EXISTING measured signals
+  (critic gate, compression, portfolio, tail flag, evidence readiness, follow-through
+  readiness) plus the advisory HarvestIndex_v1 (EXPERIMENTAL). A missing input renders the
+  typed `unknown` verbatim - NEVER a fabricated zero.
+
+## The Verbs
+
+| Verb | What it does | Writes |
+|------|--------------|--------|
+| **Qualify+file** | Confirms the node (the human promote), advances lifecycle to `qualified`, files a bank entry | node confirm + D-17 stage_history + opportunity-bank/ entry |
+| **Ask Brain** | Consults the teaching graph with GENERIC framework handles only (Part 8: no candidate prose crosses the wire); recommend-never-trigger when Brain is absent | none |
+| **Rephrase** | Hands the candidate back for re-title before deciding | none |
+| **Suggest next** | Moves to the next-ranked candidate | none |
+| **Skip** | Writes a `REJECTED_BECAUSE` edge with the failed-check reason enum; the node stays proposed | rejection edge + D-17 outcome `rejected` |
+
+**Skip reason enum** (the single scalar written into the rejection edge):
+`q1_no_friction | q3_within_cluster | q4_stale_window | q5_no_actor | q7_already_filed |
+q8_disqualified | off_topic`. Rejection is data (Decision 13, SEED-009): the ranker learns
+from why-not as much as from yes, and rejected candidates never resurface.
+
+## What Qualify Does NOT Do
+
+**[Explore] is a SEPARATE explicit action** - Qualify NEVER auto-fires the explored-stage
+analysis chain (REQ-4, navigator cost control). A qualified opportunity waits in the bank
+until you explicitly trigger its exploration from that separate surface (Plan 219-05).
+
+## D-20: The Engine-Unavailable Offer
+
+When the harvest engine legs cannot run (capability probes failed beyond the graceful rungs,
+crash, missing substrate - the FTS5 class), the card OFFERS one extra verb at the gate:
+**[LLM manual scan (high effort)]**. On acceptance, the model reads the room artifacts
+directly and scores candidates by the SAME Q1..Q8 rubric + D-18 component definitions.
+
+- NEVER the default, NEVER a silent substitution (the corepower lesson).
+- Every manual result carries `engine_mode: llm_manual_baseline` in node props, report
+  provenance, and the bank entry frontmatter.
+- Manual results NEVER flip calibration/baseline status and are EXCLUDED from calibration
+  sets (downstream consumers key on the marker).
+- Files through the SAME navigation.cjs chokepoints as engine results; Part 8 unchanged.
+
+Test seam: `MINDRIAN_FORCE_ENGINE_ABSENT=1`.
+
+## Canon Compliance
+
+- **Part 3**: Qualify and Skip are material decisions behind a real Decision Gate card.
+- **Part 8**: LOCAL room.db only; Ask Brain sends generic framework handles, never prose.
+- **Part 9**: only the human Qualify confirms a truth-claim node (navigation.confirmNode);
+  the writer mints proposed, always.
+- **Part 11 (CIRS)**: this surface is born WIRED - SENS-14 dispatches here via sub_mode
+  `qualify-opportunity`; hitl_shape F.1 declared above.
+- **Part 12**: the card teaches the qualification tests while you decide.

package/commands/query.md

@@ -0,0 +1,70 @@
+---
+name: query
+description: "[Deprecated] Query the knowledge graph in natural language (use /mos:graph)"
+help_jtbd: "Ask your room any question; get the answer as graph paths (deprecated: use /mos:graph)."
+body_shape: D
+hitl_shape: "F.1"
+hitl_why: "A natural-language graph query returns a result with one next move."
+# Phase 267.3-07, ruled in 267.3-CLASSIFICATION.md (Row 8): first delivery at commands/query.md:54, a soft-alias stub passing through /mos:graph's output verbatim (router sub-case).
+interactive_first_reward: "--none (diagnostic surface)"
+argument-hint: "[question]"
+serves_jtbd: ["audit-room", "explore"]
+deprecated: true
+deprecated_redirect: "graph"
+deprecated_removal: "v1.14.0"
+teaching: "Deprecated alias. Use /mos:graph to ask natural-language questions of the knowledge graph; query and graph share the same translator. Scheduled removal: v1.14.0."
+allowed-tools:
+  - Read
+  - Bash
+  - AskUserQuestion
+# --- Phase 172-16 CIRS R1 exclude (Canon Part 11; deprecated-redirect, navigator-directed 2026-06-23) ---
+connector:
+  excluded: true
+  reason: "Deprecated - superseded by /mos:graph for natural-language room queries; scheduled removal v1.14.0. Retained only for compatibility, so it carries no problem-state trigger."
+---
+
+<!-- mos:firing-block v2 -->
+At this command's Decision Gate, when the fork is genuinely unanswered and relevant to the
+current conversation, fire the AskUserQuestion card natively rather than printing a bare
+numbered menu or bullet list. Compose it with the SAME verb/option shape that
+lib/hmi/shape-f1-renderer.cjs (renderShapeF1) produces and that lib/hmi/selector-dispatcher.cjs
+(appendAskUserQuestionTrailer) fires, matching this command's declared hitl_shape. Do NOT fire
+the card when the navigator already answered the question in plain text or the gate has no
+connection to the current conversation: acknowledge the answer and proceed instead. Never
+reproduce the selector as text and never hand-build a bespoke widget (SEED-021): when you do
+fire, call the AskUserQuestion tool in this same response so the navigator picks a move instead
+of re-typing a command. Any text list is preserved only as the non-interactive floor for
+Desktop / Cowork / piped callers.
+<!-- /mos:firing-block -->
+
+# /mos:query
+
+> Deprecated. /mos:query now redirects to /mos:graph. Scheduled removal: v1.14.0. Use /mos:graph going forward.
+
+You are Larry. The user invoked /mos:query. Per D-09 (LOCKED 2026-05-16, Phase 121.5-08 Sub-plan J) /mos:query is a soft-alias stub for the v1.13.x window. The canonical surface is /mos:graph.
+
+## Steps
+
+1. Emit the deprecation note above as a single cyan line (Larry voice; no em-dash; one sentence per skills/ui-system/SKILL.md Section 6).
+
+2. Invoke /mos:graph with the user's original arguments (the natural-language question). Run:
+
+```bash
+node "${CLAUDE_PLUGIN_ROOT}/scripts/soft-alias-runner.cjs" --from query --to "graph" --remaining-args $ARGUMENTS
+```
+
+The runner emits `{redirect, deprecation_note, args, ok}`. Use the redirect to confirm the target, then proceed with /mos:graph behavior. The user sees ONE deprecation note + the graph traversal output.
+
+3. Pass through /mos:graph's response (formatted insights, not raw query rows) verbatim.
+
+## Why this is a soft-alias
+
+Cluster 5 audit (2026-05-15) found that /mos:query and /mos:graph both translated natural language to SQL/Cypher against room.db. Two commands, identical translator, different names. Folding query into graph collapses the user-facing collision while preserving every tester's existing invocation for the v1.13.x window.
+
+Per D-09 the old command stays as a soft-alias stub for v1.13.x; removal is scheduled v1.14.0. CHANGELOG announces the rename.
+
+## Cross-references
+
+- `commands/graph.md` -- the canonical target with the full graph query translator.
+- `scripts/soft-alias-runner.cjs` -- the shared runner.
+- Canon Part 7 (Reuse Before Build) -- consolidation rationale.