Scanner Runtime Readiness Checklist

Last updated: 2025-10-19 · Audience: Runtime Guild, Notify Guild, and Scanner integrators

This runbook confirms that Scanner.WebService surfaces the metadata Runtime Guild consumers depend on: quieted finding counts in the signed report events, and progress hints on the scan event stream. Work through the checklist to validate these fields in a staging or sandbox environment before relying on them in production automation.

1. Prerequisites

• Scanner.WebService release includes SCANNER-POLICY-09-107 (adds quieted provenance and score inputs to POST /api/v1/reports).
• Docs repository at a commit containing docs/modules/signals/events/scanner.report.ready@1.json with the quietedFindingCount field.
• Access to a Scanner environment (staging or sandbox) with an image capable of producing policy verdicts.

2. Verify quieted finding hints

1. Trigger a report – run a scan that produces at least one quieted finding (policy with quiet: true). After the scan completes, call:

   POST /api/v1/reports
   Authorization: Bearer <token>
   Content-Type: application/json
   

   Ensure the JSON response contains report.summary.quieted and that the DSSE payload mirrors the same count.
2. Check emitted event – pull the latest scanner.report.ready event (from the queue or sample capture). Confirm the payload includes:
   • quietedFindingCount equal to the summary.quieted value.
   • Updated summary block with the quieted counter.
3. Schema validation – optionally validate the payload against docs/modules/signals/events/scanner.report.ready@1.json to guarantee downstream compatibility:

   npx ajv validate -c ajv-formats \
     -s docs/modules/signals/events/scanner.report.ready@1.json \
     -d <payload.json>
   

   (Use npm install --no-save ajv ajv-cli ajv-formats once per clone.)

Snapshot fixtures: see docs/modules/signals/events/samples/scanner.event.report.ready@1.sample.json for a canonical orchestrator event that already carries quietedFindingCount.

3. Verify progress hints (SSE / JSONL)

Scanner streams structured progress messages for each scan. The data map inside every frame carries the hints Runtime systems consume (force flag, client metadata, additional stage-specific attributes).

1. Submit a scan with custom metadata (for example pipeline=github, build=1234).
2. Stream events:

   GET /api/v1/scans/{scanId}/events?format=jsonl
   Authorization: Bearer <token>
   Accept: application/x-ndjson
   

3. Confirm payload – each frame should resemble:

   {
     "scanId": "2f6c17f9b3f548e2a28b9c412f4d63f8",
     "sequence": 1,
     "state": "Pending",
     "message": "queued",
     "timestamp": "2025-10-19T03:12:45.118Z",
     "correlationId": "2f6c17f9b3f548e2a28b9c412f4d63f8:0001",
     "data": {
       "force": false,
       "meta.pipeline": "github"
     }
   }
   

   Subsequent frames include additional hints as analyzers progress (e.g., stage, meta.*, or analyzer-provided keys). Ensure newline-delimited JSON consumers preserve the data dictionary when forwarding to runtime dashboards.

The streaming/NDJSON conventions are described in the API & CLI Reference. Reuse this frame structure in integration tests to keep downstream consumers compatible.

4. Sign-off matrix

Mark the stakeholder boxes as each team completes its validation. Once all checks are green, record completion in the owning sprint’s Delivery Tracker.