auditor-lambda 0.2.6 → 0.2.9

package/docs/releasing.md

@@ -0,0 +1,98 @@
+# 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
+- previews the packed tarball with `npm pack --dry-run` before any live publish attempt
+- defaults semver prerelease versions to the `next` dist-tag unless manual dispatch overrides it
+- uploads npm debug logs when a publish-path step fails
+
+## 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.
+
+## Supported Node lines
+
+Routine CI currently exercises the repository on Node `20` and Node `22`.
+
+Release and publish workflows stay pinned to Node `22.14.0` because that is the line this repository uses for npm Trusted Publishing and release smoke verification.
+
+## 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.
+
+## Workflow troubleshooting
+
+If a GitHub Actions run fails:
+
+1. download the uploaded `*-npm-logs` artifact from the failed run
+2. rerun `npm ci` and `npm run verify:release` locally from the same commit
+3. for publish failures, rerun `publish-package.yml` with `dry_run=true` before retrying a live publish
+4. if publish still fails, confirm npm Trusted Publishing is still configured for `publish-package.yml`
+
+## 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/remediation-baseline.md

@@ -0,0 +1,75 @@
+# Remediation Baseline
+
+This document preserves the remediation work that is already in the source tree so the stale audit state can be discarded safely before a fresh rerun.
+
+## Safe reset boundary
+
+After reviewing this document and [docs/workflow-refactor-brief.md](/C:/Code/auditor-lambda/docs/workflow-refactor-brief.md), it is safe to delete:
+
+- `.audit-artifacts/`
+- `audit-report.md`
+
+Those files describe a stale audit run and should not be used as the primary workflow driver for the next implementation pass.
+
+The source tree and tests are the durable baseline to keep.
+
+## Remediation already landed in the source tree
+
+The current worktree already includes substantial remediation across the main audited areas.
+
+- Fixtures and workflows were hardened across `tests/fixtures/simple-app/...`, `.github/workflows/...`, `scripts/smoke-linked-audit-code.mjs`, `scripts/smoke-packaged-audit-code.mjs`, and the related release/operator docs.
+- Extractor path handling and classification behavior were tightened in `src/extractors/...` with dedicated regressions in `tests/extractors-remediation.test.mjs`.
+- Schema-contract and validation coverage were improved across `schemas/...`, `tests/helpers/jsonSchemaAssert.mjs`, `src/validation/...`, `tests/schema-contracts.test.mjs`, and `tests/validation-remediation.test.mjs`.
+- Orchestrator behavior was hardened in `src/orchestrator/...` with focused regressions in `tests/orchestrator-remediation.test.mjs` and `tests/orchestration.test.mjs`.
+- Supervisor and provider behavior were improved in `src/supervisor/...`, `src/providers/...`, and their companion tests.
+- CLI and IO behavior were tightened in `src/cli.ts`, `src/index.ts`, `src/io/...`, and the related remediation tests.
+- Reporting and synthesis behavior were improved in `src/reporting/...` with `tests/reporting-remediation.test.mjs`.
+- The generated repo-local install payload was refreshed so `.audit-code/install/claude-desktop/...` now matches the current `dist/`, `schemas/`, and `skills/audit-code` source of truth, and `.audit-code/install/manifest.json` now points `source_prompt_path` at the repo-local prompt asset instead of a machine-specific global npm path.
+
+## Verification already performed
+
+The following verification was already recorded against the current remediation tree.
+
+- `npm test` passed on 2026-04-22 with 106 passing tests.
+- `npm run build` passed in the targeted remediation passes below.
+- `node --test --test-isolation=none tests/validation-remediation.test.mjs tests/validate-command.test.mjs tests/field-trial-remediation.test.mjs tests/provider-auto-resolution.test.mjs tests/supervisor-remediation.test.mjs` passed.
+- `node --test --test-isolation=none tests/cli-remediation.test.mjs tests/validate-command.test.mjs` passed.
+- `node --test --test-isolation=none tests/extractors-remediation.test.mjs` passed.
+- `node --test --test-isolation=none tests/io-remediation.test.mjs tests/cli-remediation.test.mjs tests/validate-command.test.mjs tests/staleness.test.mjs` passed.
+- `node --test --test-isolation=none tests/adapters-remediation.test.mjs tests/reporting-remediation.test.mjs tests/field-trial-remediation.test.mjs` passed.
+- `node --test --test-isolation=none tests/orchestration.test.mjs tests/orchestrator-remediation.test.mjs tests/reporting-remediation.test.mjs` passed.
+- The manually repaired install payload now has hash parity between the committed Claude Desktop bundle and the canonical repo `dist/`, `schemas/`, and `skills/audit-code` files.
+
+## Environment limits observed during verification
+
+The current sandbox still hits `spawn EPERM` for subprocess-heavy wrapper/provider coverage.
+
+That means:
+
+- broader wrapper/provider integration checks remain environment-limited here
+- the stale audit rerun should not be treated as authoritative
+- the workflow refactor should be completed before a fresh audit is attempted
+
+## Release status
+
+Do not cut a release tag, push a release branch, or publish from the current stale audit state.
+
+The correct order is:
+
+1. preserve the source changes already made
+2. refactor the workflow
+3. delete the stale audit state
+4. rerun the audit from a clean slate
+5. only then decide whether a release is ready
+
+## Fresh rerun checklist
+
+When the workflow refactor is complete, the next context should:
+
+1. keep the current source and doc changes
+2. delete `.audit-artifacts/`
+3. delete `audit-report.md`
+4. run `npm run build`
+5. run the most relevant regression tests for the refactor
+6. start a fresh `/audit-code` run
+7. treat the new audit output as the release gate

