@mindrian_os/install 1.13.0-beta.11 → 1.13.0-beta.12

package/lib/workflow/ROOM.md

@@ -5,7 +5,7 @@ section: lib/workflow
 purpose: Workflow layer -- the framework <-> command registry resolver. The sole door from "framework" to "/mos: command".
 founding_phase: 122
 phase: 122
-milestone: v1.13.0-beta.11
+milestone: v1.13.0-beta.12
 canon_parts: [7, 8]
 created: 2026-05-12
 ---

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mindrian_os/install",
-  "version": "1.13.0-beta.11",
+  "version": "1.13.0-beta.12",
   "description": "Install MindrianOS into Claude Code with one command -- `npx @mindrian_os/install`. Ships the MindrianOS plugin (Larry + PWS methodology + Data Room) plus a setup/diagnostics CLI (install/doctor/update).",
   "scripts": {
     "mcp": "node bin/mindrian-mcp-server.cjs",

package/references/brain/command-triggers-schema.md

@@ -1,226 +1,15 @@
-# Brain Command Trigger Schema
+# Brain Command Trigger Schema -- REMOVED (Phase 122, v1.13.0-beta)
 
-## Purpose
+This document used to describe a "commands are first-class Neo4j nodes with typed trigger relationships" design. That design was never built into the live Brain (no such label exists in the deployed graph), and it is a latent **Canon Part 8** breach in prose: it asserts that plugin commands live in the Brain. Per Canon Part 8 (`docs/MINDRIAN-CANON.md`), the Brain is a repository of strategic thinking tools, never a repository of plugin internals or user data. Commands never enter the Brain.
 
-Commands are first-class nodes in the Neo4j Brain. They have typed relationships to Frameworks, ProblemTypes, VentureStages, and Signals that define WHEN they should fire. The Brain doesn't just recommend frameworks -- it recommends ACTIONS mapped to specific /mos: commands with trigger conditions.
+## What replaced it
 
-## Node: Command
+The framework-to-command mapping is now plugin-local, generated, and CI-checked:
 
-```cypher
-CREATE (c:Command {
-  name: '/mos:find-analogies',
-  slug: 'find-analogies',
-  category: 'intelligence',          // infrastructure | methodology | intelligence | export | meeting | funding
-  description: 'Cross-domain analogy discovery via structural isomorphism',
-  jtbd_when: 'stuck on a problem that feels unique to your domain',
-  jtbd_want: 'discover that other industries already solved the same structural conflict',
-  jtbd_so: 'adapt their approach instead of inventing from scratch',
-  time_estimate: '5 minutes',
-  flags: ['--brain', '--external'],   // available flags
-  min_sections: 2,                    // minimum populated sections to be relevant
-  requires_brain: false,              // works without Brain (but better with)
-  powerhouse: true                    // v1.6.0+ feature
-})
-```
+- **Source of truth:** the `frameworks:` key in each `commands/*.md` frontmatter. Contract: `docs/COMMAND-FRONTMATTER.md`.
+- **Generated registry:** `data/command-registry.json` -- built from frontmatter by `scripts/build-command-registry.cjs`; never hand-edited; pre-commit + Feynman-runner tripwire on drift.
+- **The only door at runtime:** `lib/workflow/command-resolver.cjs` (`commandsForFramework`, `composeWorkflow`, `validateChainAutonomy`).
+- **The Brain side:** `lib/brain/chain-recommender.cjs` ranks WHICH frameworks to chain next via the Brain's `FEEDS_INTO` traversal -- framework names + problem-type enums only, never a command string, never user content.
+- **The full picture:** `docs/WORKFLOWS.md`.
 
-## Relationships
-
-### TRIGGERED_BY_SIGNAL
-
-Links a Command to the Room Signal types that should trigger it.
-
-```cypher
-// When a CONTRADICTS edge exists between sections -> suggest find-analogies
-CREATE (cmd:Command {name: '/mos:find-analogies'})-[:TRIGGERED_BY_SIGNAL {
-  signal_type: 'TENSION',            // TENSION | BLIND_SPOT | BOTTLENECK | PATTERN | SURPRISE
-  priority: 1,                        // 1=highest, 5=lowest
-  condition: 'contradicts_count >= 1',
-  jtbd_framing: 'When your Sections have unresolved Tensions, you want to see how other domains resolved the same structural conflict'
-}]->(sig:SignalType {name: 'TENSION'})
-
-// When 3+ sections have gaps -> suggest act --swarm
-CREATE (cmd:Command {name: '/mos:act --swarm'})-[:TRIGGERED_BY_SIGNAL {
-  signal_type: 'BLIND_SPOT',
-  priority: 1,
-  condition: 'gap_count >= 3',
-  jtbd_framing: 'When 3+ Sections have Blind Spots, you want to fill them all at once instead of one at a time'
-}]->(sig:SignalType {name: 'BLIND_SPOT'})
-
-// When reverse salients detected -> suggest specific methodology for lagging section
-CREATE (cmd:Command {name: '/mos:act'})-[:TRIGGERED_BY_SIGNAL {
-  signal_type: 'BOTTLENECK',
-  priority: 2,
-  condition: 'reverse_salient_count >= 1',
-  jtbd_framing: 'When a Section lags behind the others, you want to close the gap before it compounds'
-}]->(sig:SignalType {name: 'BOTTLENECK'})
-```
-
-### FOLLOWS_FRAMEWORK
-
-Links a Command to the Framework it should follow (chaining).
-
-```cypher
-// After JTBD analysis -> suggest Blue Ocean
-CREATE (cmd:Command {name: '/mos:dominant-designs'})-[:FOLLOWS_FRAMEWORK {
-  confidence: 0.85,
-  reason: 'JTBD reveals customer needs; dominant designs reveals competitive whitespace',
-  hop_distance: 1
-}]->(f:Framework {name: 'Jobs-to-Be-Done'})
-
-// After find-analogies -> suggest validate (stress-test the analogy)
-CREATE (cmd:Command {name: '/mos:validate'})-[:FOLLOWS_FRAMEWORK {
-  confidence: 0.90,
-  reason: 'Analogies must be stress-tested before acting on them',
-  hop_distance: 1
-}]->(f:Framework {name: 'Design-by-Analogy'})
-
-// After grade --full -> suggest act --swarm on weak sections
-CREATE (cmd:Command {name: '/mos:act --swarm'})-[:FOLLOWS_FRAMEWORK {
-  confidence: 0.80,
-  reason: 'Grading reveals gaps; swarm attacks them in parallel',
-  hop_distance: 1
-}]->(f:Framework {name: 'Assessment'})
-```
-
-### RELEVANT_AT_STAGE
-
-Links a Command to VentureStages where it's most impactful.
-
-```cypher
-// find-analogies is most powerful at Discovery and Design stages
-CREATE (cmd:Command {name: '/mos:find-analogies'})-[:RELEVANT_AT_STAGE {
-  impact: 'high',
-  reason: 'Discovery needs fresh perspectives; Design needs proven patterns'
-}]->(stage:VentureStage {name: 'Discovery'})
-
-// grade --full becomes critical at Investment stage
-CREATE (cmd:Command {name: '/mos:grade --full'})-[:RELEVANT_AT_STAGE {
-  impact: 'critical',
-  reason: 'Investment stage demands rigor across every Section'
-}]->(stage:VentureStage {name: 'Investment'})
-
-// scout is always relevant but especially at Validation
-CREATE (cmd:Command {name: '/mos:scout'})-[:RELEVANT_AT_STAGE {
-  impact: 'high',
-  reason: 'Validation stage has deadlines and competitor dynamics'
-}]->(stage:VentureStage {name: 'Validation'})
-```
-
-### ADDRESSES_PROBLEM_TYPE
-
-Links a Command to ProblemTypes it solves (via multi-hop through Frameworks).
-
-```cypher
-// find-analogies addresses wicked problems (via Design-by-Analogy framework)
-CREATE (cmd:Command {name: '/mos:find-analogies'})-[:ADDRESSES_PROBLEM_TYPE {
-  via_framework: 'Design-by-Analogy',
-  effectiveness: 0.85
-}]->(pt:ProblemType {name: 'wicked'})
-
-// act --swarm addresses complex problems with multiple dimensions
-CREATE (cmd:Command {name: '/mos:act --swarm'})-[:ADDRESSES_PROBLEM_TYPE {
-  via_framework: 'Multiple simultaneous frameworks',
-  effectiveness: 0.90
-}]->(pt:ProblemType {name: 'ill-defined-complex'})
-```
-
-### RESOLVES_TENSION_BETWEEN
-
-Links a Command to Framework pairs that commonly produce contradictions.
-
-```cypher
-// find-analogies resolves tensions between pricing frameworks and competitive positioning
-CREATE (cmd:Command {name: '/mos:find-analogies'})-[:RESOLVES_TENSION_BETWEEN {
-  framework_a: 'Lean Canvas',
-  framework_b: 'Competitive Analysis',
-  resolution_pattern: 'Cross-domain structural isomorphism finds how other industries resolved pricing vs positioning'
-}]->(tension:TensionType {name: 'pricing_vs_positioning'})
-```
-
-## Multi-Hop Proactive Query
-
-The power of this schema is MULTI-HOP reasoning. The Brain can traverse:
-
-```
-User's Room State
-  -> Current Frameworks (from Room artifacts)
-    -> FEEDS_INTO relationships (what comes next)
-      -> Command nodes (which /mos: command delivers it)
-        -> TRIGGERED_BY_SIGNAL (is the trigger condition met?)
-          -> Return ranked command suggestion with full JTBD framing
-```
-
-### Query: brain_proactive_command (Pattern 10d)
-
-```cypher
-// Multi-hop: Room frameworks -> next framework -> command -> trigger check
-MATCH (current:Framework)<-[:FOLLOWS_FRAMEWORK]-(cmd:Command)
-WHERE current.name IN $room_frameworks
-
-// Check if command is relevant at this venture stage
-OPTIONAL MATCH (cmd)-[stage_rel:RELEVANT_AT_STAGE]->(stage:VentureStage {name: $venture_stage})
-
-// Check if command is triggered by current signals
-OPTIONAL MATCH (cmd)-[trigger:TRIGGERED_BY_SIGNAL]->(sig:SignalType)
-
-// Get success data
-OPTIONAL MATCH (current)-[:APPLIED_IN]->(example:Example)
-WHERE example.grade_numeric >= 80
-
-RETURN cmd.name AS command,
-       cmd.jtbd_when AS when_situation,
-       cmd.jtbd_want AS want_motivation,
-       cmd.jtbd_so AS so_outcome,
-       cmd.time_estimate AS time,
-       cmd.flags AS available_flags,
-       stage_rel.impact AS stage_impact,
-       trigger.signal_type AS triggered_by,
-       trigger.condition AS trigger_condition,
-       trigger.jtbd_framing AS trigger_framing,
-       count(example) AS success_count
-ORDER BY stage_rel.impact DESC, trigger.priority ASC, success_count DESC
-LIMIT 5
-```
-
-**Parameters:**
-- `$room_frameworks` -- frameworks used in Room (from artifact frontmatter)
-- `$venture_stage` -- from STATE.md
-
-**Output:** Ranked command suggestions with full JTBD framing, trigger conditions, and success data from real projects.
-
-## Seeding Script
-
-The Command nodes and trigger relationships need to be seeded into Neo4j. Create a script that:
-
-1. Reads all commands/*.md files
-2. Extracts: name, description, allowed-tools, category
-3. Generates JTBD statements from the command's purpose
-4. Creates Command nodes with relationships to:
-   - Frameworks they follow (from methodology chaining rules)
-   - VentureStages they're relevant at (from problem-types.md)
-   - SignalTypes that trigger them (from proactive-intelligence patterns)
-5. Runs the Cypher via `mcp__neo4j-brain__write_neo4j_cypher`
-
-Script location: `scripts/seed-brain-commands.cjs`
-
-## The Intelligence Hierarchy (Updated)
-
-```
-LEVEL 3 (Brain + Room + Signals):
-  brain_proactive_command (Pattern 10d)
-  Multi-hop: frameworks -> commands -> triggers -> JTBD
-  Calibrated from 100+ real projects
-  Knows which sequences ACTUALLY produced results
-
-LEVEL 2 (Room + Local Fabric):
-  Larry's JTBD provoked suggestions (every 3-7 turns)
-  KuzuDB Tensions, Bottlenecks, Surprises, Convergences
-  Good but not cross-venture calibrated
-
-LEVEL 1 (No Room):
-  Generic stage-based defaults
-  methodology/index.md routing table
-  Better than nothing
-```
-
-Brain-connected users get LEVEL 3: the Brain literally tells Larry which command to suggest, when, and why -- backed by data from 100+ real ventures. The JTBD framing is baked into the Command node itself. Larry just reads it and presents it naturally.
+Trigger conditions (which signal surfaces which next step) live in the navigation engine (Phase 91 family) and the cascade hooks (Phase 116/117) -- locally, where the room state is, not in the Brain.

package/references/methodology/index.md

@@ -1,81 +1,24 @@
-# Methodology Index -- Command Routing Reference
+# Methodology Index -- Pointer
 
-*All MindrianOS methodology commands. Used for progressive disclosure and framework routing.*
+> Phase 122 (Workflow Layer) replaced the hand-maintained framework-to-command routing table that used to live here. That table drifted (it is the exact drift class the Workflow Layer was built to delete). The authoritative mapping is now generated, CI-checked, and resolved at runtime through one door.
 
 ---
 
-## Infrastructure Commands
+## Where the framework-to-command mapping lives now
 
-| Command | Description | Default Room |
-|---------|-------------|--------------|
-| `/mos:new-project` | Start a new venture project -- Larry explores your idea and creates your Data Room | (creates all rooms) |
-| `/mos:help` | Larry recommends 2-3 relevant commands based on your room state | (none) |
-| `/mos:status` | Room overview, venture stage, gaps, suggested next action | (none) |
-| `/mos:room` | View, add, or export Data Room sections | (none) |
+- **Source of truth:** the `frameworks:` key in each `commands/*.md` frontmatter (one place, nothing else asserts it). Contract: `docs/COMMAND-FRONTMATTER.md`.
+- **Generated registry:** `data/command-registry.json` -- built from that frontmatter by `scripts/build-command-registry.cjs`; never hand-edited. A pre-commit tripwire (`build-command-registry.cjs --check`) and the Feynman test runner fail the build on a stale registry or an unresolvable framework name.
+- **The only door at runtime:** `lib/workflow/command-resolver.cjs` (`commandsForFramework(<framework>)`, `composeWorkflow(<framework-chain>)`, `validateChainAutonomy(...)`). Larry never names a `/mos:` command from memory -- every command he surfaces came back from the resolver. If a framework has no command yet, the resolver returns `null` and the answer is "run it manually" (degrade, do not fabricate).
+- **The Brain side:** `lib/brain/chain-recommender.cjs` ranks WHICH frameworks to chain next via the Brain's `FEEDS_INTO` traversal -- framework names + problem-type enums only. Turning a recommended framework into a `/mos:` command is the resolver's job, not the Brain's. Commands NEVER enter the Brain (Canon Part 8). See `docs/WORKFLOWS.md` for the full Brain <-> registry <-> Larry join.
 
----
-
-## Methodology Commands (26)
-
-| Command | Description | Default Room |
-|---------|-------------|--------------|
-| `/mos:beautiful-question` | Reframe your challenge into a question worth answering -- Why / What If / How | problem-definition |
-| `/mos:map-unknowns` | Map what you know, don't know, and can't see -- Known/Unknown Matrix | problem-definition |
-| `/mos:challenge-assumptions` | Stress-test your assumptions before the market does -- Devil's Advocate | competitive-analysis |
-| `/mos:analyze-systems` | Decompose complex systems into layers -- find where leverage lives | solution-design |
-| `/mos:leadership` | Leadership coaching -- what kind of leader does your team actually need? | team-execution |
-| `/mos:lean-canvas` | Build your business model on one page -- 9 boxes, no fluff | business-model |
-| `/mos:systems-thinking` | See feedback loops, stocks, flows, and leverage points in your system | solution-design |
-| `/mos:explore-domains` | Map the innovation domains around your venture -- find where fields collide | problem-definition |
-| `/mos:structure-argument` | Build a Minto Pyramid -- structure your thinking top-down | problem-definition |
-| `/mos:think-hats` | Six Thinking Hats -- explore your problem from 6 perspectives | solution-design |
-| `/mos:analyze-needs` | Jobs to Be Done -- discover what progress your customers hire for | market-analysis |
-| `/mos:find-bottlenecks` | Reverse Salient -- find the bottleneck holding your system back | solution-design |
-| `/mos:build-thesis` | Build an investment thesis -- structure your venture's narrative | financial-model |
-| `/mos:grade` | Assess your progress -- get honest feedback on your venture thinking | (all rooms) |
-| `/mos:explore-trends` | Trending to the Absurd -- push current trends to their logical extreme | market-analysis |
-| `/mos:analyze-timing` | S-Curve analysis -- is the technology ready? Is the market ready? | market-analysis |
-| `/mos:scenario-plan` | Map plausible futures and prepare for each | market-analysis |
-| `/mos:validate` | Check claims against evidence -- Validation Compass | competitive-analysis |
-| `/mos:build-knowledge` | Ackoff's Pyramid -- climb from data to wisdom | problem-definition |
-| `/mos:explore-futures` | Oracle -- explore long-range futures and weak signals | market-analysis |
-| `/mos:root-cause` | Trace problems to their source -- 5 Whys, Fishbone, and more | problem-definition |
-| `/mos:macro-trends` | Identify large-scale shifts affecting your domain | market-analysis |
-| `/mos:dominant-designs` | Analyze convergence patterns in your market | competitive-analysis |
-| `/mos:user-needs` | Deep dive into user behavior and motivation | market-analysis |
-| `/mos:score-innovation` | HSI scoring -- cross-domain innovation opportunity assessment | (all rooms) |
-| `/mos:diagnose` | Problem type classification + framework recommendation | (none) |
-
----
-
-## Venture Stage Routing
-
-| Venture Stage | Recommended Commands |
-|---------------|---------------------|
-| **Pre-Opportunity** | new-project, beautiful-question, explore-domains, explore-trends, map-unknowns |
-| **Discovery** | analyze-needs, challenge-assumptions, explore-domains, structure-argument, build-knowledge |
-| **Validation** | validate, find-bottlenecks, analyze-timing, map-unknowns, challenge-assumptions |
-| **Design** | think-hats, structure-argument, scenario-plan, analyze-systems, systems-thinking, lean-canvas |
-| **Investment** | build-thesis, grade, root-cause, build-knowledge, score-innovation |
-
----
-
-## Brain-Powered Commands (5)
-
-*Require Brain MCP connection. Run `/mos:setup brain` to enable.*
-
-| Command | Description | Default Room |
-|---------|-------------|--------------|
-| `/mos:suggest-next` | Graph-informed recommendation -- what should you work on next? (Requires Brain) | (none) |
-| `/mos:find-connections` | Cross-domain pattern discovery -- what connects to your work? (Requires Brain) | (none) |
-| `/mos:compare-ventures` | Who else did something like this -- and what happened? (Requires Brain) | (none) |
-| `/mos:deep-grade` | Calibrated venture assessment -- scored against 100+ real projects (Requires Brain) | competitive-analysis |
-| `/mos:research` | External web research with Brain cross-reference -- find evidence for your venture (Requires Brain) | market-analysis |
+For a human-readable list of commands with descriptions, see `commands/help.md` (the `/mos:help` surface) or `docs/COMMAND-FRONTMATTER.md`. For the closed-loop picture, see `docs/WORKFLOWS.md`.
 
 ---
 
 ## Design-by-Analogy Reference Files
 
+These are reference *data* files (not a framework-to-command map), loaded on demand by the Design-by-Analogy pipeline:
+
 | File | Description |
 |------|-------------|
 | `triz-matrix.json` | 39x39 TRIZ contradiction matrix mapping engineering parameter pairs to inventive principles |
@@ -88,10 +31,4 @@ Used by the Design-by-Analogy pipeline (`/mos:find-analogies`) and `enrichContra
 
 ## Brain Enhancement
 
-When Brain MCP is connected, methodology commands gain:
-- Contextual framework chaining (Brain recommends the perfect next framework)
-- Calibrated grading (100+ real student projects)
-- Cross-domain pattern matching (21K+ knowledge graph nodes)
-- Framework sequencing based on your specific room state
-
-Without Brain, all commands work using embedded reference definitions.
+When Brain MCP is connected, methodology commands gain contextual framework chaining (the Brain ranks the next framework via `FEEDS_INTO`), calibrated grading (100+ real student projects), and cross-domain pattern matching (21K+ knowledge graph nodes). Without Brain, all commands work using embedded reference definitions. Either way, the framework-to-command mapping comes from the plugin-local `data/command-registry.json` via `lib/workflow/command-resolver.cjs` -- not from the Brain, not from memory.

package/skills/brain-connector/SKILL.md

@@ -90,13 +90,11 @@ RETURN f.name AS available_framework
 
 ## Brain-Powered Command Suggestions
 
-Brain has Command nodes linked to Frameworks, VentureStages, SignalTypes. Level 3 intelligence from 100+ real projects.
+**The command for a framework is whatever `command-resolver.commandsForFramework(<framework>)` returns** (`lib/workflow/command-resolver.cjs`, reading the generated `data/command-registry.json`) -- or, if none, "run <framework> manually -- there is no /mos: for it". For a chain, use `composeWorkflow(<framework-chain>)`. **Commands NEVER live in the Brain (Canon Part 8): the Brain holds methodology -- the FEEDS_INTO chains -- and the `recommendFrameworkChain` traversal in `lib/brain/chain-recommender.cjs` carries framework names + problem-type enums only, never a command string, never user content; the plugin-local registry holds the framework-to-command mapping.** Larry never names a `/mos:` from memory. If the resolver returns nothing, the answer is "run <framework> manually".
 
-Query `brain_proactive_command` for ranked suggestions with JTBD framing, trigger conditions, stage impact. Pick top match for current Room Signals. Present via JTBD formula from Command node fields.
+The Brain ranks WHICH frameworks to suggest next (the FEEDS_INTO traversal in `lib/brain/chain-recommender.cjs`); turning a recommended framework into a `/mos:` command is the resolver's job, not the Brain's, not memory. Fallback when the Brain is unreachable: local Room heuristics from the navigation engine + the `larry-personality` skill -- still resolving any command through `lib/workflow/command-resolver.cjs`.
 
-Multi-hop: Room frameworks -> FOLLOWS_FRAMEWORK -> Command -> TRIGGERED_BY_SIGNAL -> Signals -> RELEVANT_AT_STAGE -> Stage
-
-Fallback: local Room heuristics from larry-personality provoked suggestions.
+See `docs/WORKFLOWS.md` for the full Brain <-> registry <-> Larry join and the Canon Part 8 boundary.
 
 ## Delegation
 

package/skills/pws-methodology/SKILL.md

@@ -8,17 +8,19 @@ description: >
 
 # PWS Methodology -- Framework Routing
 
-## Brain-First, References-Fallback
+## The Resolver Is the Only Door
 
-If Brain is connected, use it for framework suggestions -- it knows room state and recommends contextually. Otherwise, load `references/methodology/index.md` for the command routing index.
+Framework-to-command routing goes through `lib/workflow/command-resolver.cjs` -- the generated `data/command-registry.json` (built from each command's frontmatter, validated against the Brain's framework names). Larry NEVER names a `/mos:` command from memory: every command Larry surfaces came back from the resolver (`commandsForFramework(<framework>)`, or `composeWorkflow(<framework-chain>)` for a sequence). If a framework has no command yet, say so -- "run <framework> manually -- there is no /mos: for it" -- never invent one (degrade, do not fabricate).
 
-## 26 Methodology Commands
+The Brain still informs WHICH frameworks to chain (the FEEDS_INTO traversal, via `lib/brain/chain-recommender.cjs` `recommendFrameworkChain` -- framework names + problem-type enums only; Canon Part 8: the Brain holds methodology, never commands). The plugin-local registry holds the framework-to-command mapping. When the Brain is unreachable, the resolver still gives framework -> command from the registry; when there is no registry either, fall back to framework-only advice. Each layer fails to a true statement.
 
-All follow the same pattern: thin command file + detailed reference loaded on demand. Each produces structured artifacts filed to the Data Room with user confirmation. Full list: `references/methodology/index.md`.
+## Methodology Commands
+
+All follow the same pattern: thin command file + detailed reference loaded on demand. Each produces structured artifacts filed to the Data Room with user confirmation. The authoritative framework -> command index is `data/command-registry.json` (resolved via `lib/workflow/command-resolver.cjs`); the frontmatter contract is `docs/COMMAND-FRONTMATTER.md`; the closed-loop picture is `docs/WORKFLOWS.md`. (`references/methodology/index.md` is now just a pointer to those -- it no longer hand-maintains a command table.)
 
 ## Framework Routing Rule
 
-When Larry recognizes a problem type, apply the methodology through conversation, never by announcing it. The index enables `/mos:help` to recommend commands based on room state.
+When Larry recognizes a problem type, apply the methodology through conversation, never by announcing it. To recommend a command (e.g. for `/mos:help` or `/mos:suggest-next`), resolve the framework through `lib/workflow/command-resolver.cjs` / the generated registry -- never name a `/mos:` from memory.
 
 ## Design-by-Analogy (DbA)