docs(r3): gate #87 PASSING + r3-structure §Acceptance (regen registry)

[briansrls]

Summary

This PR is the ledger + canonical-archive follow-up to PR #2757 (gate #87 cementing harness receipts: LensOutputEquals / DifferentialEquals / SymbolicCostExprEquals, paired Rust pins in r3_gate_87_lens_cementing_regen_receipts_test).

It does three things:

1. Promotes §1.8 row RT1-RT4: model correctness — credential wiring, fail-closed auth, fil… #87 lens_cementing_test_discipline_complete to CONSUMER_LANDED + PASSING in docs/r3-program-plan.md, with receipts citing PR R3 gate #87: lens_cementing_test_discipline_complete #2639 (inventory + t_pb_b_1_dag_runner_test) and Complete gate #87 lens cementing receipts #2757.
2. Amends docs/r3-structure.md §"Acceptance" (and the T-Tests-As-Data-Completeness lane table clause) so the authoritative Pass corpus for this gate id is explicitly every LensRegistryEntry in src/v3/compiler/regen.dag (witness rules per capability register v2 column + TESTING.md Band-C). Non-regen .dag lenses remain Band-C / register scope outside this gate’s enumeration.
3. Aligns §1.8 Notes + lane digest + Q-PB0-Risk6 so §1.7 is not misread as “slice PASSING over a larger implicit canon”: PASSING here means exhaustive coverage of the amended §Acceptance corpus (the registry rows), documented in row RT1-RT4: model correctness — credential wiring, fail-closed auth, fil… #87 Notes after commit e5398d6ac.

Canonical text changed (review focus)

• docs/r3-structure.md — §Acceptance bullet lens_cementing_test_discipline_complete + T-Tests-As-Data lane row (3).
• docs/r3-program-plan.md — §1.8 row RT1-RT4: model correctness — credential wiring, fail-closed auth, fil… #87, §1 lane-status table T-Tests-As-Data-Completeness, §10 Q-PB0-ClusterM-Cold-Risk6 digest for RT1-RT4: model correctness — credential wiring, fail-closed auth, fil… #87.

Test plan / CI

• Local: cargo fmt --all --check; cargo test -p v3-compiler r3_gate_87 (integration subset covering r3_gate_87_lens_cementing_regen_receipts_test + t_pb_b_1_dag_runner_test::r3_gate_87_cementing_regen_lens_suites_pass_through_runner).
• CI: repository ci workflow on the live PR head (fmt, changes, ci, v3, etc.) is the merge gate; do not merge until dashboard-ops reviews reports ready=true (per Verification Mgr: passing checks, no REQUEST_CHANGES, no active reviews, ≥2 distinct approvals on current head_sha).

Worker attestation

• Title describes the change (not only the session / branch name).
• PR body states what changed, why it follows Complete gate #87 lens cementing receipts #2757, and which canonical files moved.
• Tests: cargo fmt --all --check + cargo test -p v3-compiler r3_gate_87 run locally on this worktree; full matrix = CI.
• No Closes #N — not applicable (internal ledger / gate work; no GitHub issue to reference).
• Commits are authored in this session worktree only.
• No secrets or large binaries.

[briansrls]

Gate #87 / APPROVE_WITH_COMMENTS follow-up (canonical alignment)

We co-landed the missing docs/r3-structure.md §"Acceptance" amendment + matching T-Tests-As-Data-Completeness lane-row clause so the authoritative Pass surface for lens_cementing_test_discipline_complete is explicitly the src/v3/compiler/regen.dag LensRegistryEntry enumeration (v2-oracle / DifferentialEquals / LensOutputEquals vs register v2 column; v3-native / N/A / helper rows per TESTING.md Band-C). docs/r3-program-plan.md §1.8 row 87 Notes now cite that bullet instead of narrowing canon via §1.7 alone; Q-PB0-Risk6 digest cites r3-structure.md §Acceptance. r3_gate_87_lens_cementing_regen_receipts_test module doc points at structure → plan authority order.

Commit: e22229614.

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: a222dd90 · Trigger: schedule
• Thinking: 359s wall

---

BLOCKING (1)

Root Cause

• docs/r3-program-plan.md the ledger narrows the authoritative acceptance scope without updating the canonical pass-condition body → either revise r3-structure.md/the gate definition to make the Phase-2 regen.dag slice the actual corpus, or keep #87 at CONSUMER_LANDED until the existing corpus is covered.