package/docs/run-flow.md

@@ -4,20 +4,29 @@ The canonical product route is `/audit-code` in conversation.
 
 This document describes the backend execution flow that supports that conversational route and the repo-local fallback wrapper.
 
-## Current backend execution path
+## Intended review-dispatch path
 
 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.
+2. Build units, flows, and other deterministic structure artifacts.
+3. Determine which files require which lenses.
+4. Partition unresolved file/lens obligations into non-overlapping review blocks.
+5. Hand one review block at a time to the active conversation agent.
+6. Let the active agent decide whether it wants to use subagents in parallel.
 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.
+8. Mark completed file/lens coverage in the coverage matrix.
+9. Build requeue only for still-missing coverage.
 10. Repeat until coverage rules are satisfied.
 11. Synthesize findings into merged outputs.
 
+## Current implementation note
+
+The current TypeScript backend still has workflow drift:
+
+- planning is still mostly unit-first rather than lens-block-first
+- explicit backend providers can still end up owning semantic review in fallback mode
+
+That drift is being tracked explicitly in [docs/workflow-refactor-brief.md](/C:/Code/auditor-lambda/docs/workflow-refactor-brief.md).
+
 ## Current backend capability
 
 The current TypeScript implementation already covers:
@@ -27,23 +36,26 @@ The current TypeScript implementation already covers:
 - reviewed-range ingestion from audit results
 - runtime validation update ingestion
 - synthesis and completion tracking
-- backend provider handoff for interactive or assisted review
+- backend provider handoff for fallback or compatibility review flows
 
 ## Product interpretation
 
 - the conversation route should hide this state machine behind `/audit-code`
 - the repo-local `audit-code` wrapper is fallback infrastructure for operators and local harnesses
 - provider adapters and artifact plumbing are backend details, not the primary product story
+- the active conversation agent should own semantic review by default
 - when fallback execution blocks, the wrapper should still leave behind explicit operator handoff files and suggested evidence-import paths
 
 ## Next backend implementation steps
 
 The next backend-focused work should support the conversation route more directly by:
 
