Local argv cut, the constructor wall it needs, and the inert-admit_callers finding

[gunbai-bot]

admit_callers on a service operation is accepted and inert

admit_callers is the repository's construction wall: a declaration names who may call it, and
anyone else is refused. On a fn it works. On a service operation the same syntax parses,
resolves clean, and does nothing.

Why this is worse than the wall simply being absent

An absent wall is visible — you go looking, find nothing, and know where you stand. This one is
invisible while reading as present: an author seals an operation, a reviewer reads the roster as a
boundary, and it admits everyone. It is the inert-lens failure at construction grain, which is
the worst place for it, because a construction refusal is the rung people stop checking behind.

Measured evidence that the illusion works: I was one step from reporting "the wall is available"
after watching the declaration parse, and the reviewing session says it would have believed me.

Two independent routes, deliberately not two readings of one artifact

• By execution — admit_callers added to the real shell.Exec.Run naming only
  gunbc.command_runner; the unadmitted gunbc.package_delivery, which calls Run five times,
  then resolved byte-identically to the unsealed baseline captured first.
• By source, independently — enforcement lives at exactly one seed site, gated on an
  exact-constructor-declaration lookup reading the fn admission list. An operation invocation is
  not a constructor-declaration lookup, so it never reaches that arm, and no operation-call
  analogue exists.

Blast radius today: zero

No operation in the corpus carries admit_callers — all 21 occurrences across dag/ and src/v2/
attach to a fn or a sealed type. This is a latent trap, not a live hole, and the distinction
matters: the first author to reach for it is the one who gets hurt, and they will have no reason to
doubt it.

The pair is one artifact, and that is the point

The positive control (fn form refuses — green) and the finding (operation form does not — red) run
through one invocation, over sources compiled as data via the guarantee probe corpus. Split
into two files they are two observations; together they are a discrimination, and the discrimination
is the finding. Without the control, a red could equally mean the mechanism is inert or that the
file cannot compile a probe at all — different states, different remedies.

Compiling the sources as data is also what makes the pair possible at all: a refusal here is a
resolve error, so an unadmitted call written directly into the module would take the whole file down
with it.

Executed: fn form true, operation form false, same file, same run.

Enrolled as known-red, not left to fail

A bare red takes the floor down and gets triaged as breakage by someone who does not know why it is
there. Per §4b it does not get deleted when the resolver gains operation-grain enforcement — it
flips to a permanent regression control, because deleting the evidence on the climb recreates
specification-without-execution one rung up. The roster's own coherence witness passes with the
identity added.

Rung, honestly

Not mitigatable but below it: no mitigation occurs — nothing refuses, nothing counts, nothing
is logged. Attainable ceiling: structurally guaranteed; the class is decidable and fully
modeled, and only implementation stands between here and there. Next-rung trigger: an
operation-grain construction refusal exists, verified by a correctly-imported unadmitted caller.

That trigger is stated in its verified form because its first two attempted verifications were
inconclusive for reasons unrelated to the seal — a missing import, then a fixture whose service did
not resolve at all. A trigger already mis-measured twice should carry how to measure it.

Not fixed here

The resolver change is substrate work with its own owner and review bar. Routing around the defect,
or following it into infer from this lane, would both be the wrong move.

---

Second change: command_runner's local path stops round-tripping argv through a shell

The chain that is now gone from the local arm: render the argv to quoted text → wrap it in a
bash heredoc → hand it to a shell → let the shell split it back into an argument vector — to reach
a seed that ends in Command::new(argv[0]).args(argv[1..]) regardless. Every step existed only to
undo the one before it. On LocalExec, command_over_transport is the identity, so the render
had nothing to transform either.

Measured before cutting: 22 live call sites across 5 modules, 17 of them
run_shell_command_capture. All 22 pass LocalExec; zero pass SshExec — so the entire live
population moves here. Callers are untouched: the change is internal and both signatures are
preserved.

The enabler, and why it is a wall rather than a claim

ArgvCommand.argv is a runtime List<String>; CliSurface is sole_constructor and its only
route is CliArgumentSyntax fragments, which carry declared token classes and cannot express a
word that does not exist until the program runs (a path, a hostname). So
cli_surface_of_literal_words was added — and restricted to its two callers.

