code-auditor-mcp 3.9.1 → 3.9.4

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.1** • Run `code-audit --version` to check your installed version.
+> **Version 3.9.4** • 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 the order to act (`critical` → `warning` → `suggestion`), not a truth score. A suggestion reading is as real as a critical one; it is just lower in the queue.
+- **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.
 
 ## 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 triage order — critical first, then warning, then suggestion — and resolve them all. Severity is triage, 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 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.
 
-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; the `changed` hook blocks on any violation at a blocking severity — `critical` and `warning` by default, configurable via `gateSeverities` in `.codeauditor.json` — from any rule, 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 `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).
 
 ### `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 → warning → suggestion. 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 → 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.
 
 There is **no skip or decline affordance**. A reading leaves the queue only by being fixed, or by editing the rule that produces it in `.codeauditor.json` (your rules editor). If a rule keeps firing on something you judge correct, change the rule — never work around it.
 
@@ -96,7 +96,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 severity gate as every other rule (`critical` and `warning` by default).
+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`).
 
 ### `code-audit index` — refresh the index after structural changes
 
@@ -124,7 +124,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 suggestion 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 high severity. Use these to discover norms an unfamiliar agent would otherwise break:
 
 ```bash
 code-audit conventions list                          # See what conventions were mined
@@ -146,7 +146,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 `suggestion` severity by default. Severity is triage — how a violation blocks the edit gate, not whether it matters. Resolve suggestions the same way you resolve warnings, and promote them with `severityOverrides` if your team wants them to block edits too.
+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.
 
 ### `code-audit hotspots` — identify churn-prone code
 
@@ -188,7 +188,7 @@ 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 is severity-scoped: any violation at a blocking severity (`critical` and `warning` by default, configurable via `gateSeverities` in `.codeauditor.json`) blocks the edit, from any rule. Suggestions are still violations and must be resolved — they report but do not block by default.
+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.
 
 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.
 

package/server.json

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