-- reducing operator friction when the backend reaches a blocked handoff
-- improving continuation when interactive providers are configured
+- realigning review planning around non-overlapping lens blocks
+- moving semantic-review ownership back to the active conversation agent
+- keeping backend provider bridges explicitly secondary
 - keeping evidence import and runtime-update handoff paths explicit and easier to follow
 
 Broader product priorities are tracked in:
 
+- `docs/workflow-refactor-brief.md`
 - `docs/next-steps.md`

package/docs/session-config.md

@@ -1,9 +1,14 @@
 # session-config
 
-This file only applies to the backend fallback CLI.
+This file only applies to explicit backend fallback workflows.
 
 The canonical `/audit-code` conversation route should not require users to touch it.
 
+It does not define who owns semantic review in the canonical conversation flow, and it is not enough by itself to transfer semantic review away from the active conversation agent.
+
+In the intended product workflow, the active conversation agent owns review tasks and any subagent fan-out.
+Use this file only when you intentionally need backend fallback behavior or an explicit compatibility bridge.
+
 Backend provider configuration lives at:
 
 ```text
@@ -35,8 +40,7 @@ audit-code validate
   "provider": "local-subprocess",
   "timeout_ms": 1800000,
   "ui_mode": "headless",
-  "agent_task_batch_size": 4,
-  "parallel_workers": 2
+  "agent_task_batch_size": 1
 }
 ```
 
@@ -51,6 +55,12 @@ Supported values:
 - `opencode`
 - `vscode-task`
 
+Current implementation note:
+
+- `claude-code`, `opencode`, `subprocess-template`, and `vscode-task` are backend compatibility bridges
+- they are not the intended default owner of semantic review when the active conversation agent can handle the work directly
+- to activate one of those bridges for semantic review, re-run the wrapper with an explicit `--provider <name>` flag
+
 ### `timeout_ms`
 
 Worker-run timeout in milliseconds.
@@ -70,10 +80,16 @@ 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.
 
+The intended default review granularity remains one review block per task.
+
 ### `parallel_workers`
 
 How many provider-assisted review batches to launch in parallel when the selected provider supports it.
 
+This setting only applies to explicit backend bridge launches.
+
+It should not be treated as the source of truth for in-conversation subagent parallelism, which belongs to the active conversation agent or host runtime.
+
 ## Auto provider mode
 
 `auto` is an explicit opt-in mode.
@@ -98,6 +114,8 @@ 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.
 
+This remains the safest fallback default while the semantic-review workflow is being realigned.
+
 ### `claude_code`
 
 ```json
@@ -116,7 +134,9 @@ 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.
+Current implementation support only.
+
+Use this only when you intentionally want the backend fallback CLI to bridge review into an external Claude Code process, together with `audit-code --provider claude-code`.
 
 ### `opencode`
 
@@ -136,7 +156,9 @@ 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.
+Current implementation support only.
+
+Use this only when you intentionally want the backend fallback CLI to bridge review into an external OpenCode process, together with `audit-code --provider opencode`.
 
 ### `subprocess_template`
 
@@ -157,6 +179,7 @@ Fields:
 - `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`.
+Activate it explicitly with `audit-code --provider subprocess-template`.
 
 ### `vscode_task`
 
@@ -172,6 +195,7 @@ When you use this bridge for provider-assisted review, the launched process shou
 ```
 
 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.
+Activate it explicitly with `audit-code --provider vscode-task`.
 
 ## Template placeholders
 
@@ -215,6 +239,9 @@ This adapter is intentionally thin. It uses the same template expansion model as
 }
 ```
 
+Use this only when you intentionally want backend fallback routing.
+It is not the canonical semantic-review path.
+
 ### Delegate worker runs into Claude Code
 
 ```json
@@ -224,6 +251,12 @@ This adapter is intentionally thin. It uses the same template expansion model as
 }
 ```
 
+Then start the backend bridge explicitly:
+
+```bash
+audit-code --provider claude-code
+```
+
 ### Delegate worker runs into OpenCode
 
 ```json
