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

package/commands/ingest-methodology.md

@@ -0,0 +1,128 @@
+---
+name: ingest-methodology
+description: Maintainer pipeline to add a methodology to the remote Brain safely
+help_jtbd: "Add a new methodology to the Brain so every user can reach it - without ever leaking user data."
+serves_jtbd: ["build"]
+teaching: "Maintainer-only. When you want to teach the Brain a new methodology, /mos:ingest-methodology runs the 7-step pipeline - encode, Part-8 boundary gate, graph write, vector write, trigger + chain, register, local refresh - so the framework is reachable by every user and operable Local-Only, with zero user-data egress."
+body_shape: "action-report"
+hitl_shape: "F.9"
+hitl_why: "A methodology is parsed and registered through ordered steps, a fixed-order walk."
+# Phase 267.3-06, ruled in 267.3-CLASSIFICATION.md (Row 19): first delivery at commands/ingest-methodology.md:123, the pipeline's own "action report" of gate/write/registration results; a maintainer-only status of GENERIC teaching knowledge, never a navigator's venture data.
+interactive_first_reward: "--none (diagnostic surface)"
+kind: utility
+autonomous_safe: false
+disable-model-invocation: true
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Glob
+  - AskUserQuestion
+# --- Phase 172-12 connector frontmatter (CIRS R1 WIRED / R2 born-wired) ---
+# /mos:ingest-methodology is the maintainer surface for the CIRS born-wired
+# pipeline itself (lib/core/methodology-ingest.cjs ingestPlan step-5). It is WIRED
+# to the spine so the pipeline that makes every FUTURE methodology born-wired is
+# itself first-class in the coverage gate (the last gap -> 0). It is an admin
+# maintainer command (disable-model-invocation: true, autonomous_safe: false), so
+# it carries no sensor trigger (sensor_triggers: []) -- it declares the reach but
+# is not navigator-sensor-fired. It reuses the FROZEN brain_consult reach (the
+# methodology-lookup reach); NO 7th reach minted. framework:null (additive-degrade,
+# CONNECTOR-CONTRACT section 4) because the pipeline is methodology-agnostic -- it
+# ingests ANY framework, so no single resolvable :Framework name applies.
+connector:
+  connects_to_spine: true
+  sensor_triggers: []
+  reach_id: brain_consult
+  sub_mode: methodology-ingest
+  framework: null
+  posture: push_forward
+  hierarchy_rank: 60
+  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:ingest-methodology
+
+You are Larry, in MAINTAINER mode. This is an ADMIN pipeline: it writes a new
+methodology to the shared remote Brain (Neo4j + Pinecone). Only an operator with
+write-capable Brain access should run it. It is NOT a navigator-facing reach.
+
+It codifies the 7-step process used in Phase 170 (Adoption-Capacity Engine,
+Hooked Model, Self-Selling Loop) so every future methodology follows the same
+safe path. The engine is `lib/core/methodology-ingest.cjs` (pure, tested).
+
+## Input
+
+A normalized methodology spec (see the JSDoc in `lib/core/methodology-ingest.cjs`
+for the shape): name, description, methodology_tier (`pws` | `mindrian-operation`),
+mos_command, author, variables/cases/steps/critiques, chains_in, chains_out,
+trigger_lexicon. The spec must be GENERIC teaching knowledge - never a specific
+venture's data.
+
+## The pipeline (halt at the gate)
+
+1. **Encode.** Load the spec. Build the plan: `ingestPlan(spec)`.
+
+2. **Boundary gate (HARD HALT - Canon Part 8).** Run `auditSpecPart8(spec)`.
+   If `clean === false`, STOP and report the violations. Nothing is written to
+   the Brain until the spec is clean. The Brain holds generic methodology only;
+   user/venture data never crosses this line. This step is non-negotiable.
+
+3. **Graph write (Neo4j).** Take `buildFrameworkCypher(spec)` -> `{cypher, params}`
+   and run it via the `my-neo4j` MCP `write_neo4j_cypher` tool (parameterized;
+   the framework name is never string-interpolated). This MERGEs the Framework +
+   steps + cases + author + FEEDS_INTO chains, idempotently.
+
+4. **Vector write (Pinecone).** Take `buildPineconeRecords(spec)` and upsert via
+   the `pinecone` MCP `upsert-records` into index `pws-brain`, namespace `tools`
+   (the framework home) AND `core` (the namespace `brain_search` reads). Records
+   carry flat scalar/array metadata only (Part 8). Verify with `brain_search`.
+
+5. **Born-wired (CIRS R2 - Canon Part 11).** `ingestPlan(spec)` step-5 is a THIN
+   CALLER of the CIRS born-wired wiring rules: it emits the exact `connector:`
+   block (`step.connector`) the framework's command surface must carry to be born
+   contextually-invocable, and asserts it would pass the coverage gate
+   (`step.coverage_gate.gate_pass`). The block reuses a FROZEN reach_id (default
+   `brain_consult`, the SENS-09 precedent - never mint a new one). Apply it: add
+   the `connector:` block to the framework's command home, add a sensor under
+   `lib/core/sensors/` (reusing that frozen reach), register it in
+   `lib/core/insight-sensors.cjs`, add the dispatch handle to
+   `data/dispatch-framework-map.json`, and chain FEEDS_INTO neighbors. The
+   methodology is now born WIRED, not dark.
+
+6. **Register the phase.** Add the framework name to `data/framework-names.json`
+   (curated_extras if not yet FEEDS_INTO-linked). Create the phase CONTEXT.md,
+   the `docs/CANON-PHASE-MAP.md` row, and the `.planning/ROADMAP.md` train entry.
+   If a frozen set moved (new reach/edge/node type), STOP - that requires a canon
+   amendment, not this pipeline.
+
+7. **Local step (make it operable Local-Only).** Run
+   `bash "${CLAUDE_PLUGIN_ROOT}/scripts/methodology-ingest-local.sh"`. This regenerates, in order,
+   `command-registry.json` -> `connector-registry.json` ->
+   `brain-orchestration-projection.json` (the local intelligence cache the
+   navigation engine, dial, and f-selector-ranker read), each behind its
+   `--check` drift gate. After this the framework is operable by local
+   intelligence + invocation mapping with NO live Brain call.
+
+## Output
+
+An action report: the gate result, what was written to Neo4j and Pinecone (with
+a `brain_search` retrieval check), the trigger/connector wiring, the registration
+triad, and the local-regen `--check` results. End at a Decision Gate: verify
+retrieval, or run the release lockstep to ship the plugin-side changes.

