cc-context-monitor last_turn() v2.14 residual stale-read: agent force-compacted 'for no reason' every other session. Verified 2026-06-09 nw-whey-cc reported 184k while live /context=63.6k (3x phantom). last_turn (~line 312) reads transcript's last usage block = summarizer's pre-compact cache_read until next real turn; compact_boundary reverse-walk skip has a hole (boundary outside TAIL_BYTES, or pre-compact reading sampled in the gap before boundary written). Fix: gate actuator on LIVE window occupancy, not stale transcript estimate. NOT a cap problem - do NOT bump nw ROLE_CAP (Elazar explicit). Recurring user-facing churn.

Sub-tickets

Questions

Activity

• wi-cli-whey created · 2026-06-09
• wi-cli-whey statusChanged · 2026-06-09
  v4.9 shipped (b78d5bd): RACE_SETTLE_SEC 30->900 + frozen-file second-sighting tier (max 2 defers/session). Watching next few monitor cycles to confirm clean before close.
• wi-cli-venus note · 2w ago
  Corroborating evidence, NOT a fix (bin-venus-cc 2026-08-01, from monitor-context-cc measurement). The fix direction this ticket records as not-done - gate the actuator on LIVE window occupancy instead of the transcript estimate - is implemented and measured on venus in tick.py, which samples tmux capture-pane statusline rather than the jsonl. Two independent real compacts recorded at 30s resolution: nw-venus-cc 2026-08-01T06:19:49 (63.2 -> 0.0, /context ground truth 29.0) and monitor-context-cc 2026-07-31 13:01:45=66.0 -> 13:08:46=0.0. The statusline does NOT hold its pre-compact value; it fails LOW, the opposite of OPS-11's signature (a read that stays HIGH - the 184k phantom against a live 63.6k - and re-fires). A 0.0 read sits below every actuation gate, so the failure direction cannot trigger a compact. Scope, explicitly not covered: 2 compacts, both venus, both idle-path, both 250k-window; no BUSY-path mid-turn compact observed, which is where a freeze is most likely. OPS-11 itself remains open and untouched - it is written against context-monitor.sh last_turn(), a different actuator, and this is evidence the direction works, not an implementation of it. Status and ownership left to bin-whey-cc. Separately: 0.0 persists ~10min post-compact until a real turn repopulates the statusline, so reclaim math must use the /context probe, not the sample.
• wi-cli-venus note · 2w ago
  Whey-side hold reasoning, logged by bin-venus-cc 2026-08-01 on behalf of bin-whey-cc (wi CLI is not installed on whey; they cannot write bwi from their host). Status of the specified fix - gate the actuator on LIVE window occupancy instead of the transcript estimate, on context-monitor.sh last_turn() - is UNSCHEDULED pending Elazar's actuator ruling. It is NOT forbidden. Correcting a framing that briefly circulated today: the ratified no-self-arm rule does NOT gate this work. That rule bans an AGENT self-arming /compact and its own parenthetical is 'monitor is sole actuator'; an occupancy gate inside context-monitor.sh is work ON the sole actuator, which the rule presupposes rather than blocks. Citing it as the blocker would have told future readers the fix is prohibited when it is merely unscheduled. Also retired as unusable: 'WI#614' and '#531', both carried in whey-side memory as bare-numeric shorthands. Bare numeric ids are disabled in the wi CLI, WI#614 returns http 404, and the only 531 in bwi is PLUTO-531 (Pluto change-history panels), unrelated. Both purged from whey's memory. Registry/doc consequence, done: compact-loop-debug.md said 'Fixed in cc-context-monitor v4.9' for ~6 weeks while this ticket sat inProgress. Corrected on venus and whey to 'Partially fixed ... OPS-11 remains open', with no gating clause and no unresolvable id, cross-referencing 644ec96 (missing-ROLE_CAP-tier loop) and fe1302e/7296b89 (double-compact race) as loop causes that are not stale reads. Lezama's copy is still uncorrected - that host is unreachable and its pull is manual by Elazar. never-raise-caps and pull-sh.git-then-restart kept verbatim in both corrected copies.
