carto-md 2.1.0 → 2.1.1

package/docs/api/history.md

@@ -0,0 +1,78 @@
+# `history`
+
+Temporal/architectural history: domain drift (default), domain evolution, hotspots, arch events, a file's timeline, change velocity, complexity trend, churn-vs-blast, domain health. Requires `carto temporal init`.
+
+## Input schema
+
+```json
+{
+  "type": "object",
+  "properties": {
+    "view": {
+      "type": "string",
+      "enum": [
+        "drift",
+        "evolution",
+        "hotspots",
+        "events",
+        "file",
+        "velocity",
+        "complexity",
+        "churn",
+        "health"
+      ],
+      "description": "Which historical view to return (default drift)."
+    },
+    "domain": {
+      "type": "string",
+      "description": "Domain filter (drift/evolution/health)."
+    },
+    "file": {
+      "type": "string",
+      "description": "File (file/complexity views)."
+    },
+    "time_range": {
+      "type": "string",
+      "description": "Window like \"30d\", \"90d\"."
+    },
+    "limit": {
+      "type": "number",
+      "description": "Row cap (hotspots)."
+    },
+    "severity": {
+      "type": "string",
+      "description": "Event severity (events)."
+    },
+    "kind": {
+      "type": "string",
+      "description": "Event kind (events)."
+    },
+    "days": {
+      "type": "number",
+      "description": "Lookback days (velocity)."
+    }
+  },
+  "required": []
+}
+```
+
+## Required arguments
+
+_None._
+
+## Properties
+
+| Name | Type | Description |
+|------|------|-------------|
+| `view` | string | Which historical view to return (default drift). |
+| `domain` | string | Domain filter (drift/evolution/health). |
+| `file` | string | File (file/complexity views). |
+| `time_range` | string | Window like "30d", "90d". |
+| `limit` | number | Row cap (hotspots). |
+| `severity` | string | Event severity (events). |
+| `kind` | string | Event kind (events). |
+| `days` | number | Lookback days (velocity). |
+
+## See also
+
+- [Index of all MCP tools](./README.md)

package/docs/api/impact.md

@@ -0,0 +1,56 @@
+# `impact`
+
+Impact of changing code: blast radius (default), multi-file simulate, import neighbors, or data flow. Signature capability — "what breaks if I touch this?"
+
+## Input schema
+
+```json
+{
+  "type": "object",
+  "properties": {
+    "file": {
+      "type": "string",
+      "description": "Relative file path (modes: blast, neighbors, data_flow)."
+    },
+    "files": {
+      "type": "array",
+      "items": {
+        "type": "string"
+      },
+      "description": "File paths for mode=\"simulate\" (change a set at once)."
+    },
+    "mode": {
+      "type": "string",
+      "enum": [
+        "blast",
+        "simulate",
+        "neighbors",
+        "data_flow"
+      ],
+      "description": "blast=transitive dependents (default); simulate=union for a file set; neighbors=import graph neighbors; data_flow=upstream/downstream + routes/models/env."
+    },
+    "hops": {
+      "type": "number",
+      "description": "Neighbor hops (mode=\"neighbors\", default 1, max 3)."
+    }
+  },
+  "required": []
+}
+```
+
+## Required arguments
+
+_None._
+
+## Properties
+
+| Name | Type | Description |
+|------|------|-------------|
+| `file` | string | Relative file path (modes: blast, neighbors, data_flow). |
+| `files` | array | File paths for mode="simulate" (change a set at once). |
+| `mode` | string | blast=transitive dependents (default); simulate=union for a file set; neighbors=import graph neighbors; data_flow=upstream/downstream + routes/models/env. |
+| `hops` | number | Neighbor hops (mode="neighbors", default 1, max 3). |
+
+## See also
+
+- [Index of all MCP tools](./README.md)

package/docs/api/memory.md

