refactor: extract memory, Leiden and the LLM stack into standalone crates

.claude/skills/codesearch-cli/SKILL.md

@@ -1,18 +1,16 @@
 ---
 name: codesearch-cli
-description: Use before implementing a feature, refactoring, fixing a bug, or changing any code, and whenever you need to understand how code relates — where something is handled, what calls a function, what a change would break, how modules depend. Load it first to find the right code and the blast radius before you edit. Traces relationships and recalls project memory that reading files alone misses.
+description: Use before implementing a feature, refactoring, fixing a bug, or changing any code, and whenever you need to understand how code relates — where something is handled, what calls a function, what a change would break, how modules depend. Load it first to find the right code and the blast radius before you edit. Traces relationships that reading files alone misses.
 metadata:
   author: ArtemisMucaj
-  version: "1.7.0"
-compatibility: Requires the codesearch binary installed. Code search needs the repository indexed with `codesearch index`; memory recall works as soon as any sessions have been imported.
+  version: "2.0.0"
+compatibility: Requires the codesearch binary installed and the repository indexed with `codesearch index`.
 ---
 
 # Codesearch
 
-A CLI that gives an AI assistant four capabilities over one index:
+A CLI that gives an AI assistant three capabilities over one index:
 
-- Recall — long-term memory from past sessions: user preferences, project
-  overview, experiences, and facts. Load it first, every session.
 - Map — architecture at a glance: a one-page `overview`, modules and
   communities (`clusters`, `symbol-clusters`), coupling hotspots, entry-point
   `features`, and cross-service `channels`.
@@ -34,28 +32,7 @@ Follow these phases in order. Run every command from inside the repository —
 codesearch auto-resolves the namespace and embedding config from the repo's git
 remote, so you almost never need `--namespace` or any embedding flags.
 
-## Phase 1 — Recall memory (do this first)
-
-Before any substantive work, load what past sessions learned. It is cheap and
-keeps you from re-asking things the user already told you or working against
-their conventions.
-
-```shell
-# The "read this first" digest across all memory (project + preferences overview)
-codesearch memory show memory://memory
-
-# The user's standing preferences (code style, tooling, workflow)
-codesearch memory list --kind preference
-
-# Anything specific to the task you're about to start
-codesearch memory search "how do we handle <the thing you're about to touch>"
-```
-
-`memory search` is auto-scoped to this project + globals. If memory is empty
-(nothing imported yet) these return little — that's fine, proceed. Don't skip
-the check just because it *might* be empty. (Full memory reference below.)
-
-## Phase 2 — Get the architecture overview
+## Phase 1 — Get the architecture overview
 
 Orient in the codebase before diving in. Start broad, then zoom in only if the
 task needs it.
@@ -80,7 +57,7 @@ codesearch visualize -o graph.html        # interactive community graph
 `overview` caches its analysis and refreshes automatically when you re-index.
 Add `-r/--repository` if several repos are indexed.
 
-## Phase 3 — Search by intent
+## Phase 2 — Search by intent
 
 Describe *what the code does* — include the domain noun and the behaviour.
 Prefer a short phrase or question over one word.
@@ -93,15 +70,15 @@ codesearch search "middleware that validates auth tokens before issuing a sessio
 # Weak — fix by choosing the right tool
 codesearch search "error"           # too generic → "error handling for X"
 codesearch search "HandleRequest"   # you already know the symbol → skip search;
