auditor-lambda 0.2.6 → 0.2.9

package/docs/contract.md

@@ -1,59 +1,12 @@
-# audit-code response contract
+# audit-code Response Contract
 
-This document describes the backend fallback JSON contract for `audit-code`.
+This document follows [audit-goals.md](C:/Code/auditor-lambda/spec/audit-goals.md).
 
-The canonical product remains `/audit-code` in conversation.
+## Canonical output
 
-## Backend fallback commands
+The authoritative completed-audit output is repo-root `audit-report.md`.
 
-Repo-local fallback command from the target repository root:
-
-```bash
-audit-code
-```
-
-Useful helpers:
-
-```bash
-audit-code prompt-path
-audit-code validate
-audit-code explain-task <task_id>
-audit-code --batch-results /path/to/audit-results-dir
-```
-
-Repository-local wrapper equivalent:
-
-```bash
-node audit-code.mjs
-```
-
-## Contract version
-
-Every canonical wrapper response includes:
-
-```text
-contract_version: audit-code/v1alpha1
-```
-
-Consumers should verify this value before assuming the response shape.
-
-## Source of truth
-
-The versioned wrapper schema is:
-
-```text
-schemas/audit-code-v1alpha1.schema.json
-```
-
-Artifact-level schemas also live in `schemas/`, including:
-
-- `schemas/audit_task.schema.json`
-- `schemas/audit_result.schema.json`
-- `schemas/finding.schema.json`
-
-## Top-level wrapper fields
-
-The current v1alpha1 wrapper contract includes:
+Until completion, the wrapper response remains a JSON envelope with:
 
 - `contract_version`
 - `audit_state`
@@ -65,167 +18,31 @@ The current v1alpha1 wrapper contract includes:
 - `next_likely_step`
 - `handoff`
 
-`handoff` is a companion operator-context object. It includes:
-
-- repo and artifacts paths
-- pending obligations
-- suggested evidence-import paths and commands
-- provider guidance
-- stable paths to operator handoff artifacts
-
-## Terminal states
-
-Consumers should continue invoking the same wrapper until:
-
-1. `next_likely_step == null`
+## AuditResult contract
 
-Terminal interpretation:
+Workers submit `AuditResult[]` shaped by `schemas/audit_result.schema.json`.
 
-- `audit_state.status == "complete"` means the audit finished end to end.
-- `audit_state.status == "blocked"` means no further automatic progress is available and the remaining work needs imported results or an interactive provider.
-- `progress_made` tells you whether the current invocation wrote additional artifacts before it reached that terminal state.
+Important rules:
 
-When the wrapper emits a response, it also refreshes:
+- `file_coverage` is required and must include every assigned file.
+- `file_coverage[].total_lines` must match the current file line count.
+- `findings[].affected_files` must be objects, not strings.
+- `findings[].evidence` must be an array of plain strings.
 
-- `.audit-artifacts/operator-handoff.json`
-- `.audit-artifacts/operator-handoff.md`
+Use `audit-code validate-results --results <file>` before ingestion to validate
+results against the active task manifest.
 
-## Artifact contract
+## Internal artifacts during incomplete runs
 
-These are the primary machine-readable artifacts:
+The engine may keep resumable artifacts under `.audit-artifacts/`, including:
 
-- `repo_manifest.json`
-- `file_disposition.json`
-- `unit_manifest.json`
-- `critical_flows.json`
-- `coverage_matrix.json`
-- `runtime_validation_tasks.json`
-- `runtime_validation_report.json`
+- intake/structure/planning artifacts
 - `audit_tasks.json`
 - `audit_results.jsonl`
 - `requeue_tasks.json`