@@ -0,0 +1,70 @@
+# `memory`
+
+Episodic memory: search past decisions (default), decision log, recent decisions, session recap, pending work, or a file's intervention history. Ask "did we already decide this?"
+
+## Input schema
+
+```json
+{
+  "type": "object",
+  "properties": {
+    "kind": {
+      "type": "string",
+      "enum": [
+        "search",
+        "log",
+        "recent",
+        "session",
+        "pending",
+        "interventions"
+      ],
+      "description": "search=substring over the log (default); log=recent decision log; recent=validation decisions; session=full session recap; pending=unfinished/HIGH-risk work; interventions=warnings on a file."
+    },
+    "query": {
+      "type": "string",
+      "description": "Search topic (kind=\"search\")."
+    },
+    "file": {
+      "type": "string",
+      "description": "File filter (kind=\"interventions\")."
+    },
+    "hours": {
+      "type": "number",
+      "description": "Lookback hours (kind=\"log\"/\"pending\")."
+    },
+    "time_range": {
+      "type": "string",
+      "description": "Window like \"7d\" (kind=\"recent\")."
+    },
+    "filter": {
+      "type": "string",
+      "description": "Decision-kind filter (kind=\"recent\")."
+    },
+    "session_id": {
+      "type": "number",
+      "description": "Session id (kind=\"session\")."
+    }
+  },
+  "required": []
+}
+```
+
+## Required arguments
+
+_None._
+
+## Properties
+
+| Name | Type | Description |
+|------|------|-------------|
+| `kind` | string | search=substring over the log (default); log=recent decision log; recent=validation decisions; session=full session recap; pending=unfinished/HIGH-risk work; interventions=warnings on a file. |
+| `query` | string | Search topic (kind="search"). |
+| `file` | string | File filter (kind="interventions"). |
+| `hours` | number | Lookback hours (kind="log"/"pending"). |
+| `time_range` | string | Window like "7d" (kind="recent"). |
+| `filter` | string | Decision-kind filter (kind="recent"). |
+| `session_id` | number | Session id (kind="session"). |
+
+## See also
+
+- [Index of all MCP tools](./README.md)

package/docs/api/org.md

@@ -0,0 +1,51 @@
+# `org`
+
+Cross-repo / multi-repo view: org architecture (default), service dependency graph, cross-repo blast radius, API consumers, per-repo domains, boundary violations, or migration cut points. Requires `carto org init`.
+
+## Input schema
+
+```json
+{
+  "type": "object",
+  "properties": {
+    "view": {
+      "type": "string",
+      "enum": [
+        "architecture",
+        "graph",
+        "blast",
+        "consumers",
+        "domains",
+        "violations",
+        "migration"
+      ],
+      "description": "Which org-wide view to return (default architecture)."
+    },
+    "repo": {
+      "type": "string",
+      "description": "Producer repo (view=\"blast\")."
+    },
+    "target": {
+      "type": "string",
+      "description": "Package/module (view=\"consumers\")."
+    }
+  },
+  "required": []
+}
+```
+
+## Required arguments
+
+_None._
+
+## Properties
+
+| Name | Type | Description |
+|------|------|-------------|
+| `view` | string | Which org-wide view to return (default architecture). |
+| `repo` | string | Producer repo (view="blast"). |
+| `target` | string | Package/module (view="consumers"). |
+
+## See also
+
+- [Index of all MCP tools](./README.md)

package/docs/api/patterns.md

@@ -0,0 +1,63 @@
+# `patterns`
+
+Semantic + procedural patterns mined from the repo: architectural invariants (default), naming/export/dir conventions, canonical exemplar, or "when X changes, Y changes" action patterns.
+
+## Input schema
+
+```json
+{
+  "type": "object",
+  "properties": {
+    "kind": {
+      "type": "string",
+      "enum": [
+        "invariants",
+        "conventions",
+        "canonical",
+        "actions"
+      ],
+      "description": "invariants=mined rules (default); conventions=naming/export/dir; canonical=best exemplar; actions=git co-change patterns."
+    },
+    "domain": {
+      "type": "string",
+      "description": "Domain filter (invariants/canonical)."
+    },
+    "threshold": {
+      "type": "number",
+      "description": "Confidence threshold (invariants)."
+    },
+    "file": {
+      "type": "string",
+      "description": "File or directory (conventions)."
+    },
+    "pattern_type": {
+      "type": "string",
+      "description": "route_handler | model_definition (canonical)."
+    },
+    "intent": {
+      "type": "string",
+      "description": "Intent filter (actions)."
+    }
+  },
+  "required": []
+}
+```
+
+## Required arguments
+
+_None._
+
+## Properties
+
+| Name | Type | Description |
+|------|------|-------------|
+| `kind` | string | invariants=mined rules (default); conventions=naming/export/dir; canonical=best exemplar; actions=git co-change patterns. |
+| `domain` | string | Domain filter (invariants/canonical). |
+| `threshold` | number | Confidence threshold (invariants). |
+| `file` | string | File or directory (conventions). |
+| `pattern_type` | string | route_handler \| model_definition (canonical). |
+| `intent` | string | Intent filter (actions). |
+
+## See also
+
+- [Index of all MCP tools](./README.md)

