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

package/templates/room-context/last-session.md

@@ -0,0 +1,56 @@
+# Last Session Log
+
+<!-- KAIROS-compatible format: consumed by dream cycles when tengu_kairos activates -->
+<!-- Written automatically by scripts/on-stop hook -->
+
+## Session Metadata
+
+- **Date:** {YYYY-MM-DD}
+- **Duration:** ~{N}min (estimated)
+- **Active Room:** {room-path}
+- **Venture Stage:** {stage from STATE.md}
+
+## Commands Invoked
+
+<!-- List of /mos:* commands run during this session -->
+- {command-1}
+- {command-2}
+
+## Artifacts Filed
+
+<!-- Count and list of artifacts created or modified -->
+- **Count:** {N}
+- **Files:**
+  - {section/artifact-name.md}
+
+## Signals Detected
+
+<!-- Proactive intelligence signals surfaced during session -->
+- **Contradictions:** {N found}
+- **Convergences:** {N found}
+- **Reverse Salients:** {N flagged}
+- **User Decisions:** {N APPROVE / N REJECT / N DEFER}
+
+## Active Methodology
+
+- **Last Framework Used:** {framework-name}
+- **Pipeline Stage:** {stage if in pipeline}
+- **Depth:** {shallow/medium/deep}
+
+## MINTO Governing Thoughts
+
+<!-- Current governing thoughts from active REASONING.md files -->
+- **Problem Definition:** {governing thought or "not yet established"}
+- **Market Analysis:** {governing thought or "not yet established"}
+- **Solution Design:** {governing thought or "not yet established"}
+
+## Pending Verifications
+
+<!-- Assumptions or claims that need validation before next session -->
+- {verification-1: description, status}
+- {verification-2: description, status}
+
+## Session Notes
+
+<!-- Free-form notes about session progress, blockers, or insights -->
+{notes}

package/templates/room-context/methodology-history.md

@@ -0,0 +1,28 @@
+# Methodology History
+
+<!-- KAIROS-compatible format: tracks which frameworks have been applied, where, and with what results -->
+<!-- Dream cycles use this to detect framework gaps and suggest next methodology runs -->
+
+## Format
+
+Each entry records a methodology session. Sorted chronologically, newest first.
+
+---
+
+## Sessions
+
+<!-- Append new entries at the top -->
+
+### {YYYY-MM-DD} - {framework-name}
+
+- **Date:** {YYYY-MM-DD}
+- **Framework:** {methodology command name, e.g., structure-argument}
+- **Section:** {room section targeted}
+- **Depth:** {shallow | medium | deep}
+- **Result:** {artifact filed | insight captured | no actionable output}
+- **Filed Artifacts:**
+  - {section/artifact-name.md}
+- **Signals Generated:**
+  - {N} new edges detected (types: {INFORMS, CONTRADICTS, etc.})
+- **Grade Impact:** {section grade before -> after, if grading was run}
+- **Notes:** {brief observation about what was learned}

package/templates/room-context/rejection-log.md

