claude_memory 0.13.1 → 0.13.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/.claude-plugin/marketplace.json +1 -1
- data/.claude-plugin/plugin.json +1 -1
- data/CHANGELOG.md +15 -0
- data/docs/improvements.md +4 -0
- data/lib/claude_memory/commands/checks/fts_rank_check.rb +60 -0
- data/lib/claude_memory/commands/doctor_command.rb +2 -0
- data/lib/claude_memory/commands/index_command.rb +22 -4
- data/lib/claude_memory/commands/setup_vectors_command.rb +9 -3
- data/lib/claude_memory/index/lexical_fts.rb +47 -23
- data/lib/claude_memory/index/vector_index.rb +27 -0
- data/lib/claude_memory/mcp/server.rb +33 -1
- data/lib/claude_memory/sweep/maintenance.rb +22 -0
- data/lib/claude_memory/sweep/sweeper.rb +1 -0
- data/lib/claude_memory/version.rb +1 -1
- data/lib/claude_memory.rb +1 -0
- metadata +2 -25
- data/.claude/CLAUDE.md +0 -4
- data/.claude/memory.sqlite3 +0 -0
- data/.claude/output-styles/memory-aware.md +0 -1
- data/.claude/rules/claude_memory.generated.md +0 -87
- data/.claude/settings.json +0 -113
- data/.claude/settings.local.json +0 -59
- data/.claude/skills/check-memory/DEPRECATED.md +0 -29
- data/.claude/skills/check-memory/SKILL.md +0 -87
- data/.claude/skills/dashboard/SKILL.md +0 -42
- data/.claude/skills/debug-memory +0 -1
- data/.claude/skills/improve/SKILL.md +0 -631
- data/.claude/skills/improve/feature-patterns.md +0 -1221
- data/.claude/skills/memory-first-workflow +0 -1
- data/.claude/skills/quality-update/SKILL.md +0 -229
- data/.claude/skills/quality-update/implementation-guide.md +0 -346
- data/.claude/skills/release/SKILL.md +0 -206
- data/.claude/skills/review-commit/SKILL.md +0 -199
- data/.claude/skills/review-for-quality/SKILL.md +0 -154
- data/.claude/skills/review-for-quality/expert-checklists.md +0 -79
- data/.claude/skills/setup-memory +0 -1
- data/.claude/skills/study-repo/SKILL.md +0 -322
- data/.claude/skills/study-repo/analysis-template.md +0 -323
- data/.claude/skills/study-repo/focus-examples.md +0 -327
- data/.claude/skills/upgrade-dependencies/SKILL.md +0 -154
|
@@ -1,87 +0,0 @@
|
|
|
1
|
-
<!--
|
|
2
|
-
This file is auto-generated by claude-memory.
|
|
3
|
-
Do not edit manually - changes will be overwritten.
|
|
4
|
-
Generated: 2026-06-16T18:31:16Z
|
|
5
|
-
-->
|
|
6
|
-
|
|
7
|
-
# Project Memory
|
|
8
|
-
|
|
9
|
-
## Current Decisions
|
|
10
|
-
|
|
11
|
-
- From Mastra Observational Memory study: add an episodic observation layer that augments (not replaces) the dynamic-recall semantic fact store — because facts answer 'what is true' and observations answer 'what happened', and claude_memory currently lacks the episodic half; recall stays for targeted lookups.
|
|
12
|
-
- From Mastra Observational Memory study: make observation reflection automatic via the PreCompact and SessionEnd hooks rather than a manual-only skill — because Claude Code exposes no timer/cron hook, but PreCompact fires on context pressure (the analog of Mastra's token threshold) and rides the existing session at no extra API cost.
|
|
13
|
-
- From Mastra Observational Memory study: run the Reflector's deterministic GC shell-side in Ruby and its semantic consolidation via PreCompact additionalContext (Claude-as-reflector inline) — to keep automatic reflection within the no-extra-API-cost convention, explicitly rejecting Claude Code Routines and subagents because each incurs a separate token budget.
|
|
14
|
-
- From Mastra Observational Memory study: tombstone superseded observations via a consolidated_into link rather than hard-deleting them (unlike Mastra's lossy drop) — to preserve claude_memory's provenance guarantee while still bounding context size.
|
|
15
|
-
- From Mastra Observational Memory study: promote an observation to a structured fact only after corroboration across multiple observations — because requiring repeated sightings before commitment doubles as an anti-hallucination gate against reject-churn from one-off doc/example text.
|
|
16
|
-
- MCP tool-call telemetry stores minimal columns (tool_name, duration_ms, result_count, scope, error_class) — deliberately no query_text or query_hash. YAGNI: hashes are write-only without the raw text, and raw text adds privacy concerns without clear value beyond existing shortcut tools (memory.decisions, memory.conventions). — to avoid storing query hashes that are write-only without the raw text.
|
|
17
|
-
- From QMD 2026-02-02 restudy: adopt Claude Code plugin format, MCP structured content pattern, MCP query guide prompt, inline status checks. Carry forward sqlite-vec, RRF, docids, smart expansion from 2026-01-26. Reject custom fine-tuned models, LLM reranking, YAML collections. — to align with our pure-Ruby/SQLite constraints (no GGUF, no LLM-side fine-tuning).
|
|
18
|
-
- From claude-supermemory study: adopt SessionStart hook context injection (hookSpecificOutput.additionalContext), tool-specific observation compression, and relative time formatting. Reject cloud storage dependency and no-test approach. — to avoid cloud-storage lock-in and no-test fragility identified in the study.
|
|
19
|
-
|
|
20
|
-
## Conventions
|
|
21
|
-
|
|
22
|
-
- A/B testing methodology for memory plugin evaluation — How to test with/without memory using claude CLI — --plugin-dir doesn't work with --bare, use --mcp-config instead — To A/B test memory's impact on Claude Code responses: (imported from project auto-memory; see source file for full reasoning) — to enable head-to-head measurement of memory's impact on Claude Code responses.
|
|
23
|
-
- do...end blocks over braces when args repeat or block is non-trivial — Block syntax preference for multi-argument or multi-expression blocks — When a block call has repeated argument names, multiple expressions, or reads awkwardly on one line, use `do...end` form rather than `{ }`. One-liners with simple single-expression bodies and short argument lists are fine with braces. (imported from project auto-memory; see source file for full reasoning) — to keep multi-line blocks readable and avoid brace/multi-expression awkwardness.
|
|
24
|
-
- Always commit .claude/memory.sqlite3 — Per user direction (2026-05-21), .claude/memory.sqlite3 should be staged and committed alongside any change that updates project memory — even though it's a binary SQLite DB with WAL artifacts. — Always include `.claude/memory.sqlite3` in commits that touch project memory or knowledge. (imported from project auto-memory; see source file for full reasoning) — to ensure project memory is reproducible across collaborators.
|
|
25
|
-
- Commit workflow preferences — How the user prefers commits to be structured and when to make them — Wait for the user to ask for commits — don't commit proactively. When asked, group changes into logical atomic commits: (imported from project auto-memory; see source file for full reasoning)
|
|
26
|
-
- Data-driven analysis before design changes — User expects thorough multi-project data surveys and critical questioning of assumptions before committing to architectural changes — When proposing design changes (especially to schemas, vocabularies, or policies), gather real usage data first and present a critical analysis before implementing. (imported from project auto-memory; see source file for full reasoning) — to avoid premature architectural commitments before real usage data is in hand.
|
|
27
|
-
- Fix hallucination triggers at the source, not via repeated reject churn — When the distiller repeatedly produces the same wrong fact, trace it to the CLAUDE.md / docs example text; fixing the source stops re-appearance — When the dashboard's Conflicts tab accumulates clusters of the same kind of bad fact (e.g. many `uses_database` contradictions against `sqlite`), the root cause is almost always **example text in documentation** that the distiller is interpreting as a literal claim about the current repo. Single-value predicates (`uses_database`, `deployment_platform`, `auth_method`) are especially vulnerable becau... (imported from project auto-memory; see source file for full reasoning) — because reject-only is treating symptoms; the root cause is doc/example text the distiller mistakes for project claims.
|
|
28
|
-
- Hooks run the installed gem, not the working copy — always `rake install` after editing hook/MCP code — .claude/settings.json hooks invoke `claude-memory` via PATH, so changes on a branch only take effect after `bundle exec rake install` — `.claude/settings.json` hooks call bare `claude-memory hook ingest` / `claude-memory hook context` / etc. That resolves via PATH to the installed gem, not the working-copy `./exe/claude-memory`. After editing any hook/MCP/distiller code on a branch, the change does NOT reach Claude Code until `bundle exec rake install` rebuilds and reinstalls the gem (which overwrites the prior install at the same ... (imported from project auto-memory; see source file for full reasoning) — to ensure code changes reach the production hooks, which invoke the installed gem via PATH.
|
|
29
|
-
- No extra API costs for features — User strongly prefers using Claude Code itself (skills, context hooks) over separate API calls that cost extra money — Do not add features that require separate Anthropic API calls (e.g., via anthropic-rb gem) when Claude Code itself can perform the same task. Use skills, context hook injection, and MCP tools to leverage the existing Claude Code session instead. (imported from project auto-memory; see source file for full reasoning) — to avoid hidden ongoing spend that bypasses the Claude Code session's existing budget.
|
|
30
|
-
- Quality review update cycle — Keep quality_review.md current as items are resolved — don't let it drift — When completing quality review items, update `docs/quality_review.md` immediately: (imported from project auto-memory; see source file for full reasoning) — to prevent quality_review.md from drifting out of date.
|
|
31
|
-
- Refactoring approach preferences — How to approach god object extraction and structural refactoring in this codebase — Use module inclusion (not class extraction) when breaking up god objects. Include modules directly into the existing class so the public API is unchanged and zero tests need modification. This was validated three times:
|
|
32
|
-
- Round-trip migration specs cover each prior release boundary — For pre-release prep, write end-to-end migration specs from every distinct schema boundary back through ~3 prior releases — Before cutting a release that includes migrations, add round-trip specs that fixture an older DB at each distinct prior release's schema version, open via `SQLiteStore.new`, and assert the full upgrade path: schema_info advancement, data preservation across entities/facts/content_items/provenance, additive table/column creation, predicate-rewrite effects where applicable, and idempotency on re-open... (imported from project auto-memory; see source file for full reasoning) — to ensure migrations remain forward-compatible across release boundaries.
|
|
33
|
-
- Codify behavioral contracts in tests, not just comments — When code has a deliberate scope limitation (one-shot, advisory-only, intentionally non-idempotent), write a test that fails if someone "fixes" it into being more general — When code has a deliberate scope limitation — a one-shot data migration, an advisory-only field, a method intentionally not idempotent for new inputs — write a test that exercises a scenario which would *break* if someone tried to make it more general. (imported from project auto-memory; see source file for full reasoning)
|
|
34
|
-
- Treat UX gaps as architecture smells — user inspection/debugging questions expose god classes and missing abstractions — When users ask "can I see/debug/act on X in the dashboard?", the answer is almost always "we need a new class or route, not a new button" — Across three architectural reviews in the 2026-04-17 → 20 session, every concrete UX gap the user identified traced back to a structural issue the code already had, not a frontend-only fix. Treating critique as a forcing function for refactoring produced cleaner results than either extracting preemptively (premature) or patching only the surface (symptom). (imported from project auto-memory; see source file for full reasoning) — because frontend patches usually mask structural debt that surfaces later.
|
|
35
|
-
- "database disk image is malformed" from FTS5 `ORDER BY rank` after sqlite3 .recover — sqlite3 .recover restores rows but can leave contentless FTS5 auxiliary indexes in a state where basic MATCH works but ORDER BY rank throws "malformed"; fix is `claude-memory compact` to rebuild the FTS index — A DB recovered via `sqlite3 corrupt.db .recover > dump.sql && sqlite3 fresh.db < dump.sql` can end up with an FTS5 index that's *partially* functional: (imported from project auto-memory; see source file for full reasoning) — fix is claude-memory compact to rebuild the FTS index without doing another .recover.
|
|
36
|
-
- `rake install` uses `git ls-files`; untracked files silently disappear from the gem — Running `bundle exec rake install` before staging new files produces a gem missing those files, causing LoadError in hooks and MCP server — The claude_memory gemspec builds its file list via `IO.popen(%w[git ls-files -z], ...)` (claude_memory.gemspec:24). Any file that hasn't been `git add`ed at build time is **invisible to the gem** even though it exists on disk. The local working copy keeps running fine (dashboard server uses `./exe/claude-memory` against the repo directly), but the installed gem at `~/.gem/ruby/*/gems/claude_memory-... (imported from project auto-memory; see source file for full reasoning) — to ensure new files reach the installed gem (the gemspec uses git ls-files for the manifest).
|
|
37
|
-
- Distiller scope_hint is advisory, not a routing signal — NullDistiller emits scope_hint: "global" for text matching GLOBAL_SCOPE_PATTERNS, but the resolver never routes writes between stores — scope_hint must not override fact.scope — `Distill::NullDistiller#global_scope_signal?` matches text like "always" / "my preference" / "in all projects" and stamps `scope_hint: "global"` on every fact extracted from that text. The hint is advisory metadata for downstream promotion decisions. It is NOT a routing signal — the resolver writes to whichever `SQLiteStore` was injected into it (always the project DB in the normal ingest path), re... (imported from project auto-memory; see source file for full reasoning) — to prevent scope drift between resolver-determined store and distiller-stamped hint.
|
|
38
|
-
- Sequel DB reads must use the extralite adapter — Opening a SQLite DB for ad-hoc reads requires the extralite adapter URI; Sequel.sqlite silently depends on an ungem'd sqlite3 — Never use `Sequel.sqlite(db_path)` or `Sequel.sqlite(db_path, readonly: true)` in this codebase. The gemspec lists only `extralite (~> 2.14)` — it does **not** depend on the `sqlite3` gem. `Sequel.sqlite` routes through Sequel's `sqlite` adapter which requires `gem "sqlite3"` and will raise `Sequel::AdapterNotFound: LoadError: cannot load such file -- sqlite3` at runtime. (imported from project auto-memory; see source file for full reasoning) — to avoid Sequel::AdapterNotFound at runtime (this gem doesn't depend on the sqlite3 adapter).
|
|
39
|
-
- Never `git checkout --` an active SQLite DB with WAL mode — Using `git checkout --` on .claude/memory.sqlite3 while readers/writers are open corrupts the DB via WAL/main file mismatch — Never run `git checkout -- .claude/memory.sqlite3` (or any SQLite DB in WAL mode) while any process has it open. Git replaces only the main DB file, leaving the WAL/SHM sidecar files referencing pages that no longer exist in the replaced file. Next read → "Extralite::Error: database disk image is malformed" and integrity_check shows btree errors across multiple trees. (imported from project auto-memory; see source file for full reasoning) — to avoid WAL/main file mismatch corruption.
|
|
40
|
-
- SQLiteStore silently creates in-memory DB for relative paths — `SQLiteStore.new('.claude/memory.sqlite3')` with a relative path opens an empty in-memory DB, not the file — always pass absolute paths in tests/probes — `SQLiteStore.new(path)` builds a Sequel URI as `extralite:#{path}`. With a relative path like `.claude/memory.sqlite3`, the resulting URI `extralite:.claude/memory.sqlite3` is parsed with an empty database component, so Extralite opens an in-memory database. Schema migrations run against the in-memory DB (so `schema_version` reports the current version), but ALL queries return 0 rows and the real f... (imported from project auto-memory; see source file for full reasoning) — to ensure SQLiteStore opens the real file rather than a silent in-memory shadow.
|
|
41
|
-
- Two tool_calls tables exist — don't conflate them — tool_calls (v3) stores transcript-observed Claude Code tool usage; mcp_tool_calls (v13) stores MCP server telemetry — There are **two** tables with similar names serving different purposes: (imported from project auto-memory; see source file for full reasoning) — to avoid joining unrelated rows from disjoint telemetry tables.
|
|
42
|
-
- Distiller hallucination from CLAUDE.md example text — The scope-system example in CLAUDE.md causes recurring false fact extraction — reject + re-ingest creates rejection churn — CLAUDE.md contains a scope-system explanation with example text: (imported from project auto-memory; see source file for full reasoning) — to prevent re-extraction churn from documentation example text that the distiller takes literally.
|
|
43
|
-
- PredicatePolicy is the single source of truth for predicate vocabulary — All predicate knowledge (vocabulary, cardinality, sections, synonyms, LLM guidance) derives from PredicatePolicy — never hardcode predicate names elsewhere — As of 0.9.0, `PredicatePolicy` in `lib/claude_memory/resolve/predicate_policy.rb` is the authoritative source for all predicate-related behavior. This was a deliberate consolidation after finding the same predicate list duplicated in 4 files that drifted independently. (imported from project auto-memory; see source file for full reasoning) — to avoid divergent predicate lists across files that drifted independently before consolidation.
|
|
44
|
-
- Hook-telemetry features need a manual hook trigger to verify in production, not just specs — `bundle exec rake install` AND fire a real hook AND check `sqlite3 ... json_extract(detail_json, '$.<field>')`, because specs assert against working-tree code but `.claude/settings.json` hooks invoke the installed gem via PATH so the asserted field can be silently absent in production. Hit on 2026-04-30 shipping #47 token-budget telemetry: 156 specs green but `context_tokens` was missing from 24h of real activity_events.
|
|
45
|
-
- When verifying any new field on activity_events.detail_json, the canonical smoke test is: `echo '{"hook_event_name":"SessionStart","session_id":"smoketest","source":"startup","cwd":"$(pwd)"}' | claude-memory hook context` then inspect via `sqlite3 .claude/memory.sqlite3 "SELECT json_extract(detail_json, '$.<field>') FROM activity_events WHERE event_type='hook_context' ORDER BY id DESC LIMIT 1"`. If null after rake install, the installed gem code hasn't picked up the change. — to ensure the installed gem actually picks up new detail_json fields.
|
|
46
|
-
- Treat UX gaps as architecture smells: when a user asks "can I see/debug/act on X in the dashboard?" the answer is almost always a missing class or route, not a new button. Every UX critique in this project's dashboard work traced to a structural gap — god-class growth, four drifting fact serializers, scope_hint as silent scope override, no fact detail endpoint. Pattern: the surface question is usually a router into the architecture. Before reaching for frontend fixes, ask "what server-side data shape would make this easy?" — if that shape doesn't exist cleanly, treat it as the real work. Commit refactor separately from feature it enables ([Refactor]/[Feature]/[Fix] prefixes) so the critique→structural fix→UX fix chain is visible in git log.
|
|
47
|
-
- Four-surface staleness: after any change that touches UI + backend + plugin-launched binaries, refresh all four or the change looks broken. (1) bundle exec rake install so the installed gem catches up (hooks + MCP launched by Claude Code run from PATH). (2) Ctrl-C and re-run ./exe/claude-memory dashboard — server is long-lived Ruby, no live-reload. (3) /mcp reconnect in Claude Code so the MCP subprocess respawns. (4) Hard-refresh browser (Cmd-Shift-R) so cached index.html JS reloads. Skipping any produces confusing "my fix doesn't work." rspec green does NOT mean end-to-end works; before declaring UI-affecting changes done, curl the endpoint and verify shape matches frontend expectation. curl alt-port dashboard (--port 3388 --no-open in background) is fastest smoke test without disturbing user's running dashboard.
|
|
48
|
-
- MCP tool-call telemetry is recorded via MCP::Telemetry wrapping Server#handle_tools_call. Writes to mcp_tool_calls table in the project DB. Swallows DB errors so telemetry never breaks a real tool response. Viewable via 'claude-memory stats --tools [--since DAYS]'. — to ensure telemetry never breaks a real tool response (DB errors are swallowed).
|
|
49
|
-
- mcp_tool_calls retention is 90 days, enforced by Sweep::Maintenance#prune_old_mcp_tool_calls wired into Sweeper#run!. Configurable via mcp_tool_call_retention_days in Maintenance DEFAULT_CONFIG. — long enough to support quarterly tool-usage retrospectives without unbounded DB growth.
|
|
50
|
-
- CLAUDE_CONFIG_DIR env var overrides the default ~/.claude location for Configuration#global_db_path. Access via Configuration#claude_config_dir. Additive, backwards compatible. — to support test isolation and air-gapped installs that don't touch ~/.claude.
|
|
51
|
-
- Registry::COMMANDS stores {class:, description:} entries as the single source of truth for command name, class reference, and shell-completion description. Class constants stored directly (no const_get). Registry.descriptions feeds CompletionCommand; adding a new command requires updating only this hash. — to ensure adding a command requires only this hash update (no const_get, no description duplication).
|
|
52
|
-
- EXPECTED_HOOKS constant must stay in sync with events in HooksConfigurator#build_hooks_config. Adding a new hook event without updating EXPECTED_HOOKS causes false doctor warnings. — without this sync the doctor reports false hook-mismatch warnings.
|
|
53
|
-
- Tests using --db for hook context only set the project DB path. StoreManager still connects to the real global DB. Must stub Configuration to return a temp global path for isolation. — to ensure test isolation from the user's real global DB.
|
|
54
|
-
- Version must be updated in three places: lib/claude_memory/version.rb, .claude-plugin/plugin.json, .claude-plugin/marketplace.json. Runtime code uses ClaudeMemory::VERSION dynamically. — to ensure plugin/marketplace metadata matches the gem version on release.
|
|
55
|
-
- Use module inclusion (not class extraction) to break up god objects — preserves public API so zero tests need modification — to avoid breaking the public API and forcing test updates during god-object cleanup.
|
|
56
|
-
- Configuration class has instance methods only — use Configuration.new.global_db_path, not Configuration.global_db_path. Stub with instance_double + allow(Configuration).to receive(:new).and_return(config) — to make Configuration stubbable in tests via instance_double.
|
|
57
|
-
- OperationTracker.reset_stuck_operations only resets operations older than 24 hours (STALE_THRESHOLD_SECONDS). Tests must backdate started_at to trigger resets. — to prevent the reset from clobbering operations still legitimately in flight.
|
|
58
|
-
- SCHEMA_VERSION constant lives in Store::SchemaManager module but is accessible as SQLiteStore::SCHEMA_VERSION via Ruby include-based constant lookup — accessible via include because Ruby's constant lookup walks the inclusion chain.
|
|
59
|
-
- MCP tools return dual content (text summary) + structuredContent (JSON) via TextSummary module and Server#handle_tools_call. Compact mode (compact: true) omits receipts for ~60% smaller responses. — so that compact-mode callers pay ~60% fewer tokens per response.
|
|
60
|
-
- ContentSanitizer strips system-reminder, local-command-caveat, command-message, command-name, command-args tags in addition to private/no-memory/secret/claude-memory-context. — to prevent harness-internal tags from being ingested as user content.
|
|
61
|
-
- Core::RelativeTime module provides progressive time formatting: just now → Xm ago → Xh ago → Xd ago → YYYY-MM-DD. Used in ResponseFormatter for *_ago fields. — to make stale-fact warnings legible across both recent and old timestamps.
|
|
62
|
-
- MCP server registers memory_guide prompt via prompts/list and prompts/get endpoints. QueryGuide module holds prompt content. — to ensure memory_guide is discoverable via the standard MCP prompt registry.
|
|
63
|
-
|
|
64
|
-
## Technical Constraints
|
|
65
|
-
|
|
66
|
-
- **Uses framework**: django
|
|
67
|
-
- **Uses language**: typescript
|
|
68
|
-
- **Uses language**: python
|
|
69
|
-
- **Uses framework**: rails
|
|
70
|
-
- **Uses framework**: react
|
|
71
|
-
- **Uses framework**: sinatra
|
|
72
|
-
- **Uses language**: javascript
|
|
73
|
-
- **Uses language**: go
|
|
74
|
-
- **Uses language**: ruby
|
|
75
|
-
- **Uses database**: sqlite
|
|
76
|
-
|
|
77
|
-
## Additional Knowledge
|
|
78
|
-
|
|
79
|
-
### Architecture
|
|
80
|
-
|
|
81
|
-
- mcp_server: Claude Code does NOT pass its session_id into plugin-spawned MCP server subprocesses — neither via JSON-RPC transport nor CLAUDE_SESSION_ID env var. Configuration.new.session_id returns nil inside the MCP process, so MCP-originated activity events (recall, store_extraction) get session_id=nil. Hook commands are different — .claude/settings.json payloads explicitly include session_id in their JSON. For dashboards or any feature that needs per-session attribution of MCP-originated events, correlate by time window using hook events (which do carry session_id) rather than strict session_id equality. Dashboard::API#efficacy uses session_window + within_window? for this.
|
|
82
|
-
- MCP::Tools: Thin 104-line dispatcher that includes 6 handler modules in mcp/handlers/: QueryHandlers, ShortcutHandlers, ContextHandlers, ManagementHandlers, StatsHandlers, SetupHandlers
|
|
83
|
-
- Recall: 94-line facade delegating to @engine (DualEngine or LegacyEngine), both include shared QueryCore module with all store-level query logic
|
|
84
|
-
- SQLiteStore: 386-line CRUD class that includes RetryHandler (retry/connection logic) and SchemaManager (migrations/version sync) modules
|
|
85
|
-
- Embeddings: Pluggable providers via Embeddings.resolve(name, env:). Three providers: tfidf (default), fastembed, api. Duck-typed contract: name, dimensions, generate(text). ENV: CLAUDE_MEMORY_EMBEDDING_PROVIDER
|
|
86
|
-
- Embeddings::DimensionCheck: Pure value object — DimensionCheck.call(store, provider) returns Data.define Result with :fresh/:match/:mismatch status. No side effects; caller decides how to handle mismatch.
|
|
87
|
-
|
data/.claude/settings.json
DELETED
|
@@ -1,113 +0,0 @@
|
|
|
1
|
-
{
|
|
2
|
-
"hooks": {
|
|
3
|
-
"Stop": [
|
|
4
|
-
{
|
|
5
|
-
"hooks": [
|
|
6
|
-
{
|
|
7
|
-
"type": "command",
|
|
8
|
-
"command": "claude-memory hook ingest --db /Users/valentinostoll/src/claude_memory/.claude/memory.sqlite3",
|
|
9
|
-
"timeout": 5,
|
|
10
|
-
"statusMessage": "Saving memory..."
|
|
11
|
-
}
|
|
12
|
-
]
|
|
13
|
-
}
|
|
14
|
-
],
|
|
15
|
-
"StopFailure": [
|
|
16
|
-
{
|
|
17
|
-
"hooks": [
|
|
18
|
-
{
|
|
19
|
-
"type": "command",
|
|
20
|
-
"command": "claude-memory hook ingest --db /Users/valentinostoll/src/claude_memory/.claude/memory.sqlite3",
|
|
21
|
-
"timeout": 5,
|
|
22
|
-
"statusMessage": "Saving memory..."
|
|
23
|
-
}
|
|
24
|
-
]
|
|
25
|
-
}
|
|
26
|
-
],
|
|
27
|
-
"SessionStart": [
|
|
28
|
-
{
|
|
29
|
-
"hooks": [
|
|
30
|
-
{
|
|
31
|
-
"type": "command",
|
|
32
|
-
"command": "claude-memory hook context",
|
|
33
|
-
"timeout": 5,
|
|
34
|
-
"statusMessage": "Loading memory..."
|
|
35
|
-
}
|
|
36
|
-
]
|
|
37
|
-
}
|
|
38
|
-
],
|
|
39
|
-
"PreCompact": [
|
|
40
|
-
{
|
|
41
|
-
"hooks": [
|
|
42
|
-
{
|
|
43
|
-
"type": "command",
|
|
44
|
-
"command": "claude-memory hook ingest --db /Users/valentinostoll/src/claude_memory/.claude/memory.sqlite3",
|
|
45
|
-
"timeout": 30,
|
|
46
|
-
"statusMessage": "Saving memory..."
|
|
47
|
-
},
|
|
48
|
-
{
|
|
49
|
-
"type": "command",
|
|
50
|
-
"command": "claude-memory hook sweep --db /Users/valentinostoll/src/claude_memory/.claude/memory.sqlite3",
|
|
51
|
-
"timeout": 30,
|
|
52
|
-
"statusMessage": "Sweeping memory..."
|
|
53
|
-
}
|
|
54
|
-
]
|
|
55
|
-
}
|
|
56
|
-
],
|
|
57
|
-
"SessionEnd": [
|
|
58
|
-
{
|
|
59
|
-
"hooks": [
|
|
60
|
-
{
|
|
61
|
-
"type": "command",
|
|
62
|
-
"command": "claude-memory hook ingest --db /Users/valentinostoll/src/claude_memory/.claude/memory.sqlite3",
|
|
63
|
-
"timeout": 30,
|
|
64
|
-
"statusMessage": "Saving memory..."
|
|
65
|
-
},
|
|
66
|
-
{
|
|
67
|
-
"type": "command",
|
|
68
|
-
"command": "claude-memory hook sweep --db /Users/valentinostoll/src/claude_memory/.claude/memory.sqlite3",
|
|
69
|
-
"timeout": 30,
|
|
70
|
-
"statusMessage": "Sweeping memory..."
|
|
71
|
-
}
|
|
72
|
-
]
|
|
73
|
-
}
|
|
74
|
-
],
|
|
75
|
-
"TaskCompleted": [
|
|
76
|
-
{
|
|
77
|
-
"hooks": [
|
|
78
|
-
{
|
|
79
|
-
"type": "command",
|
|
80
|
-
"command": "claude-memory hook ingest --db /Users/valentinostoll/src/claude_memory/.claude/memory.sqlite3",
|
|
81
|
-
"timeout": 10,
|
|
82
|
-
"statusMessage": "Saving memory..."
|
|
83
|
-
}
|
|
84
|
-
]
|
|
85
|
-
}
|
|
86
|
-
],
|
|
87
|
-
"TeammateIdle": [
|
|
88
|
-
{
|
|
89
|
-
"hooks": [
|
|
90
|
-
{
|
|
91
|
-
"type": "command",
|
|
92
|
-
"command": "claude-memory hook ingest --db /Users/valentinostoll/src/claude_memory/.claude/memory.sqlite3",
|
|
93
|
-
"timeout": 15,
|
|
94
|
-
"statusMessage": "Saving memory..."
|
|
95
|
-
}
|
|
96
|
-
]
|
|
97
|
-
}
|
|
98
|
-
],
|
|
99
|
-
"Notification": [
|
|
100
|
-
{
|
|
101
|
-
"matcher": "idle_prompt",
|
|
102
|
-
"hooks": [
|
|
103
|
-
{
|
|
104
|
-
"type": "command",
|
|
105
|
-
"command": "claude-memory hook sweep --db /Users/valentinostoll/src/claude_memory/.claude/memory.sqlite3",
|
|
106
|
-
"timeout": 10,
|
|
107
|
-
"statusMessage": "Sweeping memory..."
|
|
108
|
-
}
|
|
109
|
-
]
|
|
110
|
-
}
|
|
111
|
-
]
|
|
112
|
-
}
|
|
113
|
-
}
|
data/.claude/settings.local.json
DELETED
|
@@ -1,59 +0,0 @@
|
|
|
1
|
-
{
|
|
2
|
-
"permissions": {
|
|
3
|
-
"allow": [
|
|
4
|
-
"mcp__claude-memory__memory_changes",
|
|
5
|
-
"mcp__claude-memory__memory_status",
|
|
6
|
-
"mcp__claude-memory__memory_recall",
|
|
7
|
-
"Bash(./exe/claude-memory:*)",
|
|
8
|
-
"mcp__claude-memory__memory_store_extraction",
|
|
9
|
-
"mcp__plugin_claude-memory_claude-memory__memory_store_extraction",
|
|
10
|
-
"mcp__plugin_claude-memory_claude-memory__memory_recall",
|
|
11
|
-
"mcp__plugin_claude-memory_claude-memory__memory_status",
|
|
12
|
-
"mcp__plugin_claude-memory_memory__memory_recall",
|
|
13
|
-
"mcp__memory__memory_recall",
|
|
14
|
-
"mcp__memory__memory_changes",
|
|
15
|
-
"mcp__memory__memory_status",
|
|
16
|
-
"mcp__memory__memory_store_extraction",
|
|
17
|
-
"mcp__memory__memory_explain",
|
|
18
|
-
"Bash(bundle exec rspec:*)",
|
|
19
|
-
"Bash(bundle exec rake:*)",
|
|
20
|
-
"mcp__plugin_claude-memory_memory__memory_store_extraction",
|
|
21
|
-
"WebFetch(domain:raw.githubusercontent.com)",
|
|
22
|
-
"Bash(grep:*)",
|
|
23
|
-
"Bash(gem list:*)",
|
|
24
|
-
"Bash(ag:*)",
|
|
25
|
-
"Bash(git log:*)",
|
|
26
|
-
"Bash(find:*)",
|
|
27
|
-
"Bash(wc:*)",
|
|
28
|
-
"mcp__plugin_claude-memory_memory__memory_architecture",
|
|
29
|
-
"mcp__plugin_claude-memory_memory__memory_recall_index",
|
|
30
|
-
"Bash(./bin/run-evals:*)",
|
|
31
|
-
"WebSearch",
|
|
32
|
-
"mcp__memory__memory_check_setup",
|
|
33
|
-
"WebFetch(domain:docs.anthropic.com)",
|
|
34
|
-
"Bash(export PATH=\"$HOME/.bun/bin:/usr/bin:/bin:$PATH\")",
|
|
35
|
-
"Bash(qmd search:*)",
|
|
36
|
-
"Skill(study-repo)",
|
|
37
|
-
"WebFetch(domain:www.rubydoc.info)",
|
|
38
|
-
"Bash(git status:*)",
|
|
39
|
-
"WebFetch(domain:github.com)",
|
|
40
|
-
"mcp__memory__memory_stats",
|
|
41
|
-
"mcp__memory__memory_recall_index",
|
|
42
|
-
"Bash(mkdir -p /tmp/study-repos)",
|
|
43
|
-
"Read(//tmp/**)",
|
|
44
|
-
"Bash(ls:*)",
|
|
45
|
-
"Bash(sort -k2 -rn)",
|
|
46
|
-
"Bash(claude-memory recall:*)",
|
|
47
|
-
"Bash(claude-memory stats:*)",
|
|
48
|
-
"Bash(claude-memory search:*)",
|
|
49
|
-
"Bash(bundle exec:*)",
|
|
50
|
-
"Skill(improve)",
|
|
51
|
-
"Skill(improve:*)",
|
|
52
|
-
"WebFetch(domain:arxiv.org)",
|
|
53
|
-
"mcp__memory__memory_conflicts"
|
|
54
|
-
]
|
|
55
|
-
},
|
|
56
|
-
"enableAllProjectMcpServers": false,
|
|
57
|
-
"disabledMcpjsonServers": ["memory"],
|
|
58
|
-
"outputStyle": "memory-aware"
|
|
59
|
-
}
|
|
@@ -1,29 +0,0 @@
|
|
|
1
|
-
# Deprecated: /check-memory
|
|
2
|
-
|
|
3
|
-
This skill is **no longer needed** and should not be used.
|
|
4
|
-
|
|
5
|
-
## Why Deprecated?
|
|
6
|
-
|
|
7
|
-
The `/check-memory` skill was created to force a "check memory before file exploration" workflow. However, this should be **automatic**, not manual.
|
|
8
|
-
|
|
9
|
-
## What Replaced It?
|
|
10
|
-
|
|
11
|
-
The enhanced `memory-aware` output style now handles this automatically by:
|
|
12
|
-
- Explicitly instructing Claude to check memory FIRST before file reads
|
|
13
|
-
- Providing clear workflow: memory.recall → then file exploration if needed
|
|
14
|
-
- Making this behavior persistent across all conversations
|
|
15
|
-
|
|
16
|
-
## If You Need Debugging
|
|
17
|
-
|
|
18
|
-
Use `/debug-memory` instead to troubleshoot ClaudeMemory installation issues.
|
|
19
|
-
|
|
20
|
-
## Migration
|
|
21
|
-
|
|
22
|
-
If you were using `/check-memory`:
|
|
23
|
-
- **Remove** any references to it
|
|
24
|
-
- **Use** the `memory-aware` output style (automatically applied)
|
|
25
|
-
- **Trust** that Claude will check memory first automatically
|
|
26
|
-
|
|
27
|
-
## Archive Date
|
|
28
|
-
|
|
29
|
-
Deprecated: 2026-01-29
|
|
@@ -1,87 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: check-memory
|
|
3
|
-
description: Explicitly check memory system before answering or exploring
|
|
4
|
-
disable-model-invocation: true
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
# Check Memory First
|
|
8
|
-
|
|
9
|
-
When invoked with `/check-memory <topic>`, this skill forces a memory-first workflow.
|
|
10
|
-
|
|
11
|
-
## Task
|
|
12
|
-
|
|
13
|
-
**IMPORTANT: You MUST check memory BEFORE reading any files or running any code searches.**
|
|
14
|
-
|
|
15
|
-
The user is asking about: $ARGUMENTS
|
|
16
|
-
|
|
17
|
-
## Step-by-Step Workflow
|
|
18
|
-
|
|
19
|
-
### 0. Verify Memory Health
|
|
20
|
-
|
|
21
|
-
Before querying, confirm the memory system is operational:
|
|
22
|
-
|
|
23
|
-
```
|
|
24
|
-
memory.check_setup
|
|
25
|
-
```
|
|
26
|
-
|
|
27
|
-
If status is not "healthy", inform the user and suggest running `claude-memory doctor` for details.
|
|
28
|
-
|
|
29
|
-
### 1. Query Memory (REQUIRED FIRST STEP)
|
|
30
|
-
|
|
31
|
-
Run multiple memory queries to find existing knowledge:
|
|
32
|
-
|
|
33
|
-
```
|
|
34
|
-
memory.recall "$ARGUMENTS"
|
|
35
|
-
```
|
|
36
|
-
|
|
37
|
-
Also try specialized shortcuts:
|
|
38
|
-
- `memory.decisions` (if implementing a feature)
|
|
39
|
-
- `memory.architecture` (if working with frameworks)
|
|
40
|
-
- `memory.conventions` (if writing code)
|
|
41
|
-
- `memory.conflicts` (if encountering contradictions)
|
|
42
|
-
|
|
43
|
-
### 2. Analyze Results
|
|
44
|
-
|
|
45
|
-
Review what memory returns:
|
|
46
|
-
- **If sufficient**: Answer using recalled facts with citations
|
|
47
|
-
- **If partial**: Note what's known and what needs investigation
|
|
48
|
-
- **If empty**: Memory has no knowledge on this topic yet
|
|
49
|
-
|
|
50
|
-
### 3. Explore Code (ONLY IF NEEDED)
|
|
51
|
-
|
|
52
|
-
If memory doesn't have enough information:
|
|
53
|
-
- Use Read/Grep/Glob to explore the codebase
|
|
54
|
-
- Clearly distinguish between:
|
|
55
|
-
- **Recalled knowledge** (from memory)
|
|
56
|
-
- **Discovered information** (from code exploration)
|
|
57
|
-
|
|
58
|
-
### 4. Provide Complete Answer
|
|
59
|
-
|
|
60
|
-
Combine:
|
|
61
|
-
- Facts from memory (with fact IDs if relevant)
|
|
62
|
-
- New information from code exploration (if any)
|
|
63
|
-
- Clear indication of sources
|
|
64
|
-
|
|
65
|
-
## Example Response Format
|
|
66
|
-
|
|
67
|
-
```
|
|
68
|
-
Based on memory:
|
|
69
|
-
- [Fact from memory with context]
|
|
70
|
-
|
|
71
|
-
From code exploration:
|
|
72
|
-
- [New findings from reading files]
|
|
73
|
-
|
|
74
|
-
Answer: [Complete response combining both sources]
|
|
75
|
-
```
|
|
76
|
-
|
|
77
|
-
## Why This Matters
|
|
78
|
-
|
|
79
|
-
Memory contains distilled knowledge from previous sessions. Checking it first:
|
|
80
|
-
- Saves time (no need to re-explore known areas)
|
|
81
|
-
- Provides context (decisions, patterns, conventions)
|
|
82
|
-
- Avoids mistakes (previous lessons learned)
|
|
83
|
-
- Reduces token usage (recalled facts are concise)
|
|
84
|
-
|
|
85
|
-
## Remember
|
|
86
|
-
|
|
87
|
-
**ALWAYS start with memory queries. NEVER skip this step.**
|
|
@@ -1,42 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: dashboard
|
|
3
|
-
description: Launch a local web dashboard for ClaudeMemory debugging and observability
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Dashboard
|
|
7
|
-
|
|
8
|
-
Launch the ClaudeMemory debugging dashboard to visualize memory system health, activity, and efficacy.
|
|
9
|
-
|
|
10
|
-
## Task
|
|
11
|
-
|
|
12
|
-
Start the dashboard web server so the user can inspect what's happening behind the scenes.
|
|
13
|
-
|
|
14
|
-
## Steps
|
|
15
|
-
|
|
16
|
-
1. Run the dashboard command:
|
|
17
|
-
|
|
18
|
-
```bash
|
|
19
|
-
claude-memory dashboard
|
|
20
|
-
```
|
|
21
|
-
|
|
22
|
-
This starts a local web server (default port 3377) and opens it in the browser.
|
|
23
|
-
|
|
24
|
-
## What the Dashboard Shows
|
|
25
|
-
|
|
26
|
-
- **Health Status**: Database health, hook configuration, vector index status
|
|
27
|
-
- **Overview**: Fact/entity/content counts, top predicates, entity type distribution, 30-day activity timeline
|
|
28
|
-
- **Activity**: Live event log of hook executions (ingest, context, sweep), memory recalls, and store extractions with timing and details
|
|
29
|
-
- **Facts**: Searchable fact explorer with status filtering, predicate/object search
|
|
30
|
-
- **Efficacy**: Recall hit rate, total results served, average results per query, top queries by result count
|
|
31
|
-
|
|
32
|
-
## Options
|
|
33
|
-
|
|
34
|
-
- `--port PORT` - Use a different port (default: 3377)
|
|
35
|
-
- `--no-open` - Don't auto-open the browser
|
|
36
|
-
|
|
37
|
-
## Notes
|
|
38
|
-
|
|
39
|
-
- Dashboard auto-refreshes every 30 seconds
|
|
40
|
-
- Activity events are recorded by hooks and MCP tools into the `activity_events` table
|
|
41
|
-
- The dashboard reads from both global and project databases
|
|
42
|
-
- Press Ctrl+C to stop the server
|
data/.claude/skills/debug-memory
DELETED
|
@@ -1 +0,0 @@
|
|
|
1
|
-
../../skills/debug-memory
|