Dead code: three placement systems with zero production callers, and grid_overflow_lanes has no reader

[joelteply]

Symptom

The Academy benchmark team (Atlas / Benchy / Anwen / Asha) is live and cycling on hard-rs cards, and every turn dies. Observed: resident_personas=4, warm_slots=1.

The warm-slot math is CORRECT — do not "fix" it

serving_plan.rs computes lanes as the largest lane count whose per-slot window >= BOOTSTRAP_WORKING_SET, correctly determines only 1 of 4 minds clears the full-turn floor, fires the warm-slot-oversubscribed probe, and at :590 sets:

grid_overflow_lanes: demand_lanes.saturating_sub(lanes),

with the comment "carries the same count to the governor for off-box placement."

Do NOT unwedge this by raising warm_slots to 4. The floor gate is what keeps each slot able to see one full turn; raising it trades the wedge for 4 warm-but-blind minds — the 4-lanes-@-6k starvation the 2026-07-17 revert already caught.

Defect 1 — nothing READS grid_overflow_lanes

rg grid_overflow across the entire repo, all file types. Outside serving_plan.rs it appears in exactly three places:

• core/continuum-core/src/commands/serving/plan.rs:94
• core/continuum-core/src/commands/serving/pin.rs:201
• core/continuum-core/src/modules/serving_daemon.rs:4543

All three are grid_overflow_lanes: 0, struct-literal initializers. Zero readers. It is not serialized to TypeScript/protocol either, so it never reaches a UI or the wire.

Defect 2 — nothing CALLS the planner

core/continuum-core/src/resources/placement.rs:309

pub fn plan_grid_placement(nodes: &[GridNode], demand: &LaneDemand) -> GridPlacement

Its own doc comment calls it "THE grid admission planner." It has zero production callers: #[cfg(test)] mod tests starts at :334, and every call site (525, 544, 554, 572, 588) is inside it.

The shape

Two complete, well-tested halves and no join. serving_plan.rs:1185 even asserts "the 2 unslotted minds are surfaced for grid placement" — a test that passes while placement never happens.

This is the disk_eviction pattern from CLAUDE.md exactly: unit-green components with dead wiring. Third instance of that class found on 2026-08-10.

Consequence: the 3 unslotted minds are neither queued nor placed. They stay resident and LRU-clobber each other's KV, re-prefilling ~10k cold every turn (#266's 96%-prefill / 0%-cache-reuse story). That is the wedge.

The fix

serving_daemon already publishes the plan on plan_tx: watch::Sender<Option<ServingPlan>> (:246, send_replace at :2046, subscribe() at :587) — the canonical RTOS shape CLAUDE.md prescribes. So the join is a subscriber, NOT a hot-path edit: no pressure interpretation inside compute_plan, no parallel allocator, nothing added to the tick.

1. A placement task subscribes to plan_tx.
2. On a plan with grid_overflow_lanes > 0, build GridNodes from the live capacity::grid::GridSnapshot.
3. Call resources::plan_grid_placement(nodes, &LaneDemand).
4. Act on the verdict: Place { node_id, placement } -> dispatch the overflow mind to that peer. NoNodeReachable -> loud, because silently keeping it local is today's wedge.

Which planner: resources::plan_grid_placement — its signature already takes LaneDemand, which is what serving_plan produces. provisioning::placement_planner is footprint-shaped and answers a different question (does THIS model fit THAT peer); it should not become a second caller. Settling this matters — adding a caller without deciding creates the third parallel allocator CLAUDE.md forbids.

Required alongside the wire: a chain-level guard

Per the disk_eviction precedent in CLAUDE.md, the fix is not only the wire. That lesson pairs it with broker_relieve_actually_deletes_from_an_over_budget_pool, which pins pressure -> broker -> real deletion end-to-end precisely because unit-green-with-dead-wiring is what it catches.

Add the analogue here: a test driving plan-with-overflow -> placement -> real dispatch, so this cannot silently regress into another green assertion over a placement that never happens.