package/docs/api/set_intent.md

@@ -0,0 +1,45 @@
+# `set_intent`
+
+Capture a user-stated intent about this project — product type, stack, or a scope note ("single-user for now"). Product-type gates every rule in the rule engine, so calling this correctly is how the AI unlocks (or narrows) gap detection. Notes accumulate — this tool never overwrites prior notes, only appends.
+
+## Input schema
+
+```json
+{
+  "type": "object",
+  "properties": {
+    "product_type": {
+      "type": "string",
+      "description": "The product classification, e.g. \"saas-with-auth\" or \"unsupported\"."
+    },
+    "stack": {
+      "type": "array",
+      "items": {
+        "type": "string"
+      },
+      "description": "Optional explicit stack list, e.g. [\"Next.js\", \"Supabase\"]. Replaces the auto-detected stack."
+    },
+    "note": {
+      "type": "string",
+      "description": "A single scope statement from the user. Timestamped and appended to the notes array."
+    }
+  },
+  "required": []
+}
+```
+
+## Required arguments
+
+_None._
+
+## Properties
+
+| Name | Type | Description |
+|------|------|-------------|
+| `product_type` | string | The product classification, e.g. "saas-with-auth" or "unsupported". |
+| `stack` | array | Optional explicit stack list, e.g. ["Next.js", "Supabase"]. Replaces the auto-detected stack. |
+| `note` | string | A single scope statement from the user. Timestamped and appended to the notes array. |
+
+## See also
+
+- [Index of all MCP tools](./README.md)

package/docs/api/simulate_change_impact.md

@@ -1,5 +1,7 @@
 # `simulate_change_impact`
 
+> ⚠️ **Deprecated (CF-7).** Use `impact(files, mode="simulate")` instead. This name still resolves and returns byte-identical output for a deprecation window, but is no longer listed by default and emits a one-line notice.
+
 Given a list of files, returns all files transitively affected by changing them simultaneously, with hop distance. Powered by the bitmap engine — only feasible at this speed (sub-millisecond) with bitmap OR-aggregation. Use when planning a refactor that touches multiple files.
 
 ## Input schema

package/docs/concepts/domains.md

@@ -1,91 +1,116 @@
 # Concept: Domains
 
-> Auto-detected clusters of tightly-coupled files. Carto's "AUTH", "PAYMENTS", "DATABASE" — without you writing a config.
+> Named groupings of related files — Carto's "AUTH", "PAYMENTS", "DATABASE". Declared in config when you want them exact, inferred from the code when you don't.
 
 ## The intuition
 
-Files that import each other heavily belong together. Files that don't, don't. Cluster the import graph and you get a set of communities — those communities are the codebase's *domains*.
+A *domain* is a slice of the codebase that hangs together: the auth code, the billing code, the database layer. Carto assigns every file to exactly one domain and everything downstream — `get_cross_domain`, `get_data_flow`, the impact report, `validate_diff`'s cross-boundary signal — reads off that single assignment.
 
-Carto runs **Leiden+CPM** (Constant Potts Model) on the import graph. It's the same family of community-detection algorithms used in social-network analysis. The output: each file gets a domain id; the bitmap engine indexes by it; everything downstream (cross-domain checks, the impact report, the validation API) reads off this.
+There are two ways a file gets its domain, in strict priority order:
 
-## Why not just regex on paths?
+1. **Declared** — you told Carto in `carto.config.json`. Deterministic, always wins.
+2. **Inferred** — Carto guessed from path keywords and the import graph. The fallback for anything you didn't declare.
 
-Path-based detection works for greenfield projects with a clean `src/auth/`, `src/payments/` layout. It collapses on:
+## Source of truth (why the numbers always agree)
 
-- Monorepos where every package has its own `auth/` subdir
-- Legacy projects where the directory structure doesn't match the actual coupling (auth code mysteriously lives in `lib/middleware/`)
-- Frameworks that hide the structure (Next.js routes spread across `pages/`, `app/`, `api/`)
+Domain assignments live in the `domain_assignments` table. The `files.domain_id` column is a **denormalized mirror** of that table, written in the same call (`assignFileToDomain`) and cleared in the same call (`clearDomainAssignments`) — the two can never drift. Every tool resolves a file's domain through one accessor, `store.getDomainOf(fileIdOrPath)`, so `get_data_flow` and `get_cross_domain` can never report different domains for the same file. (Before v2.1 they could: `data_flow` read the never-populated `files.domain_id` and showed blank while `cross_domain` read `domain_assignments` and showed a domain — that split is now closed.)
 
