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

Following the CUST-WP-0045 daily-triage cutover, the activity-core
runner now writes a daily progress event with the full WSJF report
nested under detail.report. The only ways to read it today are tail
the working-memory file or curl /progress/ — neither serves the
"sit-down review" use case the triage was designed for.

Proposed dashboard page under the existing Workstreams section:
recent reports table, per-report detail with linked recommendations,
14-day pattern view, action colour cues consistent with the rest of
the dashboard. Read-only; no schema or API changes; reuses the
existing /progress/?event_type=daily_triage endpoint.

Six tasks (T01 skeleton + nav, T02 recent table, T03 detail with
links, T04 colour cues, T05 pattern view, T06 docs). Status:
proposed — awaiting review before workstream registration.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

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

@@ -0,0 +1,308 @@
+---
+id: STATE-WP-0053
+type: workplan
+title: "WSJF Triage Review Page (Workstreams section)"
+domain: custodian
+repo: state-hub
+status: proposed
+owner: custodian
+topic_slug: custodian
+created: "2026-06-02"
+updated: "2026-06-02"
+---
+
+# 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](/workstreams/d9d9a3ec…) | `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):
+
+```json
+{
+  "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
+
+```task
+id: STATE-WP-0053-T01
+status: todo
+priority: medium
+```
+
+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
+
+```task
+id: STATE-WP-0053-T02
+status: todo
+priority: medium
+depends_on: [STATE-WP-0053-T01]
+```
+
+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
+
+```task
+id: STATE-WP-0053-T03
+status: todo
+priority: medium
+depends_on: [STATE-WP-0053-T02]
+```
+
+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
+
+```task
+id: STATE-WP-0053-T04
+status: todo
+priority: low
+depends_on: [STATE-WP-0053-T03]
+```
+
+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
+
+```task
+id: STATE-WP-0053-T05
+status: todo
+priority: medium
+depends_on: [STATE-WP-0053-T02]
+```
+
+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
+
+```task
+id: STATE-WP-0053-T06
+status: todo
+priority: low
+depends_on: [STATE-WP-0053-T05]
+```
+
+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.