The Broadside card — one look, every surfaceReview

One renderer, every review card. The 2026-06-10 Broadside lock means proposal cards, route-approval cards, and dataviz reviews all flow through for_tom_html.render_review() — they differ by content modules, never by palette or layout. Today's review: why that constraint is a feature, not a limitation.

A design system's real job isn't to make things pretty — it's to make the RIGHT thing the EASY thing. When there's one render path, the cheapest way to add a card type is to add a content module, and the cheapest way is also the correct way. The system's grain points at consistency.

The Broadside lock encodes this: card types differ by what CONTENT they compose (a proposal card adds a decision-memo band + SVG viz via decision_memo.py; a route-approval card doesn't), but the palette, the masthead, the two-tier ruling, the ink decision bars — those are LOCKED. Same skeleton, different organs. This is why proposing a 'per-workflow aesthetic' is a regression: it re-opens the snowflake door the lock closed.

In your workspace this is the difference between editing JARBUS/DESIGN.md (allowed — add a rule, both judge agents pick it up) and hand-rolling a new HTML template (forbidden — it escapes the contract). The rule of thumb: change the rubric or add a module, never fork the renderer.

Worked example

Prove the single-path claim to yourself — every card type resolves to one function:

grep -rn "def render_review" ~/Claude/JARBUS/scripts/for_tom_html.py
grep -rn "render_review(" ~/Claude/JARBUS/scripts/route.py
grep -rln "render_review\|decision_memo\|narrative" ~/Claude/JARBUS/scripts/

• First line: finds the ONE definition of the renderer — there is a single render_review(), not one per card type.
• Second line: shows route.py calling that same function regardless of which workflow dispatched the card.
• Third line: maps the helper modules (decision_memo, narrative) that compose CONTENT on top of the shared renderer — these are the 'organs', render_review is the 'skeleton'.

Gotchas

• style= and memo= params still exist on render_review but are accepted NO-OPS — passing them does nothing; don't think you're switching looks.
• The retired aesthetics live in git history and Aesthetics/_archive/ — seeing them there is not permission to resurrect them.
• Adding a grading rule means editing the rubric (JARBUS/_docs/review-standards.md), NOT building a third judge agent — standards-checker and tom-review-judge both read the same file.