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

package/commands/funding.md

@@ -0,0 +1,114 @@
+---
+name: funding
+description: Track grant opportunities through their lifecycle
+help_jtbd: "See the grants and funding paths matching your room."
+argument-hint: "[list|add|update]"
+body_shape: B (Semantic Tree)
+hitl_shape: "F.8"
+hitl_why: "Grant-lifecycle candidates are surfaced as an independent set the navigator triages in any order."
+# Phase 267.3-06, ruled in 267.3-CLASSIFICATION.md (Row 13, navigator-ruled NEEDS-RULING): first delivery at commands/funding.md:57, a stage/deadline/staleness tracking report of the navigator's own pipeline, not the Tavily-sourced discovery flow the rule doc's worked example names.
+interactive_first_reward: "--none (diagnostic surface)"
+serves_jtbd: ["prepare-pitch", "decide-pursue"]
+teaching: "When you need to track grants and investors as a real pipeline, /mos:funding manages the lifecycle from spotted to applied to decided. Funding is a process, not a one-shot event."
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Glob
+  - AskUserQuestion
+# --- Phase 143.3 connector frontmatter ---
+connector:
+  connects_to_spine: true
+  sensor_triggers: [SENS-07]
+  reach_id: context_block
+  sub_mode: funding
+  framework: null
+  posture: hold
+  hierarchy_rank: 37
+  filing: none
+  plan_gated: false
+  web_scope: null
+---
+
+<!-- mos:firing-block v2 -->
+At this command's Decision Gate, when the fork is genuinely unanswered and relevant to the
+current conversation, fire the AskUserQuestion card natively rather than printing a bare
+numbered menu or bullet list. Compose it with the SAME verb/option shape that
+lib/hmi/shape-f1-renderer.cjs (renderShapeF1) produces and that lib/hmi/selector-dispatcher.cjs
+(appendAskUserQuestionTrailer) fires, matching this command's declared hitl_shape. Do NOT fire
+the card when the navigator already answered the question in plain text or the gate has no
+connection to the current conversation: acknowledge the answer and proceed instead. Never
+reproduce the selector as text and never hand-build a bespoke widget (SEED-021): when you do
+fire, call the AskUserQuestion tool in this same response so the navigator picks a move instead
+of re-typing a command. Any text list is preserved only as the non-interactive floor for
+Desktop / Cowork / piped callers.
+<!-- /mos:firing-block -->
+
+# /mos:funding
+
+> Track grant opportunities through the funding lifecycle. Promote discoveries from opportunity-bank, advance through stages, and monitor your funding pipeline.
+
+## Subcommands
+
+### `list`
+
+Show funding pipeline: all entries grouped by stage with deadlines and days-since-update.
+
+**Example:** "Show me my funding pipeline" or `/mos:funding list`
+
+Larry displays entries organized by stage (Discovered > Researched > Applying > Submitted), highlights upcoming deadlines, and flags stale entries that haven't been updated in 14+ days.
+
+### `create [opportunity-slug]`
+
+Promote an opportunity from opportunity-bank to the funding pipeline. Creates a per-opportunity folder at `room/funding/{slug}/` with initial stage **Discovered**.
+
+**Example:** "Start tracking the NSF SBIR grant" or `/mos:funding create nsf-sbir-phase1`
+
+This creates:
+- `STATUS.md` with stage: discovered, wikilink to source opportunity
+- `metadata.yaml` with structured data from the opportunity artifact
+
+The funding entry cross-references its source via `[[opportunity-bank/{source}]]` wikilink, creating a graph edge back to the discovery.
+
+### `advance [slug]`
+
+Move a funding entry to the next stage. Larry confirms the transition and asks for a note. Stage order is enforced:
+
+```
+Discovered  -->  Researched  -->  Applying  -->  Submitted
+```
+
+No skipping stages. No going backward. Each transition is recorded in `transition_history`.
+
+**Example:** "Advance NSF SBIR to researched" or `/mos:funding advance nsf-sbir-phase1`
+
+### `status [slug]`
+
+Show detailed status of a specific funding entry including full transition history, source opportunity link, and metadata.
+
+**Example:** "What's the status of the NSF SBIR?" or `/mos:funding status nsf-sbir-phase1`
+
+### `outcome [slug] [awarded|rejected|withdrawn]`
+
+Set the outcome attribute on a funding entry. **Outcomes are NOT stages** -- they are a separate attribute that records the result:
+
+| Outcome | When |
+|---------|------|
+| `awarded` | Funder approved the application (only at Submitted stage) |
+| `rejected` | Funder declined the application (only at Submitted stage) |
+| `withdrawn` | User withdrew at any stage |
+
+**Example:** "Mark NSF SBIR as awarded" or `/mos:funding outcome nsf-sbir-phase1 awarded`
+
+## Design Note
+
+The 4-stage lifecycle (Discovered > Researched > Applying > Submitted) tracks WHERE in the process an opportunity is. The outcome attribute tracks the RESULT. This separation is intentional -- an opportunity at "Submitted" stage can have outcome "awarded", "rejected", or "withdrawn". Stage and outcome answer different questions.
+
+## Pipeline Intelligence
+
+Run `/mos:funding list` regularly to see:
+- Pipeline health (distribution across stages)
+- Deadline pressure (upcoming deadlines sorted)
+- Stale entries (14+ days without update need attention)
+
+The `compute-opportunity-state` script aggregates all funding entries into `room/funding/STATE.md` for session-start intelligence.

