auditor-lambda 0.1.0 → 0.2.2

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

package/docs/run-flow.md

@@ -9,11 +9,11 @@ This document describes the backend execution flow that supports that conversati
 1. Build or import a repository manifest.
 2. Build audit units from the repository manifest.
 3. Initialize a coverage matrix from the file list.
-4. Apply unit-to-file coverage requirements.
-5. Build initial audit tasks.
-6. Dispatch those tasks to LLM agents or other runtimes.
-7. Ingest structured audit results.
-8. Apply reviewed ranges and completed lenses to the coverage matrix.
+4. Apply unit-to-file coverage requirements.
+5. Build initial audit tasks.
+6. Dispatch those tasks to LLM agents or other runtimes.
+7. Ingest structured audit results.
+8. Apply reviewed ranges and completed lenses to the coverage matrix.
 9. Build requeue tasks for missing lenses or uncovered ranges.
 10. Repeat until coverage rules are satisfied.
 11. Synthesize findings into merged outputs.