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

package/references/meeting/cross-relationship-patterns.md

@@ -0,0 +1,202 @@
+---
+title: Cross-Relationship Detection Patterns
+description: >
+  Defines the 5 edge types (INFORMS, CONTRADICTS, CONVERGES, INVALIDATES, ENABLES)
+  that the file-meeting command's Step 6 batch scan uses to discover cross-subsystem
+  impacts in the Data Room. Tier 0 detection heuristics require no ML -- Larry's
+  reasoning plus keyword matching.
+tier: 0
+used_by:
+  - commands/file-meeting.md (Step 6: batch cross-relationship scan)
+  - scripts/analyze-room (convergence + contradiction detection)
+  - skills/room-passive/SKILL.md (cascade awareness)
+---
+
+# Cross-Relationship Detection Patterns
+
+After all meeting segments are filed, Larry performs a **batch cross-relationship scan** to discover how new artifacts connect to existing room content. This reference defines the 5 edge types, their detection heuristics, and when to surface findings.
+
+## Why Cross-Relationships Matter
+
+Ventures are wicked problems (Rittel & Webber 1973). Changes in one subsystem cascade through others (Simon 1962). The Data Room is NOT a flat document store -- it is a nested system where insights in one section may inform, contradict, or invalidate claims in another. The cross-relationship scan finds what humans miss.
+
+---
+
+## Edge Types
+
+### INFORMS (Impact: MEDIUM)
+
+**Definition:** A new artifact provides evidence, context, or supporting data for content in another room section. The information flows one direction -- source informs target without conflicting.
+
+**Wicked problem connection:** Addresses characteristic #3 ("Solutions are not true-or-false, but good-or-bad") -- new evidence shifts the quality of existing analysis.
+
+**Tier 0 detection heuristics:**
+- Shared keywords between new artifact content and existing section entries (noun phrases, proper nouns, technical terms)
+- Explicit section references in text: "this affects our financials," "relevant to our market analysis," "connects to the IP question"
+- Speaker mentions another domain by name: "from a legal perspective," "on the competitive side"
+- New artifact contains data (numbers, percentages, dates) relevant to an existing section's claims
+
+**Examples:**
+1. A researcher's insight about material costs INFORMS the financial-model section's cost projections
+2. A mentor's feedback about go-to-market strategy INFORMS the market-analysis section's channel assumptions
+3. An advisor's note about regulatory changes INFORMS the legal-ip section's compliance analysis
+
+**Surface when:** Direct relevance to a section the user has content in. Skip when the connection is trivially obvious (same section) or when the target section is empty (no existing content to inform).
+
+**Output format:** `INFORMS: {source_artifact} -> {target_section}. {brief explanation}. Impact: MEDIUM.`
+
+---
+
+### CONTRADICTS (Impact: HIGH)
+
+**Definition:** A new artifact conflicts with an existing claim, assumption, or conclusion in the Data Room. The two pieces of information cannot both be true simultaneously, or they present incompatible perspectives on the same topic.
+
+**Wicked problem connection:** Addresses characteristic #9 ("The planner has no right to be wrong") -- contradictions signal that a previous decision may need revisiting. Also addresses #2 ("No stopping rule") -- contradictions re-open what seemed settled.
+
+**Tier 0 detection heuristics:**
+- Opposite sentiment about the same topic: one artifact says "market is growing" while another says "market is shrinking"
+- Numerical disagreements: different TAM figures, conflicting timelines, mismatched cost estimates
+- Contradiction signals in speech: "actually," "contrary to what we assumed," "I disagree," "that's not what we're seeing," "the data shows otherwise"
+- Assumption with `status: validated` in frontmatter that new data challenges
+- Speaker role conflict: investor says one thing, researcher data shows another
+
+**Examples:**
+1. Investor says "TAM is $50M" but market-analysis has an entry claiming "TAM is $190M"
+2. New competitive intelligence shows a direct competitor, but competitive-analysis states "no direct competitors"
+3. Mentor advises pivoting to B2C but business-model is built entirely around B2B enterprise sales
+
+**Surface: ALWAYS.** Contradictions are the most valuable signal in wicked problem management. They reveal where the venture's understanding is inconsistent. Never suppress a contradiction.
+
+**Output format:** `CONTRADICTS: {source_artifact} -> {target_section}/{target_artifact}. {what conflicts}. Impact: HIGH.`
+
+---
+
+### CONVERGES (Impact: HIGH)
+
+**Definition:** A theme, concept, or concern from the current meeting appears in 3 or more room sections. This cross-cutting pattern signals a topic that is central to the venture and deserves focused attention.
+
+**Wicked problem connection:** Addresses characteristic #7 ("Every wicked problem is essentially unique") -- convergence patterns reveal the unique structure of THIS venture's problem space. Also addresses #5 ("Every solution is a 'one-shot operation'") -- convergent themes are the highest-leverage points for intervention.
+
+**Tier 0 detection heuristics:**
+- Key noun phrases from new artifacts appear in 3+ existing section entries (proper nouns, technical terms, framework names)
+- Proper nouns mentioned across sections: competitor names, technologies, market segments, regulations
+- Themes surfaced by multiple speakers in the meeting that also appear in existing room content
+- A single concept (e.g., "sustainability," "compliance," "scalability") referenced across problem-definition, solution-design, and business-model
+
+**Examples:**
+1. "Sustainability" mentioned by mentor in problem-definition, by researcher in solution-design, and now by investor in business-model -- convergent theme
+2. A specific competitor's name appears in competitive-analysis, market-analysis, solution-design, and now in a meeting discussion -- this competitor is a cross-cutting concern
+3. "Regulatory risk" surfaces in legal-ip, financial-model, market-analysis, and the current meeting -- systemic theme requiring a unified response
+
+**Surface: ALWAYS.** Convergence signals that a theme deserves its own strategic attention. It may warrant a dedicated session or cross-section synthesis.
+
+**Output format:** `CONVERGES: "{theme}" appears in {count} sections ({section_list}). Consider a focused analysis on this cross-cutting theme. Impact: HIGH.`
+
+---
+
+### INVALIDATES (Impact: HIGH)
+
+**Definition:** A new artifact makes an existing assumption stale, outdated, or factually incorrect. The assumption's `status` should change from `validated` or `unvalidated` to `invalidated`.
+
+**Wicked problem connection:** Addresses #1 underserved outcome: "Minimize time to detect invalid assumptions" (Opportunity Score: 18). Also addresses characteristic #8 ("Every wicked problem can be considered a symptom of another") -- an invalidated assumption may reveal a deeper problem.
+
+**Tier 0 detection heuristics:**
+- Scan existing artifacts' `assumptions:` frontmatter fields. Compare new information against `claim:` values
+- Temporal conflicts: "That was true in Q1 but..." / "Since we last discussed..." / "The landscape has changed"
+- Numerical/factual conflicts between new data and existing assumption claims
+- Speaker explicitly references a previous assumption: "I know we assumed X, but..."
+- Market or competitive changes that alter the basis of existing claims
+
+**Examples:**
+1. New competitive intelligence invalidates the assumption "No competitors in ionic liquids space" -- a funded startup just launched
+2. Updated market research shows the regulatory environment changed, invalidating the assumption "FDA approval not required for our device class"
+3. A team member reports that the key technical partner withdrew, invalidating the assumption "Partnership with X secures our supply chain"
+
+**Surface: ALWAYS.** Stale assumptions are the #1 underserved outcome in venture intelligence. An invalidated assumption may cascade through multiple sections. Flag immediately and trace the cascade.
+
+**Output format:** `INVALIDATES: {source_artifact} invalidates assumption "{claim}" in {target_section}/{target_artifact}. {why it's stale}. Impact: HIGH.`
+
+---
+
+### ENABLES (Impact: MEDIUM)
+
+**Definition:** A new artifact unblocks progress in another section. A decision was made, information was provided, or an action was completed that resolves an open question or dependency in another part of the Data Room.
+
+**Wicked problem connection:** Addresses characteristic #4 ("There is no immediate and no ultimate test of a solution") -- enablement signals that the venture can now test a hypothesis that was previously blocked. Also addresses #6 ("Wicked problems do not have an enumerable set of potential solutions") -- each enablement opens new solution paths.
+
+**Tier 0 detection heuristics:**
+- Action items completed that other sections referenced as blockers
+- Decisions that resolve open questions: "We've decided to go B2B" enables financial-model projections that were waiting on market definition
+- "Now we can..." / "This means we can..." / "This unblocks..." / "The missing piece was..." signals
+- Resource acquisition (funding, hire, partnership) that other sections depend on
+- Regulatory/legal clearance that other sections were waiting for
+
+**Examples:**
+1. Decision to go B2B enables financial-model projections that were blocked by undefined target market
+2. Securing a Letter of Intent from a pilot customer enables the business-model section's revenue projections
+3. Hiring a CTO enables the solution-design section's technical architecture work that was on hold
+
+**Surface when:** The previously blocked section exists and has content waiting. Skip when the target section is empty (nothing to unblock) or when the enablement is trivially local (same section).
+
+**Output format:** `ENABLES: {source_artifact} -> {target_section}. {what is now unblocked}. Impact: MEDIUM.`
+
+---
+
+## Batch Scan Protocol
+
+After all meeting segments have been filed (Step 5 of file-meeting completes), Larry performs the batch cross-relationship scan:
+
+1. **Collect filed artifacts:** Gather all artifacts just filed from this meeting session
+2. **Load room context:** For each non-empty room section, read the existing entries (titles, headers, frontmatter including assumptions)
+3. **Compare each new artifact:** Against existing room content using Tier 0 heuristics above
+4. **Identify significant relationships:** Apply the impact and surfacing rules for each edge type
+5. **Present findings:** Show only significant discoveries -- do not overwhelm with trivial INFORMS connections
+6. **Prioritize:** CONTRADICTS and INVALIDATES first (highest user value), then CONVERGES, then ENABLES and INFORMS
+
+**Presentation order:**
+```
+HIGH impact first:
+  1. INVALIDATES (stale assumptions -- most urgent)
+  2. CONTRADICTS (conflicting claims -- action required)
+  3. CONVERGES (cross-cutting themes -- strategic awareness)
+
+MEDIUM impact second:
+  4. ENABLES (unblocked progress -- opportunity)
+  5. INFORMS (supporting evidence -- enrichment)
+```
+
+**User interaction after scan:**
+- For each HIGH finding, ask: "Want to explore this?" (opens the relevant section)
+- For MEDIUM findings, present as a summary list
+- If no significant relationships found: "No cross-subsystem impacts detected from this meeting."
+
+---
+
+## Tier Progression
+
+| Tier | Phase | Method | Capability |
+|------|-------|--------|------------|
+| **Tier 0** | Phase 6 | Larry's reasoning + keyword matching | Detects obvious relationships via shared terms, explicit references, and speech signals. No dependencies required. |
+| **Tier 1** | Phase 8 | LSA + MiniLM embeddings | Semantic similarity discovers non-obvious connections. "Cash burn rate" and "runway" recognized as related even without keyword overlap. |
+| **Tier 2** | Phase 9 | Full HSI with Brain graph | Quantitative Hybrid Similarity Index. Pinecone embeddings + Neo4j relationship traversal. Reverse Salient discovery finds hidden cross-meeting connections. |
+
+**Graceful degradation:** Tier 0 always works. Higher tiers enhance accuracy but are never required. A Data Room with only Tier 0 still catches the most impactful relationships.
+
+---
+
+## Output Format Reference
+
+Each discovered relationship is presented as a single line:
+
+```
+{EDGE_TYPE}: {source} -> {target}. {explanation}. Impact: {HIGH|MEDIUM}.
+```
+
+**Batch summary example:**
+```
+INVALIDATES: meeting-segment-03.md invalidates assumption "No direct competitors" in competitive-analysis/landscape.md. New entrant Acme Corp launched Q4. Impact: HIGH.
+CONTRADICTS: meeting-segment-01.md -> financial-model/projections.md. Investor estimates $50M TAM vs. existing $190M claim. Impact: HIGH.
+CONVERGES: "regulatory compliance" appears in 4 sections (legal-ip, market-analysis, solution-design, financial-model). Consider a focused regulatory strategy session. Impact: HIGH.
+ENABLES: meeting-segment-05.md -> business-model/revenue.md. B2B decision unblocks pricing model. Impact: MEDIUM.
+INFORMS: meeting-segment-02.md -> solution-design/architecture.md. CTO feedback on tech stack choice. Impact: MEDIUM.
+```