-Graph clustering is path-agnostic. It looks at who imports whom and produces named communities whose names are derived from the path tokens *most common in that cluster*. That's the magic — the cluster is found by structure, the *name* is found by frequency on the actual file paths in it.
+## 1. Declared domains (primary)
 
-## Naming heuristics
+Two override shapes, both under `domains` in `carto.config.json`.
 
-After clustering, Carto picks a name for each cluster:
-
-1. Tokenize each file path: `src/auth/login.ts` → `[src, auth, login]`
-2. Drop stopwords (`src`, `lib`, `app`, `index`, `utils`, `helpers`)
-3. Cross-reference with a small built-in dictionary of well-known domain hints: `AUTH`, `PAYMENTS`, `DATABASE`, `NOTIFICATIONS`, `EVENTS`, `TRPC`, `CORE`
-4. Most-frequent matching token wins. Ties broken by dictionary priority (security-relevant domains first).
-5. If no token matches the dictionary, the most-common path token becomes the domain name (uppercased).
-
-The result: real repos light up with sensible labels — vscode gets `EXTENSIONS`, `EVENTS`, `DATABASE`, `CLI`, `CORE`; zed (Rust) gets `DATABASE`, `AUTH`, `EVENTS`, `CORE`. A game engine would get `RENDERER`, `PHYSICS`, `AUDIO` automatically because those tokens dominate the path namespace.
-
-## Adaptive gamma
-
-The Leiden+CPM algorithm has a resolution parameter γ (gamma). High γ → many small clusters. Low γ → few big clusters. Carto picks γ based on repo size:
-
-- **<100 files:** keyword-only fallback (graph clustering over-fragments tiny repos)
-- **100–1,000 files:** γ = 0.04
-- **1,000–10,000 files:** γ scales linearly to 0.02
-- **>10,000 files:** γ = 0.015 (large repos have dense graphs; tighter resolution prevents one giant component)
-
-These constants come from validation on 12 real repos. See `src/store/sync.js` for the exact formula.
-
-## Custom domains via `carto.config.json`
-
-Override the auto-detection if your repo needs it. Two shapes:
-
-**Simple — keyword hints:**
+**Globs → domain (recommended for monorepos).** Any file whose path matches a domain's globs is assigned that domain regardless of what inference would have guessed. First matching domain in declaration order wins.
 
 ```json
 {
   "domains": {
-    "EDITOR": ["editor", "monaco", "text"],
-    "WORKBENCH": ["workbench", "layout", "panel"]
+    "EDITOR":    { "globs": ["src/editor/**", "packages/*/editor/**"] },
+    "WORKBENCH": { "globs": ["src/workbench/**"] }
   }
 }
 ```
 
-Files whose path tokens match the hints get pulled into the named domain even if the graph clusterer would have put them elsewhere.
+Supported glob syntax: `**` (any number of path segments), `*` (any run of characters except `/`), `?` (a single non-`/` character). Everything else matches literally, paths are compared with `/` separators, and the match is anchored (full-path).
 
-**Full — keywords + anchors:**
+**Keywords + anchors (finer control).**
 
 ```json
 {
   "domains": {
     "AUTH": {
       "keywords": ["auth", "login", "session"],
-      "anchor": ["src/auth/session.ts", "src/auth/middleware.ts"]
+      "anchor":   ["src/auth/session.ts", "src/auth/middleware.ts"]
     }
   }
 }
 ```
 
