memtrace-skills 1.2.6 → 1.2.8

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.
@@ -1,57 +1,24 @@
1
1
  ---
2
2
  name: memtrace-first
3
- description: "Route code discovery, debugging, flow tracing, how-code-works questions, and pre-edit rationale checks in indexed source-code repos to Memtrace graph plus Cortex decision tools. Use first before searching/reading code, and before editing, refactoring, deleting, or re-picking an approach that may have a recorded decision, ban, convention, or contract. Do not use Grep, Glob, rg, find, or manual file browsing for code discovery when Memtrace is indexed. Zero results are not permission to grep; diagnose/reindex with Memtrace."
3
+ description: "Route code discovery, debugging, flow tracing, how-code-works questions, and pre-edit rationale checks in indexed source-code repos to Memtrace graph plus Cortex decision tools. Use first before searching/reading code, and before editing, refactoring, deleting, or re-picking an approach that may have a recorded decision, ban, convention, or contract. Do not use Grep, Glob, rg, find, or manual file browsing for code discovery when Memtrace is indexed. Zero results are not permission to grep: diagnose the miss first, then allow one targeted reformulation and bounded source verification or fallback, and reindex only on evidence of stale or incomplete coverage — never in a loop. A `repo_not_in_store` refusal means a different store holds the repository: route to that store, never grep and never re-index here."
4
4
  ---
5
-
6
5
  # Memtrace First
7
6
 
8
- ## The Iron Law
9
-
10
- ```
11
- IF THE REPO IS INDEXED IN MEMTRACE → USE MEMTRACE TOOLS FIRST.
12
- After a search hit, route to GRAPH tools (get_symbol_context, get_impact,
13
- analyze_relationships) — that's what Memtrace uniquely provides. Read source
14
- ONLY when you're about to edit or quote, and read only the bounded span
15
- returned by Memtrace (start_line .. end_line + small context). Do not
16
- Grep/Glob/Find to "locate" anything already in the graph, and do not read
17
- the whole file when Memtrace has given you exact lines.
18
-
19
- BEFORE you edit/refactor/delete existing code or choose/re-pick a pattern,
20
- call Cortex decision memory: recall_decision for the symbol/subsystem/approach,
21
- and use provenance/contracts when a symbol_id is available. Use Memtrace's graph
22
- tools for structure and blast radius; use Cortex for rationale, bans, and
23
- contracts.
24
- ```
25
-
26
- Memtrace is the **memory layer** of the codebase, not a search engine that returns code. It has the full knowledge graph — every symbol, call, import, community, process, and API — with a time dimension. The point is to navigate that graph: who calls this, what's the blast radius, when did this change, what community is it part of. File tools are blind to all of that.
27
-
28
- **No exceptions for what's in the graph.**
29
-
30
- ## Value Tracking
31
-
32
- Do not print usage receipts in normal answers. Memtrace records tool usage, graph facts, file references, and estimated context avoided internally. Users can inspect that in the local UI's Value panel.
33
-
34
- ## What Memtrace actually indexes
35
-
36
- Memtrace's hybrid search = **BM25 over symbol metadata** (name, signature, file_path, kind) **+ semantic vector search over embedded code bodies** (first ~1500 chars of every Function / Method / Class / Struct / Interface body), fused via Reciprocal Rank Fusion.
37
-
38
- The semantic side means **string literals, error messages, magic constants, log strings, and any text inside an indexed symbol's body are findable through `find_code`**. The body got embedded; the embedding catches it. You do NOT need `Grep` to hunt for `STRIPE_KEY_FOO_BAR` if it lives inside a function in your indexed codebase.
39
-
40
- ## Zero results are not a grep license
7
+ Use Memtrace first for code discovery in indexed repositories. Use its graph to
8
+ understand relationships, processes and impact; verify source when exact behavior
9
+ matters. Retrieval is evidence, not a guarantee of complete coverage.
41
10
 
42
- If Memtrace returns 0 results, or repository stats look incomplete, do **not**
43
- infer that a source subdirectory is outside the index. Diagnose through
44
- Memtrace:
11
+ ## Establish scope
45
12
 
