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.
- package/dist/skills.js +2 -1
- package/dist/tool-names.d.ts +1 -0
- package/dist/tool-names.js +101 -0
- package/dist/transformers/cursor.js +1 -1
- package/dist/transformers/pi.d.ts +8 -0
- package/dist/transformers/pi.js +36 -6
- package/package.json +1 -1
- package/plugin-assets/index.d.ts +1 -1
- package/plugin-assets/index.js +5 -1
- package/plugins/memtrace-skills/references/mcp-parameters.md +53 -4
- package/plugins/memtrace-skills/skills/memtrace-codebase-exploration/SKILL.md +17 -0
- package/plugins/memtrace-skills/skills/memtrace-first/SKILL.md +206 -230
- package/plugins/memtrace-skills/skills/memtrace-graph/SKILL.md +12 -0
- package/plugins/memtrace-skills/skills/memtrace-index/SKILL.md +19 -2
- package/plugins/memtrace-skills/skills/memtrace-search/SKILL.md +51 -9
- package/skills/commands/memtrace-graph.md +12 -0
- package/skills/commands/memtrace-index.md +19 -2
- package/skills/commands/memtrace-search.md +53 -9
- package/skills/workflows/memtrace-codebase-exploration.md +17 -0
- package/skills/workflows/memtrace-first.md +206 -230
|
@@ -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
|
|
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
|
-
|
|
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
|
-
|
|
43
|
-
infer that a source subdirectory is outside the index. Diagnose through
|
|
44
|
-
Memtrace:
|
|
11
|
+
## Establish scope
|
|
45
12
|
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
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
|
|
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:
|
|
65
|
-
`memtrace start --
|
|
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
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
-
|
|
81
|
-
`
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
|
|
92
|
-
|
|
93
|
-
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
|
|
97
|
-
|
|
98
|
-
|
|
99
|
-
|
|
100
|
-
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
|
|
107
|
-
|
|
108
|
-
|
|
109
|
-
|
|
110
|
-
|
|
111
|
-
|
|
112
|
-
|
|
113
|
-
|
|
114
|
-
|
|
115
|
-
|
|
116
|
-
|
|
117
|
-
|
|
118
|
-
|
|
119
|
-
|
|
120
|
-
|
|
121
|
-
|
|
122
|
-
|
|
123
|
-
|
|
124
|
-
|
|
125
|
-
|
|
126
|
-
|
|
127
|
-
|
|
128
|
-
|
|
129
|
-
|
|
130
|
-
|
|
131
|
-
|
|
132
|
-
|
|
133
|
-
|
|
134
|
-
|
|
135
|
-
|
|
136
|
-
|
|
137
|
-
|
|
138
|
-
|
|
139
|
-
|
|
140
|
-
|
|
141
|
-
|
|
142
|
-
|
|
143
|
-
|
|
144
|
-
|
|
145
|
-
|
|
146
|
-
|
|
147
|
-
|
|
148
|
-
|
|
149
|
-
|
|
150
|
-
|
|
151
|
-
|
|
152
|
-
|
|
153
|
-
|
|
154
|
-
|
|
155
|
-
|
|
156
|
-
|
|
157
|
-
|
|
158
|
-
|
|
159
|
-
|
|
160
|
-
|
|
161
|
-
|
|
162
|
-
|
|
163
|
-
|
|
164
|
-
|
|
165
|
-
|
|
166
|
-
|
|
167
|
-
|
|
168
|
-
|
|
169
|
-
|
|
170
|
-
|
|
171
|
-
|
|
172
|
-
|
|
173
|
-
|
|
174
|
-
|
|
175
|
-
|
|
176
|
-
|
|
177
|
-
|
|
178
|
-
|
|
179
|
-
|
|
180
|
-
|
|
181
|
-
|
|
182
|
-
|
|
183
|
-
|
|
184
|
-
|
|
185
|
-
|
|
186
|
-
|
|
187
|
-
|
|
188
|
-
|
|
189
|
-
|
|
190
|
-
|
|
191
|
-
|
|
192
|
-
|
|
193
|
-
|
|
194
|
-
|
|
195
|
-
|
|
196
|
-
|
|
197
|
-
|
|
198
|
-
|
|
199
|
-
|
|
200
|
-
|
|
201
|
-
|
|
202
|
-
|
|
203
|
-
|
|
204
|
-
|
|
205
|
-
|
|
206
|
-
|
|
207
|
-
|
|
208
|
-
|
|
209
|
-
|
|
210
|
-
|
|
211
|
-
|
|
212
|
-
|
|
213
|
-
|
|
214
|
-
|
|
215
|
-
|
|
216
|
-
|
|
217
|
-
|
|
218
|
-
|
|
219
|
-
|
|
220
|
-
|
|
221
|
-
`
|
|
222
|
-
|
|
223
|
-
|
|
224
|
-
|
|
225
|
-
|
|
226
|
-
|
|
227
|
-
|
|
228
|
-
|
|
229
|
-
|
|
230
|
-
|
|
231
|
-
|
|
232
|
-
|
|
233
|
-
|
|
234
|
-
|
|
235
|
-
|
|
236
|
-
|
|
237
|
-
|
|
238
|
-
|
|
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
|
|
255
|
-
-
|
|
256
|
-
|
|
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,
|
|
48
|
-
`memtrace start --
|
|
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
|