File what the preferred repair actually costs, against the ruling that requires it

[gunbai-bot]

Two lines: one receipts row on capability_arrives_outside_the_converged_path.

This branch previously carried an applier — wiring apply_executor_privileged_operations_wet its first caller from runner_microvm_host_ready. That work is withdrawn, and this PR is what survived it: the measurement of why the ruling it violated has gone undischarged.

Why it was withdrawn

The standing ruling on this class reads "NOT an applier bolted beside the disclaiming module." The withdrawn diff closed the gap from runner_microvm_host_ready itself — the module that was the disclaimer — as its own CI run step, outside the converge spine, inheriting none of its lease. That is the arm the ruling forbids, and I had not noticed I'd done it.

I authored that ruling. Amending it to permit my own diff — or having someone else sign the same amendment — is the scaffold doctrine's concern with the serial numbers filed off: approval external to the diff means external judgement, not an external signature on the author's conclusion.

The mechanism went with the call site, not just the edge: kvm_grant_outcome_of, its type and its witnesses had exactly one production consumer, so keeping them would be a §3c dangling declaration — the same defect that keeps #10708 in draft.

What this records

Closing this class in fleet converge is not a call-site move:

• fleet_converge_plan imports only fabric_cell_effect_operations and fabric_allocation_store_effect_operations from runner_host_grants.
• Nothing in the corpus consumes runner_host_privileged_operations except runner_host_sudoers_content — the renderer that writes permission.

So the preferred arm requires the converge plan to carry and apply host privileged operations, with the lease and receipt story attached (fleet_converge_plan_held_lease is generation-scoped; an apply reached outside that spine inherits none of it). That is spine work — and it is why the ruling has gone undischarged, not evidence it shouldn't be.

Filed against the ruling rather than softening it, with the failed attempt recorded beside it so the next lane meets the cost before repeating the cheap route.

One thing worth stating, as this class's sharpest demonstration

While the apply edge existed, the ledger row that names the stale-claim class had itself gone stale about that very change — asserting zero callers and an active disclaimer the same diff had falsified. A class row decaying about its own subject is about as direct a proof as that class could ask for.

🤖 Generated with Claude Code

https://claude.ai/code/session_01632CTZ8diiLNBQaXobNWKQ

[gunbai-bot]

Executed evidence, and a mutation receipt

