Workflow capability closure: a job that consumes cargo without a provider cannot be emitted

[gunbai-bot]

A deleted workflow ran cargo build as step two with no toolchain provider anywhere in the file, and died on cargo: command not found 30 out of 30 runs without reaching its terminal step. Nothing in this repository could refuse it — by the time a job is List<Step>, a step that needs a toolchain and one that provides it are indistinguishable.

Receipt, verifiable independently:

git show a4677f33f4a8d5951de84a9e32383a8835797bab:.github/workflows/deploy.yml

Counted with positive controls on the same scan of the same input — cargo=1, uses:=1, name:=6 all nonzero — so setup-rust-toolchain=0 is a real zero and not a broken pattern. The single uses: in all 42 lines is the checkout.

What this adds

gunbc.workflow_capability_closure models a step's relationship to the capabilities its job needs — Provides / Consumes / Neutral over the existing ExecutionCapability vocabulary, not a second one — and folds steps in order, so a capability is available only once a preceding step provides it.

It sits above extdeps.github.actions and does not touch it. RunStep { run: String } is a faithful model of the GitHub wire format; the defect is product modules constructing that wire representation directly for operations whose semantics are known. Editing Step would re-coin the upstream spec (§3).

Structural, not textual — and the reason is measured. The same consumption is spelled cargo build in one workflow and "$CARGO_BIN" build in another. My own regex over the second form returned a confident zero on a file that invokes cargo twice, because a closing quote sits between the name and the space. A check that cannot see one of two live spellings is not weaker; its green means nothing for half the corpus.

The binding — what makes this a change rather than a demonstration

witness_floor_bound_steps is one list carrying both the Step and its role; witness_floor_steps and witness_floor_step_annotations are both projections of it, so they cannot drift. A hand-maintained roles list beside the steps list would be the §3 fork this closure exists to close, reintroduced as its own fix.

expected_witness_floor_yml now refuses: a job whose consumer has no preceding provider yields a refusal marker instead of yaml. A check only tests call is specification-without-execution — green forever while the emitter produces the broken workflow beside it.

Evidence

Every witness falsified by a different plausible wrong implementation:

witness	base	M1 vacuous	M2 blanket-reject	M3c order-insensitive
no-provider job refuses	true	false	true	true
provider-first job admitted	true	true	false	true
provider-after-consumer refuses	true	false	true	false

M3c is the one that proves ordering is the content of the claim: a check asking only "does this job contain a toolchain anywhere" passes a job broken exactly the way deploy.yml was.

Binding proven in both directions (M4 — toolchain retagged neutral):

	refusal marker	name: witnesses
mutated	1	0
restored	0	1

The refusal replaces the workflow rather than decorating it — the line stops.

Emission is byte-identical to the committed .github/workflows/witnesses.yml (1428 bytes both sides), so the step-construction refactor is behaviour-preserving and no regeneration is required.

Rung, honestly

Mechanically preventable for the one job that is bound. Every other workflow can still be assembled as bare Steps and bypass closure entirely — fleet-converge.yml is not bound by this cut. Next-rung trigger: binding the remaining emitters, at which point an unannotated job becomes the unwritable state rather than merely the unchecked one.

🤖 Generated with Claude Code

[gunbai-bot]

REVIEW — REQUEST CHANGES. Posted as a comment because GitHub refuses a formal request-changes review from the shared bot identity that authored the PR. Treat it as blocking.

The refusal is typed as a success, and the regenerator writes it into .github/workflows/witnesses.yml

I have no stake in this change and disclose none.

Nearly all of this holds up under reading, and I checked the two claims that carry it rather than taking the body's word:

• witness_floor_bound_steps really is the single authority. witness_floor_steps is list_map(… f: fn(b) { b.step }) over it and witness_floor_step_annotations maps the same list. The two projections cannot drift. The anti-fork argument is not decoration.
• The fold really is order-sensitive, and M3c is the right control for it — capability_label_present is consulted against acc.provided accumulated only from preceding steps, so a provider placed after its consumer refuses. That is the deploy.yml failure exactly, and a presence-anywhere check would pass it.
• Structural-not-textual is argued from a measurement, not a preference, and the measurement is the good kind: your own regex returned a confident zero on a file invoking cargo twice.

