Development record
The implement loop's merged check (internal/core/implement/loop/land.go, landMerged) asks the forge twice per poll while a pull request is not merged: `gh pr view --json state`, then prMergeability's `gh pr view --json mergeable,mergeStateStatus`. Both fields come from one view, so each poll spends two forge calls where one would answer, against the same rate limit the loop's other waits share.
issueopennitpickiss-2610120138028442
The implement loop's merged check (internal/core/implement/loop/land.go, landMerged) asks the forge twice per poll while a pull request is not merged: gh pr view --json state, then prMergeability's gh pr view --json mergeable,mergeStateStatus. Both fields come from one view, so each poll spends two forge calls where one would answer, against the same rate limit the loop's other waits share.
Frontmatter
| id | iss-2610120138028442 |
|---|---|
| type | issue |
| lifecycle | open |
| severity | nitpick |
.abcd/work/issues/open/iss-2610120138028442-the-implement-loop-s-merged-check.md
open on GitHub ↗ · commit history ↗
mentions5
- dcn-26102223565326382026-10-22 — The merge gate's footprint is step-wise (abcd-ae's ruling as coordinator of 2026-10-23, spc-2610161609350616, itd-2610150602547271, following the worktree store's dcn-2610222227336378): the build reserves at start only the files steps 1-3, 5 and 6 change, leaving out internal/core/implement/loop/land.go and its test, which only step 4 changes and which the drain's reservation of iss-2610120138028442 holds while that lane waits for its preflight, and internal/surface/cli/cli.go, which only step 2 changes and which iss-2610171110154902 and iss-2610171200535090 hold until 2026-10-23T08:40Z; when the step that changes a left-out file begins, the spec's packages line widens to name it and a re-run of abcd build reserves the widened footprint (the verb reserves again when the spec has widened, per commands/build.md), judged for overlap like any reservation. Steps 4 and 6 still land as one change. <!-- record-lint: forward-looking -->
- iss-2610222000271964abcd drain run from a plain terminal stops at its first move: it reserves the first eligible issue, writes a host-judgement request, and waits for an agent session to answer it, so a person who types abcd drain in a terminal gets no fixes (seen 2026-10-22 20:47 BST on a second machine: 213 eligible, 0 lanes opened, iss-2610120138028442 reserved for 2h and left). The person wants abcd drain to work from the plain terminal by launching claude sessions itself to judge each remedy and drive each lane.
- iss-2610222359046244abcd build (and abcd reserve) refuses a reservation by naming only the first footprint path that overlaps a live reservation, so a build whose footprint collides with several reservations is refused once per collision: on 2026-10-22/23 the merge gate's build (itd-2610150602547271) was refused in turn on internal/core/implement/loop/land.go (iss-2610120138028442), internal/surface/cli/cli.go (iss-2610171110154902; a second reservation, for an issue filed on the unmerged fix/autonomous-permission-ask-denied branch, held it too, unnamed) and internal/core/landing/config.go (iss-2610222014550692, a directory footprint), each discovered only after the previous one was routed round. <!-- record-lint: forward-looking -->
- iss-2610230651407493While a lane's landing is held by another copy's release reservation (rel-vX.Y.Z), every implement step pushes a fresh renewal of the lane's reservation to origin, whatever its age: on 2026-10-23 the branch abcd-reserved/iss-2610120138028442 took five renewal commits between 06:02:43Z and 06:02:57Z and one per later step, each for two hours. commands/build.md says a renewal is pushed only once half the lease has passed, and that the land fence, when it holds, renews for a day; neither holds on the release-hold path, so a lane held for a day writes dozens of commits to the reservation branch.
- iss-2610231004140527The live-reservation cap is counted per GitHub login across every session, copy and account that pushes under it (internal/core/claim/crowd.go), while each machine sets its own ceiling in reservation.max_live. On 2026-10-23 six interactive sessions on one login reached 30 live holds and abcd-43's reserve was refused at 10:40; abcd-ae raised the ceiling to 40 by hand, the third raise since 10-22 (hand-rolled coordination log, 10:40 and 10:41). A drain run under another account that pushes with the same login is counted against the same holder under its own, possibly lower, ceiling, which no session here can read, so the interactive sessions can hold the drain at its cap with nothing on either side saying so. Graded minor when filed, because the drain waits at the cap rather than failing (iss-2610161015371794), and whether the drain shares this login and at what ceiling is not yet confirmed; it was confirmed the same day, and the grade raised (below). This revisits the ruling recorded in iss-2610170717515674 (one ceiling per person, raised in the machine's configuration); related: iss-2610160925028248 (one reservation per record spends the cap) and iss-2610161457209287 (holds do not name their copy).