File the accepted-source-emits-uncompilable-target class: a unit variant in a non-applied type position

[gunbai-bot]

What

TWO authority changes on gunbc.recurring_failure_mode, plus its two regenerated projections (DESIGN.md, docs/design-ledgers.md). No emitter edit — v1_compiler_emit_rust and v1_compiler_infer_emit_info are untouched, they are mid-transaction in a sibling lane.

1. The new row accepted_source_emits_uncompilable_target — the subject of this PR, evidenced below.
2. An appended receipt on the existing merge_region_excludes_shared_tail row (commit 4f533ed2), disclosed here because an earlier revision of this section claimed one row and that was wrong. It is deliberate branch-authored authority content, not conflict repair or generated-projection churn, and it was authored at the manager's instruction while resolving this branch's own integrations.

Evidence boundary for change 2, stated separately because it is a different subject with different evidence: while integrating main, this branch reproduced merge_region_excludes_shared_tail live — git's conflict region excluded the shared evidence: [], / } tail, so taking both sides verbatim severed sealing_property_erases_structure and donated its closing lines to the following declaration. Found by auditing the resulting declarations, not by any marker. The receipt also corrects its own first report: this lane initially claimed the fused file still parsed, which was an inference from reading text; compiling the reconstructed fused shape refuses at expected expression, found Eq, the same diagnostic the row already measured. The class is not re-filed and its recognition rule is untouched — it held. No rung is claimed for change 2; it adds a receipt and a severity correction to an existing row.

The class

gunbc accepts a coproduct's unit variant standing in a non-applied type position — a field, parameter or return type spelled with a constructor — with zero blocking diagnostics, and emits a Rust program rustc refuses. §5 silent wrongness on the source→target path; §7 makes it the seed's floor, not rustc's problem.

Evidence, both halves executed

• Field specimen (neat-otter-332, preserved in the row because its fixture tree was discarded): type Quantity = Time | Memory in scope.provider; type NonApplied { value: Time } and fn field_as_quantity(subject: NonApplied) -> Quantity { subject.value } in scope.consumer. Narrow emitter classifier → error[E0573]: expected type, found variant Time at the emitted field. Broad classifier imports a phantom marker struct Time, so the field-only source compiles — and the same accepted source across its declared parent boundary refuses E0308 expected Quantity, found Time. The mask never preserved the modelled meaning, so the narrow classifier's E0573 is the class becoming visible, not a regression it introduced.
• Parameter position, reproduced on this branch (baeabbbf80): type StampMode = StampClass | StampOther with fn take(stamp: StampClass) -> StampMode { stamp }. gunbc compile --target rust exits 0, 0 blocking errors, one advisory about import listing; emits pub fn take(stamp: StampClass) -> StampMode beside pub struct StampClass;; cargo check on the emitted crate refuses E0308 expected StampMode, found StampClass.

One source defect, three target behaviours — which is why the row says the class must not be read off the rustc code.

§4b fields

• Rung found at: below the ladder, established by execution at the emission boundary. No rung-1 mitigation exists at the .dag boundary.
• Ceiling: 4 (structurally impossible) — constructor identity and type identity are distinct modelled facts, decidable from the coproduct declaration; no undecidable predicate, so a wall and not a ratchet.
• Next-rung trigger (capability, not artifact): type-position name resolution consulting the TYPE namespace alone, refusing a name that resolves to a constructor with a located diagnostic, sufficient that no Accepted program contains a variant name in any non-applied type position. Repairing either specimen or narrowing the classifier does not retire the row.

Scope is stated rather than generalised: unit arms, field and parameter position, Rust target only.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AsNTMSgjX8EPvGHVNo2sNC

[gunbai-bot]

One observation from this PR's integrations that belongs on the record, since it is evidence about a prescribed repair rather than about this change.

merge_region_excludes_shared_tail (landed on main during this PR's lifetime) prescribes its repair as: make the appended unit one line, so the shared suffix is a blank separator carrying nothing. That repair has now been observed working, not merely argued.

• The class firing. Integrating main when sealing_property_erases_structure landed as a multi-line block: git's conflict region excluded the shared evidence: [], / } tail, so the purely additive resolution left that row unterminated and donated its closing lines to the row after it. Caught by auditing the resulting declarations rather than by any marker. Compiling the reconstructed fused shape refuses at expected expression, found Eq — the same diagnostic the row itself records.
• The repair holding. Integrating main when restoration_promise_names_a_route_that_does_not_exist landed in the one-line form: no shared tail existed to be excluded, both sides of the conflict region were complete units, and keeping both sides was the entire resolution. The class did not fire.

Two integrations, same carrier, same session, differing only in the authored form of the incoming row. That is an independent instance confirming the prescription, which is a stronger artifact than a repair that has only been reasoned about.

Procedural note, adopted because skipping it produced a wrong report: resolving a conflict in this carrier now ends with executing the compiler on the resolved file, not with reading it. Auditing for a fusion and establishing what it costs are two different steps, and every signal available without executing — both rows present, no markers, nothing red — agrees with "parses fine".

— sent from vivid-boar-481

[briansrls]

REQUEST_CHANGES at exact head e6572baaf889e6f040760633aeb5642e1383f20f.

The accepted_source_emits_uncompilable_target row remains substantively accepted. Its source/target boundary, measured field and parameter scope, below-ladder standing, structural ceiling, and type-namespace repair trigger are coherent; exact-head CI is green. I am not requesting a redesign of that row.

The blocker is a false subject description. The PR body says the change is one row plus its two regenerated projections, and the queue packet again describes one row and one roster line. The live authority diff contains an additional, deliberate branch-authored edit to the existing merge_region_excludes_shared_tail row: commit 4f533ed2405ca07721200ad8e2a3f3d7211cb09e appends a second sighting and a corrected severity account, and that edit is projected into the two ledgers. It is not merge-only churn and it is not part of the original one-row subject.

Either:

1. remove that unrelated authority edit from this PR, regenerate the projections, and return with fresh exact-head CI; or
2. retain it and correct the PR body/status claim to disclose that #9909 carries two authority changes—the new accepted-source row and the added merge_region_excludes_shared_tail receipt—and state the evidence boundary for both.

If the second path changes only PR metadata and the code head remains exactly e6572baaf889e6f040760633aeb5642e1383f20f, the existing exact-head CI may carry. The bytes of the second sighting are not rejected here; the undisclosed scope is.

Disposition 2 was applied exactly: the PR body now discloses both authority changes, separates their evidence boundaries, and the code head remains byte-identical at e6572ba. The scope-only blocker is closed.

[briansrls]

APPROVE at exact head e6572baaf889e6f040760633aeb5642e1383f20f.

Disposition 2 is satisfied without moving the code subject. The PR body now states that #9909 carries two authority changes: (1) the new accepted_source_emits_uncompilable_target row and roster entry, and (2) the deliberate 4f533ed2 receipt/severity correction appended to the existing merge_region_excludes_shared_tail row. It gives the second change its own evidence boundary, records that the fused-shape parse claim was corrected by execution, and does not re-file the class or claim a rung.

The first authority change remains substantively accepted at its stated scope. The second authority bytes were not rejected; the prior blocker was only their omission from the declared subject. The code head is unchanged, so exact-head workflow run 33527540358 remains applicable and is successful.

#9909 is approved for merge at this exact head. Any code-head movement requires exact-head revalidation.