d6246b4e01
The setup schema offered db_path as f"{display_hermes_home()}/memory_store.db",
so `hermes memory setup` (Enter on the field) and the dashboard form wrote the
active profile's concrete path into plugins.hermes-memory-store. initialize()
only expands a literal $HERMES_HOME, and neither `profile create --clone` nor
`profile rename` rewrites config.yaml, so:
- a cloned profile opened the source profile's memory_store.db: facts stored
in one profile were recalled into the other's prompts, both ways;
- a renamed profile opened profiles/<old>/memory_store.db, which MemoryStore
re-created as an empty DB in a ghost directory under the old name, while the
real facts sat orphaned in the renamed directory.
The schema default is now "$HERMES_HOME/memory_store.db", the value the docs
already give, which initialize() resolves against whichever profile opens it.
save_config also stores a db_path equal to this profile's own DB as the
placeholder, so a config written by an older setup is repaired on its next save
from the CLI or the dashboard. A path anywhere else is kept as given.
Holographic Memory Provider
Local SQLite fact store with FTS5 search, trust scoring, entity resolution, and HRR-based compositional retrieval.
Requirements
None — uses SQLite (always available). NumPy optional for HRR algebra.
Setup
hermes memory setup # select "holographic"
Or manually:
hermes config set memory.provider holographic
Config
Config in config.yaml under plugins.hermes-memory-store:
| Key | Default | Description |
|---|---|---|
db_path |
$HERMES_HOME/memory_store.db |
SQLite database path |
auto_extract |
false |
Auto-extract facts at session end |
default_trust |
0.5 |
Default trust score for new facts |
hrr_dim |
1024 |
HRR vector dimensions |
Tools
| Tool | Description |
|---|---|
fact_store |
9 actions: add, search, probe, related, reason, contradict, update, remove, list |
fact_feedback |
Rate facts as helpful/unhelpful (trains trust scores) |