timeline
Reveal what records were written immediately before and after a chosen memory, in creation order, so you can inspect context that keyword search would miss.
Instructions
What else was being written around one memory, in creation order.
For the question search cannot ask: not what mentions this record, but what was being written when it was. Neighbours are picked by time alone, so they come back whether or not they share a word with the anchor -- around a checkpoint, that is the notes and pitfalls of the same stretch of work.
One of uid or query is required; give both and uid wins. The response
reports anchored_by ('uid' or 'query') and the whole anchor record,
so which record the timeline is built around is never a guess.
Returns {"anchored_by": ..., "anchor": {...}, "before": [...], "after": [...]}, both lists oldest first, so before + [anchor] + after reads straight down the clock. Neither list contains the anchor. domain and type narrow the NEIGHBOURHOOD, not the anchor, and archived records are left out of it, as everywhere else by default.
Each record is snippet-truncated with est_tokens for its full content
-- call get_memory(uid) to open one.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| uid | No | the anchor, named outright. | |
| type | No | one memory type, as search() takes it; empty is every type. | |
| after | No | how many records created immediately after it. | |
| query | No | searches for the anchor and takes the top hit (the same search search() runs, scoped by domain/type). | |
| before | No | how many records created immediately before the anchor. | |
| domain | No | covers a path and everything under it, plus what is cross-listed into it, and resolves a bare deep segment the way the other scoped reads do. |