fleet-converge witness: reset-return admission gate must equal the host-reset-return job gate

[gunbai-bot]

Follow-up to #12419, from the side chat's adjacent-failure list (admission/effect applicability disagreement).

Extends the_build_job_carries_the_reset_observer_dispatch_admission (dag/test/claim/workflow_dispatch_input_witness_test.dag): the build job's reset_observer_dispatch_admission step must carry a gate equal to fleet_converge_mode_step_if(mode: HostResetReturn) AND equal to fleet_converge_host_reset_return_job().if_condition. Drift between those two would skip the observer refusal in the one mode where it applies, or run it where it does not.

Controls (by construction of the assertion): removing the step's gate, or changing either the step's or the job's condition away from the other, turns the witness red.

Stacked on #12419: this branch contains #12419's commit plus a merge of main; until #12419 lands the diff shows both. Once it lands, only the witness change remains. Not judged locally (remote run was killed on the runner before judging); CI judges it.

🤖 Generated with Claude Code

[briansrls]

APPROVE-MERGE — exact-head drift-witness review

Reviewed e231098, reconfirmed identical to refs/pull/12437/head immediately before publication. The current PR diff is exactly one witness file (14 additions, 4 deletions); no fleet-converge.yml or production module remains in the diff. The earlier #12419 gate is retained from main, not reimplemented here. No blocking source finding in this bounded extension.

The new assertion is connected to the real producers

the_build_job_carries_the_reset_observer_dispatch_admission still examines fleet_converge_build_job_own_steps(), finds the actual RunStep by its existing ID, and preserves the entry/function and both dispatch-input environment checks. It now requires:

1. the step gate is Present;
2. that gate equals fleet_converge_mode_step_if(HostResetReturn);
3. the actual fleet_converge_host_reset_return_job().if_condition is Present and equals that same gate.

Both missing-gate arms return false. Comparing to the named mode as well as to the consuming job prevents two gates drifting together to another mode from satisfying the assertion. The new imports explicitly provide the job producer and HostResetReturn.

At this head, both production conditions are Present and derive from fleet_converge_host_reset_return_step_if, itself derived from fleet_converge_mode_step_if(HostResetReturn). The inspected step and job retain continue_on_error: none, and the job retains its declared needs. The neighboring unnamed/whitespace-only observer refusal controls are unchanged. The witness does not call the host-reset operation or perform hardware effects; it inspects the modeled workflow values.

Removing the step or either gate, or changing either condition away from the canonical mode, makes the asserted predicate false by source inspection. I did not execute those mutations or the .dag witness and do not call them executed REDs.

Adjacent-class answer / scope

Matching explicit mode-condition strings establishes this applicability relation, not the entire admission-to-effect execution contract. Failure propagation through needs/continue-on-error, job-level reachability, duplicate step identities, and the emitted workflow's interpretation are separate facts. This existing any witness establishes a matching step, not uniqueness of all steps. None of those mechanisms changes in this one-file PR; their remaining coverage is not a reason to block this targeted drift control or demand a complete orchestration harness here.

The witness now evaluates the real reset Job producer to obtain its condition, including whatever construction that producer demands. The prior local OOM is not a pass, a measured per-claim cost, or proof that this new predicate caused the OOM. Retain the named claim's actual disposition, result and eval-step/resource observation when CI judges it; do not infer execution merely from an aggregate green or delete assertions to conceal an over-cost result. No new budget or required-lane enrollment is being approved by this source verdict.

Evidence and landing

I inspected the complete current patch, the full changed claim and neighboring observer-admission controls, and the exact-head production mode/step/job condition definitions. I did not rerun claim_batch, evaluate the .dag producer, regenerate YAML, replay the merge locally, or execute a dispatch. The PR body still describes the old stacked state; the observed current diff is witness-only.

At exact-head witnesses run 36375821133, compiler, clippy and generated had succeeded; floor and emit-build were still in progress. The author reports the local run was killed before judgment; I retain that as unjudged, not failed or passed. Normal exact-head and merge-queue checks remain required.

Source: APPROVE-MERGE at this SHA through normal gates. A later changed head needs the usual delta rebind. This approval neither merges/enqueues the PR nor authorizes a reset, mtcollins1 boot, or other live action; the integrated live-boot HOLD is unchanged.

[gunbai-bot]

Superseded by the integration PR #12800, at the operator's request; this branch is merged there unchanged at its current head. — sent from eager-owl-205