test generalization

[briansrls]

Opened from session-dashboard for session valiant-swift-774.

[briansrls]

Review: APPROVE — solid cementing infrastructure, ready to promote from draft.

This is the right implementation of the register's discipline rule #3 generalization. Scope is exactly what we discussed: build the mechanism, not blanket-mandate test coverage. Four design choices that get it right:

What's load-bearing

TESTING.md section is precise about the trigger condition. The "Where this applies" paragraph names the two cases (v2 counterpart exists / v3-native but COMPLETE) and the "Anti-scope" paragraph prevents scope creep. Explicitly: "This section is not a mandate to prove full lens equivalence for every .dag file." That line is important — without it, future readers might interpret the section as "every lens needs a cementing test" and end up stuck on Band C gaps.

regen.dag header comment creates obligation at registration time. Any new LensRegistryEntry author will see "If the register row is BEHAVIORALLY COMPLETE and names a concrete v2 counterpart, add a matching behavioral cementing module..." — that's the right place for the cue. Catches drift at the earliest structural point.

Register rule #6 closes the loop from register → test discipline. The register (which lands before cementing tests per ordering) now names the test discipline as its enforcement arm. Bidirectional: register rule #3 asks for cementing tests; rule #6 says they live in TESTING.md + cementing/. No orphaned docs.

CEMENTING_MODULES_FOR_V2_COMPLETE_CLAIMS is honest empty today. The ratchet list is &[] because no lens is currently both BEHAVIORALLY COMPLETE and has a v2 counterpart (provenance/unused_parameters/etc. are v3-native). The first lens to claim v2-parity-COMPLETE — presumably after substrate-carrier work closes the gap for complexity or cost — extends this list in the same PR. The structural ratchet (file-must-exist check) catches the claim being made without the backing test.

Why promoting provenance's cementing test anyway is good design

Provenance is v3-native (N/A counterpart), so it doesn't strictly trigger the ratchet. But the worker cemented it anyway. This is exactly the right interpretation of the TESTING.md rule "No v2 counterpart but register marks COMPLETE: pin the lens's published behavioral contract on minimal constructed Dag shapes."

It demonstrates two things in one artifact:

• The mechanism works end-to-end (not hypothetical)
• Even v3-native COMPLETE claims get voluntary cementing, giving the discipline room to mature before the substrate-carrier lenses force it

The compile_to_dag fixture approach (vs the preferred "minimal constructed Dag shapes") is a concession — noted honestly in the file comment ("Integration crate cannot reach Dag's pub(crate) builder helpers"). That's a real packaging issue worth a future small lane ("expose Dag builder helpers for integration tests"), but not a blocker here; full-pipeline fixtures still cement the shipped contract.

Two minor observations (non-asks, worth noting)

1. The ratchet list is empty today, which is semantically correct but a reader encountering this file for the first time might wonder "what does this enforce?" The test name cementing_test_modules_exist_for_escalated_v2_complete_registry_claims is self-documenting, and the const's comment explains when to extend it. I think this is fine — leaving a stub entry would create fake-test-debt. Flagging so you can reinforce via follow-up PR comment if desired.

2. The Dag builder accessibility issue. Your file comment flags that integration tests can't reach pub(crate) builder helpers, so full-pipeline fixtures are the fallback. If more cementing tests get authored and this becomes routine overhead, a small "expose test-builder helpers" lane makes sense. Not for this PR — just noting it'll be real debt if cementing-test authoring accelerates.

Verdict

Ready to promote from draft. Once it's ready-for-review the CI run (now draft-aware thanks to #626) will pick it up. The mechanism is the right shape: minimal enforcement, maximal clarity about when it fires, example test showing the pattern. When the first v2-parity-COMPLETE claim comes through (complexity or cost after substrate-carrier work lands), the author has a clean template to follow.

Suggest: before promoting, double-check that sg0_census_test.rs also tracks the new cementing/ directory as expected and that no currently-passing ratchet complains about the new path. (The diff shows the file was added to EXPECTED_HAND_AUTHORED — good.)

🤖 Director review

[briansrls]

Review metadata

• Provider / model: codex / gpt-5.4
• Commit: c98e93f5 · Trigger: schedule
• Thinking: 152s wall

---

Findings

• NON-BLOCKING — src/v3/compiler/tests/integration/cementing/cementing_lens_registry_dispatch_test.rs:73 with the manual module-registration pattern in src/v3/compiler/tests/integration.rs:40 violates TESTING.md's API-level-enforcement-over-convention intent. The new ratchet only asserts that cementing/<stem>.rs exists on disk; it never verifies that the file is actually wired into tests/integration.rs, so a future PR can satisfy the documented “same PR” rule with an inert file that never compiles or runs.

Verdict
APPROVE_WITH_COMMENTS. The diff is small and I don’t see a concrete modeling/substrate violation. The only concern is that the new cementing-dispatch guard does not yet enforce the full workflow it documents.

[briansrls]

Review metadata

• Provider / model: claude / claude-opus-4-7
• Commit: c98e93f5 · Trigger: schedule
• Thinking: 477s wall

---

The monitor timed out after the cargo test had already completed and I confirmed the results. No re-arm needed — review is complete.

Final verdict: APPROVE_WITH_COMMENTS. The two new tests pass, the diff is a narrowly-scoped process/discipline change (cementing-test section in TESTING.md, mirror entry in the lens capability register, comment on regen.dag, a ratchet slice, and the first cementing module for provenance.dag), and only minor style nits were worth noting.

[briansrls]

CI fix — both failures are the same root cause

The 3 failing tests all trace to a single fact: your header-comment addition to src/v3/compiler/regen.dag (+9 lines) changed the file's content hash / parsed .dag bytes. Three snapshots track regen.dag's state and need a refresh — they're not "which files exist" ratchets, they're "what does parsing/compiling this file produce" ratchets. The sg0 census update you did is necessary but not sufficient.

Specific fixes (order matters; each captures a different snapshot)

1. Parse-corpus manifest (fixes parse_stage4_prep::handwritten_parse_snapshot_matches_manifest)

The only diff between left and right in the assertion is exactly one line — regen.dag's fnv1a64 hash:

• Expected: 01fdfda0b031563d
• Actual: 49f47c59c626d776

Everything else is byte-identical. Refresh command is in the failure output's first line:

cargo test -p v3-compiler refresh_handwritten_parse_snapshot_manifest -- --ignored

This runs the ignored refresh_handwritten_parse_snapshot_manifest test (defined next to the failing one at tests/integration.rs:330), which writes the regenerated manifest to tests/integration/parse_corpus_manifest.txt.

2. Bootstrap snapshots (fixes both pb1_bootstrap_full_snapshot_test::*)

The generated bootstrap snapshots also bake in regen.dag's current parse state, so they drifted. Regenerate via:

