fix(codegen): reconcile the tree wherever a codegen target is in the run

[raphaelvigee]

A codegen target's contract is about the tree: copy says "this generated file lives here, and the provenance xattr keeps glob() off it"; in_place says "these committed files are the transform's output". Neither claim gets weaker because the run reached the target through a dependent or a group instead of naming it — that changes what the user typed, not what the graph says the tree should hold.

Both write-backs were gated on is_top, so it did.

The case that bites

The fully-cached one. When the dependent hits the cache, inputs_result_exec never runs, so the codegen target is only ever hashed (OutputMatcher::None, via meta) and no frame touches the tree. A pre-existing unstamped file at a copy path — checked in, or generated before the target owned it — then stays visible to every glob that walks the package, and the tree quietly disagrees with the graph.

Running the target directly always worked; that path was verified against the real binary (fresh execute, cache hit, glob output, directory output) before anything was changed.

The change

One pass over both modes, on every frame that resolves the target — top-level, dependent, and the meta walk — single-flighted per addr per request on a new mem_codegen_tree cell, so the tree is written once however many frames offer it. It fetches any codegen group the calling frame did not ask for (a dependent reads one group, the meta walk reads none), so the result does not depend on which frame arrives first. Blobs that are cached but no longer obtainable skip with a debug!: nothing to write is not a reason to fail a build that asked for something else.

The is_top gate on in_place was never justified in the commit that introduced it (bbee1786, "fmt-like codegen"); every comment explaining it since was written after the fact. Its effect was that heph run //pkg:fmt formatted and heph run //pkg:consumer (which depends on fmt) did not.

Three gates travel together, so all three moved:

• the write-back itself;
• check_in_place_inputs_unchanged, now inside the single flight rather than beside it — it exists to protect that write, so one write, one guard;
• maybe_store_fixpoint, likewise, or a dependency-reached formatter would write the tree and re-execute on every subsequent run.

--frozen — a real behaviour change

--frozen became request-scoped (RequestState::frozen) because dependency frames resolve with ResultOptions::default() and would otherwise never see the flag. It now reports a codegen divergence reached through a dependency.

It has to. Once dep frames materialize, a frozen check that only looked at top-level frames would pass while the real run rewrote the tree underneath it — a CI gate reporting clean on a dirty tree. Runs that were green may now fail, and where they do, the drift they name is real.

Accepted costs, deliberately

• A fully-cached run now reads every codegen target's outputs and compares them against the tree, where before it did nothing. Writes are still skipped when the bytes match, so it is read-and-compare rather than rewrite — but it is new per-run work proportional to generated bytes.
• Commands that resolve the graph rather than just query it (heph inspect hashin/hashout) now materialize codegen outputs. heph query never resolves and is unaffected.
• Ordering wart, pre-existing and now wider: a dependent's @heph/fs glob and the codegen target it depends on resolve concurrently in inputs_result_meta, and glob results are memoized per request_id — so whether the dependent hashes pre- or post-write-back bytes is a race, self-correcting on the next run. Writing the tree during a run that is hashing the tree is the underlying issue; it wants a phase boundary, not a wider gate.

Cleanup

ExecuteOptions::{frozen, is_top} are dead after this and are removed, along with inner_result_addr's is_top parameter. is_top stays in the mem_result key: the codegen write-back was its justification and no longer is, but collapsing the key changes single-flight behaviour for every target reached both ways — a separate change with its own blast radius. The second variant hits the on-disk cache, so it costs a re-filter, not a re-execute.

Tests

• copy_dep_is_written_back_and_stamped, copy_group_member_is_written_back_and_stamped — the two ways a frame loses is_top.
• copy_dep_stamps_a_preexisting_unstamped_file, writeback_stamps_a_preexisting_unstamped_file — the reported bug: the bytes already match, so there is nothing to write, only provenance to record.
• in_place_dep_is_written_back — replaces in_place_dep_is_not_written_back, which pinned the old rule.
• frozen_run_reports_a_dep_codegen_divergence_and_writes_nothing — the --frozen half.
• codegen_write_back_runs_off_the_runtime_workers — still witnesses the blocking::run hop, now through the single pass.

Verified against the real binary: on a 2-hit / 0-miss cached run, heph run //pkg:consumer writes and stamps the copy dep's outputs and applies the in_place dep's transform (hello there → HELLO THERE); --frozen on the same run reports the divergence with its diff box and writes nothing.

Local suites: engine 549, e2e 127, plugingo-e2e --test codegen 10/10 and --test lint 4/4 (run with --test-threads=1; in parallel they exhaust this machine's disk and fail on os error 28).

🤖 Generated with Claude Code

https://claude.ai/code/session_01W9pJTeJGLJva1b2ZCJGtgz