-                                    #   go to Phase 4 (context / impact) instead
+                                    #   go to Phase 3 (context / impact) instead
 ```
 
 Then read the top hits (each result has `file_path`, line range, symbol, and
 a preview): search → Read the top 3–5 at their lines → confirm. Treat the
 ranking as a lead, not a verdict.
 
 > If you already have the exact symbol name, `search` is the wrong phase — jump
-> straight to Phase 4 (`context` / `impact`) to see its callers, callees, and
+> straight to Phase 3 (`context` / `impact`) to see its callers, callees, and
 > blast radius.
 
 If the first query misses, refine rather than repeat:
@@ -118,9 +95,9 @@ Rephrase using vocabulary you saw in the first batch. Scoring note: hybrid RRF
 scores are ~0.016–0.033; semantic-only cosine scores are 0.0–1.0 — set
 `--min-score` to match the mode.
 
-## Phase 4 — Understand a symbol (start here when you know its name)
+## Phase 3 — Understand a symbol (start here when you know its name)
 
-Once you have a symbol name — from Phase 3, or because the user named it — this
+Once you have a symbol name — from Phase 2, or because the user named it — this
 is how you learn where it's used and where a change lands. These query the call
 graph, so they report real callers, callees, and blast radius.
 
@@ -144,14 +121,13 @@ codesearch impact "^MyNs/.*Service#get$" --regex
 codesearch features impacted authenticate hash_password   # which features a change touches
 ```
 
-## Phase 5 — Change, re-index, record
+## Phase 4 — Change, then re-index
 
 After editing, keep the index (and thus the call graph and architecture
-analysis) in sync, and capture what you learned:
+analysis) in sync:
 
 ```shell
-codesearch index <path>                     # incremental — only changed files re-parse
-codesearch memory import <transcript.jsonl> # distill this session for next time
+codesearch index <path>   # incremental — only changed files re-parse
 ```
 
 ---
@@ -175,35 +151,6 @@ Supported languages: Rust, Python, JavaScript, TypeScript, Go, HCL/Terraform,
 PHP, C++. Indexing extracts functions, methods, classes/structs/enums, traits,
 impls, modules, constants, typedefs, and imports.
 
