memtrace 0.8.3 → 0.8.5

package/skills/commands/memtrace-preflight.md

@@ -1,10 +1,13 @@
 ---
 name: memtrace-preflight
-description: "Run a one-call pre-flight check on a single existing symbol before editing it: blast radius (who depends on it), co-change partners (files that historically change with it), complexity, 30-day churn, and a generated verification checklist. Use before modifying any existing function or symbol you did not just write. Do not start editing a non-trivial existing function without a pre-flight check; Memtrace knows the dependency graph and change history. For a full multi-symbol change plan or what-will-break analysis, use memtrace-change-impact-analysis."
+description: "Run a one-call pre-flight check on a single existing symbol before editing it: blast radius, co-change partners, complexity, 30-day churn, and verification checklist, then check Cortex decision memory for rationale/bans when intent may matter. Use before modifying any existing function or symbol you did not just write. Do not start editing a non-trivial existing function without pre-flight plus decision-memory recall/provenance; Memtrace knows the dependency graph, change history, and recorded decisions."
 allowed-tools:
   - mcp__memtrace__preflight_check
   - mcp__memtrace__get_impact
   - mcp__memtrace__get_cochange_context
+  - mcp__memtrace__recall_decision
+  - mcp__memtrace__why_is_this_here
+  - mcp__memtrace__governing_contracts
 metadata:
   author: "Syncable <support@syncable.dev>"
   version: "1.0.0"
@@ -26,6 +29,8 @@ symbol.
 | `preflight_check` | Full radar for one symbol: blast radius + co-change + churn + checklist |
 | `get_impact` | Deeper blast-radius walk when the radar flags HIGH/CRITICAL |
 | `get_cochange_context` | Wider co-change window when partners look surprising |
+| `recall_decision` | Recorded choices, bans, and conventions for the symbol/subsystem/behavior |
+| `why_is_this_here` / `governing_contracts` | Symbol-scoped rationale and constraints when a symbol id is available |
 
 > **Parameter types:** MCP parameters are strictly typed. Numbers must be
 
@@ -65,12 +70,23 @@ frequent partner, say so explicitly and why.
 - The complexity number should not have grown without a stated reason;
   if it did, simplify before declaring the work done.
 
+### Cortex gate before editing
+
+Before changing behavior, deleting code, or refactoring odd/legacy code:
+
+1. Run `recall_decision("<symbol/subsystem/behavior>")`.
+2. If the preflight/graph result gives you a numeric `symbol_id`, run
+   `why_is_this_here(symbol_id)` and `governing_contracts(symbol_id)`.
+3. Honor matching held decisions/bans. Treat CannotProve as unknown, not approval.
+
 ## Verdict guidance
 
 - `risk: CRITICAL/HIGH` — propose the change plan before editing; consider
   a feature flag or staged rollout.
 - `dependents: 0` — edit freely; note the symbol may be newly added or an
   entry point.
+- A matching Cortex decision/ban — surface it before editing and do not
+  contradict it without explicit user sign-off.
 
 ## Output
 

package/skills/commands/memtrace-provenance.md

@@ -1,6 +1,6 @@
 ---
 name: memtrace-provenance
-description: "Retrieve the governing decision lineage (why is this here) and the contracts that bind a symbol, from Cortex decision memory. Use before deleting, rewriting, or 'cleaning up' code that looks unused, odd, or redundant, and when the user asks why a symbol exists or what rules constrain it. Symbol-scoped; for free-text decision search use memtrace-decision-recall. Do not infer intent from the diff or assume unfamiliar code is safe to remove."
+description: "Retrieve the governing decision lineage (why is this here) and contracts that bind a symbol from Cortex decision memory through the normal Memtrace MCP server. Use before deleting, rewriting, refactoring, or 'cleaning up' existing code that looks unused, odd, redundant, legacy, or policy-sensitive, and when the user asks why a symbol exists or what rules constrain it. Symbol-scoped; for free-text decision search use memtrace-decision-recall first. Do not infer intent from the diff or assume unfamiliar code is safe to remove."
 allowed-tools:
   - mcp__memtrace__why_is_this_here
   - mcp__memtrace__governing_contracts