---

Found while unblocking the Academy team. Diagnosis confirmed independently in-file by M5.

[joelteply]

Correction — it is worse than a missing wire. THREE placement systems, all dead.

The original report said "wire resources::plan_grid_placement". Do not do that yet. Further grepping shows the problem is not one missing consumer — it is that no placement system has ever been wired, and there are three of them.

System	Entry point	Production callers
resources/placement.rs	plan_grid_placement(nodes: &[GridNode], demand: &LaneDemand)	0 — #[cfg(test)] mod tests starts at :334; call sites 525, 544, 554, 572, 588 are all inside it
provisioning/placement_planner.rs	select_grid_peer(snapshot, footprint), grid_has_fit	0
capacity/grid.rs	GridPlacementPolicy::place — impls LocalFirstFitPolicy, AffinityFitPolicy, StickyPlacementPolicy<P>	0

For (3): rg '\.place\(' outside capacity/grid.rs returns nothing. Inside it, the only calls are StickyPlacementPolicy delegating to its inner policy (:244), the GridScenario simulation runner (:437), and the test mod (:720+).

So we do not have a broken wire. We have three parallel allocators and no consumer — plus a simulation harness that exercises one of them, which is why they all look alive.

serving_plan.rs predicted this in a comment, in advance:

capacity::grid's GridPlacementPolicy becomes a thin adapter over this once its GridSnapshot carries each node's resident models (the integration slice) — NOT a third parallel allocator.

It became the third parallel allocator.

Why this needs a deliberate decision, not a quick wire

Adding a subscriber that calls any one of these makes that planner the survivor by accident — chosen by whoever grepped first, not by anyone's judgment. CLAUDE.md's compression principle is explicit that one logical decision lives in exactly one place, and picking the winner at 2am to unwedge a benchmark is how a fourth one gets born.

Suggested shape (needs a human call before anyone implements)

• capacity/grid.rs as the survivor — richest surface: policy trait, sticky/affinity variants, OOM accounting, and a scenario simulator.
• Adapt it to take LaneDemand — resources/placement.rs has the better-shaped input, since LaneDemand is what serving_plan already emits. Absorb or delete plan_grid_placement.
• Keep provisioning::placement_planner as a helper, not a placer — it answers a genuinely different question (does THIS model fit THAT peer).
• Then wire exactly one subscriber on plan_tx, plus the chain-level guard test described in the original report.

Blocking on: which system survives. That is an architecture call, not a grep result.

[joelteply]

Survivor decided + complete implementation spec (every seam verified)

SURVIVOR: resources/placement.rs. Decided from git history, not surface richness, and independently confirmed by M5 after an initial disagreement.

Evidence:

• capacity/grid.rs ADDED 2026-07-18, LAST touched 2026-07-20 by commit 0bd652b8b.
• resources/placement.rs ADDED 2026-07-20 — by that same commit 0bd652b8b ("Lane admission planner + Proctored Exam Session").

So grid.rs was not abandoned by neglect; it was superseded, deliberately, in the commit that introduced its replacement.

The comment at resources/placement.rs:253-257 is the supersession note, and the pronoun is load-bearing:

plan_grid_placement is the convergence … capacity::grid's GridPlacementPolicy becomes a thin adapter over this …

this = plan_grid_placement. It demotes GridPlacementPolicy to a shim; it does not crown it. (Both M5 and I initially misread this as crowning grid.rs — worth flagging for the next reader.)

And :247-251 gives the functional reason: grid.rs's LocalFirstFitPolicy places lanes model-blind — by free bytes — so it "would spill a lane to the peer with the most free RAM even when another peer already has that base model WARM." For the Academy case that is actively wrong: it would spill a Devstral lane away from the peer already holding Devstral warm, recreating the cold-prefill cost we are trying to escape.

