Development record
The implement loop titles a lane's pull request from its issue's title; when that title names another record id, RS004 refuses the PR because no Refs line declares it (PR #865 named iss-2609261536147903 from its issue's title; fixed by hand by editing the body).
The implement loop titles a lane's pull request from its issue's title; when that title names another record id, RS004 refuses the PR because no Refs line declares it (PR #865 named iss-2609261536147903 from its issue's title; fixed by hand by editing the body).
Evidence 2026-10-11
A second occurrence: PR #947 (run-2610111820413440, iss-2610110359273529) quoted its issue's first line, which names iss-2610092011131598, into both the title and the body. The attribution job's RS004 step refused both ("the pull-request title names iss-2610092011131598 without declaring its relation to it", and the same for the body). It was fixed by hand: a Refs: iss-2610092011131598 line added to the body, which clears the title mention too. Every lane whose issue text names another record will hit this until the landing writes the declarations itself.
Evidence 2026-10-31
A third occurrence, on an intent lane this time. PR #1301 (run-2610310228179894, lane-1 of itd-2609201916151817) was opened with the title build(itd-2609201916151817): …, step 11 of spc-2609202134338445. land.go's title composer (about line 662) writes that shape for every intent lane. It breaks the title rule: a commit or pull-request title takes a conventional prefix with no scope (the COMMITTING rules, .github/CONTRIBUTING.md). The ids in it broke no rule: RS004 judges iss- ids only, and accepts a mention a Refs: line in the body declares. The title was rewritten by hand with gh pr edit to feat: plan a draft unattended with build --auto-plan.
Evidence 2026-11-02
#1344, the landing of spc-2610142146250176's step 1 (run-2611012152474713), was titled from its step title, which names an issue: "… emits no Cloudflare files (resolves iss-2610142036270003), step 1 of spc-2610142146250176". The lane's receipt named no resolves, so the body carried no Resolves: or Refs: line for that issue, and the build session added a Refs: line to the body by hand before the pull request reached its record gate.
Frontmatter
| id | iss-2610080546203039 |
|---|---|
| type | issue |
| lifecycle | open |
| severity | minor |
.abcd/work/issues/open/iss-2610080546203039-the-implement-loop-titles-a-lane-s-pull.md
open on GitHub ↗ · commit history ↗
mentions7
- iss-2609261536147903Planned intents and disciplines still cite specs of the retired predecessor store unqualified, and such an id at or below spc-70 resolves to a live spec on another subject (spc-12, for one, is live as the disembark grounding spec): itd-48, itd-50 and itd-53 name spc-12, spc-28, spc-29, spc-31, spc-33, spc-43 and spc-52 for the fidelity reviewer, lifecycle hook and cleanup work (which of these are predecessor ids is itself the reading this record owes); itd-24 names spc-66 as the phase-audit receipt; itd-1 and itd-37 name spc-12 as the manual reviewer. The specs charter (Two spc-N Namespaces) rules that every predecessor citation carries the '(predecessor store)' qualifier; iss-239 applied it to the draft corpus only. Each site needs a reading to tell a predecessor citation from a live one, which is why the sweep was not folded into iss-239.
- iss-2610092011131598TestSurpriseRefusesAnUnresolvedOccasion failed in the merge queue on 2026-10-09 (PR #880, macOS race lane, run 37980092117) with 'duplicate issue id: srp-2610092000060599 already exists in this ledger; the mint collided with a record already committed': the test mints three surprise records in quick succession, two drew the same timestamp-plus-four-digit id within one second, and the allocator refuses a collision instead of drawing again, so a records-only pull request was dropped from the queue.
- iss-2610110359273529After the drain lane for iss-2610092011131598 lands, the surprise, admission, disposition and reframe records redraw a minted id only when it clashes with a record this same process wrote, and still refuse a clash with any other existing record. The issue and reading-item allocators redraw on any clash (spc-33 ruling 2). Both of that lane's reviewers noted the split. The retained refusal guards against overwriting, which a redraw never does, so it protects nothing a redraw would endanger, and it can still fail a same-second mint against a peer's committed record.
- iss-2610142036270003On the github-pages hosting provider the site loses the security headers abcd's own site serves: the build copies site-src/headers to _headers, which Cloudflare reads and GitHub Pages ignores, so a project site on GitHub Pages is served without the Content-Security-Policy and the other headers that file declares.
- itd-2609201916151817One verb takes a READY intent to delivered, and refuses while a decision is open
- spc-2609202134338445one-verb-takes-a-single-intent-from-ready-to-delivered-witho
- spc-2610142146250176abcd-s-own-development-record-is-built