Reduce the micro-VM module to the grant authorization rule FCI-2 owns

[briansrls]

Answers one question and stops there: does an execution grant authorize the reserved cell a micro-VM job would run in? The measurement work that was on this branch is now #10806, and the launch plan that was on it has been deleted rather than moved.

Why the launch plan is gone

The original module composed a launch straight from a cell binding and started a VMM. gunbc.fabric_ci_program FCI-3 owns that question — what causes the target process — and its exit predicate is that a persistent executor re-reads the committed Grant before starting, so an absent, corrupt or expired Grant yields zero target processes.

FCI-1's non-goals name Work-process-start and ExecutionGrant explicitly; FCI-2's name process-start. So the module was doing FCI-3's job while skipping FCI-2 — the second execution system ROADMAP forbids when it says the fabric is four consumers of one fabric, not four execution systems.

That is also why nothing consumed it. The correct consumer is the FCI-3 executor, and it could not consume a launch whose signature omitted the grant. Any caller written would have cemented the bypass rather than closing it.

Requiring the grant as a parameter fixed the bypass but left the module still performing FCI-3's job with FCI-2's input bolted on. The honest reduction is to keep only the part that is FCI-2's: the authorization rule. Composition of the launch belongs to the executor, when that lane exists.

What survives, and why deleting the rest lost no coverage

grant_authorizes_reservation refuses on four axes — the money fence, and Work / Demand / Offer agreement between the grant and the cell — and seal_execution_binding pairs a grant with a binding through a sole_constructor type, so an unauthorized binding has no constructor outside the module.

The seven deleted planning claims were duplicates, which is why this is a §2 reduction rather than a §6 scope cut. Their subjects are already covered by execution elsewhere: the reserve and guest-memory boundary family and the orphanable-unit and shared-slot-credential refusals in runner_microvm_witness_test, ownership in runner_microvm_attempt_witness_test, and the credential in the JIT mint witness.

Evidence

Three claims pass by execution:

• a_grant_that_does_not_fence_authorizes_nothing
• a_grant_for_another_work_authorizes_nothing — the substitution seal: a grant issued for a different Work authorizes nothing here
• the_issued_grant_authorizes_its_own_reservation — the positive control

Verified by mutation, re-derived against the reduced module rather than carried over from the pre-reduction run: removing only the Work join reds the substitution claim alone, while the fence check and the positive control stay green. The RED is discriminating, not a blanket failure.

The seal's forbidden state — constructing a MicroVmExecutionBinding outside the module — is already refused by execution under the existing sole_constructor_violation_outside_module test over a synthetic two-module pair, so a type-specific duplicate would be a second authority for one rule. One wrinkle, stated rather than left for a reader to find: compile-enforced on every build, but the evidence one would point at is off the merge path under rust_unit_tests_off_the_merge_path.

No claim asserts the absent-grant case. Its RED is unauthorable once the grant is a required parameter, so that check would be a §4b decoration — permanently green and cited as coverage.

The finding this branch also files

A recurring failure mode row, production_actuation_unmodeled_beside_a_modeled_probe: micro-VM install is modeled and a boot probe launch is modeled, but the launch real jobs take on Mt. Collins is host tooling outside the substrate with .dag carrying prose receipts after the fact. Two homes for one effect, and the modeled one is what a reviewer finds first.

The row records that this finding's own first statement ("no argv_command starting firecracker anywhere") was false and would have been refuted by its own counterexample. It also carries the count-first rule the near-misses on this branch produced: for an append-only carrier, the merge check is a count comparison against the base, not a read of the diff — a re-applied roster renders as reordering, which is exactly what a reviewer expects.

Not in scope

The FCI-3 executor itself, and durable grant state. Durable state extends gunbc.fabric_allocation_store_substrate when that work is dispatched; it does not get a parallel store.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VQ1HbKBP5SH24N2zxExYmN

[gunbai-bot]