-Anchor files are *pinned*. They always end up in their named domain regardless of clustering. Useful when you've got a deliberately central auth file that the graph clusterer would otherwise lump into CORE.
+- `keywords` feed the inference seed list (below) — hints, not hard rules.
+- `anchor` files are *pinned*: they always land in the named domain. Anchors are the most specific override and win even over globs.
+
+Precedence: **anchors > globs > inference.** Declared assignments are recorded with confidence `1.0`.
+
+## 2. Inference (the fallback)
+
+For everything not covered by config, Carto picks a strategy based on repo size and import-graph density (`selectClusteringStrategy` in `src/store/sync.js`):
+
+| Condition | Strategy |
+|---|---|
+| `< 100` files | keyword + vote |
+| import density `< 1.5` edges/file (sparse graphs, most monorepos) | keyword + vote |
+| otherwise (dense, larger repos) | Leiden+CPM graph clustering |
+
+> The docs used to claim Leiden ran on *every* repo. It doesn't — sparse and small repos (which includes big monorepos like supabase, whose graph is sparse) use the keyword-and-vote path. Leiden is reserved for dense graphs where community detection actually beats keywords.
+
+### 2a. Keyword + vote (small / sparse repos)
+
+Implemented in `buildFileAssignments` (`src/agents/domains.js`):
+
+1. **Seed by keyword** — a file is seeded into a domain when a built-in keyword matches a **path segment** of its path (`/auth/`, `/auth.`, `-auth.`, `_auth.`, `/auth-`, `/auth_`), never an arbitrary substring. Confidence `0.9`.
+   The seed list is deliberately narrow: `auth/login/logout/oauth/jwt/session/password/credential` (AUTH), `payment/billing/stripe/invoice/subscription/checkout` (PAYMENTS), `trpc/procedure` (TRPC), `prisma/drizzle/migration/sqlalchemy` (DATABASE), `webhook/queue/worker/cron` (EVENTS), `notification/mailer/sms` (NOTIFICATIONS). Over-broad tokens that caused false positives — `token`, `db`, `model`, `schema`, `event`, `job`, `task`, `router` — were removed.
+2. **Expand by a conservative import vote** — up to 2 hops, an unseeded file adopts a neighbor domain only when that domain has **≥ 2 votes from seed-strength neighbors**, is a **strict plurality**, and is **≥ 50 % of all domain votes** among its neighbors. Otherwise it stays unassigned. Confidence `0.5`. This is what stops a single AUTH-labelled neighbor from painting an entire import chain AUTH (the old "theme → AUTH", "byte-util → AUTH" bug).
+3. **Everything left → `CORE`**, confidence `0.2`. A low-confidence file is honestly `CORE`, never a wrong specific domain.
+
+### 2b. Leiden+CPM (dense repos)
+
+`clusterByGraph` (`src/agents/leiden.js`) runs Leiden community detection with the Constant Potts Model quality function over the undirected import graph. Communities are then **named** — by keyword-seed match first, then by the most common distinctive path segment (stopwords like `src`, `lib`, `app`, `utils` dropped). Communities smaller than `minSize` are merged into `CORE`.
+
+**Adaptive resolution (γ).** Higher γ → more, smaller communities.
+
+```
+γ       = min(0.10, 0.02 + 0.02 · log10(fileCount / 10))
+minSize = clamp(round(sqrt(fileCount)), 5, 20)
+```
+
+See `selectClusteringStrategy` in `src/store/sync.js` for the exact formula.
+
+## Confidence
+
+Every assignment carries a confidence in `domain_assignments.confidence`:
+
+| Source | Confidence |
+|---|---|
+| Declared glob / anchor | `1.0` |
+| Keyword seed (path-segment match) | `0.9` |
+| Import vote | `0.5` |
+| `CORE` fallback | `0.2` |
+
+Low confidence is a feature: Carto would rather label a file `CORE` than guess a specific domain it isn't sure about.
 
 ## Stability across syncs
 
-Re-clustering after a code change can shuffle domain assignments. Carto tracks the previous mapping and warns when >5% of files change domain between syncs (`carto check` surfaces it as "unstable clustering"). Anchor files give you a way to force stability where it matters.
+Re-clustering after a code change can shuffle assignments. Carto stores the previous mapping and warns via `carto check` when > 5 % of files change domain between syncs. Declared globs and anchors give you deterministic stability where it matters.
 
 ## Where domains show up
 
-- **`AGENTS.md`** lists them with file counts
-- **`.carto/context/<DOMAIN>.md`** has per-domain context the AI reads when working in that area
-- **`get_domain(name)`** MCP tool returns the full list of files, routes, models in a domain
-- **`validate_diff`** uses cross-domain edges as a violation signal — adding `auth/login.ts → payments/billing.ts` is HIGH-risk because it crosses a sensitive boundary
+- **`AGENTS.md`** lists them with file counts.
+- **`.carto/context/<DOMAIN>.md`** holds per-domain context the AI reads when working in that area.
+- **`get_domain(name)`** returns the files, routes, and models in a domain.
+- **`get_cross_domain`** lists every import edge whose endpoints are in different domains.
+- **`validate_diff`** treats new cross-domain edges as a risk signal.
 
 ## Related
 
