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

package/data/harness-fixtures/converged-room/problem-definition/CONTEXT.md

@@ -0,0 +1,32 @@
+# problem-definition - the problem, not a solution
+
+**Statement:** This section holds the problem this venture is actually trying to solve, stated so a stranger can restate it.
+
+One job: hold the problem this venture is actually trying to solve, stated so a stranger can restate it.
+
+## Inputs
+- Working (this room): meeting notes and uploads in `meetings/`, and this room's own `STATE.md` venture stage.
+- Reference (every run): ../references/SECTION-SCHEMA.md
+- Reference (when relevant): ../references/SUB-SCHEMAS.md
+
+Do NOT load: the solution. That is `solution-design/`'s job. Pulling solution content in here is the single most common way a problem write-up quietly turns into a solution pitch.
+
+## Process
+1. State the problem in one sentence, the way it would be said to a stranger with no context.
+2. Place it on the PWS ladder: Un-Defined, Ill-Defined, or Well-Defined. Wicked is not a fourth, co-equal rung; it is a score-triggered escalation off any of the three, for a problem that resists decomposition.
+3. Decompose the stated problem into its parts only after it is placed on the ladder. Do not decompose before placing it, and do not let the decomposition quietly restate the solution instead of the problem.
+
+## Outputs
+- One folder per artifact at `problem-definition/<artifact-slug>/<artifact-slug>.md` (the Obsidian-nested convention, Key Decision 16). The folder IS the artifact.
+- Never inline content into `ROOM.md`. `ROOM.md` is ICM Layer 0 identity only: statement, purpose, stage relevance, default methodologies. Real content is ICM Layer 4 and lives in its own dated entry folder. Five of twelve sections in the audited `launchpad-02` room had already drifted this way; this line is why the contract exists.
+
+## Human check
+- Feynman: can a stranger restate this section's governing thought in one sentence, without jargon?
+- Minto: does the apex claim sit on MECE-grouped, non-overlapping support?
+- Does this read as a problem, or as a solution wearing a problem's clothes?
+
+## Commands that write here
+- Ground truth (the command's own `produces` path names this section): `/mos:beautiful-question`, `/mos:diagnose`, `/mos:explore-domains`
+- Framework-matched (a wildcard command whose framework fits this section's job): `/mos:root-cause`, `/mos:causal`, `/mos:map-unknowns`, `/mos:build-knowledge`, `/mos:validate`, `/mos:research`
+
+Note: `/mos:trending-to-absurd` used to be cited here and is NOT, as of Phase 275. It produces into `room/opportunity-bank/trending-to-absurd/*`; the misfiling was corrected in Phase 275 (D-05).

package/data/harness-fixtures/converged-room/problem-definition/ROOM.md

@@ -0,0 +1,36 @@
+---
+section: problem-definition
+statement: "This section holds the problem this venture is actually trying to solve, stated so a stranger can restate it."
+purpose: "Define the core problem this venture addresses."
+stage_relevance:
+  - Pre-Opportunity
+  - Discovery
+default_methodologies:
+  - explore-domains
+  - beautiful-question
+  - diagnose
+icm_layer: 0
+auto_scaffolded: true
+---
+
+<!-- ICM Layer 0 identity file per Canon decision 15 (every directory has ROOM.md).
+     This file was auto-scaffolded by Phase 119 (Room-as-Receipt Invariant); content
+     will be populated by /mos:* methodology runs or by Larry's first conversation.
+     Phase 275: `statement` is the ICM L1 routing field carried on this L0 identity
+     file, rendered twice (frontmatter key for tools, body blockquote for a human
+     or a foreign host reading raw markdown with no MCP tools). The ICM L2 contract
+     for this section lives in the sibling CONTEXT.md. -->
+
+# Problem Definition
+
+> This section holds the problem this venture is actually trying to solve, stated so a stranger can restate it.
+
+Define the core problem this venture addresses.
+
+## Starter Questions
+
+*(populated when material lands or methodology fires; until then the section is empty by design)*
+
+## Status
+
+Auto-scaffolded. Awaiting first content.

package/data/harness-fixtures/converged-room/references/ROOM.md

@@ -0,0 +1,13 @@
+---
+directory_type: references
+icm_layer: 0
+auto_scaffolded: true
+purpose: "ICM Layer 3, the factory layer: stable reference material that does not change per run. Holds the venture_stage axis schema, the section and family methodology schemas, and the per-section nested sub-schemas. Read every run, edited rarely, never a destination for work product."
+---
+
+<!-- ICM Layer 0 identity file per Canon decision 15. Every directory in the Data
+     Room has ROOM.md -- no exceptions. This file was auto-scaffolded by Phase 119. -->
+
+# references
+
+ICM Layer 3, the factory layer: stable reference material that does not change per run. Holds the venture_stage axis schema, the section and family methodology schemas, and the per-section nested sub-schemas. Read every run, edited rarely, never a destination for work product.

package/data/harness-fixtures/converged-room/references/SECTION-SCHEMA.md

@@ -0,0 +1,213 @@
+# Section Schema
+
+This is the stable schema behind every section in this room: ICM Layer 3, the factory layer.
+Read every run, edited rarely, never a destination for work product. It holds no value
+belonging to this particular venture - no room name, no current stage, no chosen methodology.
+This room's own current stage lives in `STATE.md` at the room root; this file only says which
+values are legal and what each one means.
+
+## 1. Three stage vocabularies, three separate axes
+
+Three vocabularies that sound alike coexist in this system. Conflating them bakes ambiguity
+into every room, so this is stated plainly, as a ruling (2026-09-02): these are three distinct
+axes, not three versions of one taxonomy. Each answers a different question and owns a
+different ICM layer.
+
+| Axis | Answers | Values | ICM layer | Where it lives |
+|---|---|---|---|---|
+| Problem type | What KIND of problem is on the table | Un-Defined, Ill-Defined, Well-Defined, with Wicked as a score-triggered escalation rather than a co-equal fourth value | L1 routing | Shared plugin routing code, not a room file |
+| Venture stage | How far along is THIS venture | the five values below | L0 identity, with its schema at L3 | The room's `STATE.md`; this file holds only the schema |
+| Brain innovation stage | Where in the teaching curriculum a methodology sits | Discovery, Focus, Proof, Creation, Launch Zone | Not a room concept | The Brain's own graph; zero runtime consumers in a room today, deliberately out of scope |
+
+The disconfirming test actually run: a search for any code path that reads one vocabulary and
+derives or writes another found nothing. What would overturn this ruling: a real code path that
+reads `venture_stage` to set `problem_type` or the reverse, or a runtime consumer of Brain
+innovation stage appearing inside a room.
+
+## 2. The venture_stage axis schema
+
+The five legal values, in order, from `lib/core/model-profiles.cjs`'s `VALID_STAGES`:
+
+| Value | What it means for the venture |
+|---|---|
+| Pre-Opportunity | No problem has been committed to yet. The venture is exploring a domain or interest, not yet defending a specific claim. |
+| Discovery | A candidate problem is named and the venture is establishing whether it is real and who has it. |
+| Validation | The problem is established; the venture is testing whether a solution and a market actually fit it. |
+| Design | The solution, business model, and team are being built out in detail. |
+| Investment | The venture is preparing to raise, seeking funding, or otherwise seeking external commitment on the strength of what has been built. |
+
+A room is born at Pre-Opportunity. Progression is bidirectional: a venture can regress, and the
+history is preserved rather than overwritten (this repo's Key Decision 14) - moving backward is
+not an error, it is the venture correcting course with the record intact.
+
+**Honesty note.** A sixth value, `QA`, has been observed written into room index files. It is
+NOT in the code's own valid-stage list (`VALID_STAGES` above), so treat it as drift rather than
+as a legal value. Do not add it to a room's `venture_stage` field on the strength of having seen
+it elsewhere.
+
+## 3. stage_relevance, per section
+
+This says when a section is most likely to matter, not when it is forbidden. A room owner
+working out of order is not making an error.
+
+| Section | stage_relevance |
+|---|---|
+| problem-definition | Pre-Opportunity, Discovery |
+| market-analysis | Discovery, Validation |
+| solution-design | Validation, Design |
+| business-model | Design, Investment |
+| competitive-analysis | Discovery, Design |
+| team-execution | Validation, Design |
+| legal-ip | Design, Investment |
+| financial-model | Design, Investment |
+| opportunity-bank | Pre-Opportunity, Discovery |
+| funding | Validation, Investment |
+| strategy | Discovery, Design |
+
+## 4. default_methodologies at two grains, and which one wins
+
+This is the part that was undocumented before Phase 275, and the two grains below were a
+colliding source of truth for the same fact, with nothing reconciling them. Documenting the
+reconciliation rule here IS the reconciliation.
+
+### Section grain
+
+Static, the same for every room, transcribed from `SECTION_METADATA` in
+`lib/core/room-skeleton-scaffold.cjs`:
+
+| Section | default_methodologies (section grain) |
+|---|---|
+| problem-definition | explore-domains, beautiful-question, diagnose |
+| market-analysis | analyze-needs, user-needs |
+| solution-design | bono, structure-argument, think-hats |
+| business-model | lean-canvas, validate-proposition, structure-argument |
+| competitive-analysis | compare-ventures, challenge-assumptions |
+| team-execution | leadership, think-hats |
+| legal-ip | structure-argument, challenge-assumptions |
+| financial-model | build-thesis, grade |
+| opportunity-bank | trending-to-absurd, whitespace, futures |
+| funding | mullins, grade |
+| strategy | scenario-plan, find-bottlenecks |
+
+### Family grain
+
+Chosen once, at room birth, from the navigator's arrival shape, transcribed from
+`data/room-blueprints.json`. All 9 blueprint families:
+
+| Family | default_methodologies (family grain) |
+|---|---|
+| exploration | explore-domains, beautiful-question, map-unknowns |
+| solution-first | find-analogies, user-needs, validate |
+| problem-first | validate, mullins, explore-domains |
+| business-first | lean-canvas, challenge-assumptions, diagnose |
+| portfolio | find-connections, whitespace, explore-domains |
+| venture | mva-brief, diagnose, lean-canvas |
+| program | explore-domains, mullins, validate |
+| case-study | diagnose, lean-canvas, find-analogies |
+| hypothesis | structure-argument, challenge-assumptions, validate, research |
+
+### The precedence rule, stated as what the code actually does
+
+When a blueprint family is active AND its `default_methodologies` array is non-empty, the
+FAMILY value is written into every section's `ROOM.md` frontmatter at scaffold time, and the
+section-grain value is not used. When no family is active, or the family's array is empty, the
+section-grain value from `SECTION_METADATA` is used instead.
+
+Grounded in `lib/core/room-skeleton-scaffold.cjs`, the `familyActive && defaultMethodologies.length > 0`
+ternary in the section write loop: family wins when it is both active and non-empty; the
+section-grain table above is the fallback, not a second, competing source of truth.
+
+## 5. Which commands write into which section
+
+Three tiers, and the confidence of each is labelled honestly, because they are not equal.
+Re-verified live against `data/command-registry.json` at authoring time, not transcribed from
+prior notes without checking - a stale reference here is worse than no document.
+
+### Ground truth (the command's own produces path names the section)
+
+| Section | Ground-truth commands |
+|---|---|
+| problem-definition | `/mos:beautiful-question`, `/mos:diagnose`, `/mos:explore-domains` |
+| market-analysis | `/mos:analyze-needs`, `/mos:user-needs` |
+| solution-design | `/mos:bono` |
+| business-model | `/mos:lean-canvas`, `/mos:validate-proposition` |
+| competitive-analysis | `/mos:compare-ventures` |
+| team-execution | `/mos:leadership` |
+| legal-ip | none today - zero commands produce directly into this section |
+| financial-model | none directly - relies entirely on the wildcard `/mos:build-thesis` (see Framework-matched, below) |
+| opportunity-bank | `/mos:futures`, `/mos:score-innovation`, `/mos:trending-to-absurd`, `/mos:whitespace` |
+| funding | none today - zero commands produce directly into this section |
+| strategy | `/mos:scenario-plan`, `/mos:find-bottlenecks`, `/mos:rs-experts`, `/mos:rs-explain`, `/mos:rs-fetch`, `/mos:rs-thesis` |
+
+`strategy`'s six commands are a deliberate, decided exception worth naming honestly: their own
+`produces` field is a cross-section wildcard path (`room/**/...`), not a path that literally
+names `strategy`. They are promoted to ground-truth status here by an explicit Phase 275 ruling
+(SEED-084 ADDENDUM 2026-09-04g, DECIDED), because `strategy` was created specifically to be
+their one proper home - Scenario Planning and Reverse Salient Analysis were previously
+judgment-call matches scattered across `market-analysis`, `business-model`, `financial-model`,
+`competitive-analysis`, and `solution-design`, and all of those scattered citations retarget
+here in this same pass. This is a documented, deliberate promotion, not an oversight in the
+ground-truth definition.
+
+### Framework-matched (a wildcard command whose named framework fits the section's job)
+
+A judgment call, flagged as such, not equal certainty to ground truth.
+
+| Section | Framework-matched commands (framework) |
+|---|---|
+| problem-definition | `/mos:root-cause`, `/mos:causal` (Root Cause Analysis), `/mos:map-unknowns` (Knowns/Unknowns Matrix), `/mos:build-knowledge` (Ackoff Pyramid), `/mos:validate` (JTBD), `/mos:research` (Hypothesis-Driven Problem Solving) |
+| market-analysis | `/mos:macro-trends` (PEST), `/mos:analyze-timing`, `/mos:diffusion` (Adoption-Capacity Theory), `/mos:explore-trends` (S-Curve), `/mos:dominant-designs` (Dominant Design), `/mos:mullins` (Mullins Model) |
+| solution-design | `/mos:find-analogies` (Four Lenses of Innovation), `/mos:find-connections` (Usher's Cumulative Synthesis), `/mos:analyze-systems`, `/mos:systems-thinking` (Systems Thinking), `/mos:hat-briefing` (Six Thinking Hats) |
+| business-model | `/mos:explore-futures` (Scenario Planning), `/mos:mullins` (Mullins Model), `/mos:analyze-systems` (Systems Thinking) |
+| competitive-analysis | none currently - the Reverse Salient family that judgment-matched here before Phase 275 moved to `strategy` (its proper Tier-1 home) in this same pass |
+| team-execution | `/mos:hat-briefing`, `/mos:think-hats` (Six Thinking Hats) |
+| legal-ip | `/mos:challenge-assumptions` (Red Teaming - risk-surfacing fits legal/IP exposure review) |
+| financial-model | `/mos:build-thesis`, `/mos:deep-grade`, `/mos:grade` (PWS Triple Validation Compass) |
+| opportunity-bank | `/mos:explore-futures` (Scenario Planning - exploring future opportunity space) |
+| funding | `/mos:mullins` (business case), `/mos:deep-grade`, `/mos:grade` (Triple Validation) - the only two indirect touches this section gets |
+| strategy | none additional - this section is the definitive Tier-1 home for its two frameworks, not a secondary match for anything else |
+
+### Room-wide infrastructure (no `room/` produces path at all)
+
+Roughly sixty commands (62 measured live against `data/command-registry.json` at authoring
+time) with no section affinity: they operate on the room as a whole (navigation, export, admin,
+meta-orchestration) rather than producing section content. Same pool for every section, not
+worth enumerating in full here. A handful of examples: `/mos:room`, `/mos:status`,
+`/mos:export`, `/mos:onboard`, `/mos:new-project`, `/mos:rooms`, `/mos:dashboard`, `/mos:act`,
+`/mos:doctor`, `/mos:help`, `/mos:wiki`, `/mos:graph`.
+
+Two utility surfaces belong here specifically, distinguished from the methodology commands
+above even though they name their sections in their own titles: `/mos:opportunities` (the
+scan/list/file pipeline-management surface for `opportunity-bank`) and `/mos:funding` (the
+list/create/advance/status/outcome pipeline-management surface for `funding`) are both
+registered `kind: utility` with no `produces` path - they manage the pipeline, they do not
+produce section content the way a methodology command does.
+
+## 6. What changed in Phase 275, and what did not
+
+The section set grew from 8 to 11: `opportunity-bank`, `funding`, `strategy` joined the frozen
+`SECTION_NAMES` table. Five dead or misfiled command citations were corrected in this pass,
+named here by their defect rather than by the dead slug's own literal name (a dead slug spelled
+out in a live reference document risks a future reader copy-pasting it as if it still resolved):
+a formerly-cited domain-exploration command, referenced twice (under `problem-definition` and
+under `market-analysis`), turned out not to exist at all and was simply removed; a
+formerly-cited scenario command (the old slug paired the Scenario Planning framework name with
+the general word for a written breakdown), referenced three times (under `market-analysis`,
+`business-model`, and `financial-model`), also turned out not to exist, and its live
+replacement, `/mos:scenario-plan`, is retargeted to the new `strategy` section rather than
+patched back into the three original sites. `trending-to-absurd` (live, but misfiled under
+`problem-definition` when it actually produces to `opportunity-bank` - refiled) and
+`analyze-needs` (live, but misfiled under `team-execution` when it actually produces to
+`market-analysis` - refiled) account for the two misfiled-citation corrections.
+
+`value-proposition` is sub-structure inside `business-model`, not a section of its own -
+"Value Proposition" stays reserved for the venture-level Triple Validation gate. `meetings` is a
+structural directory that feeds sections, not a section itself, and needed no schema change.
+`marketing-sales` and `research-documents` are deliberately deferred rather than rejected: the
+2026-04-14 primary source shows real intended content for `marketing-sales` (Marketing
+Strategies, Sales Strategies and Pipelines) that was simply never built.
+
+One more naming mismatch, found in passing while grounding this document, named here rather
+than silently absorbed: `/mos:persona` produces to `room/team/*`, a fourth section-slug spelling
+distinct from `team-execution`. Not a defect this plan is scoped to fix, named so a future
+reader does not rediscover it as new.

package/data/harness-fixtures/converged-room/references/SUB-SCHEMAS.md

@@ -0,0 +1,91 @@
+# Sub-Schemas
+
+The nested schemas inside individual sections. ICM Layer 3, same as its sibling
+`SECTION-SCHEMA.md`. A section whose contract says "the full field list lives in
+SUB-SCHEMAS.md" is pointing here.
+
+## 1. funding: two orthogonal dimensions
+
+This is two dimensions, not one, because collapsing them is the exact error the command's own
+Design Note exists to prevent: stage answers WHERE in the process an entry is; outcome answers
+WHAT the result was. An entry at Submitted can carry any of the three outcomes.
+
+### Stage (sequential, enforced)
+
+| Stage | What being there means |
+|---|---|
+| Discovered | The entry was just promoted from opportunity-bank; nothing has been researched yet. |
+| Researched | The room owner has looked into the funder, the program, and the fit. |
+| Applying | An application is actively being prepared. |
+| Submitted | The application has been sent; the room owner is waiting on a result. |
+
+Enforcement, stated verbatim: no skipping stages, no going backward, each transition is
+recorded in `transition_history`.
+
+### Outcome (orthogonal, not a stage)
+
+| Outcome | What it means | When valid |
+|---|---|---|
+| awarded | The funder approved the application | only at Submitted |
+| rejected | The funder declined the application | only at Submitted |
+| withdrawn | The room owner withdrew | at any stage |
+
+### Funding type
+
+Two types, per the 2026-04-14 primary source: `dilutive` (equity and venture capital;
+ownership is given up) and `non-dilutive` (grants and similar; ownership is retained).
+
+Honestly: the command surface implements the non-dilutive half today. Dilutive tracking is a
+named Phase 275 deferral. A dilutive entry, until that is built, is recorded as an ordinary
+dated entry folder without a stage machine, not as a `funding/<slug>/STATUS.md` pipeline entry.
+
+## 2. opportunity-bank: Knight position plus confidence
+
+Quoted verbatim from `commands/opportunities.md`: every opportunity carries a Knight position
+(risk vs uncertainty vs mixed) and a confidence score. Risk = known problem with quantifiable
+odds. Uncertainty = unknown problem requiring exploration. Mixed = contradiction that could go
+either way.
+
+Field shape: `knight_position` is one of `risk`, `uncertainty`, `mixed`. `confidence` is a
+number from 0.0 to 1.0.
+
+Two source kinds, each populated differently: a grant-sourced opportunity gets `risk` (grants
+are known risk) with confidence taken from its relevance score; a cascade-sourced opportunity
+takes both `knight_position` and `confidence` from the framework that surfaced it.
+
+The schema is load-bearing, not decorative: the `list` subcommand's filter flags consume these
+fields directly, `--knight <position>` and `--min-confidence <N>`.
+
+Why the distinction earns its place: risk and uncertainty are different problems requiring
+different next moves, and a bank that does not distinguish them cannot tell you which
+opportunities need a decision and which need exploration.
+
+## 3. team-execution: Mentor-Profiles
+
+This is where this document does work no existing file does. Define the record.
+
+**Required fields:**
+
+- `name`
+- `domain` - what they actually know
+- `answers` - the one question they are the right person to answer, stated as a question
+- `last_consulted` - a date
+
+**Optional fields:**
+
+- `relationship` - how they came to be in this venture's orbit
+- `access` - how to reach them and how much of their time is realistically available
+- `open_asks` - what is currently outstanding with them
+
+**Filing convention**, matching the L4 rule every section contract carries: one folder per
+mentor at `team-execution/mentors/<mentor-slug>/<mentor-slug>.md`, never a list inlined into
+`ROOM.md`.
+
+**The human check that makes the schema worth having:** if the `answers` field is empty or
+generic, the profile is a contact record, not a mentor profile, and it will not help anyone
+decide who to call.
+
+**The directory distinction**, because three spellings are live: `team-execution/` is the ICM
+section, a scored destination for methodology content. `team/` is a structural directory
+holding the people layer, including AI personas at `team/ai-personas/`. `meetings/` is the
+other structural directory, a source that feeds sections rather than a destination.

package/data/harness-fixtures/converged-room/solution-design/CONTEXT.md

@@ -0,0 +1,36 @@
+# solution-design - the solution and why
+
+**Statement:** This section holds the solution and the technical choices behind it, and why each choice was made.
+
+One job: hold the solution and the technical choices behind it, and why each choice was made.
+
+## Inputs
+- Working (this room): `problem-definition/`'s stated problem; `market-analysis/`'s named job.
+- Reference (every run): ../references/SECTION-SCHEMA.md
+- Reference (when relevant): ../references/SUB-SCHEMAS.md
+
+Do NOT load: the financial model.
+
+## Process
+1. State the solution.
+2. Name the technology stack.
+3. Name the features each stack choice enables. The 2026-04-14 Notion primary source nests Technology Stack directly beside Feature Planning under Solution and Product; that adjacency is why both live in this one section rather than split across two.
+
+## Outputs
+- One folder per artifact at `solution-design/<artifact-slug>/<artifact-slug>.md` (the Obsidian-nested convention, Key Decision 16). The folder IS the artifact.
+- Never inline content into `ROOM.md`. `ROOM.md` is ICM Layer 0 identity only: statement, purpose, stage relevance, default methodologies. Real content is ICM Layer 4 and lives in its own dated entry folder. Five of twelve sections in the audited `launchpad-02` room had already drifted this way; this line is why the contract exists.
+
+## Human check
+- Feynman: can a stranger restate this section's governing thought in one sentence, without jargon?
+- Minto: does the apex claim sit on MECE-grouped, non-overlapping support?
+- **Moat:** does this technical choice enable a feature that is hard to copy, or does it just solve the immediate problem? If the answer is "hard to copy," `competitive-analysis` is the section that tests whether the claimed defensibility actually holds against a real competitor: record the claim here, run the test there.
+
+  The doctrine behind this question, quoted verbatim from this plugin's own `.claude/includes/moat.md`: "Prompts can be copied. The graph that knows WHEN to use WHICH prompt, in WHAT SEQUENCE, calibrated by REAL teaching data, is the moat." The same causal shape, a copyable surface plus an uncopyable underlying capability, applied one level down: to the venture this room holds, not to the plugin itself (Canon Part 6 dog-fooding).
+
+  Name this honestly: it is a repeated Larry heuristic, not a book-canon framework. It shows up in Lean Canvas's Unfair Advantage box, in Build-Thesis's "defensible go / no-go" tagline, and in Larry's own investment-mode line, "That's a feature, not a moat. What happens when someone copies it?" Theo's book has no dedicated moat chapter. State that plainly; do not present this heuristic as canon it is not.
+
+## Commands that write here
+- Ground truth (the command's own `produces` path names this section): `/mos:bono` (produces `room/solution-design/*`)
+- Framework-matched (a wildcard command whose framework fits this section's job): `/mos:find-analogies`, `/mos:find-connections`, `/mos:analyze-systems`, `/mos:systems-thinking`, `/mos:hat-briefing`
+
+Note: the Reverse Salient family (`/mos:rs-experts`, `/mos:rs-explain`, `/mos:rs-fetch`) used to be framework-matched here and moved to `strategy` in Phase 275 (D-06), where it is ground truth instead.

package/data/harness-fixtures/converged-room/solution-design/ROOM.md

@@ -0,0 +1,36 @@
+---
+section: solution-design
+statement: "This section holds the solution and the technical choices behind it, and why each choice was made."
+purpose: "Design the solution, technology, and architecture."
+stage_relevance:
+  - Validation
+  - Design
+default_methodologies:
+  - bono
+  - structure-argument
+  - think-hats
+icm_layer: 0
+auto_scaffolded: true
+---
+
+<!-- ICM Layer 0 identity file per Canon decision 15 (every directory has ROOM.md).
+     This file was auto-scaffolded by Phase 119 (Room-as-Receipt Invariant); content
+     will be populated by /mos:* methodology runs or by Larry's first conversation.
+     Phase 275: `statement` is the ICM L1 routing field carried on this L0 identity
+     file, rendered twice (frontmatter key for tools, body blockquote for a human
+     or a foreign host reading raw markdown with no MCP tools). The ICM L2 contract
+     for this section lives in the sibling CONTEXT.md. -->
+
+# Solution Design
+
+> This section holds the solution and the technical choices behind it, and why each choice was made.
+
+Design the solution, technology, and architecture.
+
+## Starter Questions
+
+*(populated when material lands or methodology fires; until then the section is empty by design)*
+
+## Status
+
+Auto-scaffolded. Awaiting first content.

package/data/harness-fixtures/converged-room/strategy/CONTEXT.md

@@ -0,0 +1,35 @@
+# strategy - the futures and the bottlenecks
+
+**Statement:** This section holds where this venture could go and what is holding it back: the scenarios and the reverse salients.
+
+One job: work the futures and the bottlenecks. Where could this venture go, and what is holding it back right now.
+
+## Inputs
+- Working (this room): `problem-definition/`'s ladder position (Scenario Planning addresses Un-Defined, Ill-Defined AND Wicked problems, so it is broadly applicable rather than narrow); `market-analysis/`'s trends; `solution-design/`'s current architecture (a reverse salient is usually a technical or organisational bottleneck inside it).
+- Reference (every run): ../references/SECTION-SCHEMA.md
+- Reference (when relevant): ../references/SUB-SCHEMAS.md
+
+Do NOT load: the financial model. A scenario is a story about a plausible future, not a prediction with a number on it; do not turn scenarios into forecasts.
+
+## Process
+1. Find the reverse salient, the specific lagging component holding the whole system back (Thomas Hughes' bottleneck theory, the founding case).
+2. Build scenarios around it (Royal Dutch Shell's 1960s Group Planning department, the founding case).
+3. Name what each scenario would require you to decide differently.
+
+State the grounding for the pairing directly: the book's own graph asserts `Reverse Salient Analysis FEEDS_INTO Scenario Planning` with confidence 0.65 and the transform label `bottleneck-to-scenario`. These are not two unrelated tools filed under a label of convenience; the pairing is a graph-asserted relationship, not an engineering shortcut.
+
+Evidence-tier honesty, stated the way SEED-084 itself states it: `opportunity-bank` earned its place with a single verbatim book-canon hit defining one taxonomy rung; `strategy` is two strong, separately-chaptered frameworks that the book never groups under the name "Strategy." The organising label is a room-design choice; the two frameworks under it are canon. This is not inflated to canon it does not have, and it is not undersold either.
+
+## Outputs
+- One folder per artifact at `strategy/<artifact-slug>/<artifact-slug>.md` (the Obsidian-nested convention, Key Decision 16). The folder IS the artifact.
+- Never inline content into `ROOM.md`. `ROOM.md` is ICM Layer 0 identity only: statement, purpose, stage relevance, default methodologies. Real content is ICM Layer 4 and lives in its own dated entry folder. Five of twelve sections in the audited `launchpad-02` room had already drifted this way; this line is why the contract exists.
+
+## Human check
+- Feynman: can a stranger restate this section's governing thought in one sentence, without jargon?
+- Minto: does the apex claim sit on MECE-grouped, non-overlapping support?
+- For each scenario, name the one thing that would have to be observed for you to believe it is the one actually happening. A scenario with no such signal is a story, not a planning tool.
+
+## Commands that write here
+- Ground truth (locked by D-06): `/mos:scenario-plan`, `/mos:find-bottlenecks`, `/mos:rs-experts`, `/mos:rs-explain`, `/mos:rs-fetch`, `/mos:rs-thesis`
+
+Note: the dead slug `scenario-analysis` was cited by `market-analysis`, `business-model` AND `financial-model`; its live replacement `/mos:scenario-plan` now has a proper home here rather than three patched citations. The Reverse Salient family, previously framework-matched for `competitive-analysis` and `solution-design` and ground truth nowhere, is ground truth here.

package/data/harness-fixtures/converged-room/strategy/ROOM.md

@@ -0,0 +1,35 @@
+---
+section: strategy
+statement: "This section holds where this venture could go and what is holding it back, the scenarios and the reverse salients."
+purpose: "Work the futures and the bottlenecks, where this venture could go and what is holding it back."
+stage_relevance:
+  - Discovery
+  - Design
+default_methodologies:
+  - scenario-plan
+  - find-bottlenecks
+icm_layer: 0
+auto_scaffolded: true
+---
+
+<!-- ICM Layer 0 identity file per Canon decision 15 (every directory has ROOM.md).
+     This file was auto-scaffolded by Phase 119 (Room-as-Receipt Invariant); content
+     will be populated by /mos:* methodology runs or by Larry's first conversation.
+     Phase 275: `statement` is the ICM L1 routing field carried on this L0 identity
+     file, rendered twice (frontmatter key for tools, body blockquote for a human
+     or a foreign host reading raw markdown with no MCP tools). The ICM L2 contract
+     for this section lives in the sibling CONTEXT.md. -->
+
+# Strategy
+
+> This section holds where this venture could go and what is holding it back, the scenarios and the reverse salients.
+
+Work the futures and the bottlenecks, where this venture could go and what is holding it back.
+
+## Starter Questions
+
+*(populated when material lands or methodology fires; until then the section is empty by design)*
+
+## Status
+
+Auto-scaffolded. Awaiting first content.

package/data/harness-fixtures/converged-room/team/ROOM.md

@@ -0,0 +1,13 @@
+---
+directory_type: team
+icm_layer: 0
+auto_scaffolded: true
+purpose: "The people layer of the Data Room. Members, mentors, advisors -- created on demand from meetings or user input."
+---
+
+<!-- ICM Layer 0 identity file per Canon decision 15. Every directory in the Data
+     Room has ROOM.md -- no exceptions. This file was auto-scaffolded by Phase 119. -->
+
+# team
+
+The people layer of the Data Room. Members, mentors, advisors -- created on demand from meetings or user input.

package/data/harness-fixtures/converged-room/team-execution/CONTEXT.md

@@ -0,0 +1,36 @@
+# team-execution - who works, who advises, what next
+
+**Statement:** This section holds who does the work, who advises it, and what happens next.
+
+One job: hold who does the work, who advises it, and what happens next.
+
+## Inputs
+- Working (this room): `meetings/` (the structural directory where conversations land); the room's `team/` directory.
+- Reference (every run): ../references/SECTION-SCHEMA.md
+- Reference (when relevant): ../references/SUB-SCHEMAS.md
+
+Do NOT load: the market analysis.
+
+## Process
+1. Name who does the work: roles, not just names.
+2. Name who advises it, using the Mentor-Profiles sub-structure below.
+3. Name what happens next: the concrete execution step each person owns.
+
+**D-12, stated explicitly:** Mentor-Profiles is real sub-structure of this section, not a gesture. A mentor profile carries who they are, what domain they cover (their role and their domain expertise), what question they are the right person to answer, their availability, and when they were last consulted, cross-linked back to the meeting or entry that consulted them. The full field list lives in `../references/SUB-SCHEMAS.md` (plan 275-07 writes it); this contract points at that schema instead of duplicating it.
+
+Three spellings are live in this room, named here because a reader will otherwise conflate them: `team-execution/` is this ICM section, a scored destination for methodology content. `team/` is a structural directory (`STRUCTURAL_DIRS`), holding the people layer and, via `/mos:persona`, AI personas at `team/ai-personas/`. `meetings/` is the other structural directory, a source that feeds sections, not a destination. Phase 275 changed none of these; they are named here because the fourth-spelling confusion was found in passing during D-05's citation sweep.
+
+## Outputs
+- One folder per artifact at `team-execution/<artifact-slug>/<artifact-slug>.md` (the Obsidian-nested convention, Key Decision 16). The folder IS the artifact.
+- Never inline content into `ROOM.md`. `ROOM.md` is ICM Layer 0 identity only: statement, purpose, stage relevance, default methodologies. Real content is ICM Layer 4 and lives in its own dated entry folder. Five of twelve sections in the audited `launchpad-02` room had already drifted this way; this line is why the contract exists.
+
+## Human check
+- Feynman: can a stranger restate this section's governing thought in one sentence, without jargon?
+- Minto: does the apex claim sit on MECE-grouped, non-overlapping support?
+- For each named person, is there one sentence saying what only they can answer?
+
+## Commands that write here
+- Ground truth (the command's own `produces` path names this section): `/mos:leadership`
+- Framework-matched (a wildcard command whose framework fits this section's job): `/mos:hat-briefing`, `/mos:think-hats`
+
+Note: `/mos:analyze-needs` used to be cited here and was refiled to `market-analysis` in Phase 275 (D-05), because that is where it actually produces.

package/data/harness-fixtures/converged-room/team-execution/ROOM.md

@@ -0,0 +1,35 @@
+---
+section: team-execution
+statement: "This section holds who does the work, who advises it, and what happens next."
+purpose: "Document team, advisors, and execution plan."
+stage_relevance:
+  - Validation
+  - Design
+default_methodologies:
+  - leadership
+  - think-hats
+icm_layer: 0
+auto_scaffolded: true
+---
+
+<!-- ICM Layer 0 identity file per Canon decision 15 (every directory has ROOM.md).
+     This file was auto-scaffolded by Phase 119 (Room-as-Receipt Invariant); content
+     will be populated by /mos:* methodology runs or by Larry's first conversation.
+     Phase 275: `statement` is the ICM L1 routing field carried on this L0 identity
+     file, rendered twice (frontmatter key for tools, body blockquote for a human
+     or a foreign host reading raw markdown with no MCP tools). The ICM L2 contract
+     for this section lives in the sibling CONTEXT.md. -->
+
+# Team Execution
+
+> This section holds who does the work, who advises it, and what happens next.
+
+Document team, advisors, and execution plan.
+
+## Starter Questions
+
+*(populated when material lands or methodology fires; until then the section is empty by design)*
+
+## Status
+
+Auto-scaffolded. Awaiting first content.