Summary

The automatic memory recall pipeline lacks sufficient logging to diagnose precision issues. When irrelevant memories are injected into context, there is no structured trace showing why those candidates were selected over others.

Current State

The only recall log is turn_memory_recall which emits:

• degraded (bool)
• stage (string)
• durationMs (int)
• itemCount (int)
• itemIds (comma-separated)

The SQLiteMemoryRecallCoordinator does emit memory_retrieval_request_plan and memory_retrieval_candidate_selection structured logs, but these don't appear in the daemon log for the observed sessions — possibly because they're at a different log level or the structured log context doesn't propagate.

Required Observability

Per-turn recall trace (always logged)

• FTS query terms used
• Number of raw FTS candidates returned
• Number of candidates after audience/boundary filtering
• Number of candidates after selector scoring
• Final selected item IDs with their scores

Detailed candidate trace (debug-level)

• Per-candidate: ID, title, score breakdown (lexical, facet, anchor, soft-scope, domain affinity)
• Rejected candidates: top N runners-up with their scores (to understand near-misses)

Recall quality metrics (periodic/stats)

• Average candidate pool size per recall
• Score distribution (min/max/median of selected vs rejected)
• Progressive recall exhaustion rate (how often all candidates were already injected)

Why This Matters

Without this data, diagnosing recall precision issues (#559) requires manually querying the SQLite database and cross-referencing with daemon logs. The retrieval planner, candidate selector, and score function are all opaque at runtime.

Related

• fix(wizard): init wizard fixes for 0.10.1 (#537, #538, #540) #559 — automatic recall overfetch at scale
• Add access-aware memory scoping beyond channel/session boundaries #203 — domain collapse
• fix(memory): collapse per-channel memory domains to project:default #557 — PR with domain + audience fixes