2026-09-25 — The build's open-question check reads the record's own settled convention and stays fail-closed (lane implementer, autonomous run A, fix round 1 of the loop lane, on iss-2609252053576085; the lane's first ruling, that every list item under `## Open Questions` is a question whatever it says, lived only in its report and refused intents the record had settled). `intent.OpenQuestions` recognises exactly two markers, learned from the 12 planned intents that carry list items there. A section whose first non-blank line is an italic `_All resolved …_`, with at most one count word (`_All four resolved …_`), is settled whole (itd-111, itd-93); `_All but one resolved_` is not. An item explicitly marked resolved or deferred is not a question: a bold span opening with the word (`**Resolved — …**`, `**Deferred**`, `**Deferred to a follow-up intent**`, `**explicitly deferred**`, `**explicit deferral**`) or the word as a label (`resolved:`, `RESOLVED:`, `Deferred:`), anywhere in the item including its continuation lines. Everything else stays a question: an item led `**Open` whatever it goes on to say (itd-60's "Open, and not gating scope"), an item that only points to another record (itd-76's "travel with itd-126"), `**Out of scope …**`, and a question that merely mentions deferral. With the rule, itd-111 and itd-93 pass the check; itd-7, itd-60, itd-65, itd-66, itd-76, itd-82, itd-117, itd-131, itd-2609170822093401 and itd-2609211116005482 still refuse, each on an item the record does not mark settled. Relabelling those items is the product thinker's call through the planning interview, not the loop's.

Frontmatter

.abcd/work/decisions/dcn-2609250000000028-the-build-s-open-question-check-reads.md
open on GitHub ↗ · commit history ↗

mentions14

• iss-2609252053576085The build's open_questions check (intent.OpenQuestions, read by internal/core/implement/loop/check.go) counts every list item under '## Open Questions' as a question whatever it says, so it refuses records that follow the record's own settled convention: 12 of 50 planned intents carry list items there, and some are settled by their own words, itd-111's section opening '_All resolved or explicitly deferred at planning_' and itd-93's '_All four resolved_', itd-76's item marked '**explicitly deferred**', itd-60's items marked '**Resolved', itd-117's '**Deferred**' items. 'abcd build next' (itd-2609211116005482) would meet refusals nobody planned, and the ruling lives only in a lane report. Keep the check fail-closed, but read the markers the record actually uses.
• itd-7Lifeboats Carry RepoPrompt Workspace Definitions Forward
• itd-60When A Surface Ships, The Brief Describes It — Or The Intent Does Not Reach Shipped
• itd-65abcd Refuses To Publish A Payload Until The Full Ship-Time Pre-Flight Gate Suite Passes, Not Just The Secret Scan
• itd-66abcd Renders The Exact Public Payload, Proves The Excludes Never Leak, And Smoke-Tests The Installed Surface Before Any Snapshot
• itd-76abcd Lets You Consult Sources You Cannot Cite — and Remembers Every Debt
• itd-82`abcd drain` fixes the issues that need no decision, and hands the rest back by kind
• itd-93abcd Scaffolds a Release Gate That Works on the First Try
• itd-111A Stale abcd Never Answers Silently
• itd-117A Machine's Shared Conventions Are Declared Once In The User Scope — And Every Managed Repo Inherits Them
• itd-126A Team Shares One Bibliography Without Sharing Anyone's Corpus
• itd-131The managed-repo identity gate: the human is the author of record on every commit, before the first one
• itd-2609170822093401abcd proposes the model each agent deserves, and facilitates it where it can
• itd-2609211116005482`abcd build next` picks the readiest planned intent itself, and writes down why