@mindrian_os/install 1.13.0-beta.16 → 1.13.0-beta.19

package/lib/statusline/version-resolver.cjs

@@ -0,0 +1,81 @@
+// lib/statusline/version-resolver.cjs -- Phase 121.5-03 Task 2 Step 2
+//
+// Resolves the running plugin version + checks whether an update is available.
+// Pure, single-purpose: no rendering, no truncation. Returns:
+//   {
+//     current_version: string,
+//     update_available: boolean,
+//     update_available_version: string|null
+//   }
+//
+// SEED-007 (version-of-record) anchored here. Row 1 of the statusline reads
+// from this resolver.
+//
+// Canon Part 8: LOCAL-only. Reads ~/.mindrian/update-check.json (LOCAL
+// side-channel) + the plugin's own .claude-plugin/plugin.json. Zero network.
+
+'use strict';
+
+const fs = require('fs');
+const path = require('path');
+const os = require('os');
+
+function defaultCheckPath() {
+  return path.join(os.homedir(), '.mindrian', 'update-check.json');
+}
+
+function readUpdateCheck(checkPath) {
+  const p = checkPath || defaultCheckPath();
+  try {
+    return JSON.parse(fs.readFileSync(p, 'utf8'));
+  } catch (_) {
+    return null;
+  }
+}
+
+function readPluginVersion(pluginRoot) {
+  // Resolution chain (mirrors scripts/context-monitor readPluginVersion):
+  //   1. opts.pluginRoot (explicit override for tests)
+  //   2. __dirname/../../.claude-plugin/plugin.json (this file lives at lib/statusline/)
+  //   3. MINDRIAN_OS_ROOT env (when set by statusline-mos wrapper)
+  const candidates = [];
+  if (pluginRoot) candidates.push(pluginRoot);
+  candidates.push(path.resolve(__dirname, '..', '..'));
+  if (process.env.MINDRIAN_OS_ROOT) candidates.push(process.env.MINDRIAN_OS_ROOT);
+  for (const root of candidates) {
+    try {
+      const pj = path.join(root, '.claude-plugin', 'plugin.json');
+      if (fs.existsSync(pj)) {
+        const data = JSON.parse(fs.readFileSync(pj, 'utf8'));
+        if (data && typeof data.version === 'string' && data.version.length > 0) {
+          return data.version;
+        }
+      }
+    } catch (_) {}
+  }
+  return 'unknown';
+}
+
+function resolveVersion(opts) {
+  const o = opts || {};
+  const checkPath = o.checkPath || defaultCheckPath();
+  const check = readUpdateCheck(checkPath);
+  const current = readPluginVersion(o.pluginRoot);
+  const hasUpdate =
+    !!check &&
+    check.available === true &&
+    typeof check.available_version === 'string' &&
+    check.available_version.length > 0 &&
+    check.available_version !== current;
+  return {
+    current_version: current,
+    update_available: !!hasUpdate,
+    update_available_version: hasUpdate ? check.available_version : null,
+  };
+}
+
+module.exports = {
+  resolveVersion,
+  readUpdateCheck,
+  readPluginVersion,
+};

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mindrian_os/install",
-  "version": "1.13.0-beta.16",
+  "version": "1.13.0-beta.19",
   "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/visual/ROOM.md

