[V3RON]

Closes #774

Status

Implement: done (14/14 green, audited) Review: passed; R5 accepted open by the maintainer (2026-10-21) Hardware: n/a Gate: waiting for the stack

• pnpm test:changed passes.
• pnpm test:e2e e2e/warm-pool-reserve.test.ts e2e/warm-targets.test.ts passes.
• rg -n -i "behind a queued request" docs src finds only the new wording.
• rg -n "cpuCount" src/core/warm-pool/config.ts shows the default derived there, and docs/CONFIGURATION.md states the formula.

Assumptions

• Assumption: which waiter is "the head" for the pool — the first waiter that no ready idle device takes; a waiter whose every earlier waiter is matched to a ready idle device counts as the head too. The queue reaches it at once and leasing creates for it, so a pool creation would only duplicate (an idle extra device). Conservative: the pool creates less. One policy case in the spec ("one ready device and two waiters it serves → the second gets a creation") holds only when an earlier waiter is in flight or on its way.
• Assumption: the e2e queues the five leases behind a device the pool is booting. A lease that arrives while no request is enqueued plans for itself at once, so five simultaneous leases with room all create their own device and the pool has no one to create for.
• Assumption: a lease granted a ready device wakes the queue (LeaseAcquisitionCoordinator). Without it, a request behind the head whose pool-made device was already ready stayed queued until some other event; the e2e found it.
• Assumption: src/daemon/main.test.ts "creates no further device for a target once a stop is asked for" pins warmPool.maxConcurrentBoots to 1, as e2e/warm-targets.test.ts does, because its two-target count relied on the old default.

Review

Spec review: 1 blocking, 1 fixed, 0 notes. Code review: 2 blocking, 1 fixed, 0 notes. Claims review: 1 blocking, 1 fixed, 1 notes.
Rounds: 2. Tokens: 5.7M.
Runs: 15. Cost USD: 9.544. Agent seconds: 6655.
Assessment: incomplete

Written by an agent.

[V3RON]

Decision taken

Question: with one ready device and two queued requests it would serve, does the warm pool create a device for the second request? The spec said yes; the build assumed no (review R2).

• A — pool creates for the second (spec as written). The second request gets its device a little sooner. In the build's e2e this produced one extra device: once the first request is granted, the second becomes the queue head and leasing creates for it as well.
• B — the head is the first waiter no ready idle device takes (taken). The second request is the head; leasing creates for it, as today. No duplicate creation; the second request waits only for the first grant, which is immediate because its device is ready.

Why B: it is closest to today's behaviour (leasing owns the head's creation, a Non-goal of #771), it creates fewer devices, and it is easy to reverse.

Reverting: treat a waiter matched to a ready device as the head in evaluate (src/core/warm-pool/policy.ts), restore the two.slice(1) assertion in policy.test.ts, and make the pool's creation count as on its way for leasing's head creation. Issue #774's body now carries B, marked pending the maintainer.

Written by an agent.

[V3RON]

CI e2e/usage-projection "newer stored projection version" failure (run 39481062187) is a known flake, not this change: reproduced on base 80cba39, filed as #790.

[V3RON]

Review ledger

Runs: 15. Cost USD: 9.544. Agent seconds: 6655.
Tokens input 718, output 217995, cache read 32072154, cache write 1061087.
- build implementer: claude-sonnet-5-5 2545 s $4.0768
- audit implementer: claude-sonnet-5-5 657 s $0.3611
- review 1 reviewer: claude-sonnet-5-5 418 s $0.2829
- review 1 spec: claude-sonnet-5-5 49 s $0.3153
- review 1 code both: claude-opus-5-5 322 s $1.6781
- review 1 claims: claude-sonnet-5-5 74 s $0.289
- fix 1 implementer: claude-sonnet-5-5 106 s $0.2047
- fix 1 implementer: claude-sonnet-5-5 1722 s $0.5356
- review 2 reviewer: claude-sonnet-5-5 196 s $0.1745
- review 2 reviewer spec: claude-opus-5-5 32 s $0.2679
- review 2 reviewer code: claude-opus-5-5 102 s $0.5439
- review 2 reviewer claims: claude-sonnet-5-5 38 s $0.0863
- fix 2 implementer: claude-sonnet-5-5 65 s $0.1065
- review fix-check reviewer: claude-sonnet-5-5 202 s $0.1061
- review fix-check code both: claude-opus-5-5 127 s $0.5153
Finding outcomes: {"duplicate":1,"fixed":3,"open":1}. Classes: {"architecture 13":1,"incomplete doc wording":1,"retry schedule not read for waiter boots":1,"spec case contradicted by assumption":1,"testing 3, 9":1}.

{"findings":[
{"id":"R1","role":"code","class":"retry schedule not read for waiter boots","outcome":"fixed","path":"src/core/warm-pool/policy.ts","fix":"8dbbe671"},
{"id":"R2","role":"spec","class":"spec case contradicted by assumption","outcome":"fixed","path":"src/core/warm-pool/policy.ts","fix":"0020a846"},
{"id":"R3","role":"claims","class":"architecture 13","outcome":"duplicate","path":"src/core/warm-pool/converger.ts","canonicalId":"R1"},
{"id":"R4","role":"claims","class":"incomplete doc wording","outcome":"fixed","path":"docs/CONFIGURATION.md","fix":"0020a846"},
{"id":"R5","role":"code","class":"testing 3, 9","outcome":"open","path":"src/core/warm-pool/converger.ts"}
]}

Written by an agent.