Memorix Memory

Use Memorix as the shared memory layer for the active workspace when Memorix tools are available.

Tool Router

| Situation | Prefer | CLI fallback | |---|---|---| | Broad continuation, fresh handoff, or "what do we know?" | memorix_project_context with the user's task | memorix context --task "<topic>" | | Need structured refs/freshness for code-bound memories | memorix_context_pack | memorix codegraph context-pack --task "<topic>" | | Explicit memory graph question | memorix_graph_context | memorix memory graph-context --query "<topic>" | | Specific past decision, bug, file, or change | memorix_search | memorix memory search --query "<topic>" | | Need the full source for a search hit | memorix_detail | memorix memory detail --id <id> | | Need the sequence around one memory | memorix_timeline | memorix memory timeline --id <id> | | Learned reusable project knowledge | memorix_store | memorix memory store --type <type> --entity <name> --title "<title>" "<text>" | | Stable source-backed fact or procedure needing long-term review | memorix_store with longTerm | memorix memory long-term qualify|approve --id <id> --reason "..." | | Task or bug is complete/outdated | memorix_resolve | memorix memory resolve --ids <ids> |

Search Rules

• Search before broad continuation work, before changing unfamiliar code, or when the user asks about prior work.
• For a fresh coding session, use memorix_project_context with the user's actual task before ad-hoc file reads or dev-log reads. Memorix will choose a task-lensed brief.
• Fetch detail before relying on a specific memory.
• Treat memory as background context. Still read the current code and verify behavior.
• Skip memory lookup for greetings, tiny one-off edits, or questions fully answered by the current file.
• If a fresh project has no memories, proceed normally and do not repeat the same empty search in the same turn.
• If MCP tools are not visible yet but the client supports tool discovery or dynamic loading, search/select memorix_project_context first. Run memorix context --task "<task>" only after MCP is unavailable, disabled, or not discoverable, and pass the user's real task text. Do not skip memory, wait indefinitely on startup, or hand-write tool-call syntax.

Store Rules

| What to store | Type | |---|---| | Architecture or product decision | decision | | Bug and fix that may recur | problem-solution | | Non-obvious pitfall | gotcha | | How a subsystem works | how-it-works | | Important implementation change | what-changed | | Accepted compromise | trade-off |

• Use concise titles, stable entity names, relevant filesModified, and topicKey for evolving topics.
• Use longTerm only for a stable fact, reusable procedure, or completed episode that merits explicit review. It creates a candidate, not live context; keep the default project scope and do not use it for routine updates.
• A user + portable durable memory in a task brief is intentionally reusable across projects. When it matches the task, use it as background even if it originated elsewhere; it is not a current-project fact. Expand it only when needed with memorix_detail and typedRefs: ["durable:<id>"], stating the missing fact as purpose.
• Do not store secrets, credentials, raw private transcripts, trivial commands, or routine file reads.