noyalib-validation-and-qalisted

# noyalib Validation & QA The evidence bar. A PR that "looks right" is not merged; a PR that proves a behaviour with a test that would have failed on the previous tree is. This skill fences that discipline into checklists. - Audience: mid-level engineer or Sonnet-class model. - Scope: pure-Rust YAML library `noyalib` v0.0.14, test harness and conformance suites. - Not this skill: - Running / interpreting the tools → `noyalib-diagnostics-and-tooling`. - The 95 → 98 coverage push specifically → `noyalib-coverage-campaign`. - Chronicle of settled fights → `noyalib-failure-archaeology`. - Date-stamped: 2026-07-07. > **Reference material** (full 130-file test taxonomy, the official > YAML Test Suite mechanics + bench-fixture inventory, and the > read-only provenance one-liners): see `reference.md` in this > directory. This file keeps the evidence bar, the add-a-test > checklists, the acceptance thresholds, and what does NOT count. --- ## 1. The evidence bar (non-negotiable) **A fix is proven by a test that FAILS on the pre-fix tree.** The discipline is: write the regression test first, watch it fail (`cargo test <name>` red), then fix, then watch green. `CONTRIBUTING.md` lines 47–48 codify the rule: *"Add or update tests in the same commit / PR as the behaviour change. Never as a follow-up."* There is one caveat driven by the [CI-always-green invariant] captured in `MEMORY.md`: **red tests never get PUSHED alone.** The red→green transition happens locally. What land