Nothing enforces `GENERATED-TRACKED` against `scripts/generate.lg`

[mparrett]

• Depends on: build: content-gate every committed generated artifact, not just the bundle #634 (introduces the list)
• Epic: Epic: Maintenance debt — retire superseded mechanisms, reduce process weight #528

Problem

#634 adds GENERATED-TRACKED to the Makefile: the committed generated
artifacts that make check-generated stashes, regenerates, and compares. The comment says "keep this list in step with scripts/generate.lg" and nothing checks that it is.

If generate.lg grows a sixth committed output and the Makefile list is not updated, the gate silently under-covers it. That is the failure #634 exists to fix, reintroduced one level up. Before #634 the gate compared only core_compiled.lgb, which is how zz_primitives_generated.go sat drifted from its generator without anything noticing.

Where the outputs are declared

Four of the five outputs are already named at their call site:

(gen-go   "…/op_generated.head"        "pkg/ir/ir_ops.lg"    "pkg/ir/op_generated.go")
(gen-go   "…/ir_bridge_generated.head" "pkg/ir/ir_bridge.lg" "pkg/rt/ir_bridge_generated.go")
(gen-lisp "pkg/ir/ir_data.lg" "pkg/rt/core/ir/data/generated.lg")
(run! … "./cmd/lginterop" … "-primitives-out" "pkg/rt/zz_primitives_generated.go")

Only core_compiled.lgb is implicit, written inside lgbgen --target=both along with generated.sums and the gitignored lowered tree.

Proposal

Have the pipeline record what it wrote, and have the gate audit its own list against that record.

gen-go and gen-lisp already funnel through helpers, so they can append their out path to an atom. generate.lg writes the collected list beside generated.provenance, which it already emits. check-generated regenerates before it compares, so the record is fresh by the time it reads it: the gate fails if any recorded path is missing from GENERATED-TRACKED.

No git, no filename heuristics, and it works under jj — the record comes from the pipeline rather than from the VCS.

A missing or empty record must be an error, not a pass. Otherwise the check degrades into exactly the silent under-coverage it exists to catch.

Residual gap: core_compiled.lgb still has to be named by hand, because lgbgen does not report its outputs. That shrinks a five-entry list in the Makefile to a one-entry declaration next to the lgbgen call, in the file that invokes it. Closing it fully means teaching lgbgen to report what it wrote, which is a separate change.

Happy to implement this once #634 lands, or to hear that the list is small enough that a comment is sufficient.

Alternatives considered

A Go test that parses generate.lg for output literals. No runtime changes, but it sees only the four declared paths and misses core_compiled.lgb — the one most likely to drift, since it is invisible at the call site.

Deriving GENERATED-TRACKED from the record via $(shell cat …). Removes the duplication, but on a fresh clone the record does not exist, the list comes back empty, and the gate passes vacuously. Worse than the problem.

[mparrett]

Recommendation after tracing the current generation pipeline

The issue is correctly scoped, and I think this should remain a standalone follow-up rather than reopen #634. #634 establishes the content gate; this issue makes its coverage self-auditing.

The count checks out: there are five committed generated artifacts, four named at their call site and only pkg/rt/core_compiled.lgb written implicitly inside lgbgen --target=both.

One small implementation refinement: instrumenting only gen-go and gen-lisp records three paths, not all four explicit ones. pkg/rt/zz_primitives_generated.go is emitted through the direct lginterop -primitives-out invocation, so I would give that invocation a narrow helper (or explicitly record its output immediately beside it). I would not teach generic run! to infer outputs from argv.

I would define the record narrowly as a committed/tracked-output manifest, not a log of every file generation writes. The pipeline also writes generated.provenance, generated.sums, the gitignored lowered tree, and its wireup files; those have deliberately different ownership and freshness rules. Naming the manifest for tracked outputs keeps the invariant precise.

Suggested shape:

1. generate.lg collects the three helper outputs plus the primitives output.
2. It writes the manifest atomically only after the full pipeline succeeds, beside generated.provenance.
3. check-generated, after regeneration, fails if the manifest is missing, empty, contains duplicates, or names a path absent from GENERATED-TRACKED.
4. Keep the bundle as an explicit manual entry until lgbgen can report outputs. Making that exception visible, e.g. GENERATED-TRACKED-MANUAL := pkg/rt/core_compiled.lgb, makes the remaining duplication auditable rather than implicit.

The full static Make list should remain the fresh-clone baseline. The generated manifest should audit that list after generation, not define it through $(shell cat ...); otherwise a missing record can still collapse the gate into a vacuous pass.

I would also keep the audit one-way for this change: every recorded committed output must be tracked. Requiring every Make entry to appear in the record would immediately conflict with the intentional manual bundle exception; that can become symmetric once lgbgen reports its outputs.

Recommended order is #634 → #637 → #635. #635 does not technically depend on this issue, but landing the self-audit before removing the digest preserves the strongest transition: first direct content coverage, then coverage-of-coverage, then retirement of the proxy manifest.

So my vote is to implement this after #634 lands. The list may be small today, but this is exactly the kind of invariant that only fails when someone adds the sixth output and reasonably assumes the existing gate covers it.