@@ -0,0 +1,55 @@
+---
+type: visual_canon
+purpose: De Stijl palette source-of-truth + glyph vocabulary canon for MindrianOS surfaces
+canon_parts: [Part 3, Part 7, Part 10]
+phase_origin: 121.5
+plan_origin: 121.5-03
+consumers:
+  - lib/core/visual-ops.cjs
+  - scripts/banner
+  - scripts/context-monitor
+  - templates/destijl-base.css
+  - templates/shared.css
+  - references/vault-kit/snippets/mindrian-destijl.css
+  - lib/render/render-v2.cjs
+  - lib/render/JTBD-PALETTES.md
+---
+
+# references/visual/ -- the De Stijl canon
+
+`palette.json` is the single source of truth for every De Stijl hex value rendered by MindrianOS. The CI tripwire `scripts/check-palette-consistency.cjs` asserts every consumer file matches the canonical hex set.
+
+## ODD 3 resolution (Phase 121.5, 2026-05-16)
+
+Keep existing muted/earthy values. The external reference doc's brighter classic-Mondrian rebrand is a brand pivot, not an alignment; deferred to v1.14.0 if it ever comes. Canon Part 7 (consolidation, not rebrand).
+
+## Provenance
+
+Hex values copied verbatim from `lib/core/visual-ops.cjs` `DS_HEX` -- the shipping source of truth at the time of Phase 121.5-03. The current palette has been in production across v1.10 and v1.13 betas without complaint; consolidation preserves it.
+
+## Future additions (deferred)
+
+- `glyph-vocabulary.json` -- the SKILL.md section 3 12-glyph table as machine-readable. Surface-anchored meaning per ODD 4 (still open).
+- `banner-templates.json` -- the ASCII banner geometry per surface (CLI / Desktop / Cowork).
+
+Both deferred. Phase 121.5-03 ships `palette.json` only.
+
+## Deferred consumer audits
+
+Two CSS consumers were found to use surface-specific hex variants that intentionally diverge from the core palette and require their own audit pass:
+
+- `templates/shared.css` -- dashboard-styling lighter/darker variants (surface elevation tones; brighter accent reds for hover states). Captured in `palette.json` `deferred_consumers` for audit-trail purposes.
+- `references/vault-kit/snippets/mindrian-destijl.css` -- Obsidian-vault legibility variants tuned for Obsidian's default dark theme. Distinct surface; deferred to the Obsidian-vault color audit.
+
+These remain unchanged by Phase 121.5-03. The CI tripwire `scripts/check-palette-consistency.cjs` excludes them via the `derived_files` allowlist; the deferred entries record the audit-trail.
+
+When a future plan consolidates either surface, move the entry from `deferred_consumers` to `derived_files` and reconcile the variants.
+
+## How to add a new hex
+
+1. Add the key + hex to the right tier in `palette.json` (`base` / `palette_a_discovery` / `palette_b_build` / `extended`).
+2. Add the consumer file to `derived_files` if it is not already listed.
+3. Run `node scripts/check-palette-consistency.cjs` to confirm the CI tripwire passes.
+4. Update the consumers to derive the value from `palette.json` (not hardcoded).
+
+Hex values that drift from `palette.json` will fail the CI check.

package/references/visual/palette.json

@@ -0,0 +1,54 @@
+{
+  "version": 1,
+  "canon_parts": ["Part 3", "Part 7", "Part 10"],
+  "provenance": "Sourced verbatim from lib/core/visual-ops.cjs DS_HEX (the shipping source of truth as of Phase 121.5). ODD 3 resolution (2026-05-16): keep existing muted/earthy values; brighter classic-Mondrian rebrand deferred to v1.14.0 if it ever comes. See .planning/phases/121.5-terminal-coherence-capstone/121.5-CONTEXT.md item 7. Plan 121.5-03.",
+  "base": {
+    "mondrian_red":    "#A63D2F",
+    "mondrian_blue":   "#1E3A6E",
+    "mondrian_yellow": "#C8A43C",
+    "mondrian_black":  "#0D0D0D",
+    "mondrian_white":  "#F5F0E8",
+    "cream":           "#F5F0E8",
+    "gray_meta":       "#A09A90",
+    "amethyst":        "#6B4E8B",
+    "success_green":   "#2D6B4A"
+  },
+  "palette_a_discovery": {
+    "context_states": ["EXPLORE_CAPTURE", "JUST_TALK"],
+    "muted_red":   "#A63D2F",
+    "muted_green": "#2D6B4A",
+    "teal_accent": "#2A6B5E"
+  },
+  "palette_b_build": {
+    "context_states": ["METHODOLOGY", "DECISION_GATE", "BUILD_ROOM"],
+    "saturated_red":    "#A63D2F",
+    "saturated_blue":   "#1E3A6E",
+    "saturated_yellow": "#C8A43C"
+  },
+  "extended": {
+    "sienna":   "#B5602A",
+    "bg":       "#0D0D0D",
+    "surface":  "#1A1A1A",
+    "elevated": "#2A2A2A",
+    "gray":     "#5C5A56"
+  },
+  "ansi_5_color": {
+    "green":  "32",
+    "cyan":   "36",
+    "yellow": "33",
+    "red":    "31",
+    "gray":   "90"
+  },
+  "derived_files": [
+    {"path": "lib/core/visual-ops.cjs",                                    "via": "require + DS_HEX = palette.base + palette_a + palette_b + extended"},
+    {"path": "scripts/banner",                                             "via": "ANSI codes inline; hex documented in trailing comments + matched against palette.json"},
+    {"path": "templates/destijl-base.css",                                 "via": "CSS variables :root { --ds-red: ... } match palette.json values"},
+    {"path": "lib/render/JTBD-PALETTES.md",                                "via": "documentation cites palette.json hex values"}
+  ],
+  "deferred_consumers": [
+    {"path": "templates/shared.css",                              "reason": "Per-surface lighter/darker variants for dashboard styling (e.g. #2d2d2d surface elevation, #c95a4a lighter red). Distinct semantic palette intentionally diverges; consolidation deferred to a future plan that audits dashboard color tokens against palette.json + variant generation rules."},
+    {"path": "references/vault-kit/snippets/mindrian-destijl.css", "reason": "Vault-kit Obsidian snippet uses brighter classic-Mondrian variants (e.g. #c83d2f, #2b5ba5) for vault legibility in Obsidian's default dark theme. Distinct surface; covered when Obsidian-vault color audit lands."},
+    {"path": "templates/shared.css", "scope_note": "Captured as deferred so the audit trail records that shared.css palette divergence was SEEN by Phase 121.5-03, not silently passed."},
+    {"path": "lib/render/render-v2.cjs", "reason": "Future consumer once wired in Plan 121.5-05 (render-v2 disposition); not yet routing through palette.json."}
+  ]
+}

