## Problem / Motivation When working on one piece of content, an editor needs a focused view showing every review category individually with its pass / warn / fail status and threshold rules. Reviews should run progressively so the editor is not staring at a blank screen, and the layout has to read sensibly whether there is one category configured or ten. ## Mockups ### Default display review panel collapsed. {width=900 height=592} ### Reviews Exist and Panel Expanded {width=900 height=592} ### Reviews haven't run yet (Newly created content draft) {width=900 height=590} ## Video of Interactions {width=900 height=563} ### Layout - **Top of view:** the same segmented pill widget proposed for the list view (counts of pass / warn / fail), plus the optional aggregate score. Acts as the summary header. Keeps the visual pattern consistent across surfaces. - **Below the pill:** the per-category breakdown. One row per category. Two columns when there are six or more categories; one column when there are five or fewer (subject to refinement). - **Each row contains:** - Category label. - Threshold thermometer: a horizontal bar showing the score position relative to the configured fail threshold and (optional) warn threshold. Uses red / yellow / green zones derived from the thresholds. - Pass / warn / fail status icon. - Brief feedback text or a "View details" affordance. ### Threshold model - Each category has a **fail threshold** (required) and a **pass threshold** (required). - The **warn threshold** is optional. Categories without a warn threshold render as a two-zone bar (red / green) and never produce a yellow status. - We **do not support more than three tiers** of feedback per category in this UI. Holding the line at three keeps the pill widget on the list view honest and the per-category bar legible. ### Run states - **Not yet run:** placeholder state, run-all button visible. - **Run in progress:** each row shows a loading state as its review fires. Reviews complete independently; rows update as results arrive. A category that takes 60 seconds should not block one that takes 5 seconds. - **Completed:** the pill widget at the top reflects the final tally. - **Re-run:** running again replaces prior results. Previous results are not surfaced in this UI (history could be a future enhancement). ### Tooltip / drilldown reuse - The same per-category bar is what the list view's tooltip surfaces, so a single component does double duty. Hover or click on a category row reveals additional rule context (rule description, examples) without leaving the page. ### Edge cases - **One category configured.** Renders as a single row. The pill widget at the top is technically redundant but kept for consistency. Width should be capped so a single segment does not stretch absurdly wide. - **Category with only fail/pass thresholds.** Renders without a yellow zone. No "warning" state appears for that category in either the pill or the row. - **Category not yet run while others have.** Renders as a gray segment in the pill and a "Run" affordance on the row, unless the team chooses the "reset all on add" behavior (see overview issue). ## User interface changes - New per-node review surface, likely a tab or dedicated panel on the node edit screen (placement to be confirmed with the architecture discussion issue). - Reusable threshold-bar component shared with the list-view tooltip. - Loading / progressive-update behavior on the per-category rows. ## API / data changes - Reviews need to surface progress events so the UI can update rows individually as they complete (rather than waiting for a single bulk response). - Per-category configuration must expose: fail threshold, pass threshold, optional warn threshold, label, optional rule description. ## Remaining tasks - [ ] Confirm progressive update mechanics with backend (Ajax? React?). - [ ] Decide whether reviewing one category at a time (vs. always run-all) is a first-class affordance. - [ ] Walk the resulting design through the three task scenarios in the parent issue. ## Notes - Source: AI review working session, May 8, 2026. - The pill widget at the top of this view is the same component as the list view widget. Sharing it across surfaces reduces design and implementation surface area.