Skip to content

v6 Phase 0 Trio — Consistency Reconciliation Findings

Status: DRAFT (2026-05-12) — Phase 0 cross-spec consistency pass over PRs #855 / #856 / #859. Reviewer: SD (read this FIRST, then review the three sibling PRs with this context). Sibling PRs under review:

This doc is report-only. Per the user's constraints, no inline edits were applied — the three PR branches stay as-is for SD review. Each finding below names the doc(s), quotes the conflicting text, and recommends a surgical resolution. Findings are sorted major → minor within each category.

1. Summary

The three specs are substantially consistent at the structural level — all agree on 12 stages, the stage names are byte-identical across #855 and #856, and #859's rule-destination column reaches into stages that exist in the canonical list. There are no contradictions that would block CI gates from being designed.

What needs attention is a small set of stale or imprecise references that will confuse a future reader (especially a reviewer auditing the lockstep gate). The single highest-impact one is in #859 §6 OQ.02, which states "v6 spec lists 10 stages" while the other two docs (and #859's own usage) operate on 12. Beyond that, cross-spec linking is asymmetric — only #856 links to its siblings — and the CI gate algorithm in #859 §5 does not actually read sibling-spec data the way the lockstep description implies.

Totals: 18 findings across 10 categories. 5 major (would mislead a careful reader or break a CI gate when implemented literally), 13 minor (typos, missing cross-links, naming-convention nits). 0 fixes applied inline — all flagged for SD because (a) the three spec files are not on this branch and (b) several "obvious" fixes touch wording that Naidu or SD might prefer to phrase differently. Consolidated open-question dedupe: 9 Naidu items (down from 17 raw across docs) and 7 SD/engineering items (down from 9 raw).

Phase coverage is correctly distributed across the three docs:

  • Phase 1 (resolver implementation) — #855
  • Phase 2a (clinical wording lockstep) — #859
  • Phase 2b (stages.yaml + extractor wiring) — #856

Phase 0 sign-off condition #3 ("3 companion docs authored") is satisfied by the trio as a whole.

2. Findings

Numbered findings. Categories map to the 10 checks in the user's brief.

