Development record
2026-10-12 — A build next series counts a pick whose lane waits for a person to merge its pull request as done and moves on, as the drain does, so both verbs read that lane state through one predicate (the product thinker's ruling on itd-2609211116005482 decision 4 and criterion 5; iss-2610111014218303).
decisiondcn-2610120000000005
2026-10-12 — A build next series counts a pick whose lane waits for a person to merge its pull request as done and moves on, as the drain does, so both verbs read that lane state through one predicate (the product thinker's ruling on itd-2609211116005482 decision 4 and criterion 5; iss-2610111014218303).
Frontmatter
| id | dcn-2610120000000005 |
|---|---|
| type | decision |
| date | 2026-10-12 |
.abcd/work/decisions/dcn-2610120000000005-a-build-next-series-counts-a-pick-whose.md
open on GitHub ↗ · commit history ↗
mentions2
- iss-2610111014218303Two verbs in the implement loop read one lane state differently: build next's series counts a pick delivered only when its run is Complete(), which a lane whose pull request is left open for a person to merge never reaches, so 'build next --until-empty' in such a repository makes one pick and then only says 'drive run X' until a person merges; the drain reads the same state as DrainLanePullRequest and moves on, because the merge is a person's gate. itd-2609211116005482 decision 4 calls the two flags shared with the drain, and criterion 5's 'its lane stops' does not say which reading is meant. Found by the build-next lane's ruthless review (run-2610110908001704).
- itd-2609211116005482`abcd build next` picks the readiest planned intent itself, and writes down why