-- `merged_findings.json`
-- `root_cause_clusters.json`
-- `synthesis_report.json`
-
-Important shape notes:
-
-- `audit_tasks.json`: each task already contains its resolved `file_paths`.
-- `coverage_matrix.json`: each file records `classification_status`, `audit_status`, `required_lenses`, and `completed_lenses`.
-- `synthesis_report.json`: includes `merged_findings`, semantic `root_cause_clusters`, and `work_blocks`.
-
-## Task id conventions
-
-Current task ids follow a few stable patterns:
-
-- Standard unit/lens task: `<unit_id>:<lens>`
-- Large-file split task: `<unit_id>:<lens>:<file_path>`
-- External analyzer follow-up: `analyzer:<tool>:<lens>:<path>:<result_id>`
-- Requeue task: `requeue:<lens>:<path>`
-
-If you need the resolved task payload plus current coverage state, use:
-
-```bash
-audit-code explain-task <task_id>
-```
-
-## AuditResult contract
-
-`AuditResult.findings[].evidence` is an array of plain strings only. Use entries like:
-
-```text
-src/foo.ts:42 - variable overwritten before use
-```
-
-`reviewed_ranges` now carries mechanical verification metadata:
-
-- `path`
-- `start`
-- `end`
-- `line_count`
-
-`line_count` must match the current total line count of the file. Ingestion also checks that any cited `affected_files` line span falls inside the declared `reviewed_ranges`.
-
-Worked example:
-
-```json
-[
-  {
-    "task_id": "src-api-auth:security",
-    "unit_id": "src-api-auth",
-    "pass_id": "pass:security",
-    "lens": "security",
-    "agent_role": "security-auditor",
-    "reviewed_ranges": [
-      {
-        "path": "src/api/auth.ts",
-        "start": 1,
-        "end": 48,
-        "line_count": 48
-      }
-    ],
-    "findings": [
-      {
-        "id": "finding-auth-1",
-        "title": "Authentication failures are not logged",
-        "category": "security",
-        "severity": "medium",
-        "confidence": "high",
-        "lens": "security",
-        "summary": "Rejected authentication attempts bypass structured audit logging.",
-        "affected_files": [
-          {
-            "path": "src/api/auth.ts",
-            "line_start": 18,
-            "line_end": 26
-          }
-        ],
-        "evidence": [
-          "src/api/auth.ts:18 - failure branch returns without emitting audit telemetry"
-        ]
-      }
-    ],
-    "notes": [
-      "Reviewed the entire file under the security lens."
-    ],
-    "requires_followup": false
-  }
-]
-```
-
-Workers should validate against these schemas before submission instead of discovering shape errors during ingestion.
-
-## Audit state shape
-
-`audit_state` includes:
-
-- `status`
-- `obligations`
-- optional `last_executor`
-- optional `last_obligation`
-- optional `blockers`
-
-`status` is one of:
-
-- `not_started`
-- `active`
-- `blocked`
-- `complete`
-
-Each obligation includes:
-
-- `id`
-- `state`
-- optional `reason`
-
-Obligation `state` is one of:
-
-- `missing`
-- `present`
-- `stale`
-- `blocked`
-- `satisfied`
-
-## Compatibility note
+- `runtime_validation_tasks.json`
+- `runtime_validation_report.json` when runtime validation is planned
+- dispatch files for the active worker task
 
-This contract is versioned as `v1alpha1` deliberately. It is stable enough for current product use, but it should still be treated as pre-v1.
+These artifacts are internal and transient. On successful completion, they are
+cleared out and only `audit-report.md` remains.

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,45 +15,68 @@ 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. Realign review dispatch with the conversation-owned workflow
 
-The biggest remaining UX gap is that some hosts still lack a verified repo-local install surface.
+The highest-priority product refactor is to move semantic-review ownership back to the active conversation agent and to replace the current unit-first review fan-out with non-overlapping lens-aware review blocks.
 
 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
+- making the active conversation agent the default owner of semantic review
+- keeping `agent_task_batch_size` at one review block per task
+- treating backend provider adapters as compatibility bridges rather than the default review owner
+- replacing the current unit-first task planner with a non-overlapping lens-block planner
+- deleting the stale audit state and rerunning the audit only after that refactor lands
 
-Current emphasis should follow actual operator usage:
+The current handoff for this work is:
 
-- 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
+- `docs/workflow-refactor-brief.md`
+- `docs/remediation-baseline.md`
 
-### 2. Make the conversation route more native
+### 2. Verify the shipped host integrations end to end
 
-The product goal is still conversational first, not fallback-CLI first.
+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:
 
-- 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
+- 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
 