@@ -233,6 +266,12 @@ This adapter is intentionally thin. It uses the same template expansion model as
 }
 ```
 
+Then start the backend bridge explicitly:
+
+```bash
+audit-code --provider opencode
+```
+
 ### Use a generic bash launcher bridge
 
 ```json
@@ -245,6 +284,12 @@ This adapter is intentionally thin. It uses the same template expansion model as
 }
 ```
 
+Then start the backend bridge explicitly:
+
+```bash
+audit-code --provider subprocess-template
+```
+
 ## Antigravity note
 
 A dedicated Antigravity adapter is not currently shipped.

package/docs/supervisor.md

@@ -6,6 +6,9 @@ The primary product contract is `/audit-code` in conversation.
 
 Everything here is fallback and implementation detail guidance for the repo-local backend surface.
 
+In the intended workflow, the active conversation agent owns semantic review.
+Provider adapters are compatibility bridges for backend fallback mode, not the default review owner.
+
 ## Repo-local backend surface
 
 From the target repository root:
@@ -55,6 +58,9 @@ audit-code --provider subprocess-template
 audit-code --provider vscode-task
 ```
 
+Those `--provider` invocations are the explicit bridge handoff point.
+Without an explicit `--provider` flag, the backend keeps semantic review with the active conversation agent and uses `local-subprocess` only for deterministic worker steps.
+
 ## Auto resolution rule
 
 When `provider` is set to `auto`, the backend resolves in this order:
@@ -81,3 +87,4 @@ See:
 ## Note
 
 Provider adapters are backend integrations, not the primary product concept.
+Session config defines bridge settings, but the explicit `--provider` flag is what opts the backend into owning semantic-review dispatch.

package/docs/workflow-refactor-brief.md

