doctor

Work in this order and stop at the first thing that is broken. Each step costs more than the one before it, and the cheap steps answer most questions.

1. Read the local status marker at status/<run_id>.json under the plugin data dir (MUBIT_CC_DATA_DIR, else CLAUDE_PLUGIN_DATA, else the liveliest ~/.claude/plugins/data/mubit-memory* directory — the host adds a suffix naming the install source, so the bare mubit-memory is usually the one directory nothing writes to; prefer ${CLAUDE_PLUGIN_DATA}, which the host substitutes into this file for you). Free, no network. It carries the last known state, updated_at, recall counts, captured counts including pending, the last reflect result, and last_error. A marker whose captured.pending keeps growing is a drain problem, not a recall problem. A marker whose recall.dry_streak keeps growing is the reverse: recall is running and returning nothing. Check this before step 3 — it is the one fault that leaves state: ready and a healthy-looking line, so every other check below will come back clean while the model receives no memory at all. Read recall.empty_reason for which kind:

   • policy_denied — the instance has direct-access recall (rung 1) disabled, and the agent_routed fallback is off by default because it costs an LLM call per prompt. Ask the operator to enable direct search. MUBIT_CC_RECALL_FALLBACK=agent_routed restores recall at that cost; MUBIT_CC_POLICY_TTL_MS=1 re-probes immediately once it is on.
   • budget_exhausted — recall ran out of time before the call returned. Raise MUBIT_CC_RECALL_BUDGET_MS, and note it cannot usefully exceed the hook timeout.
   • breaker_open — recall is not being attempted at all; the connection is the problem, so continue to step 3.
   • no_evidence with a long streak — the connection and policy are fine and the store genuinely has nothing for these prompts. Go to step 4.

   Read reflect.status the same way. It is written by exactly two processes, and each value means one thing:

   reflect.status	Written by	What it means
   ""	nobody — the marker's own default	session-end never got as far as handing the flush over. The hook did not run, or was killed before its first act.
   handoff	the session-end hook, before it does any work	The hook started and was killed before it could either hand the flush over or fall back to running it inline. This is the value to expect when the host cancels SessionEnd inside its ~1 s window, and it is what keeps "" above meaning only "never ran". Still reading this minutes later means that session's flush was lost — the next session's first drain picks the captures back up, but its reflection is gone.
   detached	the session-end hook, just before it spawns	The flush was handed to a background process and no child has reported since. Momentary at the end of a session; still reading this minutes later means the child was reaped before it finished — the container exited with it, or the machine went to sleep.
   ok	whichever process ran the flush	Reflection ran. lessons_stored is what it stored, and it can legitimately be 0 when the server has not finished indexing the session's evidence.
   failed	"	Reflection was attempted and did not answer. last_error carries the reason and attempts says how many tries it took to give up; this session's lessons stay at run scope. Read attempts before diagnosing anything else — see the note below.
   skipped:disabled	"	MUBIT_CC_REFLECT_ON_END=0. Not a fault — a deliberate opt-out that costs cross-session memory.
   skipped:not-ingested	"	Nothing was ingested this session, so there was no tail to reflect over.
   skipped:undrained	"	The spool did not land, so reflecting would have drawn conclusions from a session the server only half has. The next session drains the rest and reflects then.