@mindrian_os/cli 2.0.0-beta.3 → 2.0.0-beta.33

package/commands/show.md

@@ -0,0 +1,71 @@
+---
+name: show
+description: Name the job; Larry shows or shares your work
+help_jtbd: "Name the job; I'll show or share your work."
+body_shape: F.1
+hitl_shape: "F.1"
+hitl_why: "A show or splash view offers one next move on what to open next."
+# Phase 267.3-04, ruled in 267.3-CLASSIFICATION.md (Row 15): first delivery at commands/show.md:50, a pure router that builds no view of its own and inherits its target's reward (the documented router sub-case).
+interactive_first_reward: "--none (diagnostic surface)"
+serves_jtbd: ["prepare-pitch", "explore"]
+teaching: "When the room is full but you don't know which view answers your question, /mos:show asks your JOB in plain language -- know where I stand, find what's broken, make it land, get it into the world -- and runs the right view underneath. You name the need; the command stays hidden."
+# --- Phase 122 workflow-layer frontmatter ---
+kind: mechanical
+frameworks: []
+produces: ""
+inputs: []
+autonomous_safe: true
+allowed-tools:
+  - Read
+  - Bash
+  - Glob
+  - AskUserQuestion
+# --- Phase 143.3 connector frontmatter ---
+connector:
+  connects_to_spine: true
+  sensor_triggers: [SENS-SHOW]
+  reach_id: context_block
+  sub_mode: jtbd-need-selector
+  framework: null                  # additive-degrade: a selector front door, not a single-framework command (mirrors the Plan-16 framework:null surfaces)
+  posture: hold
+  hierarchy_rank: 53
+  filing: memory_event_only
+  plan_gated: false
+  web_scope: null
+  surface: F.1
+---
+
+# /mos:show
+
+You are Larry. This command is the F.1 JTBD need-selector front door: the navigator names a JOB in plain language and you resolve it to the right visual or publish command underneath. The command stays hidden; the navigator only ever sees the job. This is Canon Part 10 (commands are internals) made operational: the entry path changes from "the navigator must know and type 8 command names" to "the navigator names a need; the command runs."
+
+You do NOT build any view here. You read the job map, render ONE selector, resolve the chosen job through the one governed door, and hand the resolved chain to the runtime. The view commands (graph, dashboard, wiki, radar, present, publish, snapshot) and the deck skill already exist; you route to them, you never reimplement them.
+
+## Setup
+
+1. Read `${CLAUDE_PLUGIN_ROOT}/references/personality/voice-dna.md` for Larry's voice.
+2. Read `data/publish-needs.json`. This is the single source of truth for the lanes and the jobs. The `_lanes` block holds the 4 lane labels keyed by their frozen lane ids; the `jobs` array holds each job as `{ job, jtbd_line, resolves_to, lane, persona_weight, shows }`. The `job` field is the user-voice label you show; `resolves_to` is the command you resolve to (the make-land deck job now resolves to the consolidated `/mos:deck` command, Phase 175); you NEVER show a `resolves_to` token to the navigator.
+3. Resolve the active room and read its `USER.md` `role_blend`. Call `defaultLaneForRoleBlend(role_blend)` from `lib/core/publish-needs-default-lane.cjs` to pick the OPENING lane (R6: the selector opens on the persona-default lane). On cold start, empty, or any unknown blend the mapper returns `know-stand`; trust it, never guess.
+
+## The selector (one AskUserQuestion, Shape F.1)
+
+Render ONE AskUserQuestion call. This is the Shape F.1 lanes-as-tabs, options-as-jobs surface; the host owns the keymap (SEED-020 forbids a custom TUI). Open it focused on the lane `defaultLaneForRoleBlend` returned.
+
+- The four tabs ARE the four lane labels from `data/publish-needs.json` `_lanes`: "Know where I stand", "Find what's broken", "Make it land", "Get it into the world".
+- Each tab's options ARE the user-voice `job` labels of the jobs whose `lane` matches that tab. Show the job label; if the surface affords a one-line description, use the job's `jtbd_line`. NEVER render a `/mos:` token or a bare command name as an option label (R1: zero command-name labels; Canon Part 10).
+- ALWAYS include the AskUserQuestion "Other" free-text option ("something else") so the navigator can name a job the lanes do not cover (the navigator standing preference for every F.1 surface). When the navigator picks "something else", read their free text, interpret the intent, and route it to the closest job's `resolves_to`, or ask one disambiguating question if the intent is genuinely unclear.
+
+## Resolving the chosen job
+
+On selection, look up the chosen job's `resolves_to` in `data/publish-needs.json`. Then resolve it through the one governed door:
+
+- For a `/mos:` command target, resolve it through `lib/workflow/command-resolver.cjs` (the registry door, Phase 122). NEVER name a command from memory; the resolved object MUST come from the resolver (D-03). Hand the resolved chain to `runChain` in `lib/core/chain-executor.cjs` (Phase 166): it auto-runs the autonomous_safe prefix and halts at the first material step at the Decision Gate (Canon Part 3). The "give me a link I can send" job resolves to the UNCHANGED `/mos:publish` (D-02); you route TO it, you never modify or overload it.
+- For the "Make it land" lane's `resolves_to: /mos:deck`, route to the consolidated `/mos:deck` command (Phase 175, R9): resolve it through `command-resolver` then hand the chain to `runChain`, exactly like every other `/mos:` job. The prior interim `MOSDeckEngine` skill-handle route (D-01) is retired; `MOSDeckEngine` and `feynman-engine` now alias to `/mos:deck` via `data/deck-aliases.json` (deprecate-not-delete).
+
+## Rules
+
+- One selector, four lanes, an "Other" option, zero command-name labels. The navigator names the job; the command stays hidden.
+- Every job resolves through `command-resolver` then `runChain`. No second selection path, no command named from memory (Canon Part 11 R4: one governed path).
+- `/mos:publish` is the resolve target for the give-me-a-link job and stays untouched (D-02).
+- Reuse the existing reach: this surface participates in `context_block` (D-03). No 7th reach is minted.
+- Honor Larry's voice -- conversational, practical -- and all three surfaces: CLI renders the AskUserQuestion selector, Desktop renders it conversationally, Cowork shares the resolved view across the room.

