auditor-lambda 0.2.5 → 0.2.8

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 18, 2026, this repository is not yet ready for a public production launch.
+As of April 22, 2026, the shared MCP substrate and the first host-native installer pass have landed, but this repository is not yet ready for a public production launch.
 
 See:
 
@@ -15,43 +15,49 @@ The repository now supports:
 - `/audit-code` as the documented canonical product route
 - packaged and repository-local access to `skills/audit-code/audit-code.prompt.md`
 - `audit-code prompt-path` as a stable prompt lookup helper
-- `audit-code install` as a bootstrap installer for the currently automated repo-local host surfaces
+- `audit-code install --host vscode|opencode|codex|claude-desktop|antigravity|all` as a bootstrap installer for the current host surfaces
+- `audit-code mcp` as a first-class stdio MCP server entrypoint
+- a stable MCP contract with the `start_audit`, `get_status`, `continue_audit`, `explain_task`, `validate_artifacts`, `import_results`, and `import_runtime_updates` tools
+- repo-local MCP resources for current artifacts, operator handoff, install guidance, and the current audit report
+- repo-local MCP prompts for `audit-code`, `review-task`, and `synthesize-report`
+- generated `.audit-code/install/manifest.json` plus a shared repo-local MCP launcher script
+- Codex install assets including a repo skill bundle, `AGENTS.md` support, MCP setup guidance, and an automation recipe
+- Claude Desktop install assets including a project template, remote connector template, and generated local bundle artifacts
+- OpenCode install assets including command, skill, prompt, and `opencode.json` support
+- VS Code install assets including prompt file, Copilot instructions, custom agent, and `.vscode/mcp.json`
+- Antigravity install assets including planning-mode guidance and MCP-oriented setup guidance
 - explicit failures for malformed backend config and corrupted artifact JSON
 - `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.
+That means the current release is suitable for a controlled alpha or beta skill-first workflow with MCP-aware host bootstrapping, but it is not yet the final public production end-state.
 
 ## Near-term priorities
 
-### 1. Reduce conversation setup friction
+### 1. Verify the shipped host integrations end to end
 
-The biggest remaining UX gap is that some hosts still lack a verified repo-local install surface.
+The biggest remaining gap is not raw feature presence anymore. It is host-by-host proof that the generated assets work in the actual products they target.
 
 Near-term work should focus on:
 
-- host-specific setup guides that reduce copy-paste ambiguity
-- preserving `audit-code install` as the default no-guess bootstrap path
-- extending bootstrap coverage to hosts that still need manual prompt import
-- a shorter path from package install to a working `/audit-code` conversation flow
+- verifying the Codex skill bundle, `AGENTS.md`, MCP setup guidance, and automation recipe against the real Codex app flow
+- installing and smoke-testing the generated Claude Desktop `DXT` or bundle output in a real Desktop environment
+- validating that the OpenCode `opencode.json` shape, command file, and MCP config match current OpenCode behavior
+- validating the VS Code prompt, agent, and `.vscode/mcp.json` flow inside a real workspace
+- validating that the Antigravity planning-mode guidance is accurate and does not over-promise a native saved-workflow surface
 
-Current emphasis should follow actual operator usage:
+### 2. Close the remaining host-native UX gaps
 
-- keep VS Code and OpenCode as the primary polished happy path
-- treat Claude Desktop and Antigravity as the highest-priority manual-import surfaces
-- avoid spending near-term effort on lower-priority editor integrations unless they materially improve the shared prompt-import path
-
-### 2. Make the conversation route more native
-
-The product goal is still conversational first, not fallback-CLI first.
+The product goal is still conversational first, not fallback-CLI first, and some shipped surfaces are still guidance-heavy rather than truly native.
 
 Near-term work should focus on:
 
-- first-class integrations for the most important editor or agent hosts
-- removing host-specific manual prompt wiring where practical
-- keeping the active conversation model and attached repo context as the default operating mode
+- turning the Codex automation recipe into a proven, documented automation flow after real operator validation
+- polishing Claude Desktop one-click install so the generated bundle is a clearly supported path instead of a mostly technical artifact
+- deciding whether OpenCode and VS Code need any smaller UX refinements after smoke-testing, rather than assuming the first generated surfaces are final
+- keeping Antigravity framed as a workflow-and-artifacts host until Google documents a stable project-local config surface
 
 ### 3. Polish continuation through assisted review
 
@@ -70,25 +76,28 @@ The packaged install story is in place, but release operations still need finish
 Near-term work should focus on:
 
 - npm package-name availability and ownership
-- final publication automation and secret management
+- one-time npm Trusted Publisher setup for `.github/workflows/publish-package.yml`
+- the first GitHub Actions dry run and live publish through that workflow
+- keeping prerelease publication off the `latest` dist-tag unless intentionally requested
 - keeping linked-install and packaged-install smoke checks as release gates
 
 ## Frictionless-ready checklist
 
 The repository should not be described as frictionless and production-ready until this checklist is substantially true:
 
-### VS Code, OpenCode, and Claude Code
+### Codex, Claude Desktop, OpenCode, and VS Code
 
 - `audit-code install` remains the default bootstrap path
 - the generated repo-local surfaces are obvious in installer output and in `.audit-code/install/GETTING-STARTED.md`
 - a new user can invoke `/audit-code` without guessing where prompts or commands were written
+- the generated MCP setup path works in the real host, not only in unit tests
 - smoke coverage continues to verify the exact repo-local files these hosts consume
 
-### Claude Desktop and Antigravity
+### Antigravity
 
-- the installed prompt-import path is explicit, repo-local, and easy to discover
-- `.audit-code/install/GETTING-STARTED.md` gives host-specific steps instead of generic manual-import advice
-- docs avoid implying native repo-local slash-command support that is not actually shipped
+- the planning-mode guidance is explicit, repo-local, and easy to discover
+- `.audit-code/install/GETTING-STARTED.md` gives Antigravity-specific steps instead of generic prompt-import advice
+- docs avoid implying native repo-local saved-workflow support that is not actually shipped
 - the backend fallback remains a clearly secondary path instead of the default recommendation
 
 ### Assisted review continuation
@@ -99,27 +108,28 @@ The repository should not be described as frictionless and production-ready unti
 ### Release operations
 
 - `npm run verify:release` remains green and authoritative
-- the real publish path is proven with npm ownership, `NPM_TOKEN`, and a real dry-run or pre-release publish
+- the real publish path is proven with npm ownership, npm Trusted Publishing, and a real GitHub Actions dry run or prerelease publish
 
 ## Probable next steps
 
 These are the most likely next implementation steps based on the current codebase state, but they should still be treated as provisional rather than guaranteed:
 
-### 1. Ship a real bootstrap installer instead of making users pick a host first
+### 1. Prove the host installers in real products
 
 Status:
 
-- completed for the currently automated repo-local hosts via `audit-code install`
+- partially completed in code, not yet fully validated operationally
 
-Practical success bar now met:
+Most likely shape:
 
-- a new user can run one install command and get repo-local `/audit-code` surfaces for VS Code / Copilot, OpenCode, and Claude Code without guessing where the prompt belongs
+- run fresh-repo smoke checks inside Codex, Claude Desktop, OpenCode, and VS Code
+- confirm that the generated files are both syntactically valid and actually discovered by each host
+- tighten generated docs wherever operator confusion appears during those checks
+- keep Antigravity as a documented planning-mode path unless a stable project config contract is published
 
-Follow-on shape:
+Practical success bar:
 
-- keep the shared bootstrap path well-supported instead of growing one-off host installers
-- 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
+- a new operator can run one install command and reach a working `/audit-code` or MCP-backed flow in each claimed host without guesswork
 
 ### 2. Harden configured interactive-provider continuation
 
@@ -134,25 +144,30 @@ Practical success bar:
 
 - 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
+### 3. Finish the Claude Desktop and Antigravity follow-through
 
 Most likely shape:
 
-- confirm npm package-name ownership and `NPM_TOKEN` availability
-- run a real pre-release or dry-run publish
-- keep `npm run verify:release` as the minimum in-repo gate before publish
+- prove the generated Claude Desktop local bundle in a real Desktop install flow
+- decide whether to check in or generate the final desktop-extension packaging metadata more explicitly
+- add remote connector deployment guidance that is specific enough for Team or Enterprise rollout
+- document exactly how Antigravity-produced artifacts should flow back through `import_results` and `import_runtime_updates`
 
 Practical success bar:
 
-- the release workflow is demonstrated end to end instead of only being inferred from configuration
+- Claude Desktop and Antigravity guidance is operational, specific, and consistent with what the products really support
 
-### 4. Expand host-specific setup guidance after the first integration lands
+### 4. Prove the release path outside the repository
 
 Most likely shape:
 
-- keep the generated repo-local guide aligned with the real bootstrap surfaces for VS Code, OpenCode, and Claude Code
-- keep Claude Desktop and Antigravity guidance explicit about prompt import and terminal fallback rather than pretending native repo-local slash-command support
-- avoid broad host promises that the codebase does not yet verify
+- confirm npm package-name ownership and npm Trusted Publisher configuration
+- run a real GitHub Actions pre-release or dry-run publish
+- keep `npm run verify:release` as the minimum in-repo gate before publish
+
+Practical success bar:
+
+- the release workflow is demonstrated end to end instead of only being inferred from configuration
 
 ## Non-goals for the next phase
 

package/docs/packaging.md

@@ -61,22 +61,32 @@ The release publish gate also runs both installed-entrypoint smoke paths before
 The repository now includes packaging metadata and lifecycle hooks intended for registry publication:
 
 - `package.json` is no longer marked private
+- `publishConfig.access` defaults publication to the public npm access level
 - package contents are curated with a `files` allowlist that includes the canonical prompt asset
 - `prepack` and `prepare` build the runtime artifact
 - `verify:release` codifies the minimum in-repo release gate
 - `prepublishOnly` now runs that full release gate, including both linked-install and packaged-install smoke validation
 - packaged smoke now verifies the tarball includes `audit-code-wrapper-lib.mjs`, the prompt asset, the response schema, and `dist/` entrypoints before install-time smoke runs
 - the GitHub publish workflow uses the same release gate before `npm publish`
+- the GitHub publish workflow uses npm Trusted Publishing with GitHub OIDC instead of a long-lived publish token
+- prerelease versions now default to the `next` dist-tag in the publish workflow unless an explicit tag override is chosen on manual dispatch
 
-## Remaining external dependency
+## Remaining external release steps
 
-Actual publication still depends on confirmed npm package-name availability and ownership, plus a configured `NPM_TOKEN` secret for automated publishing.
+Actual publication still depends on npm-side configuration outside the repository:
+
+1. confirm package ownership and intended publish target for `auditor-lambda`
+2. configure npm Trusted Publishing for `.github/workflows/publish-package.yml`
+3. run the first GitHub Actions dry run or live prerelease from that workflow path
+
+The repository-side workflow already pins Node `22.14.0` and upgrades npm to `>=11.5.1`, which is the current minimum combination npm documents for GitHub Actions Trusted Publishing.
 
 ## Next packaging steps
 
 The next implementation phase should focus on:
 
-- completing npm publication prerequisites
+- completing the one-time npm Trusted Publisher setup
+- proving the GitHub Actions dry-run and live publish path end to end
 - preserving the packaged prompt asset and `audit-code prompt-path` as stable release guarantees
 - preserving `audit-code install` as a packaged-install compatibility guarantee
 - keeping linked-install and packaged-install smoke coverage in the publish gate

package/docs/production-launch-bar.md

@@ -61,8 +61,8 @@ npm run verify:release
 In addition to the in-repo gate, production readiness still requires these external checks:
 
 1. confirm npm package-name ownership and intended publish target
-2. confirm `NPM_TOKEN` availability for the publish workflow
-3. run a real pre-release or dry-run publish from the release path you intend to use
+2. configure npm Trusted Publishing for `.github/workflows/publish-package.yml`
+3. run a real GitHub Actions dry run or prerelease publish from that workflow path
 
 ## Operator validation expectations
 

package/docs/production-readiness.md

@@ -2,26 +2,30 @@
 
 ## Verdict
 
-As of April 18, 2026, this repository is not yet ready for a public production launch.
+As of April 22, 2026, the package release path is ready for a public npm release candidate, but the broader host experience still has follow-through work before it should be described as a frictionless production launch.
 
-It is in good shape for a controlled alpha or beta release:
+What is already true:
 
 - TypeScript build passes
 - automated test suite passes
 - linked-install smoke coverage passes
 - packaged-install smoke coverage passes
 - packaged tarball contract verification passes
+- `npm run verify:release` passes for the current `0.2.8` worktree
+- local `npm publish --dry-run` passes for `auditor-lambda@0.2.8`
+- npm currently reports `auditor-lambda@0.2.6` as `latest`, so the checked-in release version is still unpublished
 - 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
+- the GitHub publish workflow is configured for Trusted Publishing through GitHub OIDC rather than a long-lived npm token
 
-## Why It Is Not Yet Production-Ready
+## Why It Is Not Yet A Broad Production Claim
 
 The biggest remaining gaps are product and release-operational, not core wrapper correctness:
 
 1. npm publication is not fully proven end to end.
-   The repo has publish automation, but package-name ownership and registry credentials still need to be confirmed outside the codebase.
+   The repo now has a Trusted Publishing workflow and a passing local dry run, but npm-side trusted publisher setup plus the first GitHub Actions dry run still need to be completed 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. Provider-assisted continuation still needs polish outside the happy path.
@@ -32,7 +36,7 @@ The explicit launch bar is now documented in `docs/production-launch-bar.md`, an
 ## Required Next Steps
 
 1. Confirm release operations externally.
-   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.
+   Validate npm package-name ownership for `auditor-lambda`, configure npm Trusted Publishing for `.github/workflows/publish-package.yml`, and run a real GitHub Actions dry run or prerelease publish from that 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. Polish provider-assisted UX.

package/docs/releasing.md

@@ -0,0 +1,81 @@
+# Releasing
+
+This repository publishes to npm through GitHub Actions Trusted Publishing.
+
+The canonical workflow is:
+
+`/.github/workflows/publish-package.yml`
+
+That workflow already:
+
+- runs on GitHub-hosted runners
+- requests `id-token: write` for npm OIDC exchange
+- pins Node `22.14.0`
+- upgrades npm to `>=11.5.1`
+- runs `npm run verify:release` before any publish attempt
+- defaults semver prerelease versions to the `next` dist-tag unless manual dispatch overrides it
+
+## One-time npm setup
+
+Before the first live publish, configure npm itself to trust this repository:
+
+1. confirm the intended npm owner already controls `auditor-lambda`
+2. in the npm package settings, add a GitHub Actions trusted publisher for:
+   - owner or organization: `OhOkThisIsFine`
+   - repository: `auditor-lambda`
+   - workflow filename: `publish-package.yml`
+3. keep the workflow filename stable after that, or update the npm trusted publisher entry before renaming it
+4. after the first successful trusted publish, consider enabling npm's setting that requires 2FA and disallows legacy publish tokens
+
+## Release preflight
+
+From the repository root:
+
+```bash
+npm ci
+npm run verify:release
+npm publish --dry-run
+```
+
+The local dry run is still valuable even though the real publish happens in GitHub Actions. It proves the packed artifact, lifecycle hooks, and publish metadata before you spend a release on a broken workflow run.
+
+## GitHub release paths
+
+### Manual dry run
+
+Use GitHub Actions `workflow_dispatch` when you want to prove the exact publish workflow without uploading a package.
+
+Recommended inputs:
+
+- `dry_run=true`
+- `publish_tag=auto`
+
+`publish_tag=auto` resolves like this:
+
+- stable versions publish to `latest`
+- semver prerelease versions publish to `next`
+
+### Manual live publish
+
+Use `workflow_dispatch` with:
+
+- `dry_run=false`
+- `publish_tag=auto` unless you intentionally need a different dist-tag
+
+This is the safest path for the first trusted-publishing release because it lets you prove the workflow before tying it to a GitHub Release event.
+
+### Release-driven publish
+
+After the manual path is proven, publishing a GitHub Release will trigger the same workflow and publish the package.
+
+## Post-publish checks
+
+After a live publish, verify the result from a clean shell:
+
+```bash
+npm view auditor-lambda version
+npm view auditor-lambda dist-tags --json
+npm audit signatures
+```
+
+Also confirm that the npm package page shows the expected version and provenance information.

package/docs/session-config.md

@@ -13,6 +13,13 @@ Backend provider configuration lives at:
 This file is optional.
 
 If it does not exist, the backend defaults to its built-in behavior.
+On first backend run, `audit-code` now writes a repo-local default file automatically:
+
+```json
+{
+  "provider": "local-subprocess"
+}
+```
 
 If it exists but contains invalid values, the backend now fails loudly before starting worker runs.
 You can also check it explicitly with:
@@ -27,7 +34,9 @@ audit-code validate
 {
   "provider": "local-subprocess",
   "timeout_ms": 1800000,
-  "ui_mode": "headless"
+  "ui_mode": "headless",
+  "agent_task_batch_size": 4,
+  "parallel_workers": 2
 }
 ```
 