cargo run -p v3-compiler --bin regen_bootstrap

That should update the checked-in generated_full_bootstrap_*.rs snapshots under src/v3/compiler/src/.

After the regen

Commit the refreshed manifest + regenerated bootstrap snapshots in the same commit (call it something like chore: refresh parse manifest + bootstrap snapshots after regen.dag header edit). CI should go green.

Small meta-observation (non-ask)

Ironic context: your PR implements Band-C cementing-test discipline, and the failures are caused by parallel-authority ratchets (3 places track regen.dag's state separately). This is exactly the shape of tracked debt the register philosophy flags — but it's pre-existing, not caused by this PR. Worth a ROADMAP entry after land: "bootstrap/parse-corpus snapshots form a parallel-authority cluster with regen.dag; editing regen.dag requires 3 refreshes." Could eventually dissolve via a shared regen entrypoint, but out of scope here.

🤖 Director review

[briansrls]

Review metadata

• Provider / model: openai-pro / gpt-5-4-pro
• Commit: c98e93f5 · Trigger: manual
• Conversation: View conversation

---

1. Story of the diff

This PR is trying to formalize a new “cementing test” lane for Band-C lens-subsumption claims. The docs changes in TESTING.md:334-383, docs/v3-lens-capability-register.md:81, and the header note in src/v3/compiler/regen.dag:27-35 all say the same thing from different angles: when v3 is claimed behaviorally complete—especially against a real v2 counterpart—that claim should be backed by a focused integration test module under src/v3/compiler/tests/integration/cementing/.

The executable part of that policy is wired in at src/v3/compiler/tests/integration.rs:40-41, which pulls in a new test file, and src/v3/compiler/tests/integration/sg0_census_test.rs:183, which updates the hand-authored census. Inside the new module, src/v3/compiler/tests/integration/cementing/cementing_lens_registry_dispatch_test.rs:46-65 adds one real provenance regression on tiny compile_to_dag fixtures, while :27-35 and :67-80 introduce the intended ratchet for future v2-complete claims by mapping registry names to expected cementing modules and checking that those modules exist.

2. Invariant categories

1. LAYER MODEL (substrate vs implementation).

N/A — this diff is docs/tests only. src/v3/compiler/regen.dag:27-35 is a comment addition, not a substrate-type or Dag-shape change.

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

Finding (BLOCKING) — single-authority metadata / facts flow forward: TESTING.md:340-345 says the authoritative inventory for this obligation is the capability register, but src/v3/compiler/tests/integration/cementing/cementing_lens_registry_dispatch_test.rs:27-35 introduces a separate hand-maintained slice, CEMENTING_MODULES_FOR_V2_COMPLETE_CLAIMS, and :73-79 consults only that slice. Because the test never derives from or cross-checks against the authoritative register/regen source, a future PR can promote a row to BEHAVIORALLY COMPLETE and forget the slice update with no failing ratchet. That makes the new enforcement path drift-prone at exactly the point where the docs claim single authority.

1. CODING.md.

Compliant — the new helper logic is small, free-function style, and explicit about dependencies: origin_label at src/v3/compiler/tests/integration/cementing/cementing_lens_registry_dispatch_test.rs:15-25 and find_bind_value_port at :37-44 match the repo’s “data + functions, not objects” discipline.

1. TESTING.md.

Finding (BLOCKING) — regression tests should enforce the claimed behavior, not just an inert artifact: the comment at src/v3/compiler/tests/integration/cementing/cementing_lens_registry_dispatch_test.rs:32-34 says each listed stem must land with a #[path = ...] registration in tests/integration.rs, but the actual test at :69-79 only checks path.is_file(). A future PR can add an unreferenced cementing/<stem>.rs file and still go green even though that module would never be compiled or run. So the “same PR as the claim” rule documented in TESTING.md:369-378 is not actually enforced by the new ratchet.

1. LOCKED DESIGN DECISIONS.

N/A — no locked thesis/design decision is altered here; the diff stays in testing/process docs plus test wiring.

1. TRACKED vs UNTRACKED DEBT.

N/A — no explicit TODO, bridge, deprecation, or temporary scaffold is introduced as such. The issue is not missing debt bookkeeping; it is that the landed enforcement mechanism is weaker than the process it claims to ratchet.

3. Verdict

REQUEST_CHANGES

The direction is good, and most of the diff is clean implementation-only policy/test work. But the load-bearing new mechanism does not yet enforce what the prose says it enforces: it shadows the authoritative inventory in a manual slice and only verifies on-disk file presence, not that the required cementing module is actually registered and executed.

[briansrls]

Review metadata

• Provider / model: codex / gpt-5.4
• Commit: 74204844 · Trigger: schedule
• Thinking: 234s wall

---

Findings

• [BLOCKING] src/v3/compiler/tests/integration/cementing/cementing_lens_registry_dispatch_test.rs:35, :104, :110 violate docs/modeling-discipline.md Practice 6 / the new TESTING.md dispatch rule. The ratchet only checks whatever is manually entered in CEMENTING_MODULES_FOR_V2_COMPLETE_CLAIMS, so a PR can still promote a register row to BEHAVIORALLY COMPLETE with a real v2 counterpart and pass CI simply by forgetting to update that slice. That leaves the critical obligation convention-only, even though this PR documents it as a regen.dag -> register -> test-module ratchet.

Verdict
REQUEST_CHANGES. The main new behavior here is the cementing-dispatch enforcement, and right now it does not actually enforce the authoritative sources it claims to guard. Once that obligation is derived from, or at least cross-checked against, the real registry/register data, the rest of the diff looks clean.

[briansrls]

Review metadata

• Provider / model: claude / claude-opus-4-7
• Commit: 74204844 · Trigger: schedule
• Thinking: 436s wall

---

Review complete — already posted above. The original background cargo test completed successfully, matching the synchronous run (3 passed). No changes to the verdict: APPROVE.

[briansrls]

Review metadata

• Provider / model: codex / gpt-5.4
• Commit: d609bbc5 · Trigger: schedule
• Thinking: 399s wall

---

BLOCKING (1)

Root Cause

• src/v3/compiler/tests/integration/cementing/cementing_lens_registry_dispatch_test.rs Behavioral completeness for provenance is defined over the full Origin carrier, but the new ratchet asserts only a lossy projection → match on Origin::{Source,Computed}{_0} and compare those payloads to the expected producer node ids from the compiled fixtures.

⚠️ The Band-C dispatch shape looks sound overall, but the new provenance exemplar needs to cement the full Origin contract rather than only the variant labels.

[briansrls]

Review metadata

• Provider / model: claude / claude-opus-4-7
• Commit: 2187b319 · Trigger: schedule
• Thinking: 69s wall

---

Findings

• Test name vs body mismatch — src/v3/compiler/tests/integration/cementing/cementing_lens_registry_dispatch_test.rs:74. The test is named provenance_origin_of_cements_behavior_complete_row_on_minimal_ports, but the body drives compile_to_dag("let lit: Int = 7", …) / compile_to_dag("let sum: Int = 1 + 2", …) — a pipeline fixture, not minimal ports. The comment on lines 76–79 honestly explains why (integration-crate visibility of alloc_port_with_shape), which is fine per TESTING.md's "single tiny compile_to_dag fixture when the contract genuinely spans the pipeline" escape hatch. But TESTING.md §"Naming convention" says "The name IS the contract claim" — _on_minimal_ports in the name advertises a shape the test does not use. Rename to reflect what it actually pins (e.g. _via_compile_to_dag_fixture or _on_live_lowering_path), or drop the qualifier. Non-blocking.

• Empty ratchet slice is intentional but worth a breadcrumb — cementing_lens_registry_dispatch_test.rs:36 declares CEMENTING_MODULES_FOR_V2_COMPLETE_CLAIMS: &[(&str, &str)] = &[]. The ratchet does nothing today (no register row is COMPLETE with a concrete v2 counterpart — provenance.dag is None (v3-native)). This is a correctly bounded scaffold: documented (doc comment), bounded (empty), and with a named dissolution trigger (promotion of a lens row to COMPLETE with v2 counterpart). Passes the tracked-debt bar. No action needed.

Verdict

APPROVE. Small, process-oriented PR that hardens the Band-C cementing discipline without touching substrate. It (a) documents the rule in TESTING.md and the register, (b) lands a ratchet test module that's self-wired and checks both on-disk presence and #[path] wiring in integration.rs, and (c) adds a concrete behavioral test cementing provenance.dag's COMPLETE row. Bootstrap regen + manifest diffs are mechanical byte-offset shifts from the new regen.dag header comment — expected. Only nit is the test-name/body drift noted above.

[briansrls]

Review metadata

• Provider / model: codex / gpt-5.4
• Commit: 2187b319 · Trigger: schedule
• Thinking: 269s wall

---

Findings

• BLOCKING — src/v3/compiler/tests/integration/cementing/cementing_lens_registry_dispatch_test.rs:35: the new ratchet hangs off a manually maintained CEMENTING_MODULES_FOR_V2_COMPLETE_CLAIMS slice, even though TESTING.md:340 says the capability register is the authoritative inventory and src/v3/compiler/regen.dag:28 presents this as same-PR dispatch enforcement. Since cementing_test_modules_exist_for_escalated_v2_complete_registry_claims only iterates that local slice, a future promotion in docs/v3-lens-capability-register.md can still pass CI if the author forgets to update this duplicate list. That is a concrete single-authority / API-level-enforcement miss against docs/modeling-discipline.md.

Verdict
REQUEST_CHANGES. The added provenance coverage looks fine, but the dispatch ratchet itself is still convention-only because it never consumes the authority it claims to police. I’d fix that linkage before relying on this mechanism.

[briansrls]

Review metadata

• Provider / model: claude / claude-opus-4-7
• Commit: dad52a3c · Trigger: schedule
• Thinking: 106s wall

---

Findings

None blocking. A few observations below.

Verdict

APPROVE — This PR adds a Band-C cementing discipline (TESTING.md section + capability-register hook + in-tree ratchet test) and wires one supplementary cementing test for provenance.dag. The rest of the diff is mechanical: span offsets in bootstrap_generated*.rs tracking the new header comment in regen.dag, manifest hash bump, sg0 census entry for the new file, and re-exporting the already-generated origin_for_behavior. No substrate types change; no modeling discipline is violated.

The ratchet is architecturally clean: cementing_escalation_slice_matches_capability_register derives the required slice by joining two independent authorities (docs/v3-lens-capability-register.md and regen.dag) and asserts CEMENTING_MODULES_FOR_V2_COMPLETE_CLAIMS is a projection, not a third authority. Today the expected slice is empty (all COMPLETE rows are None (v3-native)), so the empty &[] is correct — the test will fire the moment a register row promotes with a real v2 counterpart. That's exactly the "tracked bridge" shape: documented (TESTING.md §Cementing, register discipline §6, regen.dag header), bounded (empty until a register row changes), with a named dissolution trigger (promotion to COMPLETE + non-None v2 counterpart).

Exploratory observations (non-blocking)

• provenance_origin_of_cements_complete_row_via_compile_to_dag_fixture (cementing_lens_registry_dispatch_test.rs:247) uses origin_for_behavior as its oracle. Both origin_of and origin_for_behavior are emitted from the same provenance.dag, so this cements the decomposition origin_of = origin_for_behavior ∘ node_lookup ∘ produced_by ∘ port rather than pinning concrete Origin values. A lockstep edit to both functions would pass. The author calls this out ("Exhaustive NoProducer / Missing* cases stay in lib.rs::lens_provenance::tests"), and those unit tests in lib.rs do use labelled-string pins against minimally constructed Dag shapes, which is what TESTING.md's new section describes as the canonical form. Worth noting that the new integration test is a seam check layered on top of the real value pins — not the cementing pattern itself. Fine as-is; just flagging so future readers don't cargo-cult the decomposition-vs-authority pattern.
• Two tests (cementing_lens_registry_dispatch_test_is_wired_in_integration_rs and the #[path = ...] check inside cementing_test_modules_exist_for_escalated_v2_complete_registry_claims) do substring matches against tests/integration.rs. sg0_census_test.rs already enumerates that hand-authored list; if that census ever grows a stronger invariant ("every cementing/*.rs is wired"), these string-search ratchets could collapse into it. Not a change ask for this PR — just a future simplification seam.

[briansrls]

Review metadata

• Provider / model: codex / gpt-5.4
• Commit: dad52a3c · Trigger: schedule
• Thinking: 291s wall

---

Findings

• src/v3/compiler/tests/integration/cementing/cementing_lens_registry_dispatch_test.rs:62 violates TESTING.md’s behavior-driven / cost-of-change guidance. The new “cementing” test at :247-258 derives its expected value by calling origin_for_behavior, which is the same implementation origin_of delegates to after the produced_by walk. That means a regression in the shared Behavior -> Origin mapping would still pass here, so this does not independently cement the published Origin contract for the BEHAVIORALLY COMPLETE provenance row.

Verdict
APPROVE_WITH_COMMENTS

The process/docs ratchet is directionally clean, and the new tests pass (cargo test -p v3-compiler cementing_lens_registry_dispatch_test). My only concern is that the provenance cementing test is implementation-coupled, so it is weaker than the testing discipline this PR is trying to establish.

[briansrls]

Review metadata

• Provider / model: claude / claude-opus-4-7
• Commit: 2d12c445 · Trigger: schedule
• Thinking: 128s wall

---

Review

This is a test-infrastructure / documentation PR. Summary of what's in scope:

• TESTING.md — new section Cementing tests (Band C — lens subsumption) plus a Related cross-ref.
• docs/v3-lens-capability-register.md — new discipline bullet feat(cloud): add cloud resource management layer with GCP and AWS sup… #6 pointing at the in-tree dispatch.
• src/v3/compiler/regen.dag — header comment only; substantive behavior unchanged. Bootstrap fixtures (bootstrap_generated*.rs) are mechanical span bumps from that comment.
• src/v3/compiler/src/lib.rs — re-exports origin_for_behavior alongside origin_of / Origin.
• tests/integration.rs — wires one new module via #[path = "integration/cementing/…"].
• tests/integration/cementing/cementing_lens_registry_dispatch_test.rs — new ratchet test + one provenance seam check on compile_to_dag fixtures.
• parse_corpus_manifest.txt / sg0_census_test.rs — expected census/hash updates.

What I looked for and did not find

• No substrate change; no new carrier types in dag.rs. Modeling discipline around illegal-states-unrepresentable / coprod dissolution doesn't have concrete surface here.
• The cementing slice CEMENTING_MODULES_FOR_V2_COMPLETE_CLAIMS: &[] = &[] is correctly empty — every COMPLETE row in the register is None (v3-native), so the derived expected set is empty (cementing_escalation_slice_matches_capability_register passes trivially today, but becomes load-bearing the moment a v2 counterpart row is escalated). This is a projection of register + regen, not a parallel authority — the test comments are explicit about that.
• The provenance_origin_of_cements_complete_row_via_compile_to_dag_fixture test asserts origin_of(dag, port) == origin_for_behavior(producer). Both are emitted from the same provenance.dag file, so this is not an independent oracle — the module docstring (lines 12–19) and the test docstring (lines 273–276 in the new file) explicitly flag it as a seam check on the live lowering path, with the actual Behavior → Origin contract pinned in lib.rs::lens_provenance::tests. That framing is honest and consistent with INVARIANTS P1 ("single authority") — there is one source (provenance.dag), two generated readers.
• TESTING.md's "mocks over compile" preference is acknowledged in the new test's doc (it justifies the compile_to_dag use case as cementing the seam, with mapping pins kept in-crate). Consistent.

Exploratory observation (non-blocking)

assert_origin_carriers_equal (tests/integration/cementing/cementing_lens_registry_dispatch_test.rs:27–46) enumerates the seven current Origin variants and falls through to _ => panic!("full Origin carrier mismatch"). If a future PR adds an 8th variant, two equal instances of that new variant would hit the catch-all and panic as "mismatch" — a silent false failure rather than a compile error. A generated PartialEq on Origin (or an exhaustive match with named new-variant arms) would future-proof this. Not a concern for this diff since no variant is added.

Verdict

APPROVE — diff is narrowly scoped to test/doc infrastructure, the new ratchet is derived from a single authority rather than hand-maintained, and the known seam-vs-oracle caveat is documented at both the module and function level. No invariant violations grounded in the diff.

[briansrls]

Review metadata

• Provider / model: codex / gpt-5.4
• Commit: 2d12c445 · Trigger: schedule
• Thinking: 294s wall

---

Findings

• BLOCKING — src/v3/compiler/src/lib.rs:383, src/v3/compiler/tests/integration/cementing/cementing_lens_registry_dispatch_test.rs:28, :53-58: this PR widens v3_compiler::lens_provenance with origin_for_behavior only so the new integration test can reach an internal seam. That conflicts with TESTING.md’s “don’t test private state through public surfaces” guidance and with the module’s own boundary comment immediately above the export: the test itself says this helper is not the published contract, so leaking it into the public API makes later cleanup a breaking change. Keep the helper crate-private and either move the seam check under crate tests or assert origin_of’s public behavior directly from the integration fixture.

Verdict
REQUEST_CHANGES. The new cementing/ratchet work is otherwise coherent, and the focused tests I spot-checked pass, but I would not merge the public origin_for_behavior export just to support this test wiring.

[briansrls]

Review metadata

• Provider / model: codex / gpt-5.4
• Commit: 816b20e9 · Trigger: schedule
• Thinking: 256s wall

---

Verdict: APPROVE. Diff is narrowly scoped to the new cementing-test ratchet and its documentation, and I don’t see a concrete violation of INVARIANTS.md, docs/modeling-discipline.md, CODING.md, or TESTING.md in the changed lines. Targeted check cargo test -p v3-compiler cementing_lens_registry_dispatch_test -- --nocapture passes.

[briansrls]

Review metadata

• Provider / model: claude / claude-opus-4-7
• Commit: 0f9c9c6e · Trigger: schedule
• Thinking: 100s wall

---

Review

This PR adds scaffolding for Band-C cementing tests (TESTING.md §Cementing tests, a dispatch ratchet in cementing_lens_registry_dispatch_test.rs, and an SG-6 census check that the module is wired). No substrate or lens semantics change. The ratchet currently operates over an empty slice (CEMENTING_MODULES_FOR_V2_COMPLETE_CLAIMS = &[]), which is correct: no register row is COMPLETE with a non-N/A v2 counterpart today, so the derived expectation set is empty — the equality assertion holds honestly.

Things I checked against the rubric:

• Single authority. CEMENTING_MODULES_FOR_V2_COMPLETE_CLAIMS is a projection, not a parallel inventory: cementing_escalation_slice_matches_capability_register (lines 306–320) derives the required set from the register md + regen.dag and asserts exact equality. That's a shared read, not duplication.
• Behavior→Origin mirror (lines 82–90 of the test). Duplicated deliberately to keep origin_for_behavior crate-private (per the 816b20e fix addressing a prior blocking review). The duplication is (1) documented, (2) bounded to five variants, and (3) has a named dissolution note ("keep in lockstep with provenance.dag"), with independent minimal-Dag pins in lens_provenance::tests. Tracked bridge — accept. I cross-checked against src/v3/lenses/provenance.dag:84–91; the mirror matches exactly.
• Wiring ratchet placement. Moving the #[path = ...] check into sg6_hand_authored_census_test.rs (lines 459–478) is the right call — an in-module assertion can't catch the case where the mod line itself is deleted. SG-6 is always linked.
• Bootstrap regen. The 18 edited lines in bootstrap_generated*.rs are mechanical span offsets for the new regen.dag comment block. No semantic drift.
• md_table_cells unit pin (lines 119–137) locks the \| escaping against accidental markdown churn in the register. Sensible.

No findings.

Verdict

APPROVE — scaffolding-only diff, no substrate changes, ratchet is correctly grounded in the register + regen.dag rather than asserted as a second source, and the prior blocking review comments (API-surface, false-green wiring, seam-vs-oracle split) are visibly addressed.

Exploratory observations (optional)

• The provenance_origin_of_cements_complete_row_via_compile_to_dag_fixture test runs two full compile_to_dag invocations for what is ultimately a seam check on produced_by → classification. If integration wall time becomes a concern, you could swap for a single fixture exercising both Value and Transform producers — but at two calls it's noise, and this is a one-shot COMPLETE cement, not a growing suite. Fine to leave.
• The cementing discipline will get its real stress test the first time a row escalates with a live v2 counterpart (probably complexity.dag / cost.dag per the register's root-cause analysis). Worth re-reading the md-parsing helper at that point — right now only COMPLETE / None (v3-native) branches are exercised by real data.

[briansrls]

Review metadata

• Provider / model: codex / gpt-5.4
• Commit: 0f9c9c6e · Trigger: schedule
• Thinking: 196s wall

---

Findings

• NON-BLOCKING [src/v3/compiler/tests/integration/cementing/cementing_lens_registry_dispatch_test.rs:164] re-encodes the “has a real v2 counterpart” rule but only excludes None (v3-native), while the new testing guidance treats both None (v3-native) and N/A as “no v2 counterpart” cases (TESTING.md:345). That splits the policy across two inconsistent authorities, which is a Boundary Discipline / single-authority metadata issue: a future COMPLETE row written as N/A will falsely trip the v2-cementing ratchet.

Verdict
APPROVE_WITH_COMMENTS

The diff is otherwise clean and the new ratchets are directionally sound. I also ran cargo test -p v3-compiler cementing_lens_registry_dispatch -- --nocapture; the new tests pass as landed.

[briansrls]

Review metadata

• Provider / model: claude / claude-opus-4-7
• Commit: eb2ff4a5 · Trigger: schedule
• Thinking: 134s wall

---

Review of PR #638 — test generalization

This PR wires up a Band-C "cementing test" dispatch framework: it adds a section to TESTING.md, a discipline note to the capability register, a header comment to regen.dag, and a new integration-layer test module (cementing_lens_registry_dispatch_test.rs) that mechanically cross-checks docs/v3-lens-capability-register.md + regen.dag against a declared slice of required cementing modules. An external SG-6 ratchet verifies the new module is wired via #[path] (self-defeating-mod check). bootstrap_generated*.rs + manifest hash updates are the expected artifacts of adding the comment block to regen.dag.

Notes (no findings)

• Parallel-representation concern considered and ok. The local expected_origin_from_producer_behavior (cementing_lens_registry_dispatch_test.rs:287–295) mirrors origin_for_behavior from provenance.dag. This looks like duplication at first read, but it is the explicit test oracle — the test exists so that drift in provenance.dag surfaces, and the mirror is bounded (five arms), documented, and kept crate-private by design (commit 816b20e narrows visibility after review). That matches "one authority, one oracle"; it is not two authorities.
• CEMENTING_MODULES_FOR_V2_COMPLETE_CLAIMS is empty. That is accurate — no register row is currently COMPLETE with a real v2 counterpart — so the ratchet is vacuous today and activates automatically the moment a row is promoted. cementing_escalation_slice_matches_capability_register enforces that activation. Good shape.
• Markdown-table parsing is fragile but pinned. md_table_cells uses \u{241f} as a sentinel for \| escapes. The dedicated test md_table_cells_preserves_escaped_pipes_for_register_capability_rows pins the behavior, and format drift in the register will surface as a loud test failure rather than silent miscounting. Acceptable.
• Scope of provenance exemplar. provenance_origin_of_cements_complete_row_via_compile_to_dag_fixture only exercises Value-producer paths (let lit: Int = 7, let sum: Int = 1 + 2); the docstring correctly delegates Transform/Branch/Loop/Bind coverage to lens_provenance::tests with minimal hand-built Dag shapes. That split matches the TESTING.md prose this PR introduces ("minimal constructed Dag shapes ... or a single tiny compile_to_dag fixture").
• SG-6 cross-check is correctly placed. A module can't assert its own #[path] wiring (the mod declaration's deletion kills the assertion). Putting the check in sg6_hand_authored_census_test.rs:611–627 is the right call and the comment explains why.

Verdict

APPROVE. The PR is disciplined test infrastructure: it adds enforcement without widening substrate or public API, the ratchet derives from existing authorities rather than creating a third, the one new crate-private helper (origin_for_behavior) was deliberately kept pub(crate), and the self-defeating-mod hole is covered externally. No INVARIANTS / modeling-discipline / CODING / TESTING violations observed in the diff.

[briansrls]

Review metadata

• Provider / model: codex / gpt-5.4
• Commit: eb2ff4a5 · Trigger: schedule
• Thinking: 234s wall

---

Verdict: APPROVE

Diff is narrowly scoped to test/docs ratchets, and I don’t see a concrete violation of INVARIANTS.md, docs/modeling-discipline.md, CODING.md, or TESTING.md in the changed lines. The new cementing dispatch stays fail-closed and single-authority enough for this slice: regen.dag remains the registry authority, the capability register stays the behavioral authority, and the added ratchets only enforce the wiring between them. Targeted checks I ran passed, including cementing_escalation_slice_matches_capability_register, provenance_origin_of_cements_complete_row_via_compile_to_dag_fixture, sg6_cementing_lens_registry_dispatch_module_is_wired_in_integration_rs, and sg0_v3_hand_authored_census.

[briansrls]

Review metadata

• Provider / model: codex / gpt-5.4
• Commit: eb2ff4a5 · Trigger: schedule
• Thinking: 258s wall

---

Non-blocking — Strengths

• src/v3/compiler/tests/integration/cementing/cementing_lens_registry_dispatch_test.rs The new escalation slice is derived from the capability register plus LensRegistryEntry rows, so the cementing list stays a projection rather than becoming a competing authority.
• src/v3/compiler/tests/integration/sg6_hand_authored_census_test.rs Owning the integration-module wiring ratchet in SG-6 matches the layer that can actually observe tests/integration.rs linkage and closes the prior self-disabling hole cleanly.

✅ The previously flagged gaps are fixed and I do not see a new thesis- or invariant-level concern in this test generalization pass.

[briansrls]

Review metadata

• Provider / model: openai-pro / gpt-5-4-pro
• Commit: eb2ff4a5 · Trigger: manual
• Conversation: View conversation

---

1. Story of the diff

This PR turns “cementing tests” from a loose review expectation into an explicit Band‑C ratchet for lens-subsumption claims. The docs now say that when the capability register marks a lens COMPLETE against a real v2 counterpart, the same PR must land a matching cementing module and wire it into the integration harness (TESTING.md:334-389, docs/v3-lens-capability-register.md:81, src/v3/compiler/regen.dag:27-36). The load-bearing implementation is the new src/v3/compiler/tests/integration/cementing/cementing_lens_registry_dispatch_test.rs:163-359, which parses the capability-register markdown, projects LensRegistryEntry rows out of the compiler Dag, and checks that the hand-maintained CEMENTING_MODULES_FOR_V2_COMPLETE_CLAIMS slice is exactly that projection; it also adds a small provenance seam test for the v3-native complete case at src/v3/compiler/tests/integration/cementing/cementing_lens_registry_dispatch_test.rs:310-325. The rest of the diff is the harness/bookkeeping needed to make that ratchet live: wiring the new module into tests/integration.rs:40-41, adding census coverage in src/v3/compiler/tests/integration/sg0_census_test.rs:183 and src/v3/compiler/tests/integration/sg6_hand_authored_census_test.rs:463-479, and regenerating bootstrap/manifest artifacts after the regen.dag comment shift (src/v3/compiler/src/bootstrap_generated.rs:1040-1048, src/v3/compiler/src/bootstrap_generated_without_runtime_mirrors.rs:1040-1048, src/v3/compiler/tests/integration/parse_corpus_manifest.txt:14).

2. Invariant categories

1. LAYER MODEL (substrate vs implementation).

N/A — no substrate semantics change. src/v3/compiler/regen.dag:27-36 adds process commentary only, and the bootstrap_generated* / manifest edits are regen fallout rather than a new Dag shape (src/v3/compiler/src/bootstrap_generated.rs:1040-1048, src/v3/compiler/src/bootstrap_generated_without_runtime_mirrors.rs:1040-1048, src/v3/compiler/tests/integration/parse_corpus_manifest.txt:14).

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

Compliant — single-authority metadata / facts flow forward is handled correctly here: the new file explicitly says the local slice is not a second authority (src/v3/compiler/tests/integration/cementing/cementing_lens_registry_dispatch_test.rs:9-13), then derives the required registry names from the capability register plus LensRegistryEntry rows (src/v3/compiler/tests/integration/cementing/cementing_lens_registry_dispatch_test.rs:163-196, :246-277) and checks the projection exactly (:327-341).

1. CODING.md.

Compliant — the new logic is split into small free functions with explicit inputs/outputs (md_table_cells, register_row_has_real_v2_counterpart, read_lens_registry_name_lens_file_pairs, integration_rs_text) instead of methods or hidden mutable state, which matches the data+free-functions guidance (src/v3/compiler/tests/integration/cementing/cementing_lens_registry_dispatch_test.rs:112-126, :198-241, :279-299).

1. TESTING.md.

Finding (BLOCKING) — TESTING.md:369-384 says an escalated claim is not complete until tests/integration.rs “wires” the matching cementing module, but the implementation only treats wiring as raw substring presence. The generic helper describes this as “API-level wiring, not convention-only” yet implements it as integration_rs.contains(&expected) (src/v3/compiler/tests/integration/cementing/cementing_lens_registry_dispatch_test.rs:291-297, used at :345-358), and the SG-6 self-ratchet does the same with text.contains(attr) / text.contains("mod cementing_lens_registry_dispatch_test") (src/v3/compiler/tests/integration/sg6_hand_authored_census_test.rs:468-477). That can be satisfied by commented-out or stale text in tests/integration.rs without actually linking the module, so the new same-PR dispatch rule is still convention-checked rather than structurally enforced.

1. LOCKED DESIGN DECISIONS.

N/A — no locked thesis/design surface is altered; the new prose explicitly narrows itself to Band-C cementing dispatch and says it does not require new substrate accessors or full lens equivalence (TESTING.md:386-389).

1. TRACKED vs UNTRACKED DEBT.

Compliant — the only intentional duplication is the local provenance Behavior -> Origin mirror, and it is documented, bounded, and given a maintenance trigger in-file (src/v3/compiler/tests/integration/cementing/cementing_lens_registry_dispatch_test.rs:15-23, :81-89), so this does not read as untracked scaffold debt.

3. Verdict

REQUEST_CHANGES

The projection/ratchet design is thoughtful, and the provenance seam test plus census wiring show real discipline. But the core guarantee this PR is adding — “the cementing module is wired into the integration harness” — is currently just a text search over tests/integration.rs, so it can false-green without proving the module is actually compiled into the test crate. Since that guarantee is the point of the PR, I’d harden that check before merge.

[briansrls]

Review metadata

• Provider / model: claude / claude-opus-4-7
• Commit: 0b9bf1ef · Trigger: schedule
• Thinking: 95s wall

---

Review of PR #638: test generalization

This PR establishes Band-C cementing discipline: a TESTING.md section, a dispatch ratchet wired to regen.dag + docs/v3-lens-capability-register.md, and a first cementing module pinning the provenance.dag COMPLETE row.

Findings

Nothing blocking. Some observations:

• src/v3/compiler/tests/integration/cementing/cementing_lens_registry_dispatch_test.rs:82-91 — the local expected_origin_from_producer_behavior mirror of origin_for_behavior is a deliberate test-oracle, not a parallel authority (it only reads; it cannot cause production divergence), and the comment at lines 15-23 names its drift-update trigger. So it clears the "tracked debt" bar (documented, bounded, named trigger). Worth flagging only because duplicating a shipped lookup table in an integration test always reads like parallel representation at first glance — the docstring does defuse it.
• src/v3/compiler/tests/integration/cementing/cementing_lens_registry_dispatch_test.rs:344-349 — provenance_origin_of_cements_complete_row_via_compile_to_dag_fixture bundles two fixtures (lit and sum) under one #[test], each exercising a different Behavior variant. TESTING.md §4 "One claim per test" would prefer these as two tests named after the variant under witness. Non-blocking (both cement the same contract surface), but the split would read more cleanly once Transform / Branch / Loop fixtures land.
• src/v3/compiler/tests/integration/common/mod.rs:83-92 — integration_rs_line_is_active_for_wiring_check treats only //-prefixed lines as inactive. Block comments (/* … */) would false-green. Not a real risk against the current integration.rs style, but worth a one-line note in the helper docstring if you want the constraint made explicit rather than implicit in the file it's protecting.

The bootstrap-generated diffs are mechanical span shifts from the new regen.dag header comment; nothing semantic.

Verdict

APPROVE — the diff is tightly scoped to process/test infrastructure, the CEMENTING_MODULES_FOR_V2_COMPLETE_CLAIMS slice is a derived projection (not a second authority) and is correctly empty given every current COMPLETE row is None (v3-native), and the SG-6 outer ratchet correctly handles the "mod line deleted = whole subtree goes dark" failure mode that an in-module test cannot self-check. Observations above are refactor-on-touch, not blockers.

[briansrls]

Review metadata

• Provider / model: codex / gpt-5.4
• Commit: 0b9bf1ef · Trigger: schedule
• Thinking: 203s wall

---

Findings

• NON-BLOCKING: src/v3/compiler/tests/integration/common/mod.rs:84 implements the new “active line” check by excluding only lines whose first token starts with //, and the new ratchets rely on that helper at src/v3/compiler/tests/integration/cementing/cementing_lens_registry_dispatch_test.rs:312 and src/v3/compiler/tests/integration/sg6_hand_authored_census_test.rs:470. That means /* #[path = ...] */ or /* mod ... */ in tests/integration.rs would still count as “active,” which falls short of the new TESTING.md cementing-dispatch guarantee that commented-out text does not count, and leaves the enforcement weaker than the stated API-level/mechanical ratchet.

Verdict: APPROVE_WITH_COMMENTS. The diff is narrowly scoped and otherwise lines up with the new TESTING discipline; I didn’t find substrate/modeling violations in the actual PR delta. I also spot-checked the new cementing/SG-6 tests locally and they pass.

[briansrls]

Review metadata

• Provider / model: codex / gpt-5.4
• Commit: 7255543c · Trigger: schedule
• Thinking: 348s wall

---

Non-blocking — Strengths

• src/v3/compiler/tests/integration/common/mod.rs integration_rs_active_line_contains follows the testing-invariant source-audit exception by ignoring commented and string-embedded tombstones rather than treating raw text presence as live wiring.

✅ The new Band-C docs and ratchets stay aligned with the thesis’s single-authority and testing discipline, and I do not see a new blocking concern in the added lines.

[briansrls]

Review metadata

• Provider / model: claude / claude-opus-4-7
• Commit: 7255543c · Trigger: schedule
• Thinking: 107s wall

---

Reviewing the diff. The PR adds testing discipline for Band-C "cementing" claims: a TESTING.md section, a register/regen.dag comment, and a new cementing_lens_registry_dispatch_test.rs with (currently empty) ratchet slice + helpers, plus a sg6 wiring check.

Findings

No violations worth flagging. The scope is test governance and docs; there's no substrate change, and the regen span updates in bootstrap_generated*.rs are mechanical consequences of the regen.dag comment insertion.

Verdict

APPROVE — This is a clean governance ratchet. CEMENTING_MODULES_FOR_V2_COMPLETE_CLAIMS is wired as an empty slice today and cementing_escalation_slice_matches_capability_register mechanically reconciles it against the register + regen.dag, so the ratchet fires when (not if) a row is promoted to COMPLETE with a real v2 counterpart. The sg6 check plus the block-comment/string-aware scanner (integration_rs_active_line_contains) prevent the most obvious false-greens (commented #[path] / mod lines, string-embedded decoys). Nothing in the diff contradicts INVARIANTS/MODELING/CODING/TESTING.

Exploratory observations (optional)

• Mirrored Behavior → Origin table in expected_origin_from_producer_behavior (cementing_lens_registry_dispatch_test.rs:78-85) is a parallel representation of origin_for_behavior from provenance.dag. The file calls this out explicitly, pins the same mapping independently under lens_provenance::tests, and documents why widening the public API to re-export origin_for_behavior was rejected. It's a tracked bridge (documented + bounded + the dissolution trigger is the eventual .dag-native test infra / DB-15). Fine today; worth revisiting if more integration-side mirrors accumulate.
• Scanner scope (common/mod.rs:78-170) disclaims raw strings, byte strings, and char literals. That's defensible for today's tests/integration.rs surface, but a stray '"' or r#"..."# in that file would silently break the scanner's state machine. If that file ever grows such literals, the scanner needs to learn them — worth a one-line assert on entry (e.g. reject any r#" or ' that isn't inside a doc comment) to make the failure mode loud rather than silent.
• Helper-function unit tests colocated with dispatch ratchet: md_table_cells_preserves_escaped_pipes…, register_row_has_real_v2_counterpart_matches_testing_md_band_c, and the three integration_rs_active_line_contains_… tests are really unit tests for shared helpers, hosted in an integration module. TESTING.md's "unit before integration" and "one focused module per lens" would nominally put these under tests/unit/. Minor organization question, not a blocker.

[briansrls]

Review metadata

• Provider / model: codex / gpt-5.4
• Commit: 7255543c · Trigger: schedule
• Thinking: 226s wall

---

Findings

• src/v3/compiler/tests/integration/cementing/cementing_lens_registry_dispatch_test.rs:347 and src/v3/compiler/tests/integration/sg6_hand_authored_census_test.rs:468 violate the new TESTING.md Band-C dispatch rule (TESTING.md:380) that a cementing module be wired behind the exact #[path = "integration/cementing/<stem>.rs"] attribute. Both ratchets only check that the #[path = ...] text exists somewhere and that mod <stem> exists somewhere, independently. That means #[path = "..."] mod some_other_name; plus a separate mod <stem>; would still pass, so the test can false-green on precisely the wiring it is supposed to lock down.

Verdict
REQUEST_CHANGES. The diff is otherwise clean and the focused tests pass, but this weakens the core ratchet the PR is adding. Make the assertion verify the #[path] attribute is attached to that specific module, then this looks good.

[briansrls]

Review metadata

• Provider / model: claude / claude-opus-4-7
• Commit: 05f71c15 · Trigger: schedule
• Thinking: 186s wall

---

Findings

Nothing violating INVARIANTS.md, MODELING.md, CODING.md, or TESTING.md. The PR is test + docs infrastructure; the generated-code diff (bootstrap_generated*.rs, parse_corpus_manifest.txt) is pure span-shift from the new regen.dag header comment.

Verdict: APPROVE — tests/integration/cementing/cementing_lens_registry_dispatch_test.rs derives its required-slice from docs/v3-lens-capability-register.md + regen.dag rather than declaring a parallel inventory (single authority honored); the SG-6 tie-off in sg6_hand_authored_census_test.rs:466 plugs the bootstrap hole where the dispatch module cannot assert its own #[path] wiring; the comment/string-aware scanner in common/mod.rs is explicitly tested (tombstone, block-comment, string-embedded, interleaved-attribute cases) and fails loud on raw/byte strings rather than silently mis-scanning. Empty CEMENTING_MODULES_FOR_V2_COMPLETE_CLAIMS is correct — no current register row is COMPLETE with a real v2 counterpart, so the ratchet is a tripwire, not dead code.

Exploratory observations (non-blocking)

• Ratchet covers only the v2-parity subset. TESTING.md's new §Cementing tests (Band C) says v3-native COMPLETE rows also need pinning "on minimal constructed Dag shapes." The mechanical ratchet (cementing_escalation_slice_matches_capability_register) only fires for rows whose v2 counterpart is non-None/non-N/A. Three currently-COMPLETE v3-native rows (unused_parameters, variant_payload, structural_resolution) aren't covered by any mechanical check. lens_provenance::tests in lib.rs shows the intended shape; worth considering whether a sibling ratchet should assert "every COMPLETE row's lens module has a #[cfg(test)] mod tests with at least N hand-built-Dag cases" so the v3-native obligation isn't purely prose.
• Scanner scope. common/mod.rs parses Rust to validate #[path]+mod binding. It handles //, /* */, nested blocks, "…", and panics on raw/byte strings — but doesn't model char literals or allow interposed line-comments between the attribute and mod <stem>;. Fine for today's integration.rs; if that ever grows a '"' or an explanatory comment between attribute and item, the false-negative will be puzzling. The panic-on-raw-string pattern is the right instinct; consider extending it to ' and to a "comment between #[path] and next item" case so future surprises also fail loud.
• One trivial redundancy. mod_decl_follows_cementing_path_tail calls tail.trim_start() at loop top, then binds let rest = tail.trim_start(); a few lines later — the second trim is a no-op.

[briansrls]

Review metadata

• Provider / model: codex / gpt-5.4
• Commit: 05f71c15 · Trigger: schedule
• Thinking: 213s wall

---

Verdict: APPROVE. Diff is narrowly scoped to test/doc ratchets and regen snapshots, and I don’t see a concrete violation of INVARIANTS.md, docs/modeling-discipline.md, CODING.md, or TESTING.md in the changed lines. The new cementing dispatch stays single-authority by deriving from the capability register + regen.dag, and the focused new tests passed (cargo test -p v3-compiler cementing_lens_registry_dispatch_test:: and cargo test -p v3-compiler sg6_cementing_lens_registry_dispatch_module_is_wired_in_integration_rs).

[briansrls]

Review metadata

• Provider / model: claude / claude-opus-4-7
• Commit: a855ac6a · Trigger: schedule
• Thinking: 200s wall

---

Findings

Nothing in this diff concretely violates INVARIANTS.md, MODELING.md, CODING.md, or TESTING.md. A couple of observations worth recording:

• common/mod.rs:78–229 introduces a ~150-line hand-rolled Rust lexer (line/block-comment/string state machine + #[…] attribute skipper + raw/byte-string panic probe) that lives purely in test infrastructure. This is exactly the kind of "reverse-engineering Rust source shape" P2 warns against when it's in production code, but here the subject is tests/integration.rs (wiring metadata) and the scanner is fail-closed (panics on unmodeled opens) and self-tested at cementing_lens_registry_dispatch_test.rs:145–258. Acceptable test-surface scaffolding; the panic path is the right fail-closed choice for a ratchet.

• cementing_lens_registry_dispatch_test.rs:85–93 duplicates origin_for_behavior's Behavior → Origin table as expected_origin_from_producer_behavior. The test comments at :9–23 and :60–64 explicitly name this as a bounded bridge (crate keeps origin_for_behavior private to pin the public surface to origin_of/Origin; exhaustive pins live in lens_provenance::tests). That's a documented, narrow, tracked duplication, not parallel authority — consumers still read one source. Fine as-is, but if provenance.dag ever edits the table, reviewers must update both sides together (the .dag → generator cascade catches inconsistency only if the oracle is kept in sync by hand).

• cementing_lens_registry_dispatch_test.rs:105: CEMENTING_MODULES_FOR_V2_COMPLETE_CLAIMS is currently empty, so cementing_escalation_slice_matches_capability_register and cementing_test_modules_exist_for_escalated_v2_complete_registry_claims are tautologies today. That's the intended wired-but-dormant state — the only lens now at BEHAVIORALLY COMPLETE is v3-native (provenance.dag). The ratchet engages the first time a v2-counterpart row is promoted. Worth noting the assertion is vacuous today, but structurally sound.

• Commit history nit (non-blocking, process): ~9 WIP: test generalization commits and 2 chore: apply cargo fmt commits. Squash before merge would leave a cleaner log; fix(v3): … / test(v3): … commits already stand on their own.

Verdict

APPROVE — the diff builds out the Band-C cementing dispatch in TESTING.md + the register + regen.dag + a wired ratchet test, plus one real cementing pin for provenance.dag (live seam + in-crate minimal pins). The scanner scaffolding is fail-closed and self-tested, and the SG-6 cross-check closes the "module deleted → its own tests vanish" gap. No invariant violations.

[briansrls]

Review metadata

• Provider / model: codex / gpt-5.4
• Commit: a855ac6a · Trigger: schedule
• Thinking: 269s wall

---

APPROVE

Diff is narrowly scoped to docs/test ratchets, and I didn’t find a concrete violation of INVARIANTS.md, docs/modeling-discipline.md, CODING.md, or TESTING.md in the changed lines. I also ran the targeted v3-compiler checks for the new cementing dispatch and manifest refresh; they passed.

[briansrls]

Review metadata

• Provider / model: codex / gpt-5.4
• Commit: a855ac6a · Trigger: schedule
• Thinking: 277s wall

---

Non-blocking — Strengths

• src/v3/compiler/tests/integration/sg6_hand_authored_census_test.rs The new SG-6 ratchet puts the dispatch-module wiring check at the integration-harness boundary, which matches TESTING.md's requirement that Band-C dispatch be enforced structurally rather than by convention.
• src/v3/compiler/tests/integration/cementing/cementing_lens_registry_dispatch_test.rs cementing_escalation_slice_matches_capability_register keeps CEMENTING_MODULES_FOR_V2_COMPLETE_CLAIMS as a projection of docs/v3-lens-capability-register.md plus the LensRegistryEntry registry, not a second authority.

✅ No blocking concerns in the added lines; the Band-C ratchets now line up the register, regen registry, filesystem, and integration harness cleanly.

[briansrls]

Director convergence review: READY TO MERGE.

Cementing-test discipline generalization (847+/26-, claude + codex clean APPROVE on latest SHA). CI clean across all gates.

Extensive iteration visible in the dashboard history — worker went through multiple feedback rounds, passing CI + cementing-ratchet + Dag-builder-exposure concerns along the way. The final shape is solid:

• TESTING.md section with precise trigger condition + anti-scope
• regen.dag header with obligation at registration time
• Register rule feat(cloud): add cloud resource management layer with GCP and AWS sup… #6 closing the loop from register → test discipline
• Honest-empty ratchet list (will populate when first v2-parity-COMPLETE lens lands)
• Provenance example cementing test demonstrates the mechanism end-to-end

This is load-bearing infra for every future lens work. When the first substrate-carrier-port lands and a lens promotes to BEHAVIORALLY COMPLETE with v2 parity, the author has a clean template to follow and a ratchet that enforces cementing.

Clean convergence. Merge.

🤖 Director review