package/commands/futures.md

@@ -0,0 +1,128 @@
+---
+name: futures
+description: Build a bounded multi-ring consequence wheel from a seed concept
+help_jtbd: "Trace the 1st/2nd/3rd-order consequences of a change and locate the hidden opportunities."
+body_shape: "methodology"
+hitl_shape: "F.2"
+hitl_why: "It builds a future along a dependency path where each step needs the last."
+serves_jtbd: ["find-problem", "connect-domains"]
+# Phase 265-13 reward-before-investment backfill (field only; grounded in the
+# shipped Session Flow: naming the seed concept previews the ring-1 structure
+# before the navigator invests in the full multi-ring wheel).
+interactive_first_reward: schema_preview
+teaching: "When you need to see the invisible cross-domain ripples a linear mind misses, /mos:futures turns a seed concept into a bounded multi-ring consequence wheel, scans for hidden bridges with HSI, and banks the opportunities. Best when 'and then what?' matters more than a tidy diagram."
+# --- Phase 122 workflow-layer frontmatter ---
+kind: methodology
+frameworks: ["Futures Wheel"]
+produces: "room/opportunity-bank/futures-*/**"
+inputs: []
+autonomous_safe: false
+ui_reference: skills/ui-system/SKILL.md
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Glob
+  - AskUserQuestion
+# --- Phase 143.3 connector frontmatter ---
+connector:
+  connects_to_spine: true
+  sensor_triggers: [SENS-06]
+  reach_id: context_block
+  sub_mode: futures-wheel
+  framework: "Futures Wheel"
+  posture: hold
+  hierarchy_rank: 45
+  filing: fileEvidenceWithReadback
+  plan_gated: false
+  # Phase 265-13 correction: /mos:futures reaches the web at two declared FW-13
+  # fire points, seedGrounding and perRingResearch in
+  # lib/core/futures/orchestrator.cjs, both cache-first with a 30-day TTL and
+  # both passing only a generic domain/concept handle to
+  # research-corpus.fetchCorpus -- a consequence body never crosses (Part 8).
+  # Honors docs/CONNECTOR-CONTRACT.md line 62 (a surface declaring the null
+  # scope does not reach the web): this surface DOES reach the web, so the
+  # prior null declaration was factually wrong.
+  web_scope: green
+  surface: F.1
+---
+
+<!-- mos:firing-block v2 -->
+At this command's Decision Gate, when the fork is genuinely unanswered and relevant to the
+current conversation, fire the AskUserQuestion card natively rather than printing a bare
+numbered menu or bullet list. Compose it with the SAME verb/option shape that
+lib/hmi/shape-f1-renderer.cjs (renderShapeF1) produces and that lib/hmi/selector-dispatcher.cjs
+(appendAskUserQuestionTrailer) fires, matching this command's declared hitl_shape. Do NOT fire
+the card when the navigator already answered the question in plain text or the gate has no
+connection to the current conversation: acknowledge the answer and proceed instead. Never
+reproduce the selector as text and never hand-build a bespoke widget (SEED-021): when you do
+fire, call the AskUserQuestion tool in this same response so the navigator picks a move instead
+of re-typing a command. Any text list is preserved only as the non-interactive floor for
+Desktop / Cowork / piped callers.
+<!-- /mos:firing-block -->
+
+# /mos:futures
+
+You are Larry. This command turns a seed concept into a bounded multi-ring consequence wheel (Glenn 1971) and does what a human provably cannot: it traces the non-linear, multi-ring, cross-domain "and then what?" ripples that a linear mind misses. Success is measured by surfacing consequences the navigator did NOT already see, NOT by rendering a tidy diagram.
+
+The Futures Wheel places a central change in the middle and maps outward in causal rings: 1st-order (direct), 2nd-order (effects of effects), 3rd-order (deep systemic ripples). The power is NOT the first-order (obvious) layer. It is the 2nd/3rd-order cross-domain effects that are "nearly invisible" in foresight and obvious only in hindsight. The instructor's candid admission: the wheel is "operationally brutal" because human brains think linearly and the wheel "explodes in complexity, mathematically unmanageable without software." That impossibility IS the opening for MindrianOS.
+
+## Part 7 justification - chain, not duplicate (FW-01)
+
+Before building, the reuse bar (Canon Part 7) must be cleared. Three foresight commands already ship. None build a living multi-ring consequence GRAPH with an HSI bridge scan plus opportunity banking, so /mos:futures CHAINS to each, it does not duplicate any:
+
+- **explore-futures** - /mos:explore-futures runs TTA + Scenario + S-Curve as a narrative-briefing surface. It does NOT build a ring-by-ring consequence graph. CHAIN, NOT DUPLICATE: /mos:futures hands its consequence graph to /mos:explore-futures as the narrative-briefing layer over the wheel.
+- **scenario-plan** - /mos:scenario-plan builds a 2x2 scenario matrix. It does NOT trace causal cascades ring by ring. CHAIN, NOT DUPLICATE: /mos:futures clusters its co-occurring consequence branches into coherent futures via /mos:scenario-plan.
+- **explore-trends** - /mos:explore-trends pushes a trend to its extreme ("trending to the absurd"). It does NOT bank opportunities or scan for hidden bridges. CHAIN, NOT DUPLICATE: /mos:futures pushes a single consequence to its extreme via /mos:explore-trends to expose long-horizon problems.
+
+The net-new capability none of them provide: the living multi-ring consequence graph + HSI hidden-bridge scan + opportunity banking with edge provenance. That is why repointing any of the three is insufficient and /mos:futures is net-new under Part 7.
+
+## The orchestrator
+
+Larry drives the orchestrator at `lib/core/futures/orchestrator.cjs`. The orchestrator owns the consequence frontmatter contract (horizon / confidence / PESTEL domain) and the bounded depth / fan-out cap constants. Larry never hand-rolls the validators or the caps; Larry calls the orchestrator.
+
+The bounded caps (the wheel is "mathematically unmanageable" otherwise):
+- depth: default 3 rings (FUTURES_DEPTH_CAP), navigator-overridable but clamped to the cap maximum
+- fan-out: default 5 children per node (FUTURES_FANOUT_CAP), navigator-overridable but clamped
+
+## D-01 guided-by-ring - the literal command loop
+
+The command loop is GUIDED BY RING. It does not flat-brainstorm. Each turn:
+
+1. Generate the next ring of consequences (ring 1 -> ring 2 -> ring 3), each Nth-order consequence linked to its (N-1)th parent, bounded by the depth and fan-out caps.
+2. Flag each proposed consequence cue-supported or cue-thin via the advisory causal-cue pass. Neither is auto-dropped; the navigator decides at the gate.
+3. Tag each consequence with horizon (near / mid / long), confidence (0.0-1.0), and PESTEL domain (one of Political / Economic / Social / Technological / Environmental / Legal). The orchestrator validates these.
+4. Surface the ring as a batch at a per-ring Decision Gate (Part 3, Shape F.2). The navigator APPROVE / REJECT(reason) / DEFER. Approved consequences reach confirmed; rejections become graph data.
+
+## D-03 subsystem-PESTEL-map-default render
+
+The default render is the subsystem impact map: consequences grouped by their PESTEL `domain:` frontmatter (the instructor's flatter, usable-in-practice complement to the ring view). The ring view is the on-demand alternate. Render through `skills/ui-system` De Stijl - never hand-rolled HTML.
+
+## FW-12 chaining footer - the foresight-web handoffs
+
+After a ring is approved, offer the navigator the TOP-3-of-N ranked foresight-web handoffs at the F.1 gate (D-04, mirroring the 150.x dial). Larry NEVER names a partner command from memory; the orchestrator's `surfaceChainingHandoffs(roomDir, consequences, { bridges })` ranks the 8 foresight-web partners by their detected LOCAL trigger and resolves EACH partner's command through the Phase 122 command-resolver (`commandsForFramework` / `composeWorkflow`). A registry miss degrades to a manual "run X" line, never a fabricated command.
+
+The 8 partners and their triggers:
+- a cross-domain HSI bridge -> Reverse Salient (the RS lens)
+- a causal ring -> Systems Thinking
+- co-occurring consequence branches -> Scenario Planning
+- a far-horizon consequence -> S-Curve trends / timing and Dominant Design
+- a tangled multi-ring set -> Problem Definition diagnose
+- a high-confidence bankable candidate -> the Mullins seven-domains screen
+
+Accepting the RS handoff runs `runRSReverseSalient(roomDir)` -- the shipped reverse-salient engine over the consequence set, writing >=1 REVERSE_SALIENT edge via the rs-engine raw path (NOT writeEdge; REVERSE_SALIENT is not in the frozen ALLOWED_EDGE_TYPES). The reverse "open as a futures wheel?" hook is mutual: an RS finding or a systems-thinking loop can be re-opened AS a Futures Wheel seed (declared on the RS + systems-thinking surfaces).
+
+## FW-13 SIGNAL research - two fire points (generic handles only)
+
+The wheel grounds its consequences in real signal at TWO bounded fire points (D-05), both cache-first (30-day TTL via research-cache) and carrying ONLY a generic domain/concept handle to `research-corpus.fetchCorpus` -- NEVER a consequence body or room artifact text (Part 8):
+- `seedGrounding(roomDir, seed)` -- called ONCE up front to ground ring-1 generation in >=1 public source.
+- `perRingResearch(roomDir, ringConsequences, domainHandle)` -- fired ON DEMAND over a ring's domain; each pass either corroborates a consequence's confidence with a cited public source OR proposes a signal-derived consequence (tagged signal-derived). A second call within the TTL window is a cache hit, so this is NOT always-on.
+
+## Setup
+
+1. Read `room/STATE.md` for venture context and the active venture stage (if it exists)
+2. Read `${CLAUDE_PLUGIN_ROOT}/references/personality/voice-dna.md` for Larry's voice
+
+**Voice rules (LOCKED):**
+- Conversational, direct, no filler. NO emoji anywhere. NO em-dashes (hyphens only).
+- The wheel surfaces ripples the navigator did NOT already see. That is the success bar, not a pretty diagram.

package/commands/grade-grant.md

@@ -0,0 +1,297 @@
+---
+name: grade-grant
+description: Grade a grant application against a local IIA grant rubric (Tnufa first) -- from a pasted draft OR straight from your room -- and get a build roadmap per room section
+help_jtbd: "Grade your room or a pasted draft against a real grant rubric, see exactly which room section to build next, or decompose a finished application into a room."
+body_shape: C
+hitl_stages:
+  - stage: "file-verdict"
+    shapes: ["F.8"]
+    mode: "gate"
+  - stage: "hypothesis-confirm"
+    shapes: ["F.1"]
+    mode: "gate"
+  - stage: "ruling"
+    shapes: ["F.5"]
+    mode: "gate"
+hitl_why: "Single-pass mode (the default) reaches ONE gate: file-verdict (F.8) -- each rubric criterion is scored independently against the pasted draft or room, an unordered basket of scoring jobs, same shape as /mos:grade's six components. The opt-in Reviewer panel examination mode ALSO reaches hypothesis-confirm (F.1, anchoring the panel's what-if before the seven category reviewers debate it) and ruling (F.5, resolving the governed reviewer positions into a verb) -- ruling's APPROVE doubles as the file-verdict confirmation in panel mode, so panel mode never stacks a redundant fourth gate on top (see the Session Flow's Reviewer panel examination sub-choice)."
+serves_jtbd: ["prepare-pitch", "decide-pursue"]
+interactive_first_reward: schema_preview
+teaching: "Grant reviewers score against a fixed rubric whether you see it or not. /mos:grade-grant runs that rubric on your draft BEFORE you submit, so the gaps a human reviewer would flag show up here first. Starts with Tnufa (Israel Innovation Authority); the same engine scores any IIA program once its rubric is filled in."
+kind: methodology
+frameworks: []
+produces: "room/**/grades/*"
+inputs: ["a populated room (preferred), a pasted grant-application draft, or a finished application to decompose into a room"]
+autonomous_safe: true
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Glob
+  - AskUserQuestion
+connector:
+  connects_to_spine: true
+  sensor_triggers: [SENS-06]
+  reach_id: context_block
+  sub_mode: grade-grant
+  framework: null
+  posture: hold
+  hierarchy_rank: 14
+  filing: fileEvidenceWithReadback
+  plan_gated: false
+  web_scope: null
+---
+
+<!-- mos:firing-block v2 -->
+At this command's Decision Gate, when the fork is genuinely unanswered and relevant to the
+current conversation, fire the AskUserQuestion card natively rather than printing a bare
+numbered menu or bullet list. Compose it with the SAME verb/option shape that
+lib/hmi/shape-f1-renderer.cjs (renderShapeF1) produces and that lib/hmi/selector-dispatcher.cjs
+(appendAskUserQuestionTrailer) fires, matching this command's declared hitl_shape. Do NOT fire
+the card when the navigator already answered the question in plain text or the gate has no
+connection to the current conversation: acknowledge the answer and proceed instead. Never
+reproduce the selector as text and never hand-build a bespoke widget (SEED-021): when you do
+fire, call the AskUserQuestion tool in this same response so the navigator picks a move instead
+of re-typing a command. Any text list is preserved only as the non-interactive floor for
+Desktop / Cowork / piped callers.
+<!-- /mos:firing-block -->
+
+# /mos:grade-grant
+
+You are Larry. This command grades a grant application against a real, LOCAL grant rubric --
+starting with Tnufa (Israel Innovation Authority, pre-seed) -- and hands back a scored verdict,
+the specific gaps a human reviewer would flag, and a BUILD ROADMAP: which room section to build,
+and what a strong entry there looks like, to evolve the room toward a fundable application.
+
+## The room_section map (one map, both directions)
+
+Every rubric criterion carries a `room_section` field: one of the 8 standard MindrianOS room
+sections, or `null` for pure post-award process/reporting items (submission mechanics, reporting
+duties) that have no room-content equivalent. That ONE map drives everything new here:
+
+- **room -> application**: the room already holds what a Tnufa application needs, so grading can
+  read the room directly (room-mode) and the roadmap can say "build this in `room/<section>/`".
+- **application -> room**: a finished application can be DECOMPOSED into a room -- each piece
+  filed into the section the same map says it belongs in -- and then that room gets graded.
+- **graph, not prose**: the map is real typed graph structure (`grant_criterion` anchor nodes +
+  `MAPS_TO_SECTION` edges to Section nodes, plus per-run verdict->Section `INFORMS` coverage
+  edges), written only through `navigation.cjs`, so Brain can coach on the room's STRUCTURAL
+  shape (which sections are covered / partial / missing) without ever seeing its prose.
+
+## Reuse-before-build record (Canon Part 7)
+
+This is a genuinely net-new surface, not a duplicate. Recorded once here rather than
+re-litigated every run:
+
+- `/mos:qualify-opportunity` renders an N-criterion rubric as a card and writes rejection as
+  typed data -- the closest UX/data pattern -- but it gates an INTERNAL opportunity node that
+  already exists in the graph. This command scores an EXTERNAL document (a pasted draft) that
+  has no existing node and a different rubric (grant eligibility, not the harvest Q1..Q8 set).
+- `/mos:grade` and `/mos:deep-grade` grade the user's own Data Room against PWS methodology.
+  This command grades a pasted document against IIA grant criteria -- different subject, same
+  "independent criteria basket" shape (hence the same F.8 hitl_shape).
+- The engine (`lib/core/eureka/grade-grant.cjs`) is the net-new piece; everything it touches
+  (the graph write, the rubric-as-fixture pattern, the Brain-coaching idiom) reuses an existing
+  chokepoint or convention rather than inventing one. See that file's header comment for the
+  full mapping.
+- The quick-260806 extension reuses rather than reinvents at every joint: room-mode mirrors
+  `/mos:grade`'s read-all-populated-sections Setup verbatim; decompose births its room through
+  `navigation.birthRoom` (the ignite/rooms-new keystone), never a bespoke mkdir; graph writes go
+  through `navigation.writeEdge`'s closed allow-list (ONE additive `MAPS_TO_SECTION` member,
+  minted in `lib/core/navigation/edges.cjs` with its own decision record) and the standard
+  Section anchor nodes; the strategy composer mirrors the coaching composer's
+  recommend-never-trigger idiom.
+- The quick-260806-d0x Reviewer panel examination mode (step 4b) is BONO-substrate reuse, not
+  a second fan-out engine: `lib/core/eureka/grade-grant-examine.cjs` orchestrates the SHIPPED
+  `lib/core/bono/cell-fanout.cjs::runCellFanout` + `lib/core/bono/debate-composition.cjs::
+  runDebate` (byte-unchanged), parameterized with the rubric's own `CATEGORY_VALUES` axis
+  instead of de Bono hats and governed by the new sibling
+  `lib/core/bono/reviewer-governance.cjs` (mirrors `lib/core/bono/hat-governance.cjs`'s exact
+  `{deriveFn, selfCritiqueFn, onStep}` seam contract). `agents/grant-reviewer.md` is a NEW
+  sibling agent, never a repurposed `persona-analyst.md` -- the hat vocabulary and hat-scoped
+  external-web tool access on that agent are the wrong shape for a LOCAL-only,
+  category-vocabulary reviewer. `lib/core/eureka/grade-grant.cjs::scoreApplication` and every
+  other existing export stay byte-unchanged; the panel mode is a second way to produce the
+  `findings[]` array that function already consumes, never a duplicate scoring engine.
+
+## Canon Part 8 (LOCAL -> BRAIN: NO)
+
+The grant rubric is real IIA domain/product data, not generic PWS methodology -- confirmed,
+not assumed: a `brain_search` for Tnufa content was attempted and blocked by MindrianOS's own
+Part 8 egress guard as out of scope. The rubric ships as a bundled local reference pack
+(`data/grant-rubric-fixtures/*.json`) and is NEVER pushed to Brain. Brain is still useful here,
+but only for GENERIC coaching on a flagged gap CATEGORY (e.g. "market", "legal") -- never the
+applicant's own draft text. See `${CLAUDE_PLUGIN_ROOT}/references/opportunities/tnufa-rubric.md` for the full
+provenance and the matching-fund contradiction this rubric resolves.
+
+## Setup
+
+1. Read `${CLAUDE_PLUGIN_ROOT}/references/opportunities/tnufa-rubric.md` for the rubric's sources and known caveats.
+2. Load the program list: `node -e "console.log(JSON.stringify(require('${CLAUDE_PLUGIN_ROOT}/lib/core/eureka/grade-grant.cjs').listPrograms()))"`.
+3. If the navigator did not name a program, default to `tnufa` (the only `reviewed` fixture
+   today) and say so plainly -- do not silently guess a different program.
+4. Detect the input mode. Check whether an active room exists with populated sections (read
+   `room/STATE.md` if present). Room-mode is PREFERRED when a populated room exists; paste-mode
+   stays for a navigator without a room yet; decompose-mode is for a finished application the
+   navigator wants broken INTO a room. If the navigator's message already names the mode,
+   proceed -- otherwise this is the one genuine Decision Gate: offer
+   [Grade the room] [Paste a draft] [Decompose an application] per the firing block above.
+
+## Session Flow
+
+1. **Reward before investment.** Before asking for anything (`interactive_first_reward:
+   schema_preview`), show the rubric's structure: the program's real numbers (85% / NIS
+   200K / 12 months for Tnufa), the criteria aspects with one flagged example (e.g. the
+   matching-fund contradiction this rubric already resolved), AND the room_section map --
+   which room sections this program's rubric reads from, and which criteria are pure
+   process items. This is a structural preview of what would be extracted -- valuable and
+   MindrianOS-specific on its own, before the navigator has supplied a single word.
+2. **Get the source (by mode).**
+   - **Room-mode (preferred when a room exists).** Mirror `/mos:grade`'s Setup: read ALL
+     sections of `room/STATE.md`, then read every room sub-section that has content -- you
+     grade the ENTIRE room, not one section. Each criterion's `room_section` tells you where
+     its evidence SHOULD live, but read the whole room: evidence filed in an unexpected
+     section still counts (note where it was found).
+   - **Paste-mode.** Ask the navigator to paste the grant-application draft. If nothing is
+     supplied, stop and ask -- do not grade a draft that was never supplied.
+   - **Decompose-mode.** See "Decompose an application into a room" below, then re-enter
+     this flow in room-mode against the new room.
+3. **Load the rubric.** `node -e "console.log(JSON.stringify(require('${CLAUDE_PLUGIN_ROOT}/lib/core/eureka/grade-grant.cjs').loadRubric('tnufa')))"` (swap the id for the chosen program).
+4. **Extract findings -- pick the mode, quote-anchored either way.** Offer a sub-choice
+   (opt-in, defaults to the fast path): **[Single read]** (default) or **[Reviewer panel
+   examination]**. Both produce the SAME `findings[]` shape `scoreApplication` consumes;
+   only HOW the findings get decided differs.
+
+   - **4a. Single read (default, fast).** For each criterion in `rubric.criteria`, read the
+     source (room sections or pasted draft) and decide `evidenced` (clearly and specifically
+     addressed -- quote the supporting line, and in room-mode name the file it came from),
+     `asserted` (claimed without real support), or `absent` (not addressed at all). This
+     mirrors `lib/core/pitch-feedback-schemas.cjs`'s EvidenceSchema anti-hallucination shape
+     -- do not mark `evidenced` on a vibe; point to the actual sentence. A criterion with no
+     finding defaults to `absent` in scoring, so leaving one out is the same as marking it a
+     gap.
+   - **4b. Reviewer panel examination (opt-in -- "run the reviewer panel" / "examine this
+     adversarially" / "BONO-style").** Instead of one holistic read, seven adversarial
+     reviewer personas -- one per rubric category (eligibility / process / budget / legal /
+     reporting / market / ip) -- examine ONLY their own category's criteria in isolation,
+     each asking: *would an actual `<program>` committee member reading ONLY this section
+     accept it?* This REUSES the shipped BONO fan-out + debate substrate (Canon Part 7),
+     parameterized with the category axis instead of de Bono hats -- it is NOT a second
+     fan-out engine:
+     - `lib/core/eureka/grade-grant-examine.cjs::runReviewerFanout(rubric, sourceCtx, opts)`
+       drives `lib/core/bono/cell-fanout.cjs::runCellFanout` in two batches (5 + 2
+       categories, never asking the shared fan-out cost cap to raise -- `FUTURES_FANOUT_CAP`
+       stays 5), dispatching `agents/grant-reviewer.md` per category cell (Read/Glob only --
+       LOCAL room/draft content, never external web, never Brain).
+     - The **hypothesis-confirm** gate (F.1) HALTS here: confirm or edit the what-if
+       ("this application, as currently held, would be accepted by a `<program>` review
+       committee") before the seven-category debate argues it. The navigator may scope it
+       (e.g. "only judge against what's filed in problem-definition + solution-design so
+       far").
+     - The seven category arguments debate sequentially via
+       `lib/core/bono/debate-composition.cjs::runDebate`, each self-critiqued under
+       `lib/core/bono/reviewer-governance.cjs`'s per-category discipline (cite-or-retract
+       for process/legal/reporting, reconciliation-required for budget,
+       disconfirming-first for market, mechanism-or-retract for ip, plus eligibility's
+       hard-gate flag). The debate has TEETH: each argument step reads the chain's
+       `previousOutput` (the PRIOR reviewers' arguments -- runDebate already threads it)
+       and may emit downgrade-only challenges `{criterion_id, to_status, reason}` against
+       an EARLIER reviewer's finding (e.g. budget challenges eligibility's `evidenced` on
+       `suitability_self_check` because the post-Tnufa funding plan has no numbers behind
+       it). Downward only, `evidenced -> asserted -> absent`, never upward: the panel is
+       at least as strict as its strictest reviewer.
+     - `lib/core/eureka/grade-grant-examine.cjs::consolidatePanel(cells, rubric,
+       {challenges})` merges the collected cell readings (a merge collision fails CLOSED:
+       the stricter status wins and is recorded) and applies the SUSTAINED challenges
+       BEFORE scoring, returning `{findings, disputes, dropped}` -- `scoreApplication`
+       runs completely unchanged on those findings (step 5 below is identical either
+       way), and EVERY challenge (sustained, rebutted-stands, ignored-upward) lands in
+       `disputes` so disagreement surfaces at the ruling gate instead of being silently
+       averaged away.
+     - The **ruling** gate (F.5) HALTS: `lib/core/eureka/grade-grant.cjs::deriveRulingVerb`
+       resolves the scored verdict into `supported | rejected | refined | undecided` --
+       ANY absent eligibility criterion overrides a strong aggregate score and forces
+       `rejected`, filed as a real `REJECTED_BECAUSE` graph record naming the failing
+       criterion (Canon Part 4: "why not" is graph data, never averaged away). Render the
+       `disputes` list ABOVE the percentage (a sustained downgrade is exactly what a real
+       committee argument produces; burying it under the score would be the false-success
+       failure class). On APPROVE, file via the existing step 9 spine with
+       `writeGradingResult(db, {verdict, sessionId, programName, extraProps: {mode:
+       'panel', dispute_count: <n>, sustained_count: <n>}})` -- scalar counts only, so a
+       panel-graded verdict stays distinguishable in the graph. This gate's APPROVE **is**
+       the file-verdict confirmation in panel mode (see `hitl_why` above) -- do not also
+       fire a separate step-9 file prompt in this mode.
+5. **Score.** Call `scoreApplication(rubric, findings)` from `grade-grant.cjs` with the findings
+   array you just built (via a small inline `node -e` invocation, or write the findings to a
+   temp JSON file and load it -- either is fine, the function is pure and source-agnostic:
+   room findings and draft findings score identically).
+6. **Show the scoring table.** Every criterion, its category, its status, and for any gap its
+   `common_mistake` line from the rubric -- so the navigator learns the rule, not just the
+   verdict (Part 12: pedagogy over grade).
+7. **Show the build roadmap.** Call `buildRoadmap(rubric, verdict)`. Render its
+   `section_plans` weakest-section-first: for each, "build this in `room/<section>/`" plus
+   each gap's `build` text (what a strong entry looks like, drawn from the criterion's
+   `details`) and its `common_mistake`. Then render `process_checklist` as a plain checklist
+   ("handle at submission time / post-award") -- these criteria have NO room location and must
+   never be forced into one. Name `covered_sections` in one line so progress is visible.
+   This is the "not just a grade, an offer" step: where and what to build so the room can
+   evolve into a fundable application.
+8. **Optional Brain coaching -- content AND structure.** Call `askBrainForCoaching(verdict)`
+   for per-gap-category coaching handles, and `askBrainForStrategy(verdict, rubric)` for the
+   STRUCTURAL handle bag (`section_profile`: covered / partial / missing per mapped section).
+   Both return `brain_available:false` by design (Part 8) -- if Brain is actually connected
+   this session, fire the generic handles (categories + section-coverage enums only, NEVER
+   room or draft prose) and ask for strategic advice on the SHAPE: which section to
+   strengthen first and why. If Brain is not connected, the roadmap's weakest-first ordering
+   plus each gap's `common_mistake` already carry the coaching.
+9. **File the verdict -- node AND graph.** Ask: "File this grading run to room/**/grades/?"
+   (Reviewer panel examination mode: skip this prompt -- the ruling gate's APPROVE in 4b
+   already confirmed filing; asking twice would be a redundant halt.) If approved, over one
+   db handle (`navigation.openRoomDbForCaller(roomDir)`, closed in a `finally`):
+   - `writeGradingResult(db, {verdict, sessionId, programName})` -- the typed `heuristic`
+     claim node, `review_status: 'proposed'` (a human APPROVE, not this command, promotes it).
+   - `navigation.writeGrantRubricGraph(db, rubric)` -- the rubric map as graph
+     (`grant_criterion` anchors + `MAPS_TO_SECTION` edges; idempotent, safe to re-run).
+   - `navigation.writeGradingSectionEdges(db, {verdict_node_id, verdict, rubric})` -- the
+     per-run verdict->Section coverage-profile edges (scalar counts only).
+   Also write the human-readable table + roadmap to a room artifact per `produces:` above.
+
+## Decompose an application into a room
+
+The INVERSE direction: the navigator hands over a finished/existing application (pasted text or
+a file) and wants it examined AS a room.
+
+**Room-targeting decision (made deliberately, recorded here):** decomposition targets a NEW
+dedicated room -- slug `tnufa-app-<slug>` (swap the program id) -- NEVER the navigator's active
+venture room. Filing application-sourced prose into a live venture room would pollute real
+venture data the navigator may not want merged; a dedicated room is cheap, reversible
+(archive it), and mirrors how `/mos:rooms new` + ignite already birth rooms. Merging any of it
+into the venture room afterward is a manual, navigator-driven step, deliberately not automated.
+
+Flow:
+
+1. **Approve the birth.** Tell the navigator a new dedicated room `tnufa-app-<slug>` will be
+   created and ask for approval (this is `birthRoom`'s own B2-style gate; a decline means no
+   folder, and the decline is recorded as data by the birth machinery).
+2. **Birth the room through the real keystone.** Call `navigation.birthRoom({slug, roomDir,
+   sessionId, ventureText: <one-line application summary>, approvedBy: <navigator>, vname,
+   vstage: 'Pre-Opportunity'})` with `roomDir` under `~/MindrianRooms/`. NEVER hand-roll the
+   directory: birthRoom owns the full ICM Layer 0 scaffold (ROOM.md identity files per
+   directory, STATE.md, sentinel, registry flip, Section nodes in room.db). If it returns
+   `{ok:false}`, say so and stop -- never claim a room exists that was not born.
+3. **File by the map.** Load the rubric and call `sectionMap(rubric)`. For each mapped section,
+   read the application and file its relevant content into `room/<section>/` following the
+   room's own entry conventions (one folder per artifact, `section/name/name.md`). Quote the
+   application faithfully -- decomposition RELOCATES content, it does not rewrite it.
+   Application content matching `process` (room_section null) criteria has no section home:
+   summarize it into the grading artifact later, do not invent a section for it.
+4. **Grade the result.** Re-enter the Session Flow above in room-mode against the new room.
+   The gaps that surface are exactly what the application itself failed to cover -- that
+   contrast (what the application asserts vs what a room demands as evidence) is the point.
+
+## When Complete
+
+Summarize the score, the top 2-3 gaps by common-mistake severity, the weakest room section by
+roadmap order, and one clear next step ("build the matching-funds proof entry in
+room/financial-model/ before resubmitting" beats a generic "revise and resubmit"). If the
+application scores well, say so plainly and briefly -- Part 12: withhold compliments beyond
+what's earned, the insight should land, not the praise.