A constructor whose name says "each element is one argv word" is the declaration the refused
state lacks. But review caught that the declaration was unbounded — anyone could make it, about
anything, leaving the interpreter's argv refusal one import away from being satisfied by an intent
nobody checked. So it now carries admit_callers, proven to fire rather than trusted:

constructor call admission refused: 'v2.std.compilers.cli_surface.cli_surface_of_literal_words'
refuses call from 'test.fixture.mint_admit_probe.intruder.unadmitted_mint'
— permitted callers: [gunbc.command_runner.run_shell_command,
                      gunbc.command_runner.run_shell_command_capture]

Verifying it mattered more than usual: this PR's other change establishes that the same mechanism
is accepted-and-inert at operation grain. Writing admit_callers and trusting it is exactly the
trap filed above. This is a fn, which is the grain where it is verified to fire.

The discriminating receipt, executed wet

argv ["printf", "%s|", "a b"]
direct exec → one operand  → "a b|"   OBSERVED
via a shell → two operands → "a|b|"   asserted absent

A green here is impossible with the bash hop restored — which is the point. A test that merely runs
a command successfully would be equally green either way and would prove nothing about what changed.

It is wet and floor-excluded, and the module says so. Hermetic evaluation replays an operation's
declared mock_response and never constructs an argv, so the property is not observable
hermetically; a hermetic version could only assert the mock. The consequence is stated where the
next author stands: CI does not run this, someone reintroducing a bash hop gets no signal, rung
is mitigatable, next-rung trigger is a wet lane that executes floor-excluded receipts.

Named, not fixed

success: false still collapses "ran and exited nonzero" with "could not be executed at all". Under
the bash hop those were genuinely indistinguishable — a missing binary became the shell's exit 127,
a fabricated claim that a process ran when none existed. Going direct removes the fabricator, so
the information is now available at the transport even though ShellCaptureResult cannot carry it.
That converts the conflation from impossible-to-fix into merely-unmodeled. The destination is the
ProcessOutcome coproduct one module away; it is a 17-site caller migration and belongs with those
sites.

The dissolution trigger was aspirational and is corrected

It named host_effect_apply binding ArgvCommand as a typed transport handler. host_effect_apply
does exist (gunbc.host_effect_realize, production) — an earlier revision of this branch said
it did not, which was false and is corrected in place. What is true is that it contains zero
ArgvCommand occurrences, so it dispatches effects but is not a route from an argv to a process.
command_runner is the sole such route: no parallel authority, and satisfying the original
trigger literally would have meant building the second route rather than finding it. The row now
names what actually remains — the SSH arm and the nested command-string target another lane owns.

---

Stacked: ShellCaptureResult replaced at the root by the ProcessOutcome coproduct

A premise correction first, because it invalidates the RED this work was originally scoped around. I had claimed that removing the shell's fabricated exit 127 made "could not be executed at all" observable beside "ran and exited nonzero". That is false, and I tested it: a missing program does not produce a result record — it REFUSES the evaluation (failed to execute '...': No such file or directory (os error 2)). Spawn failure was already fail-closed one rung above the record.

The live conflation is one step over, and it was real at eight sites:

| ran and FAILED, printing nothing | success=false, stdout="" |
| ran and SUCCEEDED, printing nothing | success=true, stdout="" |

Both are stdout == "". Those eight read stdout without consulting success.

The eight, and what each does with ProcessRefused now

Site 1 is a production bug, not a modelling gap. A failed authorized_keys probe produced "", which is not "present", so the code fell through to apply. A refusal to observe caused a mutation — the system took an irreversible action on the strength of an observation it never made. Site 2 is the same failure one step later: writing the literal outcome= into a file subsequently read as fact is manufacturing a receipt out of a refusal.

