2026-10-16 — A status branch holding more new commits than one intake takes in is no longer shown as doubtful: it is left unmarked, the branches after it are not walked once nothing is left to take in, the block counts each branch left as not read yet, and the next intake starts at the branch after where this one stopped; continuity not verified stays only for a walk that itself ran out, refining dcn-2610161737571276 (spc-2610150728396006 step 3 fix round 4, on review). A read mark at the tip passed the commits the cap left over for good, and a lasting doubt told the person nothing they could act on.

Frontmatter

.abcd/work/decisions/dcn-2610161907315656-a-status-branch-holding-more-new-commits.md
open on GitHub ↗ · commit history ↗

mentions3

• dcn-26101617375712762026-10-16 — A first read of a status branch that runs past the walk limit is always shown as doubtful, continuity not verified, whatever times its commits carry, refining dcn-2610161320457650 and dcn-2610161100416718 (spc-2610150728396006 step 3 fix round 3, on review). Within the bounded walk no signal settles whether a line older than what the read took in can still stand, so the read cannot say that nothing beneath it is live.
• dcn-26101619490324582026-10-16 — The status intake keeps every branch it left unread, each with the turn it was left at, and walks them before any other branch, the one left first first; a branch walked and left again goes behind every branch already waiting, so no branch waits behind more than the branches left before it. Once the cap has cut a branch short, it takes half its share from its newest unread commits and the rest from its oldest, and its read mark moves up to the newest commit beneath which every commit is read, so every unread commit is read within a bounded number of intakes. The forge is asked about the branch waiting longest first, and each branch asked goes behind every branch still waiting; a tip whose newest covering push came from an app is kept as asked until the tip moves, so every branch is asked within a bounded number of fetches. This refines dcn-2610161907315656 (spc-2610150728396006 step 3 fix round 5, on review): one place to start from, a newest-first read of each branch and a fixed newest-first order of asking each let a branch that keeps gaining commits keep other announcements unread or unasked for good.
• spc-2610150728396006sessions-announce-what-they-are-doing