chore(issues): file the autonomous run's failures as records

.abcd/work/decisions/dcn-2611101302520880-the-autonomous-run-of-7-nov-orders-its.md

@@ -0,0 +1,6 @@
+---
+id: dcn-2611101302520880
+slug: the-autonomous-run-of-7-nov-orders-its
+date: 2026-11-10
+---
+2026-11-10 — The autonomous run of 7 Nov orders its build lanes by one rule, tried as a candidate principle for abcd. This record is the public statement of the rule; the run folder's SCHEDULING.md is a working copy of it. The rule: priority work that shares files runs as one stacked chain, each step starting on the previous step's branch once both reviewers pass it; lower-priority work is either confined to the record folders (no test slot) or collected on one side branch per chain cycle that takes a single test run and pull request, started only when the slot is free just after a chain run passes; a side lane in the chain's way or in a third review round is parked. Grounds: the person asked on 10 Nov for a recorded way to fill spare capacity without slowing priority work; a plan review of the first draft showed from the run log that review rounds and the 65 to 95 minute wait to merge, not the test slot, hold the chain. Reverse by recording a new decision that returns the run to one lane per item.

.abcd/work/issues/open/iss-2609012020476120-four-test-sites-now-assert-elapsed-wall.md

@@ -32,3 +32,5 @@ Two records-only branches failed `make preflight` on wall-clock assertions alone
 - `TestTheForgeIsAskedAboutEveryBranchInTurn` and `TestPeersListsALanesStageAndItsHoldersRecentHandBacks`: running when their packages (claim, implement/loop, surface/cli) hit the 20-minute timeout.
 
 The load gate admits one preflight's test stage at a time, but tests run outside a preflight (a session's own `go test -run …`) are not gated, so an admitted stage still runs on a saturated machine.
+
+2026-11-09: met again at 19:25 in the autonomous run of 7 Nov: #1474 failed CI's race stage because two new tests bounded a linear read at 15 seconds; under sharded race on CI each took 15.0 to 15.5 seconds, against 0.14 seconds locally without race. Neither review pair nor the local preflight, whose race stage passed, caught it.

.abcd/work/issues/open/iss-2610230059199116-a-build-run-renders-each-lane-s-brief.md

@@ -13,3 +13,5 @@ remedy: "Render a lane's brief from the run's own checkout when its record diffe
 ---
 
 A build run renders each lane's brief from the intent and spec as they stand at the lane's base on the default branch, so a refinement recorded during the run (a narrowed footprint, a new requirement or test line on a later step, a decision citing the spec) never reaches the run's own later lanes until it is merged to the default branch by some other change. On 2026-10-23 the merge gate's run (run-2610222359421510, itd-2610150602547271) recorded step-4 security requirements and step-wise footprint decisions on the orchestrating branch; lanes 2-6 would have been briefed without them, and a separate records pull request had to be cut to carry them to main ahead of lane 2.
+
+2026-11-08: met again at 15:15 in the autonomous run of 7 Nov, on an issue lane: abcd build cut the lane from the default branch, not from the head of the run's checkout, so two decision records and a capture committed in the run's worktree, meant to land with the fix, were missing from the lane; the brief named no decision records for the issue, and the records commit was cherry-picked into the lane by hand.

.abcd/work/issues/open/iss-2610230839002949-an-intent-s-build-reserves-its-spec-s.md