-## Memory in depth
-
-Four kinds: preference (how the user likes to work), fact (project facts
-and decisions), experience (a reusable insight — trigger, approach,
-guardrails), and skill (a reusable procedure).
-
-Recall (Phase 1) — more ways to read:
-
-```shell
-codesearch memory list --kind fact                  # project facts & decisions
-codesearch memory search "deploy steps" --kind skill
-codesearch memory search "..." --project <name>     # another project (or --all-projects)
-codesearch memory tree                              # browse the memory:// virtual filesystem
-codesearch memory show memory://sessions/<id>       # a past session's transcript
-codesearch memory show experience/<name>            # one item by kind/name
-```
-
-`memory://memory` is the digest across all memory; `memory://projects/<project>`
-is one project's overview. `memory search` auto-scopes to the current project +
-globals; `memory list` lists all items of a kind, newest first.
-
-Record (Phase 5) — more ways to write:
-
-```shell
-codesearch memory add ./docs/design.md               # store a file as a summarized resource
-codesearch memory add https://example.com/g --name g # store a URL
-codesearch memory dream                              # consolidate: merge dupes, resolve conflicts
-```
-
 ## Interactive TUI
 
 ```shell
@@ -239,6 +186,4 @@ call graph, impact analysis, blast radius, symbol context, callers, callees,
 explain, call flow, execution features, criticality, clusters, modules,
 architecture overview, dossier, Leiden, community detection, symbol clusters,
 communities, coupling, hub dependency, cross-service channels, kafka, cross-
-repository dependencies, uses, visualize, graph, TUI, regex symbol match,
-long-term memory, recall preferences, project overview, session start memory,
-remember decisions, user preferences, project facts
+repository dependencies, uses, visualize, graph, TUI, regex symbol match

.claude/skills/codesearch-mcp/SKILL.md

@@ -1,25 +1,22 @@
 ---
 name: codesearch-mcp
-description: Use before implementing a feature, refactoring, fixing a bug, or changing any code, and whenever you need to understand how code relates — where something is handled, what calls a function, what a change would break, how modules depend. Load it first to find the right code and the blast radius before you edit. Traces relationships and recalls project memory that reading files alone misses.
+description: Use before implementing a feature, refactoring, fixing a bug, or changing any code, and whenever you need to understand how code relates — where something is handled, what calls a function, what a change would break, how modules depend. Load it first to find the right code and the blast radius before you edit. Traces relationships that reading files alone misses.
 metadata:
   author: ArtemisMucaj
-  version: "1.7.0"
-compatibility: Requires the codesearch MCP server to be connected (e.g. `codesearch mcp` over stdio, or `codesearch serve` over HTTP). Code-search tools need the repository indexed; memory tools work as soon as any sessions have been imported.
+  version: "2.0.0"
+compatibility: Requires the codesearch MCP server to be connected (e.g. `codesearch mcp` over stdio, or `codesearch serve` over HTTP) and the repository indexed.
 ---
 
 # Codesearch (MCP)
 
-The codesearch MCP server exposes semantic code search, call-graph analysis,
-architecture mapping, and long-term memory as tools you can call directly. This
-skill is the playbook for *when and in what order* to call them. It names each
-tool and what it's for; the exact parameters are on each tool's own schema —
-discover those as you go, don't guess them from here.
+The codesearch MCP server exposes semantic code search, call-graph analysis, and
+architecture mapping as tools you can call directly. This skill is the playbook
+for *when and in what order* to call them. It names each tool and what it's for;
+the exact parameters are on each tool's own schema — discover those as you go,
+don't guess them from here.
 
-Four capabilities over one index:
+Three capabilities over one index:
 
-- Recall — long-term memory from past sessions: preferences, project overview,
-  experiences, facts. Load it first, every session (`read_memory`,
-  `search_memory`, `list_memories`).
 - Map — architecture at a glance: a one-shot dossier (`overview`), entry-point
   features, file/symbol communities, coupling hotspots, cross-service channels
   (`overview`, `list_features`, `list_clusters`, `list_symbol_clusters`,
@@ -41,34 +38,7 @@ Follow these phases in order. Most tools take an optional repository argument;
 omit it to use the connected workspace's repository, and set it only when
 several repositories are indexed and you need to disambiguate.
 
-## Phase 1 — Recall memory (do this first)
-
-Before any substantive work, load what past sessions learned. It's cheap and
-keeps you from re-asking things the user already told you or working against
-their conventions.
-
-1. `read_memory` with no arguments — returns the whole-memory digest: a single
-   abstract + overview of everything known about the user and this project.
-   Read this first, then drill in only where relevant.
-2. `list_memories` filtered to preferences — load the user's standing
-   preferences (code style, tooling, workflow) before you write or change code.
-3. `search_memory` — pull anything specific to the task you're about to start
-   (past decisions, a prior fix, a project fact).
-
-`search_memory` is scoped to the connected project + globals by default. If
-memory is empty (nothing imported yet) these return little — that's fine,
-proceed. Don't skip the check just because it *might* be empty.
-
-To go deeper into the memory virtual filesystem, call `read_memory` with a
-directory URI (e.g. `memory://sessions`) to list its children's one-line
-abstracts, then a leaf URI (e.g. `memory://sessions/<id>`) for a node's full
-detail such as a past session transcript.
-
-When a task turns up a durable reference worth keeping — a design doc, a spec, a
-guide URL — store it with `add_memory_resource` (a file path or URL) so a later
-session can recall it. It's summarised and saved under `memory://resources`.
-
-## Phase 2 — Get the architecture overview
+## Phase 1 — Get the architecture overview
 
 Orient in the codebase before diving in. Start broad, then zoom in only if the
 task needs it.
@@ -93,15 +63,15 @@ task needs it.
 Drill from a listing to a specific item with `get_feature`, `get_file_cluster`,
 or `get_symbol_cluster`.
 
-## Phase 3 — Search by intent
+## Phase 2 — Search by intent
 
 Call `search_code` with a description of *what the code does* — include the
 domain noun and the behaviour. Prefer a short phrase or question over one word.
 
 - Good: "how are file chunks created and stored", "middleware that validates
   auth tokens before issuing a session".
 - Weak: "error" (too generic — say "error handling for X"); a bare identifier
-  you already know (skip search — go straight to Phase 4).
+  you already know (skip search — go straight to Phase 3).
 
 Then read the top hits: each result carries the file path, line range, symbol,
 and a code preview. Read the top 3–5 at their lines to confirm before relying on
