DX expert review on PR #3600 (Stage 4 of #3524) flagged two related layout concerns that don't bite today (we have SUPPORTED_BADGE_VERSIONS = ['3.0'] so every agent has at most one badge per role) but will land the moment 3.1 ships and parallel-version badges become real.
The observation
At 1-3 rows the panel reads as status. At 4+ it starts feeling like inventory. The dashed row separator + repeated "Media Buy Agent" prefix is what tips it: a buyer scanning 5 rows sees five near-identical strings and has to diff the version number visually. The 5x6 case (5 versions x 6 roles = 30 rows) is unusable as a status surface — it becomes a changelog.
What to ship when this matters
1. Group rows under a role header when the same role has 2+ versions
Today every row is a flat (role, version) entry. When an agent holds media-buy@3.0 and media-buy@3.1, both rows show "Media Buy Agent" — the redundancy is what tips the layout from status to inventory.
Proposed: collapse to a role header ("Media Buy Agent") with version sub-rows beneath. Specialism chips can move to the role-header level since they rarely diverge between versions of the same role. Drop the redundancy, restore the status feel.
When a role has only one version, render it flat — no role header. Only group when grouping pays for itself.
2. "Latest only" disclosure when an agent holds 5+ badges
A buyer with 5+ versions across 6 roles (30 rows) needs a default "show me the latest per role" view with a "Show all versions" disclosure for the support / debugging case. Not a panel-row change — a panel-mode toggle.
3. PROTOCOL_LABELS audit
${protocol} Agent${versionSegment} produces "Media Buy Agent 3.1" only because PROTOCOL_LABELS values don't end in "Agent". If a future role label is added as "Media Buy Agent" we'd render "Media Buy Agent Agent 3.1". Worth a one-time audit + a comment in the constant.
Why deferred
Today (['3.0']), no agent triggers either layout case. By the time '3.1' is added to SUPPORTED_BADGE_VERSIONS we'll have actual buyer feedback on:
- How often agents end up with parallel versions
- Whether they care about the older version's row at all (vs. just "I'm latest")
- Where the 5+ ceiling actually lands in practice
Designing the layout against real distributions is much better than guessing.
Out of scope
The header count summary ("N badges across M roles") landed in PR #3600 because it's a one-line change with no layout cost.
DX expert review on PR #3600 (Stage 4 of #3524) flagged two related layout concerns that don't bite today (we have
SUPPORTED_BADGE_VERSIONS = ['3.0']so every agent has at most one badge per role) but will land the moment 3.1 ships and parallel-version badges become real.The observation
What to ship when this matters
1. Group rows under a role header when the same role has 2+ versions
Today every row is a flat
(role, version)entry. When an agent holdsmedia-buy@3.0andmedia-buy@3.1, both rows show "Media Buy Agent" — the redundancy is what tips the layout from status to inventory.Proposed: collapse to a role header ("Media Buy Agent") with version sub-rows beneath. Specialism chips can move to the role-header level since they rarely diverge between versions of the same role. Drop the redundancy, restore the status feel.
When a role has only one version, render it flat — no role header. Only group when grouping pays for itself.
2. "Latest only" disclosure when an agent holds 5+ badges
A buyer with 5+ versions across 6 roles (30 rows) needs a default "show me the latest per role" view with a "Show all versions" disclosure for the support / debugging case. Not a panel-row change — a panel-mode toggle.
3. PROTOCOL_LABELS audit
${protocol} Agent${versionSegment}produces "Media Buy Agent 3.1" only because PROTOCOL_LABELS values don't end in "Agent". If a future role label is added as "Media Buy Agent" we'd render "Media Buy Agent Agent 3.1". Worth a one-time audit + a comment in the constant.Why deferred
Today (
['3.0']), no agent triggers either layout case. By the time'3.1'is added toSUPPORTED_BADGE_VERSIONSwe'll have actual buyer feedback on:Designing the layout against real distributions is much better than guessing.
Out of scope
The header count summary ("N badges across M roles") landed in PR #3600 because it's a one-line change with no layout cost.