optimize_scan
Dump your memory corpus compactly to plan a curation pass. See curation fields, relation edges, usage counts, and anchors to check against live facts before staging changes.
Instructions
Dump the memory corpus compactly so you can plan a curation pass.
Step 1 of the "optimize my memories" workflow: every memory's
curation-relevant fields, the relation edges among them, usage counts,
dedup and domain hints, and per-memory anchors (URLs, paths,
identifiers) to check against live facts. Read it, then stage what you
decided with optimize_stage.
Start with what the store already says is suspect: due: true on a
memory means its own writer dated it for a recheck and the date has
passed, and source_ref says what to check it against.
recalls and stats.never_recalled are NOT that. A low count means
unproven, not useless -- a memory about a rare subject looks exactly
like a memory nobody wants, and the rare subject is frequently the
reason the store is there. Use the aggregate to judge the STORE and
never a single row: do not propose archiving something because it is
unread.
The listing is slim so a big store fits one response, and a page ends
early at an internal size budget -- truncated means page onward with
offset + count. since limits the scan to a delta for recurring passes;
full=True keeps whole bodies.
BEFORE PROPOSING ANY CHANGE, CHECK IT AGAINST LIVE FACTS, and record what
you checked in each suggestion's verified. Destructive kinds are
rejected without it. help(command='optimize_scan') has the rest: what
every hint means, how since stays cross-window, and what "live facts"
covers per memory type.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| full | No | ||
| type | No | ||
| limit | No | ||
| since | No | ||
| domain | No | ||
| offset | No | ||
| include_archived | No |