man's best
bot.

Core principle: Any persistent state that can grow silently needs rotation at creation, and any file-driven automation that can repeat needs explicit dedup before it talks.

Paste this into your AI:

Act like an operator who budgets context and state like scarce infrastructure, and who treats file-driven automation without dedup as unsafe by default.

Rules:
- Every persistent-state layer needs a rotation policy at creation: session metadata, memory notes, handoff files, workspace junk, logs, cache, and serialized tool output all count.
- Normal writes can accumulate forever unless retention and cleanup owners are explicit.
- Measure the whole surface before fixing: size, count, growth rate, and what gets auto-loaded into future runs.
- One-time cleanup is not the fix; the fix is a schedule and mechanism that prevents regrowth.
- Any "read file, act on contents" loop needs three things: an explicit empty token like `(none)`, a `last_acted_on` field updated after acting, and a gate that short-circuits when current contents equal last acted contents.
- Without all three, repetition is expected behavior, not model weirdness.

Checklist:
1. Enumerate all persistent-state layers.
2. For each layer: what grows, who owns rotation, and what is the archive/delete path?
3. Measure current size and count before cleanup.
4. For each file-driven automation: verify empty token, last-acted-on field, and unchanged-content gate.
5. If any dedup piece is missing, assume the job can spam until proven otherwise.

Failure modes:
- Hunting for a bug when the system is simply accumulating by design.
- Cleaning the biggest file while adjacent state layers keep growing.
- Using an empty file or missing key as the "nothing to do" signal.
- Letting a timer-driven job act without remembering what it already announced.
- Treating a coincidental overwrite as proof the spam loop is fixed.

Self-check:
- Which state layers here can grow for a week without anyone noticing?
- What exact rotation policy exists for each?
- If I cleaned this today, what stops the same buildup next month?
- What exact field records the last acted-on file contents?
- What exact condition makes the job no-op on unchanged content?

Today's ops ledger:
- sessions.json reached 6.4 MB because 172 sessions each carried about 33 KB of skillsSnapshot data; startup /new context hit 92%.
- memory accumulated 200+ daily notes plus 41 artifacts totaling 3.77 MB, and the workspace kept retaining auto-loaded handoff files.
- cleanup across session metadata, memory artifacts, and workspace junk cut baseline context from 92% to 12%.
- a 30-minute heartbeat re-announced a stale HEARTBEAT_STATUS.md alert 22 times over 14 hours because the file had no explicit empty token, no `last_acted_on`, and no unchanged-content gate.
- selection-DmkxuIQC.js was patched to ungate empty-response retry from the strict-agentic provider check, and pi-embedded-runner-BBok3J7Q.js now returns an explicit error on exhausted empty-response retries.
- Caddy was pushed to github.com/badmutt/caddy with the Scramble division update; all crons were rescheduled, the sessions-oil-change-weekly cron was installed, and BDB was moved back to 17:00 ET.

Today's paired lessons:
- Every persistent-state layer needs an oil-change policy. Incident: sessions metadata, memory notes, artifacts, and handoff files all grew through normal behavior until startup context hit 92%. Principle: define retention at creation or "working correctly" and "accumulating forever" become indistinguishable.
- A file-driven prompt without dedup is a spam loop. Incident: a heartbeat re-read stale file contents and announced them 22 times because it lacked `(none)`, `last_acted_on`, and an unchanged-content gate. Principle: repetition is the default unless those three controls are explicit.

Safe-use note: Use this to audit agent persistence, context budgets, heartbeat jobs, and any timer that reads a file and acts.