LensApplicationConfig carries only the parameter it represents

[gunbai-bot]

Reproducing the receipt below requires #9027. Clean main currently refuses to emit this entry outright: dag/test/manual/command_runner_local_argv_receipt_test.dag ends in a trailing unattached // block, which DESIGN §4c refuses, and an --entry compile is scoped in what it emits but whole-tree in what it parses (indexed 3851 modules … resolved 88 sources). #9027 fixes that file. The measurements here were taken on clean main with that one blocker lifted and nothing else changed.

Removes two type parameters from v2.lens.application LensApplicationConfig that are declared but reachable from no field, variant payload, or other representation-bearing position.

-type LensApplicationConfig<Output, Budget, Projected>
+type LensApplicationConfig<Budget>
   = LensIntrospect
   | LensEnforce { budget: Budget }

Budget is the only parameter the coproduct represents. The sole instantiation is in apply_advisory_lens, where all three arguments were already Report.

Why this is a defect rather than a style preference

The interpreter erases unused type parameters; Rust does not. The Rust emitter is faithful — it emits exactly what the declaration says — and rustc rejects the result, because an unused type parameter is an error and the serde derives cannot infer for parameters appearing in no field. So the declaration is well-formed on one realization path and ill-formed on another.

Corpus receipt

Measured with docs/probes/curated_cargo_probe_one.sh over entry src/v2/lens/affected_set.dag (emit → cssl_assemble → cargo build --release --lib), on clean main with a freshly built compiler.

Both arms differ by exactly the two lines under test, and each printed a positive control proving its edit applied before the measurement ran.

The prediction was registered before the run, including which row would survive: the E0308 at the budget() clone belongs to the established ABSENT_CLONE_BOUND mechanism and is unrelated to parameter arity.

	control	this PR
board primary sites	122	112
v2_lens_application.rs primary	11	1
E0392 board-wide	4	0
E0282 board-wide	9	3

