Triage Explainability Workspace

Status

The artifact detail shell shipped on 2026-03-07. The STI-4 server-truth cutover is shipped and live verified at exact commit 7eca7b4229 and console image sha256:6fda0c72117d....

Live verification: STI-4 evidence.

• Live queue owner: Open Work, reached contextually from Security > Exposure.
• Queue URL: /triage/artifacts.
• Compatibility URL: /security/exposure?lens=open-work forwards legacy lens bookmarks to the owner route while preserving unrelated query parameters and the fragment.
• Detail URL: /triage/artifacts/:artifactId, where :artifactId is the immutable OCI digest returned by Findings (for example, sha256:...).
• Audit bundles: /evidence/bundles and /evidence/bundles/new are canonical; /triage/audit-bundles and /triage/audit-bundles/new remain compatibility redirects.

Verification note for the original shell: docs/features/checked/web/triage-explainability-workspace-ui.md.

Authoritative Read Contract

Queue and detail use one Findings-owned projection and immutable digest identity:

• GET /api/v2/security/artifact-triage?limit=<n>&cursor=<token>
• GET /api/v2/security/artifact-triage/detail?digest=<sha256>

The Web client does not aggregate the vulnerability catalog, infer environment or artifact type from names, derive scan success from advisory timestamps, or derive attestation counts from finding disposition. Queue and detail format the same server fields through shared view helpers.

The projection carries:

• current deployed-estate entries: environmentId, releaseId, deploymentId, estateStatus, deployedAt, and updatedAt;
• scan truth: readiness, freshnessWindowDays, latestAttemptId, latestAttemptStatus, latestAttemptAt, and lastSuccessfulScanAt;
• finding totals: total plus critical, high, medium, low, unknown, reachable, and actionable counts;
• evidence truth: recorded status, exact evidence-kind count, kinds, score, and update time;
• attestation truth: recorded status and exact count;
• workflow truth: unsupported / none / null / no_persisted_workflow_state.

Missing counts remain not recorded or count unavailable. They are never rendered as zero. A failed latest attempt remains separate from durable successful scan readiness.

Queue Behavior

The Open Work page is a read-only, server-cursor table using the canonical stella-table external pager.

• Rows open detail by the exact digest, never a display name or mutable tag.
• Pagination uses the server nextCursor; no current-page search, sort, or filter pretends to cover the whole tenant result set.
• Loading renders table skeletons.
• A successful zero-row response renders the educational empty state.
• A failed read clears previously rendered rows and shows a retryable error rather than showing stale rows beside an empty or error message.
• The table owns any horizontal scrolling on narrow viewports; the page itself must not overflow at 375px or 1080px.

Detail Behavior

The detail page validates that the projector response digest canonically equals the route digest before rendering.

• The summary shows projection currency, current deployment identities and times, attempt-versus-success scan truth, all finding tiers, evidence kinds/count/score, attestation count, and unsupported workflow state.
• Human-readable dates are primary; a collapsed technical disclosure preserves the exact ISO values for support and audit work.
• Create immutable audit bundle stays disabled until the digest projection loads.
• A failed or mismatched detail read fails closed and exposes retry plus technical detail.

Workflow Boundary

Browser-local lanes are retired from the production queue and detail path.

• No lane=active|quiet|review route state is consumed.
• No localStorage lane key, lane filter, move action, assignment, or TTL action is presented as shared workflow state.
• The single queue notice says workflow is not configured because no persisted workflow state exists. There is no repeated Workflow table column.

If a future server contract publishes persisted workflow state, adoption requires a new sprint task, typed client contract, tests, and live proof. The browser must not recreate shared workflow locally.

Per-Finding Limitation

FET-4 publishes aggregate artifact truth but does not publish authoritative per-finding IDs in the artifact projection. Therefore STI-4 deliberately does not join the global vulnerability list through component aliases or pass the digest to a Scanner per-finding endpoint as if it were a finding ID.

Until a persisted cross-service finding-ID bridge exists:

• aggregate artifact detail is available;
• per-finding decision, VEX, evidence, reachability, replay, and bulk-action panels stay unavailable from this route;
• the page explains the cause and links operators to Exposure findings or Scanner operations for recovery.

This limitation is a follow-up product/contract risk, not a client-side inference opportunity.

Source Inputs

• docs/UI_GUIDE.md
• docs-archive/implplan/SPRINT_20260711_004_Scanner_triage_and_image_truth_cutover.md
• src/Findings/StellaOps.Findings.Security.WebService/Services/ArtifactTriageService.cs
• src/Web/StellaOps.Web/src/app/core/api/artifact-triage.client.ts
• src/Web/StellaOps.Web/src/app/features/exposure/exposure-destination.component.ts
• src/Web/StellaOps.Web/src/app/features/triage/triage-artifacts.component.ts
• src/Web/StellaOps.Web/src/app/features/triage/triage-workspace.component.ts
• src/Web/StellaOps.Web/src/app/routes/triage.routes.ts