robustify-doctorlisted

# Robustify Doctor ## Overview Most agent monitoring answers "did the process exit 0?" That question misses the failure class that actually hurts: the job that ran, exited clean, and did nothing. The backup that failed 573 consecutive times while its launchd unit reported success. The seven scheduled jobs that had never executed once, two of which were health checks. This skill is deliberately split in two: 1. **`scripts/robustify_collect.py`** — deterministic, stdlib-only, no LLM, no network. It gathers facts and refuses to interpret them. Every collector is fail-soft: a broken collector reports its own failure rather than killing the run. It is read-only against everything it inspects, with **one deliberate exception**: it maintains its own small SQLite history at `$HERMES_HOME/robustify/disk_history.db` so it can report a disk _trajectory_ rather than a single instantaneous number. Rows older than 30 days are pruned each run. It never writes to any database it monitors. 2. **You** — you read the fact sheet and do the part a script cannot: correlate across subsystems, decide what is a real incident versus an artifact, and choose what to fix versus escalate. The split matters. A pure-threshold monitor produces alerts nobody trusts, because the interesting failures are the ones nobody wrote a threshold for. Judgment is the product; the script is an instrument. ## When to Use - A scheduled health check (see cadence below) - After a host reboot,