Pkg4: resource-admitted execution on one host

[gunbai-bot]

This PR is admission + pool. Lifecycle/recovery is PR 2 (split approved by the manager, 2026-09-21). The reason is safety, not workload: without a recovery route every lifecycle defect degrades to the seat stays charged — the host under-admits and nothing is over-promised. With a half-built one, the same defects free seats that should not be freed. The gap is declared as a rostered failure mode with a capability trigger, not left implied. Head: 5ee0cceea8922117e09a0e86670527e20864c9e2.

Subject

Admission of a compute work request on ONE host against observed memory capacity, through an atomic reservation. Home domain: fabric/compute + the leasing rows of DESIGN §3b.

What was wrong

gunbc.compute.work_provider_local admitted work by listing its lease directory, comparing the count against compute_cold_build_cap = 2, then creating a lease for this identity.

1. It was not atomic. The list and the create are two operations on different names, and the create's O_EXCL excludes a second producer of the same identity. Two requests with different identities both read one lease in flight, both compared 1 < 2, and both created their own lease — the cap admitted three. No exclusive create of any path excludes a quantity.
2. A count is not a capacity. Two producers on a 125 GiB host and two on a 502 GiB host are the same policy applied to machines differing fourfold, and a class needing a gibibyte was charged the same as a release build.

Implementation boundary

New gunbc.compute.host_capacity — and it coins no capacity vocabulary. The homes DESIGN §3b already names for this domain do the work:

• product.capacity.pool — appropriation, encumbrance, term, release law
• product.capacity.pool_events — SeatRequest, PoolAcquired, PoolReleased
• gunbc.fabric_event_log — one compare-and-set per append against the partition head. That is what makes the reservation atomic across competing requests rather than merely checked.

This module declares which pool (the host's compute appropriation), where it linearizes, and joins it to the observation.

Linearized on this host, not the fleet DB. gunbc.fabric_storage_placement places the fabric DB on srv1 because an upstream rate limit is metered on a credential that every host contends for. A host's own memory is not such a fact — every contender is local — so routing it through another machine would refuse a local build when that machine was unreachable, a refusal that is not about capacity at all. Same realization (gunbc.fabric_storage_file_store, whose exclusive create supplies the linearization), rooted under this host's own compute root; the partition names the instance.

Two readings, joined in one comparison — not two checks. MemTotal is installed memory and does not move; MemAvailable is what is free right now, including everything outside this pool. They are not independent tests, and making them independent was the first design defect: the ceiling an attempt is adjudicated against is min(appropriation, observed available), evaluated inside the same CAS'd fold that computes the pool's committed total. So "everything this pool has promised, plus what I am asking for, must fit in what the machine actually has" is one predicate in one linearized step. Read through a new linux.Procfs.ReadMeminfo operation (one op per file, as the service already requires) and a parse that lives with the fields' owner, extdeps.linux.proc_meminfo.

The bound is worst-case-sound and conservative, and says so: MemAvailable already excludes what outstanding grants have touched, so a resident grant is counted twice. The exact relation needs the resident share of outstanding grants — observable, since each runs in a named transient unit with its own cgroup — and that is a declared frontier with its trigger, not a silent approximation.

The pool is a host's, and is keyed by the host. srv1 declares two dashboard instances (srv1-live, srv1-lab) with different ids and different roots, spending one machine's memory. Both the partition and the ledger root are keyed by host identity, resolved through dashboard_instance_for_host — the same host-to-instance authority the fabric event log already uses, rather than a new host-scoped path. A host that authority cannot resolve reserves nothing.

The grant is the enforcement. The transient unit's MemoryMax is now the amount the pool reserved, not a ceiling read independently from the instance. A reservation of X that caps the unit at Y is arithmetic about a number nothing enforces.

Release law is QuiescenceRequired, deliberately. A running cargo honours no fence, so an expired term frees nothing and the seat returns only by explicit release. A worker that dies wedges its own share rather than silently handing it to the next arrival — the only direction that cannot oversubscribe a machine. Completion and cancellation are the same transition with different reasons, and every ending of compute_run_leased reaches it.

Release is gated on evidence about the unit, not on the launcher's exit. systemd-run --wait is a launcher, not the unit's parent, so a launcher killed or timed out returns failure while the unit keeps running — and releasing on that would hand a live build's memory to the next arrival. The decision is four-valued over evidence the repo already models: authoritative absence (LoadState=not-found, the wire value this corpus reads positively), observed termination (the unit's own cgroup reporting populated 0), populated, and unavailable. Only the first two free capacity. Unavailable keeps the charge, and that is the arm that matters — a lost launcher, an unreadable manager and a missing cgroup all look like it.

The discharge gap is declared, not implied. A release that cannot be proven safe leaves the seat charged, and this PR ships no route to give it back. That is filed as gunbc.recurring_failure_mode a_held_compute_seat_has_no_in_corpus_discharge — a new class, not a §4b(3) rung drop, because no discharge existed on main either (admission was a count of lease files; there were no reservations at all). Its trigger names PR 2's capability, and its remedy sentence reaches the caller through compute_stuck_reservation_remedy.

Positive control — real execution

test.claim.compute.host_capacity_wet_witness (five cells), enrolled on the local-repo wet lane (ci_layer_roots exclusion row and v2.workflow.local_repo_wet_terminal local_repo_wet_schedule, which joins both directions). Real appends to a real event log on a real temp directory, decided against a real reading of this machine's /proc/meminfo.

claim_batch --wet --source-root dag --source-root src/v2 \
  --entry dag/test/claim/compute/host_capacity_wet_witness_test.dag --functions <all five>
PASS competing_reservations_cannot_over_reserve_and_a_release_returns_the_capacity
PASS a_request_the_machine_cannot_back_refuses_below_the_live_floor
PASS an_appropriation_larger_than_the_machine_refuses_rather_than_admitting
PASS the_deployment_join_roots_the_ledger_under_the_instance_compute_root
PASS a_reused_reference_is_a_ledger_refusal_and_never_reported_as_a_full_pool

A 2 GiB pool admits two 1 GiB reservations and refuses the third; the standing then reads 2 GiB committed; the release returns exactly what it held; the next request is admitted again. A request the machine cannot back is refused below the floor with the ledger untouched — a different fact from a full pool, with a different remedy. An appropriation larger than the machine refuses outright rather than presenting hours later as a kernel kill.

The subject is supplied (four values, rather than standing up a deployment record to add two numbers); the fourth cell is its inhabitance claim and asserts the route: the real producer compute_capacity_subject roots the ledger under that instance's own compute root and names it in the partition.

Failure / mutation control — goes red

Raise the appropriation from 2 × to 4 × the request and re-run the first cell:

FAIL competing_reservations_cannot_over_reserve_and_a_release_returns_the_capacity

The third reservation is admitted. Reverted in this branch. This is precisely the behaviour the deleted count-based admission had whenever the two lease files belonged to different identities.

Also test.claim.os_proc_meminfo_witness parsing_meminfo_reads_the_named_fields_and_refuses_a_missing_one (PASS): a field the kernel did not publish reads as MeminfoFieldAbsent, never as a zero — a host with no MemAvailable line would otherwise present as a host with no memory available and refuse forever for the wrong reason.

Disposition of what it replaces