@@ -55,6 +64,16 @@ Supported values:
 
 Use `visible` when you want stdout and stderr mirrored into the current terminal while the provider runs.
 
+### `agent_task_batch_size`
+
+How many audit tasks to include in one provider-assisted review batch.
+
+When this is greater than `1`, the generated worker prompt points at `current-tasks.json` / `pending-audit-tasks.json` and expects one `AuditResult` per assigned task.
+
+### `parallel_workers`
+
+How many provider-assisted review batches to launch in parallel when the selected provider supports it.
+
 ## Auto provider mode
 
 `auto` is an explicit opt-in mode.

package/docs/usage.md

@@ -36,10 +36,17 @@ Pass additional evidence back into the same fallback wrapper when needed:
 
 ```bash
 audit-code --results /path/to/audit_results.json
+audit-code --batch-results /path/to/audit-results-dir
 audit-code --updates /path/to/runtime_validation_update.json
 audit-code --external-analyzer-results /path/to/external_analyzer_results.json
 ```
 
+Inspect the resolved scope of a task id without reverse-engineering `coverage_matrix.json` manually:
+
+```bash
+audit-code explain-task src-api-auth:security
+```
+
 Each wrapper run also refreshes:
 
 - `.audit-artifacts/operator-handoff.json`
@@ -70,6 +77,7 @@ Optional inputs for the same bounded step:
 
 ```bash
 node dist/index.js advance-audit --root /path/to/repo --artifacts-dir .artifacts --results /path/to/audit_results.json
+node dist/index.js advance-audit --root /path/to/repo --artifacts-dir .artifacts --batch-results /path/to/audit-results-dir
 node dist/index.js advance-audit --root /path/to/repo --artifacts-dir .artifacts --updates /path/to/runtime_validation_update.json
 node dist/index.js advance-audit --root /path/to/repo --artifacts-dir .artifacts --external-analyzer-results /path/to/external_analyzer_results.json
 ```
