o9k-search

# hmem Search

When the user references past context without pinning it to an ID, or when looking up definitions, schemas, or decisions stored in hmem — convert the intent into a targeted `read_memory` query.

## Workflow

1. **Extract from the prompt:**
   - **Keywords** — distinctive nouns, project names, error fragments, schema names. Skip filler like "wir", "neulich", "besprochen", "Schema für".
   - **Time hint** — map to `after`/`before` range using the current date as anchor. "gestern" → narrow (−1 to 0d), "letzte Woche" → medium (−10 to −3d), "neulich"/"vor kurzem" → generous (−21d). No time hint → skip the range.

2. **First search:**
   ```
   read_memory({ search: "<keywords>", after: "<ISO>", before: "<ISO>" })
   ```
   Keywords as a single space-separated string. Use ISO dates (`2026-04-11`), not relative forms.

3. **If results are empty or off-topic — work through this sequence immediately, without waiting:**

   **a) Drop time filter, keep keywords**
   Time hints from humans are fuzzy; the memory may sit just outside the window.

   **b) Try term variations — systematically, not just once**
   The stored entry may use a different phrasing than what the user said. Try all that apply:
   - German ↔ English: "Schema" → "schema", "Entscheidung" → "decision", "Fehler" → "error"
   - Abbreviations or expansions: "H-Schema" → "H-Entry Schema", "O-Eintrag" → "O-entry"
   - Compound splits: "Standardschema" → "Standard Schema", "Checkpoint-Strategie" → "checkpoint strategy"
   - Synonyms: "Kollision" → "conflict", "Struktur" → "structure", "Vorlage" → "template"
   - Broader category: "H-Standardschema" → "H-entry", "entry schema", "Human schema"
   - Related prefix: if the topic is about a specific entry type (H, P, E, I…), search that prefix directly via `read_memory({ prefix: "R", search: "H" })`

   Don't try one variation and stop. Run 2–3 variations before concluding nothing was found.

   **c) Switch store**
   Default is `personal`. If the topic is work-related and personal turned up nothing, try `store: "company"`.

   **d) Broaden with `find_related`**
   If you found *something* related but not quite right, use `find_related({ id: "<hit-ID>" })` to surface linked entries.

   Only report "nothing found" after all of these have failed.

4. **Present the hits:**
   - Top 3–5 most relevant: `ID · date · one-line summary`.
   - If the question implies drilling into one entry, offer `read_memory({ id: "..." })` rather than dumping everything.

## Why term variation matters

hmem entries are titled by whoever created them, not by a controlled vocabulary. "H-Standardschema" might be stored as "H-Entry Schema: Standard-Struktur für Human-Context-Einträge" (R0025). The search engine does substring/FTS matching, but only within what's actually stored. If the first search misses, the entry almost certainly exists under a different phrasing — not in a different location.

The failure mode to avoid: searching once, getting no results, and concluding the information doesn't exist. **A null result is a signal to try harder, not a final answer.**

## The "assumed shared knowledge" trigger

The user often speaks as if you already know things you don't — because from *their* side, the conversation is continuous across sessions. Watch for:

- **Definite articles without prior mention:** "der Bug mit dem Sync", "das Problem von neulich", "die Entscheidung zum Schema" — the `der/das/die` implies you should know which one.
- **Proper names dropped cold:** a project, person, feature, or error name you haven't seen this session.
- **Casual callbacks:** "wie besprochen", "wie gesagt", "du weißt schon", "as we agreed".
- **Assumed status:** "wo stehen wir mit X?", "ist Y schon fertig?"
- **Schema/rule lookups:** "gibt es ein Standard für X?", "was ist das Schema für Y?", "was haben wir zu Z beschlossen?"

When this pattern shows up: search first, answer second.

## Don't

- Don't pre-parse time into a fixed dictionary (`"neulich" → 14d`). Context shifts the right window.
- Don't silently search only `personal` when the context is clearly work-related.
- Don't return raw `read_memory` output to the user. Summarize what was found.
- Don't trigger when the user cites a specific ID — they already know where to look.
- **Don't stop after a single null result.** Work through the variation sequence before giving up.

## Related tools

- `search_memory` — dedicated FTS5 endpoint; `read_memory({ search })` covers the same ground with structured output.
- `find_related(id)` — after locating a hit, surface linked entries.
- `read_memory({ time_around: "<ID>" })` — once you have an anchor, find entries created around the same time.
- `read_memory({ prefix: "R" })` — scan all Rules when looking for documented standards or constraints.