auditor-lambda 0.1.0 → 0.2.2

package/docs/artifacts.md

@@ -1,69 +1,69 @@
-# Core artifacts
-
-These JSON artifacts are the stable contract between deterministic tooling and LLM audit passes.
-
-## Core files
-
-- `repo_manifest.json`
-- `file_disposition.json`
-- `unit_manifest.json`
-- `graph_bundle.json`
-- `surface_manifest.json`
-- `critical_flows.json`
-- `flow_coverage.json`
-- `risk_register.json`
-- `coverage_matrix.json`
-- `runtime_validation_tasks.json`
-- `runtime_validation_report.json`
-- `external_analyzer_results.json`
-- `audit_results.json`
-- `requeue_tasks.json`
-- `merged_findings.json`
-- `root_cause_clusters.json`
-- `synthesis_report.json`
-
-## Design rule
-
-Tool-specific collectors should write into these normalized formats so that the agent layer can remain portable across runtimes.
-
-## Coverage rule
-
-Coverage is not based only on test instrumentation. It is based on explicit audit accounting:
-
-- file classification
-- file disposition
-- unit assignment
-- required lenses
-- reviewed source ranges
-- completed passes
-- requeue targets for missing review
-- critical-flow coverage state
-
-## Excluded artifact behavior
-
-Files marked as generated, vendor, binary, doc-only, or explicitly excluded should remain visible in manifests and disposition tracking, but should not receive normal audit-unit assignment or requeue tasks.
-
-## Critical flow role
-
-`critical_flows.json` is intended to bridge deterministic planning and higher-order semantic review. It gives LLM agents a bounded way to inspect important end-to-end paths without reading the entire repository at once.
-
-`flow_coverage.json` tracks whether those important paths have received the intended lenses, which allows the planner to treat critical-flow review as a first-class coverage requirement rather than a loose advisory layer.
-
-## Runtime validation role
-
-`runtime_validation_tasks.json` turns unresolved high-risk units and incomplete critical flows into explicit dynamic follow-up work.
-
-`runtime_validation_report.json` is where evidence from those checks should land so that later synthesis can distinguish confirmed, not-confirmed, and inconclusive concerns.
-
-## External analyzer role
-
-`external_analyzer_results.json` is the normalized landing zone for third-party tools such as SAST analyzers, coverage summaries, lint diagnostics, dependency scanners, and similar sources. Downstream prompts should prefer this normalized form over raw tool-native payloads.
-
-External analyzer results now also influence:
-
-- risk scoring
-- required lenses in coverage
-- task priority
-- dedicated analyzer follow-up tasks
-- requeue priority
-- synthesis evidence and summaries
+# Core artifacts
+
+These JSON artifacts are the stable contract between deterministic tooling and LLM audit passes.
+
+## Core files
+
+- `repo_manifest.json`
+- `file_disposition.json`
+- `unit_manifest.json`
+- `graph_bundle.json`
+- `surface_manifest.json`
+- `critical_flows.json`
+- `flow_coverage.json`
+- `risk_register.json`
+- `coverage_matrix.json`
+- `runtime_validation_tasks.json`
+- `runtime_validation_report.json`
+- `external_analyzer_results.json`
+- `audit_results.json`
+- `requeue_tasks.json`
+- `merged_findings.json`
+- `root_cause_clusters.json`
+- `synthesis_report.json`
+
+## Design rule
+
+Tool-specific collectors should write into these normalized formats so that the agent layer can remain portable across runtimes.
+
+## Coverage rule
+
+Coverage is not based only on test instrumentation. It is based on explicit audit accounting:
+
+- file classification
+- file disposition
+- unit assignment
+- required lenses
+- reviewed source ranges
+- completed passes
+- requeue targets for missing review
+- critical-flow coverage state
+
+## Excluded artifact behavior
+
+Files marked as generated, vendor, binary, doc-only, or explicitly excluded should remain visible in manifests and disposition tracking, but should not receive normal audit-unit assignment or requeue tasks.
+
+## Critical flow role
+
+`critical_flows.json` is intended to bridge deterministic planning and higher-order semantic review. It gives LLM agents a bounded way to inspect important end-to-end paths without reading the entire repository at once.
+
+`flow_coverage.json` tracks whether those important paths have received the intended lenses, which allows the planner to treat critical-flow review as a first-class coverage requirement rather than a loose advisory layer.
+
+## Runtime validation role
+
+`runtime_validation_tasks.json` turns unresolved high-risk units and incomplete critical flows into explicit dynamic follow-up work.
+
+`runtime_validation_report.json` is where evidence from those checks should land so that later synthesis can distinguish confirmed, not-confirmed, and inconclusive concerns.
+
+## External analyzer role
+
+`external_analyzer_results.json` is the normalized landing zone for third-party tools such as SAST analyzers, coverage summaries, lint diagnostics, dependency scanners, and similar sources. Downstream prompts should prefer this normalized form over raw tool-native payloads.
+
+External analyzer results now also influence:
+
+- risk scoring
+- required lenses in coverage
+- task priority
+- dedicated analyzer follow-up tasks
+- requeue priority
+- synthesis evidence and summaries

