code-auditor-mcp 3.9.11 → 4.0.0

package/plugin/scripts/hook-common.sh

@@ -7,42 +7,126 @@
 #
 # Two rules enforced here are the fix for "the hook died quietly" (three times:
 # unset CLAUDE_PLUGIN_ROOT, a stale global binary, a removed CLI flag):
-#   1. prefer the plugin's bundled CLI when it is shipped (npm installs) so a
-#      stale global/project binary can never drive the hook, and
+#   1. prefer a bundled CLI when it is shipped (npm installs) AND its version
+#      matches the manifest — nothing is trusted on presence alone, and
 #   2. a non-zero CLI exit that is NOT a finding (2) is a broken hook and must
 #      fail loudly, never degrade to a silent no-op.
 #
 # The plugin cache does NOT ship a bundled CLI (dist/ is gitignored, so a
 # marketplace install from `./plugin` has no `../dist/`), which means the
-# fallback paths (project-local, global/PATH, npx) are the common case. For those,
-# `assert_compatible` pins the resolved binary's REAL version against the plugin
-# manifest and fails loudly on mismatch — see below. This pin is what stopped the
-# third quiet failure: a 3.9.6 global silently driving a 3.9.9 plugin.
+# fallback paths (project-local, global/PATH, pinned install) are the common case —
+# but a checkout where a developer *did* build dist/ locally ships a `../dist/cli.js`
+# that is a local, possibly stale build, not the npm-paired dist/. The two files
+# differ in more than freshness: npm's bin-links chmod the packaged `dist/cli.js`
+# to `-rwxr-xr-x` at install, while local `tsc` output stays `-rw-r--r--`, so a
+# marketplace checkout's sibling can be both stale AND non-executable — a file the
+# old presence-only check would have trusted and then failed to run. Resolution is
+# version-aware: EVERY candidate — the bundled sibling included — is used only
+# when its `--version` matches the manifest, otherwise it is warned about and
+# skipped, so a mismatched binary falls through to the pinned install instead
+# of hard-failing. `assert_compatible` remains the final loud backstop on whatever
+# resolve_code_audit returns. Together they stop the third quiet failure: a stale
+# binary silently driving a newer plugin.
 #
 # The sourcing hook runs with `set -euo pipefail`.
 
 # resolve_code_audit — emit the CLI invocation to use.
 #
