auditor-lambda 0.1.0 → 0.2.1

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:

package/docs/pipeline.md

@@ -1,152 +1,152 @@
-# Audit pipeline
-
-## Phase 0: intake
-
-Automated:
-
-- enumerate files
-- detect languages and frameworks
-- identify exclusions
-- hash files
-- collect git metadata
-
-Outputs:
-
-- `repo_manifest.json`
-- `file_inventory.json`
-- `stack_profile.json`
-
-## Phase 1: structural extraction
-
-Automated:
-
-- detect services, packages, apps
-- detect routes, jobs, commands, workflows
-- bucket files
-- extract graphs
-- detect data-layer artifacts
-
-Outputs:
-
-- `unit_manifest.json`
-- `surface_manifest.json`
-- `bucket_assignments.json`
-- `graph_bundle.json`
-
-LLM role:
-
-- resolve ambiguous units and suspicious classifications
-
-## Phase 2: mechanical analysis
-
-Automated:
-
-- lint
-- typecheck
-- tests
-- coverage
-- secrets
-- dependencies
-- static security
-- complexity and duplication
-
-Outputs:
-
-- `mechanical_results.json`
-- `hotspot_report.json`
-
-LLM role:
-
-- distinguish signal from noise
-- identify what deserves deeper review
-
-## Phase 3: risk scoring
-
-Automated inputs:
-
-- exposure
-- privilege indicators
-- persistent writes
-- secrets access
-- concurrency signals
-- churn
-- coverage weakness
-
-Outputs:
-
-- `risk_register.json`
-
-LLM role:
-
-- adjust for semantic criticality
-
-## Phase 4: blind-spot mapping
-
-LLM task:
-
-- use manifests, graphs, and bounded source excerpts to identify what tools are likely missing
-
-Outputs:
-
-- `blind_spot_register.json`
-- `runtime_validation_targets.json`
-
-## Phase 5: unit audits
-
-LLM task:
-
-- audit each unit under required lenses
-
-Outputs:
-
-- `audit_results/<unit>/<lens>.json`
-
-## Phase 6: cross-cutting audits
-
-LLM task:
-
-- audit repo-wide concerns such as auth, retries, migrations, config validation, observability, and secrets flow
-
-Outputs:
-
-- `cross_cutting/<theme>.json`
-
-## Phase 7: dynamic validation
-
-Automated + LLM:
-
-- run targeted checks for suspicious cases
-- interpret repro results
-
-Outputs:
-
-- `runtime_validation_report.json`
-
-## Phase 8: coverage verification
-
-Automated:
-
-- verify every file is classified
-- verify every file is audited or explicitly excluded
-- verify reviewed line ranges cover the intended source
-- verify multi-pass overlap for critical units
-
-Outputs:
-
-- `coverage_matrix.json`
-- `line_coverage_map.json`
-- `uncovered_items.json`
-
-## Phase 9: synthesis
-
-LLM task:
-
-- deduplicate findings
-- cluster by root cause
-- prioritize remediation
-
-Outputs:
-
-- `findings.json`
-- `root_cause_clusters.json`
-- `remediation_plan.md`
+# Audit pipeline
+
+## Phase 0: intake
+
+Automated:
+
+- enumerate files
+- detect languages and frameworks
+- identify exclusions
+- hash files
+- collect git metadata
+
+Outputs:
+
+- `repo_manifest.json`
+- `file_inventory.json`
+- `stack_profile.json`
+
+## Phase 1: structural extraction
+
+Automated:
+
+- detect services, packages, apps
+- detect routes, jobs, commands, workflows
+- bucket files
+- extract graphs
+- detect data-layer artifacts
+
+Outputs:
+
+- `unit_manifest.json`
+- `surface_manifest.json`
+- `bucket_assignments.json`
+- `graph_bundle.json`
+
+LLM role:
+
+- resolve ambiguous units and suspicious classifications
+
+## Phase 2: mechanical analysis
+
+Automated:
+
+- lint
+- typecheck
+- tests
+- coverage
+- secrets
+- dependencies
+- static security
+- complexity and duplication
+
+Outputs:
+
+- `mechanical_results.json`
+- `hotspot_report.json`
+
+LLM role:
+
+- distinguish signal from noise
+- identify what deserves deeper review
+
+## Phase 3: risk scoring
+
+Automated inputs:
+
+- exposure
+- privilege indicators
+- persistent writes
+- secrets access
+- concurrency signals
+- churn
+- coverage weakness
+
+Outputs:
+
+- `risk_register.json`
+
+LLM role:
+
+- adjust for semantic criticality
+
+## Phase 4: blind-spot mapping
+
+LLM task:
+
+- use manifests, graphs, and bounded source excerpts to identify what tools are likely missing
+
+Outputs:
+
+- `blind_spot_register.json`
+- `runtime_validation_targets.json`
+
+## Phase 5: unit audits
+
+LLM task:
+
+- audit each unit under required lenses
+
+Outputs:
+
+- `audit_results/<unit>/<lens>.json`
+
+## Phase 6: cross-cutting audits
+
+LLM task:
+
+- audit repo-wide concerns such as auth, retries, migrations, config validation, observability, and secrets flow
+
+Outputs:
+
+- `cross_cutting/<theme>.json`
+
+## Phase 7: dynamic validation
+
+Automated + LLM:
+
+- run targeted checks for suspicious cases
+- interpret repro results
+
+Outputs:
+
+- `runtime_validation_report.json`
+
+## Phase 8: coverage verification
+
+Automated:
+
+- verify every file is classified
+- verify every file is audited or explicitly excluded
+- verify reviewed line ranges cover the intended source
+- verify multi-pass overlap for critical units
+
+Outputs:
+
+- `coverage_matrix.json`
+- `line_coverage_map.json`
+- `uncovered_items.json`
+
+## Phase 9: synthesis
+
+LLM task:
+
+- deduplicate findings
+- cluster by root cause
+- prioritize remediation
+
+Outputs:
+
+- `findings.json`
+- `root_cause_clusters.json`
+- `remediation_plan.md`