package/references/meeting/extraction-perspectives.md

@@ -0,0 +1,225 @@
+<!--
+  Phase 265 Plan 19 -- the extraction-perspectives reference: the five
+  whole-transcript lens definitions dispatched by commands/file-meeting.md's
+  Step 3a (DISPATCH) as PARALLEL subagents, one per perspective, before Step 3b
+  (CONSOLIDATION, orchestrator-only) reconciles their output into one claim set
+  and hands it, unchanged in kind, to the existing F.8 nugget routing gate.
+
+  This file does not invent a new vocabulary. Every perspective is mapped onto
+  the two ALREADY-FROZEN taxonomies this repo ships:
+    - the 6-type SEGMENT taxonomy in segment-classification.md
+      (decision / action-item / insight / advice / question / noise)
+    - the 6-enum knowledge_type taxonomy in knowledge-typing.md
+      (fact / causal / heuristic / anomaly_cue / mental_model / assumption),
+      frozen in lib/core/navigation/typed-claim.cjs's KNOWLEDGE_TYPES Set.
+
+  Each perspective reads the WHOLE transcript. None of them decides a target
+  section (that is section-mapping.md's job, an orchestrator-side concern the
+  workers never see) and none of them writes anything (writeClaimNode is called
+  exactly once per consolidated claim, from the single main-thread db handle, in
+  Step 3b sub-step 5).
+
+  NO em-dashes anywhere in this file (CLAUDE.md HARD RULE). Hyphens only.
+-->
+
+# Extraction Perspectives -- the Five Whole-Transcript Lenses
+
+Purpose: recall. One unified pass over a long meeting misses what only one lens
+would have noticed. This file defines FIVE perspectives that each read the
+FULL transcript independently, looking for a different slice of the same two
+frozen taxonomies, so the union of what they find is closer to complete than
+any single pass could be.
+
+Each perspective definition below follows the same structure so
+`commands/file-meeting.md`'s dispatch can render all five uniformly: name and
+purpose, primary segment types, primary knowledge types, what it must NOT do,
+and the uniform return schema (byte-identical across all five, given at the
+end of this file rather than repeated five times, with only `perspective` set
+to the lens name that produced each row).
+
+---
+
+## 1. Decisions and Commitments
+
+**Purpose:** Find what was decided, who owns what, what was committed to, and
+what was explicitly deferred or rejected.
+
+**Primary segment types:** `decision`, `action-item`.
+
+**Primary knowledge types:** `fact`, `assumption`.
+
+**What this lens must NOT do:**
+- It does not decide the target room section for anything it finds -- that
+  routing decision belongs to `section-mapping.md`, applied downstream of
+  consolidation, never inside this lens.
+- It does not write anything. It returns structured data only.
+- It does not judge whether another lens already found the same segment.
+  Two lenses seeing the same segment is the expected case, not a bug this
+  lens should try to avoid; consolidation (Step 3b sub-step 1) owns dedup.
+
+---
+
+## 2. Technical Claims and Causal Mechanisms
+
+**Purpose:** Find assertions about how something works, cause-and-effect
+statements, and numbers. This lens carries the strongest obligation to run the
+conditions/counter_conditions contrastive probe from `knowledge-typing.md`
+("when does this hold, when does this break"), because a causal claim without
+its breaking conditions is the weakest kind of claim in the graph.
+
+**Primary segment types:** `insight`.
+
+**Primary knowledge types:** `fact`, `causal`.
+
+**What this lens must NOT do:**
+- It does not decide the target room section.
+- It does not write anything. It returns structured data only.
+- It does not judge whether another lens already found the same segment.
+
+---
+
+## 3. Open Questions and Unknowns
+
+**Purpose:** Find what nobody in the room could answer, what was asked and not
+resolved, and what was assumed without evidence.
+
+**Primary segment types:** `question`.
+
+**Primary knowledge types:** `assumption`, `anomaly_cue`.
+
+**What this lens must NOT do:**
+- It does not decide the target room section.
+- It does not write anything. It returns structured data only.
+- It does not judge whether another lens already found the same segment.
+
+---
+
+## 4. Risks, Blockers and Anomaly Cues
+
+**Purpose:** Find the thing that surprised someone, the thing that did not fit,
+the dependency nobody owns. This lens is EXPLICITLY instructed to inspect
+segments the other four would classify as `noise`: `references/taxonomy/TAXONOMY.md`
+records the Fragment concept -- meeting "noise" segments that still carry
+micro-knowledge, saved instead of discarded -- and this is the lens most
+likely to find one.
+
+**Primary segment types:** any segment type, including `noise`.
+
+**Primary knowledge types:** `anomaly_cue`, `assumption`.
+
+**What this lens must NOT do:**
+- It does not decide the target room section.
+- It does not write anything. It returns structured data only.
+- It does not judge whether another lens already found the same segment.
+- It does not discard a `noise`-flagged segment on its own authority just
+  because the other four lenses would skip it; if it carries a claim, the
+  claim is returned like any other.
+
+---
+
+## 5. Stakeholder Dynamics and Working Models
+
+**Purpose:** Find how people in the room think about the problem, whose
+judgment is being deferred to, rules of thumb offered, and the abstract models
+a later `INSTANTIATES` edge (minted at consolidation, Step 3b sub-step 3) would
+attach a concrete claim to.
+
+**Primary segment types:** `advice`.
+
+**Primary knowledge types:** `heuristic`, `mental_model`.
+
+**What this lens must NOT do:**
+- It does not decide the target room section.
+- It does not write anything. It returns structured data only.
+- It does not judge whether another lens already found the same segment.
+- It does not itself mint the `INSTANTIATES` edge to a concrete example --
+  that is cross-claim edge work, and cross-claim edges require seeing the
+  FULL consolidated claim set, which only the orchestrator ever holds.
+
+---
+
+## The Uniform Return Schema
+
+Every perspective returns an array of objects in this EXACT shape. The field
+names and order are byte-identical across all five perspectives so
+consolidation (Step 3b) can merge the five arrays without a per-perspective
+adapter:
+
+```
+{
+  segment_id,          // stable id for the segment this claim came from
+  speaker_id,          // the Step 2 roster speaker id
+  segment_type,        // one of the frozen 6: decision | action-item | insight
+                        // | advice | question | noise
+  priority,            // HIGHEST | HIGH | MEDIUM | LOW (segment-classification.md)
+  claim_text,          // the atomic claim text (stays LOCAL, never to Brain)
+  knowledge_type,      // one of the frozen 6: fact | causal | heuristic |
+                        // anomaly_cue | mental_model | assumption
+  conditions,          // "when does this hold?" ('' if none stated)
+  counter_conditions,  // "when does this break?" ('' if none stated)
+  valid_from,          // ISO date or '' (TV-01)
+  valid_until,         // ISO date or '' (TV-01)
+  disambiguation,      // 'ambiguous' ONLY for an unresolved referent, else omitted
+  confidence,          // scalar in [0, 1]
+  reasoning_line,       // Larry's one-line classification reasoning for this claim
+  perspective,         // the lens name that produced this row (one of the five
+                        // headings above)
+}
+```
+
+A perspective that finds nothing returns an empty array. It never invents a
+claim to fill the gap, and it never writes `writeClaimNode`, `writeEdge`, or
+any artifact -- extraction is judgment over the transcript, filing is the
+orchestrator's job downstream of the F.8 gate.
+
+---
+
+## Why five and not four or eight
+
+The five perspectives above are a judgment call anchored on the two frozen
+enums, not a measured optimum. Three properties make five the right number
+here:
+
+1. **Near-complete coverage of both enums.** Between the five lenses, every
+   member of the 6-value `knowledge_type` enum (`fact`, `causal`, `heuristic`,
+   `anomaly_cue`, `mental_model`, `assumption`) and every member of the 6-value
+   segment taxonomy (`decision`, `action-item`, `insight`, `advice`,
+   `question`, `noise`) appears as a primary anchor for at least one lens.
+2. **Each has a distinct failure mode when a single unified pass runs
+   instead.** A decisions-focused pass under-reports anomaly cues (lens 4's
+   territory); a facts-focused pass under-reports the mental models a later
+   `INSTANTIATES` edge needs (lens 5's territory); a single pass biased toward
+   whichever type it classifies first will systematically under-serve the
+   others. Five separate lenses, each with ONE dominant purpose, do not
+   compete against each other for the same attention budget.
+3. **Five sits inside the existing `FUTURES_FANOUT_CAP` default of 5**
+   (`lib/core/futures/orchestrator.cjs`), so no batching idiom is required to
+   dispatch all five perspectives in a single fan-out.
+
+No claim is made that five is the measured-optimal number of lenses for
+recall; it is the number that maps cleanly onto the two taxonomies this repo
+already freezes, at a fan-out size the existing cost governor already
+supports without a new cap.
+
+---
+
+## The cost, stated plainly
+
+Five whole-transcript passes cost roughly FIVE TIMES the transcript tokens,
+plus five reference payloads (each worker's own perspective definition plus
+`segment-classification.md` plus `knowledge-typing.md`). This is bought for
+RECALL, not for wall-clock speed or token savings, and the navigator has
+explicitly valued that trade.
+
+The measured figures behind this, per the deep-dive research: a one-hour
+meeting runs about 9,000 words (roughly 13k tokens at typical conversational
+density); the largest transcript in this repo is 19,208 words (roughly 26k
+tokens). `commands/file-meeting.md`'s own Transcript size probe, wired by plan
+265-10, is where a navigator is told the run is large -- at 12,000 words or
+more -- before extraction starts, so the cost of a long meeting is a stated,
+reasoned choice rather than a silent quality loss.
+
+This reference file and `commands/file-meeting.md`'s dispatch section both
+record this cost honestly. Total tokens go UP by roughly the number of
+perspectives (five), and that is the accepted price for not missing a claim
+that only one lens would have noticed.

package/references/meeting/filing-protocol.md

@@ -0,0 +1,222 @@
+# Meeting Filing Protocol (surface-neutral extract)
+
+## Provenance (read this before anything else)
+
+This file is an EXTRACT, not the canonical source. `commands/file-meeting.md`
+Step 3 is the canonical CLI implementation of this protocol - it was built and
+verified by Phase 150.8 ("Meeting Micro-Knowledge DIKW Filing v1", 2026-06-12,
+`.planning/phases/150.8-meeting-micro-knowledge-dikw-filing-v1-any-transcript-files-/150.8-VERIFICATION.md`,
+11/11 must-have truths PASSED), and it was later restructured by Phase 265 into
+the current Step 3a (Dispatch) / Step 3b (Consolidation) split.
+
+`tests/test-kwl-meeting-mcp-honesty.cjs` is the drift guard. It machine-checks
+that the shared taxonomies (the four Claimify pass names, the six
+`knowledge_type` enum members, the six segment types) appear in BOTH this file
+and `commands/file-meeting.md`. An edit to the taxonomy in one file that does
+not land in the other turns that test red - drift is a red test here, not a
+memory problem for a future author to catch by hand.
+
+This file exists because of a real defect, recorded at
+`.planning/debug/meeting-file-meeting-false-success.md`: the MCP `meeting`
+tool's `file-meeting` branch has always tried to read this path via
+`safeReadFile`, and it did not exist on disk. The branch silently dropped the
+section when the read missed, so a calling model got a completion-shaped
+response with no usable protocol behind it. This file closes that half of the
+defect. It does NOT close the other half the RCA names: the MCP surface still
+does not call `navigation.writeClaimNode` itself. See "The honest surface gap"
+below.
+
+## What this protocol is for, and who reads it
+
+The CLI slash command `/mos:file-meeting` reads its own inline copy of this
+protocol directly out of `commands/file-meeting.md` - that copy is the
+canonical, twice-verified implementation and it is not touched by this file.
+
+This file is what the MCP `meeting` tool hands back to a calling model on
+Claude Desktop and Cowork, the two surfaces that reach meeting filing only
+through the MCP `meeting` tool and never through the CLI slash command.
+
+## The honest surface gap, stated up front
+
+An MCP caller cannot execute the full CLI pipeline. Naming why, plainly,
+rather than leaving a model to discover it by trial and error - and naming
+each gap's own status now that plans 276-12 and 276-14 have closed two of
+the three named here:
+
+- **Gap 1, the five-perspective subagent fan-out (Step 3a Dispatch).
+  STILL OPEN, structurally unreachable from MCP.** The CLI dispatches five
+  subagents in one message via the Agent tool with `subagent_type:
+  meeting-perspective-extractor`. An MCP tool call has no Agent tool and no
+  subagent registry to dispatch into on this surface. This is not fixable
+  from MCP, only declarable: use `/mos:file-meeting` on the CLI for the
+  real five-perspective dispatch.
+- **Gap 2, the F.8 filing gate. CLOSED by plan 276-14.** The `meeting`
+  tool's `file-meeting` command, called with `knowledge_type` and
+  `claim_text`, writes the claim at `review_status: 'proposed'` through the
+  same `writeClaimNode` primitive `claim_write` uses, then renders a
+  confirmation card by composing `gate-render.cjs`'s `renderGate` and the
+  shared `gate-ledger.cjs` mint - never a second gate mechanism. A claim
+  reaches `confirmed` ONLY through a separate `gate_answer` call's approve
+  branch and `navigation.confirmNode` (which ratifies a typed decision node
+  sourced from the claim); the `file-meeting` call itself never asserts
+  confirmation, and omitting `knowledge_type`/`claim_text` still returns
+  the original reference-only response, unchanged.
+- **Gap 3, a direct claim write. CLOSED by plan 276-12.** The `claim_write`
+  MCP tool writes one typed DIKW claim through `writeClaimNode`, which
+  routes through `lib/core/node-insert.cjs`, the single node-write
+  chokepoint every writer in this repo shares. An invalid `knowledge_type`
+  is refused at the schema boundary and again by `writeClaimNode` itself,
+  never silently coerced to a nearby value.
+
+What an MCP caller CAN do today: walk the Four Claimify Passes below
+itself, in one context, over the transcript it already holds; persist each
+claim it confirms through `artifact_file` (the general-purpose write path),
+or, on `file-meeting` specifically, through the `knowledge_type`/
+`claim_text` pair that writes the claim AND renders the F.8 confirmation
+gate in one call. This is an honest, reduced form of the CLI protocol, not
+an equivalent one: Gap 1, the five-perspective fan-out, still has no MCP
+path at all. When the user is on the CLI, point them at `/mos:file-meeting`
+for the fuller path: five-perspective dispatch, the F.8 gate, and the
+direct `writeClaimNode` call, all in one governed flow.
+
+## Inputs this protocol assumes
+
+- **The confirmed speaker roster**, with roles drawn from the twelve-member
+  role taxonomy: mentor, researcher, team-member, investor, advisor, customer,
+  founder, partner, domain-expert, government, competitor, unknown.
+- **The transcript itself.** See
+  `references/meeting/transcript-patterns.md` for speaker-label detection
+  heuristics when the roster is not already confirmed.
+
+## The Four Claimify Passes
+
+Faithful to `commands/file-meeting.md` Step 3 (the Four Claimify Passes
+section, lines 439-527 at the time this extract was written).
+
+### Pass 1: Selection
+
+Classify each segment using the six-member SEGMENT taxonomy from
+`references/meeting/segment-classification.md`:
+
+- `decision` (HIGHEST priority) - explicit choices made, direction set.
+- `action-item` (HIGH priority) - tasks assigned, deadlines mentioned.
+- `insight` (MEDIUM priority) - new information, discoveries, data points.
+- `advice` (MEDIUM priority) - recommendations, suggestions, should/could.
+- `question` (LOW priority) - open questions, uncertainties raised.
+- `noise` (SKIP) - greetings, small talk, logistics, off-topic.
+
+Apply role-aware priority heuristics (an investor question about financials is
+HIGH priority; a mentor's advice on problem framing is HIGH priority; a
+team-member status update is MEDIUM priority), then sort by priority:
+decisions highest, then action-items, then insights and advice, then
+questions lowest. Flag potential noise that carries proper nouns, competitor
+names, or numbers rather than discarding it outright - it still returns as a
+row for the orchestrator's basket, never silently dropped. Filler and pure
+social talk is tagged `no_claim` and discarded; it mints no claim row. The
+selection pass IS the priority sort - it decides which segments carry
+candidate knowledge.
+
+### Pass 2: Disambiguation
+
+For each selected segment, resolve pronouns and referents before decomposing:
+
+1. Use the speaker identity from the confirmed roster and the prior two to
+   three turns of context to bind every pronoun ("it", "they", "this") and
+   every bare referent ("the deal", "that number") to a concrete antecedent.
+2. An unresolvable referent is NEVER dropped. When a referent cannot be
+   resolved from the speaker plus the prior two to three turns, the resulting
+   atomic claim is still returned, marked `disambiguation: 'ambiguous'`, and
+   queued for human review.
+
+### Pass 3: Decomposition
+
+Split each compound segment into ATOMIC claims:
+
+1. A segment that asserts two things becomes two atomic claims (for example,
+   "revenue was $1.2M and churn dropped" becomes a `fact` claim about revenue
+   and a separate claim about churn).
+2. A decision-plus-action segment becomes the decision claim plus the action
+   sub-element.
+3. Each atomic claim must carry exactly ONE dominant `knowledge_type` after
+   typing. If a claim still reads as two types, it was not fully decomposed -
+   split it again.
+
+### Pass 4: Typing
+
+Classify each atomic claim against the six-member `knowledge_type` enum from
+`references/meeting/knowledge-typing.md`:
+
+- `fact` - a stated state of the world that is true or false.
+- `anomaly_cue` - a noticed surprise, an outlier, a "that is weird" signal.
+- `causal` - an X-causes-Y mechanism claim.
+- `heuristic` - a rule of thumb, an if-then operating rule.
+- `mental_model` - a belief about how a system or market works.
+- `assumption` - a claim taken as true without evidence yet.
+
+Run the `conditions` / `counter_conditions` contrastive probe ("when does this
+hold?" / "when does this break?"), extract `valid_from` / `valid_until` when
+the claim is time-bound, then return the row in the uniform schema: segment
+id, speaker id, segment type, priority, claim text, knowledge type,
+conditions, counter conditions, valid from, valid until, disambiguation,
+confidence, and a reasoning line naming the classification.
+
+## Consolidation rules that survive the surface change
+
+From the CLI's Step 3b Consolidation, only the rules an MCP caller can
+actually apply inside a single context, since Step 3b's own five-perspective
+merge machinery is a CLI-only shape:
+
+- **Merge and deduplicate on `segment_id`.** The same segment surfacing twice
+  (once through one lens, once through another) is expected on the CLI's
+  multi-perspective fan-out; an MCP caller walking one pass over the
+  transcript will naturally avoid re-emitting the same segment, but if it
+  does, merge on `segment_id` rather than filing duplicates.
+- **Never silently pick a winner on `knowledge_type` disagreement.** If a
+  claim could plausibly carry two different types, do not average and do not
+  guess - either split the claim (Pass 3's own remedy) or record the losing
+  type in `disambiguation` and surface the disagreement in the reasoning line.
+- **Detect intra-meeting contradictions** across the full claim set the pass
+  produced, rendered claim-A-versus-claim-B with speakers attributed, per
+  `references/meeting/summary-template.md`'s "Contradictions Detected" shape.
+- **Render a reasoning line for every classified claim.** Transparency is
+  mandatory even when it makes the flow longer - the user needs to trust the
+  classification, not just receive it.
+- **The cross-claim edge minting the CLI performs (`REFINES`, `ROOT_CAUSES`,
+  `INSTANTIATES` via `navigation.writeEdge`) and the five-perspective merge
+  step are CLI-only machinery an MCP caller does not have a write path for
+  today.** Say so rather than silently dropping the capability: an MCP caller
+  files the claim through `artifact_file` without minting these edges.
+
+## The rules that never bend, on any surface
+
+- **Nothing files without the navigator confirming.** Every claim is born
+  `review_status: 'proposed'` at the writer - never auto-confirmed. Only a
+  human confirms a truth-claim node (Canon Part 9, role 5).
+- **Agent attribution is forbidden.** A literal `larry`, `brain`, `system`, or
+  `assistant` identity as the claim's source is rejected with
+  `agent_attribution_forbidden`.
+- **Canon Part 8: claim prose stays LOCAL.** Claim text lives only in room.db
+  and the filed artifact. Only the `knowledge_type` enum handle may ride to
+  the Brain downstream - never the transcript text, never the claim body. This
+  rule is load-bearing precisely because a model walking this protocol on the
+  MCP surface is one careless `brain_*` call away from a constitutional breach;
+  there is no F.8 gate here to catch it first the way the CLI's
+  Step 4 does. Plan 276-14 narrows, but does not eliminate, this risk: the
+  F.8 gate that was missing from this surface now exists for the claim
+  CONFIRMATION step (Gap 2 above), so that one step of the flow is no
+  longer entirely ungoverned. It is not a Brain-call guard - `gate_render`/
+  `gate_answer` ratify a claim, they do not intercept a stray `brain_*`
+  call anywhere else in the protocol, so a model can still make one at any
+  other point while walking it. `tests/test-276-meeting-gate-wiring.cjs`
+  assertion group G pins the `meeting` tool's own branches (the wiring
+  itself, not the model's own tool-use decisions) as Brain-call free, which
+  is the guard this plan actually adds.
+
+## Where to go next
+
+- `references/meeting/section-mapping.md` - routing a classified claim to a
+  target room section.
+- `references/meeting/artifact-template.md` - the artifact frontmatter shape
+  `artifact_file` expects.
+- `references/meeting/summary-template.md` - the summary and
+  contradictions-detected shape referenced above.