package/docs/bootstrap-install.md

@@ -24,7 +24,7 @@ Installed always-on compatibility surfaces:
 
 Installed repo-local canonical assets:
 
-- `.audit-code/install/audit-code.prompt.md`
+- `.audit-code/install/audit-code.import.md`
 - `.audit-code/install/SKILL.md`
 - `.audit-code/install/GETTING-STARTED.md`
 

package/docs/model-selection.md

@@ -1,86 +1,86 @@
-# model selection
-
-This repository has two distinct model-selection layers.
-
-## 1. Skill-first product rule
-
-The canonical product surface is `/audit-code` in conversation.
-
-For that surface, the default model rule is:
-
-- use the active conversation model by default
-- avoid forcing the user to supply a model in normal usage
-
-That is the intended product contract.
-
-## 2. Backend provider rule
-
-When the local backend delegates bounded worker runs into an external provider, model selection becomes provider-specific.
-
-That means the supervisor should not invent a global model abstraction unless it can be implemented consistently across adapters.
-
-Today the practical rule is:
-
-- no provider-specific model override by default
-- let each provider use its own default model unless explicitly configured otherwise
-- when a model is required, pass it through the provider's own native CLI arguments via `extra_args`
-
-## Current provider behavior
-
-### `local-subprocess`
-
-No external LLM provider is selected here.
-
-The supervisor simply launches the bounded local worker command.
-
-### `claude-code`
-
-The built-in Claude Code adapter supports model overrides through `claude_code.extra_args`.
-
-Example:
-
-```json
-{
-  "provider": "claude-code",
-  "ui_mode": "visible",
-  "claude_code": {
-    "command": "claude",
-    "extra_args": ["--model", "sonnet"]
-  }
-}
-```
-
-Use this only when you want to force a specific Claude Code model instead of relying on the user's normal Claude Code default.
-
-### `opencode`
-
-The built-in OpenCode adapter supports model overrides through `opencode.extra_args`.
-
-Example:
-
-```json
-{
-  "provider": "opencode",
-  "ui_mode": "visible",
-  "opencode": {
-    "command": "opencode",
-    "extra_args": ["--model", "anthropic/claude-sonnet-4.5"]
-  }
-}
-```
-
-Use this only when you want to force a specific OpenCode provider/model pair instead of relying on the user's normal OpenCode default.
-
-### `subprocess-template` and `vscode-task`
-
-These adapters do not define model semantics themselves.
-
-If you need model selection here, include it in the external launcher command template or in the external tool being invoked.
-
-## Recommendation
-
-For the cleanest product behavior:
-
-1. in conversation, let `/audit-code` inherit the active conversation model
-2. for repo-local backend usage, do not force model selection unless the operator has a concrete reason
-3. when needed, set model selection in the provider-native config rather than inventing another repo-level abstraction
+# model selection
+
+This repository has two distinct model-selection layers.
+
+## 1. Skill-first product rule
+
+The canonical product surface is `/audit-code` in conversation.
+
+For that surface, the default model rule is:
+
+- use the active conversation model by default
+- avoid forcing the user to supply a model in normal usage
+
+That is the intended product contract.
+
+## 2. Backend provider rule
+
+When the local backend delegates bounded worker runs into an external provider, model selection becomes provider-specific.
+
+That means the supervisor should not invent a global model abstraction unless it can be implemented consistently across adapters.
+
+Today the practical rule is:
+
+- no provider-specific model override by default
+- let each provider use its own default model unless explicitly configured otherwise
+- when a model is required, pass it through the provider's own native CLI arguments via `extra_args`
+
+## Current provider behavior
+
+### `local-subprocess`
+
+No external LLM provider is selected here.
+
+The supervisor simply launches the bounded local worker command.
+
+### `claude-code`
+
+The built-in Claude Code adapter supports model overrides through `claude_code.extra_args`.
+
+Example:
+
+```json
+{
+  "provider": "claude-code",
+  "ui_mode": "visible",
+  "claude_code": {
+    "command": "claude",
+    "extra_args": ["--model", "sonnet"]
+  }
+}
+```
+
+Use this only when you want to force a specific Claude Code model instead of relying on the user's normal Claude Code default.
+
+### `opencode`
+
+The built-in OpenCode adapter supports model overrides through `opencode.extra_args`.
+
+Example:
+
+```json
+{
+  "provider": "opencode",
+  "ui_mode": "visible",
+  "opencode": {
+    "command": "opencode",
+    "extra_args": ["--model", "anthropic/claude-sonnet-4.5"]
+  }
+}
+```
+
+Use this only when you want to force a specific OpenCode provider/model pair instead of relying on the user's normal OpenCode default.
+
+### `subprocess-template` and `vscode-task`
+
+These adapters do not define model semantics themselves.
+
+If you need model selection here, include it in the external launcher command template or in the external tool being invoked.
+
+## Recommendation
+
+For the cleanest product behavior:
+
+1. in conversation, let `/audit-code` inherit the active conversation model
+2. for repo-local backend usage, do not force model selection unless the operator has a concrete reason
+3. when needed, set model selection in the provider-native config rather than inventing another repo-level abstraction

