The three source findings raised against #11679 after it merged (ordering, runner-width coupling, false absence)

[gunbai-bot]

#11679's park verdict arrived after it landed, so all three findings are on main. One PR, as asked. A fourth finding was raised against this PR during review and is repaired here as (d).

(a) The ordering was worse than comment-versus-code — it was encoded in two witness names

converge_controller_app_key called ensure_key_dir, which runs install -d and then observes, before observe_upper_ancestors — a host mutation ahead of the observation entitled to refuse the whole converge. No key was ever written (controller_app_key_action decides after every observation), so the residue was an empty root-owned directory, not a custody hole. But an_unsafe_directory_refuses_before_any_write and a_writable_ancestor_refuses_before_any_write call only the pure decision with supplied observations, so they stayed green while advertising a property the production route did not have. That is an evidence population inviting a future reader to cite a property the code lacks.

Both repairs, not one. The create is gated on the ancestor reading — on the refusing arm the directory is only observed, which is a read — and the two witnesses are renamed to what a claim over a pure function can establish: refuses before any KEY-CONTENT write. controller_app_key_action is untouched, so the decision keeps its single authority.

(b) Custody was coupled to runner width, and srv2 was unreachable

The entry resolved its host through runner_host_file_subject, which requires an admitted RunnerHostDeploy — a spec plus an admitted width. srv2's width is unresolved, so srv2 has no deploy row and the mode terminated there while the PR described it as covering srv1 and srv2. The key's location, administrator target and custody do not depend on how many slots a host admits, so the module resolves its subject from runner_host_spec_for.

The privilege law is not dropped with the deploy row: gunbc.runner_host_grants gains bootstrap_principal_is_not_the_job_user, and the existing deploy-shaped predicate now calls it rather than being duplicated (§3). The new subject deliberately carries no unit populations — this module verifies no teardown, so empty unit lists would be fields that lie.

(c) The staging absence probe could falsely confirm

test -e exit 1 became StagingAbsent, and GNU test -e is stat(path) == 0, so EACCES, ELOOP, ENOTDIR and EIO all answer 1 with an empty stderr — and StagingAbsent feeds ControllerAppKeyHeld, so a metadata failure would have been reported as custody held with no residue. Absence now comes from a successful listing of the parent, which is gunbc.live_deploy.member_observe's rule rather than a second vocabulary.

The departure from that authority is stated, not silent (§3b): entry_presence reaches the far side as the bootstrap principal, and this parent is the key directory at root:root 0700, so an unelevated listing can only ever refuse — it would answer Indeterminate on every host whether or not residue exists. The same membership question therefore runs over this module's elevated leg. classify_staging_residue is now pure over a listing that succeeded, so StagingUnobservable has no constructor inside it; that arm belongs to the leg.

(d) Cleanup was a root mutation beneath a path the route had just refused to trust

(a) stopped install -d under an untrusted ancestor, but converge_controller_app_key still evaluated clear_staging unconditionally, and clear_staging opens with an elevated leg: run_elevated_leg(staging_remove_argv(staging)) = sudo rm -f -- <staging>. The non-write arms of the preceding match produce none; they did not skip cleanup. So this execution was representable: /etc/gunbc group- or other-writable → PathsNotRootOnly → directory only observed → action refuses → no key content written → elevated rm still executes beneath the refused ancestor. That is not residue: a non-root principal who can write an upper ancestor can replace an intermediate path component — a directory or a symlink — between the observation and the leg, so the route performs a root mutation through the exact containment it had just declined to trust.

The module note claimed staging is removed "after every run whether or not a write was attempted", and the code implemented that literally. The correct boundary is narrower and the note now states it: after every attempt whose ancestor and parent-directory authority has been established.

Gated on path authority, deliberately not on the whole action — a content or file-metadata observation may be unobservable while the path is safely root-contained, and cleanup is still desirable there. StagingCleanupAuthorization is sole_constructor, so the bad state is unwritable rather than merely unreached (§4b rung 4). admit_staging_cleanup is its only mint and joins three facts: upper ancestors PathsRootOnly, directory KeyDirRootOnly, and path_parent(staging) == key_dir. clear_staging takes the sealed carrier instead of a bare subject and bare path, and derives every value the leg uses from it — subject, parent, path, and the residue predicate's key (review 69444: as a parameter, staging_name was the one value a caller could still spell freely, and it is exactly what classify_staging_residue keys on, so the stated rung was claimed rather than constructed). The withheld arm carries StagingUnobservable, which controller_app_key_custody already counts as not-held, so the run still refuses.

Why (a)'s controls could not see it: they invoke only the pure decision with supplied values and never execute clear_staging, so a control proving controller_app_key_action refuses was already green while the cleanup mutation ran.