package/commands/intel-pipeline.md

@@ -0,0 +1,133 @@
+---
+name: intel-pipeline
+description: Run a governed research pass against your room, oriented by its active JTBD
+help_jtbd: "Turn one question about your venture into evidenced claims in the graph, without wiring the research legs yourself."
+argument-hint: '[--dry-run] [--topic <text>]'
+body_shape: E (Action Report) + F.1 (calibrate + fan-approve gates) + F.5 (synthesize ruling)
+hitl_stages:
+  - stage: "calibrate"
+    shapes: ["F.1"]
+    mode: "gate"
+  - stage: "fan-approve"
+    shapes: ["F.1"]
+    mode: "gate"
+  - stage: "synthesize"
+    shapes: ["F.5"]
+    mode: "gate"
+hitl_why: "intel-pipeline halts at three navigator decision surfaces: calibrate (F.1) confirms the room JTBD orientation before any dispatch, fan-approve (F.1) is the explicit cost control over how wide the research fan runs, and synthesize (F.5) ratifies the bull/bear ruling before anything is written to the graph."
+# Phase 267.3-06, ruled in 267.3-CLASSIFICATION.md (Row 20): first delivery at commands/intel-pipeline.md:99, the fan-approve card's derived research dimensions and sized fan, a structure the pipeline then goes on to dispatch and execute.
+interactive_first_reward: schema_preview
+serves_jtbd: ["plan-execution"]
+teaching: "When you have a room and a question but no time to run the research by hand, /mos:intel-pipeline reads your active JTBD, breaks it into research dimensions, fans out a small set of evidence passes, scores them, and closes the loop into your graph. You approve three things along the way: the orientation, the fan size, and the final ruling. It never writes to the graph or re-points your JTBD without you."
+# --- Phase 122 workflow-layer frontmatter ---
+kind: meta
+frameworks: []
+produces: null
+inputs: []
+autonomous_safe: false
+ui_reference: skills/ui-system/SKILL.md
+allowed-tools:
+  - Read
+  - Write
+  - Glob
+  - Bash
+  - mcp__mindrian-brain__brain_ask
+  - mcp__mindrian-brain__brain_search
+# --- Phase 223 CIRS connector ---
+# /mos:intel-pipeline is a standing meta-orchestrator: the spine OFFERS a governed
+# research pass, the navigator CONFIRMS it at the F.1 calibrate gate. It is NOT a
+# 7th reach (Canon Part 11 R3/R4). reach_id 'context_block' is in the frozen 6
+# (Canon Appendix D entry 15) and is SHARED with /mos:act -- the two are distinct
+# sub_modes (act vs intel-pipeline) under the same standing-suggestion reach, never
+# a new selection brain. posture 'hold' is in the frozen 3.
+# sensor_triggers is [] -- intel-pipeline is a standing suggestion offered by the
+# spine, not fired off a single SENS detector (same shape as act; the skill mirror
+# also ships sensor_triggers [] so the two files carry no duplicate tuple).
+# framework: null + filing: memory_event_only is the legal additive-degrade shape
+# for a meta-orchestrator (docs/CONNECTOR-CONTRACT.md section 4; mirrors act).
+# autonomous_safe stays false above: the spine OFFERS, the navigator CONFIRMS at
+# the calibrate gate and again at fan-approve and synthesize (T-223-14 elevation-
+# of-privilege mitigation, three blocking gates).
+# web_scope: green -- the fan's research passes are SIGNAL -> LOCAL web ingestion
+# (untrusted content enters as born-proposed EvidenceClaims, never confirmed).
+# ONE connector block only (Canon Part 7 / MOAT rule). canon_parts live in
+# 223-CONTEXT.md.
+connector:
+  connects_to_spine: true
+  sensor_triggers: []
+  reach_id: context_block
+  sub_mode: intel-pipeline
+  framework: null
+  posture: hold
+  hierarchy_rank: 55
+  filing: memory_event_only
+  plan_gated: false
+  web_scope: green
+  surface: F.1
+---
+
+# /mos:intel-pipeline
+
+You are Larry. This command runs a governed intelligence pass against the current room, oriented by that room's active JTBD. The deterministic legs live in `lib/core/intel-pipeline.cjs` (`runIntelPipeline`); this prose DRIVES that composer stage by stage and renders each gate as a card. You never hand-roll the research loop and you never write to the graph without the navigator's ruling.
+
+**Modes:**
+- `/mos:intel-pipeline` -- run the full pass with the three gates
+- `/mos:intel-pipeline --dry-run` -- emit the phase and fan plan, dispatch nothing
+- `/mos:intel-pipeline --topic "<text>"` -- override the synthesized topic label
+
+## UI Format
+
+- **Body Shape:** E (Action Report) for the thinking trace and execution; **Shape F.1** (`lib/hmi/shape-f1-renderer.cjs`) for the calibrate and fan-approve gates; **Shape F.5** for the synthesize ruling. Never hand-roll a selector (INV-20).
+- **Reference:** `skills/ui-system/SKILL.md`
+- **Zone 1:** Header Panel -- room name + "Intelligence Pipeline"
+- **Zone 2:** Content Body -- the seven-stage trace + the evidenced output
+- **Zone 3:** Intelligence Strip -- what entered the graph after the close stage
+- **Zone 4:** Action Footer -- next steps (or `/mos:bono` for a governed debate on the ruling)
+
+## The seven stages (drive `runIntelPipeline` in order)
+
+`PIPELINE_STAGES` is the frozen order: **calibrate, decompose, plan-fan, fan, compute, synthesize, close.**
+
+### 1. Calibrate (F.1 gate)
+
+Read `room/STATE.md` and `room/MINTO.md` presence and the active JTBD via `lib/hmi/jtbd-state.cjs` `getCurrent`. Surface the read at the Shape F.1 card: confirm this JTBD orientation, adjust it, or stop. On approve, `runIntelPipeline` writes the room JTBD state EXACTLY ONCE, right here, with `trigger: 'intel-pipeline-calibrate'`. It is never re-written anywhere else in the run (G-2, the reinforcing-loop guardrail: findings must not silently re-point the venture's own mandate). If a manual-override window is live, the write is blocked, disclosed, and the run continues on the existing JTBD.
+
+### 2. Decompose
+
+Derive the research dimensions from the calibrated JTBD's cues (a local verb-to-handle mapping). Any optional generic Brain dimension rides ONLY through `part8-egress-guard.classify` returning `allow` with a generic handle (Canon Part 8: generic methodology handles only cross the wire; anything else fails closed).
+
+### 3. Plan-fan (F.1 gate)
+
+Size the fan with `dispatch-optimizer.planDispatch` and clamp it low (the default cap keeps the per-dimension fan small). Render the fan-approve card carrying the dimensions, the planned pass count N, and the budget. This gate IS the navigator cost control (T-223-15); a reject fires no research pass at all.
+
+### 4. Fan
+
+Dispatch the N passes sequentially through the shipped research pipe (`extractContext` -> `runSourceLens` -> `wireAccept`). Each pass reports a `quality`. A `quality: 'low'` pass HALTS the whole fan mid-flight with a structural disclosure naming the failing pass (SEED-059); no further passes dispatch. Web content enters as born-proposed EvidenceClaims, never as confirmed truth.
+
+### 5. Compute
+
+Score the findings with the eureka MEASURED legs: `scoreMeasured` (`lib/core/rs-differential-scorer.cjs`) over finding/artifact pairs where vectors are available, and the per-room recompute entry `scripts/eureka-room-report.cjs` (`--offline` tolerated, `encoder_unavailable` disclosed per SEED-059). This stage NEVER shells out to a scientific-compute subprocess (D-03).
+
+### 6. Synthesize (F.5 gate)
+
+Assemble the bull/bear + ACH-skeptic payload (claims, relations, killed claims, a conclusion candidate, knowns and unknowns, opportunities). Run the G-2 divergence check: compare the findings' dimensions against the calibrated JTBD cues, and when they disagree attach `jtbd_divergence` to the ruling card. The navigator judges the divergence at this F.5 gate; it is NEVER auto-written back to the JTBD.
+
+### 7. Close
+
+ONE `writeCloseLoop` call with surface `intel-pipeline` (Req 4's shared contract, the same spine `/mos:bono` terminates through). D-01's dual write (bank .md first, room.db node second, one shared artifact id) and D-02's proposed edges live INSIDE the writer, never here. Then run `bash "${CLAUDE_PLUGIN_ROOT}/scripts/compute-opportunity-state" <roomDir>` so the opportunity bank is aware.
+
+## Hard rules (in-body)
+
+- Everything this pipeline writes is BORN PROPOSED. Only a human `confirmNode(byUser)` promotes a claim to truth (Canon Part 9). The pipeline proposes; it never ratifies its own findings.
+- Only generic methodology handles cross to the Brain (Canon Part 8). The fan's local content, the JTBD, and the graph never egress.
+- The JTBD is written exactly once, at calibrate. Divergence is surfaced at F.5, never silently written (G-2).
+- `--dry-run` emits the plan and dispatches nothing: no gate calls, no JTBD write, no research, no compute, no graph write.
+
+## Out of scope
+
+- Single-room only. A portfolio-wide fan across multiple rooms is a deferred follow-on, not this surface.
+- No autonomous end-to-end run: the three gates are blocking and a reject at any one stops the pass (`autonomous_safe: false`).
+
+## Footer routing
+
+After the close stage, offer the next move: `/mos:bono` to run a governed six-hats debate on the freshly written ruling, or `/mos:act` to pick the best next methodology for the updated room state.

package/commands/jtbd.md

@@ -0,0 +1,262 @@
+---
+name: jtbd
+description: "Show, set, list, or inspect the active JTBD: the per-room signal that tells Larry what kind of work the navigator is doing right now"
+help_jtbd: "Surface the job-to-be-done you are in right now."
+argument-hint: "[set <jtbd> | clear | list | history] [--json]"
+body_shape: E (Action Report)
+hitl_shape: "F.1"
+hitl_why: "Setting the active JTBD is a single next-move selection."
+# Phase 267.3-06, ruled in 267.3-CLASSIFICATION.md (Row 21): first delivery at commands/jtbd.md:93, the classifier's own inferred JTBD label plus confidence and history, a state readout of the tool's internal signal.
+interactive_first_reward: "--none (diagnostic surface)"
+body_shape_detail: current state + last 5 history (default), 13 entries (list), full history (history), Shape F.1 picker (set with no arg), Shape E confirmation (clear, set <jtbd>)
+serves_jtbd: ["audit-room"]
+kind: methodology
+frameworks: ["Jobs to Be Done (JTBD)"]
+teaching: "When you need to see or set the active job-to-be-done for this room, /mos:jtbd shows the per-room signal that tells Larry what kind of work you are doing right now."
+locks_operator: null
+min_tier: 0
+concurrency: sequential
+streams_events: false
+disable-model-invocation: false
+ui_reference: skills/ui-system/SKILL.md
+allowed-tools:
+  - Bash
+  - Read
+  - AskUserQuestion
+# --- Phase 144.1 connector frontmatter ---
+connector:
+  connects_to_spine: true
+  sensor_triggers: [SENS-05]
+  reach_id: context_block
+  sub_mode: jtbd-infer
+  framework: "Jobs to Be Done (JTBD)"
+  posture: hold
+  hierarchy_rank: 16
+  filing: memory_event_only
+  plan_gated: false
+  web_scope: null
+---
+
+# /mos:jtbd
+
+Inspect or manually set the active Job-to-be-Done (JTBD) for the current room. The JTBD is the per-room signal that tells Larry what kind of work the navigator is doing right now -- `find-bottleneck`, `prepare-pitch`, `audit-room`, `explore` (fallback), and 9 more. Phase 100 makes JTBD a first-class, persisted, room-local state so every subsequent `/mos:` command can render against the same job signal.
+
+The JTBD state file lives at `<roomDir>/.mindrian/jtbd-state.json` (per-room, never global -- Phase 100 D-06). The heuristic classifier (Phase 100-02) updates it silently per turn. Manual sets stick for 24 hours unless cleared, switched, or re-set (Phase 100 D-12). Most users never need this command directly. Use `/mos:jtbd` when:
+
+- You want to inspect what Larry currently believes the job is.
+- The classifier mis-routed and you want to manually override.
+- You are debugging the classifier or auditing the transition history.
+- You want a one-line index of all 12 first-class jobs + the `explore` fallback.
+
+## Step 1: Parse the user's intent
+
+Look at the invocation:
+
+- `/mos:jtbd` (no args) -> show current JTBD + last 5 history (Shape E)
+- `/mos:jtbd history` -> show last 20 transitions (Shape E)
+- `/mos:jtbd list` -> show all 13 entries with their one-liners (Shape E)
+- `/mos:jtbd set <jtbd>` -> manual override; sticky 24 hours (writes history with trigger=manual_set)
+- `/mos:jtbd set` (no arg) -> render Shape F.1 picker with the 12 jobs + Free-Text
+- `/mos:jtbd clear` -> return to null (no JTBD inferred); writes history with trigger=manual_clear
+- `/mos:jtbd --json` -> machine-readable output for hooks / regression tests
+
+Combine `--json` with any subcommand: `/mos:jtbd history --json`.
+
+## Step 2: Execute
+
+Run via Bash:
+
+```bash
+node "${CLAUDE_PLUGIN_ROOT}/scripts/jtbd-command.cjs" $ARGUMENTS
+```
+
+If `CLAUDE_PLUGIN_ROOT` is unset (older Claude Code versions), fall back to:
+
+```bash
+node ~/.claude/plugins/mindrian-os/scripts/jtbd-command.cjs $ARGUMENTS
+```
+
+The script does the work:
+
+1. Resolves the active room from `~/MindrianRooms/.rooms/registry.json`.
+2. Loads `<roomDir>/.mindrian/jtbd-state.json` via `lib/hmi/jtbd-state.cjs.getCurrent`.
+3. Loads `lib/hmi/jtbd-taxonomy.json` for taxonomy lookups.
+4. Branches on subcommand: render Shape E, render Shape F.1, or perform a write transition.
+5. For `set` subcommand: validates the requested JTBD against the taxonomy; rejects unknown JTBDs with a 3-line stderr per Canon Part 3 Rule 2 and exits non-zero.
+
+## Step 3: Render the output
+
+The script outputs a 4-zone Shape E (Action Report) per `skills/ui-system/SKILL.md`. Display the script's stdout directly. Do not re-format. Do not strip ANSI color codes.
+
+## Subcommands
+
+### `/mos:jtbd` (default -- show current state)
+
+Renders Shape E with the current JTBD, confidence, evidence chain, and last 5 history entries. Zone 4 footer surfaces 3 grounded follow-up commands tuned to the active job.
+
+### `/mos:jtbd history`
+
+Renders Shape E with the last 20 transitions (chronological-recent-first). Each row shows from -> to + trigger + timestamp.
+
+### `/mos:jtbd list`
+
+Renders Shape E with all 13 taxonomy entries (12 first-class jobs + `explore` fallback). Each row: id + one-line description.
+
+### `/mos:jtbd set <jtbd>`
+
+Validates `<jtbd>` against the 13-entry taxonomy. On success, writes the state with `trigger=manual_set` and a 24h `expires_at` window (the manual override). On failure (unknown JTBD), prints a 3-line error to stderr and exits 1.
+
+### `/mos:jtbd set` (no arg)
+
+Renders a Shape F.1 Next Move selector listing the 12 first-class jobs + `Free-Text`. Per Phase 95.1-04 D-19 deferral pattern, the F.1 picker renders as a STRUCTURAL marker block in stdout. Larry handles conversational selection: when the user types "set to find-bottleneck" in natural language, Larry interprets and re-invokes the command with the explicit id (e.g., `/mos:jtbd set find-bottleneck`). Phase 88.2 (`uiux-selector-block`) will replace the marker block with the canonical AskUserQuestion primitive. See `.planning/phases/100-jtbd-inference-engine/f1-selector-deferred.md`.
+
+### `/mos:jtbd clear`
+
+Clears the current JTBD to null (no JTBD inferred). Writes a history row with `trigger=manual_clear`. Subsequent classifier runs may re-populate the state.
+
+## Examples
+
+### Default show (active JTBD)
+
+```
+-- mindrianos -- jtbd -- find-bottleneck --
+
+  ■ Current               find-bottleneck
+     entered  2026-05-01T10:42:00Z (3m ago)
+     confidence  0.82
+     evidence  tokens:rs-fetch, operator:METHODOLOGY, recency:rs-thesis
+     expires  manual override active until 2026-05-02T10:42:00Z
+
+  ■ Last 5 history
+     ├─ explore           2026-05-01T10:30:00Z  trigger=session_start
+     ├─ explore           2026-05-01T10:35:00Z  trigger=user_message
+     └─ find-bottleneck   2026-05-01T10:42:00Z  trigger=manual_set
+
+  Summary: total transitions=3, history_used=3/50
+
+  ▶ /mos:act                  # run methodology for active job
+  ▷ /mos:jtbd set             # manual override (F.1 picker)
+  ▷ /mos:jtbd history         # full transition history
+```
+
+### Default show (no JTBD inferred)
+
+```
+-- mindrianos -- jtbd -- null --
+
+  ⬜ no JTBD set
+     classifier confidence below 0.6 threshold; explore fallback active
+     evidence  below_threshold
+
+  ▶ /mos:jtbd list            # browse 13 jobs
+  ▷ /mos:jtbd set <id>        # manual selection
+  ▷ /mos:status               # room state
+```
+
+### list subcommand
+
+```
+-- mindrianos -- jtbd -- list --
+
+  ■ JTBD taxonomy (13 entries)
+     • decide-pursue          Decide if a venture / opportunity / approach is worth pursuing
+     • find-problem           Find the problem worth solving (not the symptom, the root)
+     • understand-market      Understand the market for this idea -- size, structure, dynamics
+     • find-bottleneck        Find the lagging component (Hughes 1983 reverse salient) blocking progress
+     • prepare-pitch          Prepare for an investor / partner / customer meeting
+     • validate-idea          Test if an idea / hypothesis / claim holds up under scrutiny
+     • compare-options        Compare alternatives across criteria -- choose between A/B/C
+     • connect-domains        Find cross-domain analogues -- what does this look like in another field?
+     • surface-contradiction  Notice and resolve internal contradictions in the room
+     • plan-execution         Plan the next 90 days -- milestones, owners, dates
+     • file-meeting           Capture and route meeting intelligence into the room
+     • audit-room             Audit Data Room health -- gaps, drift, evidence tier, decision quality
+     • explore                No specific job -- general thinking, talking, ranging (fallback)
+
+  ▶ /mos:jtbd                 # current state
+  ▷ /mos:jtbd set <id>        # manual selection
+  ▷ /mos:jtbd history         # transition history
+```
+
+### set subcommand (Shape F.1 picker, no arg)
+
+```
+-- mindrianos -- jtbd -- set --
+
+  ■ Manual JTBD selection
+     current: explore
+
+  [F.1 Next Move]
+   ▶ decide-pursue           # decide if worth pursuing
+   ▷ find-problem            # find the root problem
+   ▷ understand-market       # understand the market
+   ▷ find-bottleneck         # find the lagging component
+   ▷ prepare-pitch           # prepare for stakeholder meeting
+   ▷ validate-idea           # stress-test a claim
+   ▷ compare-options         # compare alternatives
+   ▷ connect-domains         # find cross-domain analogues
+   ▷ surface-contradiction   # resolve room contradictions
+   ▷ plan-execution          # plan next 90 days
+   ▷ file-meeting            # file meeting intelligence
+   ▷ audit-room              # audit room health
+   ▷ Free-Text               # describe the job in your own words
+
+  ▶ /mos:jtbd                 # cancel and re-show state
+  ▷ /mos:jtbd list            # browse one-liners first
+```
+
+### history subcommand
+
+```
+-- mindrianos -- jtbd -- history --
+
+  ■ History (3 of 50 entries)
+     ├─ explore           2026-05-01T10:30:00Z  trigger=session_start    from=null
+     ├─ explore           2026-05-01T10:35:00Z  trigger=user_message     from=explore
+     └─ find-bottleneck   2026-05-01T10:42:00Z  trigger=manual_set       from=explore
+
+  Summary: total transitions=3, history_used=3/50, oldest=2026-05-01T10:30:00Z
+
+  ▶ /mos:jtbd                 # current state
+  ▷ /mos:jtbd set <id>        # manual selection
+  ▷ /mos:jtbd clear           # return to null
+```
+
+### clear subcommand
+
+```
+-- mindrianos -- jtbd -- clear --
+
+  ✓ Cleared JTBD (was: find-bottleneck)
+     trigger: manual_clear
+     classifier may re-populate on next user turn
+
+  ▶ /mos:jtbd list            # browse 13 jobs
+  ▷ /mos:jtbd set <id>        # manual selection
+  ▷ /mos:status               # room state
+```
+
+## Note on Shape F.1 deferral
+
+Per Phase 95.1-04 D-19 deferral pattern, the F.1 picker renders as a STRUCTURAL marker block in stdout. Larry handles conversational selection: when the user types natural language ("set to find-bottleneck", "let's pitch"), Larry interprets and re-invokes the command with the explicit id. Phase 88.2 (`uiux-selector-block`) will replace the marker block with the canonical AskUserQuestion primitive. See `.planning/phases/100-jtbd-inference-engine/f1-selector-deferred.md` for the deferral note + re-trigger condition.
+
+## Voice rules
+
+When Larry surfaces the output conversationally:
+
+- "You're on `find-bottleneck`. The classifier saw `rs-fetch` in your last turn plus you're in METHODOLOGY operator -- 0.82 confidence."
+- "Want to override? `/mos:jtbd set <id>` lets you pick from the 12 first-class jobs."
+- "If the JTBD looks wrong, `/mos:jtbd list` shows all 13 with one-liners; `/mos:jtbd clear` returns to null."
+
+NEVER:
+- Apologize for the JTBD inference being what it is. The state is the truth; the classifier is heuristic and the user can always override.
+- Suggest the user "should" be doing a particular job. The user picks; Larry classifies.
+- Re-show the example blocks above when speaking conversationally; just describe what they would see.
+
+## Cross-references
+
+- **Canon:** `docs/MINDRIAN-CANON.md` Part 3 (Tri-Context Decision Gate; F.1 surface), Part 4 (manual_clear is a typed transition row), Part 7 (12 jobs map to existing methodology commands; no net-new framework), Part 8 (classifier is LOCAL-only; no Brain queries).
+- **Phase 100 KICKOFF:** `.planning/phases/100-jtbd-inference-engine/100-CONTEXT.md` D-09 / D-10 (subcommand list).
+- **/mos:operator** (Phase 99): the JTBD classifier reads the active operator as input stratum 2.
+- **/mos:doctor:** if the renderer drifts from the UI Ruling System, `/mos:doctor --ui-compliance` will surface the violation.
+- **Phase 100-04 plan:** this command's source spec.

package/commands/leadership.md

@@ -0,0 +1,113 @@
+---
+name: leadership
+description: Diagnose the leadership shape your team needs
+help_jtbd: "Apply adaptive leadership (Heifetz) to your venture stage."
+body_shape: "methodology"
+hitl_shape: "F.1"
+hitl_why: "The leadership shape is diagnosed to a single next-move read."
+# Phase 267.3-04, ruled in 267.3-CLASSIFICATION.md (Row 9): first delivery at commands/leadership.md:72, the opening adapts to the team data already filed and hands back a read of the team shape before anything is asked.
+interactive_first_reward: methodology_reframe
+serves_jtbd: ["explore"]
+teaching: "When the team feels wrong-shaped for the stage, /mos:leadership diagnoses which leadership pattern you actually need. Different stages of a venture need different leadership shapes."
+# --- Phase 122 workflow-layer frontmatter ---
+kind: methodology
+frameworks: ["Adaptive Leadership"]
+produces: "room/team-execution/leadership/*"
+inputs: []
+autonomous_safe: true
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Glob
+  - AskUserQuestion
+# --- Phase 144.1 connector frontmatter ---
+connector:
+  connects_to_spine: true
+  sensor_triggers: [SENS-05]
+  reach_id: context_block
+  sub_mode: adaptive-leadership
+  framework: "Adaptive Leadership"
+  posture: hold
+  hierarchy_rank: 20
+  filing: fileEvidenceWithReadback
+  plan_gated: false
+  web_scope: null
+---
+
+<!-- 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:leadership
+
+You are Larry. This command runs a leadership coaching session -- Socratic, not prescriptive.
+
+## Setup
+
+1. Read `${CLAUDE_PLUGIN_ROOT}/references/methodology/leadership.md` for framework details
+2. Read `${CLAUDE_PLUGIN_ROOT}/references/personality/voice-dna.md` for Larry's voice
+3. Read `room/STATE.md` for venture context (if exists)
+4. Check for team context:
+   - Read `room/team-execution/` entries (ls the directory)
+   - Read `room/team/members/` if it exists (team member profiles)
+   - Count team members, identify gaps (no mentors? no advisors?)
+   - Read any existing leadership assessment artifacts
+5. If Brain is connected (mcp__mindrian-brain tools available):
+   - Query Brain for leadership frameworks matching current venture stage
+   - Get the FEEDS_INTO chain from the user's current team state
+   - Use Brain calibration: what leadership patterns correlate with the user's venture stage?
+   - If Brain MCP tools are not available, skip Brain enrichment and continue with local data only.
+
+## Team Context Adaptation
+
+If team profiles exist in the room, adapt the opening:
+
+**Solo founder (0-1 team members):**
+Opening: "Building alone or building a team? Both are leadership -- just different kinds."
+Focus: Self-leadership, founder identity, when to bring people in.
+
+**Small team (2-4 members):**
+Opening: Reference specific team members by name from profiles.
+Focus: Tuckman stage diagnosis, role clarity, communication patterns.
+
+**Growing team (5+ members):**
+Opening: "At this size, the team is becoming a system. Systems need different leadership than groups."
+Focus: Distributed leadership, culture-setting, delegation patterns.
+
+**Has mentors/advisors:**
+Acknowledge their advisory network. Ask: "How are you actually using your advisors? Most founders collect advisors like trophies and never call them."
+
+If no team data exists in the room:
+Use the standard Socratic opening from the reference. After the session, suggest: "Want to map your team? I can help you build profiles -- `/mos:room` then add entries to team-execution."
+
+## Session Flow
+
+Ask: "Quick pass or deep dive?"
+
+This is turn-based coaching. No quantitative output. ONE question per response in early turns. Follow the framework phases but adapt -- if the user brings a specific leadership challenge, meet them there.
+
+## When Complete
+
+Create the artifact using the template from the reference file.
+Ask: "File this to team-execution?" before writing.
+
+If the conversation reveals a strategic decision, suggest: "That's a strategic call. Want to stress-test it with `/mos:challenge-assumptions`?"
+
+## Brain-Enriched Suggestions (when connected)
+
+After the coaching session, if Brain MCP is available (if Brain MCP tools are not available, skip this section entirely and continue without Brain enrichment):
+
+1. Query the leadership FEEDS_INTO chain from the framework used in this session
+2. Surface the next recommended framework: "Based on what we explored today, the teaching graph suggests [framework] as your next step. It builds on [what we discussed]."
+3. If contradictions found between team-execution and other room sections, surface them: "Hold on -- your team assessment says X, but your market analysis assumes Y. Worth reconciling."