recall.
Cross-session memory. Ask pakka about a decision from three weeks ago.
A repo's memory of itself.
Most decisions in a coding session evaporate the moment the window closes. Recall watches the conversation for the parts that ought to outlive it — the why-we-chose, the why-not, the constraints — and writes them to a small, queryable, local store.
Recall is not a transcript log — those are too noisy to be useful. Recall extracts five categories of long-lived knowledge from the turn stream and indexes them into a small, queryable SQLite database on your machine.
If a decision can't be answered by recall in one query, it isn't a decision yet — it's a vibe.
Local, by default.
SQLite FTS5 index — porter tokenizer, BM25 ranking — at $CLAUDE_PLUGIN_DATA/recall.db, falling back to ~/.pakka/recall.db. No embeddings, no API calls. Never leaves your machine.
Indexed at session end.
Entries come from the audit JSONL trail. The SessionEnd hook indexes new entries into FTS5 — idempotent, no manual step. The database survives plugin updates.
Always cited.
Each entry references the diff, the spec section, and the turn it was extracted from. No orphans, no folklore.
Cross-session, cross-author.
The next contributor — or the next model — asks /pakka:recall why redis and the original turn surfaces in milliseconds.
Five categories. One paragraph each.
Recall is opinionated about what counts. Anything outside these five is left in the transcript and compressed away.
decisions
The thing you committed to. Cites the diff. Distilled from the model's reasoning + the human's confirmation. One per material change.
rejections
The alternative that was on the table and got dropped. Cites the constraint that killed it. Saves the next contributor from re-litigating.
constraints
Hard requirements that aren't in the code yet. "Must be idempotent at the billing boundary." Surfaces during gate as the spec.
conventions
Repo-local style not in the linter: error wrapping pattern, observability key shape, where logs go. Updated, not appended.
questions
The thing nobody answered. Surfaces at the top of the next session until closed. Forces conversations rather than letting them rot.
Ask, three weeks later.
Real queries from the rate-limit engagement, fired against the recall store after the engineer left the project for a sprint. Each returns the originating turn.
why did we drop redis for the rate limiter?
what's the idempotency key shape for webhooks?
sha256(provider_event_id, account_id), truncated to 32 hex chars, stored in billing.idempotency_keys. Set on the request boundary, checked before any billing call. "Retries MUST be idempotent at the billing boundary" — spec §4.1.
cited · diff #9c4ee · spec §4.1 · gate-finding #47 are there any open questions about the auth claim model?
actor claim should be propagated through the rate-limit middleware or only consulted at the route handler. Two engineers split. Surfaces at the top of every session until resolved. cited · spec §auth.3 · age 9 days