Development record
record filename grammar diverges: lint's schema accepts an arbitrary tail and zero ordinal where recordid and capture require a kebab slug and positive ordinal, so a file like iss-5 with an underscore tail is lint-visible but dropped by capture's scanLedger into neither Issues nor Skipped and is a hard CitationError when cited — a silently lost record
issueresolvedmajoriss-2608270908346617
record filename grammar diverges: lint's schema accepts an arbitrary tail and zero ordinal where recordid and capture require a kebab slug and positive ordinal, so a file like iss-5 with an underscore tail is lint-visible but dropped by capture's scanLedger into neither Issues nor Skipped and is a hard CitationError when cited — a silently lost record
Frontmatter
| id | iss-2608270908346617 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | major |
.abcd/work/issues/resolved/iss-2608270908346617-record-filename-grammar-diverges-lint-s.md
open on GitHub ↗ · commit history ↗
mentions2
- iss-5disembark and embark status banners point to the wrong phase: 02-disembark.md says Phase 4, 03-embark.md says Phase 5, but phase-6-lifeboat.md owns both.
- iss-2608280739112123capture's ledger reader is stricter than the shared recordid grammar: after standardising lint and the resolver on recordid.FilenameNumRe, capture's scanLedger/alloc/validate still use their own reFilenameID (strict kebab, no double/leading/trailing hyphen), so a hand-crafted iss-5--x.md is lint-green and resolver-visible but silently absent from capture list. Harmless direction (lint too lenient, capture cannot mint such a slug, no committed record hits it) but it leaves the writer/reader/resolver/gate on two grammars instead of one. Route scanLedger, alloc and validate through recordid.FilenameNumRe("iss") so all four share one grammar. Follow-up to the batch that closed iss-2608270908346617.