timeline
Retrieve memories written immediately before and after a given record, in creation order, so you see the notes and pitfalls of the same work stretch regardless of shared wording.
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. uid names the anchor outright; query
searches for it and takes the top hit (the same search search() runs,
scoped by domain/type). 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": [...]}: before is the before records created immediately
before the anchor and after the after records created immediately
after it, both 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: a memory named by uid comes back as named, and the records around it are the ones matching the filters. domain 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. Archived records are left out of the neighbourhood, 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 | ||
| type | No | ||
| after | No | ||
| query | No | ||
| before | No | ||
| domain | No |