auditor-lambda 0.1.0 → 0.2.1

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.

package/docs/session-config.md

@@ -5,11 +5,11 @@ This file only applies to the backend fallback CLI.
 The canonical `/audit-code` conversation route should not require users to touch it.
 
 Backend provider configuration lives at:
-
-```text
-.audit-artifacts/session-config.json
-```
-
+
+```text
+.audit-artifacts/session-config.json
+```
+
 This file is optional.
 
 If it does not exist, the backend defaults to its built-in behavior.
@@ -20,213 +20,219 @@ You can also check it explicitly with:
 ```bash
 audit-code validate
 ```
-
-## Supported fields
-
-```json
-{
-  "provider": "local-subprocess",
-  "timeout_ms": 1800000,
-  "ui_mode": "headless"
-}
-```
-
-### `provider`
-
-Supported values:
-
-- `auto`
-- `local-subprocess`
-- `subprocess-template`
-- `claude-code`
-- `opencode`
-- `vscode-task`
-
-### `timeout_ms`
-
-Worker-run timeout in milliseconds.
-
-### `ui_mode`
-
-Supported values:
-
-- `headless`
-- `visible`
-
-Use `visible` when you want stdout and stderr mirrored into the current terminal while the provider runs.
-
-## Auto provider mode
-
-`auto` is an explicit opt-in mode.
-
-If `provider` is omitted entirely, the backend still defaults to `local-subprocess`.
-
-When `provider` is set to `auto`, resolution works like this:
-
-1. use `vscode-task` when running under VS Code and a `vscode_task.command_template` is configured
-2. otherwise use `subprocess-template` when `subprocess_template.command_template` is configured
-3. otherwise use `claude-code` when Claude Code is available and preferred by config or when it is the only detected external CLI
-4. otherwise use `opencode` when OpenCode is available and preferred by config or when it is the only detected external CLI
-5. otherwise fall back to `local-subprocess`
-
-This keeps the current default stable while still allowing best-effort cross-editor/provider routing when you explicitly want it.
-
-## Provider-specific sections
-
+
+## Supported fields
+
+```json
+{
+  "provider": "local-subprocess",
+  "timeout_ms": 1800000,
+  "ui_mode": "headless"
+}
+```
+
+### `provider`
+
+Supported values:
+
+- `auto`
+- `local-subprocess`
+- `subprocess-template`
+- `claude-code`
+- `opencode`
+- `vscode-task`
+
+### `timeout_ms`
+
+Worker-run timeout in milliseconds.
+
+### `ui_mode`
+
+Supported values:
+
+- `headless`
+- `visible`
+
+Use `visible` when you want stdout and stderr mirrored into the current terminal while the provider runs.
+
+## Auto provider mode
+
+`auto` is an explicit opt-in mode.
+
+If `provider` is omitted entirely, the backend still defaults to `local-subprocess`.
+
+When `provider` is set to `auto`, resolution works like this:
+
+1. use `vscode-task` when running under VS Code and a `vscode_task.command_template` is configured
+2. otherwise use `subprocess-template` when `subprocess_template.command_template` is configured
+3. otherwise use `claude-code` when Claude Code is available and preferred by config or when it is the only detected external CLI
+4. otherwise use `opencode` when OpenCode is available and preferred by config or when it is the only detected external CLI
+5. otherwise fall back to `local-subprocess`
+
+This keeps the current default stable while still allowing best-effort cross-editor/provider routing when you explicitly want it.
+
+## Provider-specific sections
+
 ### `local-subprocess`
 
 No extra config is required.
 
 This mode covers deterministic worker runs locally and stops in a terminal blocked state once the remaining work requires imported audit results or an interactive provider.
