Goal
- Stand up a minimal reusable local bridge from agent workflows into Hypatia.
- Detect and fix the common failure mode where writes succeed but
searchreturns nothing.
When to use
- You have Hypatia source locally and want practical reuse, not just repo study.
- You want a safe sidecar memory layer before integrating into a main agent system.
knowledge-createor direct writes succeed, butsearchreturnsNo results found.
Recommended approach
- Build Hypatia first.
- Repo example:
~/Downloads/repo-intake/hypatia - Run:
cargo build --release
- Repo example:
- Create a thin wrapper script instead of editing the main agent first.
- Good first commands:
add-notesearchget-note
- Call the Hypatia binary via subprocess, parse stdout JSON where applicable, and emit stable JSON for the caller.
- Good first commands:
- Verify the whole path end to end.
- Create a note.
- Read it back with
knowledge-get. - Search for words from name, data, and tags.
- If read works but search fails, inspect SQLite directly before guessing.
- Check
~/.hypatia/default/index.sqlite. - Compare counts in
docs_metavsdocs_fts. - Inspect recent rows in both tables.
- Check
- If
docs_metahas rows anddocs_ftsexists but MATCH finds nothing, patch Hypatia schema init to rebuild the FTS index. - Rebuild Hypatia and rerun the end-to-end verification.
Bridge template
- Implement a small Python wrapper with:
- configurable binary path via
HYPATIA_BIN - configurable default shelf via
HERMES_HYPATIA_SHELF - commands for
add-note,search,get-note
- configurable binary path via
- Prefer a sidecar workspace such as:
~/Downloads/hermes-hacks/hermes-hypatia-bridge/
Key debugging pattern
- Write test note:
hypatia knowledge-create "Hermes bridge test" --data "Hypatia bridge working" --tags hermes,memory,bridge --shelf default
- Confirm retrieval works:
hypatia knowledge-get "Hermes bridge test" --shelf default
- If search fails:
hypatia search bridge --limit 10 --shelf default- Inspect SQLite table contents directly.
- Use Python
sqlite3for direct inspection when needed:- count
docs_meta - count
docs_fts - inspect
key,fts_key,fts_data,fts_tags - run
MATCHqueries directly
- count
Actual fix
- File:
src/storage/sqlite_store.rs - In
SqliteStore::init_schema(), after recreating the triggers, run:
self.conn
.execute_batch("INSERT INTO docs_fts(docs_fts) VALUES('rebuild');")
.map_err(StorageError::from)?;
Why this matters
- Hypatia recreates the FTS virtual table in schema init.
- Recreating the FTS table alone does not repopulate it from
docs_meta. - Result: writes may exist in
docs_meta, butdocs_fts MATCH ...returns no rows. - The
rebuildcommand repopulates the FTS index from the content table.
Verification checklist
cargo build --releasesucceeds.knowledge-createsucceeds.knowledge-getreturns the inserted object.searchfinds terms from title/data/tags.- Direct SQLite MATCH query also returns rows.
Pitfalls
- Do not assume write failure just because search is empty.
- Do not trust only the CLI search path; inspect the SQLite backing store directly.
- Do not integrate deeply into Hermes first; prove the sidecar bridge works end to end.
- If a repo claims FTS works, still verify after schema migrations or virtual table recreation.