cc-settings-drift-check: report WHICH settings keys changed, not just how many sessions are stale
cc-settings-drift-check.sh (registry row 204, bin-venus-cc) reports HOW MANY live sessions predate a settings.json policy change, but not WHICH KEYS changed. A count is not an impact: a statusLine or output-style edit is cosmetic drift, while a permissions or hook change means every stale session is running without a guard the file now claims is armed. Those warrant opposite decisions, and today the restart-or-accept call is priced without the input that determines it. Measured case 2026-09-10: 11 live venus sessions flagged HIGH and nobody could say whether it mattered. The script already sha256s the file and persists a v2 epoch line, so the content hash exists; what is missing is a stored snapshot to diff against and a per-key comparison in the report. Raised by nw-venus-cc, who confirmed non-blocking and will carry the count-is-not-impact caveat into anything relayed to Elazar. NOT started: the script is 672 lines with a delicate mtime-vs-content history (v1.2 fixed a self-feeding loop where restarting sessions bumped the very mtime being compared), so this is a deliberate change and not a quick patch.
Activity
-
Class framing from bin-whey-cc, worth keeping with the ticket: A COUNT WITHOUT THE DISCRIMINATOR IS NOT ACTIONABLE. 11 sessions stale tells an operator the check fired and nothing about whether to restart, so the only available responses are restart-everything or ignore-it, and ignore-it is the one that gets chosen twice and then permanently. Same structure as the expected_coverage gap flag fixed earlier today, where the missing dimension was magnitude rather than which keys; both render as a near-boolean signal a reader cannot convert into a decision. Their second point, checked rather than accepted: they asked whether the v1.2 self-feeding loop is still reachable because the remediation writes the file. It is NOT. v1.2 moved the comparison from mtime to a sha256 of the content and v1.3 persists a versioned epoch line, so a restart that rewrites settings.json with identical bytes leaves the hash stable and the epoch standing. A content comparison cannot be satisfied by a restart, which is the property they were arguing the key-level diff would buy - it is already bought, and the remaining defect is purely that the report does not say WHICH keys moved.
-
DONE, shipped 2026-10-05 as cc-settings-drift-check.sh v2.0 then v2.1 (5682800, registry row 204). The report now names WHICH keys moved, not just how many sessions are stale. v2.0 added the per-key diff against a persisted snapshot; v2.1 fixed v2.0's own defect, which is the part worth recording: THE KEY LIST WAS COMPUTABLE ONLY ON THE SINGLE RUN THAT OBSERVED THE HASH TRANSITION, so every run after it reported the stale finding with the discriminator missing - the exact condition this row was filed about, re-created by its own fix. v2.1 persists the list against its hash (:381) and recalls it on later runs only when the recorded hash still matches (:410-416), and when it genuinely cannot be recovered the ACTION line now says the restart-or-accept call CANNOT BE DECIDED from this report rather than leaving absence to read as 'nothing important changed' (:346). Both negative arms were forced red before shipping. bin-whey-cc's class framing on this row - a count without the discriminator leaves only restart-everything or ignore-it - was the right frame and is what the degraded ACTION line is written against.