Disposition: resources/placement.rs survives · capacity/grid.rs's allocator becomes a shim or is deleted · provisioning/placement_planner.rs stays a footprint helper (newest, and the only one still maintained — last touched 2026-08-06).

---

Implementation spec

Good news: the data source is LIVE. capacity::gossip::global_ledger() is genuinely fed in production — airc/inbound_attach.rs:312 records peer offers via .hear(...), and capacity/lease.rs:143 already calls .snapshot(...). This is not a fourth dead component.

Home: a sibling ServiceModule, mirroring modules/grid_capacity.rs. That module's own doc states the shape: "no new tokio task, no new monitor — the runtime's tick cadence drives it." Follow it exactly; do NOT add a tokio task, and do NOT edit compute_plan (no hot-path pressure interpretation).

Verified seams

Need	Where	Note
The plan	serving_daemon.rs plan_tx: watch::Sender<Option<ServingPlan>> :246, send_replace :2046, subscribe() :587	subscribe, don't poll
Overflow count	ServingPlan.grid_overflow_lanes :344	demand_lanes - lanes, saturating
Live grid	capacity::gossip::global_ledger().snapshot(own_peer, local, now_ms) gossip.rs:120	pattern at lease.rs:143
Planner	resources::plan_grid_placement(&[GridNode], &LaneDemand) placement.rs:309	the survivor
Registration	ipc/mod.rs:1912 registers GridCapacityModule	mirror this site

Type mapping (all fields confirmed)

• GridSnapshot { local: DeviceCapacity, peers: Vec<PeerCapacity> }
• PeerCapacity { peer: PeerId, capacity: DeviceCapacity, reachable: bool }
• DeviceCapacity { gpu_total_bytes, gpu_free_bytes_live, system_ram_free_bytes }
• GridNode { node_id, capacity: u64, resident: Vec<ResidentLane>, reachable: bool, local: bool }
• LaneDemand { base_model_id, weights_bytes, slots, window, kv_per_token, compute_buffer, tier, isolate }

Map PeerCapacity -> GridNode (reachable carries straight over; local: false for peers, true for snapshot.local). Build LaneDemand from the ServingPlan (base_model_id, served_context_window -> window, slots = overflow count). isolate: true for Academy/exam lanes — LaneDemand's own doc says a benchmark demands a dedicated lane, and the 2026-07-21 glass-box shows a benchmark sharing a persona lane starves behind their turns.

Acting on the verdict

• GridPlacement::Place { node_id, placement } -> dispatch the overflow mind to that peer (M5 owns actuation: persona_workspace.rs:1068 re_home_all).
• GridPlacement::NoNodeReachable -> loud. Silently keeping it local is today's wedge.

Required alongside

A chain-level guard test: plan-with-overflow -> placement -> real dispatch. Per the disk_eviction precedent (broker_relieve_actually_deletes_from_an_over_budget_pool), which exists because unit-green-with-dead-wiring is what it catches. Without it this regresses into another green assertion over a placement that never happens — which is literally serving_plan.rs:1185 today.

[joelteply]

⚠️ CORRECTION — this issue misdiagnosed the Academy wedge. The wedge was ALREADY FIXED.

Do not implement the spec above as a fix for the Academy wedge. It solves a real problem, but not that one.

The warm-slot wedge has already been addressed, twice, within the last three days:

