state-hub/workplans/STATE-WP-0053-wsjf-triage-review-page.md

id, type, title, domain, repo, status, owner, topic_slug, created, updated, state_hub_workstream_id

id	type	title	domain	repo	status	owner	topic_slug	created	updated	state_hub_workstream_id
STATE-WP-0053	workplan	WSJF Triage Review Page (Workstreams section)	custodian	state-hub	finished	custodian	custodian	2026-06-02	2026-06-03	0cca23a9-9640-491a-92db-6414db891019

STATE-WP-0053 - WSJF Triage Review Page (Workstreams section)

Goal

Add a dashboard page that lets the operator review the daily WSJF triage reports produced by activity-core's daily-triage-report instruction, find the latest recommendations per workstream, and notice patterns across days without re-running the prompt.

Surface lives under the existing Workstreams dashboard section, sibling to Decisions / Dependencies / Tasks / Interventions. No schema or API changes — the data already exists in /progress/?event_type=daily_triage with the full report nested under detail.report (proven by the 2026-06-02 CUST-WP-0045 canary).

Context

CUST-WP-0045 cutover landed activity-core as the daily WSJF triage runner. Each run leaves:

• a working-memory note at the-custodian/memory/working/daily-triage-{date}-{run_id_short}.md
• a State Hub progress event with event_type: daily_triage carrying detail.report = {summary, recommendations[]}

Today the only ways to read those reports are: SSH-tail the memory file or curl /progress/ and pipe through jq. Neither serves the "operator sits down with morning coffee" use case the triage was designed for. State Hub's dashboard is where most other operational state already gets reviewed (/workstreams, /decisions, /interventions); the WSJF report belongs there too.

Scope

In scope:

• New page dashboard/src/wsjf-triage.md rendering the most recent N daily triage reports, with the latest one expanded by default.
• Nav entry "WSJF Triage" under the existing Workstreams section in observablehq.config.js.
• Recommendation rows that resolve candidate (slug) to a workstream id and link to the existing /workstreams/{id} detail page where the resolution succeeds.
• Lightweight pattern view: per-workstream count of how often it has been recommended in the last 14 days, grouped by action.
• Empty-state copy when no daily_triage events exist yet (so the page ships before tomorrow's first scheduled run).

Out of scope:

• Any write surface (no "apply recommendation" buttons, no status changes). The triage is a read model; acting on it stays a human or workplan-driven step.
• Schema or API changes to /progress/. The page reads the existing payload as-is.
• Cross-domain triage support (multi-domain digest). The current runner produces one custodian-domain report per day; design the page for that shape and broaden later if other domains adopt the pattern.
• Authoring or editing reports from the dashboard. The activity-core runner is the only writer; the page is read-only.

Page Design

Header

• Title: "Daily WSJF Triage"
• Subtitle: "Daily State Hub triage from activity-core. Recommendations are advisory; the operator and workplan owners decide what to act on."
• Last-updated badge: timestamp of the most recent daily_triage event.

Recent Reports

Top section: list of the last 14 reports as a compact table.

Date	Summary (first 120 chars)	# Recs	Top Action
2026-06-02	13 active workstreams with 58 open tasks. High-priority triage items need ...	9	work-next×3

Rows are click-to-expand: clicking a row scrolls/expands the detail section below to that report. Default expansion is the most recent report.

Detail Section

For the selected report:

• Summary: full detail.report.summary text.

• Recommendations table:

  #	Candidate	Action	Confidence	Why
  1	cust-wp-0045	work-next	high	Daily triage runner infrastructure — critical dependency …

  Action column uses colour cues consistent with the existing dashboard:

  • work-next — green
  • close-out — green
  • revisit / split — amber
  • park — grey
  • needs-human / needs-cross-agent / needs-consistency-sync — red

• Run metadata: scheduled_for, activity_core_run_id, instruction_id, link to the working-memory note path (display only, not fetched — the path lives in the-custodian, dashboard is read-only).

Patterns (14-day window)

Bottom section: aggregate view of which workstreams appear most often and with which actions, computed client-side from the events already loaded.

Workstream	Times Recommended	Most Frequent Action
cust-wp-0045	12 / 14 days	work-next (10×)

Useful for spotting recurring needs-human flags that aren't getting addressed, and for noticing a workstream that's been revisit for many days running.

Empty State

Visible until the first scheduled run lands. Copy:

No daily triage reports yet. The next run is scheduled for 07:20 Europe/Berlin (activity-core daily-statehub-wsjf-triage).

Data Source

Single API call on page load:

GET /progress/?event_type=daily_triage&limit=14

Response shape (already produced by the 2026-06-02 canary):

{
  "id": "935244fa-…",
  "topic_id": "cee7bedf-…",
  "workstream_id": "99993845-…",
  "event_type": "daily_triage",
  "summary": "13 active workstreams with 58 open tasks. …",
  "detail": {
    "report": {
      "summary": "…",
      "recommendations": [
        {"candidate": "cust-wp-0045", "action": "work-next",
         "why": "…", "confidence": "high"},
        …
      ]
    },
    "activity_id": "6fca51fa-…",
    "scheduled_for": "2026-06-02T12:52:01.690214+00:00",
    "instruction_id": "daily-triage-report",
    "activity_core_run_id": "f9b97749-…"
  },
  "author": "activity-core",
  "created_at": "2026-06-02T12:52:14.460214Z"
}

Candidate → workstream id resolution uses the existing /workstreams/workplan-index endpoint (already used elsewhere on the dashboard); fall back to plain text if the slug is not indexed.

Tasks

T01 - Page skeleton and nav entry

id: STATE-WP-0053-T01
status: done
priority: medium
state_hub_task_id: "6d33aeed-03d2-4a04-95f4-d28fe35e22c7"

Create dashboard/src/wsjf-triage.md rendering the header + empty state. Add { name: "WSJF Triage", path: "/wsjf-triage" } to the Workstreams pages list in observablehq.config.js.

Done when the page is reachable from the sidebar and shows the empty state in a dev preview.

T02 - Recent reports table

id: STATE-WP-0053-T02
status: done
priority: medium
depends_on: [STATE-WP-0053-T01]
state_hub_task_id: "b3e569df-861f-4a65-8aa5-b011547e1fdb"

Fetch up to 14 most recent daily_triage events and render the recent-reports table. Compute # Recs and Top Action per row client-side.

Done when today's canary report (and tomorrow's scheduled run) appears in the table, summary truncated to ~120 characters.

T03 - Detail section with linked recommendations

id: STATE-WP-0053-T03
status: done
priority: medium
depends_on: [STATE-WP-0053-T02]
state_hub_task_id: "fcbaca4d-3186-4192-aa79-a2ebb12074ed"

Expand selected report (default: most recent) to show full summary, recommendations table, and run metadata. Resolve each recommendation's candidate against /workstreams/workplan-index to produce a /workstreams/{id} link where possible.

Done when clicking a candidate slug navigates to the corresponding workstream detail page on the existing dashboard.

T04 - Action colour cues consistent with existing dashboard

id: STATE-WP-0053-T04
status: done
priority: low
depends_on: [STATE-WP-0053-T03]
state_hub_task_id: "45441829-6f01-4b53-8ca7-f4d6f644f77c"

Match the dashboard's existing colour palette (the same one used on /decisions for resolved/escalated and on /workstreams for active/blocked/finished). Add a small legend below the recommendations table.

Done when colour cues are visually consistent with neighbouring pages and the legend matches the action vocabulary documented in the-custodian/runtime/prompts/daily_statehub_wsgi_triage.md.

T05 - 14-day pattern view

id: STATE-WP-0053-T05
status: done
priority: medium
depends_on: [STATE-WP-0053-T02]
state_hub_task_id: "8403b3b5-9f37-4ae7-a141-6fc7afbe8053"

Aggregate the loaded 14-day window: count occurrences per candidate, compute the most frequent action per candidate, render the bottom table sorted by occurrence count desc.

Done when a workstream that has been recommended for needs-human on three or more days surfaces near the top of the pattern table.

T06 - Docs + reference cross-links

id: STATE-WP-0053-T06
status: done
priority: low
depends_on: [STATE-WP-0053-T05]
state_hub_task_id: "ce0abbbd-9418-4016-9679-3b3abe0efd6b"

Add a short src/docs/wsjf-triage.md explaining: what the triage is (reference to CUST-WP-0044), how to read recommendations, the action vocabulary, the "advisory not authoritative" stance. Wire withDocHelp from the dashboard page to that doc. Add link to Reference nav.

Cross-link from src/docs/workstreams.md and src/decisions.md to the new page so operators land there from the contexts where triage is most relevant.

Done when the dashboard doc system shows the WSJF doc and existing docs link forward to it.

Acceptance Criteria

• The page is reachable from the sidebar under Workstreams → WSJF Triage.
• Today's manual canary report (2026-06-02) and tomorrow's scheduled run (2026-06-03) both render correctly with linked candidates.
• The detail section shows summary, recommendations, and run metadata for any of the last 14 reports.
• The pattern table surfaces workstreams that have accumulated repeated recommendations within the window.
• No write surfaces; no schema or API changes; no cross-domain coupling beyond what already exists in the dashboard.

Notes

The data model is intentionally simple — one event per day, full report in detail.report. If multi-domain or per-workstream triage is added later, the schema can evolve under a different event_type (workstream_triage, domain_triage) and this page can either gain a filter or split into per-type tabs without breaking existing reports.

CUST-WP-0045's daily-triage report is the only producer today. Other producers (weekly review, incident postmortem, etc.) could write to the same event_type if their report shape matches {summary, recommendations[]}; nothing on this page assumes a particular activity definition produced the event.