Lens registry completeness: enroll unenrolled lenses at handler-grain (W3.3)

[gunbai-bot]

Worker attestation

• Title describes the change (not the session id or branch).
• PR body summarises what and why.
• Tests run: claim_batch scoped runs (below); result: PASS.
• No commits on this branch are surprises.
• No secrets / credentials / large binaries staged.

Summary

Enrolls the previously-unenrolled real lenses into LensIdV0 at handler grain (mandate W3.3), so every real invariant-handler lens is nameable by a contract and gateable — prerequisite for the Question-0 self-enforcement wall.

Census (step 1 — ground the roster in what EXISTS)

Live census of src/v2/lens/**/*.dag (excluding *_test.dag):

• 65 modules at depth 1 relative to the v2.lens. prefix (v2.lens.<name>) — each either a genuine distinct top-level lens, or already-known infra (registry, module_graph, affected_set, affected_set_examples, application, application_serializer, edit_locus, reference_deps, testgen).
• 25 modules at depth 2 (v2.lens.<parent>.<child>) — confirmed every one is an internal implementation file of an already-enrolled depth-1 parent (e.g. cost., idempotency., parallelism., ownership., structural_resolution., application., enforcement., common., …).
• No depth-3+ modules exist anywhere in the corpus.

LensIdV0 grew from 10 → 53 variants; lens_registry_v0 / lens_registry_v0_required_ids extended to match, lens_id_v0_eq given self-matching arms for all 43 new variants (it is a total match).

Grain (step 2 — one id per distinct invariant-handler)

Grain = one LensIdV0 per distinct verdict+remedy, not per module. Three modules were deliberately not given their own id because they consolidate onto an already-enrolled invariant (kept in lens_registry_completeness_consolidated_roster_note in src/v2/lens/registry/completeness.dag):

• v2.lens.wiring_liveness_preflight → shares WiringLiveness's graph_invariant reachability handler (only the corpus entry point differs).
• v2.lens.identity_captured_navigation → projects findings into DependencyFidelity's UnderClaimedEdge verdict rather than a bespoke verdict type.
• v2.lens.grounding_ledger → vocabulary/support types consumed by Grounding (GroundingVerdict, LedgerEntry), not a second checked invariant.

Two modules that look like a fork candidate were kept as two distinct ids on purpose: v2.lens.structural_similarity and v2.lens.simulated_relationship both call the shared chain_generalization.chain_collapses kernel with different parameters, and each self-declares dissolves_to: SingleAuthority as a pending future-wave dedup — but today they are two distinct call sites with no single module to bind one id to, so both are enrolled (StructuralSimilarity, SimulatedRelationship) rather than force-merged or dropped.

Enrollment (step 3)

LensIdV0 variant + LensRegistryEntryV0 + append to lens_registry_v0 and lens_registry_v0_required_ids for each of the 43 newly-enrolled lenses; lens_id_v0_eq extended with matching arms (still total).

Frontier (step 4 — receipt half out of scope, counted not faked)

41 of the 43 newly-enrolled lenses land as LensContract rows with no CoverageReceipt yet (gated on fn_body_reflection_blocker — the receipt mechanism needs fn-body reflection that doesn't exist yet). These are tracked as a counted, typed, dissolve-on frontier list — lens_contracts_pending_fn_body_reflection in src/v2/lens/enforcement/contract.dag (lens_contracts_pending_fn_body_reflection_count() == 41) — never a silent gap or a fabricated green receipt. gate.dag's existing find_receipt → ReceiptAbsent → typed LegFails mechanism was reused as-is (generalized via this list, not forked).

Completeness mechanism (this PR's fix)

src/v2/lens/registry/completeness.dag walks the live tree (module_declaration_facts_live) and flags any real v2.lens.* module that is a genuine top-level candidate and unbound in lens_registry_v0. Its nested-submodule exclusion previously relied on a hand-maintained prefix roster that was missing several real submodule directories (cost., idempotency., parallelism., ownership., structural_resolution., application., …), which made lens_registry_completeness_holds_live a false-positive gap. Replaced with a structural, single-authority rule: split the module name on . and treat >3 segments after the v2.lens. prefix as a nested submodule — this matches the confirmed corpus fact (depth 1 or 2 only, never 3+) and needs no further hand-maintenance as new submodules are added.

RED control (step 6)

lens_registry_completeness_red_control_catches_missing_lens (fixture-based) proves the completeness mechanism catches a genuinely-missing real lens — a deliberately-unenrolled fixture module is flagged as an unenrolled candidate.

Test plan

Scoped claim_batch runs (source roots src/v2, dag):

• src/v2/lens/registry/completeness_test.dag: lens_registry_completeness_holds_live, lens_registry_completeness_red_control_catches_missing_lens, lens_registry_completeness_clean_when_fully_bound — PASS (all 3).
• src/v2/lens/registry/sg_claims_test.dag: lens_registry_required_ids_resolve_holds, lens_registry_singleton_row_counts_holds — PASS (both).
• src/v2/lens/enforcement/gate_test.dag: all 11 tests — PASS.

Confirmed no sibling-lane drift: lens_id_v0_eq is the only exhaustive match over LensIdV0 in the corpus (checked standing_intent.dag, gate.dag, dag/gunbc/plans/self_applying_lenses.dag — none match exhaustively on LensIdV0 itself). git diff --name-only origin/main...HEAD confirms only this PR's 5 files changed.

Final confidence via CI (this PR), not local-only, per mandate step 6.

[gunbai-bot]

Re review 38857: agreed the per-variant lens_id_v0_eq match-arm expansion is a preexisting pattern (this PR extends the existing roster with 43 arms, doesn't introduce the shape) — folding it onto a derived-equality authority is a real improvement but changes how LensIdV0 equality is generated corpus-wide, which is out of this mandate's additive-rows scope (W3.3 is enrollment only). Leaving as a follow-up per the reviewer's own note; not blocking here.

— sent from still-raven-540

[gunbai-bot]

CI failure (generated_artifact_drift_gate_passes) traced to inherited stale state, not this PR's diff: my branch was based on afb9e14 (#6733), which drifted .github/live-deploy-srv1-apply.sh from its .dag authority; main already fixed this in cc60d91 (#6745) before I opened this PR. Merged origin/main (clean, no conflicts) to pick up that fix — git diff --name-only origin/main...HEAD still shows only this PR's 5 files. Re-running CI on the merge commit.

— sent from still-raven-540