ockentapThis plugin has no README in the catalog yet.
All plugins
memory-shaper
Keyword-index memory for Hermes: a small resident index of 'keyword,keyword -> file.md' routing lines stays in the system prompt while verbose topic files stay on disk and are read only when the conversation touches their keywords. Retrieval is done by the model reading a literal index — no embeddings, no vector store, no retrieval service. Disclosure — a pre_tool_call hook and a tool_execution middleware refuse a non-memory tool's write to the memory index across the recognised write vectors (write_file, patch, shell redirects, tee, sed -i; best-effort against arbitrary shell indirection) and refuse malformed index lines with a fix message rather than fixing them silently (including the keyword count: an entry outside the documented 5-20 keywords is refused, and the ASCII arrow is refused on every code path), while read-only commands and reads through a pipe always pass so the agent can audit the file it maintains; the same guard refuses any memory-tool remove, replace or patch whose old_text lands inside the index header, because on the stock store the whole preamble is a single §-joined entry and such an edit would rewrite or delete every header line at once; a documented escape hatch lets a scripted rewrite proceed when the sentinel file $HERMES_HOME/state/.memory_shaper_rewrite_approved exists or MEMORY_SHAPER_ALLOW_REWRITE=1 is set. Beyond $HERMES_HOME/memories/, the guard reads one thing: when a shell command invokes python3 on a script file, it opens that script (and the execute_code payload is already in args) to check whether the code would write the index; no file content is retained or sent anywhere. The repo also ships an optional core patch (scripts/patches/0001-flat-memory-separator.patch, changes tools/memory_tool_store.py) that the plugin does not need and never applies; a user who applies it by hand must re-apply it after every Hermes update. No network calls, no subprocesses, nothing spawned in the background.
About
Keyword-index memory for Hermes: a small resident index of 'keyword,keyword -> file.md' routing lines stays in the system prompt while verbose topic files stay on disk and are read only when the conversation touches their keywords. Retrieval is done by the model reading a literal index — no embeddings, no vector store, no retrieval service. Disclosure — a pre_tool_call hook and a tool_execution middleware refuse a non-memory tool's write to the memory index across the recognised write vectors (write_file, patch, shell redirects, tee, sed -i; best-effort against arbitrary shell indirection) and refuse malformed index lines with a fix message rather than fixing them silently (including the keyword count: an entry outside the documented 5-20 keywords is refused, and the ASCII arrow is refused on every code path), while read-only commands and reads through a pipe always pass so the agent can audit the file it maintains; the same guard refuses any memory-tool remove, replace or patch whose old_text lands inside the index header, because on the stock store the whole preamble is a single §-joined entry and such an edit would rewrite or delete every header line at once; a documented escape hatch lets a scripted rewrite proceed when the sentinel file $HERMES_HOME/state/.memory_shaper_rewrite_approved exists or MEMORY_SHAPER_ALLOW_REWRITE=1 is set. Beyond $HERMES_HOME/memories/, the guard reads one thing: when a shell command invokes python3 on a script file, it opens that script (and the execute_code payload is already in args) to check whether the code would write the index; no file content is retained or sent anywhere. The repo also ships an optional core patch (scripts/patches/0001-flat-memory-separator.patch, changes tools/memory_tool_store.py) that the plugin does not need and never applies; a user who applies it by hand must re-apply it after every Hermes update. No network calls, no subprocesses, nothing spawned in the background.