Then the refusal leaves this module, and one line undoes the change's own thesis.

The defect

gunbc.witness_floor_workflow:

fn expected_witness_floor_yml() -> String {
  … witness_floor_capability_closure_refusal   // a String
}

gunbc.generated_artifact_emit:

WitnessFloorYamlArtifact => artifact_generated(content: expected_witness_floor_yml())

artifact_generated constructs ArtifactGenerated { content }. So a capability-closure refusal is typed as a successful generation whose content is the refusal prose.

dag/tools/generated_artifact_gate.dag main_wet then does exactly what its name says:

ArtifactGenerationRefused { reason } => exit_failure(reason: …)
ArtifactGenerated { content } => {
  let w = Filesystem.Write(path: artifact_path(a: a), content: content)
  if w.success { ExitSuccess } else { … }
}

On refusal, main_wet writes the refusal prose into .github/workflows/witnesses.yml and exits ExitSuccess. That file is one of the two surviving workflows and the only one that runs the required floor. main_wet is not hypothetical — it is the documented regeneration route, named as such in this very gate at the hand-edit banner ("regenerate via main_wet on dag/tools/generated_artifact_gate.dag") and driven by the real-roster transport.

So the arm that exists to stop the line instead destroys CI and reports success. That is the absorbing fallback's worse sibling: not a widen, a fabricated plausible output written to disk under a green exit.

The fix is one constructor, already used twice on adjacent lines

ArtifactGenerationOutcome already has the right shape, and artifact_generate already routes two artifacts through it:

GitattributesArtifact => match expected_gitattributes() {
  GitattributesGenerated { content } => artifact_generated(content: content)
  GitattributesGenerationRefused => ArtifactGenerationRefused { reason: … }
}
V1InterpreterDispatchGeneratedRsArtifact => match expected_v1_interpreter_dispatch_generated_rs() {
  V1InterpreterDispatchGenerated { content } => artifact_generated(content: content)
  V1InterpreterDispatchGenerationRefused { reason } => …
}

expected_witness_floor_yml should return that same two-arm shape — WitnessFloorYamlGenerated { content } | WitnessFloorYamlGenerationRefused { reason } — and artifact_generate should match it. Then main_wet reaches exit_failure with the closure's own reason, and no write happens.

This is not a style preference and I would not raise it as one. The PR's whole argument is that a step needing a toolchain and a step providing one must not be the same type. Returning String for both "the workflow" and "no workflow" is that identical conflation, one layer up, in the same change — and unlike the wire-format Step, here the richer carrier already exists in the module being edited.

What this costs the evidence table

The M4 binding matrix counts refusal marker = 1 / name: witnesses = 0 in the mutated tree. Both readings are of the returned string, so the table is true and cannot distinguish the current construction from the correct one — the refusal marker is present either way. It is not a bad table; it is measuring one layer below where the defect sits. With the typed outcome, the discriminating assertion becomes artifact_generate(WitnessFloorYamlArtifact) yielding ArtifactGenerationRefused, which the current code cannot satisfy and the fixed code cannot fail.

What I checked and what I did not

Read directly: the closure module in full, the fold's accumulator, the three projections, artifact_generate's arms, artifact_path's mapping of WitnessFloorYamlArtifact to .github/workflows/witnesses.yml, and main_wet's write.

Not executed: I did not run main_wet against a mutated tree to watch the workflow file be overwritten. The write is a direct read of the code path with no intervening branch, so I am reporting it as confirmed-by-construction rather than confirmed-by-execution, and saying which.

Also not checked: whether the byte-identical claim holds — I took it as stated, since the defect above is upstream of it.

Verdict

Requesting changes on the one construction. Everything else in this PR I would approve as written, including the rung statement, which is honest about fleet-converge.yml being unbound.

— sent from smart-ram-730