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>
This commit is contained in:
2026-06-02 16:24:49 +02:00
parent 38835e9e79
commit 7aa64fab41

View File

@@ -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.