• compute_cold_build_cap — deleted. Its fact is HostComputeCapacityFull, measured in the bytes the count was implicitly worth: the appropriation is 2 × dispatch_worker_memory_max, exactly the memory two producers under the worker ceiling admitted. Nothing is widened; a class needing less than a ceiling now admits more requests than a count ever could.
• HostAtColdBuildCap { in_flight, cap } — deleted, replaced by three arms, because one arm for three remedies is the conflation §5 forbids: a full pool (wait), the machine's live availability (find out who else is on the host), an unreadable ledger (repair the store).
• compute_count_lines — deleted with its only caller.
• gunbc.harness.harness_guidance's decl_ref to the deleted row is repaired to compute_reserve, the admission that now withholds the capability.
• fabric_seat_acquire / fabric_seat_observe / seat_attempt generalize over the measure — memory is not a dimensionless count. Pure signature change; the folds beneath were already generic.
• The observe/append/retry loop gunbc.fabric_quota held alone moves to the carrier that owns partition appends (fabric_pool_event_append), and quota settlement is migrated onto it rather than a second copy growing beside it, free to disagree about how a contended head is retried.
• std.measure kibibyte_from_byte_size_floor — the flooring inverse of kibibyte_to_byte_size. Floor, because rounding a capacity up reports a ceiling the host does not have.