Back to draft, and not because of anything a review raised.

The operator asked what consumes dag/gunbc/runner/runner_microvm_launch_plan.dag. Nothing does — and it is a chain rather than one module:

• bind_microvm_to_cell — consumed only by the launch plan
• plan_jit_mint — consumed only by the launch plan
• runner_microvm_launch_plan — consumed by nothing

So this is a plan for an action that is currently impossible: production refuses every launch on ReserveUnmodeled, so the actuator that would consume this cannot usefully be written yet. That is §6's new-artifact-with-no-final-consumer, and the reviewer's test — will this survive the terminal architecture substantially unchanged and be consumed by it — I cannot answer yes to, because the actuator's shape depends on a reserve nobody has declared.

Worth recording that the defense I gave for plan_jit_mint in #10661 was "the lifecycle controller is its caller." I then built the caller and gave it the same defect, which voids that defense rather than discharging it. A promissory consumer is not a consumer.

Two approvals and four green checks are not evidence against this. They measured hygiene on a diff; none of them asked whether the thing should exist.

The ordering error underneath: the first question for "run jobs in micro-VMs" was whether a VM can be admitted at all, which is a measurement on the host and cheap. Instead this modeled three layers above an admission that refuses unconditionally, and the refusal surfaced only when a test written here failed.

Next is measuring the VMM resident footprint on srv2 so the reserve can be declared or rejected on evidence. This PR stays in draft until there is an actuator to consume it; if the measured shape says the composition should look different, this gets rewritten rather than defended.

— sent from nimble-swift-27

[briansrls]

Direction from Brian’s standing goal: the next success is a wet FCI-3 launch, followed immediately by one real required-witnesses-build canary—not another unconsumed planning layer. Keep this PR draft and stack the executor on it now; do not wait idle for #10806 review.

One correction before proceeding: requiring an ExecutionGrant parameter does not yet make this launch the realization of that committed fabric grant.

At head 9ff38d47d9c1ab30b873999ef83214e46acc2135, plan_microvm_launch accepts ExecutionGrant, MoneyAccount, and RequiredBuildCellSnapshot independently. The planner checks only fence_admits(account, grant.money_reservation, grant generation) before using the independently derived cell binding. It does not join:

• grant.context.work to snapshot.work
• grant.context.demand to snapshot.demand
• grant.object.offer to snapshot.offer
• grant.context.lease to the held reservation generation/content/fingerprint
• grant.context.executor to the selected execution cell/host
• grant.context.attempt to the micro-VM attempt, storage paths, unit name, or JIT runner identity

That leaves a valid grant for A able to authorize a launch bound to snapshot B if the supplied account fences. It is the same admission/execution substitution class this lane has already been repairing. Also, ExecutionGrant is presently an ordinary record, and the IssuedAuthorization { grant, account } pairing described in this PR exists only in the witness; the production signature still splits them. A required parameter closes Absent only syntactically. It does not establish issuance, durable commitment, independent re-read, or subject agreement.

Build this next: the smallest real FCI-3 executor

The executor—not a caller or workflow request—must:

1. Independently re-read a durably committed grant after the submitter has terminated. It must not accept a raw ExecutionGrant, MoneyAccount, RequiredBuildCellSnapshot, or LaunchAdmitted as caller-supplied authority. If there is no durable grant representation/store yet, add the minimum CAS-backed one in this vertical slice; FCI-3’s predicate cannot be met by an in-memory value.
2. Join the exact identities above before any JIT API call or target process. Mint one sealed FCI-3 execution binding from the committed-grant observation + reserved-cell observation. This is evidence of re-read/agreement, not a second authorization decision.
3. Use grant.context.attempt as the execution-attempt identity. The current micro-VM identity derived from snapshot.work.key + snapshot.generation may be a collision-safe storage spelling, but it is not the fabric ExecutionAttemptKey. Derive or bind the attempt directory, systemd unit, JIT runner name, and eventual receipt to the grant’s exact attempt identity after the join.
4. Construct the launch plan inside the executor after revalidation. Make the lower raw-argument planner inaccessible to other production callers (admit_callers or an equivalent sealed boundary). A preconstructed LaunchAdmitted is not authority to execute.
5. Perform the real effects in order: materialize attempt storage; mint the installation token/JIT config on the host; write only the opaque JIT bytes to the attempt-owned read-only drive; start exactly one Firecracker transient unit in the reserved slice; observe its InvocationID/MainPID/cgroup and bind that observation to the attempt.

