Development record
The status block's next-up head can name a READY intent abcd build next would not pick. The head is read in the pick order and passes over a held intent and one in a lane, but build next's candidates also pass every other pre-start check (open questions, the claim sections, blocked_by, the spec's steps, the peers), which the block does not run: a READY intent with an open question or an unshipped blocker, and the highest score, is marked next up on the board and the site while build next excludes it. statusblock cannot import the loop (loop imports peers, peers capture, capture site), so the fix hands the pick's candidate set in from the front doors the way the lane reader is, at the cost of a peers read on every bare board.
The status block's next-up head can name a READY intent abcd build next would not pick. The head is read in the pick order and passes over a held intent and one in a lane, but build next's candidates also pass every other pre-start check (open questions, the claim sections, blocked_by, the spec's steps, the peers), which the block does not run: a READY intent with an open question or an unshipped blocker, and the highest score, is marked next up on the board and the site while build next excludes it. statusblock cannot import the loop (loop imports peers, peers capture, capture site), so the fix hands the pick's candidate set in from the front doors the way the lane reader is, at the cost of a peers read on every bare board.
The remedy is split. Of build next's extra checks, open questions, the claim sections, blocked_by and the spec's steps are record-only reads and need no peers read: they are fixed by one shared statement of the record-only checks both front doors call, so the head excludes exactly what the pick excludes for them. Only the peers check needs a peers read, and whether the bare board pays one is ruling CC1, owed to the technical facilitator; until it is ruled the block's documentation states that the head does not consult other checkouts.
Grounds
- pursued: we expect the head to equal build next's pick whenever no peer holds anything; shown wrong if a READY intent with an open question, an unanswered claim section, an unshipped blocker or no step left is marked next up
Frontmatter
| id | iss-2609291803334904 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | minor |
.abcd/work/issues/resolved/iss-2609291803334904-the-status-block-s-next-up-head-can-name.md
open on GitHub ↗ · commit history ↗
mentions2
- dcn-26100200000000052026-10-02 — Ruling CC1 of the person as technical facilitator (2026-09-29, same interview and local-tier file as the DR3 entry above; recorded by lane rd2), verbatim: "board 'next up' vs peers: DO THE CHECK (the board pays the peers read so 'next up' always equals the pick)." Built: the status block's head takes the peers check build next runs (`loop.StatusPeers` in `internal/core/implement/loop/loop.go`, `internal/core/statusblock`), read once and only when a head is in reach, so the head is always the intent the pick would choose; the brief's surface chapter `04-surfaces/08-abcd.md` states it. The record-only half of the same finding is iss-2609291803334904.
- itd-2609212103568351The status board shows Now, Next and Later, computed from the record