@@ -46,7 +46,10 @@ Full parameter spec for every Memtrace tool: `references/mcp-parameters.md` (bun
 ### 1. Get the symbol_id
 
 If you have a name or a "why" question, run `recall_decision(...)` first and take the
-`symbol_id` from the result (or the Cortex view). The id-based tools need a numeric id.
+`symbol_id` from the result if present, or use the id returned by a graph/Cortex view.
+The id-based tools need a numeric id. If you cannot get a symbol id, do not skip
+decision memory entirely: use `recall_decision("<symbol/subsystem/behavior>")` and
+report any matching decision/bans before changing the code.
 
 ### 2. Ask why it's here
 
@@ -71,8 +74,8 @@ was superseded via `recall_decision`) changes whether the code should still look
 | Situation | Action |
 |-----------|--------|
 | Code looks unused/dead and you want to delete it | `why_is_this_here` + `governing_contracts` BEFORE deleting; CannotProve is not a green light |
-| Code is written in a strange/non-obvious way | `why_is_this_here` — there's likely a decision explaining the oddity |
-| About to refactor a symbol's internals | `governing_contracts` — preserve every constraint, not just the test surface |
+| Code is written in a strange/non-obvious way | `why_is_this_here` if you have a symbol id; otherwise `recall_decision` for the symbol/subsystem |
+| About to refactor a symbol's internals | `why_is_this_here` + `governing_contracts` — preserve the rationale and every constraint, not just the test surface |
 | User asks "why is this here?" | `why_is_this_here(symbol_id)`; if you only have a name, `recall_decision` first |
 | All provenance returns CannotProve | Treat as unknown; combine with `memtrace-impact` (blast radius) and ask the user before removing |
 

package/skills/workflows/memtrace-change-impact-analysis.md

@@ -1,6 +1,6 @@
 ---
 name: memtrace-change-impact-analysis
-description: "Compute what a planned source-code change will break — blast radius, affected processes, cross-repo callers — and produce a risk-rated change plan. Use when the user needs to know what will break before a change: edits, refactors, API changes, renames, removals, PR reviews, or risk assessments. Do not manually grep references or browse files for impact; this workflow uses Memtrace graph context, impact, and change history. For a quick blast-radius check on one symbol, use memtrace-impact."
+description: "Compute what a planned source-code change will break — blast radius, affected processes, cross-repo callers, temporal stability, and Cortex decision-memory constraints — and produce a risk-rated change plan. Use before edits, refactors, API changes, renames, removals, PR reviews, or risk assessments, especially when changing established behavior or deleting code. Do not manually grep references or browse files for impact; use Memtrace graph context, change history, and decision recall/provenance."
 allowed-tools:
   - mcp__memtrace__find_symbol
   - mcp__memtrace__find_code
@@ -9,6 +9,10 @@ allowed-tools:
   - mcp__memtrace__get_evolution
   - mcp__memtrace__get_timeline
   - mcp__memtrace__analyze_relationships
+  - mcp__memtrace__recall_decision
+  - mcp__memtrace__why_is_this_here
+  - mcp__memtrace__governing_contracts
+  - mcp__memtrace__verify_intent
 metadata:
   author: "Syncable <support@syncable.dev>"
   version: "1.0.0"
@@ -18,7 +22,7 @@ user-invocable: true
 
 ## Overview
 
-Pre-change risk assessment workflow. Before modifying code, this workflow maps the full blast radius, identifies affected processes, checks recent change history for instability signals, and produces a risk-rated change plan.
+Pre-change risk assessment workflow. Before modifying code, this workflow maps the full blast radius, identifies affected processes, checks recent change history for instability signals, checks Cortex decision memory for recorded decisions/bans/contracts, and produces a risk-rated change plan.
 
 ## Steps
 