A timer/path unit or narrowly scoped host service is sufficient for the first executor. Do not build a general scheduler. “Persistent” means the executor and committed grant survive the submitting process—not that this PR needs multi-host failover.

Wet acceptance—do not substitute pure witnesses

On an isolated disposable grant/store subject on srv2:

• issuer commits, exits, and the executor independently starts exactly one VMM for one live grant;
• deleting the grant before the executor read yields zero JIT mints and zero VMMs;
• corrupting it yields zero/zero;
• expiring or superseding its lease yields zero/zero;
• substituting Work, Demand, Offer, cell, executor, lease, or attempt yields zero/zero;
• restarting/re-running the executor does not start a second target for the same attempt.

The evidence must observe the actual GitHub request count/runner identity and actual systemd/VMM process population—not only LaunchRefused* from a pure function. Return the exact source SHA, grant/attempt/work/cell identities, host service invocation, JIT runner id/name, systemd InvocationID/MainPID/cgroup, and process count.

#10806 is preflight, not the measurement result

#10806’s host standing does useful instrument discovery and its new footprint module defines the sample/receipt vocabulary, but that module currently has no wet sampler or production receipt producer. Seven passing claims establish its pure model, not a VMM footprint. Add the minimum actuation route and run all declared sizes on srv2; return the complete receipt and run id. Use it to justify a canary-specific reserve, not a universal worst-case bound. Do this while building FCI-3 rather than serializing more groundwork behind its review.

Continue directly to the user-visible milestone

After the wet FCI-3 positive path, do not stop for cache design, a replenishing pool, multi-host scheduling, or cutover. Route one explicitly selected existing required-witnesses-build canary to the unique JIT runner, cold-cache if necessary; record the actual GitHub job conclusion and metered vCPU-minutes; prove VMM, JIT drive, writable attempt storage, network resources, runner registration, and cell holding are gone before release. That is the next report Brian needs.

A useful next update is therefore one of two things: the actual #10806 footprint receipt, or the exact first failing boundary while the persistent executor re-reads and launches from a committed grant. Another compile-only or pure-claim-only checkpoint is not progress toward this milestone.

[gunbai-bot]

Both findings confirmed and fixed in a1ecaad290e. Review 62316.

1. Silent roster drop — confirmed, and it is this PR's own class

Verified by the count comparison rather than the diff, then named by an identity join:

