v1.6.0 — Project registry + remote-based scoping
v1.6.0 — Project registry + remote-based scoping
The Problem
Memories were scoped by the repo's filesystem path. If you deleted, moved, or re-cloned a repo to a different path, the memories became orphaned — still on disk but inaccessible by default. --project memgraph only worked if you were inside the memgraph repo.
The Fix — Three Layers
1. Git remote as scope key
When a repo has a remote, the remote URL (normalized) is used as the scope key instead of the local path. Clone the same repo to any path → same scope. Move the repo → same scope.
2. Project registry (~/.memgraph/projects.json)
Maps human-readable names to memory dirs. --project memgraph resolves via the registry and works from any directory. Auto-imports existing scopes on first run.
3. memgraph attach command
memgraph attach <name>— register current repo under a stable namememgraph attach <name> --from-scope <scope>— rebind an orphaned scopememgraph attach --remove <name>— unregister
Scope Resolution Order
--memory-dir <path>(explicit override)--project <name>via registry (global, works from any dir)- Git remote-based scope (if repo has a remote)
- Git path-based scope (backward compat for existing memories)
- Default
.memgraphdir (no git repo)
Backward Compatibility
Old path-based scopes are still accessible. When resolving scope for a repo with a remote, memgraph checks if a remote-based scope exists first, then falls back to the path-based scope. New memories go to the remote-based scope.
Cold-Start Verified
An agent with zero memgraph knowledge, starting from /tmp (no git repo), successfully:
memgraph projects→ discovered 19 projects with namesmemgraph recall "commands usage" --project memgraph --format index→ got section indexmemgraph read <id>/<slug> --project memgraph→ read specific sections
No --memory-dir, no cd, no prior knowledge required.
Stats
- 42 tests pass with
-race - Pure Go stdlib, zero external dependencies
- New file:
registry.go(project registry + auto-import)