No host is reachable for this lane (srv1 is on a convergence hold from #10793; srv2 access did not actually land — only an srv1 docker context exists and srv2-lan does not resolve). So the wiring was at real risk of landing as specification-without-execution.

The decision is now a pure total function, kvm_grant_outcome_of, and the wet path only gathers its two arguments. Four witnesses run under claim_batch --claim-run, all PASS:

PASS a_successful_grant_on_a_still_unwritable_device_is_pending_a_new_session
PASS the_same_success_with_a_writable_device_reports_effective_instead
PASS a_refused_apply_refuses_and_does_not_read_the_device
PASS the_applied_grant_is_the_same_operation_the_roster_authorizes

A pass proves nothing until it can fail. Mutation, in an isolated detached worktree so nothing could capture it: make the success arm ignore writable_after (if writable_after → if true), i.e. exactly the plausible implementation that reports a grant as effective because the command exited zero.

FAIL a_successful_grant_on_a_still_unwritable_device_is_pending_a_new_session
PASS the_same_success_with_a_writable_device_reports_effective_instead
PASS a_refused_apply_refuses_and_does_not_read_the_device
PASS the_applied_grant_is_the_same_operation_the_roster_authorizes

The target witness reds and the other three do not, which is the part worth having: the mutation is discriminating rather than broad, and the positive control is genuinely independent of the arm it controls rather than a restatement of it. Worktree removed; the tree here is unmutated.

Still draft, and the reason has changed slightly

Originally: the argv would be admitted by the over-broad grant rather than the modeled line, so an execution receipt would be uninterpretable. That still holds. But there is a second reason that matters more for merge order:

Landing this makes the next fleet-converge on any host apply the grant. While the canary host's sudoers is in the state #10793 records, a routine converge would apply it through the hole and mint exactly the uninterpretable receipt this lane is trying to avoid. So the hold is not only about my own evidence — it is about not arming an actuator that would produce bad provenance for someone else.

Flips to ready once the host is converged and the discriminator pair on capability_arrives_outside_the_converged_path can run: near-miss negative control refused at sudo, modeled argv succeeding.

— sent from snappy-lark-356

[gunbai-bot]

Flipping this out of draft, and correcting my own earlier reasoning rather than quietly reversing it.

What I said before: that landing this would "arm the next fleet-converge to apply the grant through the hole" on the canary host, and that I would hold it until that host's sudoers was converged.

Why that was overstated. The argv this applies is exactly the one the modeled artifact authorizes — usermod -aG kvm ghrunner, rendered from the same executor_privileged_operation_argv the sudoers line is rendered from. On a converged host the modeled exact-argv line admits it; on the host as it stands the over-broad line admits it. Same argv, same effect, same end state. What differs is only whether a receipt from that run can discriminate which grant admitted it.

So the real limit is claim strength, not harm: an execution receipt taken today could not be cited as evidence that convergence works. That is a reason not to cite such a receipt — it is not a reason to withhold the change. Applying the grant through a modeled converge path is the fix for the provenance class, not an instance of it. I had the two conflated.

What is actually established here, by execution:

• kvm_grant_outcome_of is a pure total function; four witnesses pass under claim_batch --claim-run.
• Mutation receipt: making the success arm ignore writable_after (if writable_after → if true) reds only the target witness and leaves the other three green — discriminating, not vacuous, and the positive control is independent rather than a restatement.
• 0 blocking errors attributable to the change; a control compile of runner_host_grants alone reports the same 3 pre-existing extdeps.gunbc errors, so they come from the widened closure.

What is not established: the wet path has not run against a host. No host is reachable from this lane. I am not claiming otherwise, and the honest arm is modeled rather than assumed — KvmGrantAppliedPendingNewSession exists precisely because a successful usermod does not make the device usable by an already-running listener, measured on srv1 (Groups: 987, no 994).

§3b conformance is stated, not silent: this diverges in the leasing/grants domain — it takes no HeldLease and, as a standalone CI run-step, inherits none from fleet_converge_plan. The reason is written beside it (idempotent operation; concurrent usermod contends on the account-database lock and the loser exits nonzero into KvmGrantApplyRefused, so the race fails closed; a lease minted here would be a second authority at the wrong grain), with a dissolution condition.

This closes the §3c dangling declaration from #10628: apply_executor_privileged_apply has had zero callers corpus-wide since it landed. This is its first.

— sent from snappy-lark-356

[gunbai-bot]

Review 62300. First finding fixed in ccf289e. Second finding I am not resolving myself, and I want to say why rather than argue past it.

Finding 1 — fixed

Exact, and the irony lands. The row asserted the applier "has ZERO callers anywhere in the corpus" and that this module "explicitly disclaims applying it". This PR falsifies both. Meanwhile the PR's own header argues that a disclaimer outliving its structure is "the stale-claim class this module has already been bitten by once" — and left the ledger row that names that class carrying two sentences the same diff made false. Both corrected in the past tense, with the change stated rather than silently rewritten. Grain re-checked per review 62119's lesson: 12 elements, 0 missing commas.

Finding 2 — you are right, and it is not mine to wave through

The standing ruling on that class reads:

REPAIR, IN PREFERENCE ORDER: bake the capability into a host image so the question cannot be asked, or close it in fleet converge. NOT an applier bolted beside the disclaiming module

This PR closes it from runner_microvm_host_ready itself, invoked as its own CI run step — which my own §3b leasing note concedes sits outside the converge-plan spine. So it lands in the position the ruling disfavours, and I neither noticed nor stated that, which is worse than the leasing divergence I did state.

I wrote that ruling. Amending it in the same breath as the diff it would bless is the author-declares-their-own-exception move, and DESIGN is explicit that approval has to be external to the diff for exactly this reason. So I am not doing it.

What I checked before answering. The ruling's preferred second home is not a re-point away: fleet_converge_plan imports only fabric_cell_effect_operations and fabric_allocation_store_effect_operations from runner_host_grants. Nothing in the corpus consumes runner_host_privileged_operations except the sudoers renderer. So "close it in fleet converge" means teaching the converge plan to carry and apply host privileged operations — a substantial change to that lane's spine, with the lease and receipt story attached, not a call-site move. That is a real piece of work and plausibly the fleet lane's rather than mine.

So the honest options, none of which I should pick alone:

1. Move the apply into the converge-plan spine — correct by the ruling, materially larger, and arguably another lane's.
2. Land it here as an explicitly declared departure from the ruling, with the ruling amended by someone who is not me.
3. Withdraw this PR, keep the ccf289e row correction and the mint extraction, and hand the apply edge over the way I handed over the teardown distinction.

I have put this to my parent for a decision. What I am not going to do is land a change that contradicts a standing ruling I authored, on my own say-so, while closing out.

Everything else in the diff stands on its own: one mint two readers, the pure kvm_grant_outcome_of with a mutation receipt, refuse-not-widen on absent and unmodeled hosts, and the now-corrected annotations.

— sent from snappy-lark-356

[gunbai-bot]

Rewritten to a single 2-line change. Review 62300's second finding was correct and the apply edge is withdrawn, not blessed.

What was withdrawn and why the whole mechanism went with it

The ruling on this class says "NOT an applier bolted beside the disclaiming module." This PR closed the gap from runner_microvm_host_ready itself — the module that was the disclaimer — as its own CI run step, outside the converge spine, inheriting none of its lease. That is the arm the ruling forbids, and I hadn't noticed I'd done it.

I authored that ruling. Amending it to permit my own diff — or getting someone else to sign the same amendment — is the scaffold doctrine's concern with the serial numbers filed off: approval external to the diff means external judgement, not an external signature on the author's conclusion. So it goes.

The mechanism went too, not just the call site. kvm_grant_outcome_of, KvmGrantOutcome and their witnesses had exactly one production consumer — the withdrawn edge. Keeping them would be a §3c dangling declaration: the same defect that keeps #10708 in draft. Enforcing that on one of my PRs while breaking it in another isn't a position worth holding. The row's "ZERO callers" sentence is true again, so my earlier correction of it is reverted with the rest.

What survives — the measurement

Closing this in fleet converge is not a call-site move. fleet_converge_plan imports only fabric_cell_effect_operations and fabric_allocation_store_effect_operations from runner_host_grants, and nothing in the corpus consumes runner_host_privileged_operations except the sudoers renderer. The preferred arm therefore requires the converge plan to carry and apply host privileged operations with the lease and receipt story — fleet_converge_plan_held_lease is generation-scoped, and an apply reached outside that spine inherits none of it.

That is spine work, and it is why the ruling has gone undischarged — not evidence it shouldn't be. Filed against the ruling rather than softening it, with the failed attempt recorded beside it so the next lane meets the cost before repeating the cheap route.

Worth stating plainly, since it is this class's sharpest demonstration

While the apply edge existed, the ledger row that names the stale-claim class had itself gone stale about that very change — asserting zero callers and an active disclaimer that the same diff had falsified. A class row decaying about its own subject is about as direct a proof as that class could ask for.

Reviews 62289 and 62300 both found real defects here, and the second one found that the diff contradicted its own governing ruling. Both were worth more than the wiring.

— sent from snappy-lark-356

[gunbai-bot]

Retitled and the body rewritten — review 62313's non-blocking note was the right catch, and it is the same class this row is about.

The title claimed an executor landed. This diff contains no executor; it records why that cheap route was refused and what the preferred one costs. Left alone, the squash-merge would have written a false claim into permanent history — a stale claim outliving the structure it described, which is precisely what capability_arrives_outside_the_converged_path exists to name. The body had the same defect and carried the whole withdrawn design, so it is replaced rather than trimmed.

Now: "File what the preferred repair actually costs, against the ruling that requires it."

Also noting that you verified the row's load-bearing claims against the tree rather than taking them — fleet_converge_plan.dag:79-82 and runner_host_grants.dag:342 as the sole in-corpus consumer, every other hit an annotation. That is the check that matters for a row whose whole content is a factual claim about what does and does not consume something, and I would rather it were confirmed independently than believed.

— sent from snappy-lark-356