Development record

2026-08-01 — iss-30 (v0.5.0 item C7), CORRECTION to the entry immediately above, and two production fixes: that entry closed the item as "test-only" and stated that "no production behaviour was found to diverge from its own documentation, which is why this increment adds no fix". That claim was false and is retracted here. Two independent fresh pre-PR reviews (correctness and security) each reproduced a real defect in `internal/core/memory/yaml.go`, both now fixed detector-first on the same branch. (1) `collectBlockScalar` set the block's indent from the first non-blank line WITHOUT requiring it to exceed the indent of the `key: |` line that opened the block. Since the function is only ever reached for a top-level key (`parseYAMLLines` refuses any other indent), a `|` with no indented body took the next COLUMN-0 line as content and went on consuming every line after it: the remaining keys — `domain`, `slug`, `source` — were absorbed into the value and no error was raised. An unindented first line now ends an EMPTY block and is left unconsumed for the top-level parse. (2) `dumpString` triggered its quoting on `\n` and `\t` but not `\r`, so a bare carriage return was emitted RAW into the YAML region, while `parseFrontmatter` normalises `\r` to `\n` before splitting lines — the writer and the reader disagreed about what a line is. A value carrying `\r---` therefore re-read as an early frontmatter terminator and every key below it fell into the page body; a distiller-supplied `recall` string was enough to make `Ingest` report success while writing a page that reads back with an EMPTY source block and no source hashes, which is exactly the state the reconcile/repair path treats as an orphan. `\r` now joins the quote trigger; `doubleQuote` already escaped it correctly, so only the trigger was missing. The lesson worth keeping is about detector siting rather than either bug: the earlier increment's `\r` cases DID pass, because they round-tripped through `parseScalar`/`parseFlowMap` directly and never crossed the `dumpFrontmatter` → `joinFileFrontmatter` → `parseFrontmatter` boundary where the invariant is actually stated (yaml.go:11-16) and where the defect lived. A round-trip test that does not use the real entry points tests the parser's internals, not the invariant; the new cases go through the file boundary and, for the CR case, through `Ingest` itself. Both detectors were watched fail before the fix and pass after. Consequently the increment is no longer test-only and DOES carry a CHANGELOG entry under Fixed — the second judgement call in the entry above ("no CHANGELOG entry: nothing user-facing changed") lapses with the claim it rested on.