snapshot: preserve central wiki state 2026-08-15 (7 modified + 1 new file)

2026-08-15 22:11:30 +08:00
commit 92e8028bb8
71 changed files with 9897 additions and 0 deletions
@@ -0,0 +1,59 @@
+---
+title: Mnemosyne Automatic Capture Failure
+type: incident
+status: active
+created: 2026-08-01
+updated: 2026-08-01
+verified_on: 2026-08-01
+confidence: high
+tags: [memory, mnemosyne, hermes, incident]
+sources: [live-config, mnemosyne-db, hermes-cli-e2e]
+---
+
+# Mnemosyne Automatic Capture Failure — 2026-08-01
+
+## Impact
+Ordinary Hermes conversations were not being written to Mnemosyne `working_memory`. Explicit memory tools, SQLite integrity, vectors, FTS indexes, consolidation, backups, and cron monitoring remained operational. The newest automatic/explicit working row before repair was approximately fourteen hours old despite active Hermes sessions.
+
+The always-injected legacy files were also effectively full: `MEMORY.md` was 5,055 bytes against a 5,000-character limit and `USER.md` was 2,958 bytes against 3,000. Legacy writes had begun failing.
+
+## Root Cause
+Structured values under `memory.mnemosyne` in `~/.hermes/config.yaml` had been serialized as strings instead of native YAML types. The critical value was:
+
+```yaml
+sync_roles: "['user']"
+```
+
+The provider interpreted this as the literal invalid role `['user']`, so turn synchronization completed without persisting a user row. Other malformed values included `skip_contexts`, `reflect`, `sleep_threshold`, and `ignore_patterns`.
+
+## Repair
+- Backed up config to `/home/hermes/.hermes/backups/mnemosyne-capture-fix-20260801_180249/config.yaml.before`.
+- Rewrote structured Mnemosyne settings with native YAML types.
+- Set `profile_isolation: true` because the installation has multiple Hermes profiles.
+- Preserved `sync_roles: [user]` and the intended skipped contexts.
+- Ran `hermes config check` successfully.
+- Created authoritative Mnemosyne canonical slots for user preferences and key workflows, correcting stale light-theme, numbered-Obsidian, and CT460 route entries.
+- Backed up legacy files to `/home/hermes/.hermes/backups/legacy-memory-slim-20260801_180702/`.
+- Reduced legacy injection from 8,013 bytes to 1,080 bytes while retaining essential always-on rules.
+
+## Verification
+A pre-fix CLI turn using marker `MNEMO_E2E_20260801_180113_27053` completed but produced no database row.
+
+A post-fix CLI turn using marker `MNEMO_FIXED_20260801_180310_16583` wrote:
+
+```text
+[USER] Reply with exactly OK. Memory capture test marker: MNEMO_FIXED_20260801_180310_16583
+```
+
+The row was verified directly in `~/.hermes/mnemosyne/data/mnemosyne.db`. Final diagnostics reported zero failed checks, complete working-vector coverage, zero orphan embeddings, 1,482 working rows, and 463 episodic vectors.
+
+## Remaining Activation Step
+The already-running Telegram gateway/provider instance was initialized before the config repair. Run `hermes gateway restart` from an external terminal to load the corrected typed configuration for messaging-platform turns. The gateway cannot safely restart itself from one of its own child tool calls.
+
+## Monitoring Note
+The health script checks capture staleness only after 24 hours. It therefore remained green during this fourteen-hour active-capture outage. A future improvement should compare recent non-cron conversation activity with the newest `working_memory` row rather than lowering the threshold blindly and creating idle-period false positives.
+
+## Related
+- [[systems/mnemosyne]]
+- [[systems/memory-backend]]
+- [[incidents/2026-07-29-mnemosyne-relay]]