05-Apr-2026 — preserve camera markers and never silently drop new notes #219
release-notes: preserve camera markers and never silently drop new notes (#219, #576, #213)
Two independent bugs in the automated release-notes workflow, fixed together.
- Camera 📸 markers stripped from the index on every rewrite.
The entry line regex in content-generator.ts did not allow any trailing
content after the markdown link's closing paren, so index entries with a
trailing 📸 marker (used to flag release notes with embedded images)
failed parseIndexLine, returned null, and were silently dropped from the
re-serialised list on every build.
- Extend entryLineRegex to capture an optional trailing " 📸"
- Add hasCamera to IndexEntry; parseIndexLine records it and
formatIndexLine re-emits it
- updateIndexPageContent preserves the existing hasCamera when
re-adding an entry at the same key
- New regression tests in content-generator.spec.ts
- New release notes silently dropped when the target page already exists.
When a page already existed at the resolved path, generateReleaseNote
would skip creation entirely (to preserve manual edits like embedded
images) and do nothing else — the new commits had no release note
anywhere, and the index was rewritten with an entry still pointing at
the old, pre-edit page. Build #576 for commit 4b7e274f hit exactly
this: three new #213 commits left undocumented.
- When a collision is detected, write the new note at a distinct
build-specific path suffix (-build-, or -commit-
when no build number is available)
- Collision-proof the suffix with a recursive counter fallback
- Always create — never silently skip
- Skip removeLegacyReleasePages when we wrote to a suffixed path