@@ -0,0 +1,177 @@
+# Workflow Refactor Brief
+
+This document is the handoff for the next context window.
+
+Use it as the source of truth for the workflow refactor before running a fresh audit again.
+
+## Why this refactor is needed
+
+The current implementation still advances deterministic audit state correctly, but the semantic-review phase has drifted away from the intended product behavior.
+
+The key symptom is that the backend can currently treat `provider` selection as the owner of review work, which is how the recent rerun ended up trying to use `claude-code` from `.audit-artifacts/session-config.json`.
+
+That is not the intended workflow.
+
+## Intended workflow
+
+The intended `/audit-code` workflow is:
+
+1. The active conversation agent owns semantic review work.
+2. Deterministic planning computes which files need which lenses.
+3. Pending review is partitioned into non-overlapping review blocks, preferably grouped by lens.
+4. One dispatched review task should correspond to one review block.
+5. `agent_task_batch_size` should stay `1` by default.
+6. If the active conversation agent can delegate to subagents in parallel, that fan-out belongs to the host agent runtime, not to the backend session config.
+7. Backend provider adapters are fallback compatibility bridges only. They should not be the default review owner.
+
+## Current implementation drift
+
+The current code differs from that model in several important ways.
+
+### 1. Review ownership is provider-mediated
+
+Today, the `agent` executor in the backend fallback path is still routed through `createFreshSessionProvider()` and may spawn an external CLI such as `claude` or `opencode`.
+
+Relevant files:
+
+- [src/cli.ts](/C:/Code/auditor-lambda/src/cli.ts:771)
+- [src/providers/index.ts](/C:/Code/auditor-lambda/src/providers/index.ts:37)
+- [src/providers/claudeCodeProvider.ts](/C:/Code/auditor-lambda/src/providers/claudeCodeProvider.ts:12)
+- [src/providers/opencodeProvider.ts](/C:/Code/auditor-lambda/src/providers/opencodeProvider.ts)
+- [src/providers/spawnLoggedCommand.ts](/C:/Code/auditor-lambda/src/providers/spawnLoggedCommand.ts:24)
+
+### 2. Task planning is unit-first, not lens-first
+
+`buildChunkedAuditTasks()` currently creates tasks as `unit x lens`, then optionally splits oversized files into separate per-lens tasks.
+
+Relevant files:
+
+- [src/orchestrator/taskBuilder.ts](/C:/Code/auditor-lambda/src/orchestrator/taskBuilder.ts:101)
+- [src/orchestrator/unitBuilder.ts](/C:/Code/auditor-lambda/src/orchestrator/unitBuilder.ts:130)
+
+### 3. Required lenses are unioned at the unit level
+
+The planner derives `required_lenses` for a unit, then applies that whole union to every file in the unit.
+
+That means the task count grows with `units x required_lenses`, not with a deliberately partitioned set of file/lens review blocks.
+
+Relevant files:
+
+- [src/orchestrator/unitBuilder.ts](/C:/Code/auditor-lambda/src/orchestrator/unitBuilder.ts:153)
+- [src/orchestrator/planning.ts](/C:/Code/auditor-lambda/src/orchestrator/planning.ts:63)
+- [src/coverage.ts](/C:/Code/auditor-lambda/src/coverage.ts:29)
+
+### 4. Flow augmentation adds overlapping review tasks
+
+After the base unit tasks are built, the planner adds extra flow-aware tasks rather than repartitioning the pending review set into one global non-overlapping dispatch plan.
+
+Relevant file:
+
+- [src/orchestrator/flowPlanning.ts](/C:/Code/auditor-lambda/src/orchestrator/flowPlanning.ts:9)
+
+### 5. `parallel_workers` means subprocess fan-out, not agent-owned parallelism
+
+The current `parallel_workers` setting only controls how many external provider worker runs the backend fallback CLI launches.
+
+It does not represent, and should not limit, the active conversation agent's own ability to use subagents.
+
+Relevant files:
+
+- [src/cli.ts](/C:/Code/auditor-lambda/src/cli.ts:83)
+- [src/cli.ts](/C:/Code/auditor-lambda/src/cli.ts:960)
+
+## Evidence from the current stale audit
+
+The current stale audit run produced:
+
+- `91` units
+- average `3.26` required lenses per unit
+- `333` audit tasks total
+- `294` regular unit-lens tasks
+- `10` large-file split tasks
+- `29` flow tasks
+
+That fan-out is consistent with the current unit-first planner, not with the intended lens-block dispatch model.
+
+## Refactor goals
+
+The next implementation pass should do the following.
+
+### A. Make the active conversation agent the semantic-review owner
+
+The `agent` executor should represent review work owned by the current conversation or host agent session.
+
+Target behavior:
+
+- normal `/audit-code` usage does not require `provider: "claude-code"` or `provider: "opencode"`
+- session-config should not be the normal way to choose a second LLM for review
+- backend provider bridges remain available only for explicit fallback workflows
+
+### B. Plan review work at the file/lens level
+
+Coverage should still know which files require which lenses, but dispatch planning should work from unresolved `(file, lens)` obligations rather than from unit-wide lens unions.
+
+Target behavior:
+
+- each review block should have explicit `file_paths`
+- each review block should represent one lens
+- review blocks in the same dispatch wave should be file-disjoint unless overlap is intentionally justified
+
+### C. Partition pending review into non-overlapping blocks
+
+Replace the current unit-first task planner with a lens-aware block planner.
+
+Target behavior:
+
+- no combinatorial `unit x lens` explosion unless that is genuinely the smallest valid partition
+- large-file splitting may remain, but it should happen inside the lens-block planner
+- critical-flow context should influence block construction without blindly adding overlapping tasks on top
+
+### D. Keep result ingestion deterministic
+
+The current ingestion model is mostly sound and should be preserved.
+
+Relevant files:
+
+- [src/orchestrator/resultIngestion.ts](/C:/Code/auditor-lambda/src/orchestrator/resultIngestion.ts)
+- [src/coverage.ts](/C:/Code/auditor-lambda/src/coverage.ts:42)
+
+### E. Reframe session-config as backend fallback only
+
+`session-config.json` should continue to configure backend fallback bridges, but it should not be treated as the owner of semantic-review orchestration in the canonical workflow.
+
+`parallel_workers` should either:
+
+- become a legacy fallback-only knob, or
+- be removed from the semantic-review mental model entirely
+
+## Acceptance criteria
+
+The refactor should be treated as done only when all of the following are true.
+
+- Starting `/audit-code` in a conversation does not rely on an external `claude-code` or `opencode` subprocess to own semantic review.
+- The backend fallback still supports deterministic stages and explicit compatibility bridges.
+- The default dispatch granularity for semantic review remains one review block per task.
+- Pending review tasks are planned as lens-aware, non-overlapping file blocks.
+- `parallel_workers` no longer defines the default semantic-review parallelism model.
+- The next fresh audit can be run from a clean slate without inheriting the current stale provider-mediated task queue.
+
+## Suggested implementation order
+
+1. Refactor the review-ownership model in [src/cli.ts](/C:/Code/auditor-lambda/src/cli.ts), [src/providers/index.ts](/C:/Code/auditor-lambda/src/providers/index.ts), and related supervisor docs.
+2. Replace the current task planner in [src/orchestrator/taskBuilder.ts](/C:/Code/auditor-lambda/src/orchestrator/taskBuilder.ts) with a lens-block planner.
+3. Rework flow-aware planning in [src/orchestrator/flowPlanning.ts](/C:/Code/auditor-lambda/src/orchestrator/flowPlanning.ts) so it participates in block construction instead of layering overlapping tasks afterward.
+4. Update docs and tests.
+5. Delete the stale audit state and rerun the audit from scratch.
+
+## Clean rerun after refactor
+
+Once the refactor is in place, the next context should:
+
+1. keep the source changes and documentation already in the worktree
+2. delete `.audit-artifacts/`
+3. delete `audit-report.md`
+4. run the workflow again from a clean state
+5. treat the new audit output as authoritative
+
+For the remediation baseline that should survive the stale audit reset, see [docs/remediation-baseline.md](/C:/Code/auditor-lambda/docs/remediation-baseline.md).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "auditor-lambda",
-  "version": "0.2.6",
+  "version": "0.2.9",
   "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": {
@@ -20,19 +20,20 @@
     "task_id": { "type": "string" },
     "unit_id": { "type": "string" },
     "pass_id": { "type": "string" },
-    "lens": { "type": "string" },
+    "lens": {
+      "type": "string",
+      "enum": ["correctness", "architecture", "maintainability", "security", "reliability", "performance", "data_integrity", "tests", "operability", "config_deployment"]
+    },
     "agent_role": { "type": "string" },
-    "reviewed_ranges": {
+    "file_coverage": {
       "type": "array",
       "minItems": 1,
       "items": {
         "type": "object",
-        "required": ["path", "start", "end", "line_count"],
+        "required": ["path", "total_lines"],
         "properties": {
           "path": { "type": "string" },
-          "start": { "type": "integer" },
-          "end": { "type": "integer" },
-          "line_count": { "type": "integer", "minimum": 1 }
+          "total_lines": { "type": "integer", "minimum": 1 }
         },
         "additionalProperties": false
       }

package/schemas/audit_task.schema.json

@@ -21,6 +21,7 @@
     },
     "file_paths": {
       "type": "array",
+      "minItems": 1,
       "items": { "type": "string" }
     },
     "line_ranges": {
@@ -44,7 +45,7 @@
         "mechanical_results_ref": { "type": "string" },
         "risk_register_ref": { "type": "string" }
       },
-      "additionalProperties": true
+      "additionalProperties": { "type": "string" }
     },
     "rationale": { "type": "string" },
     "priority": {
@@ -53,6 +54,7 @@
     },
     "tags": {
       "type": "array",
+      "minItems": 1,
       "items": { "type": "string" }
     },
     "status": {