• 82ead2ac5 (Rust Module Consolidation Phase 2: Optimization & Compute Migration #266/README accuracy audit + Alpha Gap Analysis master plan #386) — "a measured solve quiesces the OTHER residents so it holds an exclusive warm slot" (agent/solve.rs, airc_runtime_registry.rs) — the 85s -> 2-5s win.
• e3ac68b99 (PersonaToolExecutor: tool selection, routing, and execution failures #368, PR fix(serving): downshift debounce + level-triggered rehome retry — a transient must never re-brain the citizenry (#368) #2186) — downshift debounce + level-triggered replan.

So resident_personas=4, warm_slots=1 is not resolved by placing overflow off-box. It is resolved by quiescing — the measured solve takes an exclusive warm slot while the others stand down. That is a fundamentally different remedy than grid placement, and it already exists.

How I got this wrong (worth recording)

I verified exhaustively that the placement code was unwired. I never verified that the problem was still open. 82ead2ac5 appeared in a git log origin/canary output I printed myself earlier in the same session, one line from commits I did read — its subject line describes the fix — and I did not connect it, because I had anchored on the oversubscription framing and was hunting for a missing consumer.

The check I skipped is cheap and should be the FIRST move on any reported blocker: git log the recent history for the symptom before diagnosing the mechanism. I applied that discipline to the planner files (where it correctly overturned my survivor pick) and not to the bug itself.

What in this issue is still valid

The dead-code findings are independently true and worth keeping:

• Three placement systems, all with zero production callers (resources/placement.rs, provisioning/placement_planner.rs, capacity/grid.rs).
• grid_overflow_lanes has zero readers and is not serialized to protocol.
• serving_plan.rs:1185 asserts "surfaced for grid placement" and passes while placement never happens — a green test over a thing that does not occur.
• The survivor analysis (resources/placement.rs, from 0bd652b8b) stands, as does the note that grid.rs's LocalFirstFitPolicy is model-blind.

Reframing: this is a dead-code / compression issue — three parallel allocators that should be one, and an overflow signal with no consumer — not an Academy blocker. Retitling accordingly. It should be scheduled on its own merits (grid placement will be wanted eventually), not as a wedge fix.

[joelteply]

Disposition change: DELETE, not consolidate — the design went to leases

Verified after M5 pointed out that "smart grid allocation" was never a placement allocator. This is not "three allocators that should be one" — it is an abandoned direction. Accommodation went to lease policy.

The lease path is genuinely live (unlike all three placement systems):

• cognition::throughput_lease::ThroughputLease has real production consumers: inference/lane.rs:53,67, inference/coordinator.rs:55, cognition/resource_admission.rs:11, cognition/generate_response.rs:48.
• inference/lane.rs:114-119 carries the revocation ladder: LaneClass::Realtime -> Pinned, Interactive -> Graceful, else Hard. That is the "Graceful leases reclaim, GPU frees" mechanism — wired, not aspirational.

So the correct disposition for the three placement systems is delete, not merge. That is cheaper and cleaner than the consolidation this issue originally proposed, and it removes the trap of a future reader wiring one of them up.

Two precision notes for whoever does the deletion

1. "Governor modes" do not exist in code. rg 'GovernorMode|governor_mode' across core/ returns zero hits outside tests. The Aug 9 design note describes modes; what is implemented is the throughput-lease revocation policy. Worth stating plainly, because "governor modes" sounds like something you can go read and tune, and there is nothing to read. Making modes first-class is a build, not a wiring.

2. capacity/lease.rs is half dead, and the dead half is being cited as a model. decide_render_lane IS live (persona/response.rs:722). decide_lane has no callers — but capacity/expert_residency.rs:32 and capacity/recursion_depth.rs:42 both reference it in their docs as the pattern they imitate ("Pure + sim-provable, exactly like super::lease::decide_lane"). A dead function serving as the reference implementation for two other modules. Don't delete it blindly — either keep it as the documented exemplar or update those two docs to point at something live.

Revised scope

• Delete resources/placement.rs's grid allocator, capacity/grid.rs's GridPlacementPolicy + policies, and the unused parts of provisioning/placement_planner.rs, OR mark them clearly as an abandoned direction if anything still wants the sim harness.
• Delete or wire grid_overflow_lanes — an overflow signal with no consumer, in a world where overflow is handled by lease reclamation, is misleading on its face.
• Fix serving_plan.rs:1185 — it asserts "the 2 unslotted minds are surfaced for grid placement", which describes a mechanism we are not building. A green test for an abandoned direction is worse than no test.

The implementation spec earlier in this issue stands only if grid placement is ever deliberately revived. It is not a to-do.