F-01 — Stage count mismatch in #859 §6 OQ.02 (MAJOR, category 4: stage count)

  • Docs involved: #859 (truth lies with #855 + #856).
  • Conflicting text (#859 §6 OQ.02):

    "OQ.02 — document_review phase has no 1:1 stage in v6. The v6 spec lists 10 stages; document review folds into records_collection guidance."

  • #855 §3 stage catalog: "Twelve stages." #856 §1 Total: "12 stages (11 forward-flow + 1 fallback)."
  • Resolution: In #859 OQ.02, change "10 stages" → "12 stages" (truth-table canon). Recommended status: typo, unambiguous — apply on next push of #859.

F-02 — intake referenced as a stage in #859 §1 shorthand (MAJOR, category 1: stage ID consistency)

  • Docs involved: #859 only.
  • Conflicting text (#859 §1, "v6 destination shorthand"):

    "stages.yaml:<stage>.<key>[<idx>] — pointer into a stage profile (e.g., stages.yaml:intake.guidance or stages.yaml:records_collection.do_not[0])."

  • Issue: intake is not a v6 stage. The canonical 12 are discovery, procedure_identification, records_collection, match_review, consent_capture, mso_offer, scheduling, pre_travel, in_treatment, recovery_offer, recovery_followup, support. #859 itself acknowledges in the same paragraph that v2 intake.yaml lands across procedure_identification + records_collection. The example string is stale from an earlier draft.
  • Resolution: Replace stages.yaml:intake.guidance with stages.yaml:procedure_identification.guidance (a real destination — see #859 §2.10 rules v4.FIRST.001–v4.FIRST.006 that target this path). Recommended status: unambiguous — apply on next push of #859.

F-03 — CI gate algorithm in #859 §5 doesn't cross-read sibling specs (MAJOR, category 5: CI gate algorithm)

  • Docs involved: #859 (claim does not match implementation), with implications for #855 and #856.
  • User-brief expectation: "#859's CI gate pseudocode reads truth-table stages + extractor matrix."
  • Actual: #859 §5 tests/test_lockstep_consistency.py reads only docs/specs/v6-rule-location-map.md plus conversation_v6.yaml, stages.yaml, knowledge/*, and conversation_v4.yaml. It does not ingest #855 (truth table) or #856 (extractor matrix). The function parse_rule_table() walks #859 itself; there is no parse_truth_table() or parse_extractor_matrix().
  • Implication: The lockstep gate cannot, as written, detect drift where (a) a stage_id is added to #855 but not registered in #859, or (b) an extractor is removed from #856 but a rule in #859 still depends on it.
  • Resolution: Two options for SD to pick:
  • (a) Add a new test in #859 §5 (test_stage_id_lockstep_with_truth_table) that reads #855 §3.1-3.12 stage IDs and asserts every stages.yaml:<stage> destination in #859 references one of them. Same idea against #856's stage column.
  • (b) Acknowledge the limit in §5 ("this gate covers rule→destination only; stage-id and extractor-id lockstep are covered by tests/test_stage_resolver_determinism.py + tests/test_extractor_matrix_stage_coverage.py which Phase 1/2b will add").
  • Recommended status: SD judgment call.
  • Docs involved: #855 and #859 (both fail to link the sibling docs); #856 is fine.
  • #855 §8 lists "Relationship to parent spec" but does not name #856 or #859 even though it must be read alongside them at PR review time. The phrase "the truth table is the canonical source" only lives in this consistency doc, not in #855 itself.
  • #859 §0 says "this doc is read by" but lists only test files and Naidu — not the sibling Phase 0 docs.
  • #856 correctly cites v6-stage-resolver-truth-table.md as "Sibling" in its frontmatter (line 11).
  • Resolution (recommended wording):
  • In #855 frontmatter (between "Parent spec" and "Tracking issue"): add "Sibling Phase 0 docs: v6-stages-extractors-matrix.md (extractor wiring), v6-rule-location-map.md (clinical-wording lockstep)."
  • In #856 frontmatter: extend the existing "Sibling" line to also name v6-rule-location-map.md.
  • In #859 frontmatter (after "Companion to:"): add "Sibling Phase 0 docs: v6-stage-resolver-truth-table.md (canonical stage list), v6-stages-extractors-matrix.md (extractor wiring)."
  • Recommended status: unambiguous — apply on next push of each PR.

F-05 — Naidu calendar burn risk: 17 raw open questions across 3 docs (MAJOR, category 7: open question dedupe)

  • Docs involved: all three.
  • Raw counts: #855 has 9 (Q-C1..Q-C7 clinical + Q-O1 + Q-O2 operational); #856 has 8 (Phase 2b implementation, none routed to Naidu); #859 has 8 (OQ.01..OQ.08, all routed to Naidu). User's brief said "#855 has 9, #856 has 8, #859 has 8" — counts confirmed.
  • Observation: #856's 8 are engineering questions (medical extractor schema, gate predicate, signal-gate threading, fallback patterns, p95 latency, support-stage extractor scope, debug card, MSO migration regression). None of #856's 8 are clinical. The user's brief implied otherwise — clarification: #856 has 0 Naidu questions and 8 SD/engineering questions, not "8 Naidu questions."
  • Consolidated counts after dedupe: see §3 below for Naidu (9 unique items), §4 for SD (7 unique items).
  • Resolution: Consolidate at the top of each spec ("see v6-trio-consistency-findings.md §3 for the merged Naidu question list — review them together to economize Naidu calendar time").

F-06 — Extractor naming inconsistency: informal "Intent extractor" vs canonical intent_extractor (MINOR, category 2: extractor ID consistency)

  • Docs involved: #855 (uses informal capitalized names); #856 (canonical).
  • Conflicting text:

  • 855 §2.2 row 1: "Set by Intent extractor on procedure confirmation"

  • 855 §3.2 exit condition: "Intent extractor flips procedure_identified=True"

  • 856 §2 catalog: intent_extractor (lowercase snake_case)

  • Resolution: In #855, normalize to lowercase snake_case (intent_extractor) wherever the extractor is referenced as an identifier, matching #856's catalog. The two non-identifier references that read as English prose ("an intent extractor flips...") can stay capitalized if they're framed as descriptive English; but the ID column should match #856 §2.

F-07 — Layer name vs extractor name divergence not explicitly mapped (MINOR, category 2)

  • Docs involved: #855 §2.3 layers, #856 §2 extractor catalog.
  • Conflicting text: #855 layer names are intent_capture, medical_status, travel_readiness, logistics, financial_readiness. #856 extractor names are intent_extractor, medical_extractor, travel_extractor, logistics_extractor, financial_extractor. The mapping is implicit (extractor X writes to layer Y) but stated nowhere in the trio.
  • Issue: A reader doing layer-state debugging needs to know which extractor populates travel_readiness — there's no travel_readiness_extractor, the answer is travel_extractor. This is a one-line addition to either #855 §2.3 or #856 §2.
  • Resolution: Add a "writes-to-layer" column in #856 §2 (intent_extractor → intent_capture, etc.), OR add a note in #855 §2.3 ("populated by <extractor_id> per #856 §2"). Recommend the #856 column; #856 is the extractor-catalog owner.

F-08 — recovery_checkin vs recovery_checkin_extractor suffix inconsistency (MINOR, category 2)

  • Docs involved: #856 internally; #859 follows #856.
  • Conflicting text:

  • 856 §2 catalog: recovery_checkin (no _extractor suffix; row 6)

  • 856 §8 Appendix: "extractor_id keys MUST match the agent_name passed to llm_gateway.invoke() (which today are intent_extractor.extract, medical_extractor.extract...)"

  • 856 §5 hard-dependency section: "recovery_checkin is independent of all others"

  • Issue: The other five extractors carry the _extractor suffix in the catalog; only recovery_checkin drops it. The §8 appendix concedes the mismatch is "preserved per Langfuse trace-tag continuity" — meaning the agent_name is recovery_checkin_extractor.extract even though the catalog short name omits the suffix. This is acceptable but worth flagging because the lockstep test in #859 references the extractor by name in §3.6 verbatim phrases (the keyword list at registry entry 42).
  • Resolution: Either (a) normalize to recovery_checkin_extractor in #856 catalog and column header, or (b) add a one-line note to #856 §2 row 6: "Short form used in this doc; agent_name is recovery_checkin_extractor.extract per Langfuse trace continuity (see §8)."

F-09 — support stage extractors_active semantic conflict with parent §2.5 (MINOR, category 5: CI gate inputs)

  • Docs involved: #856 §3 matrix vs #856 §7 question 6 (open question to self).
  • Conflicting text:

  • 856 §3 matrix row 12: support runs INT + MED

  • 856 §7 OQ-6: "v6 spec §2.5 says support 'collapses to base + patient_context only' for the main conversation LLM call. Does that exclusion apply to extractors too?"

  • Issue: The matrix asserts behavior that the spec text contradicts (or at least does not authorize). #856 already flags this — but the matrix should not state run for INT/MED in support until SD confirms in §7 OQ-6. As written, an implementer who reads only the matrix table will wire extractors on support; an implementer who reads the spec will skip them. Lockstep risk.
  • Resolution: In #856 §3 matrix row 12, replace run | run | skip | skip | skip | skip with cond(OQ-6_resolved) | cond(OQ-6_resolved) | skip | skip | skip | skip AND add a row footnote ("pending SD answer on §7 question 6"). OR resolve OQ-6 in this trio review and update both.

F-10 — Recovery-followup × MED vs §856 spec text disagreement (MINOR, category 5)

  • Docs involved: #856.
  • Conflicting text:

  • 856 §3 matrix recovery_followup row: MED=run, REC=run (2 extractors)

  • 856 §5 "recovery_followup" parallel group: {MED, REC} (consistent)

  • 856 §6 token table: "recovery_followup | 2" (consistent)

  • No conflict found on closer look — listing here so the SD reviewer can mark it satisfied during the review pass. Status: VERIFIED CONSISTENT.

F-11 — Verbatim phrase #18 in #859 §3.2 not anchored in any §2 row (MINOR, category 9: verbatim phrase registry)

  • Docs involved: #859 internally.
  • Conflicting text (#859 §3.2 entry 18):

    "Let me flag this with our care team so we can connect you with the right specialist."

  • Issue: This phrase is listed as a clinical-safety ALWAYS template, but no row in #859 §2 cites this exact wording. The closest is v4.FACTS.008 ("I don't have a precise answer for that — let me flag it for our care team to follow up.") which has different wording. Result: the lockstep test test_verbatim_phrases_survive_loader_assembly will look for entry 18 byte-string in the assembled v6 prompt but no §2 row guarantees its presence in any destination file.
  • Resolution: Either (a) drop entry 18 from §3.2 if it's not a real template, or (b) add a §2 row that pins this exact phrase to a v6 destination. Without one or the other, the CI gate will fail when implemented. Naidu input needed — is this a phrase Curaway wants to lock?

F-12 — Verbatim phrase #20 in #859 §3.2 (I have added these findings to your health record.) — has §2 anchor (MINOR, category 9, no action)

  • Docs involved: #859.
  • Verified: phase.document_review.005 (v2 doc_review:12) pins this verbatim. Status: VERIFIED CONSISTENT.

F-13 — Stage match_review × FIN "stretch" qualification language not in trio (MINOR, category 9)

  • Docs involved: #856 §3.1 ("Budget band + insurance preauth → match qualification (qualified / stretch / mismatched)") references match-qualification state literals.
  • Issue: These three literals (qualified, stretch, mismatched) are not in #859 §3.6 (extractor-coupled state machine literals). If they are extractor-coupled (and the prose implies they are), they belong in the verbatim registry.
  • Resolution: Either (a) flag these as not extractor-coupled (it's UI-only display state) and remove from this finding, or (b) add to #859 §3.6 between entries 40 and 41. SD/Backend input needed.

F-14 — H4 row in #855 §4.1 is a known production hole (MINOR, category 5, but Naidu-relevant)

  • Docs involved: #855 §4.1 row H4.
  • Conflicting text: "H4 | ... | support (no rule fires — pre-match handoff window; see §4.5 row F3)"
  • Issue: H4 is in the happy path table but routes to support. That's inconsistent with the section title; H4 is a known gap, not a happy-path step. Moves a real production behavior (transient awaiting-match-engine window) into the "happy path" reader's mental model.
  • Resolution: Move H4 + H11 to a new §4.6 "Known transient-fallback rows" (or merge into §4.5 fallback rows F3 + F4) so the happy-path table is genuinely happy-only. Recommend keeping as-is for SD review and surfacing to Naidu as Q-O1 already does — no inline edit.

F-15 — Q-C3 in #855 §6 says "Parent §2.6 raised this" but the rationale is also in #855 §5 (MINOR, category 7)

  • Docs involved: #855 internal.
  • Conflicting text: Q-C3 question says "Parent §2.6 raised this; defaulted to clinical 'why before what.' Dr. Naidu re-confirms."
  • Issue: §5 already states the same rationale in the precedence-justification list. Either Q-C3 is a Naidu sanity-check (fine) or it's redundant (drop). Recommend tagging as a low-priority Naidu item in the consolidated list — see §3 below.

F-16 — #856 §4 "Stage-by-stage default addendum" table is not lockstep-validated (MINOR, category 5)

  • Docs involved: #856 §4.
  • Issue: The default-addendum table is presented as a cheat-sheet but is not asserted by any CI gate in either #856 or #859. If a future implementer changes a default in app/agents/knowledge_addendum_resolver.py, the table here can drift silently.
  • Resolution: Out of Phase 0 scope; flag as a Phase 2b implementer's responsibility to add a parity test. Not actionable in this trio pass.

F-17 — #856 §6 token budget numbers depend on recovery_followup REC extractor running (MINOR)

  • Docs involved: #856 §6.
  • Issue: §6 table shows recovery_followup = 2 extractor calls. The §3 matrix shows REC = run with a parallel regex keyword scan that runs even when LLM fails (#856 §5 footnote). The token budget treats REC as a normal Haiku call — but per #856 §2 row 6, REC's failure mode is a regex pass, and per #859 §3.6 entry 42 the keyword list is pinned verbatim. Net effect on budget is negligible; flagging only for completeness.
  • Resolution: No action.

F-18 — procedure_clinical_facts/{procedure_slug}.yaml path appears in two specs (MINOR, category 1: cross-spec stage destinations)

  • Docs involved: #855 §3.3 ("procedure_identification") + #856 §4 (knowledge addendum gating) + #859 §2.21 phase.records_first.007 destination.
  • Conflicting text: All three use procedure_clinical_facts/{slug}.yaml consistently. Status: VERIFIED CONSISTENT. Listed only for completeness.

3. Consolidated Naidu question list (clinical / wording)

Merged dedupe across #855 §6, #856 §7, and #859 §6. 9 unique Naidu items after merge (raw total: 7 from #855 Q-C1..Q-C7 + 0 from #856 + 8 from #859 OQ.01..OQ.08 = 15 raw; 6 merged into 3 consolidated items).

Ranked by impact (clinical-safety risk × frequency of patient exposure):

  1. N-1 (HIGH) — Records-readiness threshold and confidence gating. Source: #855 Q-C1 + #855 Q-C6. Both ask whether medical_status.completion >= 0.7 is the right gate and whether confidence should enter the predicate. Same underlying question — should the records-ready predicate be tighter for high-stakes procedures? Decision needed: flat 0.7 for v6, or procedure-dependent thresholds (oncology 0.9, ortho 0.6)? Confidence inclusion → defer to v7?
  2. N-2 (HIGH) — document_review destination stage. Source: #859 OQ.02. Should phase_contexts/v2/document_review.yaml rules fold into records_collection.guidance (current default) or land in a new sub-state? Impacts how many doc-review rules need re-anchoring during Phase 2a.
  3. N-3 (HIGH) — Stage precedence: procedure_identification before records_collection. Source: #855 Q-C3 + #855 §5. Defaulted to clinical "why before what." Naidu re-confirm.
  4. N-4 (MEDIUM) — Recovery decline terminal vs follow-up. Source: #855 Q-C5 + #855 §3.11 + E8. When patient declines recovery facility (tx_done=T, rec_off=T, rec_acc=F), should the resolver fall to support (current default) or activate a recovery_decline_followup stage?
  5. N-5 (MEDIUM) — Recovery-accepted-with-empty-milestones tone. Source: #855 Q-C7 + #855 §3.12 + E7. When rec_acc=T but milestones=[], should the stage be silent or proactively reassure?
  6. N-6 (MEDIUM) — phase_complete → stage_complete rename + criteria strengthening. Source: #859 OQ.01. Token literal changes; should the underlying criteria wording be strengthened during the move (e.g., "meds confirmed" → "meds confirmed OR explicitly declined")?
  7. N-7 (MEDIUM) — MSO voice-constraint strictness. Source: #859 OQ.05 + #855 Q-C4 (downstream — what happens when MSO declined). For OQ.05: does Naidu want any MSO phrasing in v4mso.005 strengthened during the v4→v6 move, or strict semantic preservation? For Q-C4 (which #855 marks "operational"): clinical confirmation that support fallback for MSO-declined patients is acceptable until coordinator advances state.
  8. N-8 (MEDIUM) — Workflow flag corruption alerting. Source: #855 Q-C2. When consent_given=T but procedure_identified=F (E12), should the resolver alert (currently no — discovery wins, latent state preserved)?
  9. N-9 (LOW) — Recovery response shape uniformity + escalation keyword completeness. Source: #859 OQ.06 + #859 OQ.08. Combined ask: is 5-lines-max correct for both recovery_offer and recovery_followup, and is the escalation keyword list (bleeding, fever, swelling, emergency, infection, pus, dizzy, fainting, chest pain) complete or should post-op-specific keywords be added in Phase 2a?

Items that should NOT need Naidu time (move to SD list — re-categorized):

  • 859 OQ.04 (medication→condition inference list to knowledge file) — that's a Phase 5 architecture move, not a clinical-wording question. Move to SD list as S-7.

  • 859 OQ.07 (helper-consent enforcement as predicate vs guidance) — that's an implementation decision, not a clinical-wording question. Move to SD list as S-6.

4. Consolidated SD question list (product / engineering)

Merged dedupe across the three docs. 7 unique SD items after merge (raw total: 2 from #855 Q-O1..Q-O2 + 8 from #856 §7 + 2 re-categorized from #859 = 12 raw; 5 merged into 2).

Ranked by impact (downstream-block risk × Phase 1/2b coupling):

  1. S-1 (HIGH) — extractors_active threading through orchestrator. Source: #856 §7 item 3. Today triage_agent.py:902 hardcodes "active layer + signal gate." Phase 2b must thread stages.yaml.extractors_active into run_extractors_node. Decision: do this in Phase 2b or push to Phase 3?
  2. S-2 (HIGH) — medical_extractor output schema formalization. Source: #856 §7 item 1. Largest extractor output, not a Pydantic model. Should Phase 2b ship app/schemas/extractor_outputs/medical.py or defer to Phase 5 knowledge work?
  3. S-3 (MEDIUM) — awaiting_match transient stage. Source: #855 Q-O1 + #855 F3. Should the resolver have a dedicated stage for the 0-N-minute records-done-but-match-not-yet-shown window, or keep falling back to support?
  4. S-4 (MEDIUM) — support stage extractor scope. Source: #856 §7 item 6 + finding F-09 above. Does the §2.5 "support collapses to base + patient_context only" rule apply to extractors too, or just to the main conversation LLM call?
  5. S-5 (MEDIUM) — case_role predicate boundary. Source: #855 Q-O2. Confirm caregiver-vs-self affects voice (stages.yaml guidance), not stage choice (predicates). Probably a 1-minute confirm, but flagged because removing it later would be a breaking change.
  6. S-6 (MEDIUM) — Helper-consent enforcement: predicate vs prose. Re-categorized from #859 OQ.07. Should phase.intake.005 ("Block progression until confirmed") become a hard do_not: [advance_until_helper_consent] predicate in stages.yaml, or stay as guidance prose? Lockstep risk if a future implementer relaxes the prose.
  7. S-7 (LOW) — Medication→condition lookup table move. Re-categorized from #859 OQ.04. Move metformin=diabetes, lisinopril=hypertension, CPAP=sleep apnea from base prompt to knowledge/medication_lookup.yaml. Phase 5 scope; flag now to track.

Engineering items NOT needing SD decision (already self-resolving in the corresponding spec):

  • 856 §7 item 2 (intent_extractor gate predicate — deterministic vs LLM-routed) — #856 already recommends deterministic; no SD input needed.

  • 856 §7 item 4 (deterministic fallback for non-recovery extractors) — Phase 2b implementer's call.

  • 856 §7 item 5 (match_review p95 latency dashboard) — observability work, no SD blocker.

  • 856 §7 item 7 (stage_indicator debug card surfaces extractors_active) — nice-to-have, no SD blocker.

  • 856 §7 item 8 (MSO v4→v6 migration regression test) — Phase 2b acceptance criterion, no SD blocker.

Per the constraint "DO NOT rewrite the specs", these are the smallest surgical edits to bring the three docs into alignment. None of them touch SD- or Naidu-judgment material.

#855 (docs/specs/v6-stage-resolver-truth-table.md)

  1. Frontmatter (after "Tracking issue: #836") — add Sibling Phase 0 docs: line linking #856 and #859. (Resolves F-04.)
  2. §2.2 row 1 and §3.2 exit condition — replace "Intent extractor" (capitalized) with intent_extractor (canonical id from #856 §2). (Resolves F-06.)
  3. §6 Q-C3 — drop the standalone Q-C3 row and add a one-line cross-reference into the consolidated Naidu list (this doc §3 N-3). Saves Naidu calendar time. (Resolves F-15.)
  4. §4.1 happy-path table — add a footnote or move H4 + H11 to §4.5/§4.6 fallback rows so the happy-path table is happy-only. (Resolves F-14 — optional, can defer to SD review.)

#856 (docs/specs/v6-stages-extractors-matrix.md)

  1. Frontmatter "Sibling:" line — extend to also reference v6-rule-location-map.md. (Resolves F-04.)
  2. §2 row 6 — add a note: "Short form; agent_name is recovery_checkin_extractor.extract per Langfuse trace continuity (see §8)." (Resolves F-08.)
  3. §2 add a column — "Writes to layer" with the 6 layer names from #855 §2.3. Or add a single bullet paragraph in §2 stating the layer mapping. (Resolves F-07.)
  4. §3 matrix row 12 (support) — change INT and MED cells from run to cond(OQ-6_resolved) and add a row footnote referencing #856 §7 OQ-6. (Resolves F-09.)
  5. §3.1 cell row "match_review × FIN" — confirm whether qualified / stretch / mismatched are extractor-coupled literals; if yes, add them to #859 §3.6. (Resolves F-13 — coordinate with #859 author.)

#859 (docs/specs/v6-rule-location-map.md)

  1. §1 shorthand example — replace stages.yaml:intake.guidance with stages.yaml:procedure_identification.guidance. (Resolves F-02.)
  2. §6 OQ.02 — change "v6 spec lists 10 stages" → "v6 spec lists 12 stages". (Resolves F-01.)
  3. Frontmatter (after "Companion to:") — add Sibling Phase 0 docs: linking #855 and #856. (Resolves F-04.)
  4. §5 CI gate algorithm — add either (a) a new test_stage_id_lockstep_with_truth_table function or (b) an explicit acknowledgement that stage-id and extractor-id lockstep are out of scope for test_lockstep_consistency.py and are covered by sibling tests. (Resolves F-03.)
  5. §3.2 entry 18 (Let me flag this with our care team so we can connect you with the right specialist.) — either drop the entry or add a matching §2 row that pins it to a v6 destination. (Resolves F-11. Needs Naidu input.)
  6. §6 OQ.04 and OQ.07 — re-tag as SD/engineering questions (see §4 above S-6 and S-7), or leave in §6 with a note "engineering question, not clinical." (Recategorization, light touch.)

6. Notes for the lockstep CI gate (informational)

When implemented, the lockstep gate should:

  1. Read all three Phase 0 docs. Currently #859 §5 reads only #859. Recommend extending parse_rule_table() to also parse_truth_table_stages() from #855 §3 and parse_extractor_catalog() from #856 §2.
  2. Assert stage-id intersection is the canonical 12. No spec can reference a stage_id outside the truth-table list.
  3. Assert extractor-id intersection. Every extractor mentioned in any spec (including informal references) is in #856 §2 catalog.
  4. Assert verbatim phrase coverage. Every entry in #859 §3 maps to at least one §2 row.
  5. Surface the consolidated Naidu and SD lists at PR time. A small CI message ("3 sibling Phase 0 docs detected — please review consolidated open-question list at docs/specs/v6-trio-consistency-findings.md §3 and §4 before requesting Naidu/SD review") would save calendar time on every Phase 0 / Phase 2a re-spin.

End of v6 Trio Consistency Findings.