Development record
2026-10-16 — The status intake splits a branch's share between its newest and its oldest unread commits whenever the last intake left the branch unread: one the cap cut short in a walk, and one left without a walk once the cap was spent. The newest side takes the rounded-down half and the oldest the rest, so a share of one takes the oldest unread commit and every walk of a branch left moves its read mark. No tip is kept as asked because an app pushed it: a branch leaves the forge's queue once every standing announcement on it has a verdict, so an announcement an intake reads later at the same tip is still asked about. This refines dcn-2610161949032458 (spc-2610150728396006 step 3, on review), which named only a branch the cap cut short and kept a tip an app pushed as asked until it moved.
2026-10-16 — The status intake splits a branch's share between its newest and its oldest unread commits whenever the last intake left the branch unread: one the cap cut short in a walk, and one left without a walk once the cap was spent. The newest side takes the rounded-down half and the oldest the rest, so a share of one takes the oldest unread commit and every walk of a branch left moves its read mark. No tip is kept as asked because an app pushed it: a branch leaves the forge's queue once every standing announcement on it has a verdict, so an announcement an intake reads later at the same tip is still asked about. This refines dcn-2610161949032458 (spc-2610150728396006 step 3, on review), which named only a branch the cap cut short and kept a tip an app pushed as asked until it moved.
Frontmatter
| id | dcn-2610162032446286 |
|---|---|
| type | decision |
| date | 2026-10-16 |
.abcd/work/decisions/dcn-2610162032446286-the-status-intake-splits-a-branch-s.md
open on GitHub ↗ · commit history ↗
mentions2
- 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