@@ -110,6 +118,7 @@ It invokes the current bounded advance logic and reports the next backend step.
 
 ```bash
 node dist/index.js ingest-results --artifacts-dir .artifacts --results /path/to/audit_results.json
+node dist/index.js ingest-results --artifacts-dir .artifacts --batch-results /path/to/audit-results-dir
 ```
 
 This updates:
@@ -119,9 +128,22 @@ This updates:
 - `runtime_validation_tasks.json`
 - `runtime_validation_report.json`
 - `audit_results.jsonl`
+- `audit_tasks.json`
 - `requeue_tasks.json`
+- `merged_findings.json`
+- `root_cause_clusters.json`
 - `synthesis_report.json`
 
+The batch form processes every `*.json` file in the target directory in lexical order.
+
+## Explain a task id
+
+```bash
+node dist/index.js explain-task src-api-auth:security --artifacts-dir .artifacts
+```
+
+This prints the resolved task payload, matching `coverage_matrix.json` entries, pending coverage by file, and any already-ingested matching findings.
+
 ## Update runtime validation report with real evidence
 
 Prepare a JSON file shaped like `examples/runtime_validation_update.example.json`, then run:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "auditor-lambda",
-  "version": "0.2.5",
+  "version": "0.2.8",
   "private": false,
   "description": "Portable hybrid code-auditing framework for arbitrary repositories.",
   "type": "module",
