audit-tools 0.28.10 → 0.29.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "audit-tools",
-  "version": "0.28.10",
+  "version": "0.29.1",
   "private": false,
   "description": "Portable hybrid code auditing + remediation orchestrators for arbitrary repositories.",
   "type": "module",

package/skills/audit-code/SKILL.md

@@ -98,7 +98,7 @@ The prompt payload in `audit-code.prompt.md` remains the canonical instruction a
 The intended user setup is one global package install:
 
 ```bash
-npm install -g auditor-lambda
+npm install -g audit-tools
 ```
 
 That makes `audit-code` available on `PATH` and seeds user-level command/skill
@@ -132,12 +132,11 @@ audit-code
 
 from the target repository root.
 
-When developing `auditor-lambda` itself, prefer the local wrapper at
-`packages/audit-code/audit-code.mjs` (there is no `audit-code.mjs` at the
-monorepo root):
+When developing `audit-tools` itself, prefer the local wrapper at
+`audit-code.mjs` (at the repo root):
 
 ```bash
-node packages/audit-code/audit-code.mjs   # from the monorepo root
+node audit-code.mjs   # from the repo root
 ```
 
 That keeps the run pinned to the local wrapper and local `dist/` output instead

package/skills/audit-code/audit-code.prompt.md

@@ -17,12 +17,11 @@ First, make sure the repository has current local audit assets:
 audit-code ensure --quiet
 ```
 
-When developing `auditor-lambda` itself, the entrypoint lives at
-`packages/audit-code/audit-code.mjs` (there is no `audit-code.mjs` at the
-monorepo root). From the monorepo root use:
+When developing `audit-tools` itself, the entrypoint lives at
+`audit-code.mjs` (at the repo root). From the repo root use:
 
 ```bash
-node packages/audit-code/audit-code.mjs ensure --quiet
+node audit-code.mjs ensure --quiet
 ```
 
 Then ask the backend for exactly one next step. This is also the **capability
@@ -64,10 +63,10 @@ lower it under rate-limit pressure. The backend's learned quota adapts from
 there. The token values should match the window of the model(s) dispatching the
 packets (e.g. 200000 / 32000 for a 200k-context model).
 
-When developing `auditor-lambda` itself, from the monorepo root use:
+When developing `audit-tools` itself, from the repo root use:
 
 ```bash
-node packages/audit-code/audit-code.mjs next-step --host-max-active-subagents 4 --host-context-tokens 200000 --host-output-tokens 32000
+node audit-code.mjs next-step --host-max-active-subagents 4 --host-context-tokens 200000 --host-output-tokens 32000
 ```
 
 Read the returned JSON only far enough to find `prompt_path`, then read and

package/skills/remediate-code/SKILL.md

@@ -51,7 +51,7 @@ instruction asset.
 The intended user setup is one global package install:
 
 ```bash
-npm install -g remediator-lambda
+npm install -g audit-tools
 ```
 
 That makes `remediate-code` available on `PATH` and seeds user-level
@@ -76,7 +76,7 @@ bootstrap.
 
 ## Repo-local fallback
 
-When developing inside the `remediator-lambda` repository itself, prefer:
+When developing inside the `audit-tools` repository itself, prefer:
 
 ```bash
 node remediate-code.mjs

package/docs/audit-pkg/history.md

@@ -1,66 +0,0 @@
-# History
-
-This page keeps short archival context that used to live in several
-phase-specific documents. It is not the current roadmap or release gate.
-
-## Field-trial lessons
-
-Earlier real-repository runs surfaced issues around:
-
-- completion detection
-- worker launch failures
-- result ingestion validation
-- command hangs without progress
-- requeue task explosion
-- evidence schema ambiguity
-- noisy runtime placeholders
-- weak root-cause clustering
-- missing work-block presentation
-- unenforceable reviewed ranges
-
-Most of those findings have dedicated regression coverage now. The durable
-lesson is that failure states should be explicit, schema validation should be
-field-level, and packetization should optimize for coherent review context
-rather than raw worker-count reduction alone.
-
-## Remediation baseline
-
-The old remediation baseline recorded fixes across:
-
-- CI and release smoke coverage
-- extractor path handling
-- schema-contract validation
-- orchestration state handling
-- provider and supervisor behavior
-- CLI and IO robustness
-- reporting and synthesis behavior
-- generated install payload parity
-
-Current readiness is tracked in `docs/product.md`, `docs/operator-guide.md`,
-`docs/contracts.md`, `docs/release.md`, and `docs/development.md`.
-
-## Monorepo migration & drift reconciliation (2026-05 → 2026-06)
-
-The auditor and remediator began as standalone repos (`auditor-lambda`,
-`remediator-lambda`) and were merged into this npm-workspaces monorepo on a
-shared `@audit-tools/shared` foundation. `providers/` and `quota/` had been
-copy-pasted into both tools and forked in place; the ten resulting drift bugs
-were all fixed by centralizing the forked logic into `shared` (one source of
-truth). Durable decisions from that work:
-
-- **Access scoping is JSON, not MCP.** `AccessDeclaration` rides on the step
-  contract, so it works with any host; the MCP servers stay compatibility
-  adapters over the same contract.
-- **`--dangerously-skip-permissions` defaults ON for the remediator, OFF for the
-  auditor.** The remediator applies changes unattended and cannot pause; the
-  auditor is read-only. The asymmetry is intentional and the flag is overrideable.
-- **The remediator's machine input is `audit-findings.json`, not the Markdown
-  report.** `audit-report.md` is human-facing; a Markdown file handed to the
-  remediator flows through the free-form LLM extractor, not a deterministic parse.
-- **Prompts use one strict path** — no "or / unless / if-available" fallbacks.
-
-Large files were then broken up as behaviour-preserving pure moves (`cli.ts` from
-4072 lines to a thin dispatcher plus `src/cli/*` handlers; `graph.ts`,
-`reviewPackets.ts`, `internalExecutors.ts`, and the generated language table all
-split out). The sprint-by-sprint handoff docs that tracked this work were removed
-once shipped; this section is their durable residue.