Two witnesses drifted from legitimate changes: deploy-order oracle pinned tree,binary; seat oracle copied group B's ceiling

[gunbai-bot]

What this is

Work item: four witnesses reported RED at base 43643ba (session gentle-seal-606). Two are in the deploy path. This PR repairs the two that are real oracle drift on main and records why the deploy-path pair is a stale report. Evidence class is stated beside every claim.

The deploy-path pair — stale report, no change here

live_deploy_unit_emission_oracle_witness_test: the_serve_unit_matches_the_deployed_bytes, serve_unit_execstart_carries_admitted_entrypoint.

• fabric DB: replace git under the fabric event log #11723 (fabric DB) did not cause them (git-derived). 1a5d4db is a descendant of 43643ba, so a red reported at that base predates it. Its emit.dag change adds live_deploy_fabric_db_unit_file beside the serve emitter without touching the serve ExecStart producer.
• Why red at the base (git-derived): at 43643ba production already rendered --host 127.0.0.1 (roadmap_dashboard_instance listen_host) and --eval-budget-wall-ms 120000 (dashboard_serve_wall_limit), while both claims still pinned 0.0.0.0 / 30000. approval loop D: converge materialization, loopback bind, mtcollins1_boot mode #11484 (121a4d4, after the base) corrected exactly those literals in exactly those claims.
• 6b reading: the earliest unjustified boundary was the oracle's transcription; the emitter's contract (ExecStart derives from spec.service.listen and the two limit rows) held at every link. The deploy machinery was not lying.
• Executed on main: PENDING — see evidence status.

Ordering witness — oracle drift, fixed

(source-derived; executed by this PR's floor run, which plans edited test fns) deployment_owned_steps lists ServeBinary then GunbcSourceTree; deployment_steps_apply_order's annotation states binary-then-tree with its reason (the tree is published by a oneshot that RUNS the admitted binary; review on #10696). The witness literal pinned tree,binary,…; its own annotation never made the order of those two its subject. Literal follows the authority now; the stale prose on deployment_tree_remote_unit_name is corrected to match.

Seat witness — oracle drift, transcription removed

(source-derived; executed by this PR's floor run) #11617 superseded serving_group_b_route_turn_ceiling 1 → 4 and updated serving_routing_witness but not harness_seat_witness, which had copied 1. Per the parent's direction the copy is removed, not re-copied: the claim asserts w_tolerant_ceiling(g) == serving_route_turn_ceiling_count(serving_route_ceiling(g)) for both groups (the harness reads the enrollment row), and keeps != quality ceiling and != engine max_num_seqs as the discriminators. The row moving no longer reds anything.

Why all four drifted unseen — the finding beyond the four

The required floor (floor job, claim_executor --required-ci --required-lane witnesses) plans the CHANGED witness set from the test fns the diff touched — required_floor_runner.rs changed_witness_identities_from_edited_test_fns over floor_diff_edits_from_line_ranges — not from the whole corpus. So an oracle that transcribes a production value is only ever executed when its own file is edited; a production change that moves the transcribed value (listen host, wall budget, apply order, a ceiling row) never plans the witness, and its red stays invisible until someone edits or runs it. All four reds here are that class. (An earlier revision of this body wrongly said no witness executes in CI — that was a read of one run's job roster from before #11761 restored the floor job; corrected by the parent, verified against witnesses.yml at origin/main.)

Evidence status

• The two repaired witnesses are planned by this PR's own floor run because their test fns are edited; a red there blocks the merge.
• The deploy-path pair is untouched here and therefore not planned by the floor. Executed confirmation on main is still owed: claim_batch on BuildBuddy was SIGKILLed (137) on the live_deploy closure and gunbc run there refused MemoryStallRefusedPageThrash on every one of these closures; locally the host sat at 96/125 GiB and both claim_batch (MemoryStallRefusedPageThrash) and gunbc run (25 min, 26 s user / 21 min sys, timed out) thrashed. A local run is in progress with headroom; results will be posted here verbatim, or the blockade stated if it persists.
• Whole-corpus parse sweep (v1_src_dag_parse) is clean for the three edited files.

🤖 Generated with Claude Code

[gunbai-bot]

Executed evidence for the deploy-path pair (green on main).

Run locally at 3bf84fc (= origin/main 2f18c48 + this PR's commit; the two claims and their production closure are unchanged by this PR — the only touch in their closure is annotation-only prose in live_deploy/spec.dag, erased under §4c), with /cargo-target/release/gunbc copied to a session-private path:

$ gunbc run --source-root dag --source-root src/v2 --entry dag/test/claim/live_deploy_unit_emission_oracle_witness_test.dag --function the_serve_unit_matches_the_deployed_bytes
error: function `the_serve_unit_matches_the_deployed_bytes` returned `true`, not `ProcessExit`.
  cause: the host maps a run's verdict to an exit code, and only ProcessExit carries one. Wrap the result in ExitSuccess / ExitFailure.
  status: refused — printing the value and exiting 0 would report success for a run whose outcome is unknown.

$ gunbc run ... --function serve_unit_execstart_carries_admitted_entrypoint
error: function `serve_unit_execstart_carries_admitted_entrypoint` returned `true`, not `ProcessExit`.
  (same cause/status)

The refusal is the run verb's exit-code contract (a test fn returns Bool); the evaluated value it reports is true for both. That is the executed confirmation of the git-derived reading above: both claims hold on current main, and the red at 43643ba was the oracle lagging #11484's corrections.

claim_batch on the same closure still refuses MemoryStallRefusedPageThrash here and is SIGKILLed on BuildBuddy; gunbc run succeeded once the host had ~28 GiB headroom.

The two witnesses this PR edits are executed by this PR's own floor job (planned as edited test fns).

[gunbai-bot]

Executed red→green for both repaired witnesses (local gunbc run, tree = main 2f18c48 + this branch, with two temporary probe fns appended to each witness file for the run only — not committed):

deployed_tree_remote_witness_test
  the_remote_converges_after_its_inputs_and_before_the_belt   returned `true`    (repaired expectation: binary,tree,remote,publication,belt,route)
  probe_stale_tree_then_binary_expectation                    returned `false`   (the old literal: tree,binary,...)

harness_seat_witness_test
  the_tolerant_pool_is_a_separate_pool_whose_ceiling_is_not_the_engines_sequence_limit   returned `true`   (reads serving_route_ceiling)
  probe_stale_group_b_is_one                                   returned `false`   (the old transcription, w_tolerant_ceiling(B) == 1)
  probe_group_b_reads_four                                     returned `true`    (w_tolerant_ceiling(B) == 4 && w_route_ceiling(B) == 4)

(Each line is the run verb's returned \…`, not ProcessExit` refusal; the value it reports is the claim's evaluation.)

Do not read this PR's floor check as evidence. Its first run (35497139573) concluded success while the step log says required-ci: floor refused … phases_run=2 phases_failed=2 — no claim was evaluated (main's floor_naming_hygiene.dag parse break, since repaired by #11780, refused the whole floor) and the lane went green anyway. Cause: compiler_gate_workflow runs claim_executor with --measurement-receipt, under which a completed measurement carrying blockers exits 0 (the blockers go to the receipt), and the gate emits no D0-ADJUDICATE step to consume the receipt. That is a fail-open required lane, live on main since #11742/#11761; every floor success since then is unverified. Repair (decision from the roadmap manager: emit the adjudicate step) is coming as its own PR.

Review nit (the "second conjunct" prose) fixed in afd7ae9.