Organization Dashboard decision trace

Traceability

• Spec ID: 2026-09-02-organization-dashboard-decision-trace
• Status: Draft
• Extends: 2026-09-01-organization-harness-dashboard, 2026-09-02-organization-dashboard-evidence-depth

Intent

Turn the current workspace usage Dashboard into a decision-first organization Harness proof of concept without inventing policy, cost, ownership, or outcome facts that the collectors do not emit. The first screen should answer what accepted task evidence exists, where evidence is incomplete, which configured assets have observed or task-linked activity, and how a selected task connects intent, assets, validation observations, and its receipt.

Usage, token, context, and model charts remain available as engineering diagnostics, but they no longer lead the organization view or compete with task and delivery evidence.

Acceptance Scenarios

• AC-1 — Decision evidence leads: the page opens with task receipt, acceptance, task-linked asset outcome, and evidence-gap facts derived from accepted packets and collection errors. When no accepted packet exists, the page reports that evidence as unavailable rather than showing a zero-success organization state.
• AC-2 — Asset evidence classes stay separate: Skills, MCPs, and Hooks show distinct configured assets and configured Host instances. Observed Skill invocations and Host hook events are labelled as activity, while task-linked outcomes come only from accepted task packets. The page never presents these different populations as one conversion funnel.
• AC-3 — One task can be traced: accepted task packets retain their intent, scope, non-goals, acceptance rows, asset rows, observations, receipt state, organization, and digest in the Dashboard model. A keyboard-operable task selector opens one bounded trace from intent through assets and observations to receipt evidence.
• AC-4 — Diagnostics are secondary but preserved: session overview, activity, Skill, Token, Context, and Model sections remain available behind one labelled disclosure that is collapsed by default. Delivery behavior, repository outcomes, and per-Host comparison remain visible organization evidence.
• AC-5 — Responsive decision hierarchy: at 1440x900 the primary task or missing-task decision is visible without scrolling past charts. At 390x844 the decision facts and task trace stack without page-level horizontal overflow; the Host table retains bounded internal scrolling. Focus is visible on the task selector and diagnostics disclosure, with no browser/page errors.
• AC-6 — Existing collection boundaries remain honest: the change consumes the current local collector and versioned task packet without moving raw prompts, transcripts, tool inputs/outputs, credentials, absolute paths, or private evidence refs into the browser model.

Non-goals

• No remote multi-repository ingestion, authentication, RBAC, team directory, policy engine, SLO registry, chargeback, or exact-cost implementation.
• No organization maturity score, readiness grade, asset effectiveness score, or inference that an observed invocation caused a task outcome.
• No replacement of capability-owned agent-customize, session-analysis, project-harness, commit, topology, or task-evidence collectors with a UI monolith.
• No Harness Studio navigation or workbench redesign in this slice. Shared collector/catalog consolidation remains a follow-up contract migration.
• No release, package-version, changelog, publication, or deployment change.

Plan and Tasks

1. Extend the Dashboard packet projection so accepted task detail remains available to a browser-safe model rather than being reduced to coverage counts.
2. Add aggregate decision facts and per-kind asset evidence rows derived only from existing packet, inventory, activity, and collection fields.
3. Reorder the page into decision evidence, asset evidence, task trace, delivery/repository/Host comparison, and collapsed engineering diagnostics.
4. Add accessible task selection and diagnostics disclosure interactions, plus compact responsive styles that preserve existing chart and table bounds.
5. Update model, upload-chain, and browser tests, then verify typecheck, focused tests, production build, wide/compact/narrow screenshots, console errors, and the staged/unstaged review boundary.

Test and Review Evidence

• AC-1, AC-2, AC-3, AC-6: npm test -w @qoder-ai/harness-ui; model tests must cover no-packet, passed/failed/unobserved counts, task detail retention, task-linked Skill/MCP outcomes, and the absence of private evidence fields.
• AC-3, AC-4: the browser fixture prepared and applied through the real upload CLI must expose TASK-42, its acceptance rows, Skill and MCP evidence, validation/human-review observations, organization, and digest. Diagnostics must be absent before disclosure and visible after activation.
• AC-5: run the Dashboard browser test at 1440x900, 1024x768, and 390x844; inspect screenshots, page overflow, Host-table overflow, focus, console/page errors, and the primary decision position.
• Run npm run typecheck -w @qoder-ai/harness-ui and npm run build -w @qoder-ai/harness-ui.
• Run git diff --check and a Review Readiness Check before changing this spec to Implemented.

Risk review must reject aggregate labels that imply causation, organization coverage, policy compliance, or exact cost. Accepted packet detail remains bounded and sanitized by the task-evidence contract; the browser model must not add raw stored-record metadata or absolute evidence paths.