2026-10-16 — A hand-back stands while origin's default branch holds the record at the blob its tombstone names (facilitator-on-delegation, drain-many-accounts): the claim package reads that blob from origin's default branch as last fetched, as an entity tag names the version a conditional request was made against; only a blob read there that differs lifts the hand-back, never an unreadable branch or a record held in no file or in several; a blob read from a branch the act's fetch could not refresh can only read as changed sooner than a fresh one; and a release asked to hand back a record the branch does not hold in exactly one file pushes a plain tombstone and says why rather than refusing, so the reservation never outlives the hand-back (grounds: entity tags and If-Match in RFC 9110 sections 8.8.3 and 13.1.1, and git's content-addressed object model; spc-2610161044461448 step 3; iss-2610161015370582).

Frontmatter

.abcd/work/decisions/dcn-2610161412283450-a-hand-back-stands-while-origin-s.md
open on GitHub ↗ · commit history ↗

mentions6

• 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-26101618370099572026-10-16 — Refines dcn-2610161412283450 on the blob a hand-back is judged by when origin's default branch could not be refreshed (facilitator-on-delegation, drain-many-accounts review round): a stale branch reads the record at the blob it held when last fetched, so it can err either way: a hand-back made over a newer blob than that reads as changed though no one edited the record since (a drain may then take the issue), and a person's edit this copy has not fetched reads as unchanged until it is (a drain keeps backing off). Neither is bounded by the act; each lasts until this copy's next fetch of that branch succeeds, which every drain move and reservation act tries first. The earlier record's claim that a stale blob only reads as changed sooner was wrong. A release asked to hand back while the branch could not be read at all (this checkout names none, or its tree would not read) says so, rather than that the branch holds no one record of the issue (grounds: dcn-2610161412283450; spc-2610161044461448 step 3; the review of steps 1 to 18).
• dcn-26101619311226062026-10-16 — Refines dcn-2610161412283450 and dcn-2610161806433529 on a reservation made over a standing hand-back (facilitator-on-delegation, drain-many-accounts review round 2): a drain's reservation that would take over, or renew, the reservation at the issue's tip reads that reservation's first-parent line down to the tombstone it was made over, the same walk a plain release keeps a hand-back by, and backs off when that tombstone marks a hand-back whose record origin's default branch holds unchanged, whether the reservation over it is lapsed or still live, from this copy or another; a walk that cannot be read backs off too, since it cannot show the hand-back no longer stands. A person's own take-over or renewal goes ahead, as a person's own reservation over the hand-back's tombstone does. Reading the tip alone let a drain build an issue that waits on a person once that person's reservation over it lapsed (grounds: dcn-2610161412283450, dcn-2610161806433529; spc-2610161044461448 step 3; the re-review of the fix round).
• iss-2610161015370582A drain's hand-backs and judgements live only in the checkout that made them: routeHandBack promotes the issue to an intent draft in that checkout, uncommitted, then the release pushes a tombstone so the issue reads free everywhere, and eligibility ignores related_intents, so every other account's drain judges or works the same issue again and promotes it to its own draft id.
• itd-2610161016394967Drains on several accounts share the work
• spc-2610161044461448drain-many-accounts