auditor-lambda 0.1.0 → 0.2.2

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.