nx_sov_guard2.nx

nx_sov_guard2.nx -- the NO-NEW-TSV law with a WORKING TOOTH (eats seq279 at the root). WHY A REWRITE, NOT A PATCH (rule 3): v1 scanned exactly ONE directory and defaulted to `knowledge/status`, so `knowledge/registry` -- which holds ~150 .tsv including the 3 this session created -- was NEVER SCANNED. The law existed, the organ existed, the allowlist existed, and none of it could fire on the directory that mattered. A guard that cannot see the violation is not a guard. TWO STRUCTURAL FIXES: 1. MULTI-DIR, DATA-DRIVEN scan-set. Dirs come from the native plane knowledge/store/sovguard- (`dir<TAB>path` rows) -- rule 11, and pointedly NOT from a .tsv (the anti-tsv guard configuring itself with a tsv would be the joke that writes itself). If the plane is absent the organ still guards using a compiled-in default set and DECLARES `config:default-set` -- fail-SAFE, because a guard that silently stops guarding is worse than one that guards loudly with defaults. 2. RATCHET, not a cliff. ~150 legacy files exist; a plain count>0 rule would be RED forever and get ignored (an alarm nobody can silence is an alarm nobody hears). Instead we compare against a recorded BASELINE and fail ONLY when the count RISES -- which is exactly what "no NEW tsv" means. Legacy shrinks lane by lane; a new file trips it the same day. Same snapshot/check idiom as nx_tooldiff / nx_route_diff. nx_sov_guard2 check -> GREEN if count <= baseline; RED (exit 1) naming the NEW files if it rose nx_sov_guard2 snapshot -> deliberately re-record the baseline (after a migration lands) Emits knowledge/status/sov_guard.log with a VERDICT line for the reliability plane. license_tier: ORIGINAL expect_exit: 0