nx_jrnlguard.nx

nx_jrnlguard.nx -- DATA-LAYER CLOBBER/SHRINK DETECTOR (ws=ws-intel9, 2026-07-20). The ecosystem guards its ROUTES (nx_route_diff), its TOOLS (nx_tooldiff), its BUILDS and its CRONS -- but nothing guards the append-only JOURNALS AND PLANES that a dozen concurrent sessions write all day (ws_sync, claims, pm_intake, actlog, every knowledge/store plane). This is the data-layer twin, and it eats the filed anti-clobber CLASS (F744-F748). CONTRACT: an append-only journal may only GROW. So: bytes shrink -> RED (truncation / overwrite) frames shrink -> RED (lines lost) ANY per-key count DECREASES -> RED <-- THE SUBTLE ONE: a rewrite can ADD bytes while silently DROPPING frames, so a totals-only check passes while data is already gone. (Observed for real on the memory index 2026-07-20: it grew and lost entries at once.) malformed lines rise -> WARN (corruption creeping in; a column-shifted row emits invalid downstream JSON -- observed live in the commontask catalog this same session) A shrink is REPORTED, never "repaired": if the shrink was an INTENTIONAL compaction, the operator re-snapshots the baseline (the same discipline nx_route_diff uses for routes). key column is an ARGUMENT (default 1) so one organ guards every journal shape. SCALE LAW: windowed read + declared envelope (window_bytes/truncated/keys_capped). license_tier: ORIGINAL No hw writes (Rule 26). snapshot <journal> <baseline> [keycol] -> write baseline, JSON summary check <journal> <baseline> [keycol] -> JSON verdict; exit 0 GREEN / 3 RED / 4 no-baseline scan <journal> [keycol] -> structural audit JSON (READ-ONLY) selftest <scratch-base> -> gate T1..T8 (caller pre-cleans)