Sessions treat merges as held for a release cut whose holder has crashed: on 2026-10-24 local session abcd-0d told every session that v0.15.2 is being cut so merges are held, while the only marker of that cut on origin is the reservation rel-v0.15.2, held by copy 07cd3b4c167cec332f8c01cf42ad41d6 (a computer that crashed), last renewed 2026-10-23T08:52:49Z and expired 2026-10-24T08:52:49Z, with no standing announcement, no release branch and no newer tag. Nothing names a cut as abandoned: abcd status lists rel-v0.15.2 as an ordinary expired reservation, so a session reading it, or relaying a hold heard earlier, keeps work waiting on a session that no longer exists, and two finished pull requests (the drain spec's landed marks, the fix for iss-2610110918418459) sat waiting for a ruling from it.

Frontmatter

.abcd/work/issues/resolved/iss-2610241104098581-sessions-treat-merges-as-held-for-a.md
open on GitHub ↗ · commit history ↗

mentions3

• dcn-26102719263694252026-10-27 — Release hold, Q1 revised (facilitator on delegation, lane D on abcd-f5's ruling, 2026-10-27; supersedes Q1 of dcn-2610230328220298): a release reservation whose lease lapses with no release tag on origin ends its hold. The merges this cut recorded as withdrawn are re-armed, and only those, each with one comment on its pull request saying the cut lapsed. A merge the cut did not record is never armed. A cut that outlasts its lease renews it with abcd reserve rel-vX.Y.Z, so a live cut's withdrawals stay withdrawn. Grounds: on 2026-10-24 the person ruled that sessions do not hold merges for a lapsed release cut, which #1132 implements by naming a lapsed cut as holding no merge (iss-2610241104098581). That day two finished pull requests waited on rel-v0.15.2, a cut whose computer had crashed. Under the old Q1, merges such a cut withdrew stay withdrawn indefinitely, which contradicts that ruling. Q1's own risk, a cutter's next act re-arming merges mid-cut, is met by renewal: a cut that is still running is still renewing.
• iss-2610110918418459The implement loop's landing never writes a spec step's '- landed:' line, so a spec the loop landed part of still reads those steps as unlanded: a later 'spec close --remainder' carries steps that already merged into the remainder, and a fresh 'abcd build' of the same spec opens a lane for them again. Found by the fidelity audit of itd-2609212103565953 (receipt rcp-2257cc3a38d9, criterion ac-3 MET_WITH_CONCERNS); spc-2609202134338445's Progress already says the landing does not mark a non-closing lane's step.
• iss-2610241107191205A lapsed hold or reservation must be lifted without a person, or autonomous work waits on a holder that no longer exists. On 2026-10-24 a computer that had reserved a release cut (rel-v0.15.2) and dozens of issues and intents crashed. Its leases lapsed, yet sessions on another machine kept waiting on it: one session relayed the release hold to six others as live, from a read made before it lapsed, two finished pull requests waited for the dead cut's ruling, and a build was held behind the crashed copy's work. The product thinker ruled the same day that lifting a lapsed hold is autonomous: no person is needed to declare a lapsed holder gone. The reading side already counts a reservation five minutes past its expiry as released. What is missing is that every reader, verb and agent instruction acts on that, and that spent branches leave origin without a person. This record carries the ruling that the whole path runs unattended.