The new Review scheduling/freshness UI needs an immediate layout fix before this branch is deployed. The maintainer rejected the attached screenshot during implementation review.

Actual behavior

Opening article assessments turns each row into a wall of repeated freshness boilerplate, full UTC timestamps, revision IDs, and replacement-state text. The details column dominates the table: article titles and numeric column headings wrap into narrow columns, and just three expanded articles consume a very tall page. This is not an acceptable implementation of subtle per-signal freshness labels.

Reproduction

1. Use the in-progress npp-scheduling branch of Projo (not deployed).
2. Open /review with populated articles, including current, 49-hour-old, and 73-hour-old mutable observations.
3. Expand several “Assessments” sections.
4. Compare the resulting table to the attached actual Chromium screenshot. The fixture also includes unchanged 90-day-old model results and a 20-day-old reviewer lookup; these are synthetic offline data, not live articles.

Required fix

• Restore a compact, readable table with stable, usable title and numeric column widths when details are expanded.
• Make freshness a short secondary label beside each signal, not a paragraph of repeated diagnostic metadata.
• Move exact timestamps, revision IDs, window provenance, and detailed retry information behind deliberate secondary disclosure or accessible tooltips; do not repeat them in every default detail line.
• Keep current/pending/stale/unavailable/invalidated distinctions and the agreed subtle black/yellow/orange treatment. Do not fix the layout by hiding failures or changing scoring.
• Keep queue-level operational diagnostics out of article rows and avoid another dense default diagnostic dump.
• Verify the actual desktop and narrow/mobile surfaces with multiple expanded rows. Include before/after screenshots and obtain maintainer visual acceptance before considering this UI ready.

Scope and priority

Urgent pre-deployment UI correction. This is a layout/information-density issue, separate from the existing performance task T437673. The scheduling implementation is still undergoing offline verification; this report does not claim a production outage or a completed rollout.

Filed with AI assistance at the maintainer’s explicit request, based on the actual rendered screenshot.