Overview shows workstreams by repo now and allows drilldown

This commit is contained in:
2026-05-02 12:01:45 +02:00
parent e521f267ca
commit e0f6a3b7a9
5 changed files with 260 additions and 43 deletions

View File

@@ -12,10 +12,10 @@ blocking decisions, and system-derived next-step suggestions.
## Sections
### Open Workstreams by Domain
### Open Workstreams by Repository
A horizontal stacked bar chart showing every active workstream across all six
domains. Each bar is broken into four task-status segments:
A horizontal stacked bar chart showing workstreams grouped by domain and then
by repository. Each bar is broken into four task-status segments:
| Colour | Segment |
|--------|---------|
@@ -24,9 +24,13 @@ domains. Each bar is broken into four task-status segments:
| orange-red | blocked |
| light grey | todo |
The left axis shows domain labels (one per group of workstreams). The `done/total`
count is printed to the right of each bar. Workstreams with no tasks yet show
a grey "— no tasks yet" label.
The left axis shows the `domain / repository` label once per repository group.
The `done/total` count is printed to the right of each bar. Workstreams with no
tasks yet show a grey "— no tasks yet" label.
Hovering a bar shows the repository, domain, and backing workplan filename when
the workstream is file-backed. Clicking a bar or its label opens the workstream
drilldown page with the attached task list.
### Contribution & SBOM Health
@@ -78,7 +82,9 @@ and summary.
## Data source
Polls `GET /state/summary` every **15 seconds**. Blocking decisions are fetched
separately via `GET /decisions/?decision_type=pending` and only re-fetched
after a successful resolve action — this prevents the inline form from being
wiped on every poll.
Polls `GET /state/summary` every **15 seconds**. The workstream chart also polls
`GET /workstreams/`, `GET /tasks/?limit=2000`, `GET /topics/`, `GET /repos/`,
and `GET /workstreams/workplan-index` for repository grouping, task counts, and
workplan filename tooltips. Blocking decisions are fetched separately via
`GET /decisions/?decision_type=pending` and only re-fetched after a successful
resolve action — this prevents the inline form from being wiped on every poll.