Development record
A build run serialises every lane on the previous lane merging into main. The ready rule for a lane's predecessors (the DR6b default needs, read with landedInRun as being an ancestor of the default branch) holds each step until the step before it has passed the merge queue, so a six-step spec spends roughly 20 to 25 hours in serial queue time at the preflight and merge-queue times seen on 2026-10-22, most of it waiting rather than building; the merge-gate build was the case that night.
issueresolvedminoriss-2610230016561927
A build run serialises every lane on the previous lane merging into main. The ready rule for a lane's predecessors (the DR6b default needs, read with landedInRun as being an ancestor of the default branch) holds each step until the step before it has passed the merge queue, so a six-step spec spends roughly 20 to 25 hours in serial queue time at the preflight and merge-queue times seen on 2026-10-22, most of it waiting rather than building; the merge-gate build was the case that night.
Grounds
- pursued: a spec whose steps declare what they truly need runs its independent steps in parallel, so a build stops spending most of its time waiting on serial merges; the coordinator ruled on 2026-10-23 (dcn-2610230857411093) to make the missing declaration visible where specs are written rather than guess dependencies from file overlap. Shown wrong if warned planners still leave needs undeclared, or if specs that declare them still queue serially.
Frontmatter
| id | iss-2610230016561927 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | minor |
.abcd/work/issues/resolved/iss-2610230016561927-a-build-run-serialises-every-lane-on-the.md
open on GitHub ↗ · commit history ↗
mentions2
- dcn-26102308574110932026-10-23 — Decided by the technical facilitator on delegation (coordinator ruling, 2026-10-23), on iss-2610230016561927 (a build run serialises every lane on the previous lane merging): the finding's cause is authoring, not code. A spec step's needs line is already honoured, and a step with none waits for every earlier step (ruling DR6b), but only 5 of 169 specs on the default branch declared any needs line, so nearly every run defaulted to fully serial. Remedy, in order: first, intent ready and the spec's record-lint warn on a spec of two or more steps with no needs line on any step, saying the steps run fully serial and naming the fix, and the planning page and interviewer ask for each step's needs; a warning, never a refusal. Second, stacked readiness (a dependent lane starting once its predecessor is reviewed and landed on the run's own branch) is captured as its own record and draft intent for planning, not built now. Rejected: a default derived from footprints, running a step with no needs line in parallel when its packages are disjoint from every earlier step's, because file overlap misses logical dependencies (step 3 calls a function step 2 adds, in another file) and a wrong parallel step costs more than a serial one. Backfilling needs lines on the open specs is captured separately.
- iss-2610230826159867A resolved issue's resolved_by.commit goes stale when the commit it names is rewritten before it reaches the default branch, and nothing follows it. On 2026-10-22/23 lane C re-stamped records by hand three times: twice after rebasing a stacked branch onto a moved parent, and once after re-wording an unpushed commit to drop a scoped prefix. Each time RS003 found the stamp unreachable and the ledger gate failed until the sha was edited by hand. Two designs are open and not chosen here. A lookup by patch-id follows a reworded or rebased unpushed commit to its new sha, but does not survive a squash merge, which already rewrites the cited commit out of existence and which RS003 reports. Stamping at land time instead (resolve names the change, the land step writes the merged sha) survives a squash but needs the land step to own the stamp.