os-aidd-lint tier1 gap: ListItems drops hard-wrapped bullet continuations #144
Labels
No labels
P0
P1
P2
P3
bug
create
delete
enhancement
filed-by/agent
filed-by/user
frozen
lint-rule
needs-info
needs-triage
next
plugin/cc-architect
plugin/os
plugin/os-adr
plugin/os-aidd-lint
plugin/os-backlog
plugin/os-context
plugin/os-doc-hygiene
plugin/os-sdlc
plugin/os-vault
project/cc-os
ready-for-agent
ready-for-human
recurring
review
update
waiting
wayfinder:grilling
wayfinder:map
wayfinder:map
wayfinder:research
wayfinder:task
wayfinder:task
wontfix
worklist/deviations
worklist/lint-rule
worklist/new-implement-build
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
jared/cc-os#144
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Context
Found by
/os-aidd-lint:mine-blindspots(f7c52e1) on 2026-07-26 — causal bucket (a): "rule exists, logic gap" — tier-1 cop bug, not new rule.Summary
The
ListItemsparser only recognizes list markers on the physical line itself. A continuation line (hard-wrapped from the preceding item) has no marker and is never appended to the preceding item's text. Every cop built onListItemstherefore only sees the FIRST physical line of each bullet.Root cause
Code:
plugins/os-aidd-lint/lib/aidd_lint/list_items.rb:7MARKER = /\A(\s*)([-*+]|\d+\.)\s+(.+?)\s*\z/requires a list marker on the line. Wrapped continuations have no marker, don't match, and are never appended. Affected cops:TrailingProhibition,StepBulk'scheck_bullets.Observed missed instances
Fix direction
Fold continuation lines into the preceding item before cops consume it.
Caveat on the fix directions in this batch, 2026-07-26.
The code citations in #143-#147 were independently verified against source. The "fix direction" lines were NOT — they were written from reading the regexes, not from testing a fix. Treat them as starting points, not specifications. Specifically: the
hard-wrapcop fires on the same wrapped paragraphs these gaps involve (49 hits in os-doc-hygiene/skills/check/SKILL.md alone). If the house style is genuinely one-logical-line-per-paragraph, thenhard-wrapis the primary offense and several of #143-#147 are partly downstream of files violating it. That may change the sequencing — consider whether fixing hard-wrap compliance across the corpus reduces the surface of the other gaps before implementing per-cop joins.Same finding as #143: HardWrap's paragraph builder (hard_wrap.rb append_line/BLOCK_START) already folds bullet continuation lines into the bullet's paragraph and its autocorrect joins them onto one physical line. Confirmed live against os-backlog/skills/capture and route/SKILL.md — HardWrap fires on the cited wrapped bullets. Running corpus HardWrap autocorrect first removes today's observed ListItems misses. The ListItems.MARKER gap itself is still real for any file with a lettered/wrapped bullet before hard-wrap is applied — worth fixing, but land it together with #147 (same MARKER regex, same Item struct) rather than separately, since #147 widens the marker and #144 restructures how items are assembled; doing them apart risks rework.
Implemented via os-sdlc pipeline (test-writer -> red -> programmer -> green -> ac-lint -> lint -> reviewer APPROVE). Merged to main in
87f5779.