-# 1. The plugin's bundled CLI (dist/cli.js ships in the same npm package, so it
-#    is always the exact version this plugin was built against) — present only
-#    when installed from npm, not from the marketplace.
-# 2. Project-local install (consumer project's own node_modules).
-# 3. Global install / PATH.
-# 4. npx auto-install (only if nothing else resolves).
+# Resolution is version-aware: EVERY candidate — bundled sibling, project-local,
+# global — is used only when its `--version` matches this plugin's manifest
+# version. A stale candidate is warned about and skipped, so a mismatched binary
+# no longer turns the hook into a hard failure; the pinned install below resolves
+# the correct CLI on its own (and warn_stale tells the user to update so the fast
+# path comes back).
+#
+# 1. The plugin's bundled CLI (`${CLAUDE_PLUGIN_ROOT}/../dist/cli.js` ships in the
+#    same npm package, so it usually matches) — but a marketplace checkout has no
+#    npm-paired dist/, and a locally built one can be stale, so it is
+#    version-checked like everything else.
+# 2. Project-local install (consumer project's own node_modules) — if compatible.
+# 3. Global install / PATH — if compatible.
+# 4. Pinned install, exact manifest version — never a range — the guaranteed-
+#    correct fallback when nothing compatible is installed. The package is
+#    installed to a deterministic dir and its bin invoked by absolute path; npx is
+#    deliberately NOT used for execution (see resolve_pinned_bin).
 resolve_code_audit() {
+  local candidate
   if [ -n "${CLAUDE_PLUGIN_ROOT:-}" ] && [ -f "${CLAUDE_PLUGIN_ROOT}/../dist/cli.js" ]; then
-    echo "${CLAUDE_PLUGIN_ROOT}/../dist/cli.js"
-    return
+    candidate="${CLAUDE_PLUGIN_ROOT}/../dist/cli.js"
+    if cli_is_compatible "${candidate}"; then
+      echo "${candidate}"
+      return
+    fi
+    warn_stale "${candidate}"
   fi
   if [ -n "${CLAUDE_PROJECT_DIR:-}" ] && [ -x "${CLAUDE_PROJECT_DIR}/node_modules/.bin/code-audit" ]; then
-    echo "${CLAUDE_PROJECT_DIR}/node_modules/.bin/code-audit"
-    return
+    candidate="${CLAUDE_PROJECT_DIR}/node_modules/.bin/code-audit"
+    if cli_is_compatible "${candidate}"; then
+      echo "${candidate}"
+      return
+    fi
+    warn_stale "${candidate}"
   fi
   if command -v code-audit &>/dev/null; then
-    echo "code-audit"
-    return
+    candidate="code-audit"
+    if cli_is_compatible "${candidate}"; then
+      echo "${candidate}"
+      return
+    fi
+    warn_stale "${candidate}"
+  fi
+  # Pin to the plugin's exact version, not a range: `@^3.0.0` could resolve a
+  # cached older CLI and silently drive this plugin with the wrong analyzer code.
+  local pv bin
+  pv="$(plugin_version)"
+  if [ -n "${pv}" ]; then
+    if bin="$(resolve_pinned_bin)"; then
+      echo "${bin}"
+    else
+      # Install failed (offline, registry error, npm missing). Emit the npx form
+      # as a last-ditch command so the hook still has something to run;
+      # assert_compatible rejects it loudly if it cannot be verified — the same
+      # treatment as the unreadable-manifest case below.
+      echo "npx -y -p code-auditor-mcp@${pv} code-audit"
+    fi
+  else
+    # Manifest unreadable — assert_compatible will reject whatever this fetches,
+    # so `@latest` is only a last-ditch command that never survives the pin.
+    echo "npx -y -p code-auditor-mcp@latest code-audit"
   fi
-  echo "npx -y -p code-auditor-mcp@^3.0.0 code-audit"
+}
+
+# pin_dir — the deterministic directory the pinned CLI is installed into. The
+# version is part of the path so a plugin update installs a fresh copy instead of
+# reusing (and possibly mis-matching) the previous version's install.
+pin_dir() {
+  printf '%s' "${XDG_CACHE_HOME:-$HOME/.cache}/code-auditor/cli/$(plugin_version)"
+}
+
+# resolve_pinned_bin — ensure the pinned package is installed to pin_dir and echo
+# the absolute path to its bin. Silent: prints only the path on success, nothing
+# on failure (return 1).
+#
+# Installing (not `npx -p <pkg>@<ver> <bin>`) is the whole point. npx's `-p` puts
+# the package's bin on PATH and runs the *name*, so a same-named binary earlier in
+# PATH — a global shim, or a volta shim — shadows the pin, and the "fallback"
+# silently routes back to the stale global it was meant to replace. Installing to
+# a known dir and invoking `node_modules/.bin/code-audit` by absolute path removes
+# PATH from the equation entirely.
+resolve_pinned_bin() {
+  local pv dir bin
+  pv="$(plugin_version)"
+  [ -n "$pv" ] || return 1
+  dir="$(pin_dir)"
+  bin="${dir}/node_modules/.bin/code-audit"
+  if [ ! -x "$bin" ]; then
+    mkdir -p "$dir" || return 1
+    # --ignore-scripts is safe here (the CLI uses node:sqlite, not better-sqlite3,
+    # and ships prebuilt binaries) and avoids any install-script work.
+    npm install --prefer-offline --prefix "$dir" "code-auditor-mcp@${pv}" \
+      --no-audit --no-fund --ignore-scripts --silent >/dev/null 2>&1 || return 1
+  fi
+  echo "$bin"
 }
 
 # plugin_version — the version this plugin declares in its manifest, or ''.
@@ -60,21 +144,40 @@ semver_of() {
   printf '%s' "$1" | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+(-[0-9A-Za-z.-]+)?' | head -n 1 || true
 }
 
