8f45624e55
* fix(integrations): parameterize resolver-row fence by recipe id The install fence was hardcoded gbrain:agent-voice:resolver-rows, so any second copy-into-host-repo recipe wrote a mislabeled block (and refresh/ uninstall keyed on recipe id would miss it). Derive it from manifest.recipe. * feat(context): Retrieval Reflex — teach the agent when/what to retrieve (#1981) Deterministic per-turn pointer layer in the context engine: a zero-LLM, precision-biased scan resolves salient entities (names, @handles) to existing brain pages and injects compact pointers (name → slug → safe synopsis). Detect + point, never auto-dump. Fail-open, capped, suppression on prior context only. Engine-aware resolver ladder (no second DB connection): host ctx.brainQuery → PGLite serve resolve IPC (unix socket) → Postgres cached direct → disabled. Synopsis runs through get_page's privacy strip. Plus the retrieval-reflex recipe + policy skill, the retrieval_reflex_health doctor check, config gate, and the init next-step hint. * chore: bump version and changelog (v0.42.38.0) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * docs(architecture): KEY_FILES entries for Retrieval Reflex surface (#1981) Document the new src/core/context/ modules, the context-engine resolver ladder, the serve resolve IPC, the retrieval_reflex_health doctor check, and the recipe-id-keyed install fence. Current-state only. --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2.5 KiB
name, version, description, triggers, mutating, writes_pages, writes_to, tools
| name | version | description | triggers | mutating | writes_pages | writes_to | tools | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| retrieval-reflex | 0.1.0 | When/what to retrieve — open the brain page for a salient entity before answering from memory. |
|
false | false |
|
Retrieval Reflex — retrieve on demand, when an entity is salient
A person doesn't bulk-load their whole address book into working memory. They retrieve on demand, when an entity becomes salient, use it, and drop it. Encode that reflex. The brain probably has the data — if a name is salient and you haven't opened its page, open it before you answer.
Trigger policy — WHEN to retrieve
Retrieve when ANY of these holds AND the page isn't already loaded in context:
- An entity (person / company / project / deal / place) is the subject of the message, or a decision/judgment about it is being made, or the exchange is substantive / relational / emotional about it.
- A brain-page pointer appeared in context this turn (the deterministic layer told you the page exists) — open it before relying on details.
- A name or term appears that you don't recognize and that looks notable → do a quick resolve (the human reflex).
- You're about to assert a non-trivial detail about an entity (attribution, status, history) → verify against the brain first. Say "let me check", not a guess.
Skip trivial passing mentions, logistics pings, and anything already loaded. Judgment first — retrieve when it changes the quality of the reply, not reflexively.
Retrieval spec — WHAT to pull, and when to stop
Escalate only as far as the task needs:
- Pointer / metadata. If a pointer is already in context (slug + one-line summary), and the task only needs identity, stop there.
- Full page. When the entity is the subject or details matter, open it:
get_page <slug>(MCP) — read the page before relying on specifics. - Linked neighbors. Only when relationship context is needed, pull
graph/backlinksfor the slug.
Resolve only the name(s) the current task needs, use them, drop them. No bulk-loading the inner circle.
The failure this prevents
If you've discussed a named person for more than a message without opening their page, open it now. The write side captures everything; the read side only helps if you actually look.
See also: skills/query/SKILL.md (search the brain), skills/brain-ops/SKILL.md.