## Problem / Motivation Editors need to scan many pieces of content at once and see which pages have review problems. A single aggregate score is misleading when one critical category fails. A column per category does not scale. We need one compact per-row indicator that conveys pass / warn / fail counts at a glance and works whether there is one category configured or ten. ## Proposed resolution A single rendered widget per row showing a horizontal pill segmented by pass / warn / fail counts, with numeric labels and an optional aggregate score next to it. ## Design Concepts ### 10 Review Criteria {width="900" height="502"} _Tooltip is active_ {width="900" height="532"} ### 3 Review Criteria {width="900" height="502"} ### 1 Review Criteria {width="739" height="600"} ### Walk though (earlier explorations + Interactions)  ## ### Widget anatomy - **One pill per content item.** Width fixed to its column. Inside the pill, three (or fewer) colored segments proportional to the count of passing, warning, and failing review categories. - **Numeric labels inside or beside each segment** (e.g. `7 / 2 / 1` for fail / warn / pass). Numbers are always present so the data is conveyed even if color is not perceivable. - **Aggregate score beside the pill** (e.g. `78%`). Optional, configurable. Useful primarily for sorting; not the primary signal. - **Color encoding:** red (fail), yellow (warn), green (pass). Yellow is optional — categories can be configured with only fail and pass thresholds, in which case the pill never renders a yellow segment. - **Hover / click reveal:** the same widget used on the single-node review page can be reused as a tooltip or popover from the list view to show category labels and per-category status. Tooltip should require a deliberate hover delay (or click-to-open) so it does not appear unexpectedly across the table. ### Edge cases - **One category configured.** Pill still renders but is a single segment. The aggregate score is redundant in this case; consider hiding or muting it. Width must remain consistent with neighboring rows so the column is not visually unbalanced. - **Many categories (10+).** Numbers stay legible; segment widths shrink but the absolute count next to each segment carries the truth. At extreme counts (100+) segment proportions become approximate but the numbers remain accurate. - **A new category was added since last review.** Two acceptable behaviors: (a) reset all reviews on the affected content, requiring a re-run, or (b) render a gray segment for the unrun category. The first is simpler to communicate; the second is more forgiving but adds a state to explain. Open question — see Remaining tasks. - **No reviews run yet.** Empty / placeholder state with a "Run reviews" affordance. ### Sorting and filtering - Sort by aggregate score (when configured). - Sort by number of failing categories (most common operational sort). - Filter by "any category failing", "any category warning", "all passing", "not yet reviewed". ## User interface changes - New rendered widget (a Drupal field formatter or a Views field plugin) producing the segmented pill + counts + optional aggregate score. - Tooltip / popover surface that reuses the same per-category UI proposed for the single-node review (linked). - Updates to the AI Review entry-point list (probably extending the standard content listing rather than introducing a parallel one). ## API / data changes - The list view needs efficient access to per-category review state for many content items at once. If the current data model stores results inline on the content entity, a Views integration may be sufficient. If results are stored elsewhere, we need a join or a denormalized field. To be confirmed with backend (see architecture discussion issue). ## Remaining tasks - [ ] Decide handling of "category added since last review" (reset vs. grey segment). - [ ] Decide whether the aggregate score column is shown by default, hidden by default, or off-by-default-toggle. - [ ] Decide tooltip vs click-to-open for the per-category drilldown from the list view. ## Notes - Source: AI review working session, May 8, 2026. - Builds on the May 4 group decision that the **collapsed / scanning state should show pass/fail counts, not an aggregate score** (per Bruno: "you could get sued if inclusive language fails even with average passing"). - Comp explorations done in Claude Code; screenshots and a short walkthrough video to be attached.