@@ -55,20 +59,30 @@ For each target, call `get_impact` (`repo_id`, `target`) with `direction: "both"
 | High | Plan incremental migration; consider feature flags |
 | Critical | Full migration strategy; backward-compatible changes required |
 
-### 4. Check temporal stability
+### 4. Check Cortex decision memory
+
+For each target or subsystem, call `recall_decision("<target/subsystem/approach>")`.
+If the graph result exposes a numeric `symbol_id`, also call
+`why_is_this_here(symbol_id)` and `governing_contracts(symbol_id)`.
+
+- Matching decision/ban/convention → include it in the plan before recommending a change.
+- Decision you intend to rely on → run `verify_intent(decision_id)` first.
+- CannotProve → record "no decision proven"; do not treat it as approval.
+
+### 5. Check temporal stability
 
 Call `get_evolution` (`repo_id`, `from: "30d ago"`, `mode: "compound"`), then `get_timeline` on each target symbol (requires `scope_path` + `file_path` from `find_symbol`):
 - Sparse timeline history + you're about to change it → structurally surprising; extra scrutiny warranted.
 - Target appears in `top_touched_symbols` → high churn + high impact = volatile hotspot.
 
-### 5. Map affected execution flows
+### 6. Map affected execution flows
 
 From step 2, you already know which processes are affected. For critical changes, use `analyze_relationships` (`repo_id`, `target`) with `query_type: "find_callers"` at `depth: 3` to trace the full transitive caller chain.
 
 `depth: 3` is a JSON number, not a string — the validator rejects `"3"`.
 Full parameter spec for every Memtrace tool: `references/mcp-parameters.md` (bundled at the memtrace-skills plugin root).
 
-### 6. Produce the risk assessment
+### 7. Produce the risk assessment
 
 Synthesize into a change plan:
 
@@ -77,8 +91,9 @@ Synthesize into a change plan:
 3. **Affected Processes** — which execution flows will be impacted
 4. **Cross-Service Impact** — any external callers or consumers
 5. **Stability Signal** — sparse `get_timeline` history (stable) vs frequent appearance in `top_touched_symbols` (volatile)
-6. **Recommended Approach** — based on risk: direct change, incremental migration, or backward-compatible evolution
-7. **Test Coverage** — which callers/processes to verify after the change
+6. **Decision Memory** — relevant decisions/bans/contracts, or CannotProve as unknown
+7. **Recommended Approach** — based on risk and decision constraints: direct change, incremental migration, or backward-compatible evolution
+8. **Test Coverage** — which callers/processes to verify after the change
 
 ## Decision Points
 
@@ -89,6 +104,7 @@ Synthesize into a change plan:
 | Symbol has sparse timeline but high impact | Extra review — this rarely changes; make sure the change is intentional |
 | Multiple processes affected | List each affected flow; recommend testing each one |
 | Symbol is a bridge point | Change may disconnect parts of the architecture — verify alternative paths exist |
+| Cortex returns a held ban/contract | Do not recommend contradicting it without explicit user sign-off |
 
 ## Output
 

package/skills/workflows/memtrace-decision-memory.md

@@ -1,6 +1,6 @@
 ---
 name: memtrace-decision-memory
-description: "Check Cortex decision memory — the umbrella entry point for decision recall, provenance (why is this here), intent verification, and governing contracts. Use before assuming WHY code exists, before making a choice that may contradict a past one, or before deleting/rewriting code that looks odd or redundant. Route: free-text what-was-decided → memtrace-decision-recall; why does this symbol exist / what constrains it → memtrace-provenance; did the decision hold → memtrace-intent-verification. Do not guess rationale from the diff or git log; Cortex remembers the decision, the ban, and whether it still holds."
+description: "Check Cortex decision memory through the normal Memtrace MCP tools — the umbrella entry point for decision recall, provenance (why is this here), intent verification, and governing contracts. Use before assuming WHY code exists, before any non-trivial edit/refactor/delete of existing code, before re-picking a library/pattern/architecture, or before contradicting an apparent convention. Route: free-text decisions/bans/conventions → memtrace-decision-recall; symbol lineage/contracts → memtrace-provenance; did the decision hold → memtrace-intent-verification. Do not guess rationale from the diff or git log."
 allowed-tools:
   - mcp__memtrace__recall_decision
   - mcp__memtrace__why_is_this_here
@@ -52,12 +52,14 @@ These five tools are **deterministic, zero-LLM**. Every call returns a labeled
 `CannotProve` is a real, trustworthy answer ("memory has nothing on this"), not a
 failure and not a green light. Never invent a rationale to fill the gap.
 
-## Server check (once per session)
+## Tool availability (once per session)
 
-These tools are served by the **`memcortex`** MCP server (decision memory), separate
-from the `memtrace` code-graph server. If `recall_decision` isn't available, decision
-memory isn't wired in this environment — say so and use `memtrace-first` instead;
-don't fabricate decisions.
+These tools are exposed on the normal **`memtrace` MCP server**:
+`recall_decision`, `why_is_this_here`, `verify_intent`, `get_arc`, and
+`governing_contracts`. Hosts do not need a second MemCortex MCP connection. If a
+tool call returns CannotProve because Cortex is unavailable (for example native
+Windows without WSL2), say decision memory was unavailable/unknown and continue
+with `memtrace-first`; do not fabricate decisions.
 
 ## The decision rule
 
@@ -65,9 +67,9 @@ don't fabricate decisions.
 |---|---|---|
 | "Did we already decide/choose/reject X?" "What's our convention on Y?" | `recall_decision("X")` | `memtrace-decision-recall` |
 | "Is there a ban / a 'don't do this' on Z?" | `recall_decision("Z")` — bans surface as decisions | `memtrace-decision-recall` |
-| About to re-pick a library/pattern/approach | `recall_decision` FIRST — don't re-litigate a settled call | `memtrace-decision-recall` |
+| About to edit behavior, re-pick a library/pattern/architecture, or change a subsystem policy | `recall_decision` FIRST — don't re-litigate a settled call | `memtrace-decision-recall` |
 | "Why is this code here?" "Why is it done this odd way?" | `why_is_this_here(symbol_id)` | `memtrace-provenance` |
-| About to delete/refactor code that looks unused or strange | `why_is_this_here` + `governing_contracts` before touching it | `memtrace-provenance` |
+| About to delete/refactor/clean up existing code, especially odd or "dead" code | `why_is_this_here` + `governing_contracts` before touching it | `memtrace-provenance` |
 | "What rules/contracts constrain this symbol?" | `governing_contracts(symbol_id)` | `memtrace-provenance` |
 | "Did decision D actually hold, or did we drift?" | `verify_intent(decision_id)` | `memtrace-intent-verification` |
 | "What commits/episodes implemented decision D?" | `get_arc(decision_id)` | `memtrace-intent-verification` |
@@ -95,10 +97,11 @@ have a name or a free-text question, start with `recall_decision`.** Do not inve
 ## Standard workflows
 
 ### "Why does this code exist / can I delete it?"
-1. `why_is_this_here(symbol_id)` → the governing decision, if any
-2. `governing_contracts(symbol_id)` → constraints that must survive a rewrite
-3. If a decision governs it → `verify_intent(decision_id)` to see if it still holds
-4. **CannotProve on all three ≠ safe to delete** — confirm with `memtrace-impact` (blast radius) and the user
+1. If you only have a name/free-text target, `recall_decision("<symbol/subsystem>")` first.
+2. If you have a `symbol_id`, `why_is_this_here(symbol_id)` → the governing decision, if any.
+3. `governing_contracts(symbol_id)` → constraints that must survive a rewrite.
+4. If a decision governs it → `verify_intent(decision_id)` to see if it still holds.
+5. **CannotProve on all checks ≠ safe to delete** — confirm with `memtrace-impact` (blast radius) and the user.
 
 ### "Should I do X?" (about to make a choice)
 1. `recall_decision("X")` → did we already decide or ban this?
@@ -114,6 +117,7 @@ have a name or a free-text question, start with `recall_decision`.** Do not inve
 | Thought | Reality |
 |---|---|
 | "This code looks unused, I'll delete it" | `why_is_this_here` first — a decision may govern it; deletion may reopen a closed issue |
+| "I'll just edit/refactor this existing behavior" | `recall_decision("<behavior/subsystem>")` first — the change may violate a recorded decision or ban |
 | "I'll just use library/pattern X" | `recall_decision("X")` — you may be undoing a deliberate ban |
 | "The diff/git log will tell me why" | Git shows *what changed*, not *what was decided or rejected*. Decision memory has the rationale and the bans. |
 | "CannotProve, so it's fine/approved" | CannotProve = unknown, not approved. Don't treat absence of a record as permission. |

package/skills/workflows/memtrace-docs.md

@@ -0,0 +1,129 @@
+---
+name: memtrace-docs
+description: "Route Memtrace product documentation questions to the hosted docs MCP tools before guessing, searching the web, or reading stale local copies. Use when the user asks how Memtrace works, how to install/configure CLI/MCP/fleet/Cortex/enterprise MemDB, what tools or skills exist, what a command does, or wants the agent to read up on official docs. Calls search_docs, ask_docs, or read_doc on memtrace.io (override with MEMTRACE_DOCS_API_URL). Do not hallucinate Memtrace behavior — query docs first. Separate from memtrace-first (your repo's code graph)."
+allowed-tools:
+  - mcp__memtrace__search_docs
+  - mcp__memtrace__ask_docs
+  - mcp__memtrace__read_doc
+metadata:
+  author: "Syncable <support@syncable.dev>"
+  version: "1.0.0"
+  category: development
+---
+
+# Memtrace Docs First
+
+## The Iron Law
+
+```
+IF THE USER ASKS ABOUT MEMTRACE PRODUCT DOCS → USE DOCS MCP TOOLS FIRST.
+Do not guess CLI flags, MCP tool lists, enterprise deploy steps, or fleet rules
+from memory. Query the hosted documentation corpus at memtrace.io (or
+MEMTRACE_DOCS_API_URL), then answer with citations.
+
+memtrace-first  = your indexed SOURCE CODE (find_code, get_impact, …)
+memtrace-docs   = official MEMTRACE DOCUMENTATION (search_docs, ask_docs, read_doc)
+```
+
+Docs tools call the **hosted** Memtrace docs API over HTTPS. They do **not** read
+your local MemDB or your repo. Core graph tools stay offline; docs tools degrade
+gracefully when the network is down (`ok: false` + hint).
+
+## Server check (once per session)
+
+Confirm the docs tools are available on your `memtrace` MCP server:
+
+- `search_docs` — ranked chunks (slug, title, H2, excerpt)
+- `ask_docs` — grounded Q&A `{ answer, citations[], refused }`
+- `read_doc` — full page text by slug
+- Resources: `memtrace://docs/<slug>` via `read_resource` (optional)
+
+If none of these exist, the MCP build may be outdated — tell the user to update
+Memtrace and run `npx -y memtrace-skills@latest install`.
+
+Override API host: `MEMTRACE_DOCS_API_URL` (default `https://memtrace.io`).
+
+## The decision rule
+
+| User is asking | Right tool | Sub-skill |
+|---|---|---|
+| "How do I install / configure / deploy X in Memtrace?" | `ask_docs(question=…)` | `memtrace-docs-ask` |
+| "What MCP tools / skills / CLI commands exist?" | `ask_docs` or `search_docs` then `read_doc` on hit slugs | `memtrace-docs-ask` / `memtrace-docs-search` |
+| "What does `memtrace rail enable` do?" | `ask_docs` | `memtrace-docs-ask` |
+| "Find docs about fleet coordination" | `search_docs(query=…)` | `memtrace-docs-search` |
+| "Read the full getting-started page" | `read_doc(slug="getting-started")` | `memtrace-docs-read` |
+| "Read enterprise MemDB deploy guide" | `read_doc(slug="enterprise/memdb-deploy")` | `memtrace-docs-read` |
+| Need several related sections | `search_docs` → `read_doc` on top slugs | `memtrace-docs-search` + `memtrace-docs-read` |
+
+**Default for natural-language questions:** `ask_docs` — it retrieves context and
+returns a cited answer in one call.
+
+**Default for "find the doc about…":** `search_docs` — scan chunks, then `read_doc`
+if you need the full page.
+
+## Standard workflows
+
+### "How does X work in Memtrace?" (most common)
+
+1. `ask_docs(question="<user question verbatim>")`
+2. If `refused: true` or `ok: false` → `search_docs` with shorter keywords → `read_doc` on best slug
+3. Quote the answer; link slugs as `/docs/<slug>` when helpful
+4. If docs say "not found", say so — do not invent flags or behavior
+
+### "What tools / commands / skills are available?"
+
+1. `ask_docs(question="What MCP tools are available?")` or fleet/skills variant
+2. If the answer lists categories but user wants exhaustive detail → `read_doc(slug="mcp/tools")`
+3. For agent skills → `read_doc(slug="mcp/skills")`
+
+### "Read up on X before we implement"
+
+1. `search_docs(query="X", limit=8)`
+2. `read_doc(slug=<top hit>)` for each page you will rely on
+3. Summarize with citations; use `memtrace-first` only when switching to **their repo's code**
+
+### Enterprise / self-hosted MemDB
+
+1. `ask_docs(question="How do I deploy MemDB with Helm on Azure?")` or user wording
+2. Follow-up `read_doc(slug="enterprise/memdb-deploy")` for operator steps
+3. Engineer connect → `read_doc(slug="enterprise/connect")` or `cli/connect`
+
+## Red flags — STOP, use docs tools
+
+| Thought | Reality |
+|---|---|
+| "I know how Memtrace fleet works from training data" | Product docs change — `ask_docs` first |
+| "I'll grep the repo for README" | User repo ≠ official docs — use `search_docs` / `read_doc` |
+| "I'll web-search Memtrace" | Use hosted docs API — same corpus as memtrace.io/docs |
+| `ask_docs` returned `refused: true` | Docs corpus had no match — say so; try `search_docs` with different terms |
+| `ok: false` network error | Report offline; core Memtrace graph tools still work locally |
+
+## Relationship to other skills
+
+| Skill | When |
+|---|---|
+| `memtrace-docs` | Questions about **Memtrace product** (install, MCP, fleet, Cortex, enterprise) |
+| `memtrace-first` | Questions about **the user's indexed source code** |
+| `memtrace-decision-memory` | **Why** code exists (Cortex decisions) — not product docs |
+
+Use both when needed: docs for "how is Memtrace supposed to work?", graph tools for
+"how does *this repo* implement it?"
+
+## Output
+
+Prefer citing doc slugs returned in `citations` or `search_docs` results:
+
+```
+ask_docs → { ok: true, answer: "…", citations: ["cli/rail", "mcp/skills"], refused: false }
+search_docs → { ok: true, results: [{ slug, pageTitle, h2Title, excerpt }] }
+read_doc → { ok: true, slug, title, body }
+```
+
+When `refused: true`, tell the user the docs did not cover it and suggest browsing
+https://memtrace.io/docs or rephrasing.
+
+## Sub-skills
+
+- Discovery / chunk search → `memtrace-docs-search`
+- Grounded Q&A → `memtrace-docs-ask`
+- Full page read → `memtrace-docs-read`

