Development record
2026-10-16 — A yes whose hand-back a move cannot publish keeps it pending in the drain's state and publishes it over the issue's next release on origin (facilitator-on-delegation, drain-many-accounts review round): when the hold the yes would release has moved on (this person renewed or reserved the issue again by hand, another took it over, a person released it), when the drain took none because this person held the issue live from this copy, or when the release did not reach origin, the route says the hand-back is not yet published and why, the drain keeps it (pending_hand_backs: issue, kind, the blob the yes was judged over, why, when) and carries it into the next drain, and each later move whose view shows the issue's tip as a tombstone marking no hand-back publishes it as that tombstone's child, fenced on the tombstone and on the judged blob; a tip already marking a hand-back, a record finished or changed on origin's default branch, or one origin holds in no one file ends it with nothing published. The drain never releases a person's own reservation to publish it, so it waits for the person's release rather than taking the issue (grounds: dcn-2610161040365515, dcn-2610161806433529, dcn-2610161315385888; spc-2610161044461448 steps 2 and 3; the review of steps 1 to 18).
2026-10-16 — A yes whose hand-back a move cannot publish keeps it pending in the drain's state and publishes it over the issue's next release on origin (facilitator-on-delegation, drain-many-accounts review round): when the hold the yes would release has moved on (this person renewed or reserved the issue again by hand, another took it over, a person released it), when the drain took none because this person held the issue live from this copy, or when the release did not reach origin, the route says the hand-back is not yet published and why, the drain keeps it (pending_hand_backs: issue, kind, the blob the yes was judged over, why, when) and carries it into the next drain, and each later move whose view shows the issue's tip as a tombstone marking no hand-back publishes it as that tombstone's child, fenced on the tombstone and on the judged blob; a tip already marking a hand-back, a record finished or changed on origin's default branch, or one origin holds in no one file ends it with nothing published. The drain never releases a person's own reservation to publish it, so it waits for the person's release rather than taking the issue (grounds: dcn-2610161040365515, dcn-2610161806433529, dcn-2610161315385888; spc-2610161044461448 steps 2 and 3; the review of steps 1 to 18).
Frontmatter
| id | dcn-2610161826443524 |
|---|---|
| type | decision |
| date | 2026-10-16 |
.abcd/work/decisions/dcn-2610161826443524-a-yes-whose-hand-back-a-move-cannot.md
open on GitHub ↗ · commit history ↗
mentions6
- adr-2610161940004937Spent reservation branches are deleted only by one GitHub App the ruleset names
- dcn-26101610403655152026-10-16 — A drain's hand-backs are published on origin (facilitator-on-delegation, drain-many-accounts): a drain's hand-back, from a lane or from a judgement, is the release of the reservation the drain took before judging, carrying a closed-vocabulary hand-back kind and the blob id of the issue record on origin's default branch, never free text; a reservation a drain makes backs off such a tip while the blob is unchanged, while a person's own abcd reserve or abcd build is let through with a note; a promotion the checkout cannot make because it does not hold the record as origin does publishes the tombstone alone and says so; an issue whose related_intents names an intent is ineligible, a clause added to brief invariant 19; and every account draining at once runs one build, since an older build reads the tombstone as a plain release (grounds: reasoned tombstones as Cassandra and Kafka keep them, and the fixed-form rule for the shared remote, dcn-2610150000000001; iss-2610161015370582).
- dcn-26101613153858882026-10-16 — A drain takes its judgement hold on an issue once per request and never renews it on a poll; a request whose hold lapses unanswered is dropped, the hold released, and the issue asked again only after the drain's other eligible work, since judgement requests had no expiry of their own and a host that kept polling held the issue indefinitely (spc-2610161044461448 step 2).
- dcn-26101618064335292026-10-16 — A plain release keeps a hand-back that still stands (facilitator-on-delegation, drain-many-accounts review round): a release with no hand-back of its own reads the reservation branch's first-parent line below its tip, at most 256 commits, to the first tombstone, and when that tombstone marks a hand-back whose record origin's default branch holds unchanged by the reading handBackStands uses, the new tombstone carries its kind and blob forward and the result says so (Result.HandBackKept); the walk passes renewals and take-overs, and an unreadable commit, a plain tombstone, the root or the bound keep nothing. The carried tombstone names the person releasing as its holder, since the closed trailer form names no earlier holder and a new trailer would read as unreadable to every binary already released. A release asked to hand back over a tip a plain tombstone already released publishes the hand-back as that tombstone's child, fenced by Tip on the tombstone or the reservation it released; with HandBackBlob it publishes none once the record's blob is another. Reserving and releasing an issue is not a person's change to its record, and a failed build start's clean-up is not a person's decision, so neither erases the hand-back (grounds: dcn-2610161040365515, dcn-2610161412283450; spc-2610161044461448 step 3; the review of steps 1 to 18).
- dcn-26101619311309112026-10-16 — Refines dcn-2610161826443524 on when a pending hand-back ends (facilitator-on-delegation, drain-many-accounts review round 2): it ends only when a release publishes it, or when it is no longer due: a tip already marking a hand-back, a record finished or changed on origin's default branch since the yes was judged, a record origin holds in no one file, or a tombstone the hand-back would take past its cap. A move that ends it unpublished says in its next step and in the route that it was dropped, and why, and never that it was published. A release that could not read origin's default branch at all (this checkout names none, or its tree would not read) keeps it pending, whether the release pushed a plain tombstone or found one already there, since that failure says nothing about the record and passes; the next move's release publishes it once the branch reads (grounds: dcn-2610161826443524, dcn-2610161837009957; spc-2610161044461448 steps 2 and 3; the re-review of the fix round).
- spc-2610161044461448drain-many-accounts