-- [`get_cross_domain`](./mcp-integration.md#get_cross_domain) — every import edge that crosses a domain
-- [`carto check`](../../README.md#cli-commands) — flags new cross-domain violations
-- [Leiden algorithm paper](https://www.nature.com/articles/s41598-019-41695-z) — the algorithm Carto uses
+- [`get_cross_domain`](./mcp-integration.md#get_cross_domain) — every import edge that crosses a domain boundary
+- [`carto check`](../../README.md#cli) — flags new cross-domain violations and clustering instability
+- [Leiden algorithm paper](https://www.nature.com/articles/s41598-019-41695-z) — the community-detection algorithm used for dense repos

package/docs/concepts/mcp-integration.md

@@ -24,9 +24,11 @@ For each AI tool it detects on your machine, init writes the appropriate MCP con
 
 Each config tells the tool: *"when the user starts a chat, run `carto serve` as a child process and route MCP traffic to it"*.
 
-## The ~76 tools Carto exposes
+## The tools Carto exposes
 
-Grouped by what they answer. Categories below match the [`docs/api/`](../api/) layout — that directory is the full per-tool reference (auto-generated from `src/mcp/server.js`). The picks below are the high-impact ones; your AI tool picks whichever one fits the question mid-task.
+Carto exposes a small **default core (~10 tools)** plus a handful of **parameterized families** (`impact`, `memory`, `history`, `patterns`, `org`), so your AI tool spends its context budget on your codebase instead of a long tool menu. The full capability set stays reachable: the ~30 former sibling tools (`get_blast_radius`, `simulate_change_impact`, `did_we_discuss_this`, ...) resolve as **deprecated shims** with byte-identical output, and advanced/experimental tools are available by widening the surface (`CARTO_MCP_TIER=advanced`, or `carto.config.json` -> `mcp.tier`).
+
+The groups below map every capability by what it answers. Categories match the [`docs/api/`](../api/) layout, which is the full per-tool reference (auto-generated from `src/mcp/server.js`). Your AI tool picks whichever fits the question mid-task; you don't choose by hand.
 
 ### Core graph (16) — project shape, blast radius, change planning
 

package/docs/guides/pre-merge-review.md

@@ -31,7 +31,7 @@ jobs:
     steps:
       - uses: actions/checkout@v4
         with: { fetch-depth: 0 }       # full history — pr-impact needs the base ref
-      - uses: theanshsonkar/carto@v2.0.9
+      - uses: theanshsonkar/carto@v2.1.0
 ```
 
 That's the entire config. The action handles npm install, cache restore, sync, pr-impact, and the comment.
@@ -96,7 +96,7 @@ Look at the four signals in order:
 For repos that want a harder gate, set `fail-on` in the workflow:
 
 ```yaml
-- uses: theanshsonkar/carto@v2.0.9
+- uses: theanshsonkar/carto@v2.1.0
   with:
     fail-on: HIGH
 ```

package/docs/migration/v1-to-v2.md

@@ -97,9 +97,9 @@ If you're upgrading in CI, pin a known-good Carto version:
 
 ```yaml
 # .github/workflows/carto.yml
-- uses: theanshsonkar/carto@v2.0.9
+- uses: theanshsonkar/carto@v2.1.0
   with:
-    carto-version: '2.0.9'    # pin instead of `latest`
+    carto-version: '2.1.0'    # pin instead of `latest`
 ```
 
 This way the action's output (and the PR-comment shape) stays stable across CI runs even when newer Carto versions ship.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "carto-md",
-  "version": "2.1.0",
+  "version": "2.1.1",
   "description": "Structural intelligence + episodic memory for AI coding tools. Indexes your codebase into SQLite — routes, models, import graph, blast radius, domains — and exposes ~75 MCP tools (validate_diff, get_change_plan, did_we_discuss_this, get_predictive_risk, …) for Cursor, Claude Code, Codex, Kiro, and any other MCP client.",
   "bin": {
     "carto": "src/cli/index.js"
@@ -11,6 +11,7 @@
     "test:correctness": "node test/correctness.js",
     "test:benchmark": "node test/benchmark.js",
     "test:bench-ci": "node test/bench-ci.js",
+    "test:audit-supabase": "node test/audit-supabase.js",
     "postinstall": "node scripts/postinstall.js",
     "bench:bitmap": "node bench/bitmap-validation/index.js",
     "bench:scale": "node bench/scale-test/index.js"