Files
hyperguild/ingestion/internal/api
mathiasandClaude Sonnet 5 695e90257a
CI / Lint / Test / Vet (pull_request) Successful in 41s
CI / Mirror to GitHub (pull_request) Skipped
fix(api): frontmatter parser must not misparse indented list items as keys
hyperguild#128, filed while fixing the same bug class in the sibling
internal/wiki package's parseFrontmatterBlock (hyperguild#126 review
round 3). This package was the original parseFrontmatter/set()/render()
shape that reimplementation was modeled on, and had the same gap: an
indented YAML block-list item containing a colon (e.g. a title with a
subtitle inside an aliases: list) got cut at the colon and treated as a
fake top-level key, since strings.Cut doesn't know a line is a
continuation just because TrimSpace(key) happens to be non-empty.
Re-rendering then stripped the item's indentation, de-indenting it out
of the list it belongs to. This package backs UpdateNote/writeHallNote,
so it's on the live brain_update write path.

Fixed the same way as the wiki package: check indentation before
calling Cut at all -- a line starting with a space or tab is a
continuation, full stop, regardless of what it contains.

Second, related bug found via the fix's own test fixture, not
speculatively: render() wrote "key: " (trailing space) for a key with
an empty value (the same "aliases:" block-list header line) instead of
bare "key:" -- a different byte sequence than the original, breaking
this type's whole documented purpose (a byte-preserving line view, not
a YAML re-marshal). No current caller sets an empty-value key via
set(), so this hadn't shown up in a set()-driven path, but it fires on
every ordinary parse-then-render round-trip of a note that already has
one -- confirmed directly via this fix's own test output before writing
a fix for it.

Flip-tested both independently: disabling either fix turns its
corresponding test red, the other stays green.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-23 10:10:10 +02:00
..