[FEAT] user-level memory layer (v3.0.0)

[gradyzhuo]

Summary

Adds a true user-global memory layer at ~/.orrery/user/memory/ — cross-project, cross-env personal memory served via:

• SessionStart hooks auto-installed into each env's Claude / Codex / Gemini config so the user memory loads at every session start (controlled by per-env shareUserMemory, default enabled).
• MCP tools orrery_user_memory_read and orrery_user_memory_write for programmatic writes.
• New CLI: orrery memory user info / path / emit / export / enable / disable.
• Wizard prompts on orrery create and orrery setup, plus a --no-user-memory flag.

Restores the user-level memory concept that Claude Code never natively provided and that origin takeover incidentally masked (~/.claude/CLAUDE.md got folded into the origin env).

Breaking change → v3.0.0

orrery memory <info|export|isolate|share|storage> is renamed to orrery memory project <...>. No aliases. Scripts must be updated. CHANGELOG has a dedicated note.

Design & Plan

• Spec: docs/superpowers/specs/2026-05-18-user-level-memory-layer-design.md
• Plan: docs/superpowers/plans/2026-05-19-user-level-memory-layer.md (23 TDD tasks)

Architecture

• MemoryStore value type encapsulates MEMORY.md + fragments/ read/write logic — shared between project- and user-layer.
• UserMemoryHookInstaller protocol + JSONHookEditor shared logic; per-tool installers for Claude (settings.json), Codex (hooks.json), Gemini (<env>/gemini/settings.json).
• Entries carry _orrery_managed: true marker so remove never clobbers foreign hook entries.
• _reconcile-user-memory-hooks internal command runs on every orrery use to converge hook state to env config.
• OrreryEnvironment and OriginConfig both gain a shareUserMemory: Bool field (defaults to true; legacy JSON decodes tolerantly).

Test plan

• swift test — 172 tests in 46 suites pass (38 new tests vs. main baseline).
• Tests cover: MemoryStore read/write/emit/fragments, all 3 *HookInstaller lifecycles + foreign-entry preservation, EnvironmentStore.ensureUserMemoryHooks gating on shareUserMemory, addTool auto-install, applyEnable/applyDisable persistence + hook side effects, MemoryCommand structural rename.
• Manual smoke: orrery --version prints 3.0.0; orrery memory --help shows only project + user; orrery memory user emit prints empty on fresh install and prints content when seeded.

Follow-ups (non-blocking, from final code review)

• I-1: orrery origin takeover doesn't install user-memory hooks (self-heals on next orrery use; one-line fix).
• I-2: Inconsistent try vs try? for hook install errors in addTool vs ensureUserMemoryHooks.
• I-3: --user-memory flag is a silent no-op (ArgumentParser .prefixedNo limitation); document or split keys.
• M-2: Three copies of the "Pending Memory Fragments" template (MemoryStore.emit + readMemory + readUserMemory in MCPServer) — consolidate when a third unrelated caller appears.
• M-4: No integration test for CreateCommand --no-user-memory flag through full CLI parse.

🤖 Generated with Claude Code