clickmem-research

ClickMem — Memory Audit

A lightweight quality pass over the ClickMem store. The server runs zero LLM, so this skill uses the agent's current session model to score recall behaviour and propose fixes. Everything reads through the public REST + MCP surface; no direct chDB access.

Run the steps in order. Stop early if a step fails critically (server unreachable, no data).

---

Step 1: Health check

clickmem service status
curl -s http://127.0.0.1:9527/v1/health | jq
curl -s http://127.0.0.1:9527/v1/stats/overview | jq

Confirm:

• Server is reachable on port 9527.
• Memory counts are non-zero; otherwise there's nothing to audit.
• Active backend (local chDB vs clickhouse) matches what the user expects.

---

Step 2: Sample recent recall traces

The server logs every recall to the events table. Pull the last N traces and the per-candidate scoring:

clickmem recall-trace --sample 20 --since 7d
# or
curl -s -X POST http://127.0.0.1:9527/v1/recall/trace \
  -H 'Content-Type: application/json' \
  -d '{"sample": 20, "since": "7d"}' | jq

Each trace returns the query, the top hits, and the score breakdown (cosine × project multiplier × privacy filter × pinned boost). Look for:

• Low top-1 cosine (< 0.5) — the agent asked something with no anchor in the store.
• Project mismatches — top hits came from other-project (×0.0) and got filtered out.
• Stale top hits — the top memory is status='contracted' or hasn't been updated in months and yet is winning.

---

Step 3: Surface unresolved conflicts

clickmem conflicts --json
# or
curl -s http://127.0.0.1:9527/v1/conflicts | jq

For each pair, fetch both memories:

clickmem show <id_a> --history
clickmem show <id_b> --history

Decide for each pair:

• One supersedes the other → propose clickmem resolve <loser> --revise <winner>.
• Both are correct under different scopes (different projects, privacy levels) → propose clickmem resolve <a> --allow <b>.
• Neither is right anymore → propose clickmem forget on both with a reason.