package/skills/larry-personality/SKILL.md

@@ -211,6 +211,40 @@ Every 3-5 turns, surface ONE unused command framed as JTBD:
 
 Causal directives: `references/brain/causal-directives.md`
 
+## Breakthrough Voice Scaffold (Phase 120 D-17)
+
+When the breakthrough scanner surfaces a pattern via F.7, the voice line MUST satisfy all four rules. The auditor (`lib/core/breakthrough/voice-scaffold.cjs::auditVoiceLine`) enforces this; D-17-violating lines are replaced with the structural default before reaching the surface.
+
+### The 4 Rules
+
+1. **Evidence requirement.** Cite the artifact ids OR graph edges that triggered detection. Patterns: `(artifacts art:1, art:2)`, `[[artifact-name]]`, `(see edges X, Y)`. NO "you have been doing great work" without specific citation.
+2. **Mechanism clause.** Include the `by Y` action that caused it. NO inferring user intent; only naming user action.
+3. **Time anchor.** Specific window: "in the last 8 hours", "this week", "since Tuesday". NO vague "lately" or "recently".
+4. **No unbacked superlatives.** Words like `breakthrough`, `biggest`, `first`, `unprecedented`, `major`, `massive` MUST NOT appear unless adjacent to numeric backing (e.g. "the highest differential score (0.78) in this room's history"). Frequency words `consistent`, `repeated`, `always` MUST be accompanied by a count.
+
+### Worked Example
+
+GOOD: "You're seeing a convergence on operator-state machines (artifacts art:1, art:2, art:3, art:4) -- by uploading the four notes on Mode A and Mode B -- in the last two days."
+
+BAD: "You're having a major breakthrough in your thinking lately." (Violates rule 1: no evidence cite. Violates rule 2: no mechanism. Violates rule 3: "lately" is not a time anchor. Violates rule 4: "major" + "breakthrough" with no numeric backing.)
+
+The bad line returns `{ok: false, violations: ['evidence_requirement', 'mechanism_clause', 'time_anchor', 'no_unbacked_superlatives']}` from `auditVoiceLine`.
+
+### Why these rules
+
+Per Canon Part 10 sub-claim 5: the math IS the surface. The voice is the math's translation to honest prose. Without the 4 rules, the system drifts toward engagement-optimizer territory (vague pseudo-recognition that feels good but is not real). The auditor IS the structural enforcement of D-20 (every breakthrough Cypher-provable from graph state alone).
+
+### Auditor failure modes
+
+When `auditVoiceLine(line)` returns `{ok: false, violations: [...]}`, the violations array names the rule(s) that failed:
+
+- `evidence_requirement` -- no `(artifacts ...)`, `[[...]]`, or `(see edges ...)` cite
+- `mechanism_clause` -- no `by Y` user-action phrase
+- `time_anchor` -- no `in the last N hours/days`, `this week`, `today`, `since YYYY-MM-DD`, etc.
+- `no_unbacked_superlatives` -- forbidden superlative or frequency word without numeric backing
+
+The scanner replaces failed-audit lines with the structural default (composer called with `roomState=null`), which is auditor-safe by construction.
+
 ## References
 
 - Mode transitions: `mode-engine.md`