-
-### `claude_code`
-
-```json
-{
-  "provider": "claude-code",
-  "ui_mode": "visible",
-  "claude_code": {
-    "command": "claude",
-    "extra_args": []
-  }
-}
-```
-
-Fields:
-
-- `command`: optional override for the Claude Code executable
-- `extra_args`: optional extra arguments appended before the built-in permission-skipping flag
-
-### `opencode`
-
-```json
-{
-  "provider": "opencode",
-  "ui_mode": "visible",
-  "opencode": {
-    "command": "opencode",
-    "extra_args": []
-  }
-}
-```
-
-Fields:
-
-- `command`: optional override for the OpenCode executable
-- `extra_args`: optional additional arguments for `opencode run ...`
-
-### `subprocess_template`
-
-```json
-{
-  "provider": "subprocess-template",
-  "ui_mode": "visible",
-  "subprocess_template": {
-    "command_template": ["bash", "-lc", "{workerCommandShell}"],
-    "env": {}
-  }
-}
-```
-
-Fields:
-
-- `command_template`: required command array
-- `env`: optional environment-variable overlay
-
-### `vscode_task`
-
-```json
-{
-  "provider": "vscode-task",
-  "ui_mode": "visible",
-  "vscode_task": {
-    "command_template": ["bash", "-lc", "{workerCommandShell}"],
-    "env": {}
-  }
-}
-```
-
-This adapter is intentionally thin. It uses the same template expansion model as `subprocess-template`, but is named separately so the operator intent is explicit.
-
-## Template placeholders
-
-`subprocess-template` and `vscode-task` support these placeholders inside each `command_template` entry:
-
-- `{repoRoot}`
-- `{runId}`
-- `{obligationId}`
-- `{promptPath}`
-- `{taskPath}`
-- `{resultPath}`
-- `{stdoutPath}`
-- `{stderrPath}`
-- `{workerCommandShell}`
-- `{workerCommandJson}`
-- `{uiMode}`
-- `{timeoutMs}`
-
-### Placeholder guidance
-
-- Use `{workerCommandShell}` when your launcher can execute a fully rendered shell command directly.
-- Use `{workerCommandJson}` when your launcher wants the worker command as structured data.
-- Use `{promptPath}` and `{taskPath}` when an external tool should read the generated worker instructions instead of directly executing the worker command.
-
-## Suggested starting points
-
-### Safest default
-
-```json
-{
-  "provider": "local-subprocess"
-}
-```
-
-### Best-effort automatic routing
-
-```json
-{
-  "provider": "auto",
-  "ui_mode": "visible"
-}
-```
-
-### Delegate worker runs into Claude Code
-
-```json
-{
-  "provider": "claude-code",
-  "ui_mode": "visible"
-}
-```
-
-### Delegate worker runs into OpenCode
-
-```json
-{
-  "provider": "opencode",
-  "ui_mode": "visible"
-}
-```
-
-### Use a generic bash launcher bridge
-
-```json
-{
-  "provider": "subprocess-template",
-  "ui_mode": "visible",
-  "subprocess_template": {
-    "command_template": ["bash", "-lc", "{workerCommandShell}"]
-  }
-}
-```
-
-## Antigravity note
-
-A dedicated Antigravity adapter is not currently shipped.
-
-Until one exists, the practical options are:
-
-- run `audit-code` from an Antigravity terminal with `local-subprocess`
-- use `provider: "auto"` when you want best-effort routing without forcing a specific backend
-- use `subprocess-template` with a launcher that Antigravity can reliably invoke
-- treat the conversation-level `/audit-code` contract as primary and the backend CLI as fallback
+
+### `claude_code`
+
+```json
+{
+  "provider": "claude-code",
+  "ui_mode": "visible",
+  "claude_code": {
+    "command": "claude",
+    "extra_args": []
+  }
+}
+```
+
+Fields:
+
+- `command`: optional override for the Claude Code executable
+- `extra_args`: optional extra arguments appended before the built-in permission-skipping flag
+
+When audit-task review is pending, the generated provider prompt now asks Claude Code to write structured `AuditResult[]` output and then run the bounded worker command so the same `audit-code` invocation can keep advancing.
+
+### `opencode`
+
+```json
+{
+  "provider": "opencode",
+  "ui_mode": "visible",
+  "opencode": {
+    "command": "opencode",
+    "extra_args": []
+  }
+}
+```
+
+Fields:
+
+- `command`: optional override for the OpenCode executable
+- `extra_args`: optional additional arguments for `opencode run ...`
+
+When audit-task review is pending, the generated provider prompt now asks OpenCode to write structured `AuditResult[]` output and then run the bounded worker command so the same `audit-code` invocation can keep advancing.
+
+### `subprocess_template`
+
+```json
+{
+  "provider": "subprocess-template",
+  "ui_mode": "visible",
+  "subprocess_template": {
+    "command_template": ["bash", "-lc", "{workerCommandShell}"],
+    "env": {}
+  }
+}
+```
+
+Fields:
+
+- `command_template`: required command array
+- `env`: optional environment-variable overlay
+
+When you use this bridge for provider-assisted review, the launched process should write structured audit results to `task.audit_results_path` and then execute `task.worker_command`.
+
+### `vscode_task`
+
+```json
+{
+  "provider": "vscode-task",
+  "ui_mode": "visible",
+  "vscode_task": {
+    "command_template": ["bash", "-lc", "{workerCommandShell}"],
+    "env": {}
+  }
+}
+```
+
+This adapter is intentionally thin. It uses the same template expansion model as `subprocess-template`, but is named separately so the operator intent is explicit.
+
+## Template placeholders
+
+`subprocess-template` and `vscode-task` support these placeholders inside each `command_template` entry:
+
+- `{repoRoot}`
+- `{runId}`
+- `{obligationId}`
+- `{promptPath}`
+- `{taskPath}`
+- `{resultPath}`
+- `{stdoutPath}`
+- `{stderrPath}`
+- `{workerCommandShell}`
+- `{workerCommandJson}`
+- `{uiMode}`
+- `{timeoutMs}`
+
+### Placeholder guidance
+
+- Use `{workerCommandShell}` when your launcher can execute a fully rendered shell command directly.
+- Use `{workerCommandJson}` when your launcher wants the worker command as structured data.
+- Use `{promptPath}` and `{taskPath}` when an external tool should read the generated worker instructions instead of directly executing the worker command.
+
+## Suggested starting points
+
+### Safest default
+
+```json
+{
+  "provider": "local-subprocess"
+}
+```
+
+### Best-effort automatic routing
+
+```json
+{
+  "provider": "auto",
+  "ui_mode": "visible"
+}
+```
+
+### Delegate worker runs into Claude Code
+
+```json
+{
+  "provider": "claude-code",
+  "ui_mode": "visible"
+}
+```
+
+### Delegate worker runs into OpenCode
+
+```json
+{
+  "provider": "opencode",
+  "ui_mode": "visible"
+}
+```
+
+### Use a generic bash launcher bridge
+
+```json
+{
+  "provider": "subprocess-template",
+  "ui_mode": "visible",
+  "subprocess_template": {
+    "command_template": ["bash", "-lc", "{workerCommandShell}"]
+  }
+}
+```
+
+## Antigravity note
+
+A dedicated Antigravity adapter is not currently shipped.
+
+Until one exists, the practical options are:
+
+- run `audit-code` from an Antigravity terminal with `local-subprocess`
+- use `provider: "auto"` when you want best-effort routing without forcing a specific backend
+- use `subprocess-template` with a launcher that Antigravity can reliably invoke
+- treat the conversation-level `/audit-code` contract as primary and the backend CLI as fallback