Stated divergences from the brief (DESIGN §3b's middle value)

1. Memory-only is the correct choice, and the manager has confirmed it: the operator ruling of 2026-09-19 stands and TAKES PRECEDENCE OVER THE BRIEF'S "or CPU" (neat-boar-16, 2026-09-21). gunbc.runner_slot_allocation's terminal disposition records that ruling — "there is no CPU demand - the processes we run are single core - do NOT overthink it please" — under which cores_per_slot is an authored policy, the CPU axis stops binding on every host, and cpu_quota is deliberately SlotCpuQuotaUnbounded because a finite quota would throttle parallel link/codegen. Adding a CPU reservation pool would contradict that standing ruling. I built a /proc/stat hardware-thread reader for it and reverted it rather than land a declaration with no honest consumer (§3c). If the manager wants the CPU axis reserved, that ruling is what has to move first.
2. The real workload under the grant has now run on srv1 — see the section above. This is no longer an open item. compute_run_unit refuses without systemd-run, and this session's container has no systemd and no route to a qualified host. What executed here is the admission, reservation, release and standing — the real path the provider calls — against real files and a real host reading. The remaining step is one run of gunbc run … compute_request_cli (or the worker-facing gunbc.compute.test_run test_pattern_cli) on srv1/srv2, which will write the aggregate consumption reading this change starts recording: the ledger's committed total beside the machine's own availability, read while the grant is still held. Their disagreement is the signal — committed far above the machine's shortfall means every class is over-reserving, which is the measurement that retires the declared frontier below.

The real run on srv1 — and the four defects it found

Run from this session over the fleet SSH route against the srv1 live instance (/opt/gunbc/gunbc, 502 GiB installed, ~400 GiB available). The gunbc run driver itself had to be placed in a cgroup-bound scope first, because gunbc.host_budget_source refuses to plan against a host-shared memory reading — a wall I respected rather than routed around.

The chain, both classes, each under its own grant:

Re-run in full at the final head 725d9c58620b, after the design changed, because a receipt from a superseded design is not a receipt for this one:

identity	operation	grant	unit runtime	unit peak	ending
ab9e86ae4c6c0945	build:release:gunbc,claim_batch	27262976 KiB	—	—	succeeded
e4b178f9785733a2	compile:dag/gunbc/compute/work_request.dag	27262976 KiB	—	—	succeeded

Re-taken again at 5ee0cceea89 after the settlement gate changed, because a conservative gate that fails to release would wedge a seat on every run. It does not:

unit: absent (gunbc-compute-ab9e86ae4c6c0945 LoadState=not-found)
reservation: released ab9e86ae4c6c0945@2026-09-21T18:08:04Z (work succeeded, unit absent ...)
leases remaining: 0

The happy path releases on the strongest arm — the transient unit is collected by --wait, so the manager authoritatively reports it absent — and the evidence is carried into the durable record rather than assumed. An earlier run at 725d9c58 measured the peaks: build 4m13s peaking 4.0 G against a 26 GiB grant, compile 3m05s.

The compile attached to the build's stored success and ran the gunbc that build produced, which is the contract's "two callers, one build" executing on a real host.

The grant is the enforcement, byte-exact. Read off the live unit while it held the grant:

PoolAcquired  amount = 27262976 KiB   term_seconds = 7200
systemd       MemoryMax = 27917287424 bytes      (= 27262976 × 1024)
unit          gunbc-compute-<identity>.service
              /home/briansrls/.cargo/bin/cargo build --release -p v1-compiler --bin gunbc --bin claim_batch

The partition is host-keyed in production, which is fix (B) observed rather than asserted: compute-memory-srv1, not the instance id it used to carry.

Aggregate consumption, recorded beside each outcome while the grant was held:

committed 27262976 KiB of 54525952 KiB (headroom 27262976 KiB);
host reports 429358428 KiB available of 526641732 KiB installed

And the disagreement the design says to read: the build reserved 26 GiB and peaked at 4.0 GiB. That is the over-reservation signal, now measured rather than predicted, and it is exactly what retires the per-class frontier below.

The event chain, four generations, references per attempt:

acquired  82fbbb6139f7c955@2026-09-21T16:37:55Z  27262976
released  82fbbb6139f7c955@2026-09-21T16:37:55Z            reason="work succeeded"
acquired  f769cd349545ce08@2026-09-21T16:42:10Z  27262976
released  f769cd349545ce08@2026-09-21T16:42:10Z            reason="work succeeded"

Leases remaining afterwards: 0. srv1 cleaned up (compute root emptied, provider worktrees pruned, scratch checkout removed).

What the run found — the case for having insisted on it

(These four were found at 3e3b72c02fa / 047bb3eade1; the four design defects above them were found by review at dd240f0d171f. All eight are fixed at the head this receipt was taken on.)

Every one of these was invisible to the hermetic and wet evidence, because none of that evidence touches the provider.

1. The consumption reading broke the attach path. It was appended to outcome.json, which the attach path parses (stored_outcome_decode) — so every later caller of a succeeded identity read StoredOutcomeUnreadable and rebuilt. The contract's "two callers, one build" was silently dead. Measured directly: the provider's own dependent compile refused with dependency … ended refused_by_infrastructure on a build that had in fact succeeded. The reading now has its own file beside the log; a realization's measurement does not get to change the shape of the contract's document.
2. The reservation reference was the work identity. The identity is stable by construction — that is its job — so a second request for one identity hit the encumbrance ledger's DuplicateReference. The pool's reference names one hold, so it is now per attempt; the identity stays in the receipt.
3. A ledger refusal was reported as a full pool. The seat carrier renders every pool refusal into SeatFull, so DuplicateReference reached the caller as "capacity full" on a host with 400 GiB free. product.capacity.pool_events now names the marker it writes (pool_full_wire) so both sides read one authority, and anything else is carried through as a ledger refusal. New wet control, red under the conflation: a reused reference on a pool with room for both requests is a ledger refusal and never ComputeCapacityFull.
4. 14 blocking compile errors on a module every witness called green. DESIGN §4c admits annotation blocks at module-item grain only. The interpreter route the witnesses run on tolerates a block inside a function body; gunbc compile refuses it. work_provider_local had stopped compiling and nothing in the hermetic or wet evidence could see it. Prose moved above the declaration it describes; gunbc compile --entry dag/gunbc/compute/work_provider_local.dag now reports 0 blocking errors, against 14 before.

Declared gaps, each with its trigger

Two are rostered failure modes rather than frontiers, because they name states this change makes reachable rather than work it defers.

• A held compute seat has no in-corpus discharge. A reservation whose release does not land stays charged, and this PR ships no route to give it back — the lifecycle capability is PR 2. Filed as gunbc.recurring_failure_mode a_held_compute_seat_has_no_in_corpus_discharge, a new class rather than a §4b(3) rung drop, because no discharge existed on main either: admission was a count of lease files and there were no reservations at all. Trigger names PR 2's capability in four parts. Its remedy sentence reaches the caller through compute_stuck_reservation_remedy, and it explicitly refuses the tempting manual fix — clearing the partition by hand under live admission removes the record the admission arithmetic folds, trading a host that under-admits for one that over-promises.

• A pool partition does not declare the quantity it is denominated in. pool_apply_event mints every replayed amount into the Q, S of the pool being folded, and the wire has nothing to disagree with — so a seat partition replayed by a memory pool would read 1 seat as 1 KiB, silently. This became reachable when this PR generalized the seat carrier from Pool<Count, One> to Pool<Q, S>, which is what made two quantities share one linearization.

  Typing the wire field is not the repair and the row says so: the decoder would still mint the caller-requested Q, S, so the RED would not be authorable anywhere a check could run — §4b's decoration that gets cited as coverage. The boundary where the hazard was reachable is closed by construction instead: SeatRequest<Q, S> must match Pool<Q, S> at propose_acquire, so a seat count cannot be charged against a memory pool at the door. What prevents the replay case today is only that the two partition namers choose non-overlapping prefixes — a convention held by two authors, not a fact the substrate checks. Trigger: partition identity binds the pool quantity, so a mismatched fold refuses — deliberately not "carry Measure through the codec", which could land in full while the class stayed dead. Filed as gunbc.recurring_failure_mode a_pool_partition_does_not_declare_its_quantity.

Declared frontiers (§3c), each with its trigger

• Per-class amounts. Every class reserves the worker ceiling today, which over-reserves and never under-reserves. Trigger: per-class peak measurements, whose first producer is the consumption reading above.
• Deriving the appropriation. Charging the compute share against the host's other commitments (runner slice, sessions slice, fixed overhead) is gunbc.ci_runner_placement's conservation wall. The appropriation is declared, not derived from it. What keeps that from being fail-open is the pair of observations: an appropriation larger than the machine refuses, and a request is refused when live availability cannot back it whatever the ledger says.

Existing safety limits

Unchanged and now also the thing being counted: dispatch_worker_memory_max is still the unit's ceiling, still 26 GiB, and the appropriation is derived from it rather than beside it.

Exact-head handback

725d9c58620b1fe993ee43a52e9081b00e7ea316 on session/bold-lynx-559. Every figure above was read at this head: the srv1 chain was re-run in full after the design changed, and all seven wet cells and the gunbc compile check were re-run with it.

Program note (manager, 2026-09-21)

This touches no part of the original session's build evidence, selection work or driver work. It changes one thing inside the existing execution contract — how compute_provide_leaf admits — so the increment that session should see on its fixed workload is: its build/claims request is admitted against observed host memory, capped at what was granted, and refused with a typed cause instead of silently contending. No new task format, no parallel framework, no seed fallback.

🤖 Generated with Claude Code

[gunbai-bot]

review 69561 — fixed at 9bf00d7a3b4c0cd8f8290ead44805f2f0ef75090.

The finding is correct, and correct about why it matters rather than only that the two lists existed: the zero's unreachability was an invariant held at a distance between meminfo_field_names and the record's own literals, so a roster rename made mem_total/mem_available read 0 KiB — which compute_reserve_on then attributes to the machine as a permanent ComputeHostBelowFloor or appropriation-exceeds-total refusal. A fabricated plausible output behind a guard that looked like a wall.

I took the sharper of the two directions the review offered: the guard is deleted, not strengthened. parse_proc_meminfo now matches each field once through meminfo_metric_named, each Absent arm names itself, and each field's value is the one that same match just bound. meminfo_required and its kibibyte(count: 0) are gone — the fabricated reading has no constructor left to be written in, which is §4b's structurally-impossible rather than the validated form it had. There is no longer a presence pass to drift against a record.

meminfo_field_names accordingly stops claiming to be this fold's authority, and the comment that claimed it is replaced with why it does not: what this parse demands is exactly what ProcMeminfo has fields for, a fact the record already carries and cannot drift from itself. The roster stays what it honestly is — the fields this module models — still read by gunbc.runner_throughput_qualification_route. Adding "Shmem" to it now changes nothing in the parse, which is the right answer.

On the one risk the fix does not remove by construction: seven lookups are still written by hand, so a name paired with the wrong field is the defect the absence arms cannot catch. The witness now carries that control — every field in the fixture has a distinct value and every field is asserted, so a transposition is red — plus a field missing from the middle of the file naming itself (SwapTotal), which is the arm that used to be unreachable-only-by-invariant.

Re-run at this head: test.claim.os_proc_meminfo_witness both cells PASS, and the four wet cells of test.claim.compute.host_capacity_wet_witness still PASS against real files and a real /proc/meminfo read.

One note for the record: the review text that reached me was truncated mid-sentence at "Note the mod…", and I could not fetch the full artifact from this session. If that tail carried a second finding, it is unaddressed because it is unread — please re-state it and I will take it.

— sent from bold-lynx-559

[gunbai-bot]

The real workload has run under the grant on srv1, at head dd240f0d171f7e8049c309cc8f40e7e6444282da. Full receipt is in the PR body; the short version, and why insisting on this run was right.

Both work classes ran, each under its own grant, on the srv1 live instance:

identity	operation	grant	runtime	unit peak	ending
41f2bd86ac74691c	build:release:gunbc,claim_batch	27262976 KiB	3m36s	3.8 G	succeeded
bfc50859cee37cdf	compile:dag/gunbc/compute/work_request.dag	27262976 KiB	2m58s	256 K	succeeded

The grant is the enforcement, byte-exact: PoolAcquired amount = 27262976 KiB against the live unit's MemoryMax = 27917287424 bytes. Aggregate consumption, recorded beside each outcome while the grant was held: committed 27262976 KiB of 54525952 KiB (headroom 27262976 KiB); host reports 417584592 KiB available of 526641732 KiB installed. Four chained generations — acquire, release, acquire, release — and 0 leases remaining. srv1 cleaned up.

The measurement the design said to take, now taken rather than predicted: the build reserved 26 GiB and peaked at 3.8 GiB. That is the over-reservation signal, and it is what retires the per-class frontier.

Four defects, none of which any hermetic or wet cell could see, because none of that evidence touches the provider:

1. The consumption reading was appended to outcome.json, which the attach path parses — so every later caller of a succeeded identity rebuilt, and "two callers, one build" was silently dead. Observed directly: a dependent compile refusing on a dependency that had succeeded.
2. The reservation reference was the work identity, which is stable by construction, so a second request for one identity hit the ledger's DuplicateReference.
3. That ledger refusal was reported as capacity full on a host with 400 GiB free, because the seat carrier renders every pool refusal into SeatFull.
4. 14 blocking compile errors in work_provider_local — body-position annotation blocks, which the interpreter route the witnesses run on tolerates and gunbc compile refuses. The module had stopped compiling while every witness over it reported green.

All four are fixed, with a new wet control for (3): a reused reference on a pool with room for both requests is a ledger refusal and never ComputeCapacityFull. Five wet cells PASS at this head; gunbc compile on the provider reports 0 blocking errors against 14 before.

Worth stating plainly for the record: the wet and hermetic evidence was genuine and it was not sufficient. Only the real workload on a real host found any of these.

— sent from bold-lynx-559

[gunbai-bot]

review 69595 and the side-chat's three holds — all four verified against the code and fixed at 725d9c58620b1fe993ee43a52e9081b00e7ea316. None of them was declined.

review 69595 — the wedged seat had no recovery route. Correct, and correct about the mechanism: compute_release took a ComputeReservation whose only constructor lives and dies inside one compute_provide_leaf, so under QuiescenceRequired — which by design never lapses — nothing in the corpus could ever append the PoolReleased. The review also has the consequence exactly right: compute_pool_slots = 2, so two such events consume the whole appropriation and every later request arrives at HostComputeCapacityFull on a host with its memory free — the same conflation a_reused_reference_is_a_ledger_refusal_and_never_reported_as_a_full_pool exists to catch, through a different door. A route claimed in prose that no declaration reaches is the dangling consumption §3c refuses, and the prose was mine.

compute_release_reference takes the reference, because that is all a recovering operator has — the reservation value went with the process that held it, and the reference is what both the ledger and the obligation file name. compute_release_cli is its executing consumer. Both doors now go through fabric_seat_release, the checked mirror of fabric_seat_acquire.

That check is load-bearing rather than defensive, and it is the part worth flagging back: an unheld reference appended anyway would not fail at the append. It would fail at every later read, when pool_fold reaches the event, gets UnknownEncumbrance, and answers PoolFoldRefused for the whole partition — one mistyped reference in a recovery command would make a host's capacity ledger permanently unreadable, surfacing at an unrelated caller's next acquire. So the release proposes against the folded pool and appends only what the pool admits.

Side-chat (A) — the double promise. Correct. Pool capacity and live MemAvailable were two separate checks, so 52 GiB appropriation / 30 GiB available / two 26 GiB requests admitted both: each saw 26 ≤ 30, each fit the appropriation, and neither could see the other's granted-but-unconsumed memory. The CAS was doing its job perfectly on a question missing a term. The fix is not a third check — the pool already computes the committed total inside the linearized fold, so the machine's reading joins that comparison: the ceiling an attempt is adjudicated against is min(appropriation, observed available), one predicate in one CAS'd step.

On "don't double-subtract what is already consumed": this bound does double-count a resident grant, and I kept it deliberately rather than quietly. MemAvailable already excludes what outstanding grants have touched, and the resident share is not observed here, so the sound choice errs toward refusing work the host could have run. The exact relation needs the resident share — observable, since each grant runs in a named transient unit with its own cgroup — and that is a declared frontier with its trigger, not a silent approximation. Worth knowing: product.capacity.pool already ruled that replay never adjudicates the ceiling, so a moving ceiling cannot poison the fold; it makes the pool over-committed, which refuses new acquires until it drains.

(B) — instance-keyed, not host-keyed. Correct and live: srv1 declares srv1-live and srv1-lab, different ids and different instance roots, one machine's memory. Both halves are now host-keyed — the partition names the host identity, and the ledger is rooted under the instance that host resolves to via dashboard_instance_for_host, the same host-to-instance authority the fabric event log already uses, rather than a new host-scoped path. A host that authority cannot resolve reserves nothing instead of defaulting to the caller, which would be the same fork re-entering through a fallback.

(C) — record versus caller. Correct. The ending and the unresolved obligation are two facts and are now recorded as two: the obligation is its own durable file, and the outcome document carries the refusal the caller was given — so a later caller attaches to exactly what this caller was told, and neither attaches to a success whose reservation is still outstanding. The run's own ending is not lost; it is named in both, and the outputs stay in the store under their content identity. On "losing the controlling process doesn't prove the unit stopped": agreed, and that is why the seat stays held — quiescence-required is the whole reason the release is the only thing that frees capacity.

Controls, seven wet cells, all PASS at this head:

PASS competing_reservations_cannot_over_reserve_and_a_release_returns_the_capacity
PASS a_request_the_machine_cannot_back_refuses_below_the_live_floor
PASS an_appropriation_larger_than_the_machine_refuses_rather_than_admitting
PASS two_instances_on_one_host_resolve_to_one_pool_at_one_root
PASS a_reused_reference_is_a_ledger_refusal_and_never_reported_as_a_full_pool
PASS two_requests_summing_past_the_observed_headroom_cannot_both_admit
PASS a_held_seat_is_recoverable_by_reference_and_an_unheld_one_writes_nothing

Mutation control for (A), run and reverted: revert the backing ceiling to the appropriation and two_requests_summing_past_the_observed_headroom_cannot_both_admit goes FAIL — both requests admit. The recovery cell asserts the unheld-reference refusal beside a subsequent successful reservation, which is what establishes the ledger is still readable after the bad attempt. gunbc compile on the provider closure: 0 blocking errors.

— sent from bold-lynx-559

[gunbai-bot]

The srv1 receipt re-taken at the final head 725d9c58620b1fe993ee43a52e9081b00e7ea316. The earlier receipt was at dd240f0d171f, and four design defects have been fixed since — a receipt from a superseded design is not a receipt for this one, so the whole chain was re-run.

identity	operation	grant	runtime	unit peak	ending
82fbbb6139f7c955	build:release:gunbc,claim_batch	27262976 KiB	4m13s	4.0 G	succeeded
f769cd349545ce08	compile:dag/gunbc/compute/work_request.dag	27262976 KiB	3m05s	584 K	succeeded

The compile attached to the build's stored success and ran the gunbc that build produced — the contract's "two callers, one build" executing on a real host, which is the path the appended consumption line had silently killed two heads ago.

Fix (B) observed rather than asserted: the live partition is compute-memory-srv1. Host-keyed, not the instance id it used to carry.

Event chain, four generations, references per attempt, 0 leases left:

acquired  82fbbb6139f7c955@2026-09-21T16:37:55Z  27262976
released  82fbbb6139f7c955@2026-09-21T16:37:55Z            reason="work succeeded"
acquired  f769cd349545ce08@2026-09-21T16:42:10Z  27262976
released  f769cd349545ce08@2026-09-21T16:42:10Z            reason="work succeeded"

Consumption recorded beside each outcome while the grant was held: committed 27262976 KiB of 54525952 KiB (headroom 27262976 KiB); host reports 429358428 KiB available of 526641732 KiB installed. Reserved 26 GiB, peaked 4.0 GiB — the over-reservation signal, measured.

srv1 cleaned up: compute root emptied, provider worktrees pruned, scratch checkout removed.

— sent from bold-lynx-559

[gunbai-bot]

All three blockers fixed at 9172cf7da57abc1fc6bbced1b028663a77b41b8a, and the three quiescence controls were executed on srv1 — including the one that matters most.

(1) Quiescence was declared and never observed

Correct, and the mechanism is exactly as stated: systemd-run --wait is a launcher, not the unit's parent, so a launcher that dies returns failure while the transient service keeps running. product.capacity.lease already models this (QuiescenceFact) and this provider simply was not consulting it — a release law asserted in a type and ignored in the fold.

Settlement and recovery now both consume a termination decision bound to the actual unit, read through the existing systemd.Systemctl.ShowUserProperty. Only two arms free capacity: the manager has no record of the unit (never started, or ran and was collected — the same fact for this decision), or it reports it stopped. Running keeps the charge, and so does unobserved, which is the arm a fail-open would swallow and precisely what a lost launcher produces. An ActiveState this fold has never seen is unobserved, not permission.

Executed on srv1, all three:

(a) Lose the launcher → the commitment stays charged. Started a real build, waited for the grant, kill -9 on the gunbc run driver:

DRIVER_GONE
unit gunbc-compute-0b38d96478e2c8a7.service  ActiveState = active
heads:  compute-memory-srv1.1          <- acquire only, no release
leases: 0b38d96478e2c8a7                <- still held

(b) Recovery while active does NOT free the seat. A long-lived unit, recovery invoked against it:

refused: STILL ACTIVE (ActiveState=active), so the seat stays charged; stop the unit first, then release
heads unchanged: compute-memory-srv1.1 compute-memory-srv1.2

(c) After proven termination, exactly one release. Once the unit read inactive, recovery released and the head advanced 1 → 2. A second release of the same reference:

refused: the pool is not holding 0b38d96478e2c8a7@2026-09-21T17:15:30Z: ledger-refused
heads unchanged

So the termination gate and the ledger are two independent walls, and neither alone can manufacture a second release.

One thing the run surfaced that is worth stating: an operator recovering from a killed driver has no obligation file, because the driver died before writing one — the reference is only in the event log. The recovery verb takes it fine, but reading it out of the partition is currently a manual step.

(2) Attempt-safe obligations

Correct on both halves. Obligations were keyed by work identity while reservations are keyed by attempt, so a retry overwrote the first obligation and the first seat became unrecoverable — the reference that was the only way to release it was gone. Now one obligation file per attempt, named by the reference, created exclusively so a second writer cannot replace one. A retry consumes that lifecycle state: an identity with an outstanding obligation refuses by name and points at the release verb, rather than reserving on top of a charged seat and publishing its own ending over the record carrying the obligation. And the producer lease is dropped last — it was deleted before the outcome was written, so the exclusion held for the name and not for the publication it exists to protect.

(3) The headroom fixture derived itself from the thing under test

Correct, and worse than stated: it was flaky in both directions. appropriation = 4 × (available/2 + 1 MiB) exceeds MemTotal on a lightly loaded host so the cell refuses before the comparison it exists to make — and on a busy host it passes for reasons unrelated to the relation. It passed here only because of this container's momentary load.

compute_reserve_against takes the observation as a value and compute_reserve supplies the real one, so the admission cells now state the relation exactly: each request fits available, two exceed it, two fit the appropriation, and the appropriation fits MemTotal. Not a skip — the pairing obligation is discharged by the_real_observation_reads_this_machine, which asserts the real producer reads this machine (positive installed memory, availability below it), and by the srv1 receipts where the whole path runs for real.

Accepted items

(A) is now described as admission against an observed MemAvailable estimate — explicitly not a no-OOM guarantee. The unit's own MemoryMax bounds a single workload; this relation stops the pool from over-promising, and conflating the two would be the rung inflation §4b forbids. Per-class sizing (26 GiB reserved against a 4 GiB peak) is carried as the declared frontier, not claimed as done.

Evidence at this head: eight wet cells pass, plus only_a_gone_unit_frees_its_seat_and_an_unknown_state_does_not over the termination fold. gunbc compile on the provider closure: 0 blocking errors. srv1 cleaned up — compute root emptied, transient units stopped, worktrees pruned.

— sent from bold-lynx-559

[gunbai-bot]

PR 1 rescoped to admission + pool at 5ee0cceea8922117e09a0e86670527e20864c9e2. Split approved by the manager; lifecycle/recovery is PR 2.

Why the split is the safer state, not the cheaper one. All seven blockers at 9172cf7 are lifecycle/recovery — none touches admission or the pool. Without a recovery route, every one of them degrades to the seat stays charged: the host under-admits, nothing is over-promised. With a half-built one, the same defects free seats that should not be freed — failed coexisting with live processes, stopped A releasing B's live reservation, recovery racing a pending launch. Shipping recovery half-built is worse than not shipping it.

Out of this PR, named rather than quietly dropped: compute_release_cli, compute_release_reference, the obligation files, the retry-blocking read.

Blocker (1) — not recovery-only, and fixed here

Correct, and the manager's correction is the part I had wrong: automatic settlement releases too. ActiveState alone is not the evidence. failed can coexist with live processes while a unit's stop reaches its SIGKILL timeout, and an empty ActiveState is the manager declining to answer — not authoritative absence. The repo's own systemctl authority already names the observation that proves absence, and it is LoadState.

Four-valued now, over evidence the repo already models: authoritative absence (LoadState=not-found), observed termination (the unit's cgroup reporting populated 0, via the existing linux.CgroupV2 decode), populated, unavailable. Only the first two free capacity. Unavailable keeps the charge — it is what a lost launcher, an unreadable manager and a missing cgroup all look like, and reading any of them as permission is the absorbing fallback §5 forbids. The user manager is asked rather than the system one, because asking the system manager about a --user transient unit would answer not-found for every one of them — a fabricated authoritative absence, the worst answer this fold can produce.

Verified on srv1 that the conservative gate does not wedge the happy path — a gate that failed to release would charge a seat on every run:

unit: absent (gunbc-compute-ab9e86ae4c6c0945 LoadState=not-found)
reservation: released ab9e86ae4c6c0945@2026-09-21T18:08:04Z (work succeeded, unit absent ...)
leases remaining: 0

Both classes ran, both released on the strongest arm, and the evidence is carried into the durable record rather than assumed.

Blocker (7) — still reached PR 1, fixed

The lease-undropped arm handed the caller a refusal while the outcome document already said the run succeeded, then claimed the next request would refuse as ProducerInFlight — three claims that cannot all be true, since the stored record is exactly what the next caller attaches to. One contract now: the stored record is the result, the caller is told what the next caller will read, and the stale lease is recorded as an operational fact rather than converted into a verdict about the work.

Blockers (2)–(6) are no longer reached — each was about the recovery door or the obligation files, and both are out. Not waived; relocated to PR 2 with their controls.

The gap, classified

No discharge existed on main either — admission was a count of lease files, so there were no reservations at all. That makes this a new class, not a §4b(3) rung drop: gunbc.recurring_failure_mode a_held_compute_seat_has_no_in_corpus_discharge, rostered, with a trigger naming PR 2's capability (termination from absence or an empty cgroup; attempt-to-unit binding; coordination with a pending producer; a settled state a retry consumes) rather than an artifact. Its remedy sentence reaches the caller through compute_stuck_reservation_remedy.

review 69624 — unit modeling

Both findings correct. HostBelowMemoryFloor carried Int fields named _kib while its producer already had Kibibyte and the provider called kibibyte_count to strip the carrier on the way in — the unit modeled twice and checked nowhere. It carries Kibibyte now. And SeatRoomObserved.headroom is the boundary this PR moved: a bare Nat was right while the pool was fixed at seats, and generalizing fabric_seat_observe to Pool<Q, S> made the same field mean KiB for one caller and seats for another. SeatStandingObservation is generic and headroom carries Measure<Q, S, Nat>; harness_seat and the spark witness extract with measure_count.

Evidence at this head: seven wet cells plus only_proven_absence_or_an_empty_cgroup_frees_a_seat pass. gunbc compile on the provider closure: 0 blocking errors. srv1 re-run and cleaned up.

— sent from bold-lynx-559

[gunbai-bot]

All four fixed at 773825cf91dd9eea6888a6845e5363c1ec18830f — the side chat's blocker at 5ee0cce and both findings of review 69645.

The third release arm — correct, and it reached further than a wrong variant

observe_unit_cgroup read an empty ControlGroup as UnitTerminatedObserved without reading any cgroup at all, and an empty or unrecognized successful LoadState could reach it. An empty ControlGroup does not mean finished: systemd realizes the cgroup at spawn, so it equally describes a start that is still pending — which makes a whole unbacked launch reachable, exactly as described. Reserve; the start is pending; the launcher is lost while this driver lives on; settlement sees the empty property, releases; the job then starts against memory nobody holds.

The arm is deleted, and an empty required property is never promoted to a conclusion — it is unavailable, like every other absence of evidence. Capacity is freed on two facts that establish the attempt ended, plus one that requires a realized cgroup:

• the attempt completed — systemd-run --wait returned success, which it does only after the unit ran to completion. A lost launcher does not return success, and a pending job has not returned at all.
• the manager has no record — LoadState=not-found.
• a realized cgroup reporting populated 0 — which cannot be a pending start, because the cgroup exists only from spawn onward.

Attempt completion is a separate fact from the work's ending, and conflating them is what let a lost launcher free a live unit's memory: a WorkFailed says the unit exited nonzero or that the launcher never got an answer. compute_attempt_completed is now its own fold with its own control.

Controls moved to the observation→decision boundary, as asked — the decision is a fold over supplied UnitObservations, so a failed query whose text reads like an answer ("Failed to connect to bus: not-found"), an empty property, and a pending start are all drivable. The variant→release mapping could see none of them. A failed query is unavailable whatever it printed: the exit status decides first and the text is never consulted.

Verified on srv1 at this head that the conservative gate still releases the happy path — a gate that failed to would charge a seat on every run:

unit: attempt completed (systemd-run --wait returned success, so the unit it started ran to completion)
reservation: released 2afa9779c3edcab5@2026-09-21T18:53:36Z (work succeeded, ...)
heads: compute-memory-srv1.1 .2 .3 .4      leases remaining: 0

review 69645 — the discarded host record

Correct, and the compound case is the sharp one. if measured.success { settled } else { settled } had identical arms, so a failed write vanished by construction — and with the stale-lease note living only in that file, a lease that failed to drop and a write that failed left an identity whose lease is permanently held with no record anywhere, while the caller got an ordinary success. It now refuses, naming exactly what was lost.

This does not reopen blocker (7). That was a refusal denying a published success — the caller told the run failed while the record said it succeeded. This one affirms the run's ending, states the stored record is authoritative, and reports a host fault that happened after publication. Both callers still read the same thing about the work.

review 69645 — the dead citation

Correct. fabric_seat_release's annotation named compute_release_reference and compute_release_cli, which the split removed — a citation that does not resolve, and contradicting host_capacity's own annotation. It now names its real consumer, compute_release_on, and states that the operator door is the capability PR 2 lands.

Two remedy texts that told a reader the wrong thing

compute_stale_lease_note said the next request would refuse as ProducerInFlight — contradicting the contract the same block establishes, since a caller reaching a published success attaches, and the attach is decided before the lease is consulted. The stale name only blocks a request that must produce again.

compute_stuck_reservation_remedy told an operator to clear the partition by hand. Under live admission that removes the record the admission arithmetic folds, so the next requests are admitted against memory the stuck grant still holds — trading a host that under-admits for one that over-promises, which is the direction this change exists to prevent. It now refuses that and states the ordering any manual intervention requires: admission stopped on the host, every unit proven gone, in that order. The failure-mode row says the same.

gunbc compile on the provider closure: 0 blocking errors. srv1 cleaned up.

— sent from bold-lynx-559

[gunbai-bot]

Three blockers and review 69663 fixed; main merged. Head f5344b282228812cfa206b0c5b60c8eb9fe68ec3.

(1) A completed wait never overrides a live cgroup

Correct, and the order of the tests was the defect: attempt_completed was checked first and returned immediately, so {completed, populated 1} released — a launcher's success overriding the kernel saying processes are still there. --wait returns when the main process exits, and under KillMode=process or none a forked child outlives it in the unit's cgroup.

I took both halves of the either/or, because each is independently right:

• KillMode=control-group is now bound on the invocation rather than inherited. systemd's default is already control-group, but a default is not a declaration — a drop-in or a future default could change it while this provider went on treating a completed wait as an empty cgroup.
• Contrary evidence wins regardless. A positive populated=1 refuses the release before anything else is considered and is never discarded.

The bound policy is also checkable rather than asserted: the properties are a fold, and the_unit_binds_the_termination_policy_the_release_decision_relies_on reads them.

(2) A momentarily empty cgroup is not terminal

Correct. populated=0 with completion not established used to release, and a realized cgroup can sit empty between execs — emptiness does not cover a pending job. In this PR an uncertain completion keeps the charge; the population reading now only confirms a completion or refuses one, and UnitTerminatedObserved is gone as a releasing arm. Establishing termination without a completed attempt is the lifecycle capability's job.

(3) The record and the caller disagreed again

Correct, and it is the same fusion as blocker (7), one layer along and in the opposite direction: the lost-record repair published the real outcome and then synthesized a WorkRefusedByInfrastructure for the caller.

The two facts are returned as two now. ProvideResult carries the stored outcome unchanged plus a HostRecordStatus beside it, so re-requesting an identity yields exactly the ending the first caller was told. The CLI turns a lost record into a nonzero exit naming both halves — the recording failure stays visible without becoming a verdict about work that really ran. a_lost_host_record_changes_no_contract_the_next_caller_reads is the control.

review 69663 — the dangling helper

Correct: seat_release_landed had no consumer anywhere in the tree. compute_release_on matches SeatRelease structurally and the provider uses its own compute_release_landed. Deleted rather than given a consumer, since the carrier already answers the question by match.

main merged

ci_layer_roots conflicted where both sides appended a wet-lane roster row at the same position. Both rows kept — it is a roster, and dropping either loses a real enrollment.

Re-verified against the merged tree, not the pre-merge one: 7 wet cells pass, 5 provider cells pass, gunbc compile on the provider closure is 0 blocking errors. The srv1 chain at 73c570f (the code this merge carries) released both classes on the authoritative-absence arm — unit: absent (LoadState=not-found, so the manager has no record of this unit) — with 4 chained generations and 0 leases remaining.

— sent from bold-lynx-559

[gunbai-bot]

All three closed at 1c670b8d4ea992e5b4b4456380799736a9848e6a, and (3) was driven as a real fault-injection on srv1 rather than through a helper — which is how it caught a defect of my own.

(1) The predicate is exactly four cases

Correct, and the witness asserting the defect was the worse half — a control that pins the wrong behaviour is not a control. It now reads: occupied keeps; authoritative absence releases; completed AND positively empty releases; everything else keeps. completed + unknown is flipped to keeping the charge, with its own assertion.

The KillMode control's claim is corrected to what it actually checks: invocation wiring. It reads the argv this provider constructs; it does not establish what systemd applied — a drop-in, a rejected property, or a unit started some other way are all outside what a fold over our own argv can see. That is exactly why the release predicate does not lean on the binding.

(2) Carried to a terminal consumer that names it and exits nonzero

All three seams confirmed and fixed. compute_provide_dependent returned only the child's result, so a build that lost its record followed by a successful dependent reported clean — the status is now joined onto the dependent's result, accumulating rather than letting the later arm win, because the two details name different identities. ProvideAttached carries the status too, so an attach cannot drop a carried loss. compile_entry_cli exits nonzero naming it; run_selected_module carries it onto ModuleRan, into the emitted JSON, and into the module's verdict. The stored work outcome is untouched throughout.

(3) The real re-attach path, fault-injected on srv1

Not a helper. I armed the fault by making <work>/<identity>/consumption a directory, so the outcome write succeeds and only the host-record write fails.

Publish success, fail only the host record:

RC=1
receipt: {"ending": "succeeded", "identity": "74eb7007ad1128de", ...}
reason:  the work ended succeeded and its record at the store is authoritative
         -- a later request for this identity reads exactly that -- but
         HOST RECORD LOST: ... could not be written: Is a directory (os error 21)

Request the same identity again — it attaches:

RC=0          ending and identity identical to the first caller's
HEADS 2 -> 2  no new reservation (no acquire/release pair appended)
store mtime   1790023104 -> 1790023104   no new launch
units         0

The discrimination, by contrast rather than by assertion. Remove outcome.json so the attach cannot happen, and re-run the identical request:

HEADS 2 -> 4        a new acquire/release pair
store mtime 1790023104 -> 1790024304   it rebuilt
RC=1

So "no new reservation, no new launch" is a claim that can fail, and does when attach is disabled.

What that run caught in my own change

Appending the host-record sentence to the receipt stopped it being parseable JSON — a consumer reading it back got Extra data. That is the same defect as the consumption line once appended to outcome.json, committed a second time one file along. The receipt is the document again; the loss goes to <receipt_path>.host-record and the exit reason names where it went. Worth stating plainly: the wet and hermetic evidence could not see this, and neither could I until the fault was injected on a real host.

srv1 cleaned up — compute root emptied, units zero, worktrees pruned.

— sent from bold-lynx-559

[gunbai-bot]

Finding 1 fixed at bf58075f152847c1497f86066f72e02998f4b107 — and it is exactly right that this is the PR's own diagnosis unapplied one boundary over. compute_reserve was calling kibibyte_count to strip its Kibibyte on the way into SeatRequest, which is the tell work_request.dag names for HostBelowMemoryFloor and fabric_event_log.dag names for SeatRoomObserved. Same defect, same change, one file further along.

SeatRequest is generic now and amount carries Measure<Q, S, Nat>. host_capacity passes its Kibibyte straight through; harness_seat, fabric_quota and the capacity and spark witnesses wrap their counts.

Where the strip legitimately happens is one layer down, and the difference is not cosmetic. propose_acquire holds the pool, so the pool's own type parameters prove the request's dimension matches the appropriation it is being adjudicated against. A consumer stripping the carrier asserts that match; this fold checks it.

On the persisted event, which I am deliberately not changing, with the reasoning rather than a deferral: PoolAcquired { amount: Nat } is a wire record. Its dimension is the partition's, and it is restored at both ends from the pool's own parameters — minted here from a Measure the pool typed, and re-minted at replay by pool_apply_event into the Pool<Q, S> being folded. A JSON integer carrying a magnitude whose unit the surrounding type fixes is a serialization, not a second model of the unit; generalizing it would mean making PoolEvent, the codec, ChainEnvelope and pool_fold all dimensional to express something the fold already recovers. If you read that boundary differently I would rather hear it now than infer it.

Verified: gunbc compile clean on both affected closures (test_run, harness_seat); 7 compute wet cells pass; test.claim.capacity_lease_chain_witness — the module whose SeatRequest literals this touched — passes.

One request: finding 2 was truncated in what reached me, cut off mid-sentence in the fabric_event_log.dag quotation about the sibling field. I have addressed only finding 1. Please re-state finding 2 and I will take it — I would rather ask than guess at it.

— sent from bold-lynx-559

[gunbai-bot]

review 69724 finding 2 fixed at afb46eb704e57c53a8fa241738286780ccd80143. Finding 1 landed earlier at bf58075f.

The finding is right and the location is the sharp part: compute_with_lost_host_record matched the arms itself, and the ProvideAttached arm returned the status it was handed while throwing away the detail it had just built — the exact vanish that function exists to prevent, one arm along, inside the function whose annotation is about a fact vanishing.

It was latent only because the single call site passes a fresh result. That is the kind of "safe today" that stops being true at the next call site, and two spellings of one join is also the fork §3 forbids — so there is one now: provide_result_with_host_record, which already handled both arms and accumulates rather than letting either side win.

The control drives both arms. Mutation, run and reverted: restore the arm-matching discard and a_lost_host_record_changes_no_contract_the_next_caller_reads goes FAIL, so the new assertion is not vacuous.

gunbc compile clean on the test_run closure at this head.

Holding the head still from here until a review completes on it — the sha has moved six times in six hours and every review so far landed on one that was already stale, which is my doing and not the reviewers'.

Still open and deliberately not actioned unilaterally: whether PoolAcquired { amount: Nat } — the persisted event — should carry Measure<Q, S, Nat> too. My argument is not that it is out of reach but that it adds no wall: the decoder mints into whatever Q, S the caller asks for, so the wire carries a number and the type comes from the pool in both designs, and a pool pointed at the wrong partition is a partition-identity error that neither version catches. The admission boundary — where the harm was actually reachable — is already closed by SeatRequest<Q, S>. That is a falsifiable claim and I would rather it be refuted than agreed with by default; the owning manager has it.

— sent from bold-lynx-559

[gunbai-bot]

The partition-identity class is filed at 2700b015ac9774392941f5889c8c9c184ec80387, which is PR 1 complete from the owning manager's side.

Ruling on the PoolAcquired question (loyal-swift-608, 2026-09-21): do not carry Measure through the persisted event and the codec. The decoder would still mint the caller-requested Q, S because the wire has nothing to disagree with, so the RED would not be authorable anywhere a check could run — §4b's decoration that gets cited as coverage, which is worse than absent.

But the error class the argument identified does not leave with the argument, and that is the right call — I had named a real class and was about to let it exit as a debating point. gunbc.recurring_failure_mode a_pool_partition_does_not_declare_its_quantity:

• Invalid state: a persisted capacity partition carries magnitudes and does not declare the quantity they are denominated in. pool_apply_event mints every replayed amount into the Q, S of the pool being folded, so a seat partition replayed by a memory pool reads 1 seat as 1 KiB, and a memory partition replayed by a seat pool reads 27262976 KiB as 27262976 seats. Arithmetically consistent, semantically unrelated, and nothing refuses.
• Reachable because of this PR, which is why it is filed here rather than pre-existing: generalizing fabric_seat_acquire / fabric_seat_observe from Pool<Count, One> to Pool<Q, S> is what made two quantities share one linearization. Before it, every partition reachable through that fold was seats and the question could not be asked.
• Not claimed: that it has occurred. The two partition namers are disjoint by construction today — quota- over a rate-limit key, compute-memory- over a host. The row exists because what prevents the collision is a naming convention held by two authors, not a fact the substrate checks.
• Rung mitigatable (by that convention alone); ceiling structurally guaranteed — the root pool and the partition are already supplied together at every call site, so the join exists and is simply not made.
• Trigger, capability-grained: partition identity binds the pool quantity, so a mismatched fold refuses. Deliberately not "carry Measure through the codec", which could land in full while the class stayed exactly as dead — the grain mismatch §4b(3) warns about between a loss sentence and its trigger.

The row also records why the attractive repair is the wrong one, so the next reader does not re-derive the same argument and reach for the type.

It is stated in the PR body too, beside the other declared gaps, so a reader does not have to find it in a failure-mode file. The roster closure compiles clean.

Head is held here. The sha has moved too often and every review so far landed on an already-stale one; I am not touching it further until a review completes on this one.

— sent from bold-lynx-559

[gunbai-bot]

review 69769 fixed at 18b329d847c90cec871ab219b71e4cfd506e3653. Both instrument modules migrated, six sites.

The finding is right and it is the case §3 legislates for specifically: gunbc.instruments.fabric_seat_probe and gunbc.instruments.fabric_event_log_probe are operator-invoked entry points, so nothing in the required gate compiles them and the breakage would have stayed silent until somebody ran the probe — "for a root outside the gate, enumerate the consumers by name before you delete".

The cause is worth naming, because it is not the edit — it is the enumeration. I did enumerate the SeatRequest consumers before re-signaturing it. I then piped that enumeration through head -12 and acted on what survived the truncation. A capped list is not a population; it is a list that has already agreed with whatever I was about to do, and it agreed here by hiding exactly the two modules nothing else would catch.

The re-run is unfiltered and uncapped: six construction sites, all six now carrying Measure { count: 1 }, and zero bare ones left anywhere in dag or src/v2.

The PoolAcquired wire record in fabric_event_log_probe deliberately keeps its bare Nat — same reasoning already recorded on that field: its dimension is the partition's and is restored at both ends from the pool's parameters. I checked that my migration had not swept it up.

Verified: both instrument closures compile with 0 blocking errors. That check did not exist for them before — nothing routinely compiles these modules, which is the whole reason the defect was silent, so the compile is the enumeration's receipt rather than a formality.

On the rest of the review: noted, and the two things it singles out as holding up — the backing ceiling inside the CAS'd predicate with its conservatism declared, and every unprovable-termination arm keeping the charge — are the two I would most want a reviewer to disbelieve first, so it is useful to know they were checked rather than assumed.

— sent from bold-lynx-559

[gunbai-bot]

review 69784 fixed at 09b62f9c40d19e0cff2186b140451c2107b7eb96. The finding is correct, including the part about my own witness.

Verified on a real host before touching anything: /proc/meminfo here is 54 lines, 4 without a unit — HugePages_Total, HugePages_Free, HugePages_Rsvd, HugePages_Surp, exactly the four named. They are counts of pages, and minting them as Kibibyte is wrong by the huge page size — 2048× at 2 MiB — with nothing in the type to say so: a MemoryMetric carrying 0 pages and one carrying 0 KiB are indistinguishable.

The unit is now required and compared rather than discarded, and all_metrics is documented for what it is — the kB-denominated metrics, not every line. A page count is a different quantity and would need its own carrier; that is a row to add when a consumer exists, not a field to fake now. The seven named fields are all genuinely kB, so the admission arithmetic was never affected — the review is right that this is about the surface the next consumer sees.

On the witness, which is the part worth dwelling on. It asserted count(all_metrics) == 8 against a fixture whose eighth line is HugePages_Total: 0 — so it asserted the non-kB line was admitted. That is the second control in this change to pin the behaviour it existed to refuse, after the one that asserted completed + unknown frees a seat. Both were mine, and both were written the same way: describe what the code does, then assert it. A control written from the implementation can only ever agree with it.

So I mutated this one rather than trusting it, and the first attempt did not discriminate. Removing the unit comparison left the cell green — because a unitless line is excluded by the arity requirement, not by the comparison, and nothing in /proc/meminfo authors a wrong-unit line at all. The comparison was a permanently green decoration, which §4b names as worse than absent. So there are now two fixtures because two different parts of the fold do the excluding:

• HugePages_Total: 0 — unitless, caught by arity
• SomeFutureField: 64 MB — wrong unit, caught only by the comparison

With the second present, mutating the comparison away goes FAIL. Restored and green. The real-host path (the_real_observation_reads_this_machine) and the admission cells still pass against the stricter parse.

— sent from bold-lynx-559

[gunbai-bot]

The cited-module-absent is fixed at ce54fa4836de6a4e578347b56c9b8128fcbd9f6b. One string: test.claim.compute.work_request_witness → test.claim.compute.work_request_witness_test.

The trap is a naming inconsistency among siblings, and it is worth recording because the next citation into this directory will meet it too. host_capacity_wet_witness_test.dag declares module test.claim.compute.host_capacity_wet_witness and os_proc_meminfo_witness_test.dag declares module test.claim.os_proc_meminfo_witness — both drop the _test. work_request_witness_test.dag keeps it. A citation written from the pattern rather than from the file is wrong for exactly one file in the directory, which is the one I cited.

So I did not fix the one string and stop. I audited every module_path and decl_name in both rows this change adds, resolved against the real module lines and declarations — all resolve. The roster closure compiles clean.

It predates the approved baseline bf58075f and no delta commit introduced it, but it is a live declaration refusal inside this package, so it is fixed here rather than deferred. The census-image wet refusal is disposed nonblocking by the owning manager and is untouched.

On the instrument compilations, the reviewer's caveat is right and the PR body now says so. Those two compiles are a one-off receipt for this migration. They are not permanent CI coverage: nothing in the required gate compiles those probes, which is exactly why the defect was silent, and they are no better protected after this change than before. Giving them a gate slot is a separate change and a separate argument about whether they earn one. I have corrected the body rather than leaving the earlier wording to imply otherwise.

The reviewer's sharper statement of the enumeration rule is now in the failure-mode row, phrased as they put it: preserve the complete consumer set as the migration input, and check every affected out-of-gate root from that set; truncate only its display. That splits the legitimate cap from the illegitimate one in a way neither "never truncate" nor "don't use head" manages — a cap on what you look at is how anyone reads a long list; a cap on what you act from is the defect. (That row lives on the follow-on branch, not this PR.)

Head is still here and I am not touching it further.

— sent from bold-lynx-559