Skip to content

fix(cli): refuse to write a container that would lose a broken task - #12

Merged
grinev merged 1 commit into
grinev:mainfrom
dim-s:pr/frontmatter-guard
Aug 26, 2026
Merged

grinev merged 1 commit into
grinev:mainfrom
dim-s:pr/frontmatter-guard

Conversation

@dim-s

@dim-s dim-s commented Aug 26, 2026

Copy link
Copy Markdown
Contributor

Summary

A task whose frontmatter fails to parse never enters the container's tasks array (see parser.ts). Serializing and writing that container back to disk therefore silently drops the block — the task is gone and nothing indicates it.

This guards every write path in persistence.ts (writeContainer, writeContainers, and the rename path used e.g. when a release is renamed) against the collected parse problems for that file, and refuses to write with a new UNREADABLE_FRONTMATTER error naming the offending file, instead of writing silently.

Test plan

  • Added coverage in packages/cli/src/persistence.test.ts for the new guard on all three write paths
  • Added coverage in packages/cli/src/app.test.ts for the CLI-level behavior (refuse + error surfaced, message names the file)
  • Full @grinev/boardown-cli test suite passes on top of current main (194/194)

A task whose frontmatter does not parse never enters the container's
tasks array, so serializing that container writes the file back without
it — the block is gone and nothing said so. Guard every write path
(writeContainer, writeContainers, the rename path) against the parse
problems collected for that file and fail with UNREADABLE_FRONTMATTER
instead, naming the file so it can be fixed by hand.
@grinev
grinev merged commit 5af6cd6 into grinev:main Aug 26, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants