Mechanical: TargetModel carries ProducedDeclSupport, unwired everywhere

[gunbai-bot]

Pure field addition. No behavior change anywhere. Split out deliberately so the architecture it enables is reviewable on its own rather than buried in churn — this PR is the churn, and it should read as nothing but churn.

What

TargetModel gains produced_decl_support: ProducedDeclSupport, at 105 TargetModel record literals across 54 files, plus the type definition and its imports.

Census correction. An earlier version of this body said 106 literals across 55 files. That count was wrong, and wrong in an instructive way: the mechanical pass matched TargetModel { excluding a -> prefix, which also matches type TargetModel { — so the script inserted an initializer into the type body, and the same flawed pattern then counted that site as a construction. The edit and its verification agreed because both were wrong in the same way. A count derived from the same predicate as the edit cannot verify the edit. Recounted with the type definition excluded: 105 literals, 105 fields, zero missing.

Why the shape is a coproduct, not an optional with a default

ProducedDeclSupport = ProducedDeclUnwired | ProducedDeclWired { render, scaffold_relation_rule_name, scaffold_base_row }.

There is deliberately no default that renders — such a default would be a fabricated plausible output at every unwired site simultaneously, and would make an unwired-target refusal unreachable by turning every unwired target into a quietly-working one. The bad state has no constructor rather than being avoided by discipline (DESIGN §5).

Why a function on the carrier rather than data in the Node bundle

Rendering depends on the declaration, and a function cannot survive Node encode/decode — which is what the target's bundle is. token_class_emit_transforms is already a function-valued field on TargetModel, and is the precedent for both expressibility and placement.

Why this is not a compiler-side slot template

A template puts signature order in the compiler, so the terminal architecture deletes it. A renderer puts order in the target — so when the GrammarRelationRow forward reading lands, each renderer's body changes to derive from rows while the seam (compiler asks, target renders) survives untouched.

Construction sites classify into two kinds, not three

FRESH constructors take an explicit ProducedDeclUnwired (target_model_make_with_emit_transforms is one — every field is a parameter, no source target). DERIVED constructions preserve source.produced_decl_support. There is no intentional capability removal site; nothing in the corpus means to drop the capability, so an incidental reset cannot hide among deliberate ones.

A blocking defect was found and fixed here: augmenters rebuild a TargetModel field-by-field and the inserted field was reset rather than copied, so an ordinary augmentation dropped the capability. Invisible today (all targets unwired ⇒ the reset is a no-op) and fatal once anything is wired. Auditing for the shape rather than the two reported names found ten such sites: both production augmenters, two in extdeps/languages/dag.dag, six in rust_test_fixtures.dag.

produced_decl_support_preserved_test proves preservation by executing the surviving renderer, since equality over function values is unavailable — a comparison could not have caught this class. Both augmenters are driven with nonempty input deliberately, because each returns its argument unchanged on empty input and an empty-input control would pass without reaching the reconstruction. Unwired negative controls keep the positive arm from being satisfied by a constant. This also gives ProducedDeclWired its first constructor and consumer.

Named limit

Stated in the carrier: the compiler no longer knows how a declaration closes, but still knows it is prefix → body → suffix, because that is TargetBodiedArrowStatementScaffold's shape — pre-existing, shared by every bodied arrow, consumed by 06_translate. A target whose signature follows its body needs the body-scaffold lane.

Review notes

• Apparent deletions are single-line import ... { ... } statements reflowed to multi-line; no symbol is removed.
• A brace-imbalance warning in rust_test_fixtures.dag is pre-existing at origin/main (a brace inside a string literal).
• Not adopted here, deliberately: a target_model_with_bundle(target, replacement_bundle) helper so the next field addition need not touch every constructor. It is a genuine cost-shape point rather than style, but it is a refactor of its own and this PR is meant to stay pure churn.

Follow-on PR moves signature order into the Rust handler, registers C, and proves another target can register without a compiler edit by executing both targets through one API.

[gunbai-bot]

Verified and fixed in 7028dd175b. Review 51155 is correct on every point — the type body carried produced_decl_support: ProducedDeclUnwired, which names a variant constructor where a type belongs, alongside the real produced_decl_support: ProducedDeclSupport declaration. It would not typecheck.

Cause, worth naming because it also corrupted my verification. The mechanical pass matched TargetModel { excluding a -> prefix — which also matches type TargetModel {. So the script inserted an initializer into the type body. The same flawed pattern then counted that site as a construction, so my "106/106 complete" was the edit and the check agreeing with each other because both were wrong in the same way. A count derived from the same predicate as the edit cannot verify the edit; that's on me, not on the reviewer for catching it.

Recounted with the type definition excluded: 105 true record literals, 105 unwired fields, zero missing. The earlier 106 included the type definition itself.

One thing this did not invalidate: the separately-found rust_produced_decl_target site was a genuine record literal that my patch had missed (it is deleted on the follow-on branch, so the patch was generated from a tree where it did not exist). That fix stands and is unrelated to this defect.

The PR remains what it claims to be — a pure field addition with no behavior change, now at 105 sites.

[gunbai-bot]

The observation in review 51163 is correct and I want to answer it rather than let the PR title carry the whole justification.

ProducedDeclWired genuinely has no constructor and no consumer in this diff. That is specification-without-execution in the §5 sense, and the fact that it is intentional staging does not make it not-so — it makes it staged debt with a stated owner. The split was deliberate (the architecture is unreviewable buried in 105 sites of churn, which is how a substantive gap in the sibling PR drew two approvals before I found it myself), but the honest framing is that this PR's wired arm is a promise, and the follow-up is where it either becomes real or should not exist.

So the commitment, stated so it is checkable rather than assumed: if the follow-up does not land the wired arm with an executing consumer — Rust rendering its own order, C rendering its own, both driven through one compiler API with no compiler edit between them — then ProducedDeclWired should be reverted out of the type, not left sitting as an unconsumed variant. An unconstructed coproduct arm that outlives its follow-up is exactly the parallel-representation debt DESIGN warns about, and "it was staged" would not excuse it.

What this PR does earn on its own is narrower and I would not claim more: the Unwired arm is constructed at every one of the 105 sites, and regen — the self-host fixed point, which requires the corpus to typecheck — is green on this head, so the field addition is verified by execution rather than by inspection. That is the whole of the claim.

No change pushed for this; flagging only.

— sent from wise-swift-269

[gunbai-bot]

Verified and fixed in 72675ce0ca. Review 51220 is correct: DagBodiedFnFamilySpec carries inhabitant_field, emitted_fn, grammar_row, source_literal, production_binding, authority_source_text, relation_rule and scaffold — no produced_decl_support — so spec.produced_decl_support is an undefined field access and would fail typecheck.

Root cause, mine. The preservation pass inferred "this construction derives from a source target" from a field read like <var>.authority_source_text. spec is a DagBodiedFnFamilySpec — a descriptor that happens to share a field name — not a TargetModel being reconstructed. Sharing a field name is not deriving from a target, and my heuristic could not tell the difference.

Took your second option: these sites build a fresh target from a descriptor (bundle derived from the spec, lex: dag_lex()), so ProducedDeclUnwired is the correct value and no spec field is warranted. Adding one would have invented state on a descriptor to satisfy a bad inference.

Re-audited in both directions rather than only the two reported lines, since a misclassification can go either way:

Preserving, each verified to have a genuine TargetModel source — the two target_model_augment_* reconstructions (parameter is target: TargetModel) and six rust_test_fixtures staging targets (let base = <...>_target_model_staging()).

Correctly not preserving, and deliberately left alone — the two Python/Go targets in test/fixture/rung_5_6_common.dag. They borrow only the Rust target's bundle while supplying VoidLexRules, empty binding spellings, and their own source text and runtime row. They are different-language targets, not reconstructions; preserving there would hand a Python target a Rust renderer, which is exactly the mismatch this coproduct exists to make unwritable. That one is a judgment call rather than a pattern match, so I am flagging it explicitly rather than leaving it implicit in the diff.

Net: 8 preserving sites, 2 reverted to unwired, 2 unwired by design.

[gunbai-bot]

No fix needed for review 51227, but one correction to the record, because it credits me with something I did not do.

The review says the commit series "caught its own bug" regarding the augmenters that reset produced_decl_support. It did not. That defect was found by a program review and relayed to me; I verified it against the code and fixed it. What I contributed was auditing for the shape rather than the two reported call sites, which turned two reported instances into ten — and then, after a second reviewer caught my over-correction, re-auditing in both directions to land on the final 8 preserving / 2 reverted / 2 unwired-by-design split.

Worth stating precisely because the provenance is the interesting part: three defects in this PR were caught by review, not by me. The type-body insertion (review 51155), the augmenter reset (relayed program review), and the spec.produced_decl_support over-correction (review 51220). They share one root — each time a mechanical rule was applied uniformly across a non-uniform population, and my verification reused the same predicate as the edit, so it could not fail. The regex counted the sites it had itself matched; the preservation heuristic classified by the signal it had itself keyed on.

That is also why the regression control is built the way review 51227 credits: it executes the surviving renderer rather than comparing, and it drives both augmenters with nonempty input, because each returns its argument unchanged on empty input and an empty-input control would pass without ever reaching the reconstruction that carries the defect. A control that cannot fail is the thing that let all three through.

Status: build passing on this head, regen and heal_generated_artifacts still running, ci not yet reported. I am treating executed checks on this exact head as the acceptance signal — an earlier poll of mine exited on "no checks reported" and would have read as settled, which is the same absent-evidence-scores-as-pass trap.

— sent from wise-swift-269