A dashboard summary should let a person scan the important numbers, changes, links and next decisions without reading an expanded prose report. The current title/body reporting model cannot provide that presentation reliably. Markdown tables and better wording help, but they do not give the publishing thread enough control over a card's composition.
The immediate example is a code-health coordinator: it needs counts, original/selected scores, PR and worker links, a short list of the largest improvements, and clear delivery states. Putting all of that in a prose summary card was not usable. Other coordinators will need different combinations of those elements.
Requested capability
Let threads design structured dashboard cards with React components and control over layout, using a documented, approved set of components and styles. A thread should be able to compose a concise metric grid, results table, status rows, links and relevant actions without implementing its own visual language or changing the shared dashboard page.
This belongs to the general dashboard feature, rather than a code-health-specific renderer.
Design considerations
- Provide reusable primitives and clear composition rules that match the existing design system: metrics, grids/stacks, tables/lists, status, links and actions. Support theme, accessibility and narrow layouts through those primitives.
- Define a straightforward authoring and publication API. Review how React card definitions are built, registered and updated, and how their data is supplied. The authoring model should remain understandable to agents and maintainers.
- Keep card ownership tied to its publishing thread/project/environment. Use existing thread-link routing and action permissions; a card should continue to make sense after its author stops running.
- Keep the shared page predictable. Card authors control their card's contents and layout; project navigation, attention queues and global controls remain dashboard responsibilities.
- Keep shell payloads, render cost and update behavior bounded. Separate reusable presentation assets from changing report data rather than repeatedly sending a whole implementation with each status update.
- Decide how the same card behaves on web, desktop, remote connections and small screens, and explicitly address the future mobile surface.
- Define useful empty, unavailable, loading and failure states. Missing measurements must be distinguishable from zero, and recorded results from current results.
What would demonstrate a useful first version
A thread can publish a compact summary with several metrics and a linked results list using approved components, then update its data without rewriting the dashboard. A second unrelated thread can build a different card using the same API. Both look coherent, scan clearly in light/dark themes and at narrow widths, and retain working source-thread and action routing.
Existing plain report items should remain useful for simple updates; richer cards should not require every thread to author React.
This is a feature/design request, not an implementation assignment. Consider the authoring/runtime model and a small end-to-end example before expanding the component catalog.
A dashboard summary should let a person scan the important numbers, changes, links and next decisions without reading an expanded prose report. The current title/body reporting model cannot provide that presentation reliably. Markdown tables and better wording help, but they do not give the publishing thread enough control over a card's composition.
The immediate example is a code-health coordinator: it needs counts, original/selected scores, PR and worker links, a short list of the largest improvements, and clear delivery states. Putting all of that in a prose summary card was not usable. Other coordinators will need different combinations of those elements.
Requested capability
Let threads design structured dashboard cards with React components and control over layout, using a documented, approved set of components and styles. A thread should be able to compose a concise metric grid, results table, status rows, links and relevant actions without implementing its own visual language or changing the shared dashboard page.
This belongs to the general dashboard feature, rather than a code-health-specific renderer.
Design considerations
What would demonstrate a useful first version
A thread can publish a compact summary with several metrics and a linked results list using approved components, then update its data without rewriting the dashboard. A second unrelated thread can build a different card using the same API. Both look coherent, scan clearly in light/dark themes and at narrow widths, and retain working source-thread and action routing.
Existing plain report items should remain useful for simple updates; richer cards should not require every thread to author React.
This is a feature/design request, not an implementation assignment. Consider the authoring/runtime model and a small end-to-end example before expanding the component catalog.