package/docs/supervisor.md

@@ -7,77 +7,77 @@ The primary product contract is `/audit-code` in conversation.
 Everything here is fallback and implementation detail guidance for the repo-local backend surface.
 
 ## Repo-local backend surface
-
-From the target repository root:
-
-```bash
-audit-code
-```
-
-Debug one-step mode:
-
-```bash
-audit-code --single-step
-```
-
-Explicit root override:
-
-```bash
-audit-code --root /path/to/repo
-```
-
-## Provider mode summary
-
-If provider is omitted entirely, the backend defaults to the safest mode:
-
-```json
-{
-  "provider": "local-subprocess"
-}
-```
-
-If you want best-effort routing across available or configured backends, opt into:
-
-```json
-{
-  "provider": "auto",
-  "ui_mode": "visible"
-}
-```
-
-Explicit backend selection remains available:
-
-```bash
-audit-code --provider local-subprocess
-audit-code --provider claude-code
-audit-code --provider opencode
-audit-code --provider subprocess-template
-audit-code --provider vscode-task
-```
-
-## Auto resolution rule
-
-When `provider` is set to `auto`, the backend resolves in this order:
-
-1. `vscode-task` when running under VS Code and a `vscode_task.command_template` is configured
-2. `subprocess-template` when a generic template bridge is configured
-3. `claude-code` when Claude Code is available and preferred by config or when it is the only detected external CLI
-4. `opencode` when OpenCode is available and preferred by config or when it is the only detected external CLI
-5. `local-subprocess` otherwise
-
-## Session config
-
-Optional backend config file:
-
-`.audit-artifacts/session-config.json`
-
-See:
-
+
+From the target repository root:
+
+```bash
+audit-code
+```
+
+Debug one-step mode:
+
+```bash
+audit-code --single-step
+```
+
+Explicit root override:
+
+```bash
+audit-code --root /path/to/repo
+```
+
+## Provider mode summary
+
+If provider is omitted entirely, the backend defaults to the safest mode:
+
+```json
+{
+  "provider": "local-subprocess"
+}
+```
+
+If you want best-effort routing across available or configured backends, opt into:
+
+```json
+{
+  "provider": "auto",
+  "ui_mode": "visible"
+}
+```
+
+Explicit backend selection remains available:
+
+```bash
+audit-code --provider local-subprocess
+audit-code --provider claude-code
+audit-code --provider opencode
+audit-code --provider subprocess-template
+audit-code --provider vscode-task
+```
+
+## Auto resolution rule
+
+When `provider` is set to `auto`, the backend resolves in this order:
+
+1. `vscode-task` when running under VS Code and a `vscode_task.command_template` is configured
+2. `subprocess-template` when a generic template bridge is configured
+3. `claude-code` when Claude Code is available and preferred by config or when it is the only detected external CLI
+4. `opencode` when OpenCode is available and preferred by config or when it is the only detected external CLI
+5. `local-subprocess` otherwise
+
+## Session config
+
+Optional backend config file:
+
+`.audit-artifacts/session-config.json`
+
+See:
+
 - `docs/session-config.md`
 - `docs/agent-integrations.md`
 - `docs/model-selection.md`
 - `docs/windows-setup.md`
-
-## Note
-
-Provider adapters are backend integrations, not the primary product concept.
+
+## Note
+
+Provider adapters are backend integrations, not the primary product concept.