perf: avoid full replay rescans by folding policy_stats_live deltas into snapshot refreshes #12
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
During Issue #11 verification we fixed snapshot consistency by rebuilding each snapshot from the full replay buffer and keeping live increments in
policy_stats_live.json. This is correct but it will not scale well as replay grows. We should add a delta-based refresh path that can fold fresh live counters into the last published snapshot, keep exact replay rebuilds as a periodic compaction path, and expose when the system is using exact rebuilds vs delta refreshes.Implemented and live-verified delta-based snapshot refresh.
policy_stats_live.jsonis now treated as deltas anchored to the current manifest snapshot id;refresh-policy-snapshotusesdelta_mergewhen the live delta snapshot id matches the published snapshot and falls back tofull_rebuildotherwise. After publishing, live deltas are reset and re-anchored to the new snapshot id. Live verification showed: first refreshfull_rebuild, one fresh outcome, second refreshdelta_merge, live deltas reset to zero on publish, and the sacred gate still promoted with100/100/0while reporting a pinnedpolicy_snapshot_id.