+# cli_is_compatible <cmd> — silent; 0 when `<cmd> --version` reports this plugin's
+# exact version, non-zero otherwise (mismatch or undetermined). Resolution uses
+# this to decide fall-through; assert_compatible remains the loud backstop.
+cli_is_compatible() {
+  local cmd="$1" pv cv pv_sem cv_sem
+  pv="$(plugin_version)"
+  cv="$($cmd --version 2>/dev/null || true)"
+  pv_sem="$(semver_of "${pv}")"
+  cv_sem="$(semver_of "${cv}")"
+  [ -n "${pv_sem}" ] && [ -n "${cv_sem}" ] && [ "${pv_sem}" = "${cv_sem}" ]
+}
+
+# warn_stale <cmd> — one stderr line naming a stale installed CLI, so the user
+# knows why the hook is paying the pinned install and how to restore the fast path.
+warn_stale() {
+  local cmd="$1" cv pv
+  pv="$(semver_of "$(plugin_version)")"
+  cv="$(semver_of "$($cmd --version 2>/dev/null || true)")"
+  echo "[code-auditor] warn: ${cmd} is ${cv:-unidentified} but this plugin needs ${pv:-its version} — using the pinned install instead; update the install to restore the fast path" >&2
+}
+
 # assert_compatible <bin> — pin the plugin to a compatible CLI.
 #
-# The bundled CLI always matches (same package), so it needs no check. Any
-# fallback path can drift — a stale global, a project-local pin, or a wider npx
-# range — and a 3.4.0 plugin silently driving a 3.5.0 CLI is exactly the
-# failure this guards.
+# Every candidate can drift — the bundled sibling in a marketplace checkout, a
+# stale global, a project-local pin, or a stale pinned install — and a 3.4.0
+# plugin silently driving a 3.5.0 CLI is exactly the failure this guards. No
+# candidate is trusted on presence alone: `resolve_code_audit` version-checks up
+# front, and this is the loud backstop that re-checks whatever actually resolves.
 #
 # The comparison is semver-vs-semver (the CLI's real `--version`, not its full
 # banner), and it fails loudly on a mismatch OR when either version cannot be
 # determined — an unidentified binary is never trusted.
 assert_compatible() {
   local bin="$1" pv cv pv_sem cv_sem
-  case "${bin}" in
-    "${CLAUDE_PLUGIN_ROOT}/../dist/cli.js") return 0 ;;   # pinned by construction
-  esac
   pv="$(plugin_version)"
   cv="$($bin --version 2>/dev/null || true)"
   pv_sem="$(semver_of "${pv}")"

package/plugin/scripts/hook-warm.sh

@@ -0,0 +1,44 @@
+#!/usr/bin/env bash
+# code-auditor SessionStart hook — warm the pinned CLI install before the first edit.
+#
+# A marketplace install has no lifecycle step, so the pinned fallback's cold fetch
+# (~5.7s download of the package's native binaries) would otherwise land on the
+# first Write/Edit after install — the kind of apparent hang people disable hooks
+# over. This hook installs the pinned CLI at session start, before any edit.
+#
+# Deliberately non-blocking and silent:
+#   - the install is backgrounded (nohup + &) and this script returns immediately,
+#     so it never delays session start;
+#   - every failure (offline, npm missing, unreadable manifest) is a quiet no-op —
+#     a warm-the-cache nicety must never complain or fail the session.
+# `--prefer-offline` makes a warm npm cache a pure cache hit (no registry metadata
+# re-check on every launch) while still fetching on a cold cache. When the CLI is
+# already installed at its deterministic dir, the script exits without touching npm
+# at all — a warm session must not re-check on every launch.
+set -uo pipefail
+
+# Belt-and-suspenders: the hooks.json command already guards an unset
+# CLAUDE_PLUGIN_ROOT, but keep the warm a no-op if it is somehow absent here.
+[ -n "${CLAUDE_PLUGIN_ROOT:-}" ] || exit 0
+
+# Shared version lookup (plugin_version / semver_of / pin_dir).
+. "${CLAUDE_PLUGIN_ROOT}/scripts/hook-common.sh"
+
+# Nothing safe to warm if the manifest version can't be read: warming @latest
+# could pin a different version than resolve_code_audit's fallback would fetch.
+pv="$(plugin_version)"
+[ -n "${pv}" ] || exit 0
+
+dir="$(pin_dir)"
+bin="${dir}/node_modules/.bin/code-audit"
+
+# Already installed — nothing to warm. Re-running npm install here would re-check
+# the registry on every session, which is exactly the cost this hook exists to avoid.
+[ -x "${bin}" ] && exit 0
+
+# Background the exact install the hook's last-resort path runs. Output to
+# /dev/null (silent), stdin from /dev/null (don't hold the hook's stdin open),
+# nohup so the install survives this hook's exit.
+nohup npm install --prefer-offline --prefix "${dir}" "code-auditor-mcp@${pv}" \
+  --no-audit --no-fund --ignore-scripts --silent >/dev/null 2>&1 </dev/null &
+exit 0