46
- 1. Call `list_indexed_repositories` and identify the repo root/repo_id.
47
- 2. If the path is under that indexed repo root, keep using Memtrace.
48
- 3. Retry with broader `find_code` terms and, when available, `file_path` filters
49
- such as `ui/`, `memtrace-ui/`, `src/`, or the framework directory.
50
- 4. If the language/path still appears missing, run `index_directory` on the repo
51
- root with `incremental: true` (or ask before `clear_existing: true`).
52
- 5. Report the indexing coverage problem instead of silently switching to grep.
13
+ Call `list_indexed_repositories` once per session. Select the actual repository
14
+ and branch; pass `repo_id` explicitly when possible. It lists this session's
15
+ store only, so a repository missing from it may still be indexed and live in
16
+ another store. Do not index a parent containing unrelated repositories. For a
17
+ deliberately shared workspace, verify its workspace marker and scope before
18
+ indexing. If tools are unavailable, state that limitation and use bounded source
19
+ inspection rather than blocking the task.
53
20
 
54
- ### Workspace Boundary Check
21
+ ### Workspace boundary check
55
22
 
56
23
  Before indexing or reindexing, make sure the target path is the repo the user
57
24
  asked about. If the current folder is only a parent that contains multiple
@@ -61,197 +28,206 @@ answer from stale repos.
61
28
 
62
29
  - For separate repos: use the actual git repo root as the `index_directory`
63
30
  path, or ask the user to open/run the agent from that repo root.
64
- - For an intentional shared workspace: the user should bless it explicitly with
65
- `memtrace start --bless-workspace`, then verify it with
31
+ - For an intentional shared workspace: a portable manifest is the durable
32
+ form — `memtrace start --workspace-file <manifest>` declares the members and
33
+ records the manifest as the owner of the store's membership. The Folder
34
+ Group flow still works and the CLI now calls it legacy: the user blesses the
35
+ parent with `memtrace start --bless-workspace`, then verifies it with
66
36
  `memtrace workspace status <path>`; the workspace marker should be present.
37
+ - A store whose membership is already owned by a manifest or a Named Workspace
38
+ cannot be widened by a plain `memtrace start` from a parent folder. That
39
+ start is refused with "a folder-walked start cannot widen it. Run
40
+ `<command>`", and the refusal names the exact command to run instead. Run
41
+ it. Do not route around the refusal by indexing elsewhere. A folder-sourced
42
+ store has no owning definition, so that refusal does not apply to it. A
43
+ `memtrace mcp` session can never widen an existing store under any flag,
44
+ including `--workspace-file`: adding a repository is always a `memtrace
45
+ start` for that store, carrying the manifest or the workspace name when one
46
+ owns its members.
67
47
  - If `list_indexed_repositories` returns empty or its metadata says the MCP
68
48
  child resolved a data dir from cwd because no workspace marker/git root was
69
49
  found, surface the workspace mismatch. Do not "fix" it by indexing the broad
70
50
  parent folder.
71
51
 