-### 3. Polish continuation through assisted review
+### 3. Close the remaining host-native UX gaps
+
+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:
+
+- 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
+
+### 4. Polish continuation through assisted review
 
 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.
 
@@ -63,32 +86,35 @@ Near-term work should focus on:
 - 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
+### 5. Harden publish and release operations
 
 The packaged install story is in place, but release operations still need finishing work.
 
 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 +125,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 +161,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

@@ -31,6 +31,18 @@ npm install
 npm run verify:release
 ```
 
+For live child-process output during packaged smoke debugging:
+
+```bash
+AUDIT_CODE_VERBOSE=1 npm run smoke:packaged-audit-code
+```
+
+For the linked-install variant:
+
+```bash
+AUDIT_CODE_VERBOSE=1 npm run smoke:linked-audit-code
+```
+
 That script:
 
 - creates a tarball with `npm pack`
@@ -41,6 +53,8 @@ That script:
 - invokes the installed `audit-code` binary from `node_modules/.bin`
 - validates emitted JSON against `schemas/audit-code-v1alpha1.schema.json`
 - exercises the same evidence-import and completion flow used by the linked-command smoke test
+- strips inherited `npm_config_*`, `NODE_AUTH_TOKEN`, and `NPM_TOKEN` values before nested npm operations so `npm publish --dry-run` does not accidentally suppress tarball generation or leak publish credentials into the smoke environment
+- emits step-by-step progress plus a final success summary so CI logs show where the run failed or completed across both the linked and packaged smoke paths
 
 ## CI
 
@@ -61,22 +75,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 release steps
+
+Actual publication still depends on npm-side configuration outside the repository:
 
-## Remaining external dependency
+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
 
-Actual publication still depends on confirmed npm package-name availability and ownership, plus a configured `NPM_TOKEN` secret for automated publishing.
+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/product-direction.md

@@ -78,11 +78,32 @@ For repo-local backend usage:
 - `provider: "auto"` is the explicit opt-in mode for best-effort routing across configured or detected backends
 - explicit provider names should remain available for operators who want a specific backend
 
+## Semantic review ownership
+
+The intended semantic-review owner is the active conversation agent.
+
+That means:
+
+- `/audit-code` should hand review work to the current conversation or host agent session first
+- if that active agent can delegate to subagents in parallel, that fan-out belongs to the host runtime rather than to repo-local backend defaults
+- backend provider adapters are compatibility bridges for fallback CLI usage, not the default owner of review work
+- session-config should not be the normal mechanism for redirecting semantic review into a second external LLM CLI
+
+## Task-planning rule
+
+The intended review planner should:
+
+- determine which files require which lenses
+- partition unresolved review into non-overlapping review blocks
+- prefer lens-homogeneous blocks when practical
+- keep the default dispatch granularity to one review block per task
+
 ## Default context & model rules
 
 1. By default, the current ChatGPT project conversation and its files should be treated as the primary context.
 2. The user should not need to supply `--root`, provider names, or backend-specific settings in normal usage.
 3. For backend CLI delegation, let the chosen provider own its own model-selection behavior unless explicitly configured.
+4. Backend fallback settings should not cap the active conversation agent's own subagent parallelism model.
 
 ## Development rule
 
@@ -92,6 +113,7 @@ Future development should optimize for the native skill UX first:
 - packaged installs should help users reach the prompt asset for that conversation route
 - the CLI and supervisor are implementation details and fallback harnesses
 - provider adapters are backend internals, not the primary product concept
+- semantic-review dispatch belongs to the active conversation agent, not to an externally spawned fallback provider by default
 - docs, tests, and examples should present the skill-first flow before any CLI flow
 
 If documentation or implementation details conflict, prefer the skill-first contract above over the CLI-first backend shape.

package/docs/production-launch-bar.md

@@ -20,6 +20,8 @@ Anything below `dist/index.js` remains a backend or development interface rather
 ### Node and package runtime
 
 - Node `>=20` is the minimum supported runtime from `package.json`
+- GitHub Actions currently exercises the test suite on Node `20` and Node `22`
+- release and publish automation stays pinned to Node `22.14.0`
 - packaged installs must include:
   - `audit-code`
   - `audit-code-wrapper-lib.mjs`
@@ -61,8 +63,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.