• fleet_host_key_enrollment.check — the worst. Tested trim(stdout) == "present" with no success check, so a probe that failed produced "", compared unequal, and fell through to the branch that applies. A refusal to read authorized_keys was indistinguishable from the key being absent, and the remedies are opposite. Now refuses and does not mutate.
• fleet_host_key_enrollment.verify — wrote concat("outcome=", trim(stdout)), so a refused verify emitted the literal receipt line outcome= into a file someone later reads as fact. Now outcome=UNKNOWN with the cause.
• fleet_host_key_enrollment.{user,hostname}, fleet_probe_identity_observe.user — display only; routed through process_outcome_receipt_text, which renders the three arms to three distinct strings.
• fleet_probe_identity_observe.{passwd_home,job_home} — used as paths, so these match the arms directly rather than taking the receipt projection: (refused: ...) is fine to print and catastrophic to open. An unreadable home now skips the probe with a stated not-probed line instead of reading .ssh/authorized_keys off a fabricated root.
• fleet_converge_plan_cli hostname -s — surfaced, not closed, and said so in file. A -> String function has no refusal path; the honest repair changes the return type and cascades into converge-plan subject identity. It now returns a value that cannot be mistaken for a hostname rather than a plausible "". Rung: mitigatable, next-rung trigger named on the carrier.

Sites that genuinely do not need the distinction — stated, not left silent

• test -f and the ssh-keygen -F readback: exit status is the product; no caller wants stdout. Both ask process_outcome_admitted directly. Forcing them through an output-bearing variant would add a field they cannot answer.
• fleet_ssh_credential_verify (×2): these decompose at a classifier that consumes exit, stdout and stderr together, so the correlation the other eight were missing was already performed. The match still buys exhaustiveness and names ProcessOutputAbsent, previously indistinguishable from a failure with empty stdout.

Deleted, not kept beside

type ShellCaptureResult is gone, and so is its one fabricated construction: fleet_host_key_enrollment built a ShellCaptureResult to stand in for a filesystem write failure, inventing success: false for something that was never a process. The coproduct makes that unwritable.

scan_host_key_lines shows the type fitting: scan.success && trim(stdout) != "" is ProcessOutputPresent, so a hand-written correlation became a variant.

Discriminating RED, executed wet (6/6)

Nonzero-exit-printing-nothing must be ProcessRefused; zero-exit-printing-nothing must be ProcessOutputAbsent. Both go red if ShellCaptureResult is restored, because then both are stdout == "". The receipt also records what is not tested and why — the nonexistent-program case is already distinguishable via transport refusal, so asserting it would prove nothing.

Why no fourth variant

Because spawn failure is fail-closed at the transport, a caller cannot probe for a binary's existence by trying to run it — the attempt stops the line instead of answering. A NotSpawned arm would be uninhabited: every consumer must handle it, none can reach it. That consequence is recorded on the carrier.

The SSH arm is untouched.

Site 8 has a second row, and it is about reachability

The row above claims the value is visibly wrong rather than plausibly empty. That says nothing about whether it is recorded — and it is.

fleet_converge_plan_wet writes host_short verbatim to fleet_converge_plan_subject_host_path, coerces it to NonEmptyStr as the plan's subject host, and folds it into the member-set fingerprint and the plan content hash. An unobserved hostname is persisted four ways as a receipt later read as fact.

And it defeats the guard built for exactly this case. fleet_converge_apply_wet re-observes the host and refuses on SubjectHostMismatch when observed != planned. Two consecutive refusals produce the same string, so the comparison succeeds and apply proceeds — the check whose entire purpose is to stop a plan being applied on the wrong host is satisfied by two non-observations agreeing with each other. The empty-observation narrow, relocated onto the guard: ⊥ == ⊥ read as "same host".

The obvious patch is not one: making the marker unique per call converts a false match into a false mismatch, which is a different wrong answer, not an observation. Next-rung trigger: the subject-host comparison consumes an outcome rather than a String, so unobserved-vs-unobserved is a refusal to compare rather than an equality.

Not introduced here — the prior code persisted "" and compared "" == "", which passed identically. This migration does not repair the defect; it makes the persisted evidence legible instead of blank. Filed as a second row at mitigatable rather than folded into the first, because two mitigatable states with different reachability are not one finding.

Printable and openable are different capabilities of the same string

Sites 3–5 take process_outcome_receipt_text. Sites 6–7 deliberately do not, and that is the load-bearing distinction: (refused: ...) is fine to print and catastrophic to open. A projection that serves the display site silently serves the path site too. The concrete harm avoided is reading .ssh/authorized_keys off a fabricated root.