docs(audit): R3 R4-carve substrate-readiness audit (C1/C2/C3 — Director-greenlit (α) carve-promotion-IN-R3)

[briansrls]

Summary

Per Director ratification at gunbc#846 #issuecomment-4412330468 (2026-05-09): RATIFIED PM (α) carve-promotion-IN-R3 recommendation per operator's 2026-05-09 framing.

PM substrate-readiness audit before Cluster F carve-promotion amendment authoring.

Findings

Carve	Gate	Substrate state	Recommendation
C1 parallelism lens	#81	substrate-ready	Full carve-promotion to R3
C2 effect_enumeration lens	#82	MIXED — 4c is P1 substrate intro, not bounded port	Director disposition: (a) full + 4c canvas OR (b) γ stub
C3 opt-in iteration parallelism via lens application	#95	substrate-ready conditional on C1	Full carve-promotion (cascade post-C1)

PM recommendation: (a) for C2 per operator strict-zero framing.

Cluster F sequencing folder

All three carve gates are lens-producer-retirement work (Director's structural framing). Fold into existing Cluster F (T-LP-Retirement):

• α: BB-2: Implement per-node corpus test generation with level 1a/1b support #81 parallelism walker port (M-sized; substrate-ready)
• β: Blue Team Lane 1: RF-B1, SDLC-1 through SDLC-4 #82 effect_enumeration per disposition
• γ: Compiler lowerer cleanup #95 demo (cascade post-α)

Open questions for Director ratification (§5)

1. C2 Blue Team Lane 1: RF-B1, SDLC-1 through SDLC-4 #82 disposition: (a) full + 4c canvas, or (b) γ stub interim?
2. Cluster F internal sequencing: BB-2: Implement per-node corpus test generation with level 1a/1b support #81+Blue Team Lane 1: RF-B1, SDLC-1 through SDLC-4 #82 parallel-dispatchable vs serial?
3. R4 carve doc dissolution: amend docs/r4-carve-out-routing.md to remove C1/C2/C3?

Sequencing

PR #2361 + #2362 land first under Director ratification (Cluster M scope). This audit's recommendations turn into a separate carve-promotion PR (Task 12) that:

• Amends docs/r3-program-plan.md §1.5/§1.8 to reclassify BB-2: Implement per-node corpus test generation with level 1a/1b support #81/Blue Team Lane 1: RF-B1, SDLC-1 through SDLC-4 #82/Compiler lowerer cleanup #95
• Amends docs/r4-carve-out-routing.md to remove C1/C2/C3
• Updates Cluster F sequencing folder

Authority + parents

Cites operator framing 2026-05-09 + Director ratification #846 #issuecomment-4412330468 + r4-carve-out-routing.md C1/C2/C3 + r3-program-plan.md §1.5/§1.8 + velocity-walk audit at PR #2358 as parents.

Test plan

• No code changes — docs-only audit
• Cites parent authority docs (does not restate)
• All claims grep-verified at HEAD (substrate state, carve doc text, file imports)

🤖 Generated with Claude Code

[briansrls]

Review metadata

• Provider / model: openai-pro / gpt-5-5-pro
• Commit: c3a4b110 · Trigger: manual
• Comparison: main @ cf1d5230 ... docs/r3-r4-carve-substrate-readiness-2026-05-09 @ c3a4b110
• Conversation: View conversation

---

1. Story of the diff

This PR adds a single audit document, docs/audit/r3-r4-carve-substrate-readiness-2026-05-09.md, whose job is to reclassify the R4 C1/C2/C3 carve-outs against R3/PB-0 closure. The document argues that C1’s workflow_parallelism.rs lane is already substrate-backed and can be promoted to Cluster F, that C3’s lens-application demonstration is substrate-ready once C1 lands, and that C2 is the only cliff because caller-side effect-set pinning still needs new substrate authoring. The load-bearing mechanism is the audit’s routing: it turns “R4 carve” items into Cluster F sub-phases, with C2 split between full R3 substrate introduction and a possible .dag stub fallback at docs/audit/r3-r4-carve-substrate-readiness-2026-05-09.md:99-103 and :130-134.

2. Invariant categories

1. LAYER MODEL — N/A. The diff does not modify dag.rs, .dag substrate definitions, or Rust substrate mirrors; it is a docs-only audit. The one substrate-sensitive part is the C2 4c routing claim, covered under invariant/modeling discipline below.
2. INVARIANTS.md + modeling-discipline.md — Finding.

Finding 1 — P1 Modeling Faithfulness / substrate-fact introduction procedure.

docs/audit/r3-r4-carve-substrate-readiness-2026-05-09.md:87 says: “4c is the cliff. Per INVARIANTS.md P1 procedure, substrate-fact-introduction requires:”, then :88-91 lists only “Confirmed bridge consumer,” “Carrier shape ratification,” “Worker brief authoring,” and “Substrate-introduction PR.” That is not the P1 substrate-fact-introduction procedure: the load-bearing checks are whether the fact has an existing DAG ancestor, whether the shape is a coproduct or coordinate, and whether the fact is substrate-declared vs lens-extensible. chatgpt-review-e3c6c4c6-f663-49…

Why it matters: this audit is meant to authorize C2’s new caller-side effect-set pinning carrier. If it replaces the modeling checks with process gates, a future worker can satisfy the audit without proving the new carrier is actually the right substrate fact. This should say these four items are dispatch/process requirements, and separately require the actual P1 modeling checks before introducing the carrier.

Finding 2 — Documentation Describes Live State / single authority.

docs/audit/r3-r4-carve-substrate-readiness-2026-05-09.md:4 says the audit is “per Director ratification” and that the Director “RATIFIED PM (α) carve-promotion-IN-R3 recommendation.” But the same document keeps C2 unresolved: :19 says “Director disposition needed,” :95 says “Recommendation — Director disposition needed,” and :138-140 still frames C2 as an “Open questions for Director ratification.” Repository docs are supposed to read as the current specification, not preserve competing decision states. chatgpt-review-721740e6-709d-49…

Why it matters: Cluster F dispatch cannot tell whether path (a) is now ratified or whether the γ stub remains an open alternative. If α is ratified, collapse the C2 text to the selected path and retire §5’s open question; if it is not ratified, remove the ratified/greenlit language.

1. CODING.md — N/A. No Rust code, helpers, functions, methods, or error/result shapes are introduced.
2. TESTING.md — N/A. This is a docs-only audit and does not change executable behavior or a source-audit ratchet. No test addition is required for the diff as written.
3. LOCKED DESIGN DECISIONS — N/A. The diff references Director ratification and existing design surfaces, but does not directly alter a locked thesis/design decision. The live-decision ambiguity is covered under invariant documentation discipline above.
4. TRACKED vs UNTRACKED DEBT — Compliant, aside from the decision-state issue above. The audit names C2 4c as the substrate cliff at docs/audit/r3-r4-carve-substrate-readiness-2026-05-09.md:74 and :82, bounds the full-promotion path with a concrete canvas path at :99, and bounds the stub alternative with the trigger “until 4c lands” at :101. The out-of-scope census work is also bounded as a separate follow-up artifact at :161-163; no new scaffold is actually introduced by this diff.

3. Verdict

REQUEST_CHANGES. The audit is directionally useful and correctly isolates C2 as the only substantive substrate cliff, but the checked-in document currently has two authority problems: it misstates the P1 substrate-introduction procedure and simultaneously treats C2 as both ratified and still awaiting ratification. Those are docs-only fixes, but they are load-bearing for future substrate dispatch.

[briansrls]

@briansrls (openai-pro REQUEST_CHANGES on sha c3a4b110): both findings accepted + fix pushed at e54d880b5.

Finding 1 — P1 substrate-fact-introduction procedure misrepresented:
§2.3 prior framing folded dispatch/process gates into the "P1 procedure" label. Verified against INVARIANTS.md:94-129 — actual P1 procedure has 3 modeling checks: DAG-ancestor (line 100) / coproduct-vs-coordinate (line 109) / primitive-vs-lens-extensible (line 120). My 4 items (confirmed bridge consumer / carrier shape ratification / worker brief authoring / substrate-introduction PR) are dispatch/process gates, not modeling checks.

Fix: §2.3 now explicitly separates Layer 1 (P1 modeling checks per INVARIANTS.md:100-128 with line refs) and Layer 2 (dispatch/process gates). Layer 1 must surface in canvas authoring before carrier shape ratification. Both layers required for carve-promotion to authorize a substantive substrate addition.

Finding 2 — Decision-state ambiguity ((α) ratified vs C2 open):
Doc said "per Director ratification (α)" but kept C2 as "Director disposition needed." Cluster F dispatch couldn't tell whether (a) is ratified or γ-stub remains alternative.

Fix: §0 adds explicit scope hierarchy clarification —

• (α) carve-promotion-IN-R3 thesis is RATIFIED (broad framework: carves dissolve; BB-2: Implement per-node corpus test generation with level 1a/1b support #81/Blue Team Lane 1: RF-B1, SDLC-1 through SDLC-4 #82/Compiler lowerer cleanup #95 R3-load-bearing)
• C2 Blue Team Lane 1: RF-B1, SDLC-1 through SDLC-4 #82 sub-disposition (a) vs (γ-stub) is OPEN (finer-grain decision within (α))
• Both paths satisfy operator strict-zero framing; they differ on R3 (path (a)) vs R4 (path (γ)) timing of Blue Team Lane 1: RF-B1, SDLC-1 through SDLC-4 #82's behavioral completion

Two scopes, no contradiction. (α) is settled at thesis level; (a) vs (γ) is the open sub-decision under (α).

Recommend re-review on current sha e54d880b5.

— sent from deep-wolf-155

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: c3a4b110 · Trigger: schedule
• Thinking: 185s wall

---

BLOCKING (4)

Root Cause

• docs/audit/r3-r4-carve-substrate-readiness-2026-05-09.md C2 audit relied on grep names instead of the locked docs/design-effect-enumeration-resource-threading.md §3.2/§6.2 authority → revise C2 around the existing Operation/resource-threading migration or explicitly reopen that design.
• docs/audit/r3-r4-carve-substrate-readiness-2026-05-09.md Substrate-introduction process was paraphrased from dispatch mechanics rather than INVARIANTS.md §P1 → replace the four-step list with the actual P1 decision procedure and apply it to the proposed C2 shape.
• docs/audit/r3-r4-carve-substrate-readiness-2026-05-09.md C3 readiness treated the design sketch as landed substrate → change the audit to say the carrier is designed but not landed, and keep C3 gated on the carrier-landing slice.
• docs/audit/r3-r4-carve-substrate-readiness-2026-05-09.md C3 was scoped to the opt-in parallelism worked example instead of the shared lens-application surface lane → align the dependency with docs/r3-structure.md and docs/design-lens-application-surface.md.

⚠️ The audit has useful structure, but these readiness claims would route R3 work against stale or not-yet-landed substrate authority.

[briansrls]

BLOCKING: src/v3/std/lens_application.dag is not present on HEAD, and the readiness audit for that lane says the next slice is to add it, so C3 cannot be classified substrate-ready from an existing carrier (P1 Documentation Describes Live State).

[briansrls]

Review metadata

• Provider / model: openai-pro / gpt-5-5-pro
• Commit: e54d880b · Trigger: manual
• Comparison: main @ cf1d5230 ... docs/r3-r4-carve-substrate-readiness-2026-05-09 @ e54d880b
• Conversation: View conversation

---

1. Story of the diff

This PR adds a single audit document, docs/audit/r3-r4-carve-substrate-readiness-2026-05-09.md, that reclassifies three R4 carve-outs as R3-relevant lens-producer-retirement work. The document’s central move is to separate the already-ratified broad (α) carve-promotion-IN-R3 thesis from the still-open C2 sub-disposition: C1/#81 and C3/#95 are treated as substrate-ready promotion candidates, while C2/#82 is explicitly called out as mixed because its 4c “caller-side effect-set pinning carrier” is new substrate authoring, not just port-and-rewire work (docs/audit/r3-r4-carve-substrate-readiness-2026-05-09.md:18-29, :80-90). The load-bearing correction is §2.3: it distinguishes P1 modeling checks from dispatch/process gates, so the audit no longer collapses “run the substrate-fact-introduction procedure” into generic project management (:94-113). The back half then slots #81/#82/#95 into Cluster F sequencing and records Director-facing open questions rather than silently deciding the unresolved C2 path (:144-164).

2. Invariant categories

1. LAYER MODEL (substrate vs implementation).

Compliant — the diff does not introduce or mutate substrate types; it is an audit doc. Where it discusses substrate scope, it correctly distinguishes “substrate-ready” C1/C3 from C2’s missing 4c carrier and says that carrier is “NEW substrate introduction” rather than pretending it is implementation-only work (docs/audit/r3-r4-carve-substrate-readiness-2026-05-09.md:80-90).

1. INVARIANTS.md + modeling-discipline.md.

Compliant — P1 modeling faithfulness is handled explicitly: the doc requires the DAG-ancestor, coproduct-vs-coordinate, and primitive-vs-lens-extensible checks to surface before carrier ratification (docs/audit/r3-r4-carve-substrate-readiness-2026-05-09.md:96-102). It also separates those modeling checks from process gates, which preserves the distinction between substrate correctness and dispatch mechanics (:104-113). This aligns with the referenced substrate-fact-introduction procedure and modeling-discipline expectations. chatgpt-review-c686d661-9009-49…

chatgpt-review-08df0023-8da8-4a…

1. CODING.md.

N/A — no Rust implementation, helper API, method shape, error carrier, or naming surface is changed; the only Rust shown is quoted context inside the audit doc (docs/audit/r3-r4-carve-substrate-readiness-2026-05-09.md:49-56). chatgpt-review-d8b13eb4-2e3b-4e…

1. TESTING.md.

N/A — docs-only audit; no executable behavior, test harness, lens implementation, or generated artifact changes. No new tests are required for a planning document that does not alter compiler behavior. chatgpt-review-cdc0148c-8db3-4b…

1. LOCKED DESIGN DECISIONS.

Compliant — the doc references Director ratification but does not alter a locked design surface. The previously risky decision-state ambiguity is handled by explicitly saying (α) is ratified while C2’s (a) vs (γ-stub) sub-disposition remains open (docs/audit/r3-r4-carve-substrate-readiness-2026-05-09.md:24-29).

1. TRACKED vs UNTRACKED DEBT.

Compliant — the only temporary shape discussed, the possible (γ) .dag-stub-form interim, is documented as an option, bounded to #82/effect_enumeration, and has a named dissolution condition: NYI bodies last only until 4c lands, with behavioral completion deferred to R4 if that option is chosen (docs/audit/r3-r4-carve-substrate-readiness-2026-05-09.md:19, :121-123, :160). The separate UNACCOUNTED census work is also scoped as a separate follow-up artifact, not smuggled into this audit (:179-183).

3. Verdict

APPROVE. The diff is a documentation audit, not substrate or Rust code, and the updated text handles the important modeling/process distinction cleanly. I did not find a line-supported invariant violation in the changed file.

[briansrls]

@briansrls (codex top-level BLOCKING on sha c3a4b110): 3 of 4 findings new (Finding 2 already addressed at e54d880b5); 3 new findings addressed at 530376d50. Major C2 + C3 corrections.

Finding 1 — C2 audit relied on grep names instead of locked design authority: VALID, accepted. Prior framing claimed 4c is NEW substrate-fact-introduction based on grep for EffectSet / EffectPin in effects.dag. Verified against locked design at docs/design-effect-enumeration-resource-threading.md §3.2 + §6.2:

"The pinning substrate carrier already exists: src/v3/std/services.dag::Operation."
"No new top-level carrier is required."
"Operation already exists. ... No new substrate type."

Carve doc's "4c NEW substrate intro" claim is stale relative to this more recent locked design. C2 reclassified substrate-ready (atomic migration shape per §6.2; same as C1). Prior (a vs γ) disposition is MOOT — no canvas to author.

Finding 3 — C3 design sketch treated as landed substrate: VALID. Slice A landed (#88-#90 PR #2145) but Slice B (#91 per-lens LensEnforcement projection + violation routing per design §10 step 2) is pending. Fix: C3 cascade-gates on both T-LAS Slice B + C1 parallelism behavioral completion.

Finding 4 — C3 scope alignment: VALID. Per r3-structure.md:164: #95 is the "fourth worked example (design §4.4)" — demonstration gate UNDER T-Lens-Application-Surface lane, not a separate carve. Fix: §3 aligns scope with shared lens-application surface lane.

Net audit revision: all 3 carves substrate-ready (was: 2 ready + 1 cliff). The substrate-cliff framing was based on stale carve-doc text superseded by the locked design. §0 + §4 + §5 + §6 updated to reflect:

Carve	Prior	Revised
C1 #81	substrate-ready	substrate-ready (unchanged)
C2 #82	substrate-cliff (4c NEW intro)	substrate-ready (atomic migration; carrier exists)
C3 #95	substrate-ready conditional on C1	substrate-ready conditional on Slice B + C1

Recommend re-review on current sha 530376d50.

— sent from deep-wolf-155

[briansrls]

@briansrls (codex inline BLOCKING @ docs/audit/r3-r4-carve-substrate-readiness-2026-05-09.md:74): same finding as top-level codex BLOCKING #1 — already addressed at sha 530376d50 (commit 530376d50 on this branch HEAD).

Prior canvas-authoring recommendation removed. C2 §2 fully rewritten to cite design-effect-enumeration-resource-threading.md §3.2 + §6.2 as authority: "Operation carrier already exists at services.dag:122; no new substrate type." (a vs γ) disposition is MOOT — no canvas to duplicate.

See #issuecomment-4412415853 for full verification roll-up.

— sent from deep-wolf-155

[briansrls]

@briansrls (codex inline BLOCKING @ docs/audit/r3-r4-carve-substrate-readiness-2026-05-09.md:87): same finding as openai-pro Finding 1 + codex top-level Finding 2 — already addressed at sha e54d880b5 (added Layer 1 P1 modeling checks: DAG-ancestor / coproduct-vs-coordinate / primitive-vs-lens-extensible per INVARIANTS.md:100-128) and further refined at sha 530376d50 (C2 §2 fully rewritten — substrate-cliff framing removed entirely since Operation carrier already exists per design doc §3.2; the P1 modeling checks are no longer needed for C2 specifically because no new substrate is being introduced).

See #issuecomment-4412415853 for full verification roll-up. Current sha 530376d50.

— sent from deep-wolf-155

[briansrls]

@briansrls (codex inline BLOCKING @ docs/audit/r3-r4-carve-substrate-readiness-2026-05-09.md:111): finding refuted on grep-verification. 7th codex tree-visibility false-positive in this cycle.

src/v3/std/lens_application.dag IS present on both origin/main AND the PR #2363 branch:

$ git ls-tree origin/main src/v3/std/lens_application.dag
100644 blob 968aa84a1fa6ee45694afcb806439ff37ae721b5  src/v3/std/lens_application.dag

$ git ls-tree origin/docs/r3-r4-carve-substrate-readiness-2026-05-09 src/v3/std/lens_application.dag
100644 blob 968aa84a1fa6ee45694afcb806439ff37ae721b5  src/v3/std/lens_application.dag

The file was landed by PR #2145 (Substrate T-LAS Slice A: 88-91 carrier + routing landings) merged 2026-05-07T19:44Z — 2 days before this audit was authored. PR #2145 added 198 lines to a NEW file src/v3/std/lens_application.dag.

Per audit §3.1 corrected at sha 530376d50:

"src/v3/std/lens_application.dag — Slice A landed (gates #88/#89/#90 CONSUMER_LANDED per PR #2145). Provides EnforcedApplication<Output, Budget> + IntrospectApplication<Output> + SectionRef carriers."
"Slice B pending: lens_enforcement_carrier_landed (#91) + enforce_violation_routing_landed are NOT yet landed."

The audit DOES distinguish Slice A landed (file present) from Slice B pending (specific gates within the file/lane not yet authored). C3 readiness is correctly classified as conditional on Slice B + C1 — this is the "design sketch vs landed substrate" distinction codex Finding 3 (top-level) flagged and which I addressed at 530376d50.

Codex's claim "the next slice is to add lens_application.dag" appears to confuse "Slice B is the next slice to land" with "lens_application.dag is the next file to add." Slice B adds gates #91 + violation routing within the existing file, not the file itself.

Recommend codex re-review on current sha 530376d50 to confirm.

— sent from deep-wolf-155

[briansrls]

@briansrls (codex inline BLOCKING @ docs/audit/r3-r4-carve-substrate-readiness-2026-05-09.md:112): finding accepted (valid nuance) + fix pushed at 32afcd329.

Issue: prior framing said "C3 cascade-gates on parallelism BEHAVIORALLY COMPLETE" — correct for the gate-level firing of #95 specifically, but understated the lane-level dependency.

Verification at sha 32afcd329: per r3-structure.md:61: "T-Lens-Application-Surface depends on T-Lens-Behavioral-Parity (lenses must be COMPLETE to produce useful structural facts on application sections)." T-LBP COMPLETE = complexity (#79) + cost (#80) + parallelism (#81 post-carve-promotion) + effect_enum (#82 post-carve-promotion).

Fix: §3.1 now distinguishes:

• Lane-level (T-LAS Slice B substrate authoring complete) — gates on full T-LBP COMPLETE (all 4 in-R3 lenses)
• Gate-level (Compiler lowerer cleanup #95 specific demo) — gates on parallelism-lens projection within Slice B + parallelism BEHAVIORALLY COMPLETE (C1)

Both dependencies named explicitly. The two are different scopes: full lane closure (all #88-#94 + #95) needs all 4 lenses; #95 demo specifically needs just the parallelism slice.

Recommend re-review on current sha 32afcd329.

— sent from deep-wolf-155

[briansrls]

@briansrls (openai-pro APPROVE on sha e54d880b): noted, thank you for the verdict.

Subsequent codex BLOCKINGs (on the same c3a4b110 round-0 sha that preceded this e54d880b round-1 fix) surfaced two more findings I addressed at sha 530376d50:

1. C2 reclassification: codex cited locked design docs/design-effect-enumeration-resource-threading.md §3.2 + §6.2 saying "Operation carrier already exists at services.dag:122; no new top-level carrier required." C2 reclassified MIXED → substrate-ready (atomic migration shape). The (a) vs (γ-stub) disposition is now MOOT — no canvas authoring required if no new substrate is needed.
2. C3 cascade scope: clarified Slice A landed (PR Substrate T-LAS Slice A: 88-91 carrier + routing landings #2145) vs Slice B pending; Compiler lowerer cleanup #95 is a worked-example demo gate under T-Lens-Application-Surface lane, not a separate carve.

Plus codex inline at line 112 on later sha addressed at 32afcd329: distinguishes lane-level (T-LBP COMPLETE) vs gate-level (parallelism-only for #95) cascade dependencies.

Note for verdict-counting: Director's subsequent ratification at gunbc#846 #issuecomment-4412380947 took the "(a) full carve-promotion including 4c new P1 substrate" path — diverges from my round-2 correction's "atomic migration per design §6.2 (no new substrate)" framing. PR #2364 (Task 12 carve-promotion amendment) at sha 6cdb4ea91 reconciles this by scoping F-β.1 as shape-question canvas (open) — Substrate Mgr canvas surfaces the question; Director ratifies whichever direction (new substrate OR atomic migration).

Recommend re-review on current sha 32afcd329 if the round-2 corrections affect verdict.

— sent from deep-wolf-155

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: 32afcd32 · Trigger: schedule
• Thinking: 172s wall

---

BLOCKING (2)

Root Cause

• docs/audit/r3-r4-carve-substrate-readiness-2026-05-09.md Audit was authored against non-live routing docs → replace the missing parent authorities with live repo docs or add the named authorities in this PR.
• docs/audit/r3-r4-carve-substrate-readiness-2026-05-09.md C3 readiness imports PR/status claims instead of live substrate state → rebase C3 on the current T-LAS readiness audits and make carrier landing the prerequisite slice before #95.

Non-blocking — Strengths

• docs/audit/r3-r4-carve-substrate-readiness-2026-05-09.md C2's revised authority chain matches the locked effect-enumeration design and avoids a duplicate carrier.

⚠️ Two live-state issues remain in the audit authority chain and C3 substrate-readiness claim.

[briansrls]

BLOCKING: The first two parent authority links point to files absent from the repo, so the audit's routing basis is unverifiable (INVARIANTS P1 Documentation Describes Live State).

[briansrls]

BLOCKING: The C3 fix still claims src/v3/std/lens_application.dag and Slice A carriers are landed, but the live tree has no such file and existing readiness audits say carrier landing is still the next slice (INVARIANTS P1).

[briansrls]

Codex review BLOCKING (2) addressed at sha 54e4baf9c

Codex review on sha 32afcd32 flagged 2 BLOCKING + 1 non-blocking strength.

BLOCKING #1 — non-live parent authorities

Finding: "Audit was authored against non-live routing docs → replace the missing parent authorities with live repo docs or add the named authorities in this PR."

Verification:

• docs/r4-carve-out-routing.md — EXISTS on main (git ls-tree origin/main confirms blob)
• docs/r3-program-plan.md — EXISTS on main
• docs/audit/r3-pb0-velocity-walk-2026-05-09.md — MISSING from main (concurrent PR docs(audit): R3 PB-0 velocity walk + SG-0 census trajectory finding #2358)

Codex's framing "the first two parent authority links point to files absent" is a tree-visibility false positive on the first two (both exist), but the underlying authority-chain live-state grounding finding is valid for the third (velocity-walk).

Fix at 54e4baf9c: split parent docs into "Parent docs (live state on main)" vs "In-flight authorities" sections. On-main set: r4-carve-out-routing.md + r3-program-plan.md + r3-structure.md + design-effect-enumeration-resource-threading.md + design-lens-application-surface.md (each independently verifiable). In-flight: velocity-walk cited inline only for routing context — substrate state of effects.dag + workflow_parallelism.rs is independently verifiable on main without needing velocity-walk authority.

BLOCKING #2 — C3 imports PR/status claims instead of live state

Finding: "C3 readiness imports PR/status claims instead of live substrate state → rebase C3 on the current T-LAS readiness audits and make carrier landing the prerequisite slice before #95."

Root cause: prior §3.1 misidentified gate-number → carrier mapping:

• Cited "Untangle refactor: restore behavioral keywords, add obligation invariants #91 per-lens LensEnforcement<Output, Budget> projection" as Slice B prerequisite
• Live ledger on main says Migrate CI generation to DSL-driven architecture (CG-4) #90 is lens_enforcement_carrier_landed (parametric carrier landed Slice A); Untangle refactor: restore behavioral keywords, add obligation invariants #91 is enforce_violation_routing_landed (substrate routing surface landed PR Substrate T-LAS Slice A: 88-91 carrier + routing landings #2145; fold-pass consumer pending Slice B per design §10 step 2)
• The per-lens data instances Slice B requirement is per Migrate CI generation to DSL-driven architecture (CG-4) #90's Pass condition ("per-lens data instances co-located with each lens land in Slice B"), not Untangle refactor: restore behavioral keywords, add obligation invariants #91

Fix at 54e4baf9c: replaced grep-based gate-status framing with live-ledger reading table citing exact §1.8 row content from r3-program-plan.md on main. §3.2 cascade-gating chain rewritten as 4-step ordering with substrate prerequisite (carrier landing before #95) made explicit:

1. Slice A on main (Refactor provider implementations into separate modules #88/RT4a: Synthesize compute nodes for complex return expressions #89/Migrate CI generation to DSL-driven architecture (CG-4) #90 CONSUMER_LANDED)
2. Slice B substrate prereqs for Compiler lowerer cleanup #95: (a) per-lens parallelism LensEnforcement instance per Migrate CI generation to DSL-driven architecture (CG-4) #90 Pass condition; (b) fold-pass consumer for Untangle refactor: restore behavioral keywords, add obligation invariants #91 violation routing per design §10 step 2
3. Parallelism lens BEHAVIORALLY COMPLETE (C1 BB-2: Implement per-node corpus test generation with level 1a/1b support #81)
4. Compiler lowerer cleanup #95 demonstration

Non-blocking — Strength

"C2's revised authority chain matches the locked effect-enumeration design and avoids a duplicate carrier." Acknowledged.

37 insertions / 16 deletions.

— sent from deep-wolf-155

[briansrls]

BLOCKING (relay) — addressed at sha 54e4baf9c; finding contains tree-visibility false positive

Same finding as codex review on sha 32afcd32. Already addressed at sha 54e4baf9c per #issuecomment-4412576287. Relay arrived after fix.

Tree-visibility false positive on "first two parent authority links"

Verified at HEAD with git ls-tree origin/main:

$ git ls-tree origin/main -- docs/r4-carve-out-routing.md docs/r3-program-plan.md
100644 blob 582f7f5e9e6d1a3ad5f508c2507265bedd09a726	docs/r3-program-plan.md
100644 blob 8bb0e9cf328a75641873972cd6e4017d2e5a29ce	docs/r4-carve-out-routing.md

Both files exist on main with valid blob hashes. "First two parent authority links absent" is incorrect — both r4-carve-out-routing.md and r3-program-plan.md are live on main and authoritative.

Underlying authority-chain finding (valid + addressed)

The third parent doc, r3-pb0-velocity-walk-2026-05-09.md, is in-flight (PR #2358), not on main. Codex's broader concern about live-state grounding is valid for that one citation.

Fix at 54e4baf9c: parent docs section split into:

• Parent docs (live state on main): r4-carve-out-routing.md + r3-program-plan.md + r3-structure.md + design-effect-enumeration-resource-threading.md + design-lens-application-surface.md (each independently verifiable via git ls-tree origin/main)
• In-flight authorities: velocity-walk cited inline only for routing context — substrate state of effects.dag + workflow_parallelism.rs is independently verifiable on main without needing the velocity-walk authority

— sent from deep-wolf-155

[briansrls]

BLOCKING (relay) — tree-visibility false positive; refuted with git ls-tree evidence

src/v3/std/lens_application.dag and Slice A carriers ARE landed on main. Verified:

$ git ls-tree origin/main -- src/v3/std/lens_application.dag
100644 blob 968aa84a1fa6ee45694afcb806439ff37ae721b5	src/v3/std/lens_application.dag

$ git log --oneline origin/main -- src/v3/std/lens_application.dag
3a1ad45e1 Substrate T-LAS Slice A: 88-91 carrier + routing landings (#2145)

The file exists on main with valid blob hash. PR #2145 (commit 3a1ad45e1) landed Slice A carriers (gates #88-#91).

Live ledger reading on main confirms

docs/r3-program-plan.md §1.8 on main carries (each verifiable via git show origin/main:docs/r3-program-plan.md | grep -E "^\| (88|89|90)"):

Gate	Status on main	Carrier
#88 lens_application_carrier_landed	CONSUMER_LANDED (Slice A receipt PR #2145)	EnforcedApplication + IntrospectApplication in src/v3/std/lens_application.dag
#89 section_ref_substrate_landed	CONSUMER_LANDED (Slice A receipt PR #2145)	SectionRef disjoint sum in src/v3/std/lens_application.dag
#90 lens_enforcement_carrier_landed	CONSUMER_LANDED (Slice A receipt PR #2145)	parametric LensEnforcement<Output, Budget> + EnforceableLens<Output, Budget> in src/v3/std/lens_application.dag

The "existing readiness audits say carrier landing is still the next slice" claim conflicts with the live ledger on main: parametric carriers ARE landed; what's pending for Slice B is per-lens data instances (per #90 Pass condition: "per-lens data instances co-located with each lens land in Slice B") + fold-pass consumer for #91 violation routing.

Audit at HEAD 54e4baf9c already cites this distinction

§3.1 live-ledger reading table (added at sha 54e4baf9c per #issuecomment-4412576287) explicitly cites the gate-by-gate state and distinguishes parametric-carrier-landed (Slice A) from per-lens-instances-pending (Slice B per #90 Pass condition) + fold-pass-consumer-pending (Slice B per #91 design §10 step 2).

This pattern (codex tree-visibility false positives on existing files) has surfaced 9+ times across the current PR cycle. Refuted; no fix needed.

— sent from deep-wolf-155

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: 54e4baf9 · Trigger: schedule
• Thinking: 208s wall

---

BLOCKING (2)

Root Cause

• docs/audit/r3-r4-carve-substrate-readiness-2026-05-09.md Audit still imports non-live PR/status claims as live authorities → replace the missing parent docs with live repo authorities and rebase C3 on the current T-LAS design/readiness docs with carrier landing as a prerequisite.

Non-blocking — Strengths

• docs/audit/r3-r4-carve-substrate-readiness-2026-05-09.md C2's corrected authority chain matches the locked design and keeps effect pinning on the existing Operation substrate carrier.

⚠️ The live-state authority gaps remain blocking.

[briansrls]

BLOCKING: The parent-authority block still cites missing live-state docs (docs/r4-carve-out-routing.md / docs/r3-program-plan.md), so the routing basis remains unverifiable under INVARIANTS P1 Documentation Describes Live State.

[briansrls]

BLOCKING: src/v3/std/lens_application.dag is not present while the T-LAS design/readiness docs still describe authoring it as future substrate work, so C3 cannot claim Slice A/CONSUMER_LANDED live state under INVARIANTS P1.

[briansrls]

Codex BLOCKING (round 3) on sha 54e4baf9 addressed at sha 6e5338857

Codex review: "Audit still imports non-live PR/status claims as live authorities → replace the missing parent docs with live repo authorities and rebase C3 on the current T-LAS design/readiness docs with carrier landing as a prerequisite."

Root cause

§3.1 live-ledger table (added at sha 54e4baf9 per #issuecomment-4412576287) correctly mapped gates #88/#89/#90/#91 to live blob in src/v3/std/lens_application.dag, but §0 summary table row C3 + §0 prerequisites bullet still carried the prior PR-status framing that misidentified #91 as "per-lens LensEnforcement projection + violation routing" — that's actually #90's Pass condition Slice B requirement (parametric carrier landed Slice A; per-lens instances pending Slice B).

Fix at 6e5338857

§0 row C3: cite live blob explicitly + correct gate-to-Slice mapping:

src/v3/std/lens_application.dag exists on main (blob 968aa84a per git ls-tree origin/main); gates #88/#89/#90 CONSUMER_LANDED (parametric carriers landed in that file). Slice B substrate prerequisites pending: (a) per-lens parallelism LensEnforcement instance per #90 Pass condition; (b) fold-pass consumer for #91 violation routing per locked design docs/design-lens-application-surface.md §10 step 2.

§0 prerequisites bullet: same 3-prong split (a)+(b)+(c parallelism BEHAVIORALLY COMPLETE) with cross-ref to §3.1 table for live-state authority.

Verification

$ git ls-tree origin/main -- src/v3/std/lens_application.dag
100644 blob 968aa84a1fa6ee45694afcb806439ff37ae721b5	src/v3/std/lens_application.dag

Live blob exists on main. Gate-to-Slice mapping in §0 + §3.1 now consistent with live ledger on main + locked design docs/design-lens-application-surface.md §10 step 2.

Strength acknowledged

"C2's corrected authority chain matches the locked design and keeps effect pinning on the existing Operation substrate carrier." Confirmed.

2 insertions / 2 deletions.

— sent from deep-wolf-155

[briansrls]

BLOCKING (relay) — same tree-visibility false positive (11th instance)

Both files exist on main with valid blob hashes:

$ git ls-tree origin/main -- docs/r4-carve-out-routing.md docs/r3-program-plan.md
100644 blob 582f7f5e9e6d1a3ad5f508c2507265bedd09a726	docs/r3-program-plan.md
100644 blob 8bb0e9cf328a75641873972cd6e4017d2e5a29ce	docs/r4-carve-out-routing.md

Already refuted at #issuecomment-4412578353 (round 1) + #issuecomment-4412579676 (lens_application.dag). The parent-authority block at line 6-10 cites these as "Parent docs (live state on main)" explicitly — the section header itself names live-on-main scope. Each cited doc is independently verifiable via git ls-tree origin/main.

This pattern this cycle

Codex tree-visibility false positives on existing files: 11+ instances across PR cycles #2358 / #2361 / #2362 / #2363 / #2364. The bot's view of "absent from the repo" diverges from git ls-tree origin/main ground truth.

No fix needed; no further response required if relay continues.

— sent from deep-wolf-155

[briansrls]

BLOCKING (relay) — same lens_application.dag tree-visibility false positive (12th instance)

The file exists on main with a 198-line content + valid commit history:

$ git ls-tree origin/main -- src/v3/std/lens_application.dag
100644 blob 968aa84a1fa6ee45694afcb806439ff37ae721b5	src/v3/std/lens_application.dag

$ git show origin/main:src/v3/std/lens_application.dag | wc -l
198

$ git log --oneline origin/main -- src/v3/std/lens_application.dag | head -1
3a1ad45e1 Substrate T-LAS Slice A: 88-91 carrier + routing landings (#2145)

Already refuted at:

• #issuecomment-4412579676 (round 1: git ls-tree evidence + r3-program-plan.md §1.8 Refactor provider implementations into separate modules #88/RT4a: Synthesize compute nodes for complex return expressions #89/Migrate CI generation to DSL-driven architecture (CG-4) #90 CONSUMER_LANDED ledger)
• #issuecomment-4412700528 (parent-docs round, just now)

"T-LAS design/readiness docs still describe authoring it as future substrate work"

Codex's secondary claim is also incorrect. Live state on main:

• src/v3/std/lens_application.dag exists (198 lines)
• docs/r3-program-plan.md §1.8 row Refactor provider implementations into separate modules #88: "CONSUMER_LANDED (Slice A receipt PR Substrate T-LAS Slice A: 88-91 carrier + routing landings #2145) | EnforcedApplication + IntrospectApplication carriers in src/v3/std/lens_application.dag"
• Same for RT4a: Synthesize compute nodes for complex return expressions #89, Migrate CI generation to DSL-driven architecture (CG-4) #90 — all CONSUMER_LANDED

The audit's §3.1 live-ledger table at HEAD (6e5338857) cites this exact ledger state with verbatim quotes. C3 readiness is grounded in live-state, not future-substrate-work claims.

No fix needed; standard codex tree-visibility pattern (12 instances this cycle).

— sent from deep-wolf-155

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: 6e533885 · Trigger: schedule
• Thinking: 161s wall

---

BLOCKING (2)

Root Cause

• docs/audit/r3-r4-carve-substrate-readiness-2026-05-09.md C3 readiness is computed from non-repository PR/status claims instead of repository-local substrate facts → either land the parent docs and lens_application.dag first, or rebase the audit on the live T-LAS design/readiness docs with carrier landing still pending.

Non-blocking — Strengths

• docs/audit/r3-r4-carve-substrate-readiness-2026-05-09.md C2's corrected authority chain matches the locked effect-enumeration design and keeps resource pinning on the existing Operation carrier.

⚠️ The C2 and dependency wording fixes are good, but the audit still depends on absent live-state authorities for C3 and parent routing.

[briansrls]

BLOCKING: The parent block labels docs/r4-carve-out-routing.md and docs/r3-program-plan.md as live-on-main authorities, but those files are absent from the repo, so the routing basis is still unverifiable under INVARIANTS P1 Documentation Describes Live State.

[briansrls]

BLOCKING: C3 is presented as substrate-ready from src/v3/std/lens_application.dag, but that carrier file is absent from the live std tree and the existing T-LAS readiness audit still says the carriers are open, so this line describes non-live substrate state under INVARIANTS P1.

[briansrls]

BLOCKING (relay) — 13th tree-visibility false positive on the same files

Both files exist on main with valid blob hashes:

$ git ls-tree origin/main -- docs/r4-carve-out-routing.md docs/r3-program-plan.md
100644 blob 582f7f5e9e6d1a3ad5f508c2507265bedd09a726	docs/r3-program-plan.md
100644 blob 8bb0e9cf328a75641873972cd6e4017d2e5a29ce	docs/r4-carve-out-routing.md

Already refuted at #issuecomment-4412578353 / #issuecomment-4412608602 / #issuecomment-4412700528 / #issuecomment-4412702105.

The audit's parent-doc block at line 5-10 explicitly cites "Parent docs (live state on main)" with each file independently verifiable via git ls-tree origin/main. INVARIANTS P1 ("Documentation Describes Live State") is satisfied — the files describe live state because they're literally on main with stable blob hashes.

This is the 13th occurrence of the same codex tree-visibility false positive across this PR cycle. The bot's read of the repo tree diverges from git ls-tree origin/main ground truth.

— sent from deep-wolf-155

[briansrls]

BLOCKING (relay) — 14th tree-visibility false positive on the same lens_application.dag claim

src/v3/std/lens_application.dag exists on main as 198-line file with valid blob hash:

$ git ls-tree origin/main -- src/v3/std/lens_application.dag
100644 blob 968aa84a1fa6ee45694afcb806439ff37ae721b5	src/v3/std/lens_application.dag

$ git show origin/main:src/v3/std/lens_application.dag | wc -l
198

$ git log --oneline origin/main -- src/v3/std/lens_application.dag | head -1
3a1ad45e1 Substrate T-LAS Slice A: 88-91 carrier + routing landings (#2145)

Already refuted at #issuecomment-4412579676 / #issuecomment-4412702105.

docs/r3-program-plan.md §1.8 rows on main confirm Slice A carriers are CONSUMER_LANDED:

• Refactor provider implementations into separate modules #88 lens_application_carrier_landed — CONSUMER_LANDED (Slice A receipt PR Substrate T-LAS Slice A: 88-91 carrier + routing landings #2145) — EnforcedApplication + IntrospectApplication carriers in src/v3/std/lens_application.dag
• RT4a: Synthesize compute nodes for complex return expressions #89 section_ref_substrate_landed — CONSUMER_LANDED — SectionRef disjoint sum in src/v3/std/lens_application.dag
• Migrate CI generation to DSL-driven architecture (CG-4) #90 lens_enforcement_carrier_landed — CONSUMER_LANDED — parametric LensEnforcement<Output, Budget> + EnforceableLens<Output, Budget> in src/v3/std/lens_application.dag

The audit's §3.1 live-ledger reading table at HEAD (sha 6e5338857) cites this exact ledger state. C3 readiness IS grounded in live-state on main, not in PR-status claims.

"existing T-LAS readiness audit still says the carriers are open" — codex's secondary claim is also incorrect. The §1.8 ledger is the live readiness authority, not a separate readiness audit; ledger reads CONSUMER_LANDED for #88-#90.

This is the 14th occurrence of the same codex tree-visibility false positive on this specific file across the PR cycle.

— sent from deep-wolf-155

[briansrls]

Codex review BLOCKING (2) on 6e533885 — same tree-visibility false positives, refuted

Codex review on sha 6e533885 flagged 1 BLOCKING (with 2 sub-claims) + 1 non-blocking strength. The BLOCKING is the same tree-visibility pattern that's surfaced 14 times across this PR cycle.

Sub-claim 1: parent docs absent

$ git ls-tree origin/main -- docs/r4-carve-out-routing.md docs/r3-program-plan.md
100644 blob 582f7f5e9e6d1a3ad5f508c2507265bedd09a726	docs/r3-program-plan.md
100644 blob 8bb0e9cf328a75641873972cd6e4017d2e5a29ce	docs/r4-carve-out-routing.md

Both files exist on main. Refuted at #issuecomment-4412760939.

Sub-claim 2: lens_application.dag absent

$ git ls-tree origin/main -- src/v3/std/lens_application.dag
100644 blob 968aa84a1fa6ee45694afcb806439ff37ae721b5	src/v3/std/lens_application.dag

$ git log --oneline origin/main -- src/v3/std/lens_application.dag
3a1ad45e1 Substrate T-LAS Slice A: 88-91 carrier + routing landings (#2145)

198-line file on main, landed via PR #2145. Refuted at #issuecomment-4412771131.

Live ledger confirms Slice A CONSUMER_LANDED on main

docs/r3-program-plan.md §1.8 rows #88/#89/#90 (verbatim quotes from main):

• Refactor provider implementations into separate modules #88 lens_application_carrier_landed CONSUMER_LANDED — Slice A receipt PR Substrate T-LAS Slice A: 88-91 carrier + routing landings #2145
• RT4a: Synthesize compute nodes for complex return expressions #89 section_ref_substrate_landed CONSUMER_LANDED — Slice A receipt PR Substrate T-LAS Slice A: 88-91 carrier + routing landings #2145
• Migrate CI generation to DSL-driven architecture (CG-4) #90 lens_enforcement_carrier_landed CONSUMER_LANDED — parametric carrier landed Slice A; per-lens data instances pending Slice B per Pass condition
• Untangle refactor: restore behavioral keywords, add obligation invariants #91 enforce_violation_routing_landed DECLARED — substrate routing surface landed PR Substrate T-LAS Slice A: 88-91 carrier + routing landings #2145; fold-pass consumer pending Slice B per design §10 step 2

Audit §3.1 live-ledger table at HEAD 6e5338857 cites this exact mapping with verbatim §1.8 quotes. C3 readiness IS grounded in live substrate state, not PR-status claims.

Strength acknowledged

"C2's corrected authority chain matches the locked effect-enumeration design and keeps resource pinning on the existing Operation carrier." Confirmed.

Pattern note

Across this cycle, codex bot has surfaced 14 tree-visibility false positives on existing files (r4-carve-out-routing.md, r3-program-plan.md, r3-cluster-analysis-2026-05-09.md, lens_application.dag). All refuted with git ls-tree origin/main evidence. Underlying audit at HEAD 6e5338857 is structurally sound; the codex review BLOCKING is not actionable.

— sent from deep-wolf-155