The behavioral receipt asked one generator for a mirror two generators write: ask the population that owns the path

[gunbai-bot]

The behavioral receipt asked one generator for a mirror two generators write

This body has been rewritten. The first version claimed drift coverage as a side effect of producing the candidate. Running it disproved that, and the mechanism below is what the change actually does. Both existing approvals predate this correction.

The defect

src/v1/stage0/src is written by two generators: the v1 compiler emits module mirrors, and gunbc's artifact emitters write a handful of generated files whose headers say so. The receipt asked only the first and refused when it came back empty:

behavioral-receipt: gunbc.v1_interpreter_primitive_surface REFUSED — the emit produced no
v1_interpreter_dispatch_generated.rs, so there is no candidate to compare.
Not equivalence: a missing candidate is ignorance

That refusal is correct as written and this change does not weaken it. What was wrong is that the second population was never asked, so the refusal was unconditional: any change to the interpreter dispatch roster or the stage0 crate layout redded this phase with no reachable green short of hand-editing a generated file — the laundering pattern DESIGN's CI paragraph already closed one gate over, reached from the other direction.

What I got wrong, and how running it caught me

My first version produced the candidate and handed it to the behavioral differential. That cleared the refusal above and hit a second, deeper one:

REFUSED — seed: the driver did not compile against the mirror: error[E0425]: cannot find
function `v1_interpreter_arm_shape_derivability` in module
v1_compiler::v1_interpreter_dispatch_generated

The differential compiles a driver that calls the authority's declared functions against the mirror. v1_interpreter_dispatch_generated.rs exposes enums and lookup_* fns — it is derived from the authority's data, not a Rust projection of its functions. Those functions are not there and never will be, so the differential's precondition does not hold for this population at all.

I had asked "what is missing" without asking "what will the consumer do with it once it has it".

The mechanism

Two populations, two checks that fit their subjects:

population	check	why
module mirror	behavioral differential	the mirror answers the calls the authority declares
generated artifact	byte identity	there is nothing to call; the whole content is the product

For a generated artifact, byte identity is not a weaker stand-in for behavioural equivalence — it is the complete statement of correctness.

This makes the coverage claim real rather than asserted. v1_interpreter_dispatch_generated.rs and bootstrap_stage0_crate_layout_generated.rs have had no drift check anywhere since the floor cut dropped the generated-artifact drift gates (DESIGN lists them among what is unguarded). This is now the mechanism that gives them one — a climb, not only a gate repair.

I nearly went the other way: exclude such authorities at selection, on the grounds that drift coverage belonged to the drift gate. I checked, and that gate does not exist — generated_artifact_drift_test.dag is deleted (cli_run.rs still names the path twice), and the surviving witness checks only that generation succeeds, never that it matches the committed file. The exclusion would have deleted the last observer while citing a gate that wasn't there.

Design notes

• A projection, not a second authority. generated_artifact_body_for_path folds committed_generated_artifacts() (the roster main_wet folds), filters by the existing artifact_path, and dispatches through the existing artifact_generate. No new roster, no forked dispatch — which was the available shortcut and is not needed.
• Three states, not two. GeneratedArtifactPathNotGenerated is a positive answer that routes to the mirror-emit population. Folding it into Refused would tell a caller holding an ordinary mirror that generation failed for it — false, and differently actionable.
• Asked by population, not by fallback. A fallback would make absence in one producer mean presence in the other, so an unknown path would be regenerated from nothing instead of refused. A path in neither still refuses, and says which.
• ExecutionMode::Hermetic. The projection is pure; a host effect reached during it means a generator is doing something a gate must not perform on its behalf.
• No default match arm. An unrecognised variant is ignorance; guessing NotGenerated would route a real generated artifact to the mirror emit and refuse it for the wrong reason.
• Cost shape, fixed before shipping. The first draft resolved the whole closure inside the per-module loop — unit of computation the corpus, unit of fact one path. One resolve now, before the loop.

Evidence by execution