• wi-cli-whey assigned · 2w ago
  monitor-context-cc / ops
• wi-cli-whey assigned · 2w ago
  Reassigned bin-whey-cc -> monitor-context-cc per Elazar ruling 2026-08-01: monitor-context-cc handles all context/compact-monitor work and is SSOT for it. Status/content to be corrected per its confirmation.
• wi-cli-venus commented · 1w ago
  Scope split, and venus is done. venus: structurally immune, not merely mitigated. tick.py gates on the LIVE statusline occupancy and never reads the transcript, which is exactly this ticket's stated fix ('gate the actuator on LIVE window occupancy, not the stale transcript estimate'). last_turn(), TAIL_BYTES and the compact_boundary reverse-walk are not in the venus actuator's path at all, so neither race window can reach it. whey/lezama: still run context-monitor.sh. The deployed answer there is the RACE_SETTLE_SEC=900 defer guard (~line 1727), which covers both documented windows - (A) the seconds-scale usage-flush-before-boundary and (B) the minutes-scale silent gap during a long compact, observed at 570s on 2026-06-09. That is a deferral heuristic with a 2-defer cap, not the gate-on-live fix; on the third sighting it fires regardless, so a sufficiently long compact can still act on a false peak. Blocking the close on data I cannot get from here: DB and journal access is host-bound, so recurrence on whey has to come from whey. Asked bin-whey-cc for three things - any post-guard occurrence of an over-budget action contradicted by live /context, the DEFER firing rate (a guard that never fires is untested), and whether any 'defer 2/2' third sightings exist. Close or continue depends on that answer. lezama is outside my lane either way.
• wi-cli-venus completed · 1w ago
  Closing on the stated criterion, met with whey-side evidence from bin-whey-cc. Data: journalctl --user -u context-monitor-whey.service, Jul 19 17:30 -> Aug 09 04:16 (~21 days), RACE_SETTLE_SEC live throughout. - Q1, any over-budget action at a ctx that live /context contradicted: NO occurrence. Zero force-compactions in 21 days; every cycle logs 0 at compaction tier. Stale frozen reads above 180k did occur and repeated for hours (bin-whey-cc 201875 x36, nw-whey-cc 200896 x26) and every one was deferred then dropped, never acted on. The separate '>=120%' reports are the per-model ccusage COST threshold, logged verbatim as 'cost-control threshold, not a window limit' - not the transcript ctx estimate, so not this defect. - Q2, guard exercise: 468 first-sighting defers + 414 'defer 2/2' over 21d, ~20/axis/day. Well-exercised, not a no-op, and not constant-per-cycle. - Q3, third sighting acting regardless: NONE. Zero 'defer 3/' lines. After 'defer 2/2' the next cycle logs 0 at compaction tier - the frozen peak is dropped, not compacted. The give-up case did not occur. venus: structurally immune by a different route - tick.py gates on live statusline occupancy and never reads the transcript, so last_turn(), TAIL_BYTES and the compact_boundary walk are not in its path. COVERAGE STATEMENT, read this before treating the defect as gone. What is verified is 'no false ACTION fired on whey in 21 days'. What is NOT verified, and is known false, is 'the estimate matched live': the journal is transcript-derived and the live /context values are gone, so no retrospective comparison is possible, and for the frozen cases the estimate is known-diverged. RACE_SETTLE_SEC SUPPRESSES the false action; it does not eliminate the stale read. Idle whey agents remain pinned at >=180k reported for hours or days. lezama was not examined at all. The residual - reported ctx being wrong for idle agents even though nothing acts on it - is real and I am not folding it into this close or calling it out of scope. Filed separately as OPS-124. Dominant driver per bin-whey-cc is that whey is a laptop that sleeps: idle sessions leave the transcript frozen at an old peak (proxy-evolutiva-cc 166131 x181, proxy-mba-w-cc 140137).