72
- **Never say "the index only covers X, so grep is right" when the target path is
73
- inside the indexed repository.** That is an indexing freshness/coverage issue,
74
- not permission to abandon Memtrace.
75
-
76
- ## The narrow exceptions where grep/glob are still right
77
-
78
- These are the ONLY cases where file tools beat memtrace:
79
-
80
- - **Files outside every indexed repo root.** Confirm this with
81
- `list_indexed_repositories`; 0 search results or missing language stats do not
82
- prove it. Vendored deps, system headers, and excluded dirs
83
- (`.git`, `node_modules`, `target`, `dist`) are examples Memtrace cannot see.
84
- - **Non-source artifacts.** `.env`, `package.json`, build scripts, top-level `README.md`, raw config files. Memtrace indexes parseable code, not configuration text.
85
- - **Pure file-inventory questions.** "How many `*.test.ts` files exist", "list every Markdown file in `docs/`". You're asking for a file count, not a symbol search.
86
- - **Reading at a known path outside Memtrace.** For configs, docs, or non-source artifacts that Memtrace cannot index, file `Read` is fine. For source-code spans returned by Memtrace, read the precise line range (your harness's `Read` with offset/limit, or `get_source_window` if your harness lacks bounded reads). Do not whole-file Read when you have a span.
87
-
88
- For everything else inside the indexed repo, memtrace is the right tool.
89
-
90
- ## The decision rule
91
-
92
- | Question Claude is asking | Right tool |
93
- |---|---|
94
- | "Where is symbol `foo` defined?" | `find_symbol(name="foo")` → then `get_symbol_context` for callers/callees/community, NOT a source read unless you're editing. |
95
- | "What calls `foo`?" | `get_symbol_context(repo_id, symbol="foo")` → callers with file:line. |
96
- | "How does authentication work?" | `find_code(query="authentication")` → `get_symbol_context` on the top hit, NOT a source read. |
97
- | "Find behavior X" with multi-word phrase (3+ words) | `find_code(verbatim)` first; if low confidence, fan out with identifier-shaped reshapes (camelCase / snake_case). |
98
- | "Find the function that uses `STRIPE_KEY_FOO_BAR`" | `find_code(query="STRIPE_KEY_FOO_BAR")` → semantic finds it inside any embedded body. |
99
- | "Where's that error message `'connection refused for tenant'`?" | `find_code(query="connection refused for tenant")` → semantic catches it. |
100
- | "What breaks if I change `foo`?" | `get_impact(repo_id, target="foo")` → blast radius. |
101
- | "Should I change/delete/refactor `foo`?" | `find_symbol`/`get_symbol_context` → `recall_decision("foo / subsystem / approach")`; if a symbol id is available, `why_is_this_here` + `governing_contracts`; then `get_impact`. |
102
- | "Can I use/switch to pattern or library X?" | `recall_decision("X")` FIRST; bans and conventions are decisions. Verify a matching decision with `verify_intent(decision_id)` before relying on it. |
103
- | "What changed in `auth.ts` last week?" | `get_evolution(repo_id, from="7d ago", mode="recent", file_path="auth.ts")`. |
104
- | "List all `*.test.ts` files." | `Glob` (file inventory, not symbol search). |
105
- | "Find this string in my `.env`." | `Grep` (non-source artifact). |
106
- | "I'm about to edit `foo` — show me its source." | Bounded `Read(file_path, offset=start_line, limit=end_line-start_line+8)`, or `get_source_window` if your harness lacks bounded reads. Never whole-file. |
107
- | "Read config/doc file I already have the path of." | `Read` (non-source artifact, path is known). |
108
-
109
- ## Parameter Types — Read This Before Calling Any Tool
110
-
111
- All memtrace MCP tools are **strictly typed**. Pass JSON numbers (not strings) for integer parameters.
112
-
113
- | Parameter | Correct | WRONG (fails with MCP error -32602) |
114
- |---|---|---|
115
- | `limit`, `min_size`, `depth`, `max_depth`, `last_n` | `limit: 20` | `limit: "20"` |
116
- | `repo_id`, `branch`, `name`, `symbol_name`, `query` | `repo_id: "my-repo"` | `repo_id: my-repo` (unquoted) |
117
- | `fuzzy`, `include_tests`, `invalidate` | `fuzzy: true` | `fuzzy: "true"` |
118
- | `get_evolution.from` | `from: "90d ago"` | `days: 90` (wrong param — use `from`, not `days`) |
119
- | `get_changes_since.since` | `since: "2026-04-13T10:43:00Z"` | `last_episode_id: "..."` (wrong param) |
120
- | `get_impact.target` / `get_symbol_context.symbol` | `target: "foo"` / `symbol: "foo"` | `symbol_id: "..."` (wrong — use name) |
121
- | `find_most_complex_functions` | `top_n: 10` | `limit: 10` (wrong param name) |
122
- | `get_cochange_context` | `target: "execute"` | `symbol: "execute"` (wrong param name) |
123
-
124
- If you see `failed to deserialize parameters: invalid type: string "N", expected usize`, remove the quotes from the number and retry.
125
-
126
- If you see `missing field 'from'`, you called `get_evolution` without `from` — pass e.g. `"90d ago"`, never `days`.
127
-
128
- Full parameter spec for every Memtrace tool: `references/mcp-parameters.md` (bundled at the memtrace-skills plugin root).
129
-
130
- ## Check Indexing First (Once Per Session)
131
-
132
- ```
133
- mcp__memtrace__list_indexed_repositories
134
- ```
135
-
136
- If the current repo appears → Memtrace is active. Follow this skill for ALL code tasks.
137
- If not indexed → offer to index with `mcp__memtrace__index_directory`, then follow this skill.
138
-
139
- ## Task → Tool Map
140
-
141
- | What you need | Use instead of Grep/Glob/Read |
142
- |---|---|
143
- | Find a function / class / symbol | `find_symbol` or `find_code` |
144
- | Understand how something works | `get_symbol_context` (the default next step) |
145
- | Find all callers of a function | `get_symbol_context` (callers field) |
146
- | Find all callees / dependencies | `get_symbol_context` (callees field) |
147
- | Trace a request / execution path | `get_process_flow` |
148
- | Understand module structure | `list_communities` |
149
- | Find the most important symbols | `find_central_symbols` |
150
- | Find API endpoints | `find_api_endpoints` |
151
- | Find where an API is called | `find_api_calls` |
152
- | Debug a problem | `get_symbol_context` → `get_impact` → `get_evolution` |
153
- | What changed recently? | `get_changes_since` or `get_evolution` |
154
- | What breaks if I change X? | `get_impact` |
155
- | Cross-service / cross-repo calls | `get_service_diagram` or `get_api_topology` |
156
- | Dependency between two symbols | `find_dependency_path` |
157
- | What files change together? | `get_cochange_context` |
158
- | Architecture overview | `list_communities` + `find_central_symbols` |
159
- | About to edit / quote — need exact lines | Bounded `Read(file, offset=start_line, limit=N)` (preferred), or `get_source_window` for path-resolution parity |
160
- | About to edit/refactor/delete existing code | `recall_decision` for the intent + `why_is_this_here`/`governing_contracts` when a symbol id is available, then `get_impact` |
161
- | About to choose or replace a library/pattern/architecture | `recall_decision` first; use `verify_intent` on any matching decision before contradicting it |
162
- | About to choose between competing idioms (ternary vs if-else, arrow vs fn-decl, const vs let, await vs `.then`) | `get_style_fingerprint(repo_id, file_path)` — empirical codebase norm; see `memtrace-style-fingerprint` workflow |
163
-
164
- ## Standard Workflows
165
-
166
- ### "How does X work?" / "Explain X"
167
- 1. `find_symbol` or `find_code` → locate the symbol
168
- 2. `get_symbol_context` → callers, callees, community, processes (this usually answers "how it works")
169
- 3. `get_process_flow` (if it's a process/request path)
170
- 4. Only if you need to quote source: bounded `Read` at start_line..end_line, or `get_source_window`
171
-
172
- ### Debugging "X is broken"
173
- 1. `find_symbol` → locate the broken thing
174
- 2. `get_symbol_context` → understand its role
175
- 3. `get_impact` → blast radius (what else breaks)
176
- 4. `get_evolution(from=<lookback>, mode: recent)` → per-episode changelog near the incident
177
- 5. `get_changes_since(since=<anchor>)` → catch-up since last session (requires stored `since` timestamp)
178
-
179
- ### "Where is X defined / called?"
180
- 1. `find_symbol` with `fuzzy: true`
181
- 2. `get_symbol_context` for full caller/callee map
182
- 3. Only if you need source text: bounded `Read` at start_line..end_line, or `get_source_window`
183
-
184
- ### Before any code modification
185
- 1. `find_symbol` → confirm you have the right target
186
- 2. `get_symbol_context` → understand full context
187
- 3. `recall_decision("<symbol/subsystem/approach>")` → surface recorded choices, bans, and conventions before deciding what to do
188
- 4. If a `symbol_id` is available, `why_is_this_here(symbol_id)` + `governing_contracts(symbol_id)` before deleting, rewriting, or "cleaning up" odd code
189
- 5. `get_impact` → know blast radius before touching anything
190
- 6. `get_style_fingerprint(repo_id, file_path=<file>)` → match the codebase's empirical idiom (ternary vs if-else, arrow vs fn-decl, etc.) — see `memtrace-style-fingerprint` workflow for the full decision rule
191
-
192
- ## Red Flags — STOP, Use Memtrace Instead
193
-
194
- You are violating this skill if you think:
195
-
196
- | Thought | Reality |
197
- |---|---|
198
- | "Let me grep for this" | `find_code` or `find_symbol` is faster and structurally aware |
199
- | "Let me glob for the file" | `find_symbol` returns exact location with context |
200
- | "Let me read the whole file" | `get_symbol_context` for the WHY (callers/callees/community); a bounded source read at start_line..end_line for the WHAT |
201
- | "I know why this is written this way" | Check Cortex first. Use `recall_decision`; use `why_is_this_here`/`governing_contracts` when you have a symbol id. |
202
- | "This looks unused/weird; I'll remove it" | `why_is_this_here` + `governing_contracts` first, then blast radius. CannotProve is unknown, not permission. |
203
- | "I'll just switch to library/pattern X" | `recall_decision("X")` first — you may be reintroducing a banned approach. |
204
- | "It's just a quick search" | Grep has no understanding of call graphs, communities, or time |
205
- | "I don't know if it's indexed" | Check with `list_indexed_repositories` first — takes 1 second |
206
- | "Memtrace returned 0 results" | Broaden the Memtrace query, check repo_id/path coverage, then reindex if needed |
207
- | "Stats only show Rust, but I need `ui/` or `memtrace-ui/`" | That is a coverage diagnostic. Reindex the repo root; do not grep source code. |
208
- | "The user didn't say to use Memtrace" | User asked about the code. Repo is indexed. Use Memtrace. |
209
- | "This is a simple question" | Simple questions benefit most — one `find_symbol` vs 20 file reads |
210
-
211
- ## When File Tools Are Still Correct
212
-
213
- Use Grep/Glob/Read ONLY for:
214
- - Non-source files or paths outside every indexed source repo
215
- - Files that are config, data, or docs (not source code symbols)
216
- - Repos or paths confirmed outside every Memtrace indexed root
217
- - **Official Memtrace product documentation** — use `memtrace-docs` (`ask_docs` / `search_docs` / `read_doc`), not file tools or web search
218
-
219
- For source-code spans already located by Memtrace, use a **bounded** read —
220
- your harness's `Read(file, offset, limit)` with the returned `start_line` /
221
- `end_line`, or `get_source_window` if your harness lacks bounded reads. Do
222
- not read the whole file.
223
-
224
- Never use file tools as a **discovery** mechanism when Memtrace is available.
225
-
226
- ## Skill Priority
227
-
228
- This skill is a **process skill** — it runs BEFORE any implementation or search skill.
229
-
230
- When this skill applies, it overrides default file-search behavior. Use the specific Memtrace sub-skills for deep detail on each tool:
231
-
232
- - Discovery → `memtrace-search`
233
- - Impact analysis → `memtrace-impact`
234
- - Temporal / change analysis → `memtrace-evolution`
235
- - Rationale / prior decisions / bans / contracts → `memtrace-decision-memory`
236
- - Incident investigation → `memtrace-incident-investigation`
237
- - Architecture overview → `memtrace-codebase-exploration`
238
- - Refactoring → `memtrace-refactoring-guide`
239
- - Memtrace **product docs** (install, CLI, MCP, enterprise) → `memtrace-docs`
240
-
241
- ## Output
242
-
243
- `find_symbol` / `find_code` return ranked symbol entries (`score` only with `include_diagnostics: true`):
244
-
245
- ```json
246
- { "name": "handleAuth", "kind": "Function", "file_path": "src/auth.ts",
247
- "start_line": 42, "end_line": 87 }
248
- ```
249
-
250
- `get_symbol_context` returns the graph neighborhood: `symbol`, `callers`, `callees`, `type_references`, `community`, `processes`, `api_callers_cross_repo`. Feed `start_line`/`end_line` into a bounded `Read` or `get_source_window` — never a whole-file read.
52
+ ## Search, then investigate
53
+
54
+ - Exact symbol: `find_symbol(name=..., repo_id=...)`.
55
+ - Behavior or concept: `find_code(query=..., repo_id=...)`.
56
+ - Relationships: `get_symbol_context` or `analyze_relationships` on the useful hit.
57
+ - Change impact: `get_impact`; confirm relevant callers against source.
58
+ - Execution path: `get_process_flow`; follow its `next_offset` for further steps.
59
+ - Architecture: `list_communities`, `find_central_symbols` and process tools.
60
+ - Historical coupling or changes: `get_cochange_context`, `get_evolution`,
61
+ `get_changes_since` or `get_episode_replay` as appropriate.
62
+
63
+ Inspect `find_code.context` first: concept queries include query-matched processes,
64
+ communities and selected callers/callees, referencing primary results by one-based
65
+ number. Set `include_context: true` for identifier searches or `false` for flat
66
+ results. Expand a graph tool only when this context does not answer the question.
67
+ Treat partial context, truncation and unavailable overlay context as incomplete
68
+ evidence; selected static flows are not complete runtime traces.
69
+
70
+ `context.next_calls` provides scoped follow-up arguments for the useful symbol
71
+ and process. Before changing shared behavior, inspect relevant callers and
72
+ callees to identify contracts the patch must preserve. Use process IDs for
73
+ flow navigation. No sampled flow is not proof that no call path exists.
74
+
75
+ Turn the requested behavior into observable tests, including failure and
76
+ boundary cases. Check that tests exercise the failure condition itself;
77
+ manual cleanup must not make a broken asynchronous operation appear correct.
78
+ Run related existing tests to detect regressions before claiming completion.
79
+
80
+ Read the bounded source span when verifying behavior, editing or quoting. Do not
81
+ fetch whole files or entire process traces when a local span answers the question.
82
+ `get_symbol_context` omits source bodies by default; use `include_content: true`
83
+ for explicit expansion, and `limit`/`offset` for relationship pages. An omitted
84
+ risk diagnostic means unknown, not zero callers or low risk. Check truncation and
85
+ pagination metadata before describing a neighborhood as complete.
86
+
87
+ ## Read the envelope before you diagnose anything
88
+
89
+ An empty-looking answer has three different causes and they need different
90
+ responses: the tool refused because another store holds the repository, the
91
+ tool never checked membership at all, or this store genuinely holds nothing
92
+ for the query. Before diagnosing, check which tool you called and what
93
+ `repo_in_store` and `error_code` say.
94
+
95
+ ### Only some tools check membership
96
+
97
+ Ten tools check the requested `repo_id` against this store's declared members
98
+ before they answer, and they are the only ones that set the top-level
99
+ `repo_in_store` key: `find_code`, `find_symbol`, `get_codebase_briefing`,
100
+ `find_central_symbols`, `find_dependency_path`, `find_bridge_symbols`,
101
+ `list_processes`, `get_process_flow`, `list_communities` and
102
+ `get_repository_stats`.
103
+
104
+ Every other tool that takes a `repo_id` — `get_symbol_context`, `get_impact`,
105
+ `analyze_relationships`, `get_evolution`, `get_timeline`, `get_source_window`,
106
+ `get_api_topology` and the rest — reads this session's store whatever id you
107
+ pass. Their answers carry no `repo_in_store` key at all, so a zero from one of
108
+ them is not evidence about membership and not evidence that the repository is
109
+ unindexed. When membership is in doubt, establish it with one of the ten above
110
+ before you conclude anything. `repo_in_store: null` is a third case:
111
+ membership was assumed rather than proven, because the session discovered no
112
+ workspace.
113
+
114
+ ### `repo_not_in_store` — wrong store, not a missing index
115
+
116
+ One of the ten, asked for a `repo_id` this session's store does not hold,
117
+ answers `repo_in_store: false` with `error_code: "repo_not_in_store"`. It
118
+ searched nothing. The `diagnostic` block names the store that answered, its
119
+ `members`, the `reason`, and — when a live runtime declares the repository —
120
+ `repo_lives_in` with that store, its path, `owner_pid`, `ui_port`,
121
+ `control_port` and `endpoint`.
122
+
123
+ 1. Read `diagnostic.reason` first. `ambiguous_repo_id` is not a routing
124
+ problem: the id matches more than one repository in *this* store, and the
125
+ message says to pass the exact id. Do that and stop here. Everything below
126
+ applies to the `not_in_store` reason.
127
+ 2. Do not fall back to file search. The refusal says so itself, in `_note`:
128
+ "Wrong store for this repo_id; do not fall back to filesystem search, ask
129
+ the session attached to the store named in diagnostic.repo_lives_in."
130
+ 3. Do not call `index_directory`. The repository is already indexed in the
131
+ store `repo_lives_in` names. Indexing it here would build a second copy in
132
+ the wrong store — writes are never routed to another store, so the call
133
+ lands locally.
134
+ 4. Tell the user which store holds it, and route the question to the session
135
+ or daemon attached to that store. A session cannot ask an owner to add a
136
+ repository: changing the members of a store that already has them means
137
+ running `memtrace start` for that store, with `--workspace-file <manifest>`
138
+ or `--workspace <name>` when a manifest or a Named Workspace owns its
139
+ scope.
140
+ 5. If `repo_lives_in` is absent, no live Memtrace runtime declares the
141
+ repository. Running `memtrace start` in its own workspace is the fix.
142
+
143
+ A refusal is not the only outcome. When the runtime whose store declares the
144
+ repository is live and publishes a reachable control port, the same read is
145
+ forwarded to it and you get the real answer, marked
146
+ `_meta.answered_by: "store_owner_daemon"` alongside `_meta.owner_pid`,
147
+ `_meta.owner_http` and `_meta.store`. That answer is authoritative; say which
148
+ store produced it.
149
+
150
+ A forwarded read can also come back as a bounded `busy` answer with
151
+ `"lane": "graph_materialization"` and `retryable: true`, naming what holds
152
+ the graph lane and for how long. That is a wait, not an absence — retry, or
153
+ narrow the call.
154
+
155
+ A `repo_not_in_store` refusal is also not evidence that a path lies outside
156
+ every indexed root: `list_indexed_repositories` covers this session's store
157
+ only, and the refusal's `diagnostic.repo_lives_in` names the store that does
158
+ hold the repository.
159
+
160
+ ## Handle misses without loops
161
+
162
+ This ladder applies to a genuine zero — an empty or irrelevant result from a
163
+ tool that reported `repo_in_store: true`. A refusal, or a zero from a tool
164
+ that sets no `repo_in_store` key, is handled in the section above, not here.
165
+
166
+ 1. Distinguish a tool error, a refusal (`repo_in_store: false`), a zero from a
167
+ tool that sets no `repo_in_store` key, missing scope, wrong branch, pending
168
+ index/embedding job, stale index and a valid empty result. Do not treat an
169
+ error as a clean miss, and do not treat a refusal or a keyless zero as one
170
+ either — re-ask through `find_code` or `find_symbol` before reading
171
+ anything into a keyless zero.
172
+ 2. For an ambiguous query, make at most one targeted reformulation, using an
173
+ identifier or path hint where available, and a `file_path` filter such as
174
+ `ui/`, `memtrace-ui/`, `src/` or the framework directory when one applies.
175
+ 3. If the result remains empty or irrelevant, use a bounded filesystem search
176
+ (`rg`, Grep or Glob) and verify the matching source. A returned hit that does
177
+ not answer the question is also a retrieval miss. Do **not** infer from a
178
+ zero that a source subdirectory is outside the index.
179
+ 4. Record the original miss and fallback in diagnostic/benchmark evidence. Do
180
+ not count filesystem recovery as successful Memtrace retrieval, and report
181
+ the indexing coverage problem rather than silently switching to grep.
182
+ 5. Reindex only when there is evidence of stale or incomplete coverage, at the
183
+ correct repository root, and only once steps 1 and 2 show the repository is
184
+ a member of this store. Prefer incremental repair (`index_directory` with
185
+ `incremental: true`; ask before `clear_existing: true`). Never repeat
186
+ indexing merely because a semantic query did not retrieve a target, and
187
+ never reindex in response to a `repo_not_in_store` refusal.
188
+
189
+ Memtrace combines full-text retrieval, vectors and graph expansion. Embedding
190
+ eligibility, language support, source limits and ranking affect recall. Literal
191
+ strings, short helpers and arbitrary body text are not guaranteed to appear in
192
+ semantic results. Use source search to establish exhaustive literal occurrences.
193
+ Configuration files, documentation, file inventories and excluded dependencies
194
+ are also appropriate uses of file tools.
195
+
196
+ ## Check rationale before changing code
197
+
198
+ BEFORE you edit/refactor/delete existing code or choose another pattern, call
199
+ Cortex `recall_decision("<symbol/subsystem/approach>")` when available. If a symbol
200
+ ID is available, consult `why_is_this_here(symbol_id)` and
201
+ `governing_contracts(symbol_id)`. Verify a
202
+ matching decision with `verify_intent` before relying on it. Unknown rationale
203
+ is not evidence that there is no contract. Use graph impact for structure and
204
+ Cortex for recorded choices, conventions and bans. Use `get_style_fingerprint`
205
+ when choosing among competing local idioms.
206
+
207
+ ## Tool arguments
208
+
209
+ Use JSON numbers for limits/depths and booleans for switches. Use symbol names
210
+ for `get_symbol_context.symbol`, `get_impact.target` and relationship targets;
211
+ use IDs only where the specific schema asks for one. Prefer the live schema over
212
+ remembered parameters. `find_code` has no `kind` filter; use `find_symbol` for it.
213
+ Search without an explicit repository uses safe scope inference, not an implicit
214
+ search of every repository. `get_evolution` uses `from`, not `days`.
215
+
216
+ For product setup or usage documentation, use `memtrace-docs`. Full tool parameter
217
+ references are bundled with the skills package. Do not print routine tool usage
218
+ receipts; preserve evidence internally and report meaningful findings and limits.
251
219
 
252
220
  ## Success criteria
253
221
 
254
- - The answer is grounded in Memtrace graph results (search hit → `get_symbol_context` / `get_impact`), not file-tool discovery.
255
- - Grep/Glob/Read appear only via the documented narrow exceptions (non-source artifacts, paths outside every indexed root, file inventory, bounded span reads).
256
- - Zero-result queries were diagnosed (`list_indexed_repositories` → broaden → reindex), not bypassed to grep.
222
+ - The right repository and branch were used.
223
+ - Graph claims are supported by retrieved edges, with missing/truncated data
224
+ made explicit, and exact behavioral claims are checked against source.
225
+ - A `repo_not_in_store` refusal was routed on `diagnostic.repo_lives_in`, not
226
+ answered by grep and not answered by indexing the repository into this store.
227
+ - A zero from a tool that sets no `repo_in_store` key was re-checked through a
228
+ membership-checking tool before it was called an absence.
229
+ - Failed retrieval on a genuine zero (`repo_in_store: true`) is diagnosed and
230
+ bounded; it does not trigger query or reindex loops, and fallbacks remain
231
+ distinguishable from retrieval successes.
257
232
  - Any source read was bounded to the span Memtrace returned.
233
+ - Existing rationale and contracts were checked when the tools were available.
@@ -73,6 +73,18 @@ Params are **`source`** and **`target`** (symbol names) — not `from`/`to`.
73
73
 
74
74
  `find_dependency_path` returns the ordered symbol chain from `source` to `target`; `list_communities` returns module partitions with their member symbols.
75
75
 
76
+ ## A `busy` answer is a wait, not an absence
77
+
78
+ Heavy graph work runs one repository-sized fold at a time, because holding
79
+ two in memory is what the bound protects against. When the lane is already
80
+ held, a caller is not queued indefinitely: after a bounded wait it gets a
81
+ successful answer carrying `"busy": true`, `"lane": "graph_materialization"`,
82
+ `"retryable": true`, and a `holder` block naming the operation that holds the
83
+ lane and how long it has held it. Report it as a wait, retry once the holder
84
+ is likely done, or narrow the call (one `repo_id`, a smaller `limit`, a
85
+ shorter window) so it does not need the lane. Do not read it as an empty
86
+ graph and do not fall back to file search.
87
+
76
88
  ## Common Mistakes
77
89
 
78
90
  | Mistake | Reality |
@@ -33,6 +33,13 @@ root (for example `ui/`, `memtrace-ui/`, `web/`, `frontend/`, or `src/`), treat
33
33
  that as a stale/partial index. Do not use grep as a workaround. Run incremental
34
34
  indexing on the repo root, then retry the Memtrace query.
35
35
 
36
+ If a search instead came back with `error_code: "repo_not_in_store"`, stop.
37
+ That repository is not missing from the index; it is indexed in a different
38
+ store, named in `diagnostic.repo_lives_in`. `list_indexed_repositories` lists
39
+ this session's store only, so its absence there proves nothing. Indexing it
40
+ here would build a second copy in the wrong store. Report the store that holds
41
+ it and route the question to the session or daemon attached to that store.
42
+
36
43
  ### 2. Index the directory
37
44
 
38
45
  Use the `index_directory` MCP tool:
@@ -44,10 +51,20 @@ Use the `index_directory` MCP tool:
44
51
  If the selected path is just a folder containing multiple independent git repos,
45
52
  do not index that parent folder unless the user explicitly wants a shared
46
53
  workspace. For separate repos, index each repo root separately. For intentional
47
- sharing, ask the user to bless the parent explicitly with
48
- `memtrace start --bless-workspace` first, then verify the boundary with
54
+ sharing, the durable form is a portable manifest started with
55
+ `memtrace start --workspace-file <manifest>`; the legacy Folder Group flow is
56
+ `memtrace start --bless-workspace` from the parent, verified with
49
57
  `memtrace workspace status <path>`.
50
58
 
59
+ A store whose membership is already owned by a manifest or a Named Workspace
60
+ cannot be widened from an MCP session, nor by a plain `memtrace start` from a
61
+ parent folder. Adding a repository means restarting that store's daemon with
62
+ the definition that owns it — `memtrace start --workspace-file <manifest>` or
63
+ `memtrace start --workspace <name>`, editing the manifest first when it is a
64
+ manifest. If a start is refused with "a folder-walked start cannot widen it",
65
+ run the command the refusal names. No MCP session can widen an existing store
66
+ under any flag, whatever declared it.
67
+
51
68
  **Success criteria:** You receive a `job_id` immediately.
52
69
 
53
70
  ### 3. Poll for completion