package/docs/next-steps.md

@@ -2,7 +2,7 @@
 
 This document tracks the next meaningful implementation work after the current skill-first productionization pass.
 
-As of April 17, 2026, this repository is not yet ready for a public production launch.
+As of April 18, 2026, this repository is not yet ready for a public production launch.
 
 See:
 
@@ -20,6 +20,7 @@ The repository now supports:
 - `audit-code validate` as a machine-readable backend operator check
 - an explicit in-repo release gate via `npm run verify:release`
 - structured operator handoff output plus `.audit-artifacts/operator-handoff.{json,md}` for blocked fallback runs
+- configured provider bridges that can continue audit-task review by writing structured results and handing control back to the bounded worker command
 
 That means the current release is suitable for a controlled alpha or beta skill-first workflow, but it is not yet the final public production end-state.
 
@@ -52,15 +53,15 @@ Near-term work should focus on:
 - removing host-specific manual prompt wiring where practical
 - keeping the active conversation model and attached repo context as the default operating mode
 
-### 3. Improve continuation through assisted review
+### 3. Polish continuation through assisted review
 
-The repo-local backend fallback still intentionally stops once only manual or provider-assisted review remains.
+The repo-local backend fallback still intentionally stops in blocked state under `local-subprocess`, but configured provider bridges can now continue the audit-task review phase automatically.
 
 Near-term work should focus on:
 
-- smoother continuation when an interactive provider is configured
 - clearer evidence handoff for imported results and runtime updates
-- less operator guesswork when the backend reaches a blocked terminal handoff
+- less operator guesswork when a configured provider fails to return usable results
+- stronger host-specific guidance for provider-assisted bridges
 
 ### 4. Harden publish and release operations
 
@@ -92,7 +93,7 @@ The repository should not be described as frictionless and production-ready unti
 
 ### Assisted review continuation
 
-- when an interactive provider is configured, blocked audits continue with less manual result import
+- configured interactive providers can continue blocked audits through audit-task review in the same wrapper invocation
 - operator handoff artifacts remain explicit and inspectable even when continuation is smoother
 
 ### Release operations
@@ -120,17 +121,18 @@ Follow-on shape:
 - document the exact install and verification path for hosts that still need extra handling
 - only claim native support for a host once its install surface is equally concrete and testable
 
-### 2. Continue blocked reviews through a configured interactive provider
+### 2. Harden configured interactive-provider continuation
 
 Most likely shape:
 
 - use the existing provider configuration surface in `.audit-artifacts/session-config.json`
-- make the blocked handoff less manual when `claude-code`, `opencode`, or another bridge is intentionally configured
+- keep the provider-assisted review handoff less manual when `claude-code`, `opencode`, or another bridge is intentionally configured
 - preserve explicit artifact imports and operator visibility instead of hiding state transitions
+- improve diagnostics and recovery when the provider fails to emit structured results
 
 Practical success bar:
 
-- a blocked audit can continue through the configured provider with fewer manual result-import and handoff steps
+- a configured provider can continue through audit-task review with good diagnostics and low operator guesswork when something goes wrong
 
 ### 3. Prove the release path outside the repository
 

package/docs/packaging.md

@@ -25,12 +25,12 @@ A packaged-install smoke test proves the same assets still work when consumed fr
 ## Packaged smoke command
 
 From the repository root:
-
+
 ```bash
 npm install
 npm run verify:release
 ```
-
+
 That script:
 
 - creates a tarball with `npm pack`
@@ -55,7 +55,7 @@ The release publish gate also runs both installed-entrypoint smoke paths before
 ```text
 .github/workflows/publish-package.yml
 ```
-
+
 ## Publish pipeline state
 
 The repository now includes packaging metadata and lifecycle hooks intended for registry publication: