#458 ·
agent-opsmemory-budget over-budget warning: route shared-file footprint breaches to project PM with escalation chain
- Ref
#458(#458)- Project
agent-ops- Status
- backlog
- Priority
- high
- Type
- feature
- Assigned
- bin-whey-cc coder
- Created by
- —
- Created
- 2026-05-21T22:05:43.418Z
- Updated
- 2026-05-22T05:50:57.882Z
Questions
-
Timeout X for the memory-budget escalation chain (PM warning -> DM Elazar). Proposed starting value: same project's shared-file over-budget warning recurs across 3 consecutive agent sessions (or ~24h) without footprint dropping. Confirm or adjust.answer: Elazar 2026-05-22: no numeric timeout. Escalation chain = agent -> project PM; if nothing happens on the action (e.g. brainstorm X) then DM Elazar in chat-duo. PM-first, human-DM as fallback.
Event log
-
wi cli
-
assigned to bin-whey-cc
-
Scope (Elazar greenlit 2026-05-21, relayed via nw-venus-cc): Problem: when an agent's auto-loaded footprint exceeds the §15 budget (8K) AND the cause is SHARED auto-loaded files (CLAUDE.md chain / project commons), the over-budget warning lands only in the agent's own context. It has no effective recipient - the agent cannot edit shared files. Fix: route that warning to the project's PM (owner of the commons / CLAUDE.md). Escalation chain (Elazar verbatim): warning -> project PM -> if unaddressed after timeout X -> DM Elazar in chat-duo. OPEN BRAINSTORM ITEM: timeout X. Proposed starting value to confirm with Elazar: the same project's shared-file over-budget warning recurs across 3 consecutive agent sessions (or ~24h) without the footprint dropping. Notes: 1. memory-lint-suite adjacent - cc-memlint-hook.sh surfaces the §15 line. Implementer likely bin-whey-cc/bin-venus-cc. PM-routing mechanism TBD. 2. The escalation DM to Elazar MUST use a sanctioned kind (ask) so WI 454 item 8 reroute does not bounce it. Sibling to the WI 454 resilience family; separate domain (memory budget, not roster).
-
q#31 to=elazar: Timeout X for the memory-budget escalation chain (PM warning -> DM Elazar). Proposed starting value: same project's shared-file over-budget warning recurs across 3 consecutive agent sessions (or ~24h)
-
q#31: Elazar 2026-05-22: no numeric timeout. Escalation chain = agent -> project PM; if nothing happens on the action (e.g. brainstorm X) then DM Elazar in chat-duo. PM-first, human-DM as fallback.
-
WI 458 escalation chain — FINAL SPEC (Elazar ruled 2026-05-22): agent -> project PM -> DM Elazar -> email Elazar if no acknowledgement. No separate numeric timeout; gate each tier-advance on the existing 15-min cc-context-monitor poll cadence (a tier escalates if the warning still recurs on the next poll with no ack). EMAIL-TRANSPORT BLOCKER: email tier cannot ship fleet-wide yet. whey: AVAILABLE — msmtp 1.8.28 + /etc/msmtprc + ~/.local/bin/notify-elazar.sh. venus: NO mail sender configured. lezama: unconfirmed. bin-whey-cc should code the DM tier now and stub the email tier behind a transport-available check (e.g. notify-elazar.sh present + msmtp config resolvable) so it activates per-host only where transport exists.
-
WI 458 email transport — SUPERSEDES the prior per-host transport-available note (Elazar directive 2026-05-22 via nw-venus-cc): whey is the fleet email relay. Do NOT install a mail sender on venus or lezama. The email tier sends via whey's existing msmtp + ~/.local/bin/notify-elazar.sh. venus/lezama agents needing to email Elazar route the send through whey. DESIGN CHANGE for bin-whey-cc: the email tier is a SINGLE whey-side transport call, not a per-host transport-available check. From any host, the email escalation is a remote invocation of whey's notify-elazar.sh (or equivalent whey relay endpoint). Drop the per-host stub; code one whey-relay path.