A person's reservations do not say which of their sessions or checkouts holds them. Several sessions run under one account, and every hold reads holder <the product thinker's login> with an opaque copy key. On 2026-10-16 two live intent holds (the messaging and cloud-sessions intents) sat at the ten-reservation cap while no session could tell whose they were. Two peers had to ask each other in turn before one was released.

Frontmatter

.abcd/work/issues/resolved/iss-2610161457209287-a-person-s-reservations-do-not-say-which.md
open on GitHub ↗ · commit history ↗

mentions2

• iss-2610231004012419abcd reserve cannot widen a live reservation from another copy of the same person on the same machine. A second worktree that reserves the same id with more footprint paths is refused as if the hold sat on another computer (internal/core/claim/remote.go:403, 'you are already building it on another computer; pass --take-over'), and a take-over moves the hold, which can disturb the run that owns it. Two sessions hit this on 2026-10-23 in the hand-rolled coordination log: abcd-54 at 10:04 could not add the worktree store's step 3 and 4 files to its live itd-2609091014076309 hold from a second copy, and borrowed an unrelated open record's reservation to announce them; abcd-f1 at 10:26 and 10:41 had its own hold read from a sibling worktree as another computer, and added the paths from the reserving worktree instead. Related: iss-2610161457209287 (holds do not say which of a person's copies has them).
• 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).