Development record
record-lint frontmatterOpen and frontmatter.Fields anchor on line 0 and TrimSpace does not strip a UTF-8 BOM, so a BOM-led or multi-line-comment-led record yields an empty field map and slips the no_git_metadata blocker and the record_schema id/supersession gates entirely
issueresolvedmajoriss-2608220134344680
record-lint frontmatterOpen and frontmatter.Fields anchor on line 0 and TrimSpace does not strip a UTF-8 BOM, so a BOM-led or multi-line-comment-led record yields an empty field map and slips the no_git_metadata blocker and the record_schema id/supersession gates entirely
Frontmatter
| id | iss-2608220134344680 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | major |
.abcd/work/issues/resolved/iss-2608220134344680-frontmatter-bom-multiline-comment.md
open on GitHub ↗ · commit history ↗
mentions2
- dcn-26082200000000012026-08-22 — Bug-hunt round 7, branch bughunt-b/round-7. Baseline (make preflight
- iss-2608221126066379frontmatter.Fields trims a leading UTF-8 BOM (iss-2608220134344680) but the sibling parsers that promise byte-exact parity with it do not: intent's setFrontmatterFields (internal/core/intent/intent.go:129, whose comment claims it matches frontmatter.Fields's delimiter tolerance exactly) refuses a BOM-led record the reader accepts, so intent mutations on such a record fail-closed with 'no leading frontmatter block'; changelog's bodyStart (internal/core/changelog/source.go:60, 'so the two never disagree') returns 0 and leaks the whole frontmatter block into the derived changelog body; lint's recordTitle (internal/core/lint/schema.go:554) hand-rolls the comment skip with neither TrimBOM nor the multi-line-comment state. Sweep the siblings onto the shared tolerance or narrow the parity comments to the truth.