The replay that judges every precision fix now runs daily, prints in report and status, and raises its own regression finding

[opencdlee-dotcom]

Step S8 (Phase 4) of the precision plan: the operator sees the number the precision fixes are judged on, and a regression raises a finding without anyone asking.

What changed

• Cached snapshot. _precision_measure runs _backtest_replay(30, reobserve=True) and reduces the dict it already returns (no text scraping) to noise_reopened/noise_total, interrupts (findings the replay routes to interrupt), open_cases, assay_routable_interrupting/_total, assay_predicate_passing/_total, and teaching_evaporation. Rule 17: the replay's own problems travel with the snapshot, and the assay statuses have to partition the lanes. It writes precision.json under STATE_DIR, with the path resolved when it is called. It only reads the store.
• Teaching evaporation. This counts signal incidents opened in the window whose _incident_identity (or the exact correlation key, when the identity can't generalize) matches an incident that got a benign-positive/false-positive dismissals row earlier. Incidents the machine closed in the same pass that opened them (auto-tolerated, learning-period, allowlisted) are teaching that held, so they don't count. It matches on identity only because _finding_classes isn't on this base; it lands with S6.
• When it runs. In cmd_scan after the scan lock is released, under its own .precision.lock (_scan_lock now takes a name), which no scan contends on. A scan started during the replay runs normally. It runs at most once per 24 h, using the same cadence rule as _integrity_scan_due, and checks again whether it is due once it holds the lock. A failed attempt gets a timestamp, so it's retried the next day and not on every tick. Any exception costs the snapshot and one run-log line, never the scan. Setting PRECISION_SNAPSHOT_EVERY_SECS <= 0 turns off the scan path; conftest pins it to 0 so ordinary scan tests never run a replay.
• It checks its own inputs (rule 17). Before the replay, _ledger_rows_rejected counts the in-window custody/intent ledger rows that don't verify under the HMAC key on disk. It asks the way the lookups ask, and never mints a key. The count goes into precision.json (hmac_key, ledger_rows_rejected), and the line starts with inputs unverified: N ledger rows rejected. Why: a copy of ~/.aegis without hmac.key read 143/214 noise re-opened, 165 interrupts and 167 open cases; the same copy with the real key read 127/214, 130 and 132. The earlier line printed both with the same confidence.
• Regression alarms. check_precision is registered in gather_all next to check_assay. It compares the snapshot with its stored baseline, which is the previous snapshot. If the number of routable lanes that interrupt, or predicate lanes that pass, drops at all, it raises a HIGH self-protection finding, "A detector positive control stopped firing", which interrupts. If noise_reopened or teaching evaporation rises by 3 or more, it raises a MEDIUM "Precision regressed", which goes to the digest. Both are built with finding(). A first snapshot raises nothing.
• Where it shows. report (every rendering) and status print Precision (30d replay, <age>): a/b judged-noise would re-alert · n interrupts · assay x/y routable + p/q predicate · teaching evaporation e.
• aegis.py precision [--refresh]. It prints the cached line, the open-case count, the baseline and any regression against it. --refresh measures now.

Not in this PR

• The plan's weekly-digest lines. This step only covered report and status.
• Matching evaporation by class. That needs _finding_classes from S6.
• Recall alarms compare against the previous snapshot, as the step specifies. A drop that persists raises its incident once; the next snapshot does not raise it again, and the incident stays open until someone closes it or it ages out. self:precision:* isn't a state-fingerprint prefix, so the cleared-state closer doesn't resolve it.
• In watch mode, re-observed signature verdicts stay in the in-memory sigcache and are flushed by the next scan. They are the same verdicts a scan would compute.
• Watch mode still has a daily gap. Other scanners no longer contend on the lock, but the replay runs inside the cmd_watch process (52–129 s live). For that long the watch loop can't arm kqueue or start an event scan. A change in that window is caught by the next full scan, and the 600 s floor is counted from when the last full scan started, so the replay doesn't push it back. Closing the gap means running the replay in a child process. That is platform-shaped: in install scan mode, launchd and systemd kill children when the job exits. Left for review.
• The live custody ledger has 2 rows (2026-09-19T07:45:48, homebrew package-managed) that don't verify under the live key. On this Mac the line will read inputs unverified: 2 ledger rows rejected until they age out (180 d). This PR does not touch the live ledger.

🤖 Generated with Claude Code