⚠️ The status promotion is load-bearing for R3 closure and currently overstates what the unchanged canonical acceptance text permits.

[briansrls]

Re: BLOCKING inline on docs/r3-program-plan.md:313 (codex @ a222dd90)

Verified on current HEAD (includes e22229614 + e5398d6ac):

1. r3-structure.md §Acceptance — the lens_cementing_test_discipline_complete bullet no longer says “every .dag lens …”; it now names the LensRegistryEntry / src/v3/compiler/regen.dag enumeration + witness rules (docs/v3-lens-capability-register.md v2 column + TESTING.md Band-C) and explicitly parks non-regen lenses on Band-C / register ratchets.

2. §1.8 row RT1-RT4: model correctness — credential wiring, fail-closed auth, fil… #87 Notes — cites that amended §Acceptance body and, after e5398d6ac, states explicitly that §1.7 is satisfied because PASSING here means exhaustive coverage of this gate’s §Acceptance corpus (the registry rows), not a partial receipt against a larger implicit canon.

So the review artifact anchored at a222dd90 was true for that parent only (pre–e22229614); it is not true on the live branch. No further code change required beyond the clarifying row-87 Note in e5398d6ac.

— sent from valiant-dove-21

[briansrls]

Verification (claude review #10175 / e5398d6ac)

Checked current HEAD:

• docs/r3-structure.md §Acceptance lens_cementing_test_discipline_complete (line ~155) bounds the gate corpus to LensRegistryEntry / regen.dag, with witness rules tied to the capability register + TESTING.md Band-C; non-regen lenses are explicitly out of this gate’s enumeration surface.
• docs/r3-program-plan.md §1.8 row RT1-RT4: model correctness — credential wiring, fail-closed auth, fil… #87 matches that bullet and spells out §1.7 (exhaustive coverage of this §Acceptance corpus, not a partial slice vs a larger implicit canon).
• r3_gate_87_lens_cementing_regen_receipts_test.rs is module-doc only (authority chain: structure → plan → Band-C follow-ons); no executable Rust changed.

Agree with APPROVE: no further code/doc fix required from this review artifact.

Merge readiness (not met yet): GitHub still shows v3 check pending on the same workflow run; dashboard-ops reviews reports ready=false — only one dashboard approval counts on live head_sha (10175; 10167 is on an older SHA), so the 2 distinct approval-provider rule is not satisfied until e.g. openai-pro (or another distinct provider) posts on e5398d6ac and CI is fully green.

— sent from valiant-dove-21

[briansrls]

Review metadata

• Provider / model: openai-pro / gpt-5-5-thinking
• Commit: e5398d6a · Trigger: manual
• Comparison: main @ 821b5769 ... session/valiant-dove-21 @ e5398d6a
• Conversation: View conversation

---

1. Story of the diff

This PR promotes R3 gate #87, lens_cementing_test_discipline_complete, from CONSUMER_LANDED to CONSUMER_LANDED + PASSING by making the gate’s acceptance corpus explicit: the gate now covers LensRegistryEntry rows enumerated in src/v3/compiler/regen.dag, with non-regen lenses left to the broader Band-C/register ratchets. The load-bearing docs change is in r3-structure.md:155, which rewrites the acceptance bullet from “every .dag lens” to “every LensRegistryEntry in regen.dag,” and r3-program-plan.md:313 then promotes the status row using PR #2639 + #2757 as the executable receipt set. The integration test file change is comment-only: it updates r3_gate_87_lens_cementing_regen_receipts_test.rs:26-30 to point readers at the new gate status and keep broader Band-C work scoped outside this gate.

2. Invariant categories

1. LAYER MODEL (substrate vs implementation).

N/A — diff is documentation/status plus a test-module comment; it does not touch Dag substrate types, dag.rs, cross-pass carriers, or compiler behavior.

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

Finding — P2 / single-authority status discipline. docs/r3-program-plan.md:1058 now says gate #87 is CONSUMER_LANDED + PASSING but the same added row still ends with “Verification Mgr briefs for #87/#84 dispatch awaiting plan ratification.” That leaves two live operational meanings for #87 in one authority row: “closed” and “still awaiting dispatch/ratification.” INVARIANTS P2 says every fact should live in exactly one authoritative place, and modeling discipline’s single-authority practice treats duplicate representations of a fact as violations. chatgpt-review-ea891771-51d8-40…

chatgpt-review-6763e535-141e-42…

Suggested fix: remove #87 from the “awaiting plan ratification” tail, or rewrite it as only #84 / remaining Cluster M work.

1. CODING.md.

Compliant — no executable Rust behavior changed; the only Rust-file edit is a module comment at src/v3/compiler/tests/integration/r3_gate_87_lens_cementing_regen_receipts_test.rs:26-30, so the data+free-functions, error-shape, and helper-placement rules are not newly implicated.

1. TESTING.md.

Compliant — the new acceptance language lines up with Band-C’s scoped cementing discipline: docs/r3-structure.md:155 requires .dag harnesses and Rust pin receipts where predicate carriers are intentionally narrower, and src/v3/compiler/tests/integration/r3_gate_87_lens_cementing_regen_receipts_test.rs:28-30 explicitly keeps broader non-regen.dag lens work on the Band-C/register ratchets. TESTING.md permits .dag harnesses by default and temporary Rust receipts when the predicate carrier cannot express the published shape. chatgpt-review-72e26f1d-b8f4-43…

1. LOCKED DESIGN DECISIONS.

N/A — this PR does not alter locked substrate shape, Pure Bootstrap to Zero, or testing residual design. It narrows a gate corpus to a documented registry surface rather than changing the underlying locked testing direction.

1. TRACKED vs UNTRACKED DEBT.

Compliant, except for the status wording finding above. The helper-only rows are explicitly called out as Compiles placeholders with dissolution triggers and paired Rust receipts at docs/r3-program-plan.md:313 and docs/r3-structure.md:155; that is tracked bridge language, not silent scaffolding.

2.5. Top-down PM intent review

Finding — planning artifact could dispatch stale work. The intended new meaning is clear at docs/r3-structure.md:155: gate #87’s acceptance corpus is the regen.dag LensRegistryEntry surface, and docs/r3-program-plan.md:313 marks that corpus CONSUMER_LANDED + PASSING. But docs/r3-program-plan.md:1058 still says “Verification Mgr briefs for #87/#84 dispatch awaiting plan ratification,” which could cause a worker or coordinator to treat #87 as still needing dispatch despite the same PR declaring it passing. This is a semantic status contradiction in the planning layer, not a code issue.

3. Verdict

APPROVE_WITH_COMMENTS. The PR’s main mechanism is sound and the regen-registry scoping is explicit, but the stale #87 dispatch wording at docs/r3-program-plan.md:1058 should be cleaned up so the planning artifact has one operational meaning for the gate.

[briansrls]

openai-pro APPROVE_WITH_COMMENTS — §10 Q-PB0-Risk6 P2 fix

The contradiction at docs/r3-program-plan.md:1058 (§1.8 #87 PASSING vs disposition still naming “#87/#84 briefs awaiting ratification”) is resolved in a06c4d0be: Phase-2 #87 is marked landed in the sequencing column, and the disposition tail scopes Verification Mgr briefs to #84 bulk-port only with an explicit parenthetical that no separate #87 brief gate remains.

— sent from valiant-dove-21

[briansrls]

Re: claude #10185 (APPROVE_WITH_COMMENTS — §Acceptance narrowing vs PASSING)

Verified: docs/r3-structure.md:155 + lane row co-land does replace the old “every .dag lens … v2-oracle everywhere” shorthand with the regen.dag LensRegistryEntry enumeration + explicit Band-C / register carve-out. That is not “PASSING first, rubric second”: prior openai-pro review on this PR required r3-structure.md to move with the ledger (P2 single authority); the PASSING row is indexed to that amended §Acceptance bullet, and §1.8 row #87 Notes spell out §1.7 (exhaustive coverage of this corpus only).

PM-intent traceability: docs/audit/r3-cluster-m-sequencing-plan-2026-05-09.md had stale §1.1 table + §4 discipline lines still quoting the old #87 string — fixed in e87966cac so the Cluster M sequencing artifact names the same corpus as r3-structure.md (cross-link in table).

No executable Rust changed for this follow-up (docs-only).

— sent from valiant-dove-21

[briansrls]

Verification — cursor/composer-2 #10190 (e87966cac)

Spot-checked current HEAD: docs/r3-structure.md §Acceptance line for lens_cementing_test_discipline_complete, §1.8 row #87, docs/audit/r3-cluster-m-sequencing-plan-2026-05-09.md gate table + §4 discipline bullet, and r3_gate_87_lens_cementing_regen_receipts_test.rs module docs — all agree on the regen.dag LensRegistryEntry corpus vs Band-C/register carve-out. No further diff required for this APPROVE.

Merge gate: GitHub checks on e87966cac are all green (fmt / changes / ci / v3 / self_host_ratchet). mergeStateStatus is CLEAN. dashboard-ops reviews still reports ready: false because counted distinct approving providers remain below 2 (artifact parser shows verdict: unknown for cursor #10190 and openai-pro #10184 on this head despite textual APPROVE in logs). Not squash-merging until dashboard ready: true per Verification Mgr policy.

— sent from valiant-dove-21

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: e87966ca · Trigger: schedule
• Thinking: 382s wall

---

Non-blocking — Strengths

• docs/r3-structure.md The amended acceptance text explicitly keeps non-regen lenses on Band-C/register ratchets, so the #87 PASSING claim no longer silently narrows an unchanged corpus.

✅ No blocking concerns; the prior slice-vs-corpus mismatch is resolved.

[briansrls]

Verification — codex @ e87966ca (no blocking concerns)

Confirmed docs/r3-structure.md §Acceptance for lens_cementing_test_discipline_complete keeps non-regen lenses on Band-C / register ratchets alongside the regen.dag LensRegistryEntry enumeration — matches the stated resolution of the old slice-vs-corpus tension. No code change required for this review artifact.

Merge gate: dashboard-ops reviews still ready: false — openai-pro review #10197 is running on e87966cac, so active reviews ≠ 0 and counted distinct approvals remain 1/2 until that cycle completes and the dashboard parser marks a second provider APPROVE. Not merging yet.

— sent from valiant-dove-21

[briansrls]

Review metadata

• Provider / model: openai-pro / gpt-5-5-pro
• Commit: e87966ca · Trigger: manual
• Comparison: main @ 821b5769 ... session/valiant-dove-21 @ e87966ca
• Conversation: View conversation

---

1. Story of the diff

This PR is a docs/registry alignment pass for R3 gate #87. It changes the gate from the older broad wording, “every .dag lens,” into a narrower and more explicit acceptance corpus: the LensRegistryEntry rows enumerated in src/v3/compiler/regen.dag, with non-regen lenses left to the normal Band-C / register ratchets. The load-bearing edits are the new canonical acceptance language in docs/r3-structure.md:155, the promotion of row #87 to CONSUMER_LANDED + PASSING in docs/r3-program-plan.md:313, and the audit/receipt comments that point the Rust receipt module back to that same authority at src/v3/compiler/tests/integration/r3_gate_87_lens_cementing_regen_receipts_test.rs:26-30.

The overall mechanism is sensible: instead of leaving gate #87’s pass condition as an implicit universe of “all .dag lenses,” the diff names the concrete registry slice and keeps broader lens parity work outside this gate id. That matches TESTING’s Band-C shape, where regen.dag registry rows and the capability register drive cementing obligations, while anti-scope explicitly avoids demanding full equivalence for every .dag file. chatgpt-review-785fba65-e072-47…

chatgpt-review-785fba65-e072-47…

2. Invariant categories

1. LAYER MODEL — Compliant. This is documentation plus a Rust module comment only; it does not touch substrate types, Dag, cross-pass data carriers, or generated declarations. The diff’s modeling decision is a planning/acceptance-surface clarification: docs/r3-structure.md:155 makes regen.dag registry entries the gate RT1-RT4: model correctness — credential wiring, fail-closed auth, fil… #87 enumeration surface rather than adding substrate.
2. INVARIANTS.md + modeling-discipline.md — Finding, BLOCKING. P2 / single-authority metadata is violated in the updated Risk6 row: docs/r3-program-plan.md:1058 says §1.8 #86 program_generator_carrier_landed is CONSUMER_LANDED + PASSING, but the same added line still says “Substrate Mgr canvases for Fix gist #85/BT1: SDLC pipeline compiles with unit_test profile #86 ... awaiting plan ratification.” That leaves BT1: SDLC pipeline compiles with unit_test profile #86 both closed and pending in the same dispatch artifact, which is exactly the kind of duplicate status authority P2 tries to prevent. The fix is small: drop #86 from the remaining-dispatch clauses or mark that phase as historical/complete.
3. CODING.md — Compliant. No production Rust behavior changes. The only Rust edit is a module-level documentation comment in src/v3/compiler/tests/integration/r3_gate_87_lens_cementing_regen_receipts_test.rs:26-30, so the data + free-functions / error-shape conventions are not exercised.
4. TESTING.md — Compliant. The PR does not add new behavior requiring tests; it documents that the executable receipts already live in the .dag runner and Rust pin path. The new acceptance wording at docs/r3-structure.md:155 explicitly names .dag harnesses, the runner test, and r3_gate_87_lens_cementing_regen_receipts_test, which is consistent with Band-C’s registry-driven cementing dispatch and its allowance for temporary Rust receipts only when the predicate carrier is narrower. chatgpt-review-785fba65-e072-47…
5. LOCKED DESIGN DECISIONS — N/A. The diff references broad R3 and testing authorities but does not alter a locked design decision or introduce a new locked-design divergence.
6. TRACKED vs UNTRACKED DEBT — Compliant with one caveat covered above. The diff explicitly keeps helper-only rows as Compiles placeholders with dissolution triggers and paired Rust receipts at docs/r3-program-plan.md:313, and docs/r3-structure.md:155 repeats the dissolution-trigger requirement for those placeholders. That is tracked bridge language, not unbounded scaffolding. The remaining problem is not untracked debt; it is the stale BT1: SDLC pipeline compiles with unit_test profile #86 dispatch status in docs/r3-program-plan.md:1058.

2.5. Top-down PM intent review

Finding, BLOCKING. The PM-level intent of this PR is to make Cluster M’s remaining work dispatchable after gate #87 is accepted as PASSING. The diff’s own gate table establishes #86 as already CONSUMER_LANDED + PASSING at docs/r3-program-plan.md:312, but the updated Risk6 planning row still tells the Substrate Manager that “#85/#86” canvases are awaiting plan ratification at docs/r3-program-plan.md:1058. A worker following that artifact faithfully could spend effort on gate #86 after the same document says it is closed. Narrow the remaining work to #85 and #84, or split the row into “completed Phase 1 #86” versus “remaining Phase 1 #85.”

3. Verdict

REQUEST_CHANGES. The gate #87 acceptance narrowing to the regen.dag registry corpus is coherent and aligns with Band-C, but the updated Risk6 dispatch row leaves #86 simultaneously PASSING and awaiting dispatch. That is a small docs fix, but it is load-bearing because this PR is specifically updating planning/status authority.

[briansrls]

openai-pro REQUEST_CHANGES (§10 Risk6 / #86 vs #85) — addressed

docs/r3-program-plan.md:1058 Q-PB0-ClusterM-Cold-Risk6 no longer lists #86 under “Substrate Mgr canvases for #85/#86 … awaiting ratification” while §1.8 row #86 is PASSING. Phase 1 column now: #86 landed (PR #2645) + #85 canvas still open; disposition tail: Substrate canvas for #85 only + Verification #84 bulk-port briefs; explicit parenthetical that #86/#87 are closed on §1.8 and not pending on this row.

Commit: 1ccc757c4.

— sent from valiant-dove-21

[briansrls]

Verification — cursor/composer-2 #10199 (1ccc757c4)

Re-checked current HEAD: docs-only alignment (incl. §10 Risk6 #86 pending-dispatch cleanup in 1ccc757c4) + r3_gate_87_* module comments only; APPROVE finding stands — no further repo edits needed for this artifact.

Merge gate: GitHub v3 still pending on workflow for 1ccc757c4; dashboard-ops reviews ready: false — openai-pro #10198 running, counted approvals 1/2 (dashboard parser still verdict: unknown for cursor on this head). No squash-merge yet.

— sent from valiant-dove-21

[briansrls]

Review metadata

• Provider / model: openai-pro / gpt-5-5-pro
• Commit: 1ccc757c · Trigger: manual
• Comparison: main @ 821b5769 ... session/valiant-dove-21 @ 1ccc757c
• Conversation: View conversation

---

1. Story of the diff

This PR converts gate #87 from an over-broad “every .dag lens” acceptance sentence into a narrower, explicit regen registry corpus: every LensRegistryEntry in src/v3/compiler/regen.dag must have the cementing receipts described by Band-C testing discipline, while non-regen lenses remain covered by the capability-register / dispatch-test ratchets outside this gate. The load-bearing edit is docs/r3-structure.md:155, which defines that corpus and names the receipt surfaces; the surrounding edits propagate that meaning into the sequencing audit (docs/audit/r3-cluster-m-sequencing-plan-2026-05-09.md:28, :108), the §1.8 status table (docs/r3-program-plan.md:313), the program status row (docs/r3-program-plan.md:439), and the Risk6 dispatch row (docs/r3-program-plan.md:1058). The only source-tree Rust change is a module-comment alignment in src/v3/compiler/tests/integration/r3_gate_87_lens_cementing_regen_receipts_test.rs:26-30; it does not change test behavior.

2. Invariant categories

1. LAYER MODEL (substrate vs implementation).

N/A — the diff is documentation plus a Rust module-comment update; it does not add or alter Dag substrate types, cross-pass carriers, dag.rs, variants, or mutation APIs.

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

Compliant — P2 single authority is handled by making docs/r3-structure.md §Acceptance the canonical body for gate #87 (docs/audit/r3-cluster-m-sequencing-plan-2026-05-09.md:28) and by giving the exact enumeration surface at docs/r3-structure.md:155, rather than leaving multiple broader interpretations of “every .dag lens.” This matches Boundary Discipline’s “one authoritative place” rule and generated-consumer landing bar. chatgpt-review-dd456b93-2942-4c…

Compliant — P5 tracked-bridge discipline is also preserved: the same acceptance bullet keeps Compiles placeholders only as explicit helper/N/A scopes with “dissolution triggers + Rust pin receipts” (docs/r3-structure.md:155), rather than silently treating them as permanent equivalence coverage. P5 requires scaffolds to carry dissolution paths. chatgpt-review-dd456b93-2942-4c…

1. CODING.md.

N/A — no Rust implementation logic is introduced; the only Rust file change is a doc-comment status/authority clarification at src/v3/compiler/tests/integration/r3_gate_87_lens_cementing_regen_receipts_test.rs:26-30, so data/free-function style, error carriers, and helper placement are untouched.

1. TESTING.md.

Compliant — the diff does not add a new test, but it is not making a new behavioral claim without receipts: docs/r3-structure.md:155 names the .dag harness family, runner test, and Rust receipt test; docs/r3-program-plan.md:313 names the PR #2639 / #2757 executable receipts and the narrower Rust pins. That is consistent with TESTING Band-C: registry rows promoted to behavioral parity need cementing receipts, temporary Rust receipts are allowed only with a named blocker, and missing/unwired receipts cannot satisfy the ratchet. chatgpt-review-c7023685-1ab3-44…

Also important: the narrowed gate scope does not erase broader lens obligations; TESTING’s Band-C anti-scope explicitly says it is not a mandate for full equivalence of every .dag file and governs explicit subsumption / COMPLETE-with-counterpart claims. chatgpt-review-c7023685-1ab3-44…

1. LOCKED DESIGN DECISIONS.

N/A — the diff does not edit a locked design document or change a locked substrate/evaluator decision. It references existing design/status material, but the changed lines are scoped to R3 planning and gate accounting.

1. TRACKED vs UNTRACKED DEBT.

Compliant — the PR does not introduce new scaffolding; it keeps the remaining non-registry and helper-only work explicitly routed. docs/r3-structure.md:155 names dissolution-triggered placeholders and Rust pin receipts where predicates are narrower, while src/v3/compiler/tests/integration/r3_gate_87_lens_cementing_regen_receipts_test.rs:28-30 states that broader non-regen.dag Band-C work continues through the capability register, dispatch test, and ROADMAP honesty pass.

2.5. Top-down PM intent review

Compliant. The highest-level intent is still “tests are data” and structurally-derived verification, not permanent hand-maintained test drift; the thesis says the v2-style test suite should exist as .dag TestClaim declarations or generated target-language tests, with Rust residuals dissolving under the 0-floor program. chatgpt-review-0b3eac33-aabb-47…

This PR does not weaken that target: gate #84 remains the “every Rust test ports” gate, while #87 is made a narrower registry-cementing gate (docs/r3-structure.md:155, docs/r3-program-plan.md:313, docs/r3-program-plan.md:439). The semantic narrowing is explicit rather than hidden: non-regen lenses are not declared done; they are routed to Band-C / register ratchets outside this gate (docs/audit/r3-cluster-m-sequencing-plan-2026-05-09.md:28, docs/r3-structure.md:155, src/v3/compiler/tests/integration/r3_gate_87_lens_cementing_regen_receipts_test.rs:28-30).

3. Verdict

APPROVE. The PR is a documentation/authority alignment that makes gate #87’s corpus precise, promotes PASSING against named receipts, and keeps broader lens/test-data obligations explicitly alive rather than silently dissolved. I did not find a diff-cited invariant violation.

[briansrls]

Verification — openai-pro @ 1ccc757c (APPROVE)

Walked the cited lines on 1ccc757c4: docs/r3-structure.md §Acceptance for #87, docs/r3-program-plan.md §1.8 row #87 + lane digest + §10 Risk6 (#86/#85 split), docs/audit/r3-cluster-m-sequencing-plan-2026-05-09.md gate table + §4 bullet, and r3_gate_87_lens_cementing_regen_receipts_test.rs module docs — consistent with the review’s P2 / Band-C / P5 story. No further code/doc edits required for this APPROVE.

Merge gate: GitHub v3 check still pending on workflow for 1ccc757c4 (mergeStateStatus BLOCKED while required checks run). dashboard-ops reviews still ready: false: approval_count 1/2 because the dashboard parser leaves openai-pro #10198 and cursor #10199 at verdict: unknown on this SHA even though the human-readable review is APPROVE — operators may need an ingestion fix or a manual merge policy override. Not running gh pr merge until CI green + ready: true.

— sent from valiant-dove-21

[briansrls]

Operator merge-bypass request for parser-lag on PR #2759.

Dashboard source of truth re-polled immediately before this comment:

Item	State
HEAD	1ccc757c48365f6939124f459aa4737685c77f9e
Checks	passing
Mergeable	MERGEABLE
Draft/open	ready PR, open
Active reviews	0
REQUEST_CHANGES	0
Dashboard readiness	ready=false
Dashboard approvals	1/2, counted provider: claude

Substantive review evidence at this HEAD:

Provider	Review/artifact	Dashboard verdict	Substantive state
claude	dashboard-counted	approve	APPROVE, counted
openai-pro	#10198 / GitHub comment 4431908669	unknown	PM verified textual APPROVE on 1ccc757c
cursor	#10199 dashboard artifact	unknown	Worker reports APPROVE-equivalent dashboard-only artifact on 1ccc757c

This appears to match the operator-tier parser-lag bypass class: checks are green, GitHub mergeability is clean, no request-changes are present, no active reviews remain, and the only blocker is dashboard verdict ingestion leaving openai-pro/cursor as unknown despite substantive approval evidence.

As Verification Mgr I am not authorizing a solo merge while dashboard-ops reviews reports ready=false. Requesting operator decision: either backfill/fix dashboard verdict ingestion for openai-pro/cursor on 1ccc757c so dashboard readiness becomes true, or explicitly authorize/perform squash-merge despite dashboard ready=false for this parser-lag case.

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: 1ccc757c · Trigger: schedule
• Thinking: 447s wall

---

BLOCKING (1)

Root Cause

• docs/r3-program-plan.md Risk6 was updated to remove #86/#87 pending dispatch without rebasing the #85 pending-work description on the current §1.8/Cluster-M authority → replace the #85 substrate-canvas/ratification wording with the actual generated-consumer/SuiteClaim-wrapper follow-on, or remove #85 from pending substrate dispatch if no longer applicable.

Non-blocking — Strengths

• docs/r3-structure.md The amended acceptance body now names the regen.dag registry corpus and keeps non-regen lenses on Band-C/register ratchets outside this gate.

⚠️ One stale Risk6 dispatch sentence still contradicts the updated gate authority.

[briansrls]

BLOCKING: Risk6 still routes #85 to a substrate canvas/ratification even though §1.8 row #85 says the carriers have landed and Cluster M’s locked design says no canvas-tier ratification is needed, creating duplicate dispatch authority under INVARIANTS P2.