Executed evidence

All 27 witnesses in microvm_controller_app_key_converge_witness_test pass, plus the 11 member_identity witnesses affected by the shared member_observe symbols — 38/38, run in one claim_batch from the composed head with gunbc and claim_batch rebuilt from that exact tree.

The three added for (a)–(c): srv2 resolves a custody subject while the deploy route still refuses it (the pair that goes red if custody is re-coupled to width), plus the parent listing establishing absence, residue, and the empty-listing case.

The five added for (d), over the admission fold, which is the whole gate: writable upper ancestor → withheld; unsafe key directory → withheld; unreadable key directory → withheld (blind is not safe); staging path outside the admitted directory → withheld, which tests the join rather than merely proving two positive constructors were supplied independently; and the positive control — root-only ancestors + root-only directory → an authorization naming the exact parent and staging path. The four withheld arms and the positive control discriminate each other, so neither a constant-withhold nor a constant-authorize fold stays green. A 27th (review 69456) asserts the three withheld causes are pairwise distinct and non-empty — the withheld arm had been discarding the cause admit_staging_cleanup computed and substituting one constant, so the receipt could not tell an operator whether to fix an ancestor, the directory, or a staging path pointing outside it. The cause is now threaded through, the constant is demoted to a prefix, and that control reddens if they are ever flattened back together.

Composition: merged current main (12 commits, including seed changes under src/v1/stage0) with no conflict at any file. The generated_artifact_gate dry run is green on the composed tree, and that green is itself controlled — planting one line in .githooks/pre-commit reddens it with a located finding (EXIT=1, committed content differs from authority), so the clean result is a reading rather than a silent pass.

Retained untouched, as the review asked

Key path consumed from the signer's own JwsSigningKeyRef; placement refusing the fabric-cell tree; RemoteFileModeOwnerRead closing the octal vocabulary at 0400; byte-for-byte comparison against the resolved SM version; full re-read after mutation; no key bytes in any receipt; the old runner-owned key left alone.

🤖 Generated with Claude Code

[gunbai-bot]

Both findings are right, and the sharper point is the one I'd make against myself: this diff applied the correct standard one line earlier — the privilege predicate was deliberately extracted so the comparison kept one authority — and then broke the same rule twice in the same file. Fixed in 954ff01f9c5.

1. The listing argv and the membership read. You're right that my stated §3b departure doesn't reach them: it argues only that the transport must be this module's elevated leg, and the argv and the predicate are the same facts whichever principal runs them. The drift evidence is the part worth keeping — the two copies had already diverged in the commit that created them (mine trimmed each line, member_observe's does not), which is §2's prediction arriving immediately rather than eventually.

gunbc.live_deploy.member_observe now exports the two pure halves, parent_listing_argv and listing_contains_entry, and both entry_presence_in_parent and this module consume them. The elevated transport stays here, because that is the only part that actually differs.

2. The administrator SSH target. Same class. gunbc.runner_host_file_converge now exports administrator_ssh_target — endpoint from the fleet reach authority, principal from the declared administrator, neither depending on the deploy row — and both subjects consume it.

Executed after the change: 21/21 witnesses in microvm_controller_app_key_converge_witness_test still pass, and I re-ran member_identity_witness_test because I edited member_observe itself — its consumers stay green, so the extraction didn't move the shared behaviour.

— sent from keen-bear-791

[gunbai-bot]

Conflict resolved at aaabd57da91 (merge of origin/main, which now carries #11897, #11896, #11898, #11732 and #11856).

The conflict was ROADMAP.md, and the merge driver refused rather than answering — both sides had regenerated it since the base (mine via the CI auto-heal commit, main via its own repair), so neither side's bytes are the projection of the merged authorities. That refusal is correct and it is load-bearing here: main's #11856 added six more roadmap nodes, so the right answer was neither side's. Taking either would have produced a plausible file that was wrong.

Resolved by regeneration, not by choosing a side:

• rebuilt gunbc from the merged tree (2026-09-20 23:48:53, per-session target dir, exit-2 control on an unknown flag) — necessary, since main moved the parser and several authorities;
• ran generated_artifact_gate main_wet;
• the derived count settled at 152, which is neither my branch's 143 nor main's value — the arithmetic proof that this had to be regenerated;
• no conflict markers, and a second regen after committing changes zero tracked files, so the tree is a fixpoint of its own authorities rather than merely unconflicted.

Re-verified after the merge rather than assuming: all 21 witnesses in microvm_controller_app_key_converge_witness_test pass on the merged tree, including the discriminating srv2 pair.

— sent from keen-bear-791