• origin/main: 175 enrolled
• branch HEAD: 174 — added production_actuation_unmodeled_beside_a_modeled_probe, dropped decision_surface_truncation (std.decision: decision completeness as a closed subject #10712) and lookup_miss_read_as_positive_classification (Genericity is declared, not inferred from a failed lookup #10727)

Both landed after my branch point, both module files still present, and the triple-dot diff renders it as reorder-plus-two — exactly the blindness the row I am adding describes. The review is right that this PR filed the rule and then broke it.

Repaired by merging origin/main so the roster derives from the current authorities rather than from my branch's stale copy. Now 176 with an empty join in both directions. I checked the imports and the data list body separately, because either half can drop alone and agreeing counts would hide a half-drop: 176/176, no asymmetry.

The projection docs/design-failure-modes.md is DesignFailureModesArtifact => HealRegeneratesAfterProvisionalMerge, so regenerating it after a merge is heal's job by declaration, not a hand-edit — I have deliberately not hand-written it.

2. Launch-plan residue — confirmed

• Imports: module 32 lines → 8, witness 37 → 18. All ~38 names from the deleted launch graph are gone (plan_jit_mint, RunnerMicroVmAdmission, FirecrackerVmConfig, the JIT/credential types).
• Stale annotation: the mint-last / LaunchAdmitted block asserted an ordering with no mint and no launch left to range over. Replaced with what the module now does, and it states explicitly that the ordering argument is not restated here because it belongs with the FCI-3 executor. Worth naming the reason this matters: a §4c annotation is read by no Accepted program, so a false one never reds — and it drifts in the direction that flatters the change.
• Orphan fixtures deleted: launch_org, launch_net, launch_binding, witness_reserve, both lifecycle intents, launch_test_slot. witness_reserve's own note was stale too — it still said production's reserve is ReserveUnmodeled and every launch refuses, which Set aside the allowance the VMM lives in, so a sized guest can also be an admitted one #10657 changed.

One thing the review did not raise, found while fixing it

seal_execution_binding has zero consumers — not production, and no witness can call it, because its input is a sole_constructor RequiredBuildCellSnapshot. Under §3c that is admissible only as a declared frontier with its trigger stated, so I declared it: named consumer is the FCI-3 executor, and the annotation states the trigger is not near — docs/plans/microvm-launch-displacement-analysis.md (#10823) establishes the production actuation it would displace is authored in no repository. The alternative is stated beside it: if that trigger is judged too distant to carry an unconsumed declaration, delete the seal and let it return with its consumer. The authorization rule stands alone and is consumed by three claims.

Evidence

Three claims pass by execution after the rework. Compile shows the 3 pre-existing dag/extdeps/gunbc/gunbc.dag shell-transport errors present on the merged tree and nothing in either of these files.

— sent from nimble-swift-27

[gunbai-bot]

Confirmed and fixed in aa56c4dc765. Review 62349, and this is the sharpest finding on the branch.

The gap was real and it was rung inflation

Four refusal arms — fence, Work, Demand, Offer — and two enrolled REDs. A rule that deleted the Demand and Offer joins would have greened every claim in the file, so the join was reported at a rung its executed evidence did not establish. That is §4b(1) rung inflation in the one module whose entire purpose is refusing a substitution, and the review is right that the join was only half-evidenced.

Two controls added in the same shape as the Work case. Arm-to-assertion count is now 4 and 4 — one RED per refusal arm.

Mutation-proven individually, because five passing claims do not establish discrimination

A control that fails alongside others is not a discriminating RED. So each new arm was removed in isolation and the suite re-run:

mutation	result
remove only the Demand arm	only a_grant_for_another_demand_authorizes_nothing reds — other four green
remove only the Offer arm	only a_grant_for_another_offer_authorizes_nothing reds — other four green

Baseline: all five pass. The module was restored from git and re-verified (4 refusal arms, 3 identity joins) before committing, so no mutation leaked into the diff.

One thing recorded in the witness rather than left here

These two REDs are authorable while the seal's is not, and the questions sound identical — so the witness now carries the test that separates them. The seal's input is a sole_constructor RequiredBuildCellSnapshot: a disagreeing snapshot has no constructor a fixture can reach, so a control aimed there would be a §4b decoration, permanently green and worse than absent. FabricIdentity is an ordinary constructible record, so a disagreeing demand or offer is writable right at the call site.

The constructor decides it, not how important the check feels. I applied that test correctly in one direction on this module and missed it in the other, which is why it is now written down beside the controls rather than re-derived by the next reader.

— sent from nimble-swift-27

[gunbai-bot]

Both findings confirmed and fixed in 6fd817fa898. Review 62362.

1. The seal is deleted — the review's argument is the one my own annotation made

§3c admits a frontier only with a named later change, and mine was FCI-3, which #10823 shows is blocked behind a prerequisite nobody has started. The review's phrasing is exact: a gate id plus a missing plan and an unpriceable prerequisite is not a named later change.

Worse, and this is the part I want on the record: the annotation cited docs/plans/microvm-launch-displacement-analysis.md, which does not exist on this branch — it is on the unmerged #10823. So the justification for retaining unconsumed code rested on an artifact that does not resolve. That is the same citation defect corrected on #10823 earlier today, made a third time across an unmerged branch boundary, and this time inside an argument for keeping code.

This discharges rather than overrides the earlier ruling to keep the seal. That keep was explicitly conditional on a fixture being able to author the forbidden state and be refused. I later established no witness can call seal_execution_binding at all — its input is a sole_constructor RequiredBuildCellSnapshot. The condition failed, so deletion is what that ruling directs.

The module is now 79 lines: one rule, four refusal arms, five claims. All five still pass with the seal gone, which is the evidence that they were driving the rule and never the seal — a claim that had been leaning on the deleted code would have gone red here.

2. Roster behind main again — confirmed

HEAD 176, origin/main 177, missing guarded_filter_branch_dropped_by_emitter and match_variant_lookup_does_not_peel_type_alias, exactly as reported. Merged: 178 imports and 178 list entries, empty identity join against main in both directions, both halves checked separately.

This is the second time on this branch. The ledger surface moves faster than an edit-review cycle, and the count comparison is the only thing that catches it — a diff read renders it as reordering every time.

The projection came back UU with no conflict markers, the generated-artifact merge driver refusing as designed rather than silently taking a side. That artifact is HealRegeneratesAfterProvisionalMerge, so the provisional state is staged for heal rather than hand-written; I will verify the projection identity-joins the roster at 178 once heal pushes.

— sent from nimble-swift-27

[gunbai-bot]

Repaired and measured — heal pushed 2a3d0da362. Review 62376.

The finding was correct

Roster 178, projection 176, both restored identities missing from the index and the bodies. Confirmed exactly as reported before fixing anything.

Repair, verified rather than assumed

check	result
index bullets ↔ roster imports	178 ↔ 178, empty identity join in both directions
guarded_filter_branch_dropped_by_emitter body	present (matched on an exact substring of its own receipt)
match_variant_lookup_does_not_peel_type_alias body	present (same method)
file growth	377 → 381 lines — 2 index bullets + 2 bodies

Two of my first verification greps returned 381 — the whole file — because the extracted pattern was empty, and an empty pattern matches every line. A broken check reports total success, so I re-ran with literal substrings lifted from each module's receipts. Worth stating because it is the same shape as a control that cannot fail.

The part of this that was mine

I staged a projection I had personally measured as inconsistent (176 vs 178) and justified it as provisional because the artifact is HealRegeneratesAfterProvisionalMerge — then pushed, reported the branch, and moved on without observing the outcome. The declared policy made that defensible; committing a state I knew was wrong and never watching the fix land did not. "Heal will regenerate it" is a prediction, not evidence, and this PR's own new row is about a modeled path standing in for an observed one.

I could not repair it locally, which is a real constraint rather than a preference: the heal job builds its own regenerator from the checkout, while my local binary (2026-09-05) fails on dag/gunbc/machine_intake/oob_boot_handoff.dag — a file byte-identical to main that this branch never touches. A current local build is a full release build in a shared 31 GiB slice, and a remote build produces an amd64 binary that will not execute on this arm64 session. So heal was the only available regenerator; the correction is that I now verify its result instead of trusting its commit message.

The authorization reduction the review found sound is unchanged: seal deleted, grant_authorizes_reservation with four typed refusal arms and five discriminating claims, fixtures reused from test.claim.fabric_grant_issuance_witness.

— sent from nimble-swift-27

[gunbai-bot]

Both findings confirmed and fixed in 26cb9df0a9. Review 62386.

1. The rule had no declared frontier — the review's diagnosis is exact

git grep confirms it: grant_authorizes_reservation has three kinds of hit — the definition and the witness, nothing else. bind_microvm_to_cell takes only a RequiredBuildCellSnapshot and never sees an ExecutionGrant.

The precise defect is the one the review names: the module header declared a frontier for what I deleted and said nothing about the rule it keeps. §3c's two admissible states differ by whether the consumer and trigger are stated beside the declaration, and for the rule they were not — so it was dangling rather than declared.

Now stated: named consumer is the FCI-3 executor, whose exit predicate in gunbc.fabric_ci_program is that a persistent executor re-reads the committed Grant before starting, so an absent/corrupt/expired Grant yields zero target processes — this rule is the agreement half of that predicate. Trigger is that executor existing. Route today: nothing in the runner path calls it.

It is stated with its cost rather than as a reassurance: that trigger is not near, because the actuation FCI-3 must displace is authored in no repository. A reader deciding whether this module earned its place should weigh that against what it carries — four typed refusal arms, each with a discriminating RED mutation-proven to red alone. Correctness is established by execution; only production consumption is deferred.

2. The annotation was false, not merely stale

It said the rule was "factored out of the seal above it" and that "the seal delegates to it". The seal was deleted in the previous commit, and bind_microvm_to_cell never takes a grant — so the sentence asserted a relationship between two declarations that does not exist in the corpus. The review's §4c citation is the right one, and its framing is better than mine: a false structural claim is worse than restatement.

Recorded as false rather than quietly removed. A §4c annotation is read by no Accepted program, so a false one never reds — the next reader deserves to know the claim was wrong rather than find a tidy comment where it used to be.

A tension in my own reasoning, named rather than left to be found

I deleted the seal partly on the grounds that its FCI-3 trigger "is not near", and I am now declaring a frontier for the rule on that same trigger. §3c requires a trigger to be stated, not to be near, so "not near" was over-applied as if it were the test.

The seal still went for the right reason, and it is a different one: no fixture could construct its sole_constructor input, so it had zero executed evidence. The seal failed consumption and evidence; the rule fails only consumption. That is the distinction I would defend — not the one I originally gave.

Evidence

5 claims pass by execution after the change.

— sent from nimble-swift-27

[gunbai-bot]

Both findings in review 62520 were real and both are fixed in 404195dec. One of them could not be fixed at the address the review named, and that is the part worth reading.

The String cause — correct, and it made my own annotation false. The annotation directly above the type asserted "THE REFUSAL ARMS ARE NOT COLLAPSED INTO ONE cause STRING", while the type was exactly AuthorizationDisagrees { cause: String }; the four "arms" were four if branches producing four prose strings. That is DESIGN §2's anemic String leaf, and because a §4c annotation is read by no Accepted program, the false claim could never red — it would have been cited as coverage indefinitely. Now a typed sum matching the sibling ReceiptAdmission:

GrantAuthorizes | GrantFenceRefused | GrantAuthorizesDifferentWork
| GrantAnswersDifferentDemand | GrantIssuedAgainstDifferentOffer

The five controls now match a named variant rather than string_contains. That strengthens them beyond the review's ask: a refusal that named the wrong authority could still have carried the right words, so the substring match could not separate "refused for this reason" from "refused for some reason whose text happens to contain these words".

The home — correct, but execution.dag cannot hold it. The review prescribed placing it beside admit_receipt_for_grant in product.fabric.execution. That placement does not compile: the rule needs MoneyAccount and fence_admits from product.fabric.budget, and budget already imports execution (product.fabric.budget, its import of ReservationRef). Homing it in execution closes that into an import cycle — the one structural law §4 states, and the only thing it says about the import graph.

I homed it in product.fabric.grant_issue instead, which already imports execution, budget, identity and work with no cycle, and which is the module that issues the grant. That makes the agreement join the direct counterpart of issue_grant at exactly FCI-2's grain — gunbc.fabric_ci_program gives FCI-2 the owned question "Which sole grant authorizes this Work?". The reviewer's underlying finding stands unchanged: this is fabric vocabulary and had no business claiming SingleAuthority under a gunbc.runner_microvm_* module. That module is deleted, and the witness moved to test.claim.fabric_grant_authorization_witness, beside the issuance fixture it already imported.

I also re-declared the §3c frontier at the new home rather than losing it in the move: the rule still has no production consumer, its named consumer is the FCI-3 executor, and the trigger is stated beside it.

Executed evidence, not a typecheck. All five claims pass under claim_batch --claim-run --source-root dag --source-root src/v2 --entry dag/test/claim/fabric/fabric_grant_authorization_witness_test.dag.

Still blocked, and not on a witness. The required run refuses at FAILED PHASE namespace-wave-admission (1 unadjudicated delta) while the floor on that same run is verdict=FloorClean claims_failed=0 unexpected_failures=0. Adding the row file this PR files splits into two deltas: the membership edge auto-admits as "reached by a name this module authors", and the binding refuses as NewPoolCoincidenceResolution. Since #10822 made failure-mode membership the row directory, this is the first row filed under that scheme and every future one will hit the same wall. That disposition refuses unless an operator-authored transition admission names it, so I have escalated rather than self-serving one — that would be the escape hatch §5 forbids.

— sent from nimble-swift-27

[gunbai-bot]

Both findings in review 62587 are real and both are fixed in 6744bb522d. The second one explains why the first survived, so I'll take them together.

The rule joined two independently advancing counters. fence_admits compares the generation the account holds for a reference, and product.fabric.budget reserve_money records that from the money request (generation: request.generation). The rule was presenting grant_lease_generation, which answers the resource lease's counter. So a grant authorized whenever the two happened to coincide, and a legitimate grant whose counters had diverged was refused as GrantFenceRefused — a cause naming the wrong fact. You're right that product.fabric.execution already records this class one authority over; this was that class re-introduced against a different generation authority.

ExecutionGrant carries no money generation at all — money_reservation is a bare ReservationRef — so there was no correct value to read off the grant. It is now a presented coordinate, which is what the rest of the rule already does and what makes its REDs authorable at all. The witness presents money_request.generation (what the issuer asked for) against what the account recorded — two independently authored facts. Reading it back off the account would compare a value to itself and be green by construction, which is exactly the §4b decoration this rule was written to avoid.

The positive control was green by fixture coincidence, as you said. money_request.generation = 9, fixture_lease.generation = 9. I left both at 9 and carried the discrimination in a new claim instead — a_grant_fenced_at_another_money_generation_authorizes_nothing, which presents the right account against a wrong generation. That is the arm the coincidence was hiding: the existing exhausted_account claim refuses because the account holds no lease for the reference at all, so a rule ignoring the generation entirely would still pass it.

Mutation-proven, and the result is your finding as an executed measurement. With the defect restored, exactly one claim fails:

PASS a_grant_that_does_not_fence_authorizes_nothing
FAIL a_grant_fenced_at_another_money_generation_authorizes_nothing
PASS a_grant_for_another_work_authorizes_nothing
PASS a_grant_for_another_demand_authorizes_nothing
PASS a_grant_for_another_offer_authorizes_nothing
PASS the_issued_grant_authorizes_its_own_reservation

Five pass under the defect, including the old positive control. The pre-existing suite was structurally blind to this, which is how it survived review twice. Reverted, all six pass.

I also dropped the now-unused grant_lease_generation import — leaving it would advertise a dependency the code no longer has.

One note on what this does not claim: the fence still establishes only that the account agrees with a presented money generation. It does not establish that fabric issuance durably committed the reservation, and the §3c frontier above the rule says so. Whether ExecutionGrant should carry its money generation structurally — so the coordinate could not be misrepresented by a caller — is a fabric type question I have deliberately not decided inside this PR.

— sent from nimble-swift-27