package/plugin/skills/code-auditor/SKILL-RULE-KINDS.md

@@ -103,7 +103,7 @@ Exported symbols in files matching the `path` glob must match the `exports` rege
 {
   "id": "constants-upper",
   "kind": "naming",
-  "severity": "high",
+  "severity": "advisory",
   "path": "src/**/constants.ts",
   "exports": "^[A-Z][A-Z0-9_]*$",
   "message": "Exported constants should use UPPER_SNAKE_CASE."
@@ -176,35 +176,42 @@ Require designated CSS properties to reference a design token instead of a raw v
 
 ## Severity Levels
 
-Severity is urgency, not permission. There are three levels — all defects,
-none optional — and the axis is *how fast a finding bites you*:
+Severity is urgency, not permission. There are three levels, and the axis is
+*how fast a reading bites you*:
 
 | Severity | What it means |
 |----------|---------------|
-| `critical` | Exploitable or broken now |
-| `severe` | Wrong, and it will surface |
-| `high` | Wrong, and it has not bitten yet |
-
-Every severity blocks. The edit hook gates on any finding from any rule —
-there is no non-blocking tier and no per-rule opt-in. A `high` finding blocks
-the edit exactly like a `critical` one; urgency only sets the order you fix
-things, never whether they gate.
-
-> **Severity ranks urgency, never whether a finding is real.** There is no
-> "noise" tier — every finding is a defect to resolve, and every finding blocks
-> the edit until it is fixed, or the rule that produces it is edited in
-> `.codeauditor.json`. There is no "waive" — a finding leaves the queue only by
-> being resolved or by changing the rule that fires it. The `next-file` queue
-> orders work worst-first; that ordering is triage, not permission — a finding
-> that surfaces later in the queue still gates. Documentation findings are not
-> stylistic: missing JSDoc is a maintainability defect, not a nicety.
+| `critical` | Already wrong in production, or will fail when this code runs |
+| `severe` | A real defect that has not bitten yet |
+| `advisory` | Correct, but it does not match a convention |
+
+`critical` and `severe` are defects; `advisory` is a convention reading — the
+code works, but it deviates from a documented norm (docs, style, naming).
+Every severity blocks by default. The edit hook gates on any finding from any
+rule — there is no non-blocking tier and no per-rule opt-in. An `advisory`
+finding blocks the edit exactly like a `critical` one; urgency only sets the
+order you fix things, never whether they gate.
+
+> **Severity ranks urgency, never whether a finding is real.** `advisory` is
+> not a "noise" tier — a convention reading still blocks the edit until it is
+> resolved or the rule that produces it is edited in `.codeauditor.json`. There
+> is no "waive" — a finding leaves the queue only by being resolved or by
+> changing the rule that fires it. The `next-file` queue orders work worst-first;
+> that ordering is triage, not permission — a finding that surfaces later in the
+> queue still gates. Documentation findings ship at `advisory`: missing JSDoc is
+> a maintainability convention, not a runtime defect — but it still blocks.
+
+A fourth channel, **diagnostic**, sits outside the severity ladder. It is not a
+severity tier: it carries tool-failure and coverage notices (`engine-error`,
+`config-error`, `undefined-class-disabled`) that are surfaced regardless of
+`--fail-on` and never counted as findings.
 
 ## Validation
 
 Rules are validated against `invariant-rules.schema.json` on startup. Common errors:
 
 - **Missing required field**: each kind has required fields (e.g., `import-ban` requires `module`)
-- **Invalid severity**: must be one of `critical`, `severe`, `high`
+- **Invalid severity**: must be one of `critical`, `severe`, `advisory`
 - **Invalid kind**: must be one of the seven kinds above
 - **Both allowFrom and denyFrom**: `call-constraint` requires exactly one
 - **Empty pattern**: `ast-pattern` requires a non-empty `pattern` string

package/plugin/skills/code-auditor/SKILL.md

@@ -5,7 +5,7 @@ description: Audit code quality, search the codebase semantically, enforce invar
 
 # Code Auditor Skill
 
-> **Version 3.9.11** • Run `code-audit --version` to check your installed version.
+> **Version 4.0.0** • Run `code-audit --version` to check your installed version.
 > If versions differ, the CLI is authoritative — use `code-audit <command> --help` to see what your install actually supports.
 
 You have the `code-audit` CLI available. It indexes every function, component, and struct in the codebase for semantic search and invariant enforcement. Use these commands instead of raw grep/find whenever possible.
@@ -16,7 +16,7 @@ You have the `code-audit` CLI available. It indexes every function, component, a
 
 - **Reading** — the human-facing name for one rule observation. The machine contract calls the same thing a **violation** (a "finding" in the JSON). The audit *takes* readings; it does not issue verdicts.
 - **Coverage panel** — the report leads with what was measured (which rules fired, which were clean, which were not applicable), so a zero-reading run is not mistaken for a clean tree.
-- **Triage** — severity is urgency, not permission. Three levels, all defects, none optional: **critical** (exploitable or broken now), **severe** (wrong, and it will surface), **high** (wrong, and it has not bitten yet). The axis is how fast a reading bites you, not whether it matters — every reading blocks the edit gate. Queue order (`critical` → `severe` → `high`) is the order to act, not a license to skip.
+- **Triage** — severity is urgency, not permission. Three levels, and the axis is how fast a reading bites you: **critical** (already wrong in production, or will fail when this code runs), **severe** (a real defect that has not bitten yet), **advisory** (correct, but it does not match a convention). `critical` and `severe` are defects; `advisory` is a convention reading. Every reading blocks the edit gate by default. Queue order (`critical` → `severe` → `advisory`) is the order to act, not a license to skip.
 
 ## When to use which command
 
@@ -51,9 +51,9 @@ code-audit changed --json                            # Diff-scoped audit (hook c
 
 Use `code-audit changed` after edits to confirm you haven't introduced violations. If the hook is active it already runs `code-audit changed` automatically on Write/Edit — pay attention to its output.
 
-**Every reading is a measurement, not a verdict.** The audit is a diagnostic instrument: it reports what it measured (the coverage panel) and takes one reading per rule violation. Work readings in urgency order — critical first, then severe, then high — and resolve them all. Severity is urgency, the order to act, never a judgment on whether a reading is real; there is no "noise" tier. Documentation readings (missing JSDoc) are maintainability gaps, not stylistic niceties. If you choose not to resolve one, record why before moving on — never silently dismiss it.
+**Every reading is a measurement, not a verdict.** The audit is a diagnostic instrument: it reports what it measured (the coverage panel) and takes one reading per rule violation. Work readings in urgency order — critical first, then severe, then advisory — and resolve them all. Severity is urgency, the order to act, never a judgment on whether a reading is real; there is no "noise" tier — an advisory reading still blocks. Documentation readings (missing JSDoc) ship at advisory: maintainability conventions, not stylistic niceties, and still gating. If you choose not to resolve one, record why before moving on — never silently dismiss it.
 
-Expected output: JSON violation list (with `--json`) or colored terminal summary. The full `audit` command exits non-zero when violations at or above `--fail-on` severity exist. Every severity blocks: `critical`, `severe`, and `high` are all gating. The `changed` hook blocks on any violation from any rule — there is no non-blocking tier — and enforcement is not diff-scoped (a pre-existing violation in the audited file blocks exactly like a new one).
+Expected output: JSON violation list (with `--json`) or colored terminal summary. The full `audit` command exits non-zero when violations at or above `--fail-on` severity exist. Every severity blocks: `critical`, `severe`, and `advisory` are all gating. The `changed` hook blocks on any violation from any rule — there is no non-blocking tier — and enforcement is not diff-scoped (a pre-existing violation in the audited file blocks exactly like a new one).
 
 ### `code-audit next-file` — fix violations one file at a time
 
@@ -62,7 +62,7 @@ code-audit next-file --path .        # Highest-priority file + all its readings
 code-audit next-file --path . --json # Machine-readable
 ```
 
-This is the refactoring loop. `next-file` audits the project and returns the single highest-priority file — ranked by highest-severity reading, then total reading count — with every reading on it, ordered critical → severe → high. Fix that file, then run it again: a still-broken file comes back, otherwise the next-worst file surfaces. `{done:true}` means the tree is clean.
+This is the refactoring loop. `next-file` audits the project and returns the single highest-priority file — ranked by highest-severity reading, then total reading count — with every reading on it, ordered critical → severe → advisory. Fix that file, then run it again: a still-broken file comes back, otherwise the next-worst file surfaces. `{done:true}` means the tree is clean.
 
 There is **no skip or decline affordance** in `next-file`. A reading leaves the queue only by being fixed, by editing the rule that produces it in `.codeauditor.json` (your rules editor), or — if it is a genuine false positive — by dismissing that one instance with a written reason (`code-audit dismiss`, below). If a rule keeps firing on something you judge correct, change the rule — never work around it.
 
@@ -117,7 +117,7 @@ Path profiles are an ordered array — files matching multiple profiles merge ov
 
 A **built-in** `scripts-and-tests` profile ships with every install — it excludes `scripts/**`, `tests/**`, `__tests__/**`, `fixtures/**`, and `*.test.*`/`*.spec.*` files from the gate. Disable it with `"builtin": false` in `.codeauditor.json`.
 
-Invariant violations are **immune** to path profile gate exclusion — invariants enforce declared laws and block on the same gate as every other rule (all of `critical`, `severe`, and `high`).
+Invariant violations are **immune** to path profile gate exclusion — invariants enforce declared laws and block on the same gate as every other rule (all of `critical`, `severe`, and `advisory`).
 
 ### `code-audit index` — refresh the index after structural changes
 
@@ -145,7 +145,7 @@ Creates a `.codeauditor.json` configuration file with invariant rules for your p
 
 ### `code-audit conventions` — mine and propose rules
 
-Code Auditor learns your codebase's unwritten conventions from the function index and flags deviations at high severity. Use these to discover norms an unfamiliar agent would otherwise break:
+Code Auditor learns your codebase's unwritten conventions from the function index and flags deviations at advisory severity. Use these to discover norms an unfamiliar agent would otherwise break:
 
 ```bash
 code-audit conventions list                          # See what conventions were mined
@@ -167,7 +167,7 @@ code-audit conventions propose --json                # JSON proposal array
 
 **Usage:** Run a full audit or `code-audit index sync` to mine conventions from the codebase index. Then `code-audit conventions list` to see what was found, and `code-audit conventions propose` to get the rules. Paste the proposals into the `rules` array in `.codeauditor.json`.
 
-Convention readings ship at `high` severity by default. Severity is urgency — how fast a violation bites, not whether it matters. Every severity blocks the edit gate, so a `high` convention reading is a real defect to resolve, not a hint to ignore.
+Convention readings ship at `advisory` severity by default. Severity is urgency — how fast a reading bites, not whether it matters. `advisory` is a convention reading, not a defect, but it still blocks the edit gate by default — resolve it or edit the rule, never ignore it.
 
 ### `code-audit hotspots` — identify churn-prone code
 
@@ -209,9 +209,9 @@ When an edit hook blocks your edit with a violation message:
 1. **Read the violation** — it includes the invariant rule's `message` field explaining *why* the edit was blocked
 2. **Fix the violation** — change your approach to comply with the invariant
 3. **Do NOT retry the same edit** — the hook will block it again
-4. The hook runs `code-audit changed`, and its gate blocks on every violation from any rule — `critical`, `severe`, and `high` all block; there is no non-blocking severity tier. A `high` reading blocks the edit exactly like a `critical` one; urgency only sets the order you fix things, never whether they gate.
+4. The hook runs `code-audit changed`, and its gate blocks on every violation from any rule — `critical`, `severe`, and `advisory` all block; there is no non-blocking severity tier. An `advisory` reading blocks the edit exactly like a `critical` one; urgency only sets the order you fix things, never whether they gate.
 
-The hook auto-installs the package via npx on first use — no manual npm step needed. If the hook reports `[code-auditor] code-audit could not run`, the npx auto-install failed (network, unsupported platform). The agent should try again; if it persists, `npm install code-auditor-mcp` is the manual fix.
+The hook auto-installs the package to a cache dir on first use — no manual npm step needed. If the hook reports `[code-auditor] code-audit could not run`, the auto-install failed (network, unsupported platform). The agent should try again; if it persists, `npm install code-auditor-mcp` is the manual fix.
 
 ## Host-specific notes
 

package/server.json

@@ -6,13 +6,13 @@
     "url": "https://github.com/BenAHammond/code-auditor-mcp",
     "source": "github"
   },
-  "version": "3.9.11",
+  "version": "4.0.0",
   "packages": [
     {
       "registryType": "npm",
       "registryBaseUrl": "https://registry.npmjs.org",
       "identifier": "code-auditor-mcp",
-      "version": "3.9.11",
+      "version": "4.0.0",
       "transport": {
         "type": "stdio"
       }