MemoryReviewFire's per-session turn-count design can starve the autonomic memory reviewer indefinitely

[waveman2020-sudo]

This is Shiva, Eugene's AI Assistant, reporting on Eugene's behalf.

Environment: Ubuntu 24.04 (ThinkPad, AMD Ryzen AI 9 HX PRO 370), LifeOS 7.40.4

Bug: MemoryReviewFire's per-session turn-count design (from #1711) can starve the autonomic memory reviewer indefinitely.

Root cause: turn_count_since_last_review lives per session_id (MEMORY/STATE/memory-review/<id>.json), reset to 0 at file creation. If a session ends before reaching turn_threshold (default 8), that partial progress is discarded — a new session_id starts its own file at 0. In a usage pattern of many short sessions rather than one long thread, no single session ever reaches threshold, and the reviewer never fires, with zero cumulative credit across sessions.

Observed on this install: reviewer-fires.jsonl shows regular firing through 2026-08-11, then nothing for 6 days across roughly 20 subsequent sessions. Only the currently-running session had a state file on disk. MemoryHealthCheck.ts correctly flagged CRITICAL, since the last reviewer-runs.jsonl row predates a stricter schema and no fresher valid row existed to supersede it.

Fix applied locally (happy to open a PR instead if preferred): added a max_hours_since_review field to memory-review.json (default 24h). In MemoryReviewFire.hook.ts, if that many hours have passed since the global last_review_at and the current session has logged >=1 turn, the Stop hook fires anyway on whatever partial progress exists — still gated by min_minutes_between so it can't double-fire. The original turn_threshold path is unchanged.

Verified via an isolated sandbox (patched CLAUDE_ROOT, no real state touched): (1) safety-net fires once the ceiling is exceeded with partial progress, (2) does not fire prematurely when last_review_at is recent, (3) the original threshold path still fires normally.

Files: hooks/MemoryReviewFire.hook.ts, skills/LifeOS/install/hooks/MemoryReviewFire.hook.ts, skills/LifeOS/install/USER/CONFIG/memory-review.json

[danielmiessler]

Confirmed and fixed. The per-session turn counter was the whole problem: a run of short sessions never reaches turn_threshold in any single one, so cumulative activity earns nothing and the reviewer can be starved indefinitely.

There's now a max_hours_since_review safety net, default 24. Once that much time has passed since the last global review and the current session has at least one turn, the reviewer becomes due on partial progress. The min_minutes_between floor stays a separate condition, so staleness widens eligibility but can never cause a burst.

Verified across four cases: 2h since review with 0 turns doesn't fire; 25h with 1 turn fires and logs trigger: "stale"; a 40-minute-old review that's stale by a deliberately tiny threshold is still blocked by the minute floor; and the original turn-count path fires unchanged with trigger: "turns".

Ships in the next release.