Diagnostics
Snapshot: memory_status
memory_status answers "is it alive and what
can I see" in one zero-write call: product and version, backend marker,
profile, caller, role, visibility (self or global), caller-filtered
counts, and the live tool totals. Broad-scope callers see global counts
with an explicit marker; everyone else sees exactly their own view. Call
it first when anything behaves oddly; it distinguishes "endpoint down"
from "nothing in my scope" in one round trip.
Deep check: doctor
doctor runs grouped diagnostic sections with typed
per-check results (id, status, severity, summary) across config,
database reachability, auth material presence and modes, jobs, pump
freshness, wake state, history retention, readiness, and invariants. The
sections argument filters by exact section name; detail selects
summary or full. Rules the output honours:
- Diagnostic-only: no repair, no mutation, no secret disclosure (presence and file modes only), no topology.
-
UNKNOWNis distinct from unhealthy: unknown means the check could not determine standing (e.g. pump freshness never observed), not that something failed. - Pump freshness is observed/stale/unknown and warn-only: a stale pump never fails the whole report, because delivery lag is operational, not structural.
Using the two together
memory_status for liveness and scope sanity on every session start;
doctor when onboarding a profile, after deployments and migrations, and
whenever behaviour diverges from the manual. Paste both outputs (they
contain no secrets) when asking an operator for help; they are designed
to be safe to share. For symptom-first guidance see
16-troubleshooting.