Recall fails to surface most recent handoffs

[CalebisGross]

Problem

recall with type: "handoff" does not reliably surface the most recent handoff. In today's session (2026-04-11), querying for handoffs returned memories from April 4 and April 7, but not the handoff created 30 minutes prior (08:54 today).

Observed behavior

1. recall with type: "handoff" and query "handoff 2026-04-11 EXP-30 llama.cpp verdict suspended" — returned handoffs from April 4, April 7, April 7 (three old ones). The 08:54 handoff was absent.
2. recall without type filter and query "session handoff 2026-04-11 08:54" — returned an unrelated memory about the Model Control Center.
3. recall_session showed the handoff existed in the session list (summary only, no content).
4. check_memory on the handoff ID returned truncated content (cut off after ~100 chars of the body).
5. Only the raw REST API (GET /api/v1/memories/:id) returned the full handoff content.

Expected behavior

The most recent handoff should be the first result when querying for handoffs, especially within minutes of creation. Handoffs are high-salience (0.95) and explicitly designed to be surfaced by recall_project and type-filtered recall.

Root cause hypotheses

• Recency scoring too weak for type-filtered queries: The spread activation recency bonus may not be weighting recently-created memories strongly enough relative to older memories with more associations/access counts.
• FTS ranking dominance: Older handoffs have richer concept overlap from repeated encoding cycles, so FTS scores them higher despite being stale.
• check_memory content truncation: Separate bug — check_memory should return the full content, not truncate it. This forced a workaround through the REST API.

Impact

This is a session-start blocker. The entire point of create_handoff is continuity between sessions. If the most recent handoff doesn't surface on recall, agents waste time hunting for it (as happened today — ~6 recall attempts before resorting to the raw API).

Reproduction

1. Create a handoff via create_handoff
2. Wait for encoding (< 1 min)
3. recall with type: "handoff" and a query matching the handoff content
4. Observe that older handoffs rank higher than the one just created

[CalebisGross]

Fix implemented

Two changes address the three symptoms reported:

1. Type-filtered recency boost (primary fix)

Added TypeFilterRecencyWeight (default: 0.5) and TypeFilterRecencyHalfLife (default: 7 days) to the retrieval config. When a query filters by type, these override the general recency params (0.2 weight, 30-day half-life).

Why the old behavior failed: All handoffs share identical salience (0.95), so they enter spread activation at the same base score. Older handoffs accumulate more associations over time, giving them higher activation through graph traversal. The old recency bonus (max 0.2, 30-day half-life) produced only a 0.042 delta between brand-new and 7-day-old memories — not enough to overcome the association advantage.

New behavior: The type-filter recency gives a 0.316 delta between new and 7-day-old. This is enough to ensure the most recent handoff surfaces first. The activity bonus was already disabled for type-filtered queries (good), and this completes the picture.

Design rationale: Type filtering is an intent signal — when you filter by type, you've already constrained what you want. The system should then prioritize when over semantic similarity. This applies to all type-filtered queries (handoffs, decisions, errors), not just handoffs.

Verified via direct HTTP endpoint:

• Old recency_bonus for ~11h-old handoff: 0.197
• New recency_bonus for same handoff: 0.469

2. check_memory content field (secondary fix)

check_memory output now includes the full Content field. The prior output showed Summary, Concepts, Salience, State, etc., but Content was simply missing from the format string — not truncated, just omitted.

Files changed

• internal/agent/retrieval/agent.go — config struct + ranking logic
• internal/config/config.go — config struct + defaults
• cmd/mnemonic/runtime.go — config wiring
• internal/mcp/server.go — check_memory output

Tests

• TestConfigTypeFilterRecencyBoostsRecent — recent handoff ranks above older one with more associations
• TestConfigTypeFilterRecencyParamsUsed — aggressive params override general ones
• TestHandleCheckMemoryIncludesContent — content field present in check_memory output

[CalebisGross]

Fix shipped in PR #395. Verified live on the daemon — both the recency boost and check_memory content fix are working. New sessions will pick up the fix automatically via HTTP transport.