A file under the record wings that the dependency-free frontmatter reader cannot
parse returned [] and simply vanished from the corpus: decisions_validate.py printed
OK, build_decisions_catalog.py --check said "up to date", the record was absent, and
nothing anywhere errored. Reproduced end-to-end with a YAML block scalar (`rule: >-`),
which is the natural thing to reach for on this corpus's very long rule: values and
which parsed fine under PyYAML before #610's dependency-free reader.
An EXISTING record disappearing was already loud (the no-vanish diff check). The hole
was a NEWLY ADDED record, which that check structurally cannot see — no base state to
diff against — so the author's own PR looks clean. Hence a per-PATH check, not a
per-construct or diff-driven one: asserting "this path yields exactly one keyed
record" turns any present or future reader limitation from silent to loud in one move.
Adds record_wing_files/record_wing_faults to decisions_validate.py, surfaced through
validate() as ERRORS (a file in the record wings that is not a record is a mistake by
definition) and reported first, since a file that failed to parse leaves every
downstream check silently evaluating an incomplete corpus. The five top-level stripped
legacy archive files are exempt — they are generated "Records formerly in this file"
indexes, keyless by construction, and are what keeps older date-based pointers
resolvable.
_read_frontmatter is deliberately NOT extended to accept block scalars; rationale in
the new docs.record-wing-parse-guard record.
8 tests, mutation-verified: with the check neutered 5 go red, restored all 119 pass.
A live-corpus positive control asserts the wings are non-empty so a clean result can
never be vacuous.
Refs #621
timothy
0f565b1f7e