Skip to content
SHAMPOO

Manual ยท Chapter 14 of 19

Diagnostics

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.
  • UNKNOWN is 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.

On this page