selection never spends money — the machine waits (MX-262)

[MGrin]

mgrin's call, 2026-08-22, given directly and reversing his own first answer inside the same message. The record does not carry the "yes":

"The account with billing is an exception — I just needed it one time... in normal operation the system must not prioritize the account with money; it should operate as usual, and if all accounts exhausted all their limits it should wait for limits to be waived. So sorry, my correction, the answer is no — it should not rank this account above."

This plugin is the primary switcher, so the paired change in MGrin/dotfiles (the deadman Python switcher) would not have implemented the decision on its own.

One gate, in pickBest

pickBest now returns only slots with a free window. A tier-1 slot — credits ON behind a spent window — is filtered out rather than ranked last. Ranking it last was MX-210's answer and it was right for the question MX-210 asked; it still got selected whenever nothing better existed, which is exactly the state where the money gets spent.

The gate is in pickBest deliberately, because every automatic path runs through it: decideSwitch, the reactive rate-limit handler, bb accounts auto, and analytics/simulate.ts (which exists to model what the switcher would do). Guarding each caller would leave the next caller unguarded.

bb accounts switch <slot> does not go through pickBest — it takes an explicit slot, and that is the exception mgrin invokes, so it keeps working untouched. bb accounts place was already compliant: usableHeadroom is min(switchAt − 5h, weeklyAt − 7d) and filters on > 0, so a spent burst never had headroom there.

The reason now says which state it is in

{action: "none", reason: "no eligible alternative slot"} was also what a machine returned when it had paid capacity sitting right there and declined it on purpose — which reads as a broken poll to whoever finds it in the log. Three states now:

1. nothing tripped, and the only alternative is paid
2. a move was wanted and paid capacity was declined → WAITING: ... would serve, and BILL, ... to spend deliberately: bb accounts switch <slot>
3. genuinely nothing anywhere → unchanged wording

The dedicated spread declined: guard is gone rather than duplicated — pickBest cannot hand a paid slot to anything now. Its test keeps the claim it existed for (an optimization is not a reason to bill) and asserts no switch plus a reason naming the credit account.

Reporting is untouched and disagrees on purpose

capacityVerdict still answers paid-only and bb accounts outage still exits 1 saying the machine can serve. That is MX-218 and it is true.

Question	Asked by	Answer on a paid-only machine
What is POSSIBLE?	capacityVerdict, bb accounts outage	paid-only — can serve, exit 1
What is POLICY?	pickBest, decideSwitch	select nothing; wait

The recovery sweeper deliberately follows REPORTING (anyAccountHasCapacity holds only on none), because a machine mgrin has deliberately put on the credit account must keep working. That asymmetry is now written into the README rather than left to be discovered and "fixed".

Tests

291 → 294 pass, 0 fail, 0 skip; tsc --noEmit clean. Two inverted tests keep their original provenance in their comments — a spent credit account is a candidate at all and a walled machine moves onto credits both asserted the opposite until this commit, and both were right for MX-210's question.

Paired with MGrin/dotfiles#240.

🤖 Generated with Claude Code