Findings inbox and remediation

Audience: operators, compliance reviewers, and integrators
Status: shipped — master–detail Findings Inbox, URL-synced triage filters, inline remediation stepper, and Remediation Workbench execution cockpit.

Strategy: future-vision.md · Architecture: overview.md

Operational queue (shared)

Cases (/cases), Findings Inbox, Remediation Workbench, and Audit Room share the same operational queue chrome:

Each surface adds its own slice filter param (filter or triage), scope params (processId, workspaceId, findingId), and selected for the master–detail panel.

Example: /cases?filter=sla_risk&q=vendor&page=2&selected=<caseId>

Findings Inbox

The Findings Inbox (/findings) is the primary triage surface for scanner output. It uses a master–detail layout:

URL parameters

Query params are the source of truth for inbox state (deep-linkable and shareable). Shared queue params: q, page, pageSize (see Operational queue above).

Example: /findings?triage=missing_evidence&selected=<findingId>

When selected is absent or invalid, the inbox auto-selects the highest-priority finding in the filtered list and writes selected back to the URL.

Bulk triage

Select multiple findings with row checkboxes, then use the bulk action bar:

The API returns { data, results } where each results[] entry reports ok or error for that finding id.

Inline remediation stepper

From the detail panel, operators can close the accountability loop without leaving the inbox:

1. Acknowledge     → POST /platform/findings/:id/transition { status: "acknowledged" }
2. Start remediation → POST /platform/remediations (+ transition to remediating when applicable)
3. Attach proof    → navigate to Evidence Center for linked case/process
4. Complete & resolve → PATCH /platform/remediations/:id { status: "completed", completionEvidenceId }
                     → POST /platform/findings/:id/transition { status: "resolved" }

Remediation create payloads are derived from finding metadata (finding.remediation YAML hints) and scanner context — not from model output.

Remediation Workbench

Remediation Workbench (/remediation) is the execution cockpit for open remediation actions. It mirrors the Findings Inbox master–detail pattern:

URL parameters

Shared queue params: q, page, pageSize (see Operational queue above).

Legacy deep links using remediationId= still parse into selected.

Example: /remediation?filter=needs_proof&selected=<remediationId>

When selected is absent or invalid, the workbench auto-selects the highest-priority action in the filtered list and writes selected back to the URL. When no filter is set, the default queue shows in progress actions.

Operators can execute the full accountability loop (acknowledge → start → attach proof → complete/resolve) from the workbench detail panel without returning to the Findings Inbox. Each row still links back to the finding via View finding in inbox when cross-surface context is needed.

API surfaces

OpenAPI and generated SDKs use finding and remediation vocabulary (not legacy issue terminology).

Findings inbox triage

The findings queue supports slice filters via the triage query param:

Example: /findings?triage=since_last_scan&processId=<processId>

Tests

• Unit: apps/web/tests/findings-inbox-filters.test.ts, scanner-run-triage.test.ts, findings-bulk-selection.test.ts; apps/api/tests/services/event-scanner-platform.test.ts (bulk actions)
• Route: apps/api/tests/routes/platform-findings-bulk.test.ts
• E2E: e2e/tests/findings-inbox.spec.ts (bulk acknowledge)

Operational Cases queue

Operational Cases (/cases) uses the same queue chrome with case-specific slice filters:

Example: /cases?filter=has_findings&q=vendor&sort=priority&selected=<caseId>