slm-remember

# slm-remember — Capture Durable Facts Store atomic, durable facts into SuperLocalMemory for retrieval in future sessions. One fact per call. Recall before you remember. --- ## What to store (and what not to) **Store:** - Architectural decisions ("Decided to use Postgres not MySQL — reason: JSONB support") - Project conventions ("All API routes follow /api/v1/resource/{id} pattern") - Hard constraints ("Never expose raw SQL errors to the HTTP response") - Resolved gotchas ("Ollama needs keep_alive=-1 or it unloads the model between calls") - Security rules ("Rate limit all public endpoints at 100 req/min") **Do not store:** - Transient context that is only relevant within this conversation - Large blobs of code or full file contents (those belong in the project, not memory) - Facts the project README already captures --- ## Recall-before-remember (mandatory discipline) Before calling `remember`, always call `recall` first with the core terms of what you are about to store. If a near-duplicate exists: - Use `update_memory(fact_id, content)` to refine the existing fact instead of creating a new one. - Only call `remember` when no sufficiently similar fact is found. Duplicates degrade retrieval quality for every future session. --- ## MCP-first workflow ### 1. Check for duplicates first ``` recall(query="JWT token expiry auth", limit=5, session_id="<sid>") ``` If a near-duplicate is returned: ``` update_memory( fact_id="f8a2bc91", content="JWT tokens use 1h...