@@ -13,3 +13,5 @@ remedy: "Make the reservation rule a per-repository setting with two values, as
 ---
 
 An intent's build reserves its spec's whole Footprint packages line once, for every lane of the run, and never reads a step's own packages line, so the reservation cannot start at the first step's files and widen step by step. Building that needs a reservation per open lane (the union of the steps in flight, since steps marked needs: none run beside each other), a widening act as each lane opens (a reserve with the union and the tip's term, as widenReservation already does, since claim.Request.Narrow refuses to widen), and a narrowing as each step lands. That is more than the directory-warning fix for iss-2610230016544142 could carry, so it is filed on its own.
+
+2026-11-09 and 2026-11-10: seen again in the autonomous run of 7 Nov. On 9 Nov at 08:27 a build of itd-2610240922461281 was refused at its reservation because the spec's footprint names the whole internal/core/implement/loop package and another holder had reserved one test file in it; by 12:27 that one-file hold, renewed twice at the same stage, had blocked the whole-package footprint for four hours, and the step's own files were reserved by hand instead. Later on 9 Nov two lanes of one run blocked each other because the checklist spec names the whole internal/surface/cli package, and one lane was narrowed to its step under a hand reservation. On 10 Nov at 12:23 a one-package step collided with lanes in other packages for the same reason.

.abcd/work/issues/open/iss-2610230856272073-a-dependent-build-lane-waits-for-its.md

@@ -14,3 +14,5 @@ related_intents: [itd-2610230856403803]
 ---
 
 A build run's dependent lane cannot start until its predecessor has merged into the default branch: readiness reads a predecessor as landed only when its lane is done, its pull request an ancestor of the default branch, so a step that needs another waits a whole preflight and merge-queue cycle (about one to two and a half hours each on 2026-10-22) before it opens. Stacked changes are standard practice for dependent work (Graphite, Sapling and ghstack stacks, and merge queues taking a stack in order), and on 2026-10-22/23 that shape was rolled by hand twice: merge-gate steps 2 and 3, and model-matrix step 2 stacked on the route branch. Building it is more than a fix: the dependent lane's pull request is based on the predecessor's branch, the stack merges in order, and a lane rebases (and re-stamps what it resolved) when the predecessor changes.
+
+2026-11-07 and 2026-11-08: seen again in the autonomous run of 7 Nov. At 19:41 on 7 Nov a two-step intent cost two preflights of two to five hours' wait each, and its second lane was cut from main rather than stacked on the first, though both edit the same file, so it had to merge main after the first landed. At 01:55 on 8 Nov a step could not be stacked on a lane held back until after a tag, so the spec's later steps waited for days; the only verb that closes a lane stuck off its reviewed head is --discard.

.abcd/work/issues/open/iss-2610280032429024-abcd-reserve-refuses-a-footprint-whose.md

@@ -13,3 +13,5 @@ remedy: "Let reserve derive the footprint from a branch diff and compact it to f
 ---
 
 abcd reserve refuses a footprint whose reservation message passes the 4096-byte cap, and takes only an explicit list of paths, so a large stacked build cannot name its whole diff: renewing the worktree store's reservation after a rebase with its 83 changed paths was refused at 4740 bytes, and the renewal had to fall back by hand to the store's original 50 paths, leaving the rebased-in paths unreserved.
+
+2026-11-08: seen again at 12:14 in the autonomous run of 7 Nov: reserve refused a lane's 65-path footprint because the reservation message came to 4160 bytes, and the lane collapsed internal/core/matrix to a directory, which the verb warned holds peers off 17 files the lane did not change.

.abcd/work/issues/open/iss-2610280910566850-an-intent-build-re-widens-its.md

@@ -13,3 +13,5 @@ remedy: "Reserve per lane: at each step the run reserves the open lanes' own pac
 ---
 
 An intent build re-widens its reservation to the spec's whole footprint at every step, instead of reserving only the packages of the lanes it has open. A spec footprint that names whole packages (or the whole of commands/) then overlaps peers' narrow file reservations, so the build's renewal at land is refused until the peer releases by hand, and a hand-narrowed reservation is widened again at the next step. Seen 26-28 Oct on run-2610252354599453: a peer's commands/land.md and commands/guard.md reservations blocked lane 1's renewal.
+
+2026-11-09: seen again in the autonomous run of 7 Nov: two lanes of the same run blocked each other through the spec-wide footprint, the checklist spec naming the whole internal/surface/cli package while one lane held one file in it, and build could not tell a holder from the same run from a peer's; the second lane was narrowed to its step under a hand reservation. iss-2610230839002949 lists the other sightings.

.abcd/work/issues/open/iss-2610311514162877-on-2026-10-31-abcd-build.md

@@ -13,3 +13,5 @@ remedy: "Teach the safe backup in the SHELL hazard registry: before git rebase,
 ---
 
 On 2026-10-31 abcd build itd-2610170638184486 was refused at the peers check by backup/sota-open-intents-pre-rebase, a local branch an agent made as a safety copy before rebasing research/sota-open-intents onto main; it held the intent's old drafts/ copy, while main and the rebased branch held it in planned/. The peers check reads every local branch under refs/heads/ (internal/core/peers/read.go) and cannot tell a safety copy from live work, and the guard then refused the branch's deletion (git-delete-unproven) because a rebase that squashed and resolved conflicts leaves no ancestry or patch-equivalence for it to prove, so the build stayed blocked until the person allowed the delete by hand. abcd teaches no safe form of the backup: a tag, or a ref outside refs/heads/, would have kept the copy and blocked nothing.
+
+2026-11-10: a related case at 12:23 in the autonomous run of 7 Nov: build's peers check gave a stale unpushed branch, whose only edit was to a superseded drafts copy of the intent, the weight of a live hold. Showing the hold's age and whether it is on origin, and flagging a copy in a status folder the record has since left, would have told it apart. It still counted after a2a584caf, which stops a branch checked out nowhere from holding a record, because this branch was checked out in a live worktree of its own, which the check counts by design.

.abcd/work/issues/open/iss-2610312044511316-in-facilitator-mode-auto-the-landing-s.md

@@ -17,3 +17,5 @@ In facilitator.mode auto the landing's merge gate waits for a review receipt nam
 Seen again on 2026-11-01: three build lanes under facilitator.mode auto (PRs #1313, #1314 and #1315) each stopped at their land stage with the records commit as head and no review receipt naming it, and each armed only after a second review pair over that one-line delta was recorded by hand with land --record-review; an unattended run stalls at every such lane. The closing lane, whose records commit also closes the spec, ingests the audit and adds Delivers:, and any lane that resolves a capture, carry model-composed text no reviewer read, so they stay on the hand path.
 
 Bounds a security review on 2026-11-01 set for a self-minted receipt, which covers only a mark-only lane: the commit's own diff against its parent is exactly one modified path, the open spec, with exactly one added '- landed:' line on the lane's step and nothing else added, removed, renamed or re-moded (decided from that diff, never from the lane's state flags, and catching anything swept in by git add -A or a hook); require exactly one parent, equal to the full validated sha in the lane's state, with the landed line's value a prefix of it; apply the same check to a records commit found after a killed call; and have the receipt cite the validated head's passing review pair, written only when that evidence exists.
+
+2026-11-07: a related case at 19:33 in the autonomous run of 7 Nov: a lane passed four reviewers, then the land stage made its own one-line commit marking the spec step landed and sent the lane back to validate for a second round of up to four reviewers on that line. A records commit the landing composes from its own facts could ride on the review that already passed.

.abcd/work/issues/open/iss-2611011155419019-abcd-land-announces-merging-id-for-every.md

@@ -13,3 +13,5 @@ remedy: "Announce merging only for items named in Resolves: or Delivers: trailer
 ---
 
 abcd land announces 'merging <id>' for every issue or intent a branch's commits name in a Refs: trailer, as well as Resolves: and Delivers: (internal/core/landing/announce.go, per dcn-2610170704191129). Refs: means the change touches a record without fixing it, but the announcement reads as that record's work merging. On 2026-10-31 a peer session read a build session's records-PR announcements for Refs-only issues as competing work on those issues, and the two sessions spent a round of messages confirming nobody else was on them. A colleague reading abcd status cannot tell a fix that is merging from a record that is merely cited.
+
+2026-11-07: seen again at 21:35 in the autonomous run of 7 Nov: land announced merging for two issues that the lane's commit named only under Refs and left unbuilt, and peers read it as those issues merging.

.abcd/work/issues/open/iss-2611011943357182-the-implement-loop-s-land-stage-refuses.md

@@ -15,3 +15,5 @@ remedy: "Have the land stage first check whether its landing head, or a descenda
 The implement loop's land stage refuses a lane whose branch has moved past the loop's own records commit, and offers no path for a reviewed follow-up. On 2026-11-01, lane 2 of run-2610312053537139 passed validation round 2. The land stage then wrote its records commit (0030dea82), and a reviewer's note then had to be fixed before the change merged. That fix went on top as two commits, with its own preflight and a delta review pair (SHIP and APPROVE). implement step then refused: the branch is at 764bc6a8dcc3, not at the head 0030dea82032 the landing lands, so restore the branch to that head. Following that remedy would have thrown the reviewed fix away. The lane was pushed and its pull request (#1333) opened by hand with abcd land and gh pr create, outside the run's record. The run's landing state (body_checked, armed) no longer describes the pull request.
 
 The refusal outlives the merge. #1333 merged at 21:28 with both 0030dea82 and 764bc6a8d on origin/main. implement step still refused at land, saying the branch is at 764bc6a8dcc3, not at the head 0030dea82032 the landing lands. Moving the local branch back to 0030dea82, as that remedy asks, produced a second refusal: waiting for its full check, because no preflight receipt names the lane's head 0030dea82032. So recognising an already-merged lane would have cost a full preflight of a records commit, one to two hours on the loaded machine. The preflight was not run, and run-2610312053537139's record stays at land while its work is on main.
+
+2026-11-08: seen again several times in the autonomous run of 7 Nov. At 00:23 and 00:31 a lane 39 commits behind main could not have main merged in by hand before precheck, because the push step refuses a branch moved off its reviewed head (internal/core/implement/loop/land.go). At 00:45 and 11:54 precheck at land failed an audit after every review round had passed, and with no move from land back to a fix round each fix went outside the loop, through a hand review pair, a preflight and a plain abcd land. At 13:55 three faults found after validation left a lane at land off its judged head. A correction logged at 06:13: the land stage does merge main into the lane itself and send the merged head back to validate, so the gap stands for a branch moved by hand after validation.

.abcd/work/issues/open/iss-2611022247147314-a-merge-queue-drop-is-silent-in-abcd.md

@@ -13,3 +13,5 @@ remedy: "Have land (bare, on the branch) and peers name a pull request that left
 ---
 
 A merge-queue drop is silent in abcd: #1347 left the queue twice on 2026-11-02, once when its merge-group macOS job was cancelled and once on a flaky test, and neither land, peers nor status said the entry had left or why; the coordinator learned it only by polling the forge and reading the run's jobs.
+
+2026-11-08: seen again at 09:56 in the autonomous run of 7 Nov: when #1465 merged ahead of it, the merge queue dropped #1466 once as unmergeable, though the two share no file, and nothing in abcd said so; it was re-armed by hand.

.abcd/work/issues/open/iss-2611030744325032-a-loop-run-whose-lane-was-landed-outside.md

@@ -15,3 +15,5 @@ remedy: "Have the land stage accept a lane whose pull request merged with a head
 A loop run whose lane was landed outside the loop can never be finished: run-2611030127507347's lane merged as #1367 at 85ed321d2 after a hand landing, and implement step now refuses on every call because the branch is not at the records commit 0c466ccb1 the landing pinned, with a remedy to restore the branch, which would rewind a merged branch. Nothing else ends the run, so it keeps its lane worktree (prune keeps it as held by the run) and held its reservation until it was released by hand. iss-2610142233473049 covers the unmerged case.
 
 2026-11-04: the same hold from a run left at its land stage. run-2611031131030791 kept its reservation on whole directories (internal/surface/cli and internal/core/implement/loop) until 15:08 on 2026-11-04, about fourteen hours after its pull request merged, with nothing running, and two cloud sessions worked around it.
+
+2026-11-09: seen again three times in the autonomous run of 7 Nov. At 07:20 and 11:15 build opened a run for an issue that the lane then worked by hand, leaving the run unstepped; at 09:50 run-2611090624263180 still read as in progress, driven by the host, after its issue's fix had merged. No verb closes or abandons a run whose record is already resolved.

.abcd/work/issues/open/iss-2611031146244351-abcd-land-opens-no-pull-request-for-a.md

@@ -13,3 +13,5 @@ remedy: "Have land open the pull request from the body it composed when none is
 ---
 
 abcd land opens no pull request for a branch made outside the build loop: it composes the body, pushes, and stops with 'no open pull request ... open it with the command, then run abcd land again'. On 2026-11-03 the coordinator opened eight pull requests that way by hand (gh pr create from the composed body, a re-read for footers, then land --record-review twice and land again to arm), in a helper script, so a CLI-only run cannot land a hand fix without a forge command of its own.
+
+2026-11-09: seen again in the autonomous run of 7 Nov: land --record-review recorded the receipt and exited, a second land pushed, and a third armed only after the pull request had been opened by hand, so one landing took three land calls and a hand-opened pull request.

.abcd/work/issues/open/iss-2611031146255825-no-abcd-verb-drives-an-intent-build-to.md

@@ -14,3 +14,5 @@ related_intents: [itd-2611031342011261]
 ---
 
 No abcd verb drives an intent build to done unattended: implement step takes one stage and exits, so a build of several steps needs something outside abcd to re-run it after each stage, wait out the merge queue, step again once the lane's pull request merges, and open the next lane. On 2026-11-03 the coordinator did this with a polling helper script (drive-run.sh) and timed wake-ups; drain --drive (itd-2610222215485265) covers drain lanes only, and itd-2610240933025076 starts a build but does not carry it through.
+
+2026-11-06: met again before the autonomous run of 7 Nov: with no route that drives a build walled (drain --drive covers drain lanes only), the run's coordinating session ran under a recorded exception.

.abcd/work/issues/open/iss-2611032348360959-a-spec-footprint-naming-a-whole.md

@@ -13,3 +13,5 @@ remedy: "Reserve each lane by its own step's paths rather than the whole spec's
 ---
 
 A spec footprint naming a whole directory collides with a peer holding one file in it: run-2611031640393520's footprint has internal/core/lint, a cloud session holds internal/core/lint/prosecitations.go, and the run's renewal is refused although the lane changes none of that session's files.
+
+2026-11-09: seen again on 9 Nov at 08:27 and 12:27 in the autonomous run of 7 Nov: a spec footprint naming the whole internal/core/implement/loop package was refused because another holder had reserved one test file in it, and the step's own files were reserved by hand instead; on 10 Nov at 12:23 the same collision stopped a one-package step. iss-2610230839002949 lists the other sightings.

.abcd/work/issues/open/iss-2611051719381143-an-armed-pull-request-blocked-or-dropped.md

@@ -13,3 +13,5 @@ remedy: "The status board names an armed pull request whose required check faile
 ---
 
 An armed pull request whose required check failed before it reached the queue stays armed and blocked. `abcd land` names the failed check only when it is run again, and the status board never does, so nothing says so between land runs and a queue watch sees an empty queue either way. This is the part before the queue. A drop from the queue is iss-2611022247147314, and retrying a drop that is not the pull request's own fault is iss-2610110401224302.
+
+2026-11-09: seen again at 18:53 in the autonomous run of 7 Nov: the required external-review check failed to start on #1473 and on #1474 (startup_failure, no jobs, no change to main's workflows), and both sat armed and not queued while land reported them armed; it was noticed an hour later, only by comparing main's required checks with those the pull requests reported. #1474's run re-ran clean; a startup failure cannot be re-run, so #1473 was closed and reopened and land re-armed it, restarting every check, about 45 minutes lost.