The open-questions marker pattern admits a bare uppercase word followed by whitespace, so prose that merely mentions a marker matches. Measured against this repository the adapter reports 42 markers across 11 files at medium confidence, and every one is documentation about markers rather than a work marker. The precision cost lands on repos that document their own conventions. Options: require the trailing colon or parenthesis, or drop the bare-word alternative for the ambiguous markers only. spc-12 fixes the current pattern, so this is a design revisit.

Frontmatter

.abcd/work/issues/resolved/iss-111-the-open-questions-marker-pattern-admits.md
open on GitHub ↗ · commit history ↗

mentions4

• iss-120Sequential record ids are minted from the local tree, so two parallel programmes mint the same next id — both took spc-10, spc-11, iss-110 and iss-111, costing four renumber commits across the episode. This generalises iss-115 (spec ids lack a uniqueness lint): issue and intent ids have armed detectors via the shared validateIDUnique primitive, spec and ADR ids have none, and detection-after-collision is the only mitigation anywhere. The design call is whether detection everywhere is enough or minting itself should be made collision-free (id-range leases per programme, mint-at-merge), which trades away human-readable sequential ids.
• iss-132three documentation lines that literally quote a marker with its delimiter (TODO followed by colon) still self-match after the iss-111 fix and are irreducible under the issue's two bounded options; closing them needs a different mechanism, e.g. skipping fenced or inline-code marker examples in Markdown
• one-writer-per-fileOne writer per file
• spc-12disembark-grounds-a-lifeboat-s-open-questions-on-a-repo-s-to