email recall: the design, and which answers can be trusted

the use case is someone mid-phone-call who needs a fact from eight years of
correspondence now. everything in here is in service of that moment.

the split that came out of the discussion, and it is the whole document:
counting needs EXHAUSTION, retrieval needs SPEED, and they are different
machinery. an agent asked "how many times did she ask X" will search, find
some, and answer with a number bounded by the phrasings it happened to think
of — "i found four" is indistinguishable from "there were nine", and nothing
in the output says which. vector search does not fix that; top-k misses too,
just differently. the only honest count is to judge every message once and
store the verdict.

which makes the compile half the one that answers the questions that prompted
this, and it needs no vectors at all.

embeddings still earn their place for the other row: keyword search finds
"school run" and never finds it from "the pickup arrangement", and on a live
call thirty seconds of searching is a lost moment. the stronger argument is
whatsapp and transcripts sharing no vocabulary with email — but we do not have
those, so they shape exactly one decision (the store is not email-shaped) and
nothing else.

two constraints stated as constraints rather than preferences: the embedding
model runs LOCALLY, because an api means uploading eight years of private
correspondence to a third party, and there is no ollama or embedding code on
any machine here — that is the real new dependency, not the database. and it
is sqlite-vec in the plugin's own file, not a vector database: 19,097 rows is
small, and a separate service would be operational surface bought for nothing.

the hard part is neither. it is quoted reply chains putting the same paragraph
in forty messages of one thread, which naive embedding turns into forty
identical results. step 1 of the build order is chunking with no embeddings at
all, because if that is wrong nothing after it can be right.

a stored verdict is a judgement a model made about someone's divorce, so it
records what it was asked, what it read and when. a number with no provenance
is worse than none, because it will be quoted.

CLAUDE.md

@@ -421,6 +421,9 @@ explaining why it was safe.
 
 - `docs/navigation-audit.md` — **authoritative** on routing/navigation: the opaque-click anti-pattern,
   a severity-ranked findings table, the channel-selection map and the four-phase plan
+- `docs/email-recall.md` — **design, not built**: recall over your own correspondence. The split that
+  matters is counting (needs every message judged) versus retrieval (needs the best few, fast) — and why
+  a number produced by searching is confidently wrong with no signal that it is
 - `docs/find-my-device.md` — **design, not built**: locating your own devices from Officer. What is
   assembly (most of it), what is impossible (offline finding — there is no crowd to relay it), and the
   question to settle first, which is retention rather than anything technical