package/skills/mva-pipeline/SKILL.md

@@ -0,0 +1,129 @@
+---
+name: mva-pipeline
+description: Auto-activates when UserPromptSubmit detection classifies the user's prompt as a venture sentence; relays the 30-second MVA brief in Larry's voice
+auto-activate: state-file
+state-file: ~/.mindrian/mva/<session-id>.json
+state-condition: pending && !running
+interactive_first_reward: instant_brief
+canon_parts: [Part 2, Part 8, Part 10]
+---
+
+# The 30-second MVA skill
+
+## When this activates
+
+When Plan 118-00's UserPromptSubmit detection writes a pending state with
+`pipeline_status: 'pending'` (or `hebrew_refusal: true`), this skill fires on
+the NEXT model turn. The skill is the bridge between Plan 118-00's classifier
+and Plan 118-03's orchestrator: it makes Larry the GUIDED narrator of the
+brief without baking the orchestrator into Claude Code's hook protocol.
+
+## What to do
+
+1. Run `/mos:mva-brief` (or invoke `node scripts/mva-run.cjs` via Bash directly).
+2. Relay the stdout to the user VERBATIM, in your normal Larry voice (no extra
+   framing). The renderer already speaks in Larry's GUIDED voice; double-voicing
+   breaks the pedagogical contract.
+3. Wait for the user's option selection (1, 2, 3, or free-text).
+4. Route per the footer behavior:
+   - 1 -> stay in JUST_TALK; the brief stays visible; user can ask follow-ups
+     about any cell ("tell me more about the Honeydue case", "what was the
+     Gottman analogy?", etc.)
+   - 2 -> invoke /mos:new-project (Phase 119 wrapper; in v1.13.0 this surfaces
+     a stub message that the full room-build flow lands in beta.18)
+   - 3 -> invoke /mos:challenge-assumptions against the brief
+
+## What NOT to do (per feedback_larry_pedagogical_guided_first.md)
+
+- Do NOT add commentary or "I noticed..." preamble before the rendered output.
+  The renderer already opens with "Scanning for precedents..." in Larry's
+  GUIDED voice.
+- Do NOT interpret findings autonomously ("This means you should..."). The
+  rendered output IS GUIDED -- it asks the user to think; the renderer
+  surfaces what's in the graph and lets the navigator chew on it.
+- Do NOT skip the 3-option footer. Even if all agents failed, the
+  sharp-question fallback substitutes for the footer (per binding decision B7);
+  the renderer handles this -- you just relay verbatim.
+- Do NOT pre-pick an option. The user picks. That's the decision gate.
+
+## Canon parts implemented
+
+- Part 2 (team around navigator -- 6 agents as a parallel team, with the skill
+  being the surface Larry uses to relay the team's output)
+- Part 8 (boundary -- the agents send ONLY generic handles to Brain and
+  Tavily; the renderer + skill never re-introduce user content)
+- Part 10 sub-claim 3 (room as receipt -- the brief IS the reward delivered
+  BEFORE the user is asked to invest in setting up a room; option 2 is the
+  ask-for-investment that comes AFTER the reward, per Hooked sequencing)
+
+## State file contract
+
+Read from `~/.mindrian/mva/<session-id>.json` (the Plan 118-00 wire):
+
+```
+{
+  "sentence_sha256":       "<64-hex>",      // NEVER the raw sentence
+  "classified_at":         <epoch_ms>,
+  "classifier_source":     "heuristic" | "heuristic_fallback" | "haiku-4-5",
+  "classifier_confidence": "high" | "medium" | "low",
+  "locale":                "en" | "he",
+  "hebrew_refusal":        true,            // optional, set on LD1 short-circuit
+  "pipeline_status":       "pending" | "running" | "complete"
+}
+```
+
+On `hebrew_refusal:true`, the orchestrator renders the bilingual refusal block
+and DOES NOT fire the dispatcher (per LD1 in 118-CONTEXT.md).
+
+## Routing the 3-option footer (after the brief renders)
+
+Once `/mos:mva-brief` (or the orchestrator) has rendered the brief to the user,
+the user's next message is most likely an option selection. Recognition rule:
+
+- User types exactly `1`, `2`, or `3` -> invoke `/mos:mva-option <N>` (no sha8
+  argument needed; the command auto-resolves via `resolveCurrentSha8()`)
+- User types `/mos:mva-option N` explicitly -> invoke `/mos:mva-option <N>`
+  (sha8 still optional; auto-resolved when omitted)
+- User types anything else -> handle as a normal conversation turn (do NOT
+  route through `mva-option`)
+
+The sha8 argument is OPTIONAL because the router auto-discovers the most
+recent brief via `resolveCurrentSha8()` -> `~/.mindrian/mva/state.json` (the
+manifest written by Plan 118-03's orchestrator after `mva_brief_rendered`).
+
+### Per-option behavior
+
+Option 1 -- "Just tell me what's new" (stay in tell-me mode):
+- Acknowledgment: "Keeping the brief visible. Ask me anything about what you just saw."
+- Operator: transitions to `JUST_TALK`
+- Brief stays in scrollback; follow-up questions about any of the 6 cells are welcome
+
+Option 2 -- "Build a room around this" (invest, deferred):
+- Show the stub message verbatim from `STUB_MESSAGE_119`:
+  "Building a room around this is the next layer; shipping in beta.18 (Phase 119). For now, press option 1 to keep this brief visible, or option 3 to go deeper."
+- Operator: no transition (option 2 is stubbed for v1.13.0)
+- In v1.13.0-beta.18 (Phase 119), this routes to `/mos:new-project --from-brief <sha8>`
+
+Option 3 -- "Challenge me -- Devil's Advocate" (go deeper):
+- Bridge text: "Going deeper. Pulling the brief into a Devil's Advocate pass."
+- Operator: transitions to `METHODOLOGY`
+- Invoke: `/mos:challenge-assumptions --from-brief <sha8>`
+
+### Edge cases
+
+- Brief data expired (side-file missing): tell the user the brief expired and
+  offer to re-run by typing their venture sentence again.
+- Brief is still rendering (`mva_brief_rendered` event not yet emitted): hold
+  the option, tell the user "Brief is still rendering -- options will activate
+  when it completes".
+- No `state.json` exists (fresh install or Hebrew refusal path): tell the user
+  "No recent brief found. Type your venture sentence to fire the pipeline."
+- Invalid option (`4`, `99`, etc.): treat as free-text and route normally.
+
+### Do NOT
+
+- Do NOT autonomously pick an option for the user.
+- Do NOT pre-summarize what option 2 "would do" -- the stub message says it.
+- Do NOT add em-dashes to any rendered option text -- use `--` only.
+- Do NOT invoke `/mos:new-project` for option 2 in v1.13.0 -- that wiring
+  lands in Phase 119 (beta.18).

package/skills/ui-system/SKILL.md

@@ -35,7 +35,9 @@ Every output has exactly 4 zones in fixed order. No reordering. No invention.
 
 **Density:** >30 lines: compact header, max 2 signals. <10 lines: no padding.
 
-## 2. Five Body Shapes
+## 2. Body Shapes
+
+> This section documents the current Shape F sub-shape catalog as shipped through Phase 88.2. Today's seven sub-shapes (F.0 through F.6) are the shipped vocabulary as of Phase 121.5; additive expansion is reserved for future lens-aware variants (e.g. v1.14.0 dual-graph work). Treat the catalog as the current canon, not a closed terminal set.
 
 ### Shape A: Mondrian Board
 **Used by:** `/mos:status`, `/mos:diagnose`, `/mos:radar`, `/mos:admin`
@@ -73,6 +75,28 @@ All five sub-shapes share a common envelope:
 
 The ten canonical verbs (from canon Part 3) are: Run Methodology / Reformulate / Spawn Sub-Agent / Navigate Graph / Devil's Advocate / Scenario Plan / Synthesize / Bank Opportunity / Defer / Free-Text. Each sub-shape below draws from this vocabulary.
 
+#### Shape F.0 - Mini Decision Gate
+
+Purpose: Tiny binary or trinary decision gate. Lighter than F.1 (which carries 3-5 options); F.0 is the minimum-viable gate when the navigator only needs a yes/no/defer call before the larger selector slate fires.
+
+When to use: A surface needs a confirmation BEFORE producing the larger F.1 selector. Most common: accept / reject / defer a recommendation before the full Next Move slate runs. Common pair: F.0 (accept this recommendation?) -> F.1 (now choose next move).
+
+Header format:
+```
+[filled-square] [CONTEXT] - MINI GATE             - decision gate
+[right-triangle-filled] {short binary or trinary question}
+```
+
+Options: EXACTLY 3 verbs as shipped (lib/hmi/shape-f0-renderer.cjs): Approve / Reject / Defer. No Free-Text slot in F.0 -- the Reject path captures the reason as a REJECTED_BECAUSE typed edge property (Canon Part 4: rejection is data), so the vocabulary stays closed without losing free-form intent. F.0 ALWAYS produces a typed edge; there is no silent dismiss path.
+
+Verb constraints: F.0 collapses to one of the 10 canonical verbs upon selection. Approve -> Run Methodology (or whatever the recommendation called for). Reject -> captured-reason edge (REJECTED_BECAUSE; eventType `selector_rejection_captured`). Defer -> Defer (queue for milestone audit).
+
+Keyboard: up-arrow / down-arrow (or J / K) to navigate, Enter to select, `?` to inspect, Esc to cancel. No RECOMMENDED marker is rendered in F.0 (the shape itself is the recommendation surface; marking one option would double-cue).
+
+State-update hook: append to STATE.md Decisions section with the chosen verb + a tiny one-line context snapshot (F.0 gates are lightweight; do NOT bloat Decisions with full context). A typed edge `(navigator) -[CHOSE_MINI {verb}]-> (recommendation-node)` lands in the local graph; Reject additionally writes REJECTED_BECAUSE with {reason, rejected_at, parent_decision_id}.
+
+Shipped in: Phase 88.2 (uiux-selector-block, Plan 88.2-05).
+
 #### Shape F.1 - Next Move
 
 Purpose: Default selector after any discuss chunk. The most-used shape.
@@ -178,6 +202,34 @@ Keyboard: up-arrow / down-arrow (or J / K) to navigate, Enter to select, `?` to
 
 State-update hook: append to STATE.md Decisions section naming the resolved branch and the resolution verb. A typed edge is added: (branch-root) -[RESOLVED {verb}]-> (target). Parked branches additionally create a milestone-audit TodoWrite row.
 
+#### Shape F.6 - Plan Review Round
+
+Purpose: Plan Mode wrap. When the navigator has been in a planning surface (e.g. after a methodology session that produced a plan), F.6 closes the round with an explicit Review verb selection BEFORE returning to Plan vs Build mode. F.6 is also the JTBD-aware variant of Shape F that the dispatcher routes to when a JTBD signal is set; the umbrella `F` branch in selector-dispatcher.cjs picks F.6 when jtbd is non-null and F.1 otherwise (lib/hmi/selector-dispatcher.cjs).
+
+When to use: End of a plan-producing methodology session, OR any Shape F surface where a non-null JTBD is in play and the renderer should produce a JTBD-aware Next Move slate. The navigator must explicitly review the plan (or defer review, or replan from scratch) before the system promotes the plan into the Decisions log.
+
+Header format:
+```
+[filled-square] [CONTEXT] - PLAN REVIEW           - decision gate
+[down-triangle] LOCAL   / BRAIN   / SIGNAL
+[right-triangle-filled] Review this plan:
+```
+
+Options: 3-5. Typical slate:
+  Approve plan
+  Revise plan
+  Replan from scratch
+  Defer review
+  Free-Text
+
+Verb constraints: Approve plan -> Synthesize (the plan becomes a confirmed artifact). Revise plan -> Reformulate (re-runs the planning verb with edits). Replan -> Reformulate from a fresh seed. Defer review -> Defer. Free-Text -> Free-Text. JTBD-aware variants source their verbs from `lib/hmi/jtbd-taxonomy.json` `next_move_verbs`; falls through to F.1 if the JTBD taxonomy entry is missing or the dispatcher receives a null JTBD.
+
+Keyboard: standard F-family keyboard (inherits from F.1 per Phase 101-01 D-01).
+
+State-update hook: on Approve, the plan is promoted from `review_status: proposed` to `review_status: confirmed` (Canon Part 9 truth-state machine). On Revise/Replan, the original plan stays `proposed` and a new revision edge is created. On Defer, a milestone-audit TodoWrite row queues the review. Plan-review variant additionally writes REVIEWED typed edges per question position with {round_id, position, latency_ms, was_decoy, response, confidence_self_report} (lib/hmi/shape-f6-plan-review-renderer.cjs).
+
+Shipped in: Phase 88.2 (uiux-selector-block, Plan 88.2-06 plan-review variant) + Phase 101-01 (JTBD-aware Next Move variant).
+
 ## 3. Symbol Vocabulary
 
 12 glyphs. One meaning each. No overloading.
@@ -201,6 +253,27 @@ State-update hook: append to STATE.md Decisions section naming the resolved bran
 
 Carve-out (2026-04-14, user directive): the Claude Code statusline rendered by `scripts/context-monitor` is **excepted** from this rule. The statusline is a passive signal surface rendered by the host terminal, not a MindrianOS command output body, and the user has authorized emoji use there specifically. Every other surface (slash-command output, artifact generation, MINTO.md files, CHANGELOG entries, reports, dashboard HTML bodies, PDF exports, printed logs) must continue to honor the no-emoji rule without exception. If you are reading this and about to add emoji to any surface other than `scripts/context-monitor`, stop.
 
+### ODD 4 resolution (2026-05-16): the 🎯 overload + the "JTBD" word collision
+
+Two known vocabulary collisions exist in v1.13.0 that we explicitly DOCUMENT rather than renumber or rename (the renumbering cost is too high for a closing milestone; see Phase 121.5 CONTEXT.md ODD 4). Both are RESOLVED BY POSITION-ANCHORED CONTEXT, mirroring the no-emoji + statusline carve-out pattern above:
+
+1. The 🎯 glyph means three things, each disambiguated by SURFACE:
+   - In the statusline Row 2 (`scripts/context-monitor`), 🎯 prefixes the active JTBD label -- meaning "what job are you in right now."
+   - In `/mos:jtbd` command output and JTBD broadcast banners, 🎯 prefixes a JTBD recommendation -- meaning "this is the job we're proposing."
+   - In `lib/core/visual-ops.cjs` EXPLORATION_LABELS, 🎯 is the stage emoji for `problem-definition` -- meaning "where the wicked navigator starts."
+
+   The three meanings never collide on the same surface at the same time. Reader disambiguation: where is the 🎯? (statusline row 2 / command output / EXPLORATION_LABELS render path).
+
+2. The word "JTBD" names two unrelated systems:
+   - Phase 37 nudge templates (`lib/hmi/build-jtbd-nudges` -- bash, prompt-engineering style).
+   - Phase 100 typed engine (`lib/hmi/jtbd-taxonomy.json` -- 13 JTBDs with cues / methodology hooks / next_move_verbs / completion patterns -- the AUTHORITATIVE system).
+
+   When SKILL.md, the canon, or any user-facing surface says "JTBD" without qualification, it means Phase 100 typed engine. The Phase 37 nudges are an internal prompt-engineering layer beneath the engine; user-facing surfaces never name them directly.
+
+This is the SAME shape of carve-out as the no-emoji rule + statusline exception. The pattern is: a global rule with a precisely-named exception, position-anchored. Future v1.14.0 may renumber the glyphs or rename "JTBD"; for v1.13.0 final we mark the seam, not move it.
+
+See `skills/ui-system/rules/glyph-disambiguation.md` for the full rule + the v1.14.0 cleanup proposal.
+
 ## 4. Color Contract
 
 5 ANSI colors with fixed meaning. Color is NEVER decoration.
@@ -215,6 +288,31 @@ Carve-out (2026-04-14, user directive): the Claude Code statusline rendered by `
 
 Bold for emphasis. Default/white for content. Never combine colors on one token. Red = errors only (warnings = yellow).
 
+### Dual De Stijl palette (Phase 102 D-06b)
+
+The 5-color CLI contract above is the BASE palette. Phase 102 (context-aware rendering) added a SECOND palette tier: the Mondrian primaries palette, which kicks in for FULL-COLOR surfaces (HTML exports, wiki/dashboard, presentation decks, Cytoscape graphs) where the 5-ANSI CLI palette is the wrong semantic match.
+
+The dual-palette rule (Phase 102 D-06b) is: pick the palette by SURFACE, not by JTBD. The same JTBD can render red on CLI (semantic) and blue on HTML (Mondrian) and that is correct.
+
+Two palettes:
+
+- **CLI semantic palette** (THIS section's 5-color contract: red / yellow / cyan / green / gray). Used for every `/mos:*` terminal output. Color carries semantic meaning at the terminal (red = error, etc.). Applied as a single colored Zone 1 left-rail accent at the start of the header (`lib/render/render-v2.cjs` `JTBD_CLI_COLOR` map), TTY-gated via `process.stdout.isTTY` so non-TTY captures stay byte-clean.
+
+- **Mondrian HTML palette** (red / yellow / blue / black / white). Used by HTML-emitting downstream phases ONLY (Phase 19 wiki-dashboard, Phase 25 data-room-export-v2, Phase 30 presentation-generator). Visual identity discipline: rectilinear grids, primary blocks, large white space. Mondrian shapes vocabulary extends the 12-glyph CLI set with `circle (●)` on HTML surfaces only.
+
+Surface routing:
+
+| Surface | Palette | Why |
+|---------|---------|-----|
+| CLI / TUI | 5-color semantic | Color carries semantic meaning at the terminal |
+| HTML dashboard / wiki / presentation / Cytoscape | Mondrian primaries | Visual identity discipline; De Stijl rectilinear grid |
+
+Compact mode (>80% token budget) drops the Zone 1 left-rail accent. Semantic body colors stay.
+
+Source-of-truth definitions: `lib/render/JTBD-PALETTES.md` (the Phase 102 canonical mapping). See `skills/ui-system/rules/dual-palette.md` for the full rule, hex values, and per-JTBD mapping table.
+
+The CANONICAL De Stijl hex values used across `scripts/banner`, `lib/core/visual-ops.cjs` (`DS_HEX`), `templates/destijl-base.css`, `templates/shared.css`, and `references/vault-kit/snippets/mindrian-destijl.css` will consolidate to `references/visual/palette.json` per Sub-plan D of Phase 121.5. This SKILL.md surface treats `palette.json` as the canonical reference once it lands.
+
 ## 5. Session Start Contract
 
 Three variants based on room state:
@@ -275,3 +373,13 @@ HELP:      1 line + 3 examples, grouped by flow
 WIDTH:     80 cols default, never expand
 NO EMOJI:  Ever.
 ```
+
+## 11. Cross-Reference to Canon
+
+This Ruling System implements two canon parts:
+
+- **Canon Part 3 (Tri-Context Decision Gate)** -- every Shape F surface IS the Part 3 Decision Gate at terminal scale. The 10 canonical verbs in Canon Part 3 are the vocabulary Shape F selectors draw from. The five-shape rule -- one selector family per decision moment, no command invents its own selector -- enforces Part 3 at the UI layer. See `docs/MINDRIAN-CANON.md` Part 3.
+
+- **Canon Part 10 (Conversation as Product)** -- this Ruling System enforces the property that "the terminal IS the product surface." Every glyph, every zone, every selector encodes "you are navigating a wicked problem with Larry." If the terminal is incoherent, Canon Part 10 isn't demonstrated. Phase 121.5 (terminal-coherence-capstone) is the consolidation pass that closed the gap between this ruling system and shipped code. See `docs/MINDRIAN-CANON.md` Part 10.
+
+Updates to this ruling system MUST update `docs/CANON-PHASE-MAP.md` in the same commit -- see Canon Part 6 (Product-as-Venture / dog-fooding mandate). The ruling system is dog-food: the product we ship for navigators is built using the product we ship for navigators.