@@ -39,6 +39,9 @@
     "type": "git",
     "url": "git+https://github.com/OhOkThisIsFine/auditor-lambda.git"
   },
+  "publishConfig": {
+    "access": "public"
+  },
   "homepage": "https://github.com/OhOkThisIsFine/auditor-lambda#readme",
   "bugs": {
     "url": "https://github.com/OhOkThisIsFine/auditor-lambda/issues"

package/schemas/audit_result.schema.json

@@ -8,7 +8,7 @@
     "unit_id",
     "pass_id",
     "lens",
-    "reviewed_ranges",
+    "file_coverage",
     "findings"
   ],
   "$defs": {
@@ -22,16 +22,15 @@
     "pass_id": { "type": "string" },
     "lens": { "type": "string" },
     "agent_role": { "type": "string" },
-    "reviewed_ranges": {
+    "file_coverage": {
       "type": "array",
       "minItems": 1,
       "items": {
         "type": "object",
-        "required": ["path", "start", "end"],
+        "required": ["path", "total_lines"],
         "properties": {
           "path": { "type": "string" },
-          "start": { "type": "integer" },
-          "end": { "type": "integer" }
+          "total_lines": { "type": "integer", "minimum": 1 }
         },
         "additionalProperties": false
       }

package/schemas/audit_task.schema.json

@@ -54,6 +54,16 @@
     "tags": {
       "type": "array",
       "items": { "type": "string" }
+    },
+    "status": {
+      "type": "string",
+      "enum": ["pending", "complete"]
+    },
+    "completed_at": {
+      "type": "string"
+    },
+    "completion_reason": {
+      "type": "string"
     }
   },
   "additionalProperties": false

package/schemas/runtime_validation_report.schema.json

@@ -14,7 +14,7 @@
           "task_id": { "type": "string" },
           "status": {
             "type": "string",
-            "enum": ["pending", "confirmed", "not_confirmed", "inconclusive"]
+            "enum": ["pending", "confirmed", "not_confirmed", "inconclusive", "not_required"]
           },
           "summary": { "type": "string" },
           "evidence": {

package/skills/audit-code/SKILL.md

@@ -21,8 +21,17 @@ Bounded steps are a backend implementation detail, not the intended user experie
 
 ## Embedded Prompt Payload
 
-For IDE-based LLMs (Antigravity, Copilot, Cursor), you can initialize the skill natively by importing the prompt payload defined in `audit-code.prompt.md`.
-This provides the LLM an exact instruction set required to natively intercept the state machine blocking phases securely and assume the responsibilities of the execution "worker".
+The prompt payload in `audit-code.prompt.md` remains the canonical instruction asset.
+
+The preferred setup path is:
+
+```bash
+audit-code install
+```
+
+That bootstrap writes repo-local host assets for Codex, Claude Desktop, OpenCode, VS Code, and Antigravity plus shared MCP setup guidance.
+
+Use direct prompt import only when the target host still needs it after bootstrap.
 
 ## Repo-local fallback
 

package/skills/audit-code/audit-code.prompt.md

@@ -28,6 +28,7 @@ If the top-level status is `"blocked"`, it means the orchestrator needs your LLM
 To determine what task you have been assigned, use your file-reading tool to inspect:
 
 - `.audit-artifacts/dispatch/current-task.json`
+- `.audit-artifacts/dispatch/current-tasks.json` when present
 - `.audit-artifacts/dispatch/current-prompt.md`
 
 ## Step 3: Audit the Code natively
@@ -39,16 +40,13 @@ To determine what task you have been assigned, use your file-reading tool to ins
 ## Step 4: Write the Findings
 
 Produce your findings array matching exactly the `AuditResult` JSON schema described in the prompt.
-Do not use `echo` or generic terminal shell strings for large JSON structures to avoid breaking JSON escaping. Instead, use your raw **File Edit Tool** to reliably save your results entirely to:
-`.audit-artifacts/worker_results_pending.json`
+Do not use `echo` or generic terminal shell strings for large JSON structures to avoid breaking JSON escaping.
+Instead, use your raw **File Edit Tool** to reliably save your results to the exact `audit_results_path` named in `.audit-artifacts/dispatch/current-task.json`.
+If `current-tasks.json` exists, emit one `AuditResult` per assigned task in that batch.
 
 ## Step 5: Feed the Loop
 
-Return your results to the state machine by running the ingestion command in the terminal:
-
-```bash
-audit-code --results .audit-artifacts/worker_results_pending.json
-```
+Return your results to the state machine by running the exact `worker_command` from `.audit-artifacts/dispatch/current-task.json`.
 
 ## Step 6: Loop or Terminate
 
@@ -59,8 +57,11 @@ Continue repeating Steps 1 through 5 as necessary. The state machine will iterat
 ## Step 7: Presentation
 
 Once the audit is officially complete, DO NOT run the orchestrator again.
-Instead, use your file reading tool to consume:
+Instead, read the final deterministic report at:
+
+- `audit-report.md`
 
-- `.audit-artifacts/synthesis_report.json`
+Present the completed audit back to the user with the work blocks first, since
+they are the primary remediation handoff units.
 
-Finally, read these synthesis findings and present them back to the user in a polished, highly readable **Markdown Summary Table** directly in the chat panel. Wait for the user to ask you to begin resolving or patching the root_cause_clusters you discovered.
+Wait for the user to ask you to begin resolving one or more work blocks.

package/schemas/merged_findings.schema.json

@@ -1,19 +0,0 @@
-{
-  "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "$id": "merged_findings.schema.json",
-  "title": "Merged Findings",
-  "type": "object",
-  "required": ["findings"],
-  "$defs": {
-    "Finding": {
-      "$ref": "finding.schema.json"
-    }
-  },
-  "properties": {
-    "findings": {
-      "type": "array",
-      "items": { "$ref": "#/$defs/Finding" }
-    }
-  },
-  "additionalProperties": false
-}