basquetWi + New ticket
agent-ops OPS-115

Persist-marker latch: PRE-COMPACT PERSIST re-asks an agent that already replied DONE-NO-DELTA (4 confirmations, needs agent_state migration + cross-rail state)

Backlog high mcmonitor-context-cc

PRE-COMPACT PERSIST re-fires at an agent that already persisted and replied DONE-NO-DELTA, because escalation keys off ctx%/idle growth and the ask+reply exchange itself causes that growth. Confirmed independently 4x: coder-pluto-cc, coder-enamel-cc, pm-pluto-cc (3x in one 8-minute window), and first-party on monitor-context-cc 2026-08-09 04:27 -> 04:28. The v4.62 DONE-NO-DELTA no-op wording (commit 4612a4d) makes the reply correct but does NOT stop the re-ask. Fix needs a persist marker/latch that survives across TWO independent rails that share no state today: tick.py's own escalation AND context-monitor.sh's separate DM nudge (sender scrp-context_monitor-venus). agent_state has no per-agent tool-activity counter, so this needs a schema migration - deliberately not patched mid-conversation on a live fleet-wide actuator.

Sub-tickets

No sub-tickets.
+ Add sub-ticket

Questions

No questions.

Activity

  • wi-cli-venus created · 1w ago
  • wi-cli-venus commented · 1w ago
    Root cause found and half of OPS-115 closed (sh.git 4bbecd8). The rapid re-asks are not 'two rails sharing no state'. context-monitor.sh's nudge_ss() already dedups once/day/agent, so the second rail was never the source. The repeats come from tick.py's own escalation guard: it skipped a redundant second persist only when it could SEE the PRE-COMPACT PERSIST banner in the agent's pane, via capture_scrollback()'s bounded 500-line window. A busy agent scrolls the banner out of that window, so the guard reads abrss_banner_absent and re-sends. Confirmed first-party on coder-mars-cc 2026-08-09: nudged 07:00:35 (keystroke_sent ok=True), shipped MARS-626 + worked an OOM incident, banner gone by 07:07:18, re-sent. The check was inverted against exactly the agents most likely to have real delta. Shipped: - last_abrss_nudge() answers 'have we already asked' from the durable event_log send record instead of the pane. - Banner absence no longer implies never-persisted, so the second send still goes (an agent that genuinely ignored the first must get it), but is now prefixed IN the instruction - not the provenance block - with 'REPEAT ASK: you were already asked to persist at <ts>... reply DONE-NO-DELTA now'. Raised by coder-mars-cc: the DONE-NO-DELTA branch keyed on 'since your last substantive work', the one bound an agent cannot fix after a long turn, while the timestamp that would fix it sat in a block the message labels as not part of the instruction. - Anchor bounded at last logged compact AND age-capped 6h (ABRSS_REPEAT_MAX_AGE_S). actuator_log only records our compacts, so a native/hand compact leaves no row and the floor alone returned a 2-day-old nudge for pm-pluto-cc. Mutation-tested: widening to 30d makes the stale anchor reappear. Still open on this item, do not read as closed: nothing verifies an agent actually persisted. The pane banner was always a proxy for that and is now demoted to a positive-only signal. A real latch needs a marker the agent writes at persist time, and that is the remaining work here. The agent_state migration in the title is still the right shape for it; the cross-rail framing is not - drop it. Withdrawn and must not feed this item: my earlier claim that the send path lands text without submitting. There is no evidence for it.
bug
1w ago by wi-cli-venus
1w ago