@@ -0,0 +1,25 @@
+# Rejection Log
+
+<!-- KAIROS-compatible format: "Why not" teaches the system as much as "yes" -->
+<!-- Key Decision #13: Rejection is data - rejection reasons become graph nodes -->
+
+## Format
+
+Each entry records a user rejection of a Larry suggestion. Dream cycles analyze
+rejection patterns to improve future suggestions.
+
+---
+
+## Rejections
+
+<!-- Append new entries at the top -->
+
+### {YYYY-MM-DD} - {suggestion-type}
+
+- **Suggestion:** {what Larry suggested}
+- **Rejection Reason:** {user's stated reason}
+- **Context:**
+  - Section: {room section where suggestion was made}
+  - Methodology: {framework that generated the suggestion}
+  - Venture Stage: {stage at time of rejection}
+- **Pattern Tag:** {category: timing | relevance | scope | depth | style | domain}

package/templates/room-context/weekly-digest.md

@@ -0,0 +1,54 @@
+# Weekly Digest
+
+<!-- KAIROS-compatible format: <25KB output limit for dream cycle consumption -->
+<!-- Dream cycles write to this file; sentinel mode reads from it -->
+<!-- When tengu_onyx_plover activates, auto-dream populates this weekly -->
+
+## Week of {YYYY-MM-DD}
+
+### Health Check
+
+| Section | Grade | Trend | Staleness |
+|---------|-------|-------|-----------|
+| problem-definition | {grade} | {up/down/stable} | {days since last filing} |
+| market-analysis | {grade} | {up/down/stable} | {days since last filing} |
+| solution-design | {grade} | {up/down/stable} | {days since last filing} |
+| business-model | {grade} | {up/down/stable} | {days since last filing} |
+| competitive-analysis | {grade} | {up/down/stable} | {days since last filing} |
+| team-execution | {grade} | {up/down/stable} | {days since last filing} |
+| legal-ip | {grade} | {up/down/stable} | {days since last filing} |
+| financial-model | {grade} | {up/down/stable} | {days since last filing} |
+
+### Gaps Identified
+
+<!-- Sections with declining grades, stale content, or missing REASONING.md -->
+- {gap-1: description, severity, suggested action}
+- {gap-2: description, severity, suggested action}
+
+### Convergences Detected
+
+<!-- Cross-section themes appearing in 3+ sections this week -->
+- {convergence-1: theme, sections involved, confidence}
+
+### Reverse Salients
+
+<!-- Lagging components relative to venture ambition -->
+- {reverse-salient-1: section, differential score, innovation thesis}
+
+### Cross-Session Patterns
+
+<!-- Patterns visible only across multiple sessions -->
+- {pattern-1: what was noticed, sessions involved}
+
+### Methodology Coverage
+
+| Framework | Last Used | Frequency | Sections Covered |
+|-----------|-----------|-----------|-----------------|
+| {framework} | {date} | {N times} | {sections} |
+
+### Recommendations
+
+<!-- Top 3 actions for next week, ranked by impact -->
+1. {recommendation-1}
+2. {recommendation-2}
+3. {recommendation-3}

package/templates/room-skeleton/MINTO.md.tmpl

@@ -0,0 +1,19 @@
+# MINTO Pyramid
+
+The Minto Pyramid Principle structures argument top-down: governing thought first, supporting arguments below, evidence at the leaves. This room's MINTO is empty until the first methodology lands content.
+
+<!-- mos:minto-begin -->
+## Governing Thought
+
+*(empty; will be populated when the first /mos:* methodology fires or when Larry synthesizes from the auto-explore finding)*
+
+## Supporting Arguments
+
+- *(empty support 1)*
+- *(empty support 2)*
+- *(empty support 3)*
+<!-- mos:minto-end -->
+
+## How This File Updates
+
+The sentinel-bounded section above is regenerated by `lib/core/feynman` pipelines. Edits between the sentinels are byte-preserved across regeneration; edits OUTSIDE the sentinels are append-safe.

package/templates/room-skeleton/ROOM.md.identity.tmpl

@@ -0,0 +1,13 @@
+---
+directory_type: {{DIRECTORY_TYPE}}
+icm_layer: 0
+auto_scaffolded: true
+purpose: "{{DIRECTORY_PURPOSE_YAML}}"
+---
+
+<!-- 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. -->
+
+# {{DIRECTORY_TYPE}}
+
+{{DIRECTORY_PURPOSE}}

package/templates/room-skeleton/ROOM.md.section.tmpl

@@ -0,0 +1,33 @@
+---
+section: {{SECTION_NAME}}
+statement: "{{STATEMENT_YAML}}"
+purpose: "{{SECTION_PURPOSE_YAML}}"
+stage_relevance:
+{{STAGE_RELEVANCE_LIST}}
+default_methodologies:
+{{DEFAULT_METHODOLOGIES_LIST}}
+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. -->
+
+# {{SECTION_NAME_TITLE_CASE}}
+
+> {{STATEMENT}}
+
+{{SECTION_PURPOSE}}
+
+## Starter Questions
+
+*(populated when material lands or methodology fires; until then the section is empty by design)*
+
+## Status
+
+Auto-scaffolded. Awaiting first content.

package/templates/room-skeleton/STATE.md.tmpl

@@ -0,0 +1,33 @@
+---
+phase: scoping
+role_blend: {}
+journey_stage: ordinary-world
+venture_name: untitled
+venture_stage: Pre-Opportunity
+auto_created: true
+auto_created_at: '{{AUTO_CREATED_AT_ISO}}'
+placeholder_slug: '{{PLACEHOLDER_SLUG}}'
+source_material_id: '{{SOURCE_MATERIAL_ID}}'
+---
+
+# Room State
+
+This room was auto-created as a side effect of receiving material (Canon Part 10 sub-claim 3: rooms are receipts, not entry points).
+
+The placeholder slug is `{{PLACEHOLDER_SLUG}}`. The room will be renamed (or discarded) at the first F.1 selector after the 30-second MVA pipeline completes -- see Phase 119-01.
+
+## Current Position
+
+- **Phase:** scoping (the very beginning)
+- **Role blend:** unknown (will be inferred from USER.md as conversation progresses; see Phase 115 dual-path detector)
+- **Journey stage:** ordinary-world (Campbell's monomyth Stage 1; the navigator has not yet crossed any threshold)
+
+## Recent Decisions
+
+None yet. Decisions land here via the Phase 88.2 F-shape selectors and the Phase 109 navigation chokepoint.
+
+## Active Focus
+
+None yet. The first material upload triggers Phase 117 auto-explore + Phase 118 30-second MVA -- those pipelines write the first focus node.
+
+<!-- compute-state stamp: pending; regenerate via `bash scripts/compute-state $ROOM_DIR > STATE.md` -->

package/templates/room-skeleton/USER.md.tmpl

@@ -0,0 +1,23 @@
+# User Context
+
+## Identity
+
+*(unknown; will be inferred from conversation per Phase 115 dual-path detector)*
+
+## Venture Context
+
+- **Core idea:** *(not yet articulated)*
+- **Stage:** Pre-Opportunity
+- **Primary concern:** *(unknown)*
+
+## Working Style
+
+*(unknown; will be inferred from conversational turns)*
+
+## Persona Blend
+
+*(empty -- per Phase 115 D-12, the persona blend is inferred from STATE.md + USER.md
+once enough material accumulates; until then Larry defaults to the 'default' variant)*
+
+<!-- Phase 119 auto-scaffolded. Edit freely; subsequent renames or content additions
+     from /mos:onboard / /mos:new-project / persona-analyst will merge into this file. -->

package/templates/room-skeleton/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/templates/room-skeleton/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/templates/room-skeleton/section-contracts/business-model.md

@@ -0,0 +1,32 @@
+# business-model - how this venture makes money
+
+**Statement:** This section holds how this venture makes money, and the value proposition that claim rests on.
+
+One job: hold how this venture makes money, and the value proposition that claim rests on.
+
+## Inputs
+- Working (this room): `market-analysis/`'s segments; `solution-design/`'s solution.
+- Reference (every run): ../references/SECTION-SCHEMA.md
+- Reference (when relevant): ../references/SUB-SCHEMAS.md
+
+Do NOT load: the legal structure or agreements. That is `legal-ip/`'s job; this section states the revenue logic, not the contracts that implement it.
+
+## Process
+1. Name the revenue model: how the venture actually gets paid.
+2. Name the customer segments and the payer, who signs, which may not be the same person as the user. If they differ, name both.
+3. Name the value proposition the whole claim rests on.
+
+**D-02, stated explicitly:** Value Proposition is sub-structure inside this section, NOT a section of its own. Three independent sources agree: Theo's book has no standalone value-proposition chapter (the material sits inside `bmd`, business model design); the 2026-04-14 Notion primary source gives Value Proposition and Business Model the identical statement text ("How Do We make money") and the identical icon, immediately adjacent; and `/mos:validate-proposition` already produces into `room/business-model/value-proposition/*` in the live command registry. One reservation, stated for the same reason: "Value Proposition" is a loaded PWS term naming the third gate of Triple Validation (Is it Real? / Can We Win? / Is it Worth It?), a venture-level judgment, so it is not reused as a per-section field name anywhere.
+
+## Outputs
+- One folder per artifact at `business-model/<artifact-slug>/<artifact-slug>.md` (the Obsidian-nested convention, Key Decision 16). The folder IS the artifact. `value-proposition/` is one such sub-folder, not a separate section.
+- 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?
+- Who signs the cheque, and is that the same person as the user? If not, both are named.
+
+## Commands that write here
+- Ground truth (the command's own `produces` path names this section): `/mos:lean-canvas`, `/mos:validate-proposition`
+- Framework-matched (a wildcard command whose framework fits this section's job): `/mos:explore-futures`, `/mos:mullins`, `/mos:analyze-systems`