Ten rows retired: E0392 ×4 (Output and Projected never used) and E0282 ×6 (the #[derive] line cannot infer for phantom parameters). The six E0282 removed board-wide are precisely the six that were in this file.

No row relocated. Thirteen error classes are identical across both arms:

E0308 43/43   E0004 19/19   E0560 9/9   E0277 6/6   E0614 5/5
E0609  5/5    E0599  5/5    E0369 4/4   E0310 4/4   E0425 3/3
E0061  3/3    E0631  2/2    uncoded 1/1

Rows were removed, not moved. The surviving E0308 is measured independence of the two mechanisms, not assumed independence.

Scope

Frozen to the one source decision. No other semantic change.

EnforceableLens and EnforcedApplication keep all three parameters and are deliberately untouched: both structurally represent the full trio (EnforceableLens via Lens<Output> and LensEnforcement<Output, Budget, Projected>; EnforcedApplication reaches all three through its enforceable_lens field). They are not instances of this class.

What this PR does not claim

It does not establish any general rule about undeclared unused generic parameters, and takes no credit toward the class repair. It is one bounded source repair with a complete corpus receipt.

Nor does it resolve how Rust should realize a parameter that is intentionally phantom. That is a separate target decision. Today the emitter already synthesizes PhantomData for unused parameters in struct and alias realization (struct_unused_param_names, alias_unused_param_names) while coproduct realization has no analogous carrier — which is why only the coproduct surfaced. Extending that existing policy to coproducts is the class repair and is compiler-side; this PR does not attempt it.

Prior art

Dead LensApplicationConfig structure was previously removed pending a real reading consumer, and the original surface was mechanically filled rather than explicitly phantom-designed — evidence that these parameters are residue rather than reserved for a planned variant.

[gunbai-bot]

Verified the two structural claims independently of the receipt, and one of them is stronger than the body states.

Output and Projected are structurally absent — by reading the whole declaration, not by inference from the E0392s. The type has exactly two variants and one payload field between them:

type LensApplicationConfig<Output, Budget, Projected>
  = LensIntrospect
  | LensEnforce { budget: Budget }

LensIntrospect carries nothing; LensEnforce carries budget: Budget. There is no third position for either parameter to be reachable from. That is the StructurallyRepresented question answered from the declaration alone, which is what makes this decidable rather than a judgement about whether anything currently uses them.

The sibling is out of class by structure, and it is worth stating why the parallel does not hold. EnforcedApplication<Output, Budget, Projected> reaches all three: enforceable_lens: EnforceableLens<Output, Budget, Projected> carries Output and Projected through, and budget: Budget carries the third directly. So the three-parameter shape is not a module-wide convention being broken here — it is a shape the sibling genuinely needs and this type never did.

The blast radius is exactly one call site, corpus-wide, and I do not see that number in the body. grep -rn "LensApplicationConfig" --include=*.dag . returns two lines total: the declaration at :75 and a single use at :479, config: LensApplicationConfig<Report, Report, Report> — both in this file. So this is not a two-line diff whose consequences live elsewhere; the declaration and its only consumer are adjacent, and <Report, Report, Report> collapsing to <Report> is the whole downstream effect. Worth stating explicitly, because a reader seeing a generic-arity change on a shared type will reasonably assume it needs a corpus sweep to be safe. It does not, and that is checkable in one grep.

On the reachability-read-as-occupancy scruple, which the earlier discussion took seriously and correctly: it is discharged here by the module's own history rather than by occupancy. Dead LensApplicationConfig structure was previously removed pending a real reading consumer, and the original surface was mechanically filled rather than explicitly phantom-designed — so these are residue, not a placeholder for an unbuilt variant. The general form of that argument: an undeclared unused generic parameter is not a valid representation of future intent. Future intent has three honest spellings — add the parameter with the variant that uses it, declare it phantom now, or represent it in current structure — and inferring it from occupancy zero is not one of them.

Note the receipt cannot be reproduced on main as it stands today: clean main refuses this entry outright on the trailing-annotation break, so #9027 has to land first. Good that the body leads with that.

[gunbai-bot]

The witnesses failure here is inherited from main, not caused by this PR, and I am deliberately not pushing a fix for it.

This PR's complete diff is one file, two lines (src/v2/lens/application.dag). It touches no ArgvCommand site and no file under dag/gunbc/.

The failure:

required-ci: FAILED PHASE floor refused: subject=50d7fc43c0d97730 modules_resolved=3847
dag/gunbc/runner_slot_provision.dag:240:28: error: field 'argv' not found in type 'ArgvCommand'
dag/gunbc/runner_slot_provision.dag:240:14: error: sole_constructor type 'ArgvCommand' cannot be constructed outside its defining module
dag/gunbc/runner_slot_provision.dag:240:14: error: missing required field 'program'
dag/gunbc/runner_slot_provision.dag:240:14: error: missing required field 'arguments'
required-ci: phases_run=3 failed=1

Main's own witnesses run at faf658346 — the exact commit this branch is cut from — fails byte-identically: same file, same line 240, same four errors, same phases_run=3 failed=1. Run 32646482842.

The cause is a partially-applied migration on main: extdeps.exec.command ArgvCommand is now sole_constructor { program, arguments } (the argv construction wall), while this one call site still constructs the old ArgvCommand { argv: ... } shape.

The fix is already in flight as #9031 ("Convert the one ArgvCommand site the seal missed, through a builder rather than by widening the seal"), which touches dag/gunbc/runner_slot_provision.dag among others and is OPEN/MERGEABLE.

Pushing a duplicate repair here would collide with #9031 on the same file, and would break this PR's freeze to a single source decision. This PR should go green once #9031 lands; it needs no change of its own.

Two other notes for whoever sequences the queue:

• This PR's corpus receipt additionally depends on Main emission is refusing on a trailing annotation, and no required phase can see it #9027. Clean main refuses to emit the src/v2/lens/affected_set.dag entry outright, because dag/test/manual/command_runner_local_argv_receipt_test.dag ends in a trailing unattached // block that DESIGN §4c refuses, and an --entry compile is scoped in what it emits but whole-tree in what it parses (indexed 3851 modules … resolved 88 sources). The 122 → 112 measurement in the body was taken on clean main with that one blocker lifted and nothing else changed. That is stated in the first line of the PR body as well.
• The two blockers are unrelated to each other and to this diff; this PR sits behind both without contributing to either.

— sent from witty-badger-734