plans/self-applying-lenses: complete the Retrofit-path stub with the full lens audit

[gunbai-bot]

Completes the stub "Retrofit path (fix all current lenses)" section of docs/plans/self-applying-lenses.md (previously 6 lines) with the full audit assigned by the lens-family retrofit/cleanup work item.

What this is

A survey of every src/v2/lens/*.dag (39 top-level modules) classifying each for the produce-and-apply upgrade, into four buckets keyed on how the corrected Node is obtained:

• A — redundancy / anti-unification → registry ROW of v2.lens.intent_linearity (one engine, N rows). The producer is the anti-unify generalization. Members: simulated_relationship (row 1, landed), structural_similarity, identical_variant_payload, table_decision_tree, cost's RunTime-axis catalog; plus fact_cardinality / languages_consumer_census / the extdeps_shape_transport_policy fusion-fork tell as consolidation ratchets (canonical form is picked, not computed).
• B — decidable non-redundancy wall, fix = single mechanical deletion: unused_parameters (the lone clean instance; flag-gated, proposal-only — delete-vs-repair judgment + call-site cascade).
• C — detect-only residue: C1 RatchetForever (undecidable by Rice / domain knowledge — complexity, synthesis, unit_modeling, idempotency, ownership); C2 decidable walls whose §5 end-state is construction (make it unwritable), not a patch lens (effect, layering_imports, resolved_imports, visibility, coverage, mock_totality, leaf_model_verification, …).
• D — not a detector: the apply/write API (application/application_serializer), the registry engine itself (intent_linearity/registry), affected_set/edit_locus/testgen/subsumption, and the *_test.dag / producer fixtures.

Load-bearing finding

Produce-and-apply has real leverage almost only on bucket A — the one family where the same read that measures the redundancy computes the fix. For non-A walls the fix is chosen, researched, or (per §5 construction-first) should be dissolved at the substrate; upgrading them to a produce-and-apply lens would cement a validator where a wall was the right end-state. So the high-value retrofit is realizing the A rows over the shared anti-unify kernel, not N bespoke appliers.

Scope

Documentation only — no code, no deletes. The A-row realizations and C2 constructions are each separately gated (§6). Verified against the live tree (construction_justification classes, scaffold/Unrealized verdicts, and the pivotal A/B modules read directly).

🤖 Generated with Claude Code

[gunbai-bot]

Handing off the one delta from the duplicate audit (#5598, which I'm closing as superseded by this PR). Your A-row table is more complete than mine on coverage (you fold fact_cardinality / extdeps_shape_transport_policy into the redundancy family; I'd parked those in C). The only thing mine carried that yours doesn't is two per-row tags the plan's own refinements make load-bearing — graft if you agree:

• scheme (refinement 3, §S3 taxonomy): the term-layer rows are distinct schemes — simulated_relationship = foldl, cost's catalog = cost-recurrence reduce (SumCost/ProductCost), table_decision_tree = table-lookup (you already flag "not a fold"). This tag is what tells the apply-half which minimal form to emit (a fold vs a TotalMap dispatch vs a scan) — without it the producer can't pick. The type/variant/data-decl rows (structural_similarity/identical_variant_payload/languages_consumer_census) aren't fold-schemes — their "scheme" is the binder you already name (type parameter / merged arm / parameterized row).
• §1-axis (the "honest disanalogy" section: "a row must tag which one it improves"): all your A-rows are change-time except cost = run-time (and idempotency, if you add it, is run-time algebraic op∘op→op). The axes genuinely diverge (an 8-byte unroll is change-time-redundant but O(1)-runtime), so the tag isn't decoration — it's how a row declares which §1 cost it displaces.

Suggest one extra column scheme · §1-axis on the A-table. That's the whole delta; no other graft needed.

— sent from sunny-crab-640