package/docs/production-readiness.md

@@ -2,7 +2,7 @@
 
 ## Verdict
 
-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.
 
 It is in good shape for a controlled alpha or beta release:
 
@@ -14,6 +14,7 @@ It is in good shape for a controlled alpha or beta release:
 - malformed config and corrupted artifact handling are explicit
 - blocked fallback runs now emit structured operator handoff guidance
 - supported repo-local hosts now share a bootstrap install path via `audit-code install`
+- configured provider-assisted review can now continue to completion in a single wrapper invocation
 
 ## Why It Is Not Yet Production-Ready
 
@@ -23,8 +24,8 @@ The biggest remaining gaps are product and release-operational, not core wrapper
    The repo has publish automation, but package-name ownership and registry credentials still need to be confirmed outside the codebase.
 2. The primary conversation-first product still has setup friction on hosts without a verified repo-local slash-command surface.
    VS Code / Copilot, OpenCode, and Claude Code now share a bootstrap path, but Claude Desktop, Antigravity, and other hosts still need more work.
-3. Assisted-review continuation is still only partially solved.
-   The fallback wrapper now explains blocked states much better, but the smoothest path is still missing when an interactive provider should continue the review directly.
+3. Provider-assisted continuation still needs polish outside the happy path.
+   Configured interactive bridges can now continue through audit-task review, but operator guidance and host-specific ergonomics still need refinement when a provider cannot produce results cleanly.
 
 The explicit launch bar is now documented in `docs/production-launch-bar.md`, and the in-repo release gate is codified as `npm run verify:release`.
 
@@ -34,8 +35,8 @@ The explicit launch bar is now documented in `docs/production-launch-bar.md`, an
    Validate npm package-name availability and ownership for `auditor-lambda`, confirm `NPM_TOKEN` access in GitHub Actions, and run a real pre-release or dry-run publish from the release workflow path.
 2. Extend bootstrap coverage beyond the currently automated hosts.
    Keep `audit-code install` stable for VS Code / Copilot, OpenCode, and Claude Code, and close the remaining friction gap for hosts that still lack a verified repo-local install surface.
-3. Improve interactive continuation.
-   When an interactive provider is configured, continue through provider-assisted review with less operator handoff and less manual evidence re-import.
+3. Polish provider-assisted UX.
+   Keep the new continuation path explicit and inspectable while improving failure hints, host guidance, and operator recovery when a provider bridge misbehaves.
 
 ## Nice-To-Have Follow-On Work
 

package/docs/repo-layout.md

@@ -1,5 +1,5 @@
-# Repository layout
-
+# Repository layout
+
 ## Top-level purpose
 
 - `docs/`: architecture, pipeline, layout, and design notes
@@ -12,19 +12,19 @@
 - `docs/next-steps.md`: current roadmap and next implementation notes
 - `docs/production-launch-bar.md`: explicit minimum launch criteria and release verification bar
 - `docs/production-readiness.md`: current production-readiness verdict and launch blockers
-
-## Near-term code layout
-
-- `src/extractors/`: deterministic collectors and heuristic classifiers
-- `src/orchestrator/`: task construction, chunking, pass logic, and requeue support
-- `src/coverage/` or `src/coverage.ts`: coverage accounting helpers
-- `src/reporting/`: result merging and remediation views
-- `src/types.ts`: shared TypeScript interfaces mirroring the JSON schemas as closely as practical
-
-## Skill portability rule
-
-The repo should be usable even when the host environment changes. For that reason:
-
-- prompts should remain plain markdown
-- artifacts should remain plain JSON
-- orchestration logic should not depend on one editor or one agent runtime
+
+## Near-term code layout
+
+- `src/extractors/`: deterministic collectors and heuristic classifiers
+- `src/orchestrator/`: task construction, chunking, pass logic, and requeue support
+- `src/coverage/` or `src/coverage.ts`: coverage accounting helpers
+- `src/reporting/`: result merging and remediation views
+- `src/types.ts`: shared TypeScript interfaces mirroring the JSON schemas as closely as practical
+
+## Skill portability rule
+
+The repo should be usable even when the host environment changes. For that reason:
+
+- prompts should remain plain markdown
+- artifacts should remain plain JSON
+- orchestration logic should not depend on one editor or one agent runtime