memtrace 0.6.0 → 0.6.11

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.
Files changed (30) hide show
  1. package/hooks/userprompt-claude.sh +12 -6
  2. package/install.js +0 -19
  3. package/installer/dist/commands/rail-install.d.ts +7 -0
  4. package/installer/dist/commands/rail-install.js +37 -0
  5. package/installer/dist/index.js +20 -1
  6. package/installer/dist/rail-install.d.ts +20 -0
  7. package/installer/dist/rail-install.js +183 -0
  8. package/installer/dist/transformers/claude.d.ts +21 -0
  9. package/installer/dist/transformers/claude.js +118 -3
  10. package/installer/dist/transformers/codex.js +17 -0
  11. package/installer/dist/transformers/cursor.js +23 -1
  12. package/installer/dist/transformers/gemini.d.ts +3 -0
  13. package/installer/dist/transformers/gemini.js +78 -0
  14. package/installer/dist/transformers/index.d.ts +2 -1
  15. package/installer/dist/transformers/index.js +3 -1
  16. package/installer/dist/transformers/opencode.js +31 -0
  17. package/installer/dist/transformers/rail-hooks.d.ts +56 -0
  18. package/installer/dist/transformers/rail-hooks.js +303 -0
  19. package/installer/dist/transformers/shared.js +5 -6
  20. package/installer/dist/transformers/types.d.ts +1 -1
  21. package/installer/skills/commands/memtrace-fleet-publish-intent.md +51 -0
  22. package/installer/skills/commands/memtrace-fleet-record-episode.md +48 -0
  23. package/installer/skills/commands/memtrace-fleet-resolve.md +59 -0
  24. package/installer/skills/workflows/memtrace-code-review.md +6 -0
  25. package/installer/skills/workflows/memtrace-first.md +2 -0
  26. package/installer/skills/workflows/memtrace-fleet-coordination.md +87 -0
  27. package/installer/skills/workflows/memtrace-fleet-first.md +132 -0
  28. package/installer/skills/workflows/memtrace-style-fingerprint.md +111 -0
  29. package/lib/claude-integration.js +6 -0
  30. package/package.json +6 -6
@@ -0,0 +1,59 @@
1
+ ---
2
+ name: memtrace-fleet-resolve
3
+ description: "Use to act on a Class C decision: submit your verdict as an agent judge (fleet_submit_verdict), poll your own directive (fleet_get_escalation), see the needs-human queue (fleet_list_escalations), or record a human decision (fleet_resolve_escalation). Triggered by: 'a decision is waiting', 'who should proceed', being handed a mediation_request, acting as a mediator between two agents, or a human choosing a winner in the dashboard."
4
+ allowed-tools:
5
+ - mcp__memtrace__fleet_submit_verdict
6
+ - mcp__memtrace__fleet_get_escalation
7
+ - mcp__memtrace__fleet_list_escalations
8
+ - mcp__memtrace__fleet_resolve_escalation
9
+ ---
10
+
11
+ ## Overview
12
+
13
+ The tools that resolve a Class C conflict. The judging is done by the user's own
14
+ agents (no API keys): an agent reads the bundle and submits a verdict; the daemon
15
+ is the deterministic referee that decides the outcome and routes it back.
16
+
17
+ ## Submit a verdict (you are the judge)
18
+
19
+ You were handed a `mediation_request` (from `fleet_record_episode`). Read **every
20
+ agent's `assignment`** in it and decide on merit — including against your own
21
+ change:
22
+
23
+ ```jsonc
24
+ fleet_submit_verdict({
25
+ escalation_id: "01J…",
26
+ agent_id: "agent-a",
27
+ verdict: { "kind": "recommend", "winner": "agent-b",
28
+ "rationale": "wider contract; rebase the fix onto it", "confidence": 0.8 }
29
+ })
30
+ // kinds: reconcile {merge_plan} | recommend {winner, rationale, confidence} | defer_to_human {question}
31
+ ```
32
+
33
+ The response tells you the `outcome` (`auto_apply` | `human_confirm` |
34
+ `human_required` | `pending`) and `your_directive`.
35
+
36
+ ## Read your own directive (you are blocked)
37
+
38
+ ```jsonc
39
+ fleet_get_escalation({ escalation_id: "01J…", agent_id: "agent-a" })
40
+ // → your_directive: wait | proceed | defer | review
41
+ ```
42
+
43
+ Poll until it's not `wait`. `proceed` = continue; `defer` = stand down and rebase
44
+ onto the winner; `review` = read `resolution`.
45
+
46
+ ## Human paths
47
+
48
+ - `fleet_list_escalations({repo_id})` — the per-repo "needs human" queue.
49
+ - `fleet_resolve_escalation({escalation_id, resolution, winner})` — record a human
50
+ decision (pick which agent proceeds) and clear it. Prefer the agent-judge path;
51
+ use this for genuine human/product calls.
52
+
53
+ ## Safety the referee guarantees
54
+
55
+ - A destructive **removal** (delete/move) is **never** auto-applied — always a human.
56
+ - Auto-apply happens only for the clear-safe machine case or ≥2 agents agreeing on
57
+ a non-destructive resolution.
58
+ - So a wrong verdict degrades to "a human reviews a suggestion," never a silent
59
+ bad merge.
@@ -22,6 +22,12 @@ Use Memtrace's local-first PR review workflow. The agent should call the `review
22
22
  4. Default to `minSeverity: "high"` and `maxComments: 5` when posting. For previews, `maxComments: 10` is acceptable.
23
23
  5. Pass `repoRoot` when the PR checkout is not the current working directory. Pass `repoId` when the indexed repository id is known.
24
24
 
25
+ ## Example User Prompts
26
+
27
+ - "Review this PR with Memtrace: https://github.com/OWNER/REPO/pull/123"
28
+ - "Use Memtrace to review this pull request and post the findings: https://github.com/OWNER/REPO/pull/123"
29
+ - "Create the PR, then run Memtrace code review and publish the review comments."
30
+
25
31
  ## Guardrails
26
32
 
27
33
  - Do not start with generic grep, rg, or manual diff review when `review_github_pr` is available.
@@ -122,6 +122,7 @@ If not indexed → offer to index with `mcp__memtrace__index_directory`, then fo
122
122
  | What files change together? | `get_cochange_context` |
123
123
  | Architecture overview | `list_communities` + `find_central_symbols` |
124
124
  | About to edit / quote — need exact lines | Bounded `Read(file, offset=start_line, limit=N)` (preferred), or `get_source_window` for path-resolution parity |
125
+ | 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 |
125
126
 
126
127
  ## Standard Workflows
127
128
 
@@ -147,6 +148,7 @@ If not indexed → offer to index with `mcp__memtrace__index_directory`, then fo
147
148
  1. `find_symbol` → confirm you have the right target
148
149
  2. `get_symbol_context` → understand full context
149
150
  3. `get_impact` → know blast radius before touching anything
151
+ 4. `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
150
152
 
151
153
  ## Red Flags — STOP, Use Memtrace Instead
152
154
 
@@ -0,0 +1,87 @@
1
+ ---
2
+ name: memtrace-fleet-coordination
3
+ description: "Use when you need to understand or act on fleet conflict resolution: what conflict class A/B/C means, how a Class C destructive overlap gets decided (by an agent judge or a human), how to be the judge (fleet_submit_verdict), how to read your directive after a decision, and how branch-scoping isolates fleets. Triggered by: 'two agents are changing the same thing', 'resolve this conflict', 'who should proceed', 'a decision is waiting', acting as a mediator between agents."
4
+ allowed-tools:
5
+ - mcp__memtrace__fleet_record_episode
6
+ - mcp__memtrace__fleet_submit_verdict
7
+ - mcp__memtrace__fleet_get_escalation
8
+ - mcp__memtrace__fleet_list_escalations
9
+ - mcp__memtrace__fleet_resolve_escalation
10
+ - mcp__memtrace__fleet_get_node_state
11
+ ---
12
+
13
+ # Fleet Coordination
14
+
15
+ How the fleet turns overlapping edits into a safe decision. Read
16
+ `memtrace-fleet-first` for the publish→edit→record protocol; this skill is the
17
+ *conflict resolution* half.
18
+
19
+ ## Conflict classes (what `fleet_record_episode` returns)
20
+
21
+ | Class | Meaning | What to do |
22
+ |---|---|---|
23
+ | **A** | Additive, order-independent | Proceed. |
24
+ | **B** | Non-destructive overlap with another agent's work | Re-read the shared symbols, then proceed. |
25
+ | **C** | A **destructive** change (signature change / move / dead-code removal) overlaps another agent's work | A decision is needed — it does NOT auto-resolve. |
26
+
27
+ Class is computed **only against agents on your branch** (`(repo, branch)`).
28
+ Agents on other branches are never conflict peers.
29
+
30
+ ## The Class C decision loop
31
+
32
+ When `fleet_record_episode` returns class C it also returns an `escalation_id` and
33
+ (when mediation is on) a `mediation_request`. The decision is made by an **agent
34
+ judge**, a **human**, or — only when provably safe — the **deterministic referee**.
35
+
36
+ ### Being the judge (the user's own agent does the judging — no API keys)
37
+
38
+ The `mediation_request` bundles **every agent's `assignment`** plus the contested
39
+ symbols. Read the *other* agent's task and decide on merit (including against your
40
+ own change). Submit:
41
+
42
+ ```jsonc
43
+ fleet_submit_verdict({
44
+ escalation_id: "01J…",
45
+ agent_id: "agent-a",
46
+ verdict: { "kind": "recommend", "winner": "agent-b",
47
+ "rationale": "the signature change is the wider contract; rebase the fix onto it",
48
+ "confidence": 0.8 }
49
+ })
50
+ ```
51
+
52
+ Verdict kinds: `reconcile {merge_plan}` · `recommend {winner, rationale, confidence}`
53
+ · `defer_to_human {question}`.
54
+
55
+ The referee then decides the outcome:
56
+ - **Auto-apply** only when safe: the clear machine case, or ≥2 independent agents
57
+ agree — and **never** for a destructive *removal* (delete/move), which always
58
+ needs a human.
59
+ - **Human confirm** — a recommendation is surfaced for one-click confirmation.
60
+ - **Human required** — both sides destructive, agents disagree, or an agent
61
+ deferred → a person decides.
62
+
63
+ ### Reading your directive
64
+
65
+ Poll `fleet_get_escalation({escalation_id, agent_id})` until `your_directive` ≠
66
+ `wait`: `proceed` (you continue), `defer` (stand down / rebase onto the winner),
67
+ `review` (read `resolution`).
68
+
69
+ ### Resolving as a human (or on a human's behalf via the dashboard)
70
+
71
+ `fleet_resolve_escalation({escalation_id, resolution, winner})` records a human
72
+ decision and clears the queue. Prefer the agent-judge path; use this for the
73
+ genuine human-decision cases. `fleet_list_escalations({repo_id})` shows the
74
+ "needs human" queue.
75
+
76
+ ## Why branch-scoping matters here
77
+
78
+ A "winner / defer" only makes sense on a shared surface. Across branches, the
79
+ loser can't defer (its branch needs the change too), so the fleet never escalates
80
+ cross-branch — that's a merge-time concern git already owns. Keep your fleet to
81
+ one session branch and conflicts stay real and resolvable.
82
+
83
+ ## Inspecting state
84
+
85
+ `fleet_get_node_state({repo_id, node})` — recent episodes, active intents, dominant
86
+ intent, and conflict density for one symbol. Use it to understand pressure on a
87
+ hot symbol before you pile on.
@@ -0,0 +1,132 @@
1
+ ---
2
+ name: memtrace-fleet-first
3
+ description: "Always use FIRST when more than one coding agent works the same repo+branch at once (a 'fleet'), before reading code, planning a refactor, or making an edit. Triggered by: 'I'm about to edit X', 'rename Y across the codebase', joining a running fleet/session branch, coordinating with other agents, prose hand-offs. Do not grep for 'who else is touching this' and do not skip fleet_publish_intent because 'it's a small change'. Fleet coordination is branch-scoped: pass your session branch so your fleet coordinates and stays isolated from agents on other branches. Skip ONLY for genuinely solo sessions or pure docs-only edits where coordination has zero value."
4
+ allowed-tools:
5
+ - mcp__memtrace__fleet_status
6
+ - mcp__memtrace__fleet_preflight
7
+ - mcp__memtrace__fleet_publish_intent
8
+ - mcp__memtrace__fleet_record_episode
9
+ - mcp__memtrace__fleet_get_escalation
10
+ - mcp__memtrace__fleet_submit_verdict
11
+ ---
12
+
13
+ # Fleet First
14
+
15
+ The coordination layer for **fleets of coding agents** working the same repo at the
16
+ same time. It stops agents from silently clobbering each other's edits, and turns
17
+ unsafe overlaps into a clear decision instead of a merge-time surprise.
18
+
19
+ ## The Iron Law
20
+
21
+ ```
22
+ IN A FLEET → FLEET TOOLS BEFORE EDITS. NO EXCEPTIONS.
23
+ 1. fleet_publish_intent (declare what you'll touch; get blast radius + conflicts)
24
+ 2. edit (your normal edit loop)
25
+ 3. fleet_record_episode (classify A/B/C; if C, the loop resolves it)
26
+ ```
27
+
28
+ A typed intent serializes to ~20 tokens; a prose "I'm going to change X" averages
29
+ 200+. A 10-agent fleet × 100 edits = tens of thousands of tokens saved per
30
+ fleet-turn — and zero silent overwrites — when the protocol is followed.
31
+
32
+ ## A fleet = agents on ONE branch (always pass it)
33
+
34
+ **Coordination is branch-scoped.** Two agents only coordinate when they're on the
35
+ **same `(repo, branch)`**. The branch name is the fleet identifier: a *session
36
+ branch* is how a group of agents opts into one coordinating fleet.
37
+
38
+ - Working a session branch (`session/auth-revamp`)? Pass `branch` on **every**
39
+ fleet call. Your fleet coordinates together and stays isolated from agents on
40
+ other branches.
41
+ - Omit `branch` only for the shared default pool (single, unnamed fleet).
42
+ - Agents on **different** branches never conflict — git already isolates them, and
43
+ whether branches merge isn't guaranteed, so the fleet never reasons across them.
44
+
45
+ ```jsonc
46
+ { "repo_id": "myrepo", "branch": "session/auth-revamp",
47
+ "agent_id": "agent-a", "touched": ["auth::verify_token"],
48
+ "intent": {"refactor": {"pattern": "change_signature"}},
49
+ "assignment": "widen verify_token signature for pagination" }
50
+ ```
51
+
52
+ Always include **`assignment`** — your natural-language task. When a conflict
53
+ happens, that's what the judge (another agent) or a human reads to reconcile.
54
+
55
+ ## Check the fleet first (once per session)
56
+
57
+ ```
58
+ fleet_status() → live_intents, active_agents, pending_escalations, mediator_mode
59
+ ```
60
+
61
+ If it responds, fleet coordination is active — follow this skill for every edit.
62
+ An empty fleet is **not** permission to skip: it just means you're the first agent
63
+ in this window.
64
+
65
+ ## The protocol, step by step
66
+
67
+ 1. **Before editing** — `fleet_preflight({repo_id, branch, agent_id, touched, intent})`
68
+ (read-only) or go straight to `fleet_publish_intent(...)`. You get the blast
69
+ radius, any overlapping live intents on your branch, and a `coordination` block
70
+ that may already suggest who owns a contested symbol.
71
+ 2. **Edit** — your normal loop.
72
+ 3. **After editing** — `fleet_record_episode({repo_id, branch, agent_id, touched, intent})`.
73
+ It returns a `conflict_class`:
74
+ - **A — proceed.** Additive, order-independent. Nothing to do.
75
+ - **B — re-read, then proceed.** You overlap non-destructively; re-read the
76
+ shared symbols so you build on current state.
77
+ - **C — a decision is needed.** A destructive change overlaps another agent's
78
+ work. This does **not** auto-resolve — see below.
79
+
80
+ ## Class C: the decision loop (read this)
81
+
82
+ A Class C means two edit paths can't both land safely. `fleet_record_episode`
83
+ returns an `escalation_id` and a `mediation_request` (when mediation is enabled).
84
+ What happens next depends on who judges:
85
+
86
+ - **You may be asked to judge.** The `mediation_request` carries **every agent's
87
+ assignment** — including the other side's. Read them and submit a verdict with
88
+ `fleet_submit_verdict({escalation_id, agent_id, verdict})`, where `verdict` is one
89
+ of:
90
+ - `{"kind":"reconcile","merge_plan":"…"}` — the changes combine; here's how.
91
+ - `{"kind":"recommend","winner":"<agent_id>","rationale":"…","confidence":0.0-1.0}` —
92
+ one path should continue.
93
+ - `{"kind":"defer_to_human","question":"…"}` — a real product call; ask a human.
94
+ - **A human may decide** in the Fleet dashboard. Either way the outcome flows back
95
+ to you.
96
+ - **Close YOUR loop**: poll `fleet_get_escalation({escalation_id, agent_id})` until
97
+ `your_directive` is no longer `wait`:
98
+ - `proceed` — you were chosen; continue.
99
+ - `defer` — another path won; stand down and rebase your work onto it.
100
+ - `review` — read the free-text `resolution`.
101
+
102
+ The daemon is a deterministic referee: it never auto-applies a destructive
103
+ *removal* (delete/move) without a human, and only auto-applies when it's safe (a
104
+ clear machine case, or independent agent consensus). So the judge being wrong
105
+ degrades to "a human reviews a suggestion," never a silent bad merge.
106
+
107
+ ## Routing — what do you need?
108
+
109
+ | You're about to… | Do this |
110
+ |---|---|
111
+ | Start any edit in a fleet | `fleet_publish_intent` (declare it) — never skip |
112
+ | Check before declaring | `fleet_preflight` (read-only "is the coast clear?") |
113
+ | Finish an edit | `fleet_record_episode` (get A/B/C) |
114
+ | Got a Class C as the judge | `fleet_submit_verdict` (reconcile/recommend/defer) |
115
+ | Blocked on a Class C | poll `fleet_get_escalation` until `your_directive ≠ wait` |
116
+ | See who's in the fleet | `fleet_status` (active_agents, pending decisions) |
117
+ | Inspect a symbol's coordination state | `fleet_get_node_state` |
118
+
119
+ ## Parameter notes
120
+
121
+ - Pass `intent` as JSON (externally-tagged, snake_case):
122
+ `{"refactor":{"pattern":"rename_symbol"}}`, `{"bug_fix":{"defect":"logic_error"}}`.
123
+ Destructive kinds: `refactor/change_signature`, `refactor/move_symbol`,
124
+ `cleanup/dead_code` — these are what trigger Class C over shared symbols.
125
+ - `touched` is a list of qualified symbol identities (e.g. `"module::Symbol"`).
126
+ - Always include `branch` (your session branch) and `assignment` (your task).
127
+
128
+ ## When to skip
129
+
130
+ Skip the protocol only for a genuinely **solo** session (you're the only agent and
131
+ no one else shares your branch) or **pure docs-only** edits where coordination has
132
+ zero value. Everything else in a fleet goes through the protocol.
@@ -0,0 +1,111 @@
1
+ ---
2
+ name: memtrace-style-fingerprint
3
+ description: "Always use before writing or editing source code in an indexed repo when choosing between competing idioms (ternary vs if-else, arrow vs function declaration, const vs let, await vs .then, early-return vs nested-return). Pull the codebase's empirical style norm from Memtrace and match it instead of re-deriving style from training priors. Do not maintain a markdown style guide for the project; the fingerprint is sampled live from the actual code."
4
+ allowed-tools:
5
+ - mcp__memtrace__get_style_fingerprint
6
+ - mcp__memtrace__get_codebase_briefing
7
+ - mcp__memtrace__find_code
8
+ - mcp__memtrace__list_indexed_repositories
9
+ user-invocable: true
10
+ ---
11
+
12
+ ## Overview
13
+
14
+ Every indexed Memtrace repository carries an empirical **style fingerprint** — descriptive histograms of competing AST idioms (ternary vs if-else, arrow vs function declaration, const vs let, await vs `.then`, early-return vs nested-return depth) computed at parse time and rolled up to Repository + Community level. This workflow tells you when and how to consult it so your edits match the codebase's existing idioms instead of drifting on stylistic choices the linter doesn't catch.
15
+
16
+ The fingerprint is **descriptive, not prescriptive**. It reports what the codebase actually does, not what a style guide says it should do. If the codebase deviates from a popular convention for some reason, the fingerprint captures the deviation and you should match the deviation — that's the whole point. For prescriptive bug/security/perf rules, use `find_code_review_issues` instead.
17
+
18
+ ## When to use this workflow
19
+
20
+ | Situation | Action |
21
+ |---|---|
22
+ | About to write new code (function, component, module) in an indexed repo | Step 1 + Step 2 with `file_path=<the file you'll create>` |
23
+ | About to edit an existing file | Step 1 + Step 2 with `file_path=<that file>` |
24
+ | Asked "what's the convention here for X?" | Step 1 only — repo-mode fingerprint answers it |
25
+ | Deciding between two equivalent idioms (ternary vs if, arrow vs fn-decl, await vs then) | Step 2 with `file_path` — `delta_from_codebase_norm` tells you which idiom matches the norm |
26
+ | Reviewing a diff | Step 2 on each modified file — flag any new idioms that diverge from the file's language norm |
27
+ | Session start in a multi-day project | Read the `style:` line in `get_codebase_briefing` (auto-included) |
28
+
29
+ If the repo is not indexed in Memtrace, this workflow does not apply — fall back to your default behavior.
30
+
31
+ ## Steps
32
+
33
+ ### 1. Get the codebase's overall norm
34
+
35
+ Call `get_style_fingerprint(repo_id)` with no `file_path`. The response includes:
36
+
37
+ - `histogram` — raw counts (e.g. `ternary_count: 1005, if_stmt_count: 8087`)
38
+ - `ratios` — computed shares for each competing pair (e.g. `ternary_share: 0.11`)
39
+ - `dominant_idioms` — top-3 dimensions sorted by `|ratio - 0.5|` (strongest preferences first), each with a `dimension`, `ratio`, and human-readable `interpretation`
40
+ - `function_count` — sample size at the repo level
41
+ - `sample_threshold` — minimum observations before a ratio is committed (currently 20)
42
+
43
+ A `ratio` of `null` means the codebase doesn't have enough observations for that dimension to commit a norm — treat it as "no signal", do not assume one.
44
+
45
+ ### 2. Get the file's deviation from the norm (when about to edit a specific file)
46
+
47
+ Call `get_style_fingerprint(repo_id, file_path=<file>)`. The response adds:
48
+
49
+ - `file_fingerprint` — the same shape as `histogram`/`ratios`/`function_count` but computed over just the functions in that file
50
+ - `codebase_fingerprint` — repo aggregate for comparison
51
+ - `delta_from_codebase_norm` — array of dimensions where the file diverges ≥0.15 from the codebase, sorted by absolute delta, capped at top 5. Each entry has `dimension`, `file_ratio`, `codebase_ratio`, `abs_delta`, and a `note` describing the direction
52
+
53
+ **Match the file's `language_fingerprint`, not the repo aggregate.** In file mode the response carries `language` (the file's language), `language_fingerprint` (that language's slice — the primary comparator), and `delta_from_language_norm` (divergence vs the language, not the repo). Per-language slicing prevents cross-applying Python norms to JS code or vice versa — read the `language_fingerprint`. (`delta_from_codebase_norm` is retained as a deprecated alias and is removed in 0.5.14.)
54
+
55
+ If `delta_from_language_norm` is empty, the file is already aligned — proceed without style adjustments. If it has entries, your edits should not amplify the divergence (e.g. don't add more ternaries to a file that's already above the language's ternary norm).
56
+
57
+ ### 3. Read the briefing line at session start (passive)
58
+
59
+ `get_codebase_briefing(repo_id)` auto-includes a `style:` line in its summary when the sample threshold is met and at least one ratio is outside the 0.4..0.6 no-preference band. Format:
60
+
61
+ ```
62
+ style: <interpretation 1> (<%>); <interpretation 2> (<%>); <interpretation 3> (<%>)
63
+ ```
64
+
65
+ Example on a TS/JS-heavy codebase:
66
+
67
+ ```
68
+ style: strongly prefers arrow functions (98%); strongly prefers async/await over .then chains (88%); strongly prefers const over let (94%)
69
+ ```
70
+
71
+ You should already be reading the briefing at session start (per `memtrace-codebase-exploration`). The `style:` line lands in your context for free — no extra call needed.
72
+
73
+ ## Decision points
74
+
75
+ | Condition | Action |
76
+ |---|---|
77
+ | `dominant_idioms[0].ratio >= 0.85` or `<= 0.15` | Treat as a hard preference — match it unless there's a specific structural reason not to |
78
+ | `dominant_idioms[0].ratio` in `0.65..0.85` or `0.15..0.35` | Treat as a soft preference — match it for new code, leave existing patterns alone |
79
+ | `ratio` in `0.4..0.6` | No clear preference — use your own judgment, match local file context |
80
+ | `ratio` is `null` (below sample threshold) | No signal — don't assume a norm; pick the idiom that fits the immediate context |
81
+ | `delta_from_codebase_norm` shows your target file already diverges from the norm | Don't amplify the divergence with your edits — match the codebase, not the outlier file |
82
+ | `file_fingerprint` is empty (file has no functions yet, or is a config file) | Use the language slice or repo aggregate; this is creation territory |
83
+
84
+ ## Anti-patterns — do not do these
85
+
86
+ - **Reading the repo aggregate when editing a single-language file.** If the codebase is 70% TS / 30% Python, the repo aggregate mixes both. The `language_fingerprint` (when available) or `codebase_fingerprint.ratios` filtered by the file's language is what you should match. Cross-applying TS norms to a Python file is the failure mode this whole tool exists to prevent.
87
+ - **Treating the fingerprint as prescriptive.** It tells you what the codebase does. If the codebase consistently does something unusual, match that — don't override with "this isn't best practice" arguments. The whole point is to stop drifting from the codebase's own choices.
88
+ - **Calling `get_style_fingerprint` for every line of code.** Once per file at the start of an edit session is enough. The norm doesn't change between your edits within the same session.
89
+ - **Ignoring the briefing line.** It auto-loads into your context. If you act on style choices in an edit session without reading it first, you're spending tool calls to re-derive something you already had.
90
+ - **Adding a markdown style guide to the project.** The fingerprint is the style guide. It refreshes on every reindex. A markdown file would either duplicate it or contradict it.
91
+
92
+ ## Naming-case dimensions (shipped in 0.5.13)
93
+
94
+ Beyond the AST idioms, the fingerprint also reports identifier **naming-case** per scope, across all 13 source languages:
95
+
96
+ - **Variables / functions / types / constants / files** — the share of camelCase / snake_case / PascalCase / SCREAMING_SNAKE / kebab. Read e.g. `ratios.naming_variables_snake_share` or the `dominant_idioms` entry that names the scope's winning case ("vars are snake_case (89%)").
97
+ - **Config keys** for YAML / JSON / TOML / HCL / SQL — `ratios.config_keys_*_share`.
98
+ - **Enforcement-aware:** languages that compiler-enforce a scope return `null` for it (Rust vars/fns/types/consts, Ruby constants). A `null` there means "the compiler decides, not the codebase" — don't try to match a non-signal.
99
+ - **Go** reports `go_exported_share` (PascalCase = exported) instead of per-case naming, because case encodes visibility in Go.
100
+
101
+ When editing, match the naming case the file's `language_fingerprint` reports for the scope you're touching — same per-language rule as the idiom dimensions.
102
+
103
+ ## What this workflow does NOT cover
104
+
105
+ - **Security / bug / performance rules** — use `find_code_review_issues` (prescriptive deterministic review).
106
+ - **Comment / docstring style** — not in scope; use file-local examples.
107
+ - **Architecture / module-organization decisions** — see `memtrace-codebase-exploration` and `memtrace-refactoring-guide`.
108
+
109
+ ## Why this exists
110
+
111
+ Without this workflow, LLM editors drift session-to-session on style choices that aren't enforced by linters — one session uses ternaries, the next doesn't; one uses arrow functions, the next uses `function`. The fix isn't a manually-maintained style guide (stale by week 2). The fix is sampling the codebase's actual idioms at parse time and reading them before each edit. The fingerprint is computed in the same parse pass as cyclomatic + cognitive complexity at sub-1% overhead, so the cost of providing the answer is near zero.
@@ -209,6 +209,12 @@ function applySettingsHooks(settings, hooksDir) {
209
209
  postToolHook,
210
210
  );
211
211
 
212
+ // NOTE: the Rail PreToolUse hook is intentionally NOT registered here.
213
+ // The multi-host installer owns Rail across ALL agents uniformly
214
+ // (installer/src/transformers/{claude,codex,gemini,cursor,opencode}.ts via
215
+ // rail-hooks.ts). Registering it here too would double-register the Claude
216
+ // hook (this path runs after the bundled installer and its command string
217
+ // evades the substring dedup), firing the router twice per tool call.
212
218
  return out;
213
219
  }
214
220
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "memtrace",
3
- "version": "0.6.0",
3
+ "version": "0.6.11",
4
4
  "description": "Code intelligence graph — MCP server + AI agent skills + visualization UI",
5
5
  "keywords": [
6
6
  "mcp",
@@ -39,11 +39,11 @@
39
39
  "fs-extra": "^11.0.0"
40
40
  },
41
41
  "optionalDependencies": {
42
- "@memtrace/darwin-arm64": "0.6.0",
43
- "@memtrace/linux-x64": "0.6.0",
44
- "@memtrace/win32-x64": "0.6.0",
45
- "@memtrace/linux-x64-noavx2": "0.6.0",
46
- "@memtrace/win32-x64-noavx2": "0.6.0"
42
+ "@memtrace/darwin-arm64": "0.6.11",
43
+ "@memtrace/linux-x64": "0.6.11",
44
+ "@memtrace/win32-x64": "0.6.11",
45
+ "@memtrace/linux-x64-noavx2": "0.6.11",
46
+ "@memtrace/win32-x64-noavx2": "0.6.11"
47
47
  },
48
48
  "engines": {
49
49
  "node": ">=18"