trove-recall

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

trove-recall

Good answers don't disappear into chat history — they become graph atoms. Match Scribe depth: exact lookup and full-page read first;
recall
is for open questions.

优质答案不会消失在聊天记录中——它们会成为图谱中的原子节点。匹配Scribe的深度：优先进行精确查找和整页读取；
recall
适用于开放式问题。

When to use

使用场景

A factual question about anything previously ingested or remembered.
A synthesis ("compare X and Y", "state of Z", "what am I working on").
A recommendation grounded in the user's own context.

When not to use:

The answer is in the current working directory's code — read it directly.
Fresh research with no coverage — research first, then offer
```
trove-ingest
```
.

针对任何已导入或已记忆内容的事实性问题。
需要进行内容合成的场景（如“对比X和Y”、“Z的现状”、“我之前在做什么”）。
基于用户自身上下文的推荐需求。

不适用场景：

答案存在于当前工作目录的代码中——直接读取代码即可。
无相关覆盖的全新研究——先进行研究，再使用
```
trove-ingest
```
导入内容。

Process

流程

Step 1 — pick the retrieval tool (order matters)

步骤1 — 选择检索工具（顺序很重要）

Query shape	Tool	Notes
Exact string — ticket id, product code, error text, config key, email	`grep { pattern }`	Prefer over `recall` . Example: `INV-1042` , `ECONNRESET` . Then `read` if you need the full note.
Known note — you have the name ( `billing-pricing-rules` , `onboarding-checklist` )	`read { slug }`	Full body. Do not rely on a short pack alone.
Open question — "how do we handle refunds?", "what's the plan for mobile?"	`recall { query, tokenBudget }`	Default budget 8000. Phrase as a real question.

The
```
recall
```
pack is a brief, not always the whole note.
If the top hit is right but thin → read
that slug.
Never use
```
recall
```
for a lone ticket id or error string.

查询类型	工具	说明
精确字符串 — 工单ID、产品代码、错误文本、配置键、邮件内容	`grep { pattern }`	优先于 `recall` 使用。示例： `INV-1042` 、 `ECONNRESET` 。若需要完整内容，再调用 `read` 。
已知笔记 — 已知笔记名称（如 `billing-pricing-rules` 、 `onboarding-checklist` ）	`read { slug }`	获取完整内容。不要仅依赖简短的内容包。
开放式问题 — “我们如何处理退款？”、“移动端的计划是什么？”	`recall { query, tokenBudget }`	默认token预算为8000。将问题表述为真实的疑问句。

```
recall
```
工具返回的是简短内容包，不一定是完整笔记。
如果最匹配的结果正确但内容单薄 → 调用
read
读取对应的slug。
切勿针对单个工单ID或错误字符串使用
```
recall
```
。

Step 2 — drill down (only if needed)

步骤2 — 深入挖掘（仅在需要时进行）

```
read { id | slug }
```
for full body + evidence, or a raw source document by source id.
```
neighborhood { nodeId, depth, asOf? }
```
when structure or belief history matters.

调用
```
read { id | slug }
```
获取完整内容+证据，或通过源ID读取原始源文档。
当结构或认知历史很重要时，调用
```
neighborhood { nodeId, depth, asOf? }
```
。

Step 3 — synthesize

步骤3 — 内容合成

Lead sentence answers the question.
Cite node titles/slugs for every non-trivial claim.
Surface gaps explicitly; offer
```
trove-ingest
```
for missing coverage.
Surface contradictions with both citations; recommend
```
trove-lint
```
.

首句直接回答问题。
每个重要结论都要引用节点标题/slug。
明确指出信息缺口；若存在未覆盖内容，建议使用
```
trove-ingest
```
导入。
若存在矛盾内容，需同时引用双方来源；建议使用
```
trove-lint
```
。

Step 4 — file the answer back (when non-trivial)

步骤4 — 将答案存入图谱（仅针对重要内容）

Synthesis across several atoms →

remember { type: "claim" | "decision" | "pattern", title, summary, evidence, links }

citing the atoms it drew from.

Plain fact lookup → nothing to file.

跨多个原子节点的合成内容 → 调用
```
remember { type: "claim" | "decision" | "pattern", title, summary, evidence, links }
```
，并引用所参考的原子节点。
单纯的事实查询 → 无需存入图谱。

Step 5 — confirm

步骤5 — 确认

One-sentence recap; note anything remembered back.

用一句话总结；说明是否将内容存入了图谱。

Anti-patterns

反模式

Don't call
```
recall
```
for an exact identifier — use
```
grep
```
.
Don't answer a known runbook from a thin pack —
```
read
```
the slug for the full body.
Don't chain grep→read→read→neighborhood when one well-chosen
```
recall
```
already answers an open question.
Don't dump the raw context pack on the user. Synthesize.
Don't remember trivial lookups back into the graph.

切勿针对精确标识符调用
```
recall
```
——应使用
```
grep
```
。
切勿仅凭单薄的内容包回答已知的运行手册问题——调用
```
read
```
读取对应的slug获取完整内容。
切勿在一次合适的
```
recall
```
已能回答开放式问题时，连续调用grep→read→read→neighborhood。
切勿直接向用户输出原始上下文内容包。需进行内容合成。
切勿将琐碎的查询结果存入图谱。