deepseek-memory

LIMITATIONS

Known limitations

- **The child path needs a subagent provider, and the fallback path needs a route.** With a subagent provider, the child inherits the session's model and consolidation is fully automatic. Without one, the fallback needs `consolidationRouteProvider` + `consolidationRouteModel`, or the session's logged `request/header` route; with neither, consolidation is skipped rather than guessing a model. - **Consolidation runs in-process and is not queued.** One run per session at a time; a crash mid-run loses that run's changes, never a committed store. - **Concurrent writers are refused, not merged.** If another process commits the same tier after this one loaded it (two harness windows on one project, say), the write is refused with `MEMORY_STORE_CONFLICT` and the stale cache is dropped, rather than silently overwriting the other writer's entries. Hand edits that do not bump `revision` are still invisible until a `refresh()`. - **The gate is a heuristic over text.** It reads user and assistant text only; it cannot see whether a turn was *important*, just whether it *sounded* durable. - **No dedup against near-identical entries.** Two differently-worded versions of the same fact are two entries; the consolidator is expected to merge them. - **`maxEntries` is per tier, not global**, so a deployment with both tiers enabled can hold twice the configured number of entries. - **The child can only write memory, so anything else it concludes is discarded.** That is intentional, but it means a consolidation that needs to inspect a file to decide is simply out of scope.