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

package/commands/file-meeting.md

@@ -0,0 +1,1195 @@
+---
+name: file-meeting
+description: File a meeting transcript into the Data Room
+help_jtbd: "Turn a meeting recording into structured room intelligence."
+body_shape: E
+hitl_shape: "F.8"
+hitl_why: "Extracted nuggets are routed as an independent set the navigator files in any order."
+argument-hint: "[--latest|--paste|<file>]"
+serves_jtbd: ["file-meeting"]
+teaching: "When a meeting just happened, /mos:file-meeting captures the transcript and routes the intelligence into the right room sections. Meetings are where institutional knowledge actually lives."
+# Per docs/reward-before-investment-rule.md line 60-62: surface first-paragraph extraction preview before full transcript ask. Remediation tracked as follow-up phase.
+interactive_first_reward: paragraph_preview
+# Phase 265 Plan 19 (pre-approval): Step 3a dispatches 5 meeting-perspective-extractor
+# subagents in one turn. Task is a pre-approval list entry, not a new capability --
+# Claude Code already lets any turn spawn subagents through the normal permission
+# flow; this removes the per-spawn prompt for this dispatch shape. Tracked pending
+# in data/subagent-dispatch-grants.json (row: commands/file-meeting.md); ratification
+# to status:"granted" is plan 265-23's job, not this plan's.
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Glob
+  - AskUserQuestion
+  - Task
+# --- Phase 165 connector (close the file-meeting orphan; D-165-07) ---
+# The meeting-filing event dispatches the blind-spot trigger sensors. Rides the
+# EXISTING 'contradiction' reach (a filed meeting that contradicts a confident
+# claim = the oracle returning a true label). NO new reach_id (frozen bank = 6).
+connector:
+  connects_to_spine: true
+  sensor_triggers: []
+  reach_id: contradiction
+  sub_mode: file-meeting
+  framework: null
+  posture: pull_back
+  hierarchy_rank: 37
+  filing: fileEvidenceWithReadback
+  plan_gated: false
+  web_scope: null
+  surface: F.1
+---
+
+# /mos:file-meeting
+
+You are Larry. This command turns meeting conversations into Data Room intelligence through a 6-step conversational pipeline.
+
+---
+
+## Setup
+
+Load all reference files and context before starting:
+
+1. Read `${CLAUDE_PLUGIN_ROOT}/references/personality/voice-dna.md` for Larry's voice
+2. Read `${CLAUDE_PLUGIN_ROOT}/references/meeting/transcript-patterns.md` for speaker ID regex patterns
+3. Read `${CLAUDE_PLUGIN_ROOT}/references/meeting/segment-classification.md` for the 6-type segment taxonomy (the SELECTION pass)
+4. Read `${CLAUDE_PLUGIN_ROOT}/references/meeting/knowledge-typing.md` for the 6-enum knowledge taxonomy + conditions/counter_conditions + temporal validity (the TYPING pass)
+5. Read `${CLAUDE_PLUGIN_ROOT}/references/meeting/extraction-perspectives.md` for the five whole-transcript extraction perspectives dispatched at Step 3a
+6. Read `${CLAUDE_PLUGIN_ROOT}/references/meeting/section-mapping.md` for the 12-role x 6-type x 8-section routing matrix
+7. Read `${CLAUDE_PLUGIN_ROOT}/references/meeting/artifact-template.md` for wicked-problem-aware YAML frontmatter
+8. Read `${CLAUDE_PLUGIN_ROOT}/references/meeting/summary-template.md` for narrative + structured dual storage format
+9. Read `${CLAUDE_PLUGIN_ROOT}/references/meeting/speaker-profile-template.md` for ICM nested folder profiles
+10. Read `${CLAUDE_PLUGIN_ROOT}/references/meeting/cross-relationship-patterns.md` (if file exists -- skip gracefully if not)
+11. Read `${CLAUDE_PLUGIN_ROOT}/references/meeting/cross-meeting-intelligence.md` for cross-meeting convergence/contradiction detection and action item triage protocols
+12. Read `room/STATE.md` for venture context (if exists)
+13. Scan `room/team/` for known speaker profiles: glob `room/team/*/*/PROFILE.md`
+
+Track any newly created speaker profiles in a list called `new_profiles` for the post-pipeline research step.
+
+---
+
+## Step 0: Action Item Triage (Pre-Filing)
+
+Before starting the filing pipeline, check for open action items from prior meetings.
+
+### Load Open Items
+
+Read `room/action-items.md` if it exists. If the file does not exist or has zero open items, skip Step 0 entirely and proceed to Step 1.
+
+### Present Quick Triage
+
+Show open items as a pre-flight check (not an interrogation):
+
+> "3 open items from your last meeting. Quick check -- any done?"
+>
+> | # | Owner | Task | From Meeting |
+> |---|-------|------|--------------|
+> | 1 | Lawrence | Review TAM analysis | 2026-03-15-mentoring |
+> | 2 | Sarah | Send competitor deck | 2026-03-15-mentoring |
+> | 3 | Tyler | Schedule user interviews | 2026-03-10-research |
+>
+> [mark done: 1,3 / skip / review all]
+
+### Handle Responses
+
+- **mark done (e.g., "1,3")**: Update each item's status from `open` to `done` in the SOURCE meeting's action-items.md file (not the aggregated file). Find the source by the meeting_id in the aggregated table.
+- **skip**: Move on to Step 1. No changes.
+- **review all**: Show each item individually for yes/no.
+
+Track items marked done for inclusion in this meeting's summary ("Cleared 2 action items from prior meetings").
+
+---
+
+## Step 1: Get Transcript Input
+
+Determine the input mode based on flags:
+
+### No flags (default) -- Paste Mode
+
+Ask the user to paste their transcript text:
+
+> "Paste your meeting transcript below. I'll handle any format -- Zoom, Teams, Otter, Google Meet, or raw text."
+
+Accept multi-line paste. After receiving text, detect the transcript format using the regex patterns from `${CLAUDE_PLUGIN_ROOT}/references/meeting/transcript-patterns.md`. Report the detected format:
+
+> "Got it. Looks like a {format} transcript."
+
+### `--file <path>` -- File Mode
+
+Read the file at the provided path. Support `.txt` and `.md` extensions. Detect format from content using transcript-patterns.md patterns. If the file does not exist, report the error and suggest alternatives:
+
+> "Can't find that file. Try the full path, or just paste the transcript here."
+
+### `--audio <path>` -- Audio Mode
+
+Check if Velma is configured:
+1. Check `VELMA_API_KEY` environment variable
+2. Check `.mcp.json` for `mcpServers.velma.env.VELMA_API_KEY`
+
+**If not configured:**
+> "Audio needs Velma configured. Set it up now? (30 seconds)"
+> - If yes: Walk through the Velma setup flow (same as `/mos:setup transcription`)
+> - If no: "No problem. Paste the transcript text instead, or point me to a text file with `--file`."
+
+**If configured:**
+Run `bash "${CLAUDE_PLUGIN_ROOT}/scripts/transcribe-audio" <path>` and use the output as the transcript. Note the source as `velma` (affects artifact frontmatter).
+
+Also capture the full JSON response (written to temp file via stderr) for emotion data parsing downstream.
+
+### `--latest` -- Auto-Fetch Mode
+
+Automatically fetch the most recent meeting transcript from a configured meeting source (Read AI, Vexa, or Recall.ai).
+
+#### 1. Check for Configured Meeting Source
+
+Read `.mcp.json` in the workspace root and look for meeting source keys under `mcpServers`:
+
+- `read-ai` -- Read AI MCP
+- `vexa` -- Vexa MCP
+- `recall-ai` -- Recall.ai MCP
+
+**If no meeting source configured:**
+> "No meeting source configured. Run `/mos:setup meetings` first, or paste your transcript here."
+
+Then fall back to default paste mode (continue to the paste prompt above).
+
+#### 2. Fetch Recent Meetings
+
+If a meeting source is found, detect which provider by the key name in `mcpServers` and call its list tool:
+
+| Provider | MCP Tool Call | Returns |
+|----------|--------------|---------|
+| Read AI | `mcp__read-ai__list-meetings` | Recent meetings with titles, dates, durations |
+| Vexa | `mcp__vexa__list-sessions` | Recent sessions with metadata |
+| Recall.ai | `mcp__recall-ai__list-meetings` | Recent meetings with participant info |
+
+Present the 5 most recent meetings in a table:
+
+```
+| # | Date       | Title                          | Duration | Participants |
+|---|------------|--------------------------------|----------|--------------|
+| 1 | 2026-03-23 | Weekly Team Sync               | 45min    | 4            |
+| 2 | 2026-03-22 | Investor Update Call           | 30min    | 3            |
+| 3 | 2026-03-21 | Product Review                 | 1h 15min | 6            |
+| 4 | 2026-03-20 | Mentor Session with Lawrence   | 50min    | 2            |
+| 5 | 2026-03-19 | Customer Discovery Interview   | 35min    | 3            |
+```
+
+> "Grabbing your latest meeting. Or pick a different one: [1-5]"
+
+Default to #1 (most recent) if user confirms or presses enter. If user selects a number, use that meeting.
+
+#### 3. Fetch Transcript
+
+Call the source's transcript retrieval tool with the selected session/meeting ID:
+
+| Provider | MCP Tool Call |
+|----------|--------------|
+| Read AI | `mcp__read-ai__get-transcript` with the session ID |
+| Vexa | `mcp__vexa__get-transcript` with the session ID |
+| Recall.ai | `mcp__recall-ai__get-meeting-transcript` with the meeting ID |
+
+Use the returned transcript text as input to Step 1 format detection (proceed to "Infer Meeting Metadata" below).
+
+Set source metadata to the meeting provider name (e.g., `read-ai`, `vexa`, or `recall-ai`) for artifact provenance tracking.
+
+#### 4. Handle MCP Errors
+
+**Auth errors (401/403):**
+> "Authentication expired. Re-run `/mos:setup meetings` to reconnect."
+
+Then fall back to paste mode. Never block the pipeline.
+
+**Network / other errors:**
+> "Could not reach {source}. Check your connection. Meanwhile, paste the transcript or use `--file`."
+
+Then fall back to paste mode. Never block the pipeline.
+
+**Empty response (no meetings found):**
+> "No recent meetings found in {source}. Your meeting tool might not have recorded anything recently. Paste the transcript here instead."
+
+Then fall back to paste mode.
+
+### `--join <url>` -- Future Mode
+
+Print:
+> "Not yet available. Coming in a future update. Use `--latest`, paste, `--file`, or `--audio` for now."
+
+This flag is designed in `${CLAUDE_PLUGIN_ROOT}/references/meeting/live-join-interface.md` but not implemented until v3.0.
+
+### Infer Meeting Metadata
+
+After getting the transcript content, infer metadata from content and Data Room context:
+
+- **Meeting date**: Extract from timestamps in transcript, file modification date, or ask user. When `--latest` is used, the meeting date comes directly from the MCP response metadata -- no need to infer from transcript content.
+- **Meeting purpose**: Infer from content themes and dominant topics
+- **Participant count**: Count unique speaker labels. When `--latest` is used, the participant count comes from the MCP response metadata and can be cross-checked against speaker labels in the transcript.
+
+Present inferences for confirmation:
+> "This looks like a {type} meeting from {date} with {N} participants. Correct?"
+
+If the user corrects any inference, use their version. Store confirmed metadata for artifact provenance.
+
+### Step 1c. Meeting date and time
+
+Before moving to speaker identification, ask the navigator ONE question: when did this
+meeting happen? Accept an absolute date, a relative phrase ("last Tuesday", "yesterday
+morning"), or a time of day alongside either. State plainly that the phrase is resolved by
+chrono-node against `getReferenceNow()` -- the SAME resolver Step 4's `requireValidAt` gate
+uses -- so the two never disagree.
+
+**When the ingest path already carries a trustworthy timestamp** (the `--latest` provider
+tables above and the `--audio` file mtime both do): do NOT ask blind. State the date you
+found and ask the navigator to confirm or correct it. One question either way.
+
+Carry the confirmed or corrected answer forward as `whenAnswer` and pass it into Step 4's
+`requireValidAt` call (`{whenAnswer: process.env.WHEN_ANSWER||undefined}`) so the gate
+resolves and returns `GATE_PASS` on the first attempt instead of blocking.
+
+**Why the ask moved here:** an undated meeting BLOCKS at Step 4's date-sync gate, and
+blocking after the navigator has watched the whole extraction assemble is a worse experience
+than answering one question at ingest.
+
+**This does not replace the Step 4 gate.** `requireValidAt` remains the ONE enforcement
+chokepoint (D-02); this section only PRE-POPULATES `whenAnswer` so that gate resolves
+cleanly the first time. If no answer was captured here for any reason, Step 4 still blocks
+and asks -- the enforcement point is unchanged.
+
+---
+
+## Step 2: Speaker Identification + Profile Creation
+
+### Parse Speaker Labels
+
+Use the regex patterns from `${CLAUDE_PLUGIN_ROOT}/references/meeting/transcript-patterns.md` to extract speaker labels from the transcript.
+
+**If speaker labels are found:** Extract all unique speakers and proceed to matching.
+
+**If no speaker labels found:** Ask the user:
+> "I don't see speaker labels in this transcript. Who was in this meeting? Give me names and I'll match the voices to the content."
+
+Use their response combined with content analysis to attribute segments to speakers.
+
+### Cross-Reference Against Team Directory
+
+For each identified speaker, check `room/team/` profiles:
+
+- **Known match** (exact name match in existing profile): Mark as `AUTO-MATCHED`
+  - Example: "Lawrence matches team/mentors/lawrence-aronhime/ (mentor)"
+- **Partial match** (similar name in existing profile): Present for confirmation
+  - Example: "This sounds like Lawrence -- mentor from team directory. Confirm?"
+- **Unknown** (no match in team directory): Infer role from content
+  - Example: "Speaker 2 discussed financials and seems senior -- could this be your advisor?"
+
+### Present Smart Hybrid Table
+
+Show all speakers in a single table:
+
+```
+| Speaker | Match | Role | Status |
+|---------|-------|------|--------|
+| Lawrence | team/mentors/lawrence-aronhime/ | mentor | AUTO-MATCHED |
+| Tyler | (no match) | researcher? | NEEDS CONFIRMATION |
+| Sarah | team/founders/sarah-chen/ | founder | AUTO-MATCHED |
+```
+
+User confirms matches and fills unknowns. Roles must be from the 12-type taxonomy:
+mentor, researcher, team-member, investor, advisor, customer, founder, partner, domain-expert, government, competitor, unknown
+
+### Create Profiles for New Speakers
+
+For each CONFIRMED unknown speaker (user has confirmed their identity and role):
+
+Run `bash "${CLAUDE_PLUGIN_ROOT}/scripts/create-speaker-profile" <room_dir> <speaker-slug> <speaker-role> <display-name>`
+
+Add the speaker to the `new_profiles` list for post-pipeline research.
+
+### Emotion Signals (Audio Input Only)
+
+If the input was `--audio` and Velma data includes emotion scores, surface ONLY strong emotions (score > 0.7):
+
+> "Tyler was notably skeptical when discussing market size."
+> "Sarah showed high enthusiasm about the enterprise pivot."
+
+Do not surface routine or weak emotions. Only notable emotional signals that provide insight.
+
+---
+
+### Transcript size probe
+
+Before Step 3 begins, count words and speaker turns in the transcript. State both numbers to
+the navigator in one line, for example: "3,400 words, 62 turns -- extracting now."
+
+**Under 12,000 words:** proceed. Say nothing beyond the one line above.
+
+**At or above 12,000 words:** surface an honest offer, in Larry's voice, that this is a long
+one, and ask whether to work through it in sections. For example: "This is a long one --
+{N} words. Want me to work through it in sections, or run it straight through?"
+
+**Why 12,000 words.** A 1-hour meeting runs about 9,000 words (~13k tokens at typical
+conversational density); the largest transcript in this repo is 19,208 words (~26k tokens).
+12,000 sits between the two so the offer fires on genuinely long material and not on a
+normal meeting -- this is not a magic constant, it is reasoned from the two measured data
+points above.
+
+**What the offer does and does not do today.** This is a conversational offer, not a
+fan-out: today, working "in sections" means Larry paces the four Claimify passes across the
+conversation, nothing more. The parallel perspective-subagent extraction that actually
+splits the work across concurrent workers is plan 265-19, and it reuses this SAME probe as
+its trigger -- do not build a second probe for it.
+
+**The failure this prevents.** Per the research, a long transcript degrades with no signal
+today: the symptom reads as "Larry missed some claims," not "the pass was over budget." This
+probe turns a silent quality loss into a visible, reasoned choice.
+
+---
+
+## Step 3: Claimify Extraction (Five-Perspective Parallel Dispatch + Consolidation)
+
+> Quick 260903-kwl: `${CLAUDE_PLUGIN_ROOT}/references/meeting/filing-protocol.md` is the
+> surface-neutral extract of this step, handed back by the MCP `meeting` tool
+> on Claude Desktop and Cowork. This CLI command keeps its own inline copy of
+> the protocol deliberately - the extract cannot carry the subagent dispatch
+> below or the F.8 gate in Step 4, both CLI-only machinery. `tests/test-kwl-meeting-mcp-honesty.cjs`
+> is the drift guard that pins the shared taxonomies across both files.
+
+This step replaces a single unified extraction pass with FIVE PARALLEL
+WHOLE-TRANSCRIPT PERSPECTIVE workers (Step 3a, DISPATCH) followed by one
+orchestrator-only reconciliation pass (Step 3b, CONSOLIDATION). Extraction IS
+the segmentation authority -- a transcript that decomposes into K atomic
+claims mints K claim nodes, never one file-level claim. Consolidation FEEDS
+the existing F.8 nugget routing gate in Step 4; it never replaces or bypasses it.
+
+Purpose: recall. One pass over a long meeting misses what only one lens would
+have noticed. The five perspectives, their taxonomy anchors, and the uniform
+return schema are defined in
+`${CLAUDE_PLUGIN_ROOT}/references/meeting/extraction-perspectives.md` (loaded
+in Setup, alongside segment-classification.md and knowledge-typing.md).
+
+**The cost, stated plainly.** Five whole-transcript passes cost roughly FIVE
+TIMES the transcript tokens, plus five reference payloads. This is bought for
+RECALL, not for wall clock or token savings, and that trade is recorded
+honestly rather than pretended away. The Transcript size probe above (the
+12,000-word threshold wired by plan 265-10) is where the navigator is told the
+run is large, BEFORE this dispatch starts -- the cost of a long meeting is a
+stated, reasoned choice, never a silent quality loss.
+
+All extraction judgment is LLM reasoning (Larry reasoning over the full
+transcript, once per perspective). There is NO CJS extractor: extraction is
+judgment, and a hardcoded extractor would be the RESEARCH anti-pattern.
+
+---
+
+### Step 3a: Dispatch (five perspectives, one message)
+
+Dispatch FIVE subagents in ONE message, one per perspective defined in
+`${CLAUDE_PLUGIN_ROOT}/references/meeting/extraction-perspectives.md`:
+Decisions and Commitments; Technical Claims and Causal Mechanisms; Open
+Questions and Unknowns; Risks, Blockers and Anomaly Cues; Stakeholder
+Dynamics and Working Models.
+
+**Dispatch idiom:**
+
+1. Dispatch all 5 in ONE message using the Agent tool with
+   `subagent_type: meeting-perspective-extractor` (the explicit type string,
+   not a file path -- an Agent tool call that cannot resolve a
+   `subagent_type` is a hard error listing available agents since 2.1.235;
+   see `agents/meeting-perspective-extractor.md` for its instructions).
+   Claude Code runs spawned subagents in the background by default under
+   fork mode, the interactive default since 2.1.232 -- do NOT pass any
+   manual background-execution parameter to the Agent tool call; the
+   platform removes that kind of parameter from the Agent tool entirely once
+   fork mode is on (code.claude.com/docs/en/sub-agents). The platform caps
+   concurrent subagents at 20 (`CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS`); five
+   is well under that cap, but state it anyway as the standing rule so a
+   future author does not reintroduce an unbounded fan-out.
+2. Print a status block before dispatch:
+   ```
+   [FILE-MEETING] Dispatching 5 extraction perspectives
+     1. Decisions and Commitments
+     2. Technical Claims and Causal Mechanisms
+     3. Open Questions and Unknowns
+     4. Risks, Blockers and Anomaly Cues
+     5. Stakeholder Dynamics and Working Models
+   ```
+
+**Each worker's prompt MUST carry:**
+
+- **The FULL transcript.** Not a partial excerpt, not a segment range -- the
+  fan-out is bought for recall, and a lens that cannot see the whole meeting
+  cannot notice the thing only it would notice.
+- **The CONFIRMED Step 2 speaker roster.** Never re-derived per worker;
+  speaker identity is an upstream, human-confirmed input.
+- **Its own perspective definition, verbatim,** from
+  `extraction-perspectives.md`.
+- **`${CLAUDE_PLUGIN_ROOT}/references/meeting/segment-classification.md` and
+  `${CLAUDE_PLUGIN_ROOT}/references/meeting/knowledge-typing.md`.** NOT
+  `section-mapping.md`: workers do not propose target sections, so they do
+  not need the routing matrix. This omission is a deliberate cost decision,
+  not an oversight.
+- **The Four Claimify Passes** (below) as the worker's own procedure.
+- **An explicit no-write, no-gate, no-user-interaction contract:** return
+  structured JSON only. No `writeClaimNode`, no `writeEdge`, no artifact
+  write, no AskUserQuestion, no room state change. This worker does not
+  write anything, ever.
+- **A read-only tool grant,** with the reason named: transcript prose is
+  untrusted input and `tests/test-part8-poison-transcript.cjs` exists
+  because of it; fanning it into five tool-capable contexts multiplies the
+  injection surface. `agents/meeting-perspective-extractor.md` declares
+  `allowed-tools: Read` only -- no Write, no Bash, no Glob, no external web
+  reach, no MCP tool.
+
+**Returns:** the uniform array from `extraction-perspectives.md`'s return
+schema, with `perspective` set to the worker's assigned lens name.
+
+#### The Four Claimify Passes (run inside each worker, per perspective)
+
+##### Pass 1: Selection
+
+Classify each segment using the 6-type SEGMENT taxonomy from
+`${CLAUDE_PLUGIN_ROOT}/references/meeting/segment-classification.md` (decision, action-item, insight,
+advice, question, noise) and this worker's own perspective definition (its
+primary segment types, from `extraction-perspectives.md`):
+
+1. **Classify** the segment type.
+2. **Apply role-aware heuristics**:
+   - Investor question about financials = HIGH priority
+   - Mentor advice on problem framing = HIGH priority
+   - Team-member status update = MEDIUM priority
+3. **Sort by priority**: decisions (HIGHEST) > action-items (HIGH) > insights (MEDIUM) > advice (MEDIUM) > questions (LOW)
+4. **Flag potential noise** that contains proper nouns, competitor names, or numbers -- this
+   worker does not decide to skip it; it returns the row like any other for the
+   orchestrator's basket.
+
+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, through this worker's own lens.
+
+##### Pass 2: Disambiguation
+
+For each selected segment, resolve pronouns and referents before decomposing:
+
+1. Use the **speaker identity** from the Step 2 roster and the **prior 2 to 3
+   turns** of context to bind every pronoun ("it", "they", "this") and every
+   bare referent ("the deal", "that number") to a concrete antecedent.
+2. **Unresolvable referents** do NOT drop the segment. Extend the existing
+   below-0.5 ask-the-user rule (`segment-classification.md` Classification
+   Confidence Scoring, the "below 0.5 -> ask the user" threshold): when a referent
+   cannot be resolved from the speaker plus the prior 2 to 3 turns, the resulting
+   atomic claim is still returned, marked `disambiguation: 'ambiguous'`, and QUEUED
+   for human review. An ambiguous claim is NEVER silently dropped. This worker
+   never asks the user directly -- the ambiguous marker travels in the
+   returned row for the orchestrator to surface.
+
+##### Pass 3: Decomposition
+
+Split each compound segment into ATOMIC claims (extends the Multi-Type resolution
+rules in `segment-classification.md`):
+
+1. A segment that asserts two things becomes two atomic claims ("revenue was $1.2M
+   and churn dropped" -> a `fact` claim 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 it still reads as two types, it was not fully decomposed; split again.
+
+##### Pass 4: Typing (return, do NOT write)
+
+Classify each atomic claim against the 6-enum knowledge taxonomy in
+`${CLAUDE_PLUGIN_ROOT}/references/meeting/knowledge-typing.md`
+(fact / causal / heuristic / anomaly_cue / mental_model / assumption), run the
+conditions/counter_conditions contrastive probe, extract valid_from/valid_until
+when the claim is time-bound, then RETURN the row in the uniform schema
+(`extraction-perspectives.md`):
+
+```
+{
+  segment_id, speaker_id, segment_type, priority, claim_text, knowledge_type,
+  conditions, counter_conditions, valid_from, valid_until, disambiguation,
+  confidence, reasoning_line, perspective
+}
+```
+
+This worker NEVER calls `navigation.writeClaimNode` itself -- that write
+happens exactly once per consolidated claim, from the single main-thread db
+handle, in Step 3b sub-step 5. The claim text stays out of this worker's
+return only in the sense that it never touches any Brain call; it rides the
+returned row back to the orchestrator, which is still LOCAL (Canon Part 8).
+
+##### Show perspective reasoning
+
+For EVERY classified atomic claim, this worker's `reasoning_line` field
+carries Larry's one-line reasoning, extending each line with the
+knowledge_type -- for example:
+
+> "insight about market size | claim: fact | Confidence: 0.85"
+> "decision about product focus | claim: heuristic | Confidence: 0.92"
+> "advice on hiring | claim: mental_model | Confidence: 0.78"
+> "unresolved referent 'they' -> queued AMBIGUOUS | claim: assumption | Confidence: 0.40"
+
+The section-target routing (e.g. "-> market-analysis") is added later, at
+Step 4, because target-section decisions are section-mapping.md's job and
+this worker never sees that matrix. Transparency is mandatory -- even when it
+makes the flow longer. The user needs to trust Larry's classifications.
+
+---
+
+### Step 3b: Consolidation (orchestrator only, after all five workers return)
+
+A worker structurally cannot own any of the following: Step 3 requires
+showing reasoning for EVERY classified atomic claim across the WHOLE meeting;
+Step 4 is confirm-then-file per batch with structured rejection capture;
+Step 4's date-sync gate can return `GATE_BLOCK`. None of that is visible to,
+or ownable by, a single perspective worker holding only its own output. The
+orchestrator (the main conversation thread) owns every one of these seven
+ordered sub-steps:
+
+1. **Merge and deduplicate across perspectives.** Two lenses seeing the same
+   segment is the EXPECTED case, not the edge case: a decision that is also a
+   causal claim will surface twice. Merge on `segment_id`. Step 3 has NO
+   claim-level dedup today (`CLAIM_NODE_ID` gives idempotency for the same
+   segment in the same session, which is a different property), so this step
+   is genuinely new and exists because the fan-out created the duplicate.
+2. **Reconcile `knowledge_type` disagreement.** When two perspectives assign
+   different types to the same `segment_id`, do NOT average and do NOT pick
+   by confidence alone. Apply the existing rule from `knowledge-typing.md`: a
+   claim must carry exactly ONE dominant type after typing, else it splits.
+   So either split the claim into two atomic claims (Pass 3's own remedy), or
+   record the losing type in `disambiguation` and surface the disagreement in
+   the reasoning line. A silent pick is forbidden.
+3. **Mint cross-claim edges over the full set.** When the prose justifies a
+   relationship BETWEEN two consolidated atomic claims, mint a typed edge via
+   `navigation.writeEdge` using the amended taxonomy
+   (`lib/core/navigation/edges.cjs` `ALLOWED_EDGE_TYPES`):
+   - `REFINES` -- a new claim TIGHTENS or CONDITIONS a prior claim without
+     invalidating it (the missing middle between INFORMS-too-weak and
+     CONTRADICTS-wrong). Source = the refining claim.
+   - `ROOT_CAUSES` -- a directional cause-to-effect edge. Source = the cause
+     claim, target = the effect claim (a `causal` claim is the natural
+     source).
+   - `INSTANTIATES` -- a concrete example claim that EVIDENCES an abstract
+     claim. Source = the concrete claim, target = the abstract
+     `mental_model` claim.
+   `valid_from` / `valid_until` ride the edge `properties` JSON (zero
+   `writeEdge` signature change). The claim BODY never lands on the edge --
+   edge properties are enum and scalar only (Canon Part 8). This is
+   orchestrator work: the canonical `INSTANTIATES` case is a concrete claim
+   evidencing an abstract `mental_model` claim, and in a real meeting the
+   abstraction and its example are frequently 20 minutes apart and found by
+   two different perspectives -- only the orchestrator ever holds both.
+4. **Detect intra-meeting contradictions** across the FULL claim set,
+   rendered in the claim-A-versus-claim-B-with-speakers format from
+   `${CLAUDE_PLUGIN_ROOT}/references/meeting/summary-template.md`'s
+   "## Contradictions Detected" section.
+5. **Call `navigation.writeClaimNode(db, params)` ONCE PER CONSOLIDATED CLAIM
+   FROM THE SINGLE MAIN-THREAD DB HANDLE** (via `lib/core/navigation.cjs`
+   over a room.db handle from `openRoomDb`), with:
+   ```
+   {
+     text,                  // the atomic claim text (stays LOCAL, never to Brain)
+     knowledge_type,        // one of the frozen 6 enum members
+     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)
+     sourceSpeaker,         // the Step 2 roster speaker id
+     sourceSegment,         // the segment id (idempotency key)
+     sessionId,             // the meeting session id
+     disambiguation         // 'ambiguous' ONLY for unresolved claims (Pass 2), else omitted
+   }
+   ```
+   `lib/core/room-db.cjs` folds a 5-second busy timeout into `DatabaseSync`
+   precisely because a background worker and a live conversation can
+   contend on the same WAL file; five agents writing would multiply that for
+   no benefit -- so the main thread is the ONLY writer. `writeClaimNode`
+   mints `type='claim'`, `review_status='proposed'` (NEVER auto-confirmed --
+   Canon Part 9 role 5: a human confirms truth at a Decision Gate). Re-filing
+   the same segment in the same session UPSERTs (idempotent), never
+   duplicates. The claim PROSE lives only in room.db and the artifact; only
+   the knowledge_type enum handle may ride to Brain downstream (Canon Part 8).
+6. **Render the reasoning line for every claim.** The reasoning line rule is
+   unconditional and survives verbatim, extending each line with the
+   knowledge_type AND now naming WHICH PERSPECTIVE surfaced the claim (both,
+   when two did):
+
+   > "insight about market size -> market-analysis | claim: fact | Confidence: 0.85 | via Technical Claims and Causal Mechanisms"
+   > "decision about product focus -> solution-design | claim: heuristic | Confidence: 0.92 | via Decisions and Commitments"
+   > "advice on hiring -> team-execution | claim: mental_model | Confidence: 0.78 | via Stakeholder Dynamics and Working Models"
+   > "unresolved referent 'they' -> queued AMBIGUOUS | claim: assumption | Confidence: 0.40 | via Open Questions and Unknowns, Risks, Blockers and Anomaly Cues"
+
+   Transparency is mandatory -- even when it makes the flow longer. The user
+   needs to trust Larry's classifications.
+7. **Hand the consolidated set to Step 4 UNCHANGED.** Consolidation FEEDS the
+   F.8 nugget routing table Step 4 wires (`renderShapeF8` ->
+   `consumeF8Fanout`); it does not replace or bypass it: one consolidated
+   table, one `renderShapeF8` card, one confirm through `consumeF8Fanout`,
+   nothing files without the navigator. Every claim is still born
+   `review_status: 'proposed'` at the writer, and `promoteNodeStatus` still
+   rejects a literal `larry`, `brain`, `system` or `assistant` identity with
+   `agent_attribution_forbidden`.
+
+---
+
+## Step 4: Section Mapping + Confirm-Then-File
+
+### Present Segments Batched by Type (Priority Order)
+
+Group classified segments by type. Within each type, sort by confidence. Present the highest-priority types first, with Larry's reasoning for each:
+
+```
+**DECISIONS (2 segments):**
+1. Lawrence (mentor): "Focus on B2B first, consumer can wait."
+   -> team-execution | decision | HIGH confidence
+   Reasoning: Direct strategic direction from mentor
+
+2. Sarah (founder): "We're pausing the mobile app."
+   -> solution-design | decision | HIGH confidence
+   Reasoning: Product roadmap change from founder
+```
+
+Do this for EVERY type present (decisions, action items, insights, advice, open questions)
+before moving to the filing gate below -- the navigator sees the full extraction before being
+asked to file any of it.
+
+### The Filing Gate is Shape F.8 (renderShapeF8 -> consumeF8Fanout)
+
+The frontmatter above declares `hitl_shape: "F.8"` -- "Extracted nuggets are routed as an
+independent set the navigator files in any order." This is where that declaration actually
+fires, in place of a flat ASCII prompt.
+
+**1. Build ONE consolidated nugget routing table** across ALL extracted types (decisions,
+action items, insights, advice, open questions) -- one table, not one prompt per batch.
+Use the same canonical columns already shipping in `commands/ignite.md` and
+`commands/new-project.md`:
+
+```
+| nugget | target section | why |
+|--------|----------------|-----|
+| Lawrence (mentor): "Focus on B2B first, consumer can wait." | team-execution | Direct strategic direction from mentor |
+| Sarah (founder): "We're pausing the mobile app." | solution-design | Product roadmap change from founder |
+| ... one row per classified segment across every type ... |
+```
+
+**2. Render it through the shipped machinery, never a hand-rolled prompt.** Call
+`lib/hmi/shape-f8-renderer.cjs` `renderShapeF8` with the table rows as the toggle basket
+(one option per nugget: `label` is the nugget summary, `confidence` is the segment's
+classification confidence, so a >=0.70 nugget renders PRE-CHECKED per D-06 -- display-only,
+never auto-applied). Fire the returned card via **AskUserQuestion** as a multi-select (the
+contract's `multiSelect: true`). On the single confirm, hand the navigator's selected subset
+to `lib/workflow/f8-fanout-consumer.cjs` `consumeF8Fanout`, passing a per-nugget filing
+closer that writes the artifact (see Create Filed Artifacts, below) for each confirmed item.
+ONE confirm fans out to N filed artifacts -- toggling a nugget off is how the navigator skips
+it; there is no separate "review individually" mode because every nugget already IS reviewed
+individually via its own toggle.
+
+**3. Honor the paging bound.** `MAX_TOGGLE_N` is 4. A basket larger than 4 PAGES rather than
+truncates (D-05) -- a 40-nugget meeting therefore walks several pages of the same card, never
+a silently-truncated set. Do not invent a per-command cap and do not raise `MAX_TOGGLE_N`.
+
+**4. Nothing files until the navigator confirms.** Every claim minted by Step 3 Pass 4
+(`navigation.writeClaimNode`) is born `review_status: 'proposed'` -- rendering this gate as
+F.8 does not and cannot change that; the writer is the sole mint point (Canon Part 9 role 5).
+Promotion runs only through `navigation.confirmNode` with a non-agent `byUser` resolved from
+USER.md: a literal `larry`/`brain`/`system`/`assistant` is rejected by `promoteNodeStatus`
+with `agent_attribution_forbidden`. The declaration and the render finally agree.
+
+### Handle Rejections
+
+A nugget the navigator does NOT toggle on still records why, when a reason is given: offer
+structured rejection reasons for the unchecked rows --
+
+> "Skipping {N} nuggets. Why? [not relevant] [already known] [wrong section] [other]"
+
+Capture the rejection reason per unchecked nugget. This becomes graph data per the wicked
+problem architecture (rejection IS data, project decision 13) -- the F.8 toggle basket
+changes HOW the navigator picks, it does not change that a skip is still recorded.
+
+### Cross-Reference Against Open Action Items
+
+During filing, if any open action items remain (not cleared in Step 0), compare each segment being filed against them. If a segment appears to address or complete an open action item:
+
+> "This looks like progress on Lawrence's 'Review TAM analysis'. Mark as done?"
+
+Use Larry's judgment -- not exact text matching. Only surface when confidence is high. If user confirms, update the source meeting's action-items.md.
+
+### Date+Sync Gate (R11, D-02) -- runs BEFORE any artifact write
+
+The human owns `valid_at`. `created_at` = when we filed it; `valid_at` = when it
+actually happened. A meeting is ALWAYS a real-world event, so before writing the
+meeting artifact you MUST clear the shared date+sync gate -- the ONE enforcement
+chokepoint that both this CLI path and the MCP filing tool call (D-02, tri-polar;
+the rule lives in `lib/core/temporal/date-sync-gate.cjs` `requireValidAt`, never
+re-implemented per surface).
+
+A meeting node is flagged `has_event_date=true` at write time by node type (D-04 --
+meeting always; a decision/claim is flagged ONLY when this filing path detects an
+explicit event date). The flag is set at write, never inferred at read.
+
+Call the gate before the artifact write:
+
+```bash
+node -e "const {requireValidAt}=require('./lib/core/temporal/date-sync-gate.cjs'); \
+  const r=requireValidAt({type:'meeting',id:process.env.MEETING_ID,source_path:process.env.MEETING_PATH}, \
+  {whenAnswer:process.env.WHEN_ANSWER||undefined}); \
+  console.log(JSON.stringify(r));"
+```
+
+- If the gate returns `GATE_BLOCK`, render its Shape F.1 selector spec via
+  **AskUserQuestion** (the CLI render surface): a "when?" question that sets
+  `valid_at` (it accepts a free-typed relative phrase like "last Tuesday", which
+  the gate resolves via chrono-node against `getReferenceNow()`) AND a
+  multi-select "relates to?" question. You MUST NOT write the meeting artifact
+  until the gate returns `GATE_PASS` -- an undated meeting BLOCKS here.
+- When the human answers "relates to?", the gate writes a sync edge per relation
+  and emits `f_selector_sync_confirmed` (the existing Shape F sync machinery).
+- `created_at` stays the filing moment; `valid_at` is the human's answer. Both
+  ride the meeting node's `properties` JSON (additive, no DDL), Part 8 LOCAL only.
+
+### Create Filed Artifacts
+
+For each filed segment, create a markdown file in the target room section using the frontmatter from `${CLAUDE_PLUGIN_ROOT}/references/meeting/artifact-template.md`:
+
+**File path pattern:** `room/{section}/YYYY-MM-DD-{slug}.md`
+
+Include ALL provenance fields:
+- methodology: file-meeting
+- created: {today}
+- source: transcript (or velma)
+- attribution:
+  - speaker: {name}
+  - role: {role}
+  - profile_path: team/{role-plural}/{speaker-slug}
+  - meeting_date: {meeting date}
+  - meeting_id: {YYYY-MM-DD-meeting-slug}
+- segment_type: {type}
+- confidence: {confidence score}
+- meeting_date: {meeting date}
+- meeting_name: {meeting identifier}
+- room_section: {target section}
+- assumptions: {extracted assumptions with status and impacts}
+- perspective: {speaker_role}
+- cascade_sections: {sections this may affect beyond target}
+
+When writing the artifact content, auto-insert [[concept-name]] links for key concepts that connect this segment to other parts of the Data Room. Use [[section-name]] for cross-section references (existing pattern) and [[concept-name]] for domain concepts, frameworks, or recurring themes. Examples: [[wicked-problems]], [[assumption-tracking]], [[market-sizing]], [[competitive-moat]]. These wikilinks feed the knowledge graph -- build-graph parses them into concept nodes and REFERENCES edges. Users can also manually add [[wikilinks]] to any room artifact at any time.
+
+**Native wikilink injection (NATIVE-01/02):** Immediately after writing each filed artifact, run:
+```bash
+node "${CLAUDE_PLUGIN_ROOT}/scripts/wikilink-file.cjs" "$ROOM_DIR" "$ARTIFACT_PATH"
+```
+This uses `lib/vault/wikilink-builder.cjs` to inject team-name wikilinks at write time so the artifact arrives pre-linked. Errors are logged but non-fatal -- filing never aborts because of a wikilink pass.
+
+Speaker contributions are tracked via computed backlinks in PROFILE.md (run by compute-team), not by filing copies to speaker subfolders.
+
+Track: total segments filed, total rejected, sections touched.
+
+---
+
+## Step 5: Create Meeting Summary + Archive
+
+### Infer Meeting Name + Confirm
+
+Before creating the archive, confirm the meeting name with the user:
+
+1. **Larry proposes** a meeting name from the dominant topic/purpose of classified segments:
+   > "This looks like a mentoring session focused on market validation. I'd call it 'Market Validation Mentoring'. Sound right?"
+
+2. **User confirms or changes** the name. Use their version if they provide one.
+
+3. The confirmed meeting name becomes the **meeting_id** used in all attribution blocks and archive paths:
+   - meeting_id: `YYYY-MM-DD-{confirmed-slug}` (e.g., `2026-03-15-market-validation-mentoring`)
+   - Slugify: lowercase, hyphens, no special characters, max 50 characters
+
+### Meeting Archive Package
+
+The complete meeting archive directory structure:
+
+```
+room/meetings/YYYY-MM-DD-{meeting-name}/
+  transcript.md
+  summary.md
+  speakers.md
+  decisions.md
+  action-items.md
+  metadata.yaml
+  {audio-filename}       # only if --audio input
+  filed-to/
+```
+
+Each meeting is a self-contained knowledge artifact. The entire folder can be browsed, shared, or referenced as a unit.
+
+### Create Meeting Archive Directory
+
+```bash
+mkdir -p room/meetings/YYYY-MM-DD-{meeting-name}/filed-to/
+```
+
+### Store Processed Transcript
+
+Write the processed transcript (with speaker labels and format metadata) to:
+`room/meetings/YYYY-MM-DD-{meeting-name}/transcript.md`
+
+### Create Speakers Roster
+
+Create `room/meetings/YYYY-MM-DD-{meeting-name}/speakers.md`:
+
+```markdown
+---
+meeting_id: {YYYY-MM-DD-meeting-slug}
+meeting_date: {YYYY-MM-DD}
+---
+# Speakers: {meeting_name}
+
+| Speaker | Role | Segments | Profile |
+|---------|------|----------|---------|
+| {name} | {role} | {count} | [[team/{role-plural}/{slug}/PROFILE.md]] |
+```
+
+One row per confirmed speaker from Step 2. Profile links use the slug from create-speaker-profile (canonical slug source).
+
+### Create Full Summary
+
+Following `${CLAUDE_PLUGIN_ROOT}/references/meeting/summary-template.md`, create the full meeting summary at:
+`room/meetings/YYYY-MM-DD-{meeting-name}/summary.md`
+
+Structure:
+
+1. **Narrative lead paragraph** in Larry's voice:
+   > "Lawrence pushed hard on market validation today. Three things you can't ignore..."
+
+2. **## Key Decisions** -- with who decided and the reasoning
+
+3. **## Insights Filed** -- {count} insights filed to {sections list}
+
+4. **## Contradictions Detected** -- if any contradictions found between this meeting's content and existing room content. Skip section entirely if none.
+
+5. **## Gaps Identified** -- room sections that SHOULD have received input from this meeting but didn't. Based on the speaker roles present and what they discussed.
+
+6. **## Action Items** -- with owners assigned from speaker context. Deadlines ONLY when explicitly mentioned in transcript. Never invent deadlines.
+
+7. **## Rejections** -- segments rejected with structured reasons. This IS data -- do not hide or minimize rejections.
+
+8. **## Speakers** -- {count} speakers with roles and contribution summary
+
+9. **## Convergence Signals** -- topics appearing in 3+ meetings across the meeting history. Only include if convergence was detected. Skip section entirely if none.
+
+10. **## Cross-Meeting Contradictions** -- contradictions detected against prior meetings (beyond within-meeting contradictions in section 4). Only include if cross-meeting contradictions were found.
+
+### Create Decisions Log
+
+Create `room/meetings/YYYY-MM-DD-{meeting-name}/decisions.md`:
+
+```markdown
+---
+meeting_id: {YYYY-MM-DD-meeting-slug}
+---
+# Decisions: {meeting_name}
+
+1. **{Decision summary}** -- {speaker} ({role})
+   Filed to: [[{section}/{artifact-filename}.md]]
+   Impact: {cascade_sections from the decision artifact}
+```
+
+Extract from the segments classified as `decision` in Step 3. If no decisions were made, write: "No explicit decisions were recorded in this meeting."
+
+### Create Action Items Log
+
+Create `room/meetings/YYYY-MM-DD-{meeting-name}/action-items.md`:
+
+```markdown
+---
+meeting_id: {YYYY-MM-DD-meeting-slug}
+---
+# Action Items: {meeting_name}
+
+| Owner | Task | Deadline | Status |
+|-------|------|----------|--------|
+| {name} | {task} | {date or "not specified"} | open |
+```
+
+Extract from segments classified as `action-item` in Step 3. Deadlines ONLY if explicitly stated in transcript -- never invent deadlines. All items start as `status: open`. If no action items, write: "No action items were identified in this meeting."
+
+### Create Structured Metadata
+
+Create `room/meetings/YYYY-MM-DD-{meeting-name}/metadata.yaml` as the LAST file in the archive (after all other data is known):
+
+```yaml
+meeting_id: {YYYY-MM-DD-meeting-slug}
+meeting_name: {human-readable meeting name}
+meeting_date: {YYYY-MM-DD}
+source: {transcript | velma}
+speakers:
+  - name: {full name}
+    role: {role}
+    slug: {speaker-slug matching profile directory}
+  - name: {full name}
+    role: {role}
+    slug: {speaker-slug}
+topics:
+  - {dominant topic 1}
+  - {dominant topic 2}
+decisions_count: {N}
+insights_count: {N}
+action_items_count: {N}
+sections_touched:
+  - {section-name}
+  - {section-name}
+has_audio: {true | false}
+```
+
+Topics are inferred from the dominant themes of filed segments. Speaker slugs MUST match the directory names created by create-speaker-profile (canonical slug source).
+
+### Copy Audio File (if --audio)
+
+If input was `--audio <path>`, copy the audio file into the meeting archive:
+
+```bash
+cp {audio-path} room/meetings/{YYYY-MM-DD-meeting-slug}/{original-filename}
+```
+
+Set `has_audio: true` in metadata.yaml. If no audio input, set `has_audio: false`.
+
+Register the audio file in the room's ASSET_MANIFEST.md for dashboard/wiki discovery:
+
+```bash
+# Register audio in ASSET_MANIFEST.md
+bash "${CLAUDE_PLUGIN_ROOT}/scripts/file-asset" "$room_path" "$audio_path" "meetings" --meeting "$meeting_id"
+```
+
+This creates a markdown wrapper alongside the audio file in the meeting archive with a link to the transcript:
+```yaml
+---
+type: audio
+asset_path: meetings/{meeting_id}/{audio_filename}
+meeting_id: {meeting_id}
+transcript: meetings/{meeting_id}/transcript.md
+---
+```
+
+The wrapper content includes: `Transcript: [[meetings/{meeting_id}/transcript.md]]`
+
+### Create Filed-To Reference Directory
+
+In `room/meetings/YYYY-MM-DD-{meeting-name}/filed-to/`, create a small markdown file for each filed artifact pointing to its location:
+
+```markdown
+# {artifact-slug}
+Filed to: room/{section}/YYYY-MM-DD-{slug}.md
+Speaker: {name} ({role})
+Type: {segment_type}
+```
+
+**Native wikilink injection (NATIVE-01/02):** After writing each filed-to stub AND the meeting summary.md, run the wikilink wrapper to inject team links and filed-to footer lines at write time:
+```bash
+# For each filed-to stub
+node "${CLAUDE_PLUGIN_ROOT}/scripts/wikilink-file.cjs" "$ROOM_DIR" "$STUB_PATH" \
+  --filed-to-target="{section}/YYYY-MM-DD-{slug}.md" \
+  --meeting-slug="YYYY-MM-DD-{meeting-name}"
+
+# For the meeting summary
+node "${CLAUDE_PLUGIN_ROOT}/scripts/wikilink-file.cjs" "$ROOM_DIR" "$SUMMARY_PATH" \
+  --meeting-slug="YYYY-MM-DD-{meeting-name}"
+```
+See `lib/vault/wikilink-builder.cjs` for the canonical builders. The wrapper fails soft -- if the room has zero team profiles or scan errors, filing still completes cleanly.
+
+### Create Compact Root Reference
+
+Create a compact one-paragraph reference at the room root:
+`room/meeting-YYYY-MM-DD-{meeting-name}.md`
+
+```markdown
+---
+type: meeting-reference
+meeting_date: YYYY-MM-DD
+meeting_name: {name}
+speakers: {count}
+artifacts_filed: {count}
+sections_touched: [{sections}]
+---
+
+{One paragraph summary of the meeting and its impact on the Data Room.}
+
+Full summary: [[meetings/YYYY-MM-DD-{meeting-name}/summary.md]]
+Transcript: [[meetings/YYYY-MM-DD-{meeting-name}/transcript.md]]
+Filed {N} artifacts across {M} sections.
+```
+
+### Past Meeting Lookup
+
+When Larry needs to reference past meetings (e.g., "Lawrence mentioned this 3 meetings ago"), grep metadata.yaml files across `room/meetings/`:
+
+- **By speaker:** `grep -rl '{speaker-slug}' room/meetings/*/metadata.yaml`
+- **By topic:** `grep -rl '{topic}' room/meetings/*/metadata.yaml`
+- **By date range:** Scan `meeting_date` fields in metadata.yaml files
+- **By decision count:** `grep -l 'decisions_count: [1-9]' room/meetings/*/metadata.yaml`
+
+This provides fast targeted lookups without indexing. metadata.yaml is designed as a grep-friendly structured search surface.
+
+---
+
+## Step 6: Cross-Relationship Batch Scan
+
+After ALL filing is complete, scan filed artifacts against existing Data Room content.
+
+### Load Detection Heuristics
+
+Use `${CLAUDE_PLUGIN_ROOT}/references/meeting/cross-relationship-patterns.md` (already loaded in Setup if available) for the 5 edge types:
+
+- **INFORMS**: new artifact references or provides evidence for another section
+- **CONTRADICTS**: new artifact conflicts with existing claim
+- **CONVERGES**: theme from this meeting appears in 3+ sections
+- **INVALIDATES**: new artifact makes an existing assumption stale
+- **ENABLES**: new artifact unblocks something in another section
+
+### Scan Protocol
+
+1. For each filed artifact, read its content and assumptions
+2. Glob existing room content in related sections (especially cascade_sections)
+3. Apply Tier 0 keyword matching heuristics from cross-relationship-patterns.md
+4. Detect significant cross-relationships only -- not every minor keyword overlap
+
+**Tier 0 implementation:** Larry's conversational reasoning against room content. No LSA/MiniLM in Phase 6 -- computational similarity comes in Phase 8.
+
+### Present Findings
+
+**If significant cross-relationships found:**
+
+Present in priority order (INVALIDATES > CONTRADICTS > CONVERGES > ENABLES > INFORMS):
+
+> "This meeting changed something in your Data Room:"
+>
+> **CONTRADICTS:** Tyler's market size estimate ($50M) conflicts with the $190M TAM in your financial-model/revenue-projection.md. Which is current?
+>
+> **CONVERGES:** Enterprise focus was mentioned by 3 speakers and now appears in problem-definition, market-analysis, and solution-design. This is becoming a clear strategic direction.
+>
+> **INFORMS:** Sarah's competitive analysis point adds evidence to your competitive-analysis section.
+
+**If no significant cross-relationships found:**
+
+> "No significant cross-relationships detected from this meeting's content against your existing Data Room. As your room grows, cross-meeting intelligence will get richer."
+
+### Cross-Meeting Intelligence Scan
+
+After the within-meeting cross-relationship scan, perform cross-meeting pattern detection using the protocols from `${CLAUDE_PLUGIN_ROOT}/references/meeting/cross-meeting-intelligence.md`:
+
+#### Convergence Detection
+1. Extract key topics from the current meeting's metadata (topics inferred from filed segments)
+2. Grep `topics:` across all `room/meetings/*/metadata.yaml` files
+3. Any topic in 3+ meetings (including this one) = convergence signal
+4. Surface each: "Market validation has been raised in 4 of your last 6 meetings. This is becoming a central theme."
+
+#### Contradiction Detection
+1. Pre-filter prior meetings that share topics/speakers with current meeting (via metadata.yaml grep)
+2. Load summaries from up to 10 matching prior meetings
+3. Use Larry's reasoning to detect position changes or disagreements across meetings
+4. HIGH-impact contradictions (financials, strategy, key decisions): surface immediately with specific references
+5. LOW-impact contradictions (opinions, preferences): note in meeting summary
+
+#### Record Findings
+- Add convergence signals and cross-meeting contradictions to the meeting summary (new sections in Step 5)
+- Present the combined cross-relationship + cross-meeting findings to the user in priority order
+
+---
+
+## Post-Pipeline: Proactive Speaker Research
+
+After the entire 6-step pipeline is complete, check if any new speaker profiles were created in Step 2.
+
+**If `new_profiles` is empty:** Skip this section.
+
+**If `new_profiles` has entries:**
+
+> "I created profiles for {names}. Let me research them online to fill in context..."
+
+For each new speaker profile:
+
+1. Extract venture context from `room/STATE.md` (venture name, domain, stage) or use confirmed meeting context
+2. Run: `bash "${CLAUDE_PLUGIN_ROOT}/scripts/research-speaker" <room_dir> <speaker-slug> <display-name> "<project-context>"`
+3. Present the research findings to the user:
+   > "Here's what I found about {name}. Want me to update their profile?"
+4. **User confirms** before any research content is written to PROFILE.md
+5. If confirmed, run: `bash "${CLAUDE_PLUGIN_ROOT}/scripts/research-speaker" <room_dir> <speaker-slug> <display-name> "<project-context>" --apply`
+6. If declined: Leave profile with `research_status: pending` -- user can research later
+
+**Important:** Research runs AFTER the filing pipeline. Never block filing on external API calls. This follows Pitfall 7 from research: proactive research is valuable but must not interrupt the core workflow.
+
+---
+
+## Closing
+
+After all steps complete (including optional research):
+
+> "Meeting filed. {N} artifacts across {M} sections. {P} speakers identified. {R} new profiles created. Anything else from this conversation?"
+
+If cross-relationships were found, add:
+> "I flagged {X} cross-relationships worth reviewing."
+
+If cross-meeting intelligence was detected, add:
+> "{Y} convergence signals and {Z} cross-meeting contradictions detected."
+
+### Post-Filing Next-Move Selector (F.1)
+
+A write-only ladder with no visible next move is the exact failure class this
+milestone keeps finding (RESEARCH Pitfall 5). After filing completes, surface the
+DIKW ladder's next move through the canonical Shape F.1 selector so the navigator
+always has a visible move.
+
+Count the two scalars from the room.db graph (LOCAL only -- never the transcript
+prose, Canon Part 8):
+
+- `M` = the ambiguous-queue size:
+  `SELECT COUNT(*) FROM nodes WHERE type='claim' AND json_extract(properties,'$.disambiguation')='ambiguous' AND review_status='proposed'`
+- `N` = the proposed-claim count:
+  `SELECT COUNT(*) FROM nodes WHERE type='claim' AND review_status='proposed'`
+
+Then render the selector via `lib/hmi/selector-dispatcher.cjs` pickShape (the
+dispatcher auto-attaches the AskUserQuestion trailer + archetype and appends
+Free-Text last, so 3 ladder verbs render as `verbs=4`):
+
+```js
+const dispatcher = require('lib/hmi/selector-dispatcher.cjs');
+dispatcher.pickShape({
+  requestedShape: 'F.1',
+  tier,                 // the resolved room tier
+  roomDir,              // the active room dir
+  payload: {
+    verbs: [
+      'Review ambiguous segments (' + M + ')',
+      'Confirm proposed claims (' + N + ')',
+      'Build knowledge from this meeting',
+    ],
+    header: '-- mindrianOS -- meeting filed -- next move --',
+    emitTelemetry: true,   // ONLY on the actual presentation surface
+  },
+});
+```
+
+Verb routing (each is a thin dispatch over a SHIPPED chokepoint -- no new machinery):
+
+- **Review ambiguous segments (M)** -- walk the `disambiguation:'ambiguous'`
+  queue (the same scan the SessionStart `scripts/check-pending-ambiguous.cjs`
+  resurfaces); resolve each referent with the user, then re-mint the claim with
+  the resolved text (idempotent UPSERT).
+- **Confirm proposed claims (N)** -- per-claim APPROVE routes through
+  `navigation.confirmNode(db, claimId, navigation.resolveByUser(roomDir), reason)`.
+  `resolveByUser` reads USER.md first; NEVER pass a literal
+  'larry'/'brain'/'system'/'assistant' (promoteNodeStatus rejects with
+  `agent_attribution_forbidden`). The Knowledge rung is confirmable per Canon
+  Part 9 role 5: the human confirms truth.
+- **Build knowledge from this meeting** -- invoke `/mos:build-knowledge`, which
+  reads the typed claims by `knowledge_type` and renders them by DIKW rung.
+
+The frozen 148 dial constitution is UNTOUCHED here: this is a render-host call,
+not a ranker edit. MAX_K=3, DIAL_REACH_K=6, and the 0.70/0.15 gate stay where
+they are.
+
+---
+
+## Voice Rules
+
+- Larry's conversational voice throughout. Short sentences. Direct.
+- Frame gaps as opportunities: "Your competitive-analysis is light -- this meeting could change that."
+- Show reasoning for every classification. Transparency builds trust.
+- Never file silently. Always confirm-then-file.
+- Rejection reasons are valuable -- treat them with respect, not as failures.
+- Challenge gently when a user skips something important: "That decision from Lawrence seems significant. Sure you want to skip it?"