Same worktree, one variable changed between runs:

• unperturbed → ARTIFACT-IDENTICAL — ... regenerates byte-for-byte from its authority. This is identity, not behavioural equivalence: the artifact exposes no function this fragment could call, so its bytes are the whole claim
• one appended comment line, bytes confirmed to differ before the run rather than assumed → ARTIFACT-DRIFT — ... does not match what its authority generates. Regenerate it (main_wet on dag/tools/generated_artifact_gate.dag) and commit the result
• perturbation restored afterwards, verified by byte comparison rather than inferred from the copy succeeding
• receipt-selftest OK both arms discriminate; the four DriverTranscript unit tests still pass

The positive arm alone would prove only that the mechanism reaches the artifact. The drift arm proves it discriminates — without it the check would pass on everything, which is strictly worse than the refusal it replaces, since a refusal at least announces that nothing was verified.

Downstream

This is the last cause blocking #8726, which otherwise sits at phases_run=6 failed=1 with every other phase clean.

---

Appendix — ETXTBSY forensics (NOT part of this diff; recorded so it is not re-derived)

This PR's CI red once on the floor with failed=1:

FAIL v2.test.execution.emit_host_transport_wire.emit_host_transport_green_run_holds
  errored: emit_host_run_transport: spawn "cargo" failed: Text file busy (os error 26)

It recovered green on rerun of the pinned head (63704a41): phases_run=8 failed=0,
floor planned=9931 executed=9931 failed=0, passed 9623 → 9624 — same roster, exactly +1,
so the recovered subject is the witness that errored and not a smaller question.

Status: recovered, cause NOT established. A green rerun is consistent with both a host race
and an intermittently-reproducing defect, so it does not discriminate them. Recorded here rather
than filed as a typed carrier: ETXTBSY appears nowhere in dag/src/v2, and one occurrence
whose writer cannot be named does not justify a carrier that would claim more than the evidence.

precondition	CONFIRMED — failing job on runner srv1-04 (from attempts/1; the rerun overwrites the job record). Four co-tenant slots srv1-01/02/03/05 were live at 12:31:43Z. Runner names are srvN-MM = slot MM on host srvN, so these share one machine.
candidate: toolchain installer	REFUTED — every Install Rust toolchain step on those slots ran 1–2s (cached): 12:21:05–07, 12:28:20–22, 12:28:31–32, 12:30:26–27. None contains the instant.
concurrent activity	srv1-05 was inside Build the witness fold 12:30:27→12:33:16 — a concurrent cargo build on the same host. Writes registry/ and .package-cache, not the exec'd binary.
writer of the binary	UNKNOWN

Method note: concurrency requires the step's interval to contain the instant. Comparing
start times to the instant is the wrong predicate and biases toward "found none" — using it
first produced both a false absence and a candidate that the correct predicate then refuted.

The file identity is unestablished because the diagnostic cannot carry it

v1_interpreter.rs resolve_host_tool_program resolves argv[0] by first match over PATH,
then $CARGO_HOME/bin, then $HOME/.cargo/bin, and Command::new execs that resolved path —
but both failure sites format argv[0], the bare spelling:

let mut command = std::process::Command::new(resolve_host_tool_program(&argv[0])?);
...
.map_err(|e| InterpError::TypeError {
    msg: format!("emit_host_run_transport: spawn {:?} failed: {e}", argv[0]) })

So the resolved path is computed and discarded at the moment it becomes evidence, and the error
cannot distinguish a rustup shim from /opt/cargo/bin/cargo from a per-job copy — which are
three different mechanisms with three different remedies (only one of which involves co-tenancy
at all). Two sites, emit_host_run_transport and emit_host_run_transport_cached.

Not fixed here — unrelated to this PR's subject, and bundling it would mean reverting the
forensics fix to revert this one. Offered as a separate one-line repair: report the resolved
path beside the spelling. That is what makes the next occurrence self-diagnosing instead of
costing another investigation.

— sent from snappy-ferret-99