@@ -113,11 +83,11 @@ or widen the result limit. Rephrase using vocabulary you saw in the first batch.
 (These are all parameters on `search_code` — check its schema for the names.)
 
 > If you already have the exact symbol name, `search_code` is the wrong phase —
-> jump straight to Phase 4 for its callers, callees, and blast radius.
+> jump straight to Phase 3 for its callers, callees, and blast radius.
 
-## Phase 4 — Understand a symbol (start here when you know its name)
+## Phase 3 — Understand a symbol (start here when you know its name)
 
-Once you have a symbol name — from Phase 3, or because the user named it — these
+Once you have a symbol name — from Phase 2, or because the user named it — these
 tools report where it's used and where a change lands, from the call graph:
 
 - `get_symbol_context` — who calls it and what it calls (the immediate
@@ -133,17 +103,17 @@ tools report where it's used and where a change lands, from the call graph:
 Symbol arguments match by substring by default; supply an anchored regex when
 you need precision (see each tool's schema for the flag).
 
-## Phase 5 — Keep results current after a change
+## Phase 4 — Keep results current after a change
 
 The call graph and architecture tools reflect the index as of the last time the
 repository was indexed. After a substantial change, the newest code may not be
 reflected yet, so cross-check anything critical against the file you just edited.
 
 The server keeps the index fresh for you: when it was launched to also run the
-management API, it re-indexes and consolidates memory in the background on a
-schedule, so the tools converge on the current code without any action from you.
-If you need the very latest state immediately and the tools look stale, ask the
-user to re-index, then re-run the tool.
+management API, it re-indexes in the background on a schedule, so the tools
+converge on the current code without any action from you. If you need the very
+latest state immediately and the tools look stale, ask the user to re-index,
+then re-run the tool.
 
 ---
 
@@ -153,7 +123,6 @@ user to re-index, then re-run the tool.
 
 | Phase | Tools |
 |---|---|
-| Recall | `read_memory`, `search_memory`, `list_memories`; `add_memory_resource` to store a file/URL for later recall |
 | Map | `overview`, `list_repositories`, `list_features` / `get_feature`, `list_clusters` / `get_file_cluster`, `list_symbol_clusters` / `get_symbol_cluster`, `couplings`, `channels`, `file_uses` |
 | Search | `search_code` |
 | Understand | `get_symbol_context`, `analyze_impact`, `query_graph`, `get_impacted_features` |
@@ -179,13 +148,13 @@ Most questions are answered by combining a few tool calls rather than one.
   radius and `get_impacted_features` for the user-visible behaviours affected;
   report both so the user sees the risk.
 - Locate then understand — `search_code` to find an unknown symbol, then the
-  Phase 4 tools on the symbol name it returns. Skip the search when you already
+  Phase 3 tools on the symbol name it returns. Skip the search when you already
   know the name.
 
 ## Getting good results
 
-- Start every task at Phase 1: call `read_memory` (no arguments) for the digest,
-  then `list_memories` for preferences, before acting.
+- Start every task at Phase 1: call `overview` to orient before searching or
+  tracing the call graph.
 - Prefer omitting optional filters (repository, language, limits) unless they're
   needed; add them only to disambiguate or narrow a noisy result set.
 - Read tool output before relying on it — treat rankings and matches as leads,
@@ -199,8 +168,5 @@ mcp, model context protocol, codesearch mcp, semantic code search, hybrid
 search, find code, code understanding, call graph, symbol context, callers,
 callees, impact analysis, blast radius, query graph, execution features,
 clusters, symbol clusters, communities, coupling, cross-service channels, uses,
-repository overview, dossier, overview tool, long-term memory, read_memory,
-search_memory, list_memories, add_memory_resource, store resource, remember a
-doc, recall preferences, project overview, session start memory, remember
-decisions, user preferences, project facts, search_code, get_symbol_context,
-analyze_impact
+repository overview, dossier, overview tool, search_code, get_symbol_context,
+analyze_impact, query_graph

.gitignore

@@ -34,3 +34,6 @@ Thumbs.db
 *.profdata
 coverage/
 .claude/worktrees/
+
+# SCIP indexes emitted by scip-typescript / scip-php during indexing and tests
+*.scip