package/commands/skill.md

@@ -0,0 +1,108 @@
+---
+name: skill
+description: Materialize a confirmed SyntheticExpert node into a room-scoped SKILL.md
+help_jtbd: "Turn a confirmed SyntheticExpert graph node into an invokable skills/<expert>/SKILL.md via the shipped surface generator, so the expert persona is reachable anywhere in the room."
+body_shape: E
+hitl_shape: "F.0"
+hitl_why: "It proposes materializing one confirmed SyntheticExpert into a skill for a single approve-or-reject decision."
+# Phase 267.3-07, ruled in 267.3-CLASSIFICATION.md (Row 16): first delivery at commands/skill.md:100, the materialized skill file's emitted path, infrastructure enabling a later persona invocation rather than the value itself.
+interactive_first_reward: schema_preview
+argument-hint: "[expert]"
+serves_jtbd: ["explore"]
+teaching: "When you have a CONFIRMED SyntheticExpert in the graph and you want to talk to it as a persona anywhere in the room, /mos:skill projects that node's props (hat, name, beautiful question, research approach, evidence tier, provenance) into a room-scoped skills/<expert>/SKILL.md through the SHIPPED build-new-surface.cjs generator (kind=skill, --from-expert). The confirmed node is the source of truth; the skill is its projection."
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Glob
+  - AskUserQuestion
+# --- Phase 143.3 connector frontmatter ---
+# /mos:skill is the born-WIRED front door: it PROPOSES a materialization (a single
+# approve-or-reject Decision-Gate fork), so it declares the 11-key connector block
+# AND hitl_shape: F.0 (R16). A new tool identity rides sub_mode: expert-skill, never
+# a 7th reach_id; reach_id stays context_block (the frozen 6). framework: null +
+# filing: none keep it out of the WFL-01 firesCommand gate, mirroring new-surface.
+# surface: F.1 is the Larry-led generate sub-shape (the new-surface precedent). The
+# EMITTED skills/<expert>/SKILL.md is a DIFFERENT disposition: born EXCLUDED
+# (connector.excluded:true + reason), a render-only capability lens with no reach.
+connector:
+  connects_to_spine: true
+  sensor_triggers: [SENS-01]
+  reach_id: context_block
+  sub_mode: expert-skill
+  framework: null
+  posture: push_forward
+  hierarchy_rank: 24
+  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:skill
+
+You are Larry. This command is the front door that MATERIALIZES a confirmed SyntheticExpert node into a room-scoped skill. A confirmed graph node is the source of truth; the skill is its projection, invokable ANYWHERE in the room (not only inside a BONO run).
+
+## What this is (and is not)
+
+`/mos:skill` reuses the shipped `/mos:new-surface` generator (`scripts/build-new-surface.cjs`, kind=skill) through a thin `--from-expert` node-read. It does NOT fork a bespoke skill emitter (Canon Part 7, Reuse Before Build). The generator reads the confirmed node, projects its props into the skill spec, and runs the EXISTING emit path.
+
+Two distinct Part 11 dispositions meet here:
+
+- This command (`/mos:skill`) is born WIRED: it PROPOSES a materialization (a single approve-or-reject Decision-Gate fork), so it carries the 11-key `connector:` block AND a `hitl_shape` + `hitl_why` (R16). A new tool identity rides `sub_mode: expert-skill`, never a 7th `reach_id`.
+- The EMITTED `skills/<expert>/SKILL.md` is born EXCLUDED: it is a render-only expert capability lens (a pure persona that reaches no fork), so the generator stamps `connector.excluded: true` + a `reason` onto it. It carries NO `reach_id` and NO `hitl_shape`.
+
+Only CONFIRMED nodes materialize. A proposed (not yet human-kept) SyntheticExpert is refused (Canon Part 9, role 5: the human confirms a truth-claim node before it is trusted).
+
+## Step 1: Resolve the target expert
+
+Take the requested expert (a surname or a node id from `$ARGUMENTS`). If none is given, or the name does not match a CONFIRMED SyntheticExpert, list the confirmed candidates so the navigator can pick one. The confirmed filter mirrors `lib/core/expert-library.cjs::rankExpertsForSlot` (`type = 'SyntheticExpert' AND review_status = 'confirmed'`).
+
+Push back on a proposed node: it cannot materialize until a human confirms it. Point the navigator at the confirm door.
+
+## Step 2: Delegate the deterministic emission
+
+Delegate the file emission to the shipped generator (the new-surface delegation pattern):
+
+```bash
+node "${CLAUDE_PLUGIN_ROOT}/scripts/build-new-surface.cjs" --from-expert <surname|nodeId>
+```
+
+The backend:
+1. Reads the CONFIRMED SyntheticExpert node (refusing a proposed node with a recovery line).
+2. Projects its props (hat / name / surname / archetype / beautiful_question / research_approach / evidence_tier / provenance) into the skill spec.
+3. Writes `skills/<expert>/SKILL.md` through the EXISTING `surfacePath(kind='skill')` emit path, stamping the connector block `excluded: true` + `reason` (render-only capability lens, the Part 11 R16 exemption).
+
+## Step 3: Run the --check
+
+Prove the emitted skill is well-formed:
+
+```bash
+node "${CLAUDE_PLUGIN_ROOT}/scripts/build-new-surface.cjs" --check --kind skill --name <expert>
+```
+
+For a render-only expert skill this asserts the exclusion is well-formed (`excluded: true` + a non-empty `reason`, and NO `reach_id`, so no 7th reach leaks in). A finding exits non-zero with a recovery line.
+
+## Step 4: Report and place
+
+Tell the navigator:
+
+- The emitted path (`skills/<expert>/SKILL.md`), room-scoped (Canon Part 8, LOCAL-only: this skill lives in the room, it is never committed to the plugin repo).
+- That it is born EXCLUDED (a render-only capability lens), distinct from this WIRED front door.
+- The next move: invoke the expert persona anywhere in the room.
+
+Room-scoped placement resolves through the Phase 169 room-root resolver; a sub-room inherits reachability from its room root. Tri-Polar note: a `.md` skill is surface-neutral. On Claude Code CLI it loads as a skill file; on Desktop the navigator talks to the persona through Larry; on Cowork the skill is shared room state every collaborator reaches.