package/skills/workflows/memtrace-first.md

@@ -1,6 +1,6 @@
 ---
 name: memtrace-first
-description: "Route code discovery, debugging, flow tracing, and how-code-works questions in indexed source-code repos to Memtrace graph tools. Use first — before searching files, reading code for discovery, debugging, tracing flows, finding implementations, understanding behavior, or answering how code works. Do not use Grep, Glob, rg, find, or manual file browsing for code discovery when Memtrace is indexed. Zero results, missing languages, or partial-looking stats are not permission to grep; diagnose/reindex with Memtrace."
+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."
 allowed-tools:
   - mcp__memtrace__list_indexed_repositories
   - mcp__memtrace__index_directory
@@ -23,6 +23,10 @@ allowed-tools:
   - mcp__memtrace__get_style_fingerprint
   - mcp__memtrace__find_most_complex_functions
   - mcp__memtrace__get_source_window
+  - mcp__memtrace__recall_decision
+  - mcp__memtrace__verify_intent
+  - mcp__memtrace__why_is_this_here
+  - mcp__memtrace__governing_contracts
   - Read
   - Grep
   - Glob
@@ -44,6 +48,12 @@ ONLY when you're about to edit or quote, and read only the bounded span
 returned by Memtrace (start_line .. end_line + small context). Do not
 Grep/Glob/Find to "locate" anything already in the graph, and do not read
 the whole file when Memtrace has given you exact lines.
