@danielmarbach/mnemonic-mcp 0.6.0 → 0.8.0

package/CHANGELOG.md

@@ -4,6 +4,35 @@ All notable changes to `mnemonic` will be documented in this file.
 
 The format is loosely based on Keep a Changelog and uses semver-style version headings.
 
+## [0.8.0] - 2026-03-14
+
+### Changed
+
+- All MCP tool descriptions rewritten for self-contained routing and sub-vault awareness
+
+### Added
+
+- Homebrew tap support: `brew install danielmarbach/mnemonic/mnemonic-mcp`.
+- Git submodule support: project vault creation and identity resolution now walk up through submodule boundaries to the superproject root.
+- Multi-vault support: project git roots can contain multiple vault folders (`.mnemonic-<name>`) alongside the primary `.mnemonic/`. Sub-vaults share the primary vault's embeddings directory and appear in `searchOrder`, `allKnownVaults`, and all list/recall operations.
+- `move_memory` accepts optional `vaultFolder` parameter to target specific sub-vaults.
+- `Storage` accepts optional `embeddingsDirOverride` to redirect where embeddings are stored.
+- `Vault` interface gains `vaultFolderName` field.
+- `VaultManager` exposes `getVaultByFolder(cwd, folderName)` method.
+
+## [0.7.0] - 2026-03-13
+
+### Added
+
+- Protected-branch one-time override input (`allowProtectedBranch`) for additional mutating tools that can commit to project vaults: `update`, `forget`, `move_memory`, and `consolidate` (mutating strategies).
+- Integration coverage for protected-branch policy now verifies ask/override flows across `update`, `forget`, `move_memory`, and `consolidate` in addition to `remember`.
+
+### Changed
+
+- Protected-branch policy enforcement now applies consistently to automatic project-vault commits from mutating tools, not just `remember`. Affected paths include `update`, `forget`, `move_memory`, and mutating `consolidate` strategies (`execute-merge`, `prune-superseded`).
+- Protected-branch guidance text now references the active tool when suggesting one-time override retries.
+- Tool descriptions/docs were updated to reflect cross-tool protected-branch behavior in `README.md`, `AGENT.md`, and `docs/index.html`.
+
 ## [0.6.0] - 2026-03-13
 
 ### Added

package/README.md

@@ -91,6 +91,21 @@ npm install @danielmarbach/mnemonic-mcp
 npm install @danielmarbach/mnemonic-mcp@0.2.0
 ```
 
+### Homebrew
+
+The formula lives in this repository. Tap it with an explicit URL so no separate repository is needed:
+
+```bash
+brew tap danielmarbach/mnemonic-mcp https://github.com/danielmarbach/mnemonic
+brew install mnemonic-mcp
+```
+
+Or in a single step:
+
+```bash
+brew install danielmarbach/mnemonic-mcp/mnemonic-mcp
+```
+
 ### Docker Hub
 
 Pre-built images for `linux/amd64` and `linux/arm64`:
@@ -135,6 +150,21 @@ For a fixed installed version, point at the local binary instead:
 }
 ```
 
+### Claude Desktop / Cursor (Homebrew)
+
+```json
+{
+  "mcpServers": {
+    "mnemonic": {
+      "command": "mnemonic",
+      "env": {
+        "VAULT_PATH": "/Users/you/mnemonic-vault"
+      }
+    }
+  }
+}
+```
+
 ### Claude Desktop / Cursor (Docker)
 
 ```json
@@ -208,7 +238,7 @@ User-tunable fields:
 | `mutationPushMode` | `"main-only"` | When to auto-push after a write: `"all"`, `"main-only"`, or `"none"` |
 
 `projectMemoryPolicies` and `projectIdentityOverrides` are written automatically by `set_project_memory_policy` and `set_project_identity` — no need to edit them by hand.
-Project memory policies can include protected-branch settings (`protectedBranchBehavior`, `protectedBranchPatterns`) used by `remember` when writing to project vaults.
+Project memory policies can include protected-branch settings (`protectedBranchBehavior`, `protectedBranchPatterns`) used by mutating tools when they commit to project vaults (`remember`, `update`, `forget`, `move_memory`, and mutating `consolidate` strategies).
 
 Example — raise concurrency on a fast machine and disable auto-push everywhere:
 
@@ -263,7 +293,7 @@ Use `set_project_memory_policy` to save per-project defaults:
 - protected-branch behavior for project-vault writes (`ask`, `block`, `allow`)
 - protected-branch patterns (glob strings; defaults are `main`, `master`, `release*`)
 
-When write scope policy is `ask`, `remember` returns a clear storage choice instead of guessing. When protected-branch behavior is `ask`, `remember` returns a one-time override option plus instructions to persist `block`/`allow`.
+When write scope policy is `ask`, `remember` returns a clear storage choice instead of guessing. When protected-branch behavior is `ask`, mutating tools that would commit to the project vault return a one-time override option (`allowProtectedBranch: true`) plus instructions to persist `block`/`allow`.
 
 ### Project identity
 
@@ -456,6 +486,29 @@ No. The embeddings here are **local vector representations** generated by Ollama
 
 When you call `recall` with `cwd`, mnemonic adds a fixed **+0.15 boost** to the cosine similarity score of every note belonging to the detected project. This is a soft boost, not a hard filter — global memories are still included when relevant. The boost ensures project-specific context floats to the top when you're working inside a repo while cross-project knowledge remains accessible further down the list.
 
+**I want to brainstorm with no repo yet. Should I create a temp folder first?**
+
+Usually, no. If you're talking to an LLM with mnemonic MCP configured, treat it like a normal brainstorming chat and ask it to store key points in the **main vault** (global memory).
+
+Example conversation style:
+
+```text
+You: I have an idea for a meal-planning app. Let's brainstorm v1 scope.
+LLM: Great. I can capture key decisions and open questions in global memory while we explore.
+
+You: Please remember that the app should build weekly meals from pantry items, and avoid recipes with too many missing ingredients.
+You: Also remember that I'm undecided on mobile-first vs web-first.
+```
+
+When the idea becomes a real repo, switch to that project context and ask the LLM to migrate only the notes that became project-specific.
+
+```text
+You: We're creating the repo now at /path/to/meal-planner.
+You: Recall my earlier meal-planner brainstorm notes and move the implementation-relevant ones into this project's vault.
+```
+
+This keeps early ideation reusable as personal/global knowledge while moving concrete project context into `.mnemonic/` once collaboration and implementation begin.
+
 **How does mnemonic differ from Beads?**
 
 mnemonic and Beads address complementary concerns. mnemonic is a **knowledge graph**: it stores notes, relationships between them, and lets agents retrieve relevant context through semantic search. [Beads](https://github.com/steveyegge/beads) is a **task and dependency tracker**: it models work items and their dependencies so agents can determine what is ready to execute next. Both tools can coexist in the same workflow — mnemonic stores knowledge and reasoning while Beads manages execution.