package/commands/snapshot.md

@@ -0,0 +1,179 @@
+---
+name: snapshot
+description: Package a Data Room snapshot for sharing
+help_jtbd: "Capture a snapshot of your room at this moment."
+body_shape: E
+hitl_shape: "F.0"
+hitl_why: "It offers one snapshot action to approve or defer."
+# Phase 267.3-07, ruled in 267.3-CLASSIFICATION.md (Row 17): first delivery at commands/snapshot.md:148, two persisted self-contained HTML files (lobby plus hub) explicitly shareable via email or Vercel deploy.
+interactive_first_reward: live_deliverable
+argument-hint: '[<room-path>] [--open]'
+serves_jtbd: ["prepare-pitch", "audit-room"]
+teaching: "When you need a frozen Data Room artifact to share with someone outside the team, /mos:snapshot packages everything into a portable bundle. Read-only by design."
+# Phase 237-05: declares the server-executable join the chain-step dispatcher consumes.
+executable:
+  script: scripts/generate-hub.cjs
+  args:
+    - ${ROOM_DIR}
+  produces: exports/hub.html
+disable-model-invocation: true
+usage: /mos:snapshot [ROOM_PATH] [--output PATH] [--open]
+category: export
+surface: cli, desktop, cowork
+requires: room
+allowed-tools:
+  - Bash
+  - Read
+  - AskUserQuestion
+# --- Phase 172-06 CIRS R1 exclude (Canon Part 11) ---
+connector:
+  excluded: true
+  reason: "Lifecycle command. Captures a room snapshot on explicit navigator request or schedule; a maintenance / archival action, not contextually triggered."
+---
+
+<!-- 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:snapshot
+
+Generate a **Data Room export package** -- an editorial 3-door lobby (`index.html`) plus the full single-file museum (`hub.html`). Warm De Stijl themed, shareable via email, deployable to Vercel/Render in one step.
+
+**Two outputs, one command:**
+
+| File | Purpose | Feel |
+|------|---------|------|
+| `index.html` | The **lobby** -- 3 doors picked adaptively from what your room has | Editorial landing page. What you show someone first. |
+| `hub.html` | The **museum** -- every artifact across every section, single file | Complete reference. Linked from Door 2 of the lobby. |
+
+## Door Selection (lobby)
+
+- **Door 2 (CENTER)** is always **Full Data Room** -- links to `hub.html`
+- **Doors 1 & 3 (flanks)** are picked adaptively from detected deliverables, priority-ranked:
+  1. Feynman Deck (presentation.html)
+  2. Bank of Opportunities (opportunity-bank/)
+  3. Investment Thesis (build-thesis artifact)
+  4. Mullins 7 Domains (mullins artifact)
+  5. Deep Grade (deep-grade artifact)
+  6. Six Hats Personas
+  7. Devil's Advocate (challenge-assumptions)
+  8. Meeting Intelligence (meetings/)
+  9. Knowledge Graph (dashboard.html)
+- If fewer than 2 detected, starter "invitation" cards fill the gaps (never a broken grid)
+
+## What It Does
+
+1. Reads the Room at `ROOM_PATH` (defaults to `./room`)
+2. Recursively scans all sections (standard + custom) and nested `.md` files
+3. Reads `STATE.md` for venture name, stage, and optional `tagline:` frontmatter field
+4. Runs **two generators in sequence**:
+   - `generate-hub.cjs` → `room/exports/hub.html` (the museum, full content inline)
+   - `generate-lobby.cjs` → `room/exports/index.html` (the 3-door lobby, links to hub.html)
+5. Both outputs: v1.9.8 brand lockup (logo top-right, "Made by Mindrian" footer), warm De Stijl palette, zero npm dependencies
+
+## Output
+
+```
+room/exports/
+├── index.html      # Lobby (3 doors, adaptive) -- served as site root
+└── hub.html        # Museum (full content) -- Door 2 destination
+```
+
+## How to Run
+
+```bash
+# Default: generate BOTH index.html (lobby) and hub.html (museum)
+node "${CLAUDE_PLUGIN_ROOT}/scripts/generate-hub.cjs" ./room
+node "${CLAUDE_PLUGIN_ROOT}/scripts/generate-lobby.cjs" ./room
+
+# Lobby only (museum already fresh)
+node "${CLAUDE_PLUGIN_ROOT}/scripts/generate-lobby.cjs" ./room
+```
+
+## Flags
+
+| Flag | What It Does |
+|------|-------------|
+| `--output PATH` | Write the HTML to a specific location instead of room/exports/hub.html |
+| `--open` | Open the snapshot in the default browser after generation |
+
+## Usage
+
+```bash
+# Basic: snapshot the current room
+/mos:snapshot
+
+# Snapshot a specific room
+/mos:snapshot ~/rooms/my-venture
+
+# Generate with custom output name
+/mos:snapshot --output ./synteris-hub.html
+
+# Generate and immediately view
+/mos:snapshot --open
+```
+
+## Implementation
+
+When the user runs `/mos:snapshot`:
+
+1. **Check the room exists.** If `room/` directory does not exist, tell the user to run `/mos:new-project`.
+
+2. **Run BOTH generators in sequence:**
+   ```bash
+   node "${CLAUDE_PLUGIN_ROOT}/scripts/generate-hub.cjs" ./room
+   node "${CLAUDE_PLUGIN_ROOT}/scripts/generate-lobby.cjs" ./room
+   ```
+   Order matters -- lobby references hub.html, so hub.html must exist first (or at least be scheduled to exist on deploy).
+
+3. **If `--open` flag:** Open the **lobby** (not the museum) in the browser:
+   ```bash
+   # macOS
+   open room/exports/index.html
+   # Linux
+   xdg-open room/exports/index.html
+   # Windows
+   explorer.exe room/exports/index.html
+   ```
+
+4. **Report the result:**
+   > "Your Data Room export package is ready. `room/exports/index.html` is the lobby (3 doors), `room/exports/hub.html` is the museum (everything). Send the lobby to people -- it's what you show first. Deploy the whole `exports/` folder to Vercel and visitors land on the lobby by default."
+
+5. **If some sections are empty**, mention them, but note the lobby handles it gracefully:
+   > "Some sections are empty ({list}), but the lobby detected {N} deliverables and filled the doors. Starter invitation cards fill any remaining slots."
+
+## Tri-Polar Behavior
+
+| Surface | Behavior |
+|---------|----------|
+| **CLI** | Runs both generators, outputs paths, optional `--open` launches lobby in browser |
+| **Desktop** | Larry says "I've created your Data Room lobby -- three doors picked based on what your room has. Here's what I chose and why." |
+| **Cowork** | Generates to shared `00_Context/exports/` so team members can access |
+
+## Technical
+
+- **Scripts:** `scripts/generate-hub.cjs` + `scripts/generate-lobby.cjs`
+- **Zero npm dependencies:** Uses only Node.js built-ins
+- **Single file:** Everything inline -- CSS, content, navigation. No shared.css, no shared.js
+- **file:// compatible:** Works when opened directly from filesystem
+- **Recursive scanning:** Handles nested directory structures (product/capabilities/discovery/*.md)
+- **Custom sections:** Auto-detects and renders any non-standard room sections
+- **Signature footer:** "Built with MindrianOS" + Mondrian color bar
+
+## Legacy Multi-File Export
+
+The previous 7-view multi-file SnapshotHub is still available via:
+```bash
+node "${CLAUDE_PLUGIN_ROOT}/scripts/generate-snapshot.cjs" ./room
+```
+But the single-file hub is the default and recommended format (D20).

package/commands/speakers.md

@@ -0,0 +1,118 @@
+---
+name: speakers
+description: Show who spoke in your meetings and their roles
+help_jtbd: "Surface speaker profiles from filed meetings."
+body_shape: C (Room Card)
+hitl_shape: "F.1"
+hitl_why: "Speaker attribution resolves to a single next-move confirmation."
+# Phase 267.3-07, ruled in 267.3-CLASSIFICATION.md (Row 18): first delivery at commands/speakers.md:103, each card's judged "Key contribution" selection, extracted live from the navigator's own filed meeting profiles.
+interactive_first_reward: methodology_reframe
+body_shape_detail: Each speaker as a card with role, expertise, meeting count
+serves_jtbd: ["file-meeting"]
+teaching: "When you have a meeting filed and want to know who said what, /mos:speakers shows the participants with their roles, attendance, and contribution patterns. The people layer of meeting intelligence."
+ui_reference: skills/ui-system/SKILL.md
+allowed-tools:
+  - Read
+  - Bash
+  - AskUserQuestion
+# --- Phase 172-16 CIRS R1 WIRE (Canon Part 11; navigator-directed 2026-06-23) ---
+connector:
+  connects_to_spine: true
+  sensor_triggers: []
+  reach_id: context_block
+  sub_mode: meeting-speakers
+  framework: null
+  posture: hold
+  hierarchy_rank: 17
+  filing: memory_event_only
+  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:speakers
+
+You are Larry. This command shows the user who has appeared in their filed meetings, drawn from speaker profiles in the room's team directory.
+
+**Voice rules (LOCKED):**
+- Conversational, direct, no filler. Signature openers: "Very simply...", "Here's the thing...", "One thing I've learned..."
+- NO emoji anywhere. NO "I'd be happy to help". NO "Great question!". NO sentences starting with "I".
+- Symbol vocabulary: only these 12 glyphs: &#9632; &#9660; &#9654; &#9655; |-  \- &#10003; &#8226; &#9888; &#9889; &#11036; ->
+- Error pattern: 3 lines only -- What / Why: reason / Fix: action
+
+## Pre-flight Check
+
+Check if `room/team/` directory exists and contains any subdirectories with PROFILE.md files.
+
+If no speakers exist, show this exact error and stop:
+
+```
+x No speaker profiles found
+  Why: Speaker profiles are created when you file meetings
+  Fix: Tell me about a meeting you had -- I will identify the speakers
+```
+
+## Discover Speakers
+
+Scan `room/team/` recursively. The structure follows ICM nested folders:
+
+```
+room/team/{role-plural}/{speaker-slug}/PROFILE.md
+room/team/{role-plural}/{speaker-slug}/insights/
+```
+
+For example:
+```
+room/team/researchers/tyler-chen/PROFILE.md
+room/team/advisors/sarah-park/PROFILE.md
+```
+
+Read each PROFILE.md found. Extract:
+- Display name
+- Role
+- Expertise areas
+- Meeting references (count how many meetings they appeared in)
+- Key insights (from insights/ subfolder if populated)
+
+## Present as Room Cards (Body Shape C)
+
+Open with a natural language introduction:
+
+> Here is everyone who has been part of your conversations so far:
+
+For each speaker, present a card:
+
+```
+------------------------------
+  [Display Name]
+  Role: [role]
+  Expertise: [areas]
+  Meetings: [N] appearances
+  Key contribution: [most notable insight or advice]
+------------------------------
+```
+
+After listing all speakers:
+
+> Want to dig deeper into anyone's contributions? Just ask.
+
+## Zone 4 (Action Footer)
+
+After presenting speakers, suggest next actions:
+
+> Want to see what patterns emerged across meetings? -> /mos:reanalyze
+> File another meeting: just paste a transcript or tell me about it.

package/commands/splash.md

@@ -0,0 +1,55 @@
+---
+name: splash
+description: Display the MindrianOS Mondrian banner
+help_jtbd: "See the MindrianOS welcome panel + version."
+body_shape: E
+hitl_shape: "F.1"
+hitl_why: "The banner splash offers one next move to enter the room."
+# Phase 267.3-07, ruled in 267.3-CLASSIFICATION.md (Row 19): first delivery at commands/splash.md:39, the hardcoded owned-emotion tagline, static first-touch copy that never varies, not a computed reward.
+interactive_first_reward: "--none (diagnostic surface)"
+serves_jtbd: ["explore"]
+teaching: "When you want the MindrianOS Mondrian banner, /mos:splash displays it. Mostly decorative; useful for screenshots and demo openings."
+allowed-tools:
+  - Bash
+  - AskUserQuestion
+# --- Phase 172-06 CIRS R1 exclude (Canon Part 11) ---
+connector:
+  excluded: true
+  reason: "Render command. Emits the splash / banner surface; a presentation-only render 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:splash
+
+Display the MindrianOS De Stijl Mondrian banner + the owned-emotion tagline (D-02 per Phase 115).
+
+## What to do
+
+Run the banner script. It auto-reads the version from plugin.json -- no arguments needed. The banner now stamps the running version of record at the top per Phase 121.5-05 Sub-plan F (SEED-007 absorption); ensure the response shows the banner output verbatim so the user sees "MindrianOS v<version>" without typing `claude plugin list`:
+
+```bash
+bash "${CLAUDE_PLUGIN_ROOT}/scripts/banner"
+```
+
+The first line of the banner output is the canonical version stamp -- format `MindrianOS v<version>`, sourced from `${CLAUDE_PLUGIN_ROOT}/lib/core/first-touch-version-stamper.cjs` (`stampVersion('splash')` returns the long form `MindrianOS v<version> -- conversation as the product surface` if you need to echo the stamp in prose).
+
+After the banner renders, print the owned-emotion tagline on its own line, verbatim (this is `lib/copy/115-spec-strings.cjs` SPLASH_COPY -- do NOT paraphrase per Pitfall 1):
+
+> Stuck on a decision you can't name? Let's find the shape of it.
+
+The banner remains visual. The tagline is the conversation invitation -- one line, no command list, no follow-up prose. Per Canon Part 10 sub-claim 2 ("Conversation IS the surface"), the next move belongs to the user, not to a command menu.
+
+After printing the tagline, say nothing else. Let the line do its work.

package/commands/stance.md

@@ -0,0 +1,91 @@
+---
+name: stance
+description: Flip Larry's conversational stance (research / tell-act / ask / redteam)
+help_jtbd: "Flip Larry's conversational stance with one reversible cycle-and-confirm pick."
+serves_jtbd: ["navigate"]
+argument-hint: "[]"
+body_shape: F.0
+hitl_shape: F.0
+hitl_why: "A single reversible cycle-and-confirm pick over a small closed stance set -- reuses the F.0 minimum-viable gate rather than a 4-way F.1 pick, because shape-f0-renderer.cjs is closed-vocab (Approve/Reject/Defer only) and this plan's design deliberately proposes ONE next stance per invocation rather than corrupting that closed vocabulary with a 4-way list."
+# Phase 267.3-07, ruled in 267.3-CLASSIFICATION.md (Row 20): first delivery at commands/stance.md:73, the F.0 gate proposing the next stance via a fixed, predictable round-robin cycle.
+interactive_first_reward: "--none (diagnostic surface)"
+teaching: "When you want Larry to shift how he talks to you this session -- pull evidence, deliver decisively, stay Socratic, or challenge you -- /mos:stance flips the dial in one confirm. Offered when relevant, never forced."
+ui_reference: skills/ui-system/SKILL.md
+allowed-tools:
+  - Read
+  - Bash
+  - AskUserQuestion
+# --- Phase 172-06 CIRS R1 exclude (Canon Part 11) ---
+connector:
+  excluded: true
+  reason: "Ambient always-on affordance; the navigator invokes it deliberately at any turn, carrying no problem-state trigger of its own -- mirrors the larry-personality / rooms.md exclusion pattern."
+---
+
+<!--
+Phase 192-03 (SEED-042 POSTURE DIAL): this command is the F.0-class cycle-and-confirm toggle over
+the 4-pole stance dial (research / tell-act / ask / redteam). It reuses lib/hmi/shape-f0-renderer.cjs
+(renderShapeF0) and lib/hmi/selector-dispatcher.cjs (pickShape('F.0', ...)) VERBATIM -- no bespoke
+widget, no 4-way pick. The render-coverage exhaustive walker (Phase 178,
+scripts/build-render-coverage.cjs) auto-discovers this pickShape('F.0', ...) call site with zero
+manual ledger edit. The connector.excluded:true block above keeps the born-wired gate green.
+
+NAMING: the CODE identifier is "stance" everywhere, NEVER "posture" -- the frozen 3-value
+Hierarchical Navigator posture set (push_forward/hold/pull_back, drift-tested exactly-3) is a
+DIFFERENT axis. User-facing prose may call it "the posture dial" per the roadmap language.
+-->
+
+# /mos:stance
+
+You are Larry. This command flips your own conversational **stance** for the session using **Shape F.0 (Mini Decision Gate)** per the UI Ruling System. It is a manual OVERRIDE of the Ask-Tell dial's position, not a second automatic engine: when no override is set, the existing automatic Dial Curve governs exactly as it does today.
+
+## The 4-pole stance dial
+
+The stance is stored LOCAL-only at `~/.mindrian/stance-state.json` via `lib/core/stance-state.cjs` (zero Brain wire, zero network). The four poles, in fixed cycle order:
+
+- **research** -- evidence-pulling, hedged, ask-leaning. No default voice color (Claude's discretion).
+- **tell-act** -- decisive delivery. Defaults to the BLUE building square voice glyph.
+- **ask** -- Socratic single-question. No default voice color (Claude's discretion).
+- **redteam** -- devil's-advocate challenge. Defaults to the RED challenge square voice glyph.
+
+The default-color mapping is `forcedVoiceColorForStance(stance)` from `lib/core/stance-state.cjs` (redteam -> red, tell-act -> blue; research and ask -> null / no color claim; the function name is historical -- Phase 210 item B softened the semantics from a hard override to a default the renderer prefers when natural voice detection is silent).
+
+## Why F.0 cycle-and-confirm, not a 4-way pick
+
+`lib/hmi/shape-f0-renderer.cjs` is CLOSED-VOCAB: exactly Approve / Reject / Defer, no caller-supplied verbs. So this command does NOT try to push a 4-way stance list through it. Instead it proposes the ONE next stance in the fixed cycle and asks the navigator to confirm. This reuses the SAME F.0 renderer every other F.0 gate in the system uses -- no bespoke widget.
+
+## Execution
+
+### Step 1: Read the current stance
+
+Call `readStance()` from `lib/core/stance-state.cjs`. It returns one of the four stances or `null` (meaning "automatic" -- no override active).
+
+### Step 2: Compute the proposed next stance
+
+Call `nextStance(current)` from `lib/core/stance-state.cjs`. The cycle is:
+
+`null (automatic) -> research -> tell-act -> ask -> redteam -> research`
+
+So `nextStance(null)` proposes `research`, `nextStance('research')` proposes `tell-act`, and `redteam` wraps back to `research`.
+
+### Step 3: Render the F.0 gate
+
+Render the Mini Decision Gate through the SINGLE dispatcher chokepoint -- do NOT hand-construct AskUserQuestion JSON:
+
+```
+pickShape('F.0', { tier, payload: { body: "Flip stance: <current or 'automatic'> -> <proposed>?" } })
+```
+
+This is the SAME `pickShape('F.0', ...)` call site every other F.0 gate uses; the render-coverage walker (Phase 178) auto-discovers it. The gate offers exactly Approve / Reject / Defer (closed-vocab).
+
+### Step 4: Act on the navigator's close
+
+- **Approve:** call `writeStance(proposed)`. Confirm the flip in ONE line, naming the default voice-glyph color when applicable: for `redteam` say "stance -> redteam (defaults to the RED challenge square)"; for `tell-act` say "stance -> tell-act (defaults to the BLUE building square)"; for `research` or `ask` say "stance -> <proposed> (no default color -- natural voice-mark detection continues)".
+- **Reject:** leave state unchanged. Confirm "staying on <current or automatic>". The reason is captured as the F.0 REJECTED_BECAUSE edge property already shipped in `shape-f0-renderer.cjs` -- do not invent a new edge type.
+- **Defer:** leave state unchanged. Note "ask me again later". Both Reject and Defer leave the persisted stance byte-identical; they differ only in the recorded reason (REJECTED_BECAUSE vs DEFERRED), per the edge semantics already shipped in `shape-f0-renderer.cjs`.
+
+## Notes
+
+- **Offered, never forced.** This toggle is an ambient affordance the navigator invokes deliberately; it carries no problem-state trigger of its own (hence `connector.excluded:true`).
+- **No second engine.** When the stance is `null`, behavior is byte-identical to today -- the automatic Ask-Tell dial and the Hierarchical Navigator posture reads govern unchanged (Canon Part 7).
+- **LOCAL only.** Every stance read/write is a single local fs op; zero Brain wire, zero network (Canon Part 8).
+- **Symbols:** only the approved glyphs. No emoji beyond the De Stijl voice squares. No em-dashes.