+
+BEFORE you edit/refactor/delete existing code or choose/re-pick a pattern,
+call Cortex decision memory: recall_decision for the symbol/subsystem/approach,
+and use provenance/contracts when a symbol_id is available. Use Memtrace's graph
+tools for structure and blast radius; use Cortex for rationale, bans, and
+contracts.
 ```
 
 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.
@@ -103,6 +113,8 @@ For everything else inside the indexed repo, memtrace is the right tool.
 | "Find the function that uses `STRIPE_KEY_FOO_BAR`" | `find_code(query="STRIPE_KEY_FOO_BAR")` → semantic finds it inside any embedded body. |
 | "Where's that error message `'connection refused for tenant'`?" | `find_code(query="connection refused for tenant")` → semantic catches it. |
 | "What breaks if I change `foo`?" | `get_impact(repo_id, target="foo")` → blast radius. |
+| "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`. |
+| "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. |
 | "What changed in `auth.ts` last week?" | `get_evolution(repo_id, from="7d ago", mode="recent", file_path="auth.ts")`. |
 | "List all `*.test.ts` files." | `Glob` (file inventory, not symbol search). |
 | "Find this string in my `.env`." | `Grep` (non-source artifact). |
@@ -160,6 +172,8 @@ If not indexed → offer to index with `mcp__memtrace__index_directory`, then fo
 | What files change together? | `get_cochange_context` |
 | Architecture overview | `list_communities` + `find_central_symbols` |
 | About to edit / quote — need exact lines | Bounded `Read(file, offset=start_line, limit=N)` (preferred), or `get_source_window` for path-resolution parity |
+| 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` |
+| About to choose or replace a library/pattern/architecture | `recall_decision` first; use `verify_intent` on any matching decision before contradicting it |
 | 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 |
 
 ## Standard Workflows
@@ -185,8 +199,10 @@ If not indexed → offer to index with `mcp__memtrace__index_directory`, then fo
 ### Before any code modification
 1. `find_symbol` → confirm you have the right target
 2. `get_symbol_context` → understand full context
-3. `get_impact` → know blast radius before touching anything
-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
+3. `recall_decision("<symbol/subsystem/approach>")` → surface recorded choices, bans, and conventions before deciding what to do
+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
+5. `get_impact` → know blast radius before touching anything
+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
 
 ## Red Flags — STOP, Use Memtrace Instead
 
@@ -197,6 +213,9 @@ You are violating this skill if you think:
 | "Let me grep for this" | `find_code` or `find_symbol` is faster and structurally aware |
 | "Let me glob for the file" | `find_symbol` returns exact location with context |
 | "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 |
+| "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. |
+| "This looks unused/weird; I'll remove it" | `why_is_this_here` + `governing_contracts` first, then blast radius. CannotProve is unknown, not permission. |
+| "I'll just switch to library/pattern X" | `recall_decision("X")` first — you may be reintroducing a banned approach. |
 | "It's just a quick search" | Grep has no understanding of call graphs, communities, or time |
 | "I don't know if it's indexed" | Check with `list_indexed_repositories` first — takes 1 second |
 | "Memtrace returned 0 results" | Broaden the Memtrace query, check repo_id/path coverage, then reindex if needed |
@@ -210,6 +229,7 @@ Use Grep/Glob/Read ONLY for:
 - Non-source files or paths outside every indexed source repo
 - Files that are config, data, or docs (not source code symbols)
 - Repos or paths confirmed outside every Memtrace indexed root
+- **Official Memtrace product documentation** — use `memtrace-docs` (`ask_docs` / `search_docs` / `read_doc`), not file tools or web search
 
 For source-code spans already located by Memtrace, use a **bounded** read —
 your harness's `Read(file, offset, limit)` with the returned `start_line` /
@@ -227,9 +247,11 @@ When this skill applies, it overrides default file-search behavior. Use the spec
 - Discovery → `memtrace-search`
 - Impact analysis → `memtrace-impact`
 - Temporal / change analysis → `memtrace-evolution`
+- Rationale / prior decisions / bans / contracts → `memtrace-decision-memory`
 - Incident investigation → `memtrace-incident-investigation`
 - Architecture overview → `memtrace-codebase-exploration`
 - Refactoring → `memtrace-refactoring-guide`
+- Memtrace **product docs** (install, CLI, MCP, enterprise) → `memtrace-docs`
 
 ## Output
 

package/skills/workflows/memtrace-refactoring-guide.md

@@ -1,6 +1,6 @@
 ---
 name: memtrace-refactoring-guide
-description: "Build a phased, risk-scored refactoring plan from Memtrace complexity, dead-code, bridge, and impact analysis. Use when the user wants to refactor source code, reduce complexity, clean technical debt, split large functions, extract modules, reorganize code, or choose refactoring priorities. Do not use Grep or manual reference search to plan refactors; Memtrace provides complexity, dead-code, relationships, and impact context."
+description: "Build a phased, risk-scored refactoring plan from Memtrace complexity, dead-code, bridge, impact analysis, and Cortex decision-memory constraints. Use when the user wants to refactor source code, reduce complexity, clean technical debt, delete dead code, split large functions, extract modules, reorganize code, or choose refactoring priorities. Do not plan refactors from grep/manual reference search alone; check graph impact and decision rationale/bans/contracts before changing existing code."
 allowed-tools:
   - mcp__memtrace__find_most_complex_functions
   - mcp__memtrace__find_dead_code
@@ -10,6 +10,10 @@ allowed-tools:
   - mcp__memtrace__get_symbol_context
   - mcp__memtrace__analyze_relationships
   - mcp__memtrace__list_communities
+  - mcp__memtrace__recall_decision
+  - mcp__memtrace__why_is_this_here
+  - mcp__memtrace__governing_contracts
+  - mcp__memtrace__verify_intent
 metadata:
   author: "Syncable <support@syncable.dev>"
   version: "1.0.0"
@@ -19,7 +23,7 @@ user-invocable: true
 
 ## Overview
 
-Guided refactoring workflow — identifies refactoring candidates using structural analysis, scores them by risk and priority, and produces a phased refactoring plan. Combines complexity metrics, dead code detection, bridge analysis, and temporal evolution to prioritize what to refactor first and how to do it safely.
+Guided refactoring workflow — identifies refactoring candidates using structural analysis, scores them by risk and priority, checks Cortex decision memory for rationale/bans/contracts, and produces a phased refactoring plan. Combines complexity metrics, dead code detection, bridge analysis, temporal evolution, and decision memory to prioritize what to refactor first and how to do it safely.
 
 ## Steps
 
@@ -63,7 +67,17 @@ Also call `get_symbol_context` to check:
 - How many processes does this symbol participate in? (More = more testing needed)
 - Is it part of a cross-repo API? (If yes, coordinate with consumers)
 
-### 4. Understand the neighbourhood
+### 4. Check decision memory before refactoring/removing
+
+For each top candidate, call `recall_decision("<symbol/subsystem/refactor intent>")`.
+If you have a numeric `symbol_id`, call `why_is_this_here(symbol_id)` and
+`governing_contracts(symbol_id)`.
+
+- A matching held decision/ban can veto or reshape the refactor.
+- Contracts become acceptance criteria for the new design.
+- CannotProve is unknown, not permission to delete.
+
+### 5. Understand the neighbourhood
 
 For each refactoring target, call `analyze_relationships`:
 - `find_callees` — what does it depend on? These become candidates for extraction
@@ -72,13 +86,13 @@ For each refactoring target, call `analyze_relationships`:
 
 Full parameter spec for every Memtrace tool: `references/mcp-parameters.md` (bundled at the memtrace-skills plugin root).
 
-### 5. Check community boundaries
+### 6. Check community boundaries
 
 Call `list_communities` and check: does the refactoring target sit at a community boundary?
 - If yes, the refactoring may involve splitting responsibilities across modules
 - If it belongs clearly to one community, the refactoring is more contained
 
-### 6. Produce the refactoring plan
+### 7. Produce the refactoring plan
 
 Synthesize into a phased plan:
 
@@ -98,8 +112,9 @@ For each item, include:
 1. **Target** — function/class name, file, current complexity score
 2. **Why** — complexity + volatility + blast radius rationale
 3. **How** — specific refactoring approach (extract method, split class, introduce interface)
-4. **Risk** — impact analysis rating + affected processes
-5. **Test Plan** — which callers/processes to verify
+4. **Decision Memory** — relevant Cortex decisions/bans/contracts, or CannotProve as unknown
+5. **Risk** — impact analysis rating + affected processes
+6. **Test Plan** — which callers/processes to verify
 
 ## Decision Points
 
@@ -107,9 +122,10 @@ For each item, include:
 |-----------|--------|
 | Complex + volatile + high blast radius | Highest priority — but plan carefully; incremental approach |
 | Complex + stable + low blast radius | Can wait; refactor when you're already touching nearby code |
-| Dead code with zero callers | Safe to delete — quick win |
+| Dead code with zero callers | Run Cortex provenance/recall first; zero callers is not proof that no decision/contract keeps it |
 | Bridge symbol with many dependents | Extract interface first, then refactor implementation behind it |
 | Symbol in cross-repo API | Coordinate with consumers; backward-compatible changes only |
+| Cortex returns a held ban/contract | Preserve it or ask before overriding it |
 
 ## Output
 
@@ -123,7 +139,7 @@ A phased plan (Phases 1–3). One worked entry:
 | Risk | High — upstream spans 3 processes incl. `checkout_flow`; incremental migration |
 
 Acceptance criteria:
-- Every plan item cites complexity, volatility, and blast radius — no gut-feel picks.
+- Every plan item cites complexity, volatility, blast radius, and decision-memory status — no gut-feel picks.
 - High/Critical-risk items include a test plan naming affected callers/processes.
 
 ## Common Mistakes