[V3RON]

Closes #636

Status

Implement: done Review: passed (round 2 + 4 fix-checks) Hardware: n/a Gate: waiting for the stack

Assumptions

• Assumption: the plan field name — the planner's wait, no-capacity and both eviction plans carry the reason as reason; the console row carries its text as why.
• Assumption: a victim whose eviction claim is taken at plan time cannot happen with the real claims (they are excluded first), so the planner test uses claims that refuse an eviction or boot claim.
• Assumption: three existing tests changed with the behaviour the spec decided — src/daemon/dispatcher.test.ts "list.get requests ... queue position" now lists each entry's reason, and the RAM-budget noWait test now expects code: "NO_CAPACITY" (a DispatchError with details, not a bare NoCapacityError); src/gateway/dispatcher.test.ts types the helper's reason as the enum.
• Assumption: waitingRequestSchema stays an object with .shape (the CLI and console tests read the reason field from it) while a refinement refuses reason on a starting entry.
• Assumption: createTestEngine stores NO_CAPACITY for a refused noWait request, so a replay in the dispatcher test answers that code; the daemon passes its own classifier.
• Assumption: the reject reason of a twice-failed provision on the lease.rejected event — unresolvable-spec for a local request and no-wait (a lease.declined) for a probe, the nearest existing reasons, so the event catalog stays unchanged ("Events: none").
• Assumption: PROVISION_FAILED exits 1, not the lease-ended 14 — the two stay distinct; docs/CLI.md lists the row.
• Assumption: the planner no longer takes failures — a waiter that failed twice is rejected and never plans again, so the "two failures block a provision" branch is gone.

Review

Spec review: 3 blocking, 3 fixed, 0 notes. Code review: 4 blocking, 4 fixed, 4 notes. Claims review: 3 blocking, 3 fixed, 2 notes.
Rounds: 2. Tokens: 11.9M.
Assessment: complete

Fix-checks: 4. The maintainer changed the spec after the third (a second provisioning failure now rejects with PROVISION_FAILED), which superseded X1, X3, X5 and F1; they were closed by reverting the skip logic.

Written by an agent.

[V3RON]

Decision taken

Question: after a request's second provisioning failure re-queues it, the new wake (item 2) makes the head plan again. Does the twice-failed request plan again too? If it does, it is placed at once (starting, no reason), and nobody ever sees provisioning-failed.

Options:

1. The wake plans only the waiters behind it. The twice-failed request stays queued with provisioning-failed until the next kick, as it does today. Users see — provisioning failed on its line.
2. The wake plans every waiter, the failed one included. It retries at once and may fail a third time, and its reason is seldom visible.

Taken: 1. It is closest to today's code, where a second failure enqueues without a wake, and it is the only option where the spec's provisioning-failed line can be seen.

Reverting: drop the skip in the wake, and the Tests line marked "decided in delivery" in #636.

Written by an agent.

[V3RON]

Review notes

Not blocking, not verified. Each is one reviewer's claim.

• code: src/leasing/lease-acquisition-coordinator.ts:618, :776-786 — if a physical waiter is cancelled between the #grantPhysical replan and #decidePhysical, it holds no claim, so nothing wakes the queue.
• code: e2e/console/workers.spec.ts:70 — answerMemory's route.fetch has the same end-of-test race as the one fixed in answerWithoutLoad.
• code: src/core/warm-pool/policy.ts:293 — the warm pool treats waiting-demand position 0 as the head, but leasing now skips twice-failed waiters, so a device booted for one of them may sit unclaimed.

Written by an agent.

[V3RON]

Decision changed

The maintainer replaced the delivery decision on #636 (2026-10-18).
A second provisioning failure no longer re-queues the request: it is rejected with a new error code PROVISION_FAILED carrying the driver's message, a probe included. The provisioning-failed waiting reason is dropped.
The gateway part (walk on, reject when every worker fails) goes to #637.

Written by an agent.

[V3RON]

Review notes (after the spec change)

Not blocking, not verified. Each is one reviewer's claim. Earlier notes are in the comment above.

• code: src/leasing/lease-acquisition-coordinator.ts — a local PROVISION_FAILED rejection emits lease.rejected with reason unresolvable-spec. That is the nearest existing reason, but not an exact fit.
• claims: docs/internal/adr/0021 §1 (line 111) still says a probe is declined after a "second failed provision". The ADR is a decision record and is left unedited.

Written by an agent.