abcd reserve holds one record per reservation and caps a person at ten live reservations across every session and copy of that account, so a small documentation pull request that fixes N records spends N of the ten: on 2026-10-16 two four-record follow-up PRs plus two intents another session held filled the cap, and every further reservation by any session of that person was refused until those PRs merged. The cap meant to bound one person's holds instead bounds how many record-sized fixes can be in flight.

Frontmatter

.abcd/work/issues/open/iss-2610160925028248-abcd-reserve-holds-one-record-per.md
open on GitHub ↗ · commit history ↗

mentions1

• iss-2610231004140527The live-reservation cap is counted per GitHub login across every session, copy and account that pushes under it (internal/core/claim/crowd.go), while each machine sets its own ceiling in reservation.max_live. On 2026-10-23 six interactive sessions on one login reached 30 live holds and abcd-43's reserve was refused at 10:40; abcd-ae raised the ceiling to 40 by hand, the third raise since 10-22 (hand-rolled coordination log, 10:40 and 10:41). A drain run under another account that pushes with the same login is counted against the same holder under its own, possibly lower, ceiling, which no session here can read, so the interactive sessions can hold the drain at its cap with nothing on either side saying so. Graded minor when filed, because the drain waits at the cap rather than failing (iss-2610161015371794), and whether the drain shares this login and at what ceiling is not yet confirmed; it was confirmed the same day, and the grade raised (below). This revisits the ruling recorded in iss-2610170717515674 (one ceiling per person, raised in the machine's configuration); related: iss-2610160925028248 (one reservation per record spends the cap) and iss-2610161457209287 (holds do not name their copy).