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

---
id: STATE-WP-0053
type: workplan
title: "WSJF Triage Review Page (Workstreams section)"
domain: custodian
repo: state-hub
status: finished
owner: custodian
topic_slug: custodian
created: "2026-06-02"
updated: "2026-06-03"
state_hub_workstream_id: "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](/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: 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

```task
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

```task
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

```task
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

```task
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

```task
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.