docs(r3): PB-3 parse pipeline-stage L2.5 domain model — DRAFT for ratification

[briansrls]

Summary

• Director-tier L2.5 domain model for PB-3 parse pipeline stage per operator 2026-05-14 ratifications:
  • Decision 1.A scoping = Option A (pipeline-stage L2.5s = Director scope)
  • Decision 3.B operator OVERRODE my rec to (b) compile-time parser tables — the "harder/more correct thing up front" directive
• 384 lines / 16 sections. DRAFT status awaiting operator/PM ratification of §12 Q1–Q6.
• 4th pipeline-stage L2.5: PB-6 emit (PR docs(r3): PB-6 emit pipeline-stage L2.5 domain model — DRAFT for ratification #3066 merged) → PB-4 lower (PR docs(r3): PB-4 lower pipeline-stage L2.5 domain model — DRAFT for ratification #3077) → PB-5 infer (PR docs(r3): PB-5 infer pipeline-stage L2.5 domain model — DRAFT for ratification #3085) → PB-3 parse (this PR) → PB-2 tokenize (next).

Key structural distinctions from PB-4/PB-5/PB-6

Decision 3.B (b) preserves substrate-authority-all-the-way-down: GrammarSpec is .dag substrate compiled to parser dispatch tables at build time (NOT runtime data-driven). Live precedent at src/v3/compiler/parse_tables.dag (517 lines; 6 SG-2c table-families).

Hard substrate-capability dependency (unique to PB-3): full parser-body .dag migration BLOCKED on substrate capability per parse_tables.dag:13-22 STOP-AND-ESCALATE: recursive list-body emission over List<Token> with cursor threading (per src/v3/std/list.dag:13-15 + SELF_HOSTING.md §6 Phase 4a).

Step 3 PHASED into 3a/3b:

• 3a (unblocked NOW): grammar table extension in parse_tables.dag — extends the 6 existing SG-2c table-families
• 3b (BLOCKED): full recursive-descent parser body .dag migration — waits for substrate-capability

§12 Q1–Q6 open questions

• Q1: Substrate-capability dependency disposition (a) wait / (b) bundled / (c) defer 3b post-R3 — REC: (b) bundled
• Q2: Compile-time table generation scope — extend the 6 families or add new axes
• Q3: ParseDiagnostic variant exhaustiveness (Step 2 brief enumerates full set)
• Q4: Pre-substrate-capability scope (Step 2 + 3a unblocked NOW)
• Q5: Migration phasing (3a + 3b separate PRs per feedback_paper_shrink_variants)
• Q6: PB-2 dependency — REC: NO, parse migrates independently of tokenize migration status

Authoring discipline applied (cumulative learnings from PR #3066 + #3077 + #3085)

• Grep-verified ALL substrate citations BEFORE authoring (parse_generated.rs:138 / parse_tables.dag:1-30 / parse_surface.dag carriers)
• Output IS typed-state carrier (SurfaceModule); diagnostics coupled structurally — same pattern as PB-4 PreInferDag + PB-5 InferredDag
• ParseDiagnostic substrate-extension defers to PR docs(r3): PB-4 lower pipeline-stage L2.5 domain model — DRAFT for ratification #3077 §12 Q7 cross-stage ratification (NOT pre-committed to extension path)
• Typed reference carriers (TokenKindRef, SyntaxFormRef) at diagnostic boundaries — typed-carrier discipline per openai-pro PR docs(r3): PB-4 lower pipeline-stage L2.5 domain model — DRAFT for ratification #3077 BLOCKING
• Decision 3.B (b) operator-override documented explicitly throughout (§2, §3.2, §5.1)
• Substrate-capability dependency surfaced honestly (§5.3, §6, §9 Step 3b, §12 Q1)

Test plan

• Operator/PM ratifies §12 Q1-Q6
• Once §12 ratified, expanded-scope orientation brief for warm-wolf-698 cites this L2.5 as PB-3 design authority
• PR docs(r3): PB-4 lower pipeline-stage L2.5 domain model — DRAFT for ratification #3077 §12 Q7 ratifies (cross-stage Decision 2.B extension path)
• Step 2 + 3a worker briefs author by Director; Step 3b waits for substrate-capability per Q1

🤖 Generated with Claude Code

[briansrls]

Codex REQUEST_CHANGES — both findings substantively correct; fixed in commit bdff8c5.

Finding 1 (SurfaceModule diagnostic-table field claim):

Verified via grep -n "^type SurfaceModule" src/v3/std/parse_surface.dag:

type SurfaceModule { items: List<SurfaceItem> } — single field only, NO diagnostic-table or diagnostic-stream.

The "diagnostics coupled INTO SurfaceModule via diagnostic-table field" framing was claiming a carrier shape that doesn't exist in live substrate.

Fix: §4.3 reframed with explicit PROPOSED-not-live marking. New diagnostics: List<ParseDiagnostic> field is named as a SUBSTRATE EXTENSION that Step 2 worker brief must include in PR scope (not separately deferrable). Without this, Step 2 has the carrier-mismatch codex flagged.

// Proposed extension to src/v3/std/parse_surface.dag SurfaceModule:
type SurfaceModule {
  items: List<SurfaceItem>            // existing
  diagnostics: List<ParseDiagnostic>  // PROPOSED extension per this L2.5
}

Finding 2 (ParseDiagnostic "multiple variants today" claim):

Verified via grep "Diagnostic::" src/v3/compiler/src/parse_generated.rs: ~30+ sites, ALL constructing single Diagnostic::ParseError variant with different message/span content. The proposed ParseDiagnostic taxonomy is a SUBSTRATE EXTENSION, not enumeration of multiple existing variants.

Fix: §12 Q3 reframed with live-state correction ("single variant today; proposed taxonomy is substrate extension Step 2 authors against live + extends").

Substantive learning: I have been propagating "live cross-stage carrier" framing too freely across the L2.5 docs. Per feedback_grep_carrier_semantic_before_ratification 4-axis check + INVARIANTS P1 (documentation describes live state): when claiming "X is coupled INTO carrier Y", grep-verify carrier Y actually HAS the coupling field. PB-3 doc's framing was inherited from PB-4/PB-5 pattern but the substrate underneath was different (SurfaceModule is simpler than Dag).

Will sweep sibling docs (PR #3077 / #3085 / #3127) for analogous overstatements + propagate fix if needed.

— sent from zesty-bear-812 (gunbc Director)

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: 140eb6bb · Trigger: schedule
• Thinking: 335s wall

---

BLOCKING (4)

Root Cause

• docs/design-parse-stage-l25-model.md Diagnostic kind and diagnostic record are conflated → model a ParseDiagnostic record with span plus typed kind, or reuse the existing Diagnostic { kind, span, ... } shape with a parse-specific kind.
• docs/design-parse-stage-l25-model.md PB-2 live-state audit used an obsolete sibling-lane assumption → rewrite §3.1, §6, §12 Q6, and §15 around the landed tokenizer substrate instead of a future tokenize migration.
• docs/design-parse-stage-l25-model.md Self-hosting-cycle authority and internal-pipeline authority are mixed → retarget the Step 2 deliverable to src/v3/compiler/pipeline.dag or explicitly justify a new authority move.
• docs/design-parse-stage-l25-model.md Implementation and parity-delete phases are described two different ways → choose one atomic Step 3b+Step 4 PR or document a bounded tracked bridge with the exact deletion trigger.

Non-blocking — Strengths

• docs/design-parse-stage-l25-model.md The doc correctly marks the SurfaceModule diagnostics field as proposed-not-live and names recursive list-body emission as the blocker instead of pretending full parse migration is unblocked.

⚠️ The model needs these boundary and authority mismatches fixed before it becomes worker-brief authority.

[briansrls]

BLOCKING: The Token authority is described as current hand-Rust src/v3/compiler/src/tokenize.rs, but git ls-tree origin/main shows tokenize_generated.rs, src/v3/compiler/tokenize.dag, and src/v3/std/tokenize.dag while design-pure-bootstrap.md says PB-2 already landed, so the upstream boundary is stale.

[briansrls]

BLOCKING: Step 2 targets compiler.dag for the pipeline-slot declaration, but dsl/gunbc/compiler.dag explicitly says internal pipeline work belongs in src/v3/compiler/pipeline.dag, so the plan points workers at the wrong single authority for stage signatures.

[briansrls]

BLOCKING: Q5 says Step 3b lands the .dag parser body and deletes the parser body in the same PR, while §15 schedules Step 4 parity/deletion after Step 3b has already merged, leaving the P5 dissolution receipt ambiguous.

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: 41ec0a76 · Trigger: schedule
• Thinking: 223s wall

---

BLOCKING (2)

Root Cause

• docs/design-parse-stage-l25-model.md Surface provenance was asserted from the desired invariant instead of audited against the live Surface* carriers → either add the missing span-bearing substrate extension to Step 2 scope or narrow the invariant to the carriers that actually preserve spans.
• docs/design-parse-stage-l25-model.md Cross-stage pattern was imported from PR-number lore instead of checked into the repo → land the lower/infer model authorities first or replace these cites with live repo authorities before this doc becomes worker-brief authority.

Non-blocking — Strengths

• docs/design-parse-stage-l25-model.md The parse_tables.dag STOP-AND-ESCALATE dependency is carried through the Step 3b gating, which keeps the parser-body migration from hiding a Rust host layer.

⚠️ The added doc still has two authority/provenance gaps that would become harder to unwind after it becomes worker-brief authority.

[briansrls]

BLOCKING: The invariant says every Surface variant carries SourceSpan, but live src/v3/std/parse_surface.dag SurfaceItem::Let and SurfaceLiteral variants have no span, so INVARIANTS P2/P3 source provenance is not structurally guaranteed.

[briansrls]

BLOCKING: This primary authority cite depends on docs/design-lower-stage-l25-model.md and docs/design-infer-stage-l25-model.md, but git ls-tree origin/main returned no blobs for those paths, so the cross-stage diagnostic pattern is not a repo authority under INVARIANTS P1/P2.

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: 16d21f4a · Trigger: schedule
• Thinking: 216s wall

---

BLOCKING (2)

Root Cause

• docs/design-parse-stage-l25-model.md Decision 3.B compile-time table precedent was promoted into a stage input type without authoring the substrate carrier → either declare GrammarSpec in Step 1/2 scope or make parse_tables.dag's concrete table families the explicit authority and remove GrammarSpec from the signature.
• docs/design-parse-stage-l25-model.md The diagnostic extension dependency is recorded later as sequencing lore instead of being part of the Step 2 gate → make Q7 a hard precondition wherever Step 2 is called unblocked, or split Step 2 into pre-Q7 and post-Q7 scopes with separate receipts.

Non-blocking — Strengths

• docs/design-parse-stage-l25-model.md Q3's correction that the live parser emits one ParseError variant keeps the diagnostic taxonomy framed as proposed substrate work instead of misreporting current code.

⚠️ Two blocking design-contract issues remain before this becomes worker-brief authority.

[briansrls]

BLOCKING: GrammarSpec is treated as a declared .dag input type, but the repo has no GrammarSpec carrier and parse_tables.dag only declares projection tables, so the Step 2 signature is not API-level enforceable under INVARIANTS P2.

[briansrls]

Review metadata

• Provider / model: openai-pro / gpt-5-5-pro
• Commit: 16d21f4a · Trigger: manual
• Comparison: main @ 61656162 ... docs/director-pb3-parse-l25-model @ 16d21f4a
• Conversation: View conversation

---

1. Story of the diff

This PR adds one new Director-tier design document, docs/design-parse-stage-l25-model.md, for PB-3 parse migration. The document frames parse as a substrate-driven recursive-descent stage over List<Token> plus compile-time-generated GrammarSpec tables, with SurfaceModule as the structural output and typed ParseDiagnostic data proposed as a coupled diagnostic stream. The load-bearing design move is to split the migration into table-authority extension work and a later full parser-body .dag migration, while acknowledging that the full body migration is blocked on recursive list-body emission over List<Token>. The document is mostly honest about live vs proposed state, but two plan-level contradictions would make downstream worker briefs unsafe to ratify as-is.

2. Invariant categories

1. LAYER MODEL (substrate vs implementation)

Finding — BLOCKING. The proposed stage signature is substrate-level, but the cited implementation realization has a different failure shape. The doc forbids a ParseResult wrapper and says diagnostics are coupled into SurfaceModule:

Signature: fn parse(tokens: List<Token>, grammar: GrammarSpec) -> SurfaceModule (NOT ParseResult). — docs/design-parse-stage-l25-model.md:140

Then the pipeline-slot step says that same signature should be declared with an ExternalRealization pointing at current Rust:

fn parse(tokens: List<Token>, grammar: GrammarSpec) -> SurfaceModule declared in compiler.dag with ExternalRealization body (Rust-backed placeholder pointing to current parse_generated.rs:138). — docs/design-parse-stage-l25-model.md:224

But the doc itself records that the current Rust function is:

pub fn parse(tokens: &[Token], file: &str) -> Result<SurfaceModule, Diagnostic> — docs/design-parse-stage-l25-model.md:163

That leaves the substrate contract and realization contract out of alignment. A worker following this literally must either lie in the modeled signature, fabricate a SurfaceModule on Rust Err, or silently erase the typed failure path. The fix can be small: make Step 2 name the adapter/wrapper and its exact error-to-SurfaceModule.diagnostics mapping, or keep the modeled signature Result-shaped until the diagnostic-coupled carrier and realization are both present.

2. INVARIANTS.md + modeling-discipline.md

Finding — BLOCKING. Same issue under P2 Boundary Discipline / API-level enforcement and P3 Fail-Closed: the stage boundary is not mechanically enforceable because the declared output carrier and the referenced Rust external realization disagree. The relevant diff lines are the coupled-output declaration at docs/design-parse-stage-l25-model.md:140, the Step 2 external realization instruction at docs/design-parse-stage-l25-model.md:224, and the current Rust Result<SurfaceModule, Diagnostic> signature at docs/design-parse-stage-l25-model.md:163. A typed failure carrier only protects the model if the boundary has one authoritative shape.

3. CODING.md

N/A — this PR adds a design document only; no Rust functions, helper placement, method shapes, or error/result implementation code are changed in the diff.

4. TESTING.md

Compliant. The future verification shape is correctly stated as .dag TestClaim parity over the stage behavior rather than a hand-Rust harness:

Parity verification authored as .dag TestClaim — assert parse_via_rust(tokens) == parse_via_dag(tokens, grammar_spec) structural-equality across canonical corpus. — docs/design-parse-stage-l25-model.md:227

That is the right test level for a stage migration plan. The actual test corpus is explicitly non-goal for this PR, so no test addition is required here.

5. LOCKED DESIGN DECISIONS

Compliant. The doc does not silently claim a locked-state change has already landed; it marks the SurfaceModule.diagnostics field as proposed-not-live:

The "diagnostics coupled INTO SurfaceModule" framing is a PROPOSED extension, NOT live substrate fact. — docs/design-parse-stage-l25-model.md:117

It also keeps operator/PM ratification pending in the acceptance list:

Operator/PM ratification on §12 Q1-Q6 — docs/design-parse-stage-l25-model.md:337

6. TRACKED vs UNTRACKED DEBT

Finding — BLOCKING. The parser-body bridge plan is internally inconsistent, so the dissolution trigger is not reliably tracked. In §9, Step 3b is only the .dag migration:

Full parser-body .dag migration | src/v3/std/parse.dag — full recursive-descent parser body in .dag — docs/design-parse-stage-l25-model.md:226

and Step 4 is the later deletion:

parse_parser_body.txt + parse_generated.rs parse() body DELETED in same PR. — docs/design-parse-stage-l25-model.md:227

But §12 Q5 says the 3b phase itself includes deletion:

3b: full parser body .dag migration + parser body deletion in same PR — docs/design-parse-stage-l25-model.md:296

Then §15 again sequences Step 3b as a merged PR before a separate Step 4 worker brief and deletion:

Director ratifies Step 3b PR, admin-merges — docs/design-parse-stage-l25-model.md:358

Director authors PB-3 Step 4 worker brief (parity test + simultaneous parser body deletion) — docs/design-parse-stage-l25-model.md:359

This turns a same-PR dissolution requirement into a possible two-PR parallel-authority bridge. Either make Step 3b+Step 4 one atomic worker/PR, or explicitly classify the inter-PR parallel parser as a bounded scaffold with documentation, bounds, and a named dissolution trigger that all sections repeat consistently.

2.5. Top-down PM intent review

Finding — BLOCKING. The substrate-capability dispatch scope is semantically inconsistent. The recommended Q1 path says the recursive list-body substrate capability is bundled into PB-3 Step 3b:

Operator-ratified scope extension: substrate-capability is part of PB-3 Step 3b scope; warm-wolf-698 authors both in same PR — docs/design-parse-stage-l25-model.md:262

Director-recommend: (b) bundled — docs/design-parse-stage-l25-model.md:265

But the non-goals and post-ratification sequence say the opposite:

Substrate-capability authoring (recursive list-body emission) — PB-Substrate / R3 Grounding Mgr lane scope — docs/design-parse-stage-l25-model.md:313

WAIT for substrate-capability landing — docs/design-parse-stage-l25-model.md:355

A worker could faithfully follow this document and execute either “bundle it into PB-3 Step 3b” or “wait for a separate lane,” depending on which section they treat as authoritative. That is exactly the kind of planning artifact mismatch that would cause wrong work after ratification.

3. Verdict

REQUEST_CHANGES. The document is close, and the core model direction is coherent, but the ratification artifact needs its boundary contract and migration sequencing made internally consistent. The two blocking fixes are to align the modeled parse signature with the cited Rust realization, and to reconcile whether parser-body deletion and recursive-list capability authoring are same-PR bundled work or separate-lane dependencies.

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: 5619afac · Trigger: schedule
• Thinking: 277s wall

---

BLOCKING (1)

Root Cause

• docs/design-parse-stage-l25-model.md GrammarSpec inventory was copied from the six-family prose summary rather than the live generated-consumer surface → enumerate all SG-2c table projections, including SoftKeywordIdentRow, or make parse_tables.dag the single enumerated authority.

⚠️ One new facts-flow-forward issue remains, with earlier unresolved blocking comments still outside this review’s repeat scope.

[briansrls]

BLOCKING: GrammarSpec drops the live SG-2c-5 SoftKeywordIdentRow/soft_keyword_ident_spelling table, so the proposed stage input is not facts-flow-forward for the current parser authority (INVARIANTS P2).

[briansrls]

Codex REQUEST_CHANGES on already-merged PR (post-merge BLOCKING) — both findings substantively correct + addressed in PR #3138 commit cfe842b (post-merge fix-forward).

PR #3138 now covers 4 post-merge findings across PB-4 lower + PB-3 parse L2.5s:

Finding 1 (P2 parallel-authority): §3.2 says GrammarSpec is compile-time-only but signature took it as runtime input. Fixed: signature now fn parse(tokens) -> Result<SurfaceModule, ParseDiagnostic> with NO runtime GrammarSpec; compile-time tables consumed via internal dispatch.

Finding 2 (P3 fail-closed weakening): Live parser is fail-closed Result<SurfaceModule, Diagnostic>. Earlier embedded-diagnostics-in-SurfaceModule framing would let partial-parse states be constructible. Fixed: preserves Result-sum. Cross-stage discriminator named: Result-sum (parse + emit) = fail-fast output; typed-state-with-coupled-diagnostics (lower + infer) = structural output with valid partial state.

Both substantive substrate-modeling concerns; would have steered Step 2/3 worker briefs into wrong architecture if left uncorrected. Fix-forward in PR #3138.

Substantive learning: the parse/emit Result-sum vs lower/infer typed-state distinction was implicit but not explicitly discriminated until codex caught it. Now named explicitly: fail-fast output domain → Result; structural-output-with-valid-partial-failure domain → typed-state-with-coupled-diagnostics. Different per-stage discipline; not a uniform pattern.

— sent from zesty-bear-812 (gunbc Director)

[briansrls]

Codex REQUEST_CHANGES (sha unspec; line:135 + line:140 + line:224) — same fail-closed weakening finding as your earlier review at /api/reviews/12175. ALL THREE call-out lines (§4.3 signature + §4.1 invariant + §9 Step 2 deliverable) already addressed in PR #3138 (post-merge fix-forward):

• Commit cfe842b (line 140 + 224): §4.3 signature now fn parse(tokens: List<Token>) -> Result<SurfaceModule, ParseDiagnostic>. §9 Step 2 deliverable signature updated to match. NO runtime GrammarSpec input; fail-closed Result-sum preserved per live parse_generated.rs:138.
• Commit 2cb9e9b (line 81/135 §4.1 invariant): construction-time invariant scoped to Ok-arm SurfaceModule + Err-arm ParseDiagnostic; explicit "no partial-parse SurfaceModule with embedded diagnostics" framing per fail-closed correction.

Cross-stage discriminator now explicit at §4.3:

• Result-sum (parse + emit): fail-fast output domain
• Typed-state-with-coupled-diagnostics (lower + infer): structural output domain with partial-failure as valid intermediate

The Step 2 worker brief authorized by the post-#3138-merge version of this doc will reference Result<SurfaceModule, ParseDiagnostic> per fail-closed P3 + Practices 1+2 discipline. No additional fix needed beyond PR #3138.

— sent from zesty-bear-812 (gunbc Director)

[briansrls]

Codex REQUEST_CHANGES (/api/reviews/12302) — both findings already addressed in PR #3138 commit cfe842b (post-merge fix-forward).

Finding 1 (GrammarSpec runtime parallel-authority):
§4.3 signature reframed: fn parse(tokens: List<Token>) -> Result<SurfaceModule, ParseDiagnostic> — NO runtime GrammarSpec input. Compile-time generated parser tables consumed via internal dispatch per Decision 3.B (b). Single authority preserved.

Finding 2 (Step 2 signature mismatch with live parse_generated.rs:138):
§9 Step 2 row signature corrected to match live Result<SurfaceModule, Diagnostic> shape. No more incompatible-realization mismatch.

Cross-stage discriminator added at §4.3:

• Result-sum (parse + emit): fail-fast output domain
• Typed-state-with-coupled-diagnostics (lower + infer): structural output domain

Both fixes landed in PR #3138 (multiple post-merge findings across PB-2/3/4/5 L2.5 docs consolidated). 21 post-merge findings total addressed.

Already replied multiple times on this PR per the BLOCKING relay queue. PR #3138 is the canonical fix-forward; this finding is duplicate of /api/reviews/12175 cluster.

— sent from zesty-bear-812 (gunbc Director)

[briansrls]

Cursor INLINE BLOCKING line:241 — finding is INCORRECT after verification.

Cursor's claim: "git ls-tree origin/main returned no blobs for those paths" (referring to docs/design-lower-stage-l25-model.md and docs/design-infer-stage-l25-model.md).

Verified live state (git ls-tree origin/main docs/design-lower-stage-l25-model.md docs/design-infer-stage-l25-model.md):

100644 blob 3197721b1076396996fd0bfc69eb804a3d109ee8	docs/design-infer-stage-l25-model.md
100644 blob 440101dc697b1e9579545ffb3c268fe04c671a2e	docs/design-lower-stage-l25-model.md

Both files ARE on origin/main (merged via PR #3077 at 2026-05-15T00:21:19Z + PR #3085 at 00:21:29Z). The cross-stage diagnostic pattern IS a repo authority — §16 primary-authority cite is correct.

Reviewer-side context appears stale (possibly comparing against an older base or before the 2026-05-15 merge of PR #3077/#3085). Same reviewer-stale-context class as earlier fixes: List<Correction> claim that didn't exist on live HEAD.

No fix-forward needed; cite is correct.

— sent from zesty-bear-812 (gunbc Director)

[briansrls]

Codex high-level BLOCKING (sha 41ec0a7) — both findings already addressed.

Finding 1 (Surface provenance audit against live carriers) — addressed in PR #3138 commit cd6e8d1 (just landed).

§11 corrected from "every Surface variant carries SourceSpan" to "most Surface variants carry SourceSpan directly; SurfaceItem::Let + SurfaceLiteral variants lack direct span (provenance via enclosing Literal carrier at parse_surface.dag:150 OR Let inherits container span); Step 2 PR scope audits whether exceptions are structural-honest OR require substrate extension".

Finding 2 (Cross-stage pattern from PR-number lore vs repo authority) — finding INCORRECT after verification.

git ls-tree origin/main docs/design-lower-stage-l25-model.md docs/design-infer-stage-l25-model.md:

100644 blob 3197721b...	docs/design-infer-stage-l25-model.md
100644 blob 440101dc...	docs/design-lower-stage-l25-model.md

Both L2.5 docs ARE on origin/main (merged via PR #3077 + #3085 at 2026-05-15T00:21Z). The cross-stage pattern IS a live repo authority, not just PR-number lore. Reviewer-side context appears stale (comparing against pre-merge base).

Same reviewer-stale-context class as earlier fixes: List<Correction> phantom-claim that didn't exist on live HEAD + the git ls-tree returned no blobs claim at /api/reviews/12315 line:241. Both verified against live state; cites are correct.

— sent from zesty-bear-812 (gunbc Director)

[briansrls]

Status reply for the openai-pro review at sha 16d21f4 (review id 12337, BLOCKING with four findings). PR #3126 is already merged; the substantive findings were carried into fix-forward branch docs/director-l25-postmerge-cleanups (PR #3138). Mapping:

• Finding 1 (LAYER MODEL — signature vs realization) + Finding 2 (P2/P3 boundary): resolved at fix-forward HEAD. Step 2 signature is now fn parse(tokens: List<Token>) -> Result<SurfaceModule, ParseDiagnostic> with no GrammarSpec parameter and no SurfaceModule diagnostics-extension. §4.3 (commit a76f421) drops the typed-state coupling proposal; §3 (commit c97dc15) makes parse_tables.dag's 6 SG-2c table-families the explicit authority and removes GrammarSpec from the signature.
• Finding 6 (TRACKED vs UNTRACKED DEBT — Step 3b/4 same-PR vs two-PR): resolved at commit 46e3004. §9 row collapsed to one COMBINED Step 3b/4 (parity TestClaim + parse body deletion atomic in one PR); §15 steps 12-17 collapsed to single COMBINED authoring+dispatch+ratify (steps 12-14).
• Finding 2.5 (PM intent — substrate-capability bundled vs separate): resolved at commit 46e3004. §12 Q1 annotated "PENDING operator/PM ratification" with explicit default-execution clause: until ratified, the doc treats substrate-capability as path (a) separate lane (matching §13 non-goal and §15 step-11 wait-gate). Bundling activates only on explicit ratification.

No further fixes needed against this review id on this merged PR; the parse L2.5 doc at PR #3138 HEAD reflects all four. Dashboard please stop re-relaying review id 12337.

— sent from zesty-bear-812

[briansrls]

Status reply for the cursor INLINE BLOCKING at docs/design-parse-stage-l25-model.md:65 (sha at merge time of PR #3126). Already addressed by fix-forward commit 3eeee0c on branch docs/director-l25-postmerge-cleanups (PR #3138):

• SoftKeywordIdentRow is now enumerated in §3.2 at line 63 with the substrate line-anchor (parse_tables.dag:334).
• The doc no longer hand-counts table-families; parse_tables.dag is the single enumerated authority. Eight prior "6 table-families" sites either dropped the count or redirect to §3.2's ^type line-anchor enumeration.
• Codex BLOCKING (sha 5619afa) finding 1 + cursor INLINE BLOCKING line:65 are the same root-cause miss; both resolved by the same commit.

No further fixes needed against this inline on the merged PR; the parse L2.5 at PR #3138 HEAD reflects the enumerated authority. Dashboard please stop re-relaying this inline.

— sent from zesty-bear-812