fix(infra): release builds all 17 registry images; pg_dump backup sidecar (#461)

* fix(infra): release builds all 17 registry images; pg_dump backup sidecar

release.yml was missing roboco-agent-grok-prompter and
roboco-agent-grok-secretary (both FROM the bare local roboco-agent-grok
tag, so agent-grok now builds explicitly ahead of the loop, mirroring
the agent-base special case) — a fresh registry pull could never
succeed. Both compose files gain a backup sidecar on the data network:
pg_dump -Fc on start and every 24h, crash-safe tmp+rename, newest-14
rotation, restore walkthrough in docs/backend/ops/database-backups.md.

* chore(docs): reflow hard-wrapped prose inherited from the six-PR merge train

* chore(foundation): regenerate lifecycle artifacts; reflow inherited prose

---------

Co-authored-by: Renn F <rennf93@users.noreply.github.com>
This commit is contained in:
Renzo F
2026-07-11 09:20:57 +02:00
committed by GitHub
co-authored by Renn F
parent 6e57066bd6
commit f7f411e112
11 changed files with 514 additions and 398 deletions
@@ -1,18 +1,10 @@
# Conversation-first layout, agent identity, and live-stream affordances
Interaction spec for the pattern that makes a live conversation the primary
surface of a view, rather than a secondary panel bolted onto a data table: a
three-region layout, a team-color agent identity scheme that scales to the
full 22-agent roster, connection-state visual treatment, a new-message
arrival cue, and the loading/empty/error states a conversation panel needs.
Written so a frontend developer can implement directly from this document
without further design clarification.
Interaction spec for the pattern that makes a live conversation the primary surface of a view, rather than a secondary panel bolted onto a data table: a three-region layout, a team-color agent identity scheme that scales to the full 22-agent roster, connection-state visual treatment, a new-message arrival cue, and the loading/empty/error states a conversation panel needs. Written so a frontend developer can implement directly from this document without further design clarification.
## Scope and where this lives
This is a **pattern spec**, not a new page proposal. It extends the one
conversation surface RoboCo already ships,
`panel/src/app/(dashboard)/a2a/page.tsx`, plus its sub-components:
This is a **pattern spec**, not a new page proposal. It extends the one conversation surface RoboCo already ships, `panel/src/app/(dashboard)/a2a/page.tsx`, plus its sub-components:
| Piece | Existing file it extends |
|---|---|
@@ -22,20 +14,9 @@ conversation surface RoboCo already ships,
| Agent identity | `panel/src/lib/agent-utils.ts` (`getAgentInitials`, `getAgentDisplayName`) |
| Connection state | `panel/src/hooks/use-websocket.ts` (`ConnectionState` = `"connecting" \| "connected" \| "reconnecting" \| "disconnected"`), `panel/src/components/layout/connection-status.tsx` |
Nothing here replaces the `/a2a` page's existing behavior (message fetch,
reply composer, switchboard/list toggle) — every section below is additive:
a third pane, a color layer on an existing avatar, a refined connection
badge, an entrance transition for new rows, and the states around the
stream when it has nothing (yet) to show. The same three-region composition
and identity/connection/arrival treatment apply to any future conversation
surface RoboCo adds (e.g. a unified agent-activity inbox) without
re-deriving the pattern.
Nothing here replaces the `/a2a` page's existing behavior (message fetch, reply composer, switchboard/list toggle) — every section below is additive: a third pane, a color layer on an existing avatar, a refined connection badge, an entrance transition for new rows, and the states around the stream when it has nothing (yet) to show. The same three-region composition and identity/connection/arrival treatment apply to any future conversation surface RoboCo adds (e.g. a unified agent-activity inbox) without re-deriving the pattern.
**Design bar dial read:** dense product UI (a data-heavy live-ops surface
inside existing panel chrome), not a landing page — variance 2, motion 2-3,
density 7, the UX/UI cell's dashboard default. No new radius or shadow
tokens; color additions are a bounded, named palette (below), not ad hoc
hex values.
**Design bar dial read:** dense product UI (a data-heavy live-ops surface inside existing panel chrome), not a landing page — variance 2, motion 2-3, density 7, the UX/UI cell's dashboard default. No new radius or shadow tokens; color additions are a bounded, named palette (below), not ad hoc hex values.
---
@@ -43,8 +24,7 @@ hex values.
### The three regions
A conversation-first surface is composed of three regions, always in this
order left-to-right, with the stream always the widest:
A conversation-first surface is composed of three regions, always in this order left-to-right, with the stream always the widest:
```
┌─ Roster (list rail) ─┬───── Stream (primary) ─────┬─ Context (collapsible) ─┐
@@ -55,20 +35,13 @@ order left-to-right, with the stream always the widest:
└────────────────────────┴───────────────────────────────┴─────────────────────┘
```
- **Roster** is navigation: "which conversation am I looking at" — today's
`A2ASwitchboard`/`A2AConversationList`.
- **Stream** is content: "what was said" — today's `A2ATranscript` plus the
reply composer beneath it. This region gets the majority of horizontal
space at every breakpoint that shows more than one region, because it is
the primary surface, not a byproduct of the roster selection.
- **Context** is metadata: participant identity detail, the linked task
(title, status, a link into `/tasks/{id}`), and any quick actions — a new
region, collapsible, not present in the current implementation.
- **Roster** is navigation: "which conversation am I looking at" — today's `A2ASwitchboard`/`A2AConversationList`.
- **Stream** is content: "what was said" — today's `A2ATranscript` plus the reply composer beneath it. This region gets the majority of horizontal space at every breakpoint that shows more than one region, because it is the primary surface, not a byproduct of the roster selection.
- **Context** is metadata: participant identity detail, the linked task (title, status, a link into `/tasks/{id}`), and any quick actions — a new region, collapsible, not present in the current implementation.
### Grid and breakpoints
Extends the existing `grid grid-cols-12 gap-4 lg:gap-6` container
(`a2a/page.tsx:260`) with one more breakpoint tier rather than replacing it:
Extends the existing `grid grid-cols-12 gap-4 lg:gap-6` container (`a2a/page.tsx:260`) with one more breakpoint tier rather than replacing it:
| Breakpoint | Regions visible | Column split |
|---|---|---|
@@ -76,31 +49,17 @@ Extends the existing `grid grid-cols-12 gap-4 lg:gap-6` container
| `lg` `< xl` | Roster + Stream (today's behavior, unchanged) | Roster `col-span-4`, Stream `col-span-8` |
| `xl`+ | Roster + Stream + Context | Roster `col-span-3`, Stream `col-span-6`, Context `col-span-3` |
The context pane is the new addition and is the one that collapses first —
it never appears below `xl`, and even at `xl`+ it is dismissible via a
header toggle (a `PanelRightClose`/`PanelRightOpen` icon button, `size="sm"
variant="ghost"`, matching the existing switchboard/list toggle buttons at
`a2a/page.tsx:275-296`) so a user who wants the stream at full width above
`xl` can still get it. Collapsed state persists in `localStorage`
(`roboco:conversation-context-open`, boolean), read once at mount — the same
persistence idiom already used for panel-width/theme preferences (avoids a
new state-management dependency).
The context pane is the new addition and is the one that collapses first — it never appears below `xl`, and even at `xl`+ it is dismissible via a header toggle (a `PanelRightClose`/`PanelRightOpen` icon button, `size="sm" variant="ghost"`, matching the existing switchboard/list toggle buttons at `a2a/page.tsx:275-296`) so a user who wants the stream at full width above `xl` can still get it. Collapsed state persists in `localStorage` (`roboco:conversation-context-open`, boolean), read once at mount — the same persistence idiom already used for panel-width/theme preferences (avoids a new state-management dependency).
### Context pane content
When open, the context pane shows, top to bottom:
1. Both participants' identity cards (avatar + name + team badge — see
§2), each linking to `/agents/{slug}`.
2. The linked task, if any: title (truncated to one line), status `Badge`
(reusing the same `variant` mapping already used at `a2a/page.tsx:337-344`),
and a "View task" link.
3. A muted one-line hint when there is no linked task ("This conversation
has no linked task"), matching the tone of the existing no-task composer
message (`a2a/page.tsx:373-377`).
1. Both participants' identity cards (avatar + name + team badge — see §2), each linking to `/agents/{slug}`.
2. The linked task, if any: title (truncated to one line), status `Badge` (reusing the same `variant` mapping already used at `a2a/page.tsx:337-344`), and a "View task" link.
3. A muted one-line hint when there is no linked task ("This conversation has no linked task"), matching the tone of the existing no-task composer message (`a2a/page.tsx:373-377`).
The context pane does not duplicate the reply composer or transcript — it
is read-only summary, never a second place to act on the conversation.
The context pane does not duplicate the reply composer or transcript — it is read-only summary, never a second place to act on the conversation.
---
@@ -108,22 +67,11 @@ is read-only summary, never a second place to act on the conversation.
### Why team color, not per-agent color
With 22 agents in the roster (`AGENT_UUIDS` in `agent-utils.ts`), a unique
hue per agent is not legible — nobody can hold 22 arbitrary colors in
working memory, and two similar hues (e.g. two blues for `be-dev-1` and
`fe-dev-1`) would read as "the same agent" at a glance. Colour is scoped to
the axis that actually matters for fast scanning — **which cell this agent
belongs to** — and individual identity within a team is carried by the
existing initials/code, not a second hue. This scales cleanly: adding a
23rd agent to an existing team changes zero colors; adding a whole new team
is the only case that needs a new bucket, and the palette below already has
headroom.
With 22 agents in the roster (`AGENT_UUIDS` in `agent-utils.ts`), a unique hue per agent is not legible — nobody can hold 22 arbitrary colors in working memory, and two similar hues (e.g. two blues for `be-dev-1` and `fe-dev-1`) would read as "the same agent" at a glance. Colour is scoped to the axis that actually matters for fast scanning — **which cell this agent belongs to** — and individual identity within a team is carried by the existing initials/code, not a second hue. This scales cleanly: adding a 23rd agent to an existing team changes zero colors; adding a whole new team is the only case that needs a new bucket, and the palette below already has headroom.
### The six buckets
A new pure function, `getAgentTeamColor(agentId: string | null | undefined):
AgentTeamColor`, colocated in `agent-utils.ts` next to `getAgentInitials`
(same module — it needs the same slug-resolution logic already there):
A new pure function, `getAgentTeamColor(agentId: string | null | undefined): AgentTeamColor`, colocated in `agent-utils.ts` next to `getAgentInitials` (same module — it needs the same slug-resolution logic already there):
```ts
export type AgentTeamColor =
@@ -135,11 +83,7 @@ export type AgentTeamColor =
| "system";
```
Derived from the slug prefix (`be-*``backend`, `fe-*``frontend`,
`ux-*``ux_ui`, `main-pm`/`product-owner`/`head-marketing`/`auditor`
`board`, `ceo`/`CEO``ceo`, `intake-*`/`secretary-*`/`pr-reviewer-*`
`system`), with the same UUID-to-slug resolution `getAgentInitials` already
does via `resolveToSlug`.
Derived from the slug prefix (`be-*``backend`, `fe-*``frontend`, `ux-*``ux_ui`, `main-pm`/`product-owner`/`head-marketing`/`auditor``board`, `ceo`/`CEO``ceo`, `intake-*`/`secretary-*`/`pr-reviewer-*``system`), with the same UUID-to-slug resolution `getAgentInitials` already does via `resolveToSlug`.
| Bucket | Agents | Token classes (light / dark handled by existing `dark:` pairs already in the codebase's Tailwind v4 setup) |
|---|---|---|
@@ -150,19 +94,11 @@ does via `resolveToSlug`.
| `ceo` | ceo | `bg-primary/15 border-primary/40 text-primary` (the app's own accent — the one human gets the app's own color, not a team bucket) |
| `system` | intake-1, secretary-1, pr-reviewer-1 | `bg-slate-500/15 border-slate-500/40 text-slate-700 dark:text-slate-400` |
Every value here is an existing Tailwind color family already used
elsewhere in the codebase for the same semantic weight (`amber` for
attention in `release-proposal-card.tsx:181`, `blue`/`violet`/`fuchsia` are
Tailwind defaults, no new tokens introduced) at the same `/15` background +
`/40` border opacity already established by the pulse-card treatment in
`a2a-pair-card.tsx:87`.
Every value here is an existing Tailwind color family already used elsewhere in the codebase for the same semantic weight (`amber` for attention in `release-proposal-card.tsx:181`, `blue`/`violet`/`fuchsia` are Tailwind defaults, no new tokens introduced) at the same `/15` background + `/40` border opacity already established by the pulse-card treatment in `a2a-pair-card.tsx:87`.
### Avatar composition
Extends the existing avatar circle (`PairAvatar` in `a2a-pair-card.tsx:20-31`,
and the inline avatar in `a2a-transcript.tsx:70-74`) with the team color as
`border` + `bg`, keeping the initials as the foreground content — the color
becomes a ring around identity, not a replacement for it:
Extends the existing avatar circle (`PairAvatar` in `a2a-pair-card.tsx:20-31`, and the inline avatar in `a2a-transcript.tsx:70-74`) with the team color as `border` + `bg`, keeping the initials as the foreground content — the color becomes a ring around identity, not a replacement for it:
```tsx
<div
@@ -178,25 +114,11 @@ becomes a ring around identity, not a replacement for it:
</div>
```
`TEAM_COLOR_CLASSES` is a `Record<AgentTeamColor, string>` map of the class
strings from the table above, exported alongside `getAgentTeamColor` so
every consumer (transcript rows, pair cards, roster rows, context pane
identity cards) applies the identical mapping — one source of truth, no
per-component re-derivation.
`TEAM_COLOR_CLASSES` is a `Record<AgentTeamColor, string>` map of the class strings from the table above, exported alongside `getAgentTeamColor` so every consumer (transcript rows, pair cards, roster rows, context pane identity cards) applies the identical mapping — one source of truth, no per-component re-derivation.
### Accessibility
Color is never the sole differentiator: the `title` attribute always
carries the full display name (already the case in `PairAvatar`), the
initials/code is always visible text inside the circle, and every place an
avatar appears the agent's display name renders as adjacent text (already
true in the transcript and pair card). A screen reader user gets the name
from the text content regardless of the color layer. All six token pairs
above meet WCAG AA (4.5:1) for the `text-*-700`/`text-*-400` foreground
against a `bg-*-500/15` fill over the app's `background`/`card` surface —
verify against the actual rendered surface at implementation time per the
design bar's contrast-audit rule, since a `/15` alpha fill's effective
contrast depends on what's behind it.
Color is never the sole differentiator: the `title` attribute always carries the full display name (already the case in `PairAvatar`), the initials/code is always visible text inside the circle, and every place an avatar appears the agent's display name renders as adjacent text (already true in the transcript and pair card). A screen reader user gets the name from the text content regardless of the color layer. All six token pairs above meet WCAG AA (4.5:1) for the `text-*-700`/`text-*-400` foreground against a `bg-*-500/15` fill over the app's `background`/`card` surface — verify against the actual rendered surface at implementation time per the design bar's contrast-audit rule, since a `/15` alpha fill's effective contrast depends on what's behind it.
---
@@ -204,10 +126,7 @@ contrast depends on what's behind it.
### States
`ConnectionState` already has four values (`use-websocket.ts:17-21` via
`lib/websocket/connection.ts`); the spec covers all four, since
`"connecting"` (initial handshake) and `"reconnecting"` (recovering after a
drop) share one visual family with a different label:
`ConnectionState` already has four values (`use-websocket.ts:17-21` via `lib/websocket/connection.ts`); the spec covers all four, since `"connecting"` (initial handshake) and `"reconnecting"` (recovering after a drop) share one visual family with a different label:
| State | Dot | Label | Icon (header, inline) | Placement |
|---|---|---|---|---|
@@ -216,27 +135,13 @@ drop) share one visual family with a different label:
| `reconnecting` | `bg-amber-500`, `animate-pulse` | "Reconnecting…" | `Loader2` with `animate-spin`, `h-3 w-3` | Inline in the pane header, **plus** a thin dismissable strip directly above the stream pane's message list: `bg-amber-500/10 border-b border-amber-500/30 text-amber-700 dark:text-amber-400 text-xs px-3 py-1.5` reading "Reconnecting — messages may be out of date" |
| `disconnected` | `bg-muted-foreground/40`, static | "Offline" | `WifiOff`, `h-3 w-3`, `text-muted-foreground` | Inline in the pane header, **plus** the same strip pattern as `reconnecting` but `bg-destructive/10 border-destructive/30 text-destructive`, reading "Disconnected — reconnecting automatically" |
The `connected`/`connecting`/`reconnecting` distinction matters because a
user watching a live conversation needs to know *why* nothing new is
arriving: `connected`-but-quiet means the conversation is genuinely idle;
`reconnecting`/`disconnected` means the stream itself is the problem, not
the conversation. Collapsing all three into one generic "not live" state
(as today's binary `isConnected ? "Live" : "Offline"` does) hides that
distinction.
The `connected`/`connecting`/`reconnecting` distinction matters because a user watching a live conversation needs to know *why* nothing new is arriving: `connected`-but-quiet means the conversation is genuinely idle; `reconnecting`/`disconnected` means the stream itself is the problem, not the conversation. Collapsing all three into one generic "not live" state (as today's binary `isConnected ? "Live" : "Offline"` does) hides that distinction.
The banner strip is scoped to the stream pane only, not a full-page
takeover — this is a live-connection hint, not an application-down state
(that's `OfflineState`, reserved for §5's error case where data can't load
at all).
The banner strip is scoped to the stream pane only, not a full-page takeover — this is a live-connection hint, not an application-down state (that's `OfflineState`, reserved for §5's error case where data can't load at all).
### Motion note
The existing `animate-pulse` dot (`a2a/page.tsx:228`) is a Tailwind
keyframe that only animates `opacity`, so it already satisfies the "animate
transform/opacity only" rule — but it has no `prefers-reduced-motion` guard
today. Add one: wrap the pulsing states in `motion-reduce:animate-none`, so
a reduced-motion user gets a static dot at full opacity instead of the
pulse — the color and label alone still convey the state.
The existing `animate-pulse` dot (`a2a/page.tsx:228`) is a Tailwind keyframe that only animates `opacity`, so it already satisfies the "animate transform/opacity only" rule — but it has no `prefers-reduced-motion` guard today. Add one: wrap the pulsing states in `motion-reduce:animate-none`, so a reduced-motion user gets a static dot at full opacity instead of the pulse — the color and label alone still convey the state.
---
@@ -244,11 +149,7 @@ pulse — the color and label alone still convey the state.
### The cue
When a new message is appended to the stream (a `a2a.message` frame that
resolves to a new row after the existing invalidate-on-frame refetch,
`a2a/page.tsx:131-140`), the new row enters with a **transform + opacity
only** transition — no layout-affecting property, no scroll-listener-driven
animation, per the design bar's motion rule:
When a new message is appended to the stream (a `a2a.message` frame that resolves to a new row after the existing invalidate-on-frame refetch, `a2a/page.tsx:131-140`), the new row enters with a **transform + opacity only** transition — no layout-affecting property, no scroll-listener-driven animation, per the design bar's motion rule:
```tsx
className={cn(
@@ -257,25 +158,13 @@ className={cn(
)}
```
`isNew` is derived the same render-phase way `A2APairCard`'s `isPulsing`
already is (`a2a-pair-card.tsx:49-60`): compare the incoming message id
against a "last seen" set in render, flip to `false` on the next animation
frame via `requestAnimationFrame` inside a `useEffect` — no animation
library, matching the codebase's existing idiom for this exact kind of
one-shot entrance state.
`isNew` is derived the same render-phase way `A2APairCard`'s `isPulsing` already is (`a2a-pair-card.tsx:49-60`): compare the incoming message id against a "last seen" set in render, flip to `false` on the next animation frame via `requestAnimationFrame` inside a `useEffect` — no animation library, matching the codebase's existing idiom for this exact kind of one-shot entrance state.
The starting state (`opacity-0 translate-y-1`, i.e. 4px down) is applied
only for rows that mount already-new (a message arriving while the stream
is open); rows present at initial transcript load render straight to
`opacity-100 translate-y-0` with no transition, so opening a conversation
never shows every existing message animating in at once.
The starting state (`opacity-0 translate-y-1`, i.e. 4px down) is applied only for rows that mount already-new (a message arriving while the stream is open); rows present at initial transcript load render straight to `opacity-100 translate-y-0` with no transition, so opening a conversation never shows every existing message animating in at once.
### Off-screen arrival (scrolled up)
When the user has scrolled up in the stream (not at the bottom) and a new
message arrives, do not auto-scroll and do not play the row-entrance
transition off-screen. Instead show a small pill anchored to the bottom of
the stream pane:
When the user has scrolled up in the stream (not at the bottom) and a new message arrives, do not auto-scroll and do not play the row-entrance transition off-screen. Instead show a small pill anchored to the bottom of the stream pane:
```tsx
<button
@@ -286,31 +175,17 @@ the stream pane:
</button>
```
— same transform/opacity-only constraint, appearing with the same
fade-and-rise-in treatment as the row cue. Clicking it scrolls to bottom
(smooth, CSS `scroll-behavior: smooth` — a browser-native scroll, not a
`scroll` event listener) and dismisses the pill.
— same transform/opacity-only constraint, appearing with the same fade-and-rise-in treatment as the row cue. Clicking it scrolls to bottom (smooth, CSS `scroll-behavior: smooth` — a browser-native scroll, not a `scroll` event listener) and dismisses the pill.
### `prefers-reduced-motion`
Both cues drop the `translate-y`/`-translate-x` transform and the
`duration-200` transition under `motion-reduce:`, leaving only the
`opacity` state change applied instantly (`motion-reduce:transition-none
motion-reduce:translate-y-0`) — the row/pill still visually distinguishes
"just arrived" via a brief `bg-muted/50` background flash (a
non-transform, non-motion cue: a background-color change with its own
short `transition-colors duration-150`, exempt from the transform/opacity
restriction because a plain color transition is not motion) that fades to
the row's normal `bg-card` over 150ms, so reduced-motion users still get
an arrival signal without any movement.
Both cues drop the `translate-y`/`-translate-x` transform and the `duration-200` transition under `motion-reduce:`, leaving only the `opacity` state change applied instantly (`motion-reduce:transition-none motion-reduce:translate-y-0`) — the row/pill still visually distinguishes "just arrived" via a brief `bg-muted/50` background flash (a non-transform, non-motion cue: a background-color change with its own short `transition-colors duration-150`, exempt from the transform/opacity restriction because a plain color transition is not motion) that fades to the row's normal `bg-card` over 150ms, so reduced-motion users still get an arrival signal without any movement.
---
## 5. Loading, empty, and error states
All three states are scoped to the stream pane's content area — the pane
chrome (header, region title, connection badge) stays mounted and stable
across state changes, only the message-list area swaps.
All three states are scoped to the stream pane's content area — the pane chrome (header, region title, connection badge) stays mounted and stable across state changes, only the message-list area swaps.
| State | Trigger | Treatment |
|---|---|---|
@@ -318,11 +193,7 @@ across state changes, only the message-list area swaps.
| **Empty** | Fetch resolved, zero messages (`A2ATranscript` lines 51-60) | Existing centered icon + one-line text (`MessagesSquare`, opacity-50, `text-sm text-muted-foreground`). Extend the copy to be context-aware: "No messages in this conversation yet" when a conversation is selected (current copy, unchanged) vs. "Select a conversation to view messages" when nothing is selected yet (the roster-selected-nothing case, not currently distinguished) — same icon, same layout, only the string changes based on whether `selectedId`/`peekedPair` is set. |
| **Error** | The messages fetch itself errors (distinct from the page-level `isOffline` full-page case at `a2a/page.tsx:239-244`, which covers the *conversations list* failing to load) | A scoped inline state inside the stream pane, not a full-page `OfflineState`: centered `AlertTriangle` icon (`h-8 w-8 opacity-50 text-destructive`), "Couldn't load this conversation" text, and a `Button variant="outline" size="sm"` "Retry" that calls the existing `refetchMessages()`. Reuses the same centered-icon-plus-text layout shell as the empty state (same wrapper `div`, different icon/copy/action) so the three states read as one family, not three unrelated designs. |
The distinction between the page-level `OfflineState` (backend unreachable
entirely, `a2a/page.tsx:239-244`) and this pane-level error state (this one
conversation's message fetch failed, everything else on the page still
works) matters: a transient 500 on one conversation's messages should never
take over the whole page.
The distinction between the page-level `OfflineState` (backend unreachable entirely, `a2a/page.tsx:239-244`) and this pane-level error state (this one conversation's message fetch failed, everything else on the page still works) matters: a transient 500 on one conversation's messages should never take over the whole page.
---
+22 -126
View File
@@ -1,39 +1,16 @@
# Filter control for A2A conversations
Design spec for a filter control on the panel's `/a2a` page
(`panel/src/app/(dashboard)/a2a/page.tsx`), which is the CEO-facing
conversation-first view of agent-to-agent chats. Today the page has no
filtering at all: Panel 1 shows either the org-chart **Switchboard**
(`A2ASwitchboard`) or the classic **Conversation List** (`A2AConversationList`),
capped at the last 100 conversations with no way to narrow them.
Design spec for a filter control on the panel's `/a2a` page (`panel/src/app/(dashboard)/a2a/page.tsx`), which is the CEO-facing conversation-first view of agent-to-agent chats. Today the page has no filtering at all: Panel 1 shows either the org-chart **Switchboard** (`A2ASwitchboard`) or the classic **Conversation List** (`A2AConversationList`), capped at the last 100 conversations with no way to narrow them.
This spec covers the filter dimensions, their placement, the active-filter
chip representation, and accessibility. It reuses the Popover + Checkbox +
Badge-chip pattern already shipped in
`panel/src/components/tasks/task-filters.tsx` rather than inventing a new
filter idiom, and stays within primitives already in
`panel/src/components/ui/` (`popover.tsx`, `checkbox.tsx`, `badge.tsx`,
`button.tsx`, `input.tsx`).
This spec covers the filter dimensions, their placement, the active-filter chip representation, and accessibility. It reuses the Popover + Checkbox + Badge-chip pattern already shipped in `panel/src/components/tasks/task-filters.tsx` rather than inventing a new filter idiom, and stays within primitives already in `panel/src/components/ui/` (`popover.tsx`, `checkbox.tsx`, `badge.tsx`, `button.tsx`, `input.tsx`).
## Design-bar dial read
This is a dense admin surface (a live operations console), not a marketing
page, so per the UX/UI team's design bar defaults: **DESIGN_VARIANCE 2**
(the control sits in an already-fixed grid, no asymmetry), **MOTION_INTENSITY
2** (popover open/close and chip enter/exit only, no scroll choreography),
**VISUAL_DENSITY 7** (compact chips and a single icon-button trigger, not an
airy multi-field form bar like the full-width `TaskFilters` on `/tasks`,
because Panel 1 is only 4/12 columns wide at `lg`+).
This is a dense admin surface (a live operations console), not a marketing page, so per the UX/UI team's design bar defaults: **DESIGN_VARIANCE 2** (the control sits in an already-fixed grid, no asymmetry), **MOTION_INTENSITY 2** (popover open/close and chip enter/exit only, no scroll choreography), **VISUAL_DENSITY 7** (compact chips and a single icon-button trigger, not an airy multi-field form bar like the full-width `TaskFilters` on `/tasks`, because Panel 1 is only 4/12 columns wide at `lg`+).
## 1. Filterable dimensions
Four dimensions, each backed by a field already on the wire today
(`AdminConversationSummary` / `AdminPairSummary` in `panel/src/lib/api/a2a.ts`).
None of these are supported as backend query params yet — `a2aApi.listAdminConversations`
only accepts `limit`. The spec below filters **client-side over the already-fetched
page** (currently capped at `limit=100`); the "Future work" note calls out
the backend seam so a later task can add server-side params without changing
this UI contract.
Four dimensions, each backed by a field already on the wire today (`AdminConversationSummary` / `AdminPairSummary` in `panel/src/lib/api/a2a.ts`). None of these are supported as backend query params yet — `a2aApi.listAdminConversations` only accepts `limit`. The spec below filters **client-side over the already-fetched page** (currently capped at `limit=100`); the "Future work" note calls out the backend seam so a later task can add server-side params without changing this UI contract.
| # | Dimension | Source field(s) | Value domain | Control widget |
|---|---|---|---|---|
@@ -42,31 +19,13 @@ this UI contract.
| 3 | **Status** | `status` (`"active"` \| `"archived"`, the same two values `A2AConversationList`'s `Badge variant` already branches on) | The 2 known statuses | Two-option toggle group (button pair, `aria-pressed`, same idiom as the page's own Switchboard/List view toggle) — a checkbox list would be overkill for 2 values |
| 4 | **Date/time range** | `last_message_at` (falls back to `created_at` when null, matching the list item's own `formatDistanceToNow` fallback) | Any ISO-8601 instant; user picks calendar dates, compared at day granularity in the viewer's local timezone | Two `Input type="date"` fields labeled "From" / "To" — no date-range-picker component exists in `panel/src/components/ui/`, so this stays within already-installed primitives per the ladder (native `<input type="date">` is a browser-native widget, not a new dependency) |
**Per-view applicability.** The Switchboard is org-chart pair cards
(`AdminPairSummary`), not a conversation feed — most pairs have never
talked (`conversation_id: null`). Only **Agent** applies there (narrows
which pair cards render, same predicate as dimension 1 above); Task/Status/
Date filters have no meaning for a pair with no conversation, so selecting
them while in Switchboard view shows a one-line inline note ("Task, Status,
and Date filters apply to the Conversation List view") rather than silently
hiding pairs. Switching to List view via the existing `LayoutGrid`/`ListIcon`
toggle applies all four dimensions.
**Per-view applicability.** The Switchboard is org-chart pair cards (`AdminPairSummary`), not a conversation feed — most pairs have never talked (`conversation_id: null`). Only **Agent** applies there (narrows which pair cards render, same predicate as dimension 1 above); Task/Status/ Date filters have no meaning for a pair with no conversation, so selecting them while in Switchboard view shows a one-line inline note ("Task, Status, and Date filters apply to the Conversation List view") rather than silently hiding pairs. Switching to List view via the existing `LayoutGrid`/`ListIcon` toggle applies all four dimensions.
**Future work (not this task):** once conversation volume regularly exceeds
the `limit=100` page, promote Task/Status/Date to real backend query params
on `GET /a2a/chat/admin/conversations` (`agent`, `task_id`, `status`,
`from`, `to`) so filtering isn't limited to whatever page happened to load.
Client-side filtering as specified here is correct for the current data
volume and ships without a backend task.
**Future work (not this task):** once conversation volume regularly exceeds the `limit=100` page, promote Task/Status/Date to real backend query params on `GET /a2a/chat/admin/conversations` (`agent`, `task_id`, `status`, `from`, `to`) so filtering isn't limited to whatever page happened to load. Client-side filtering as specified here is correct for the current data volume and ships without a backend task.
## 2. Placement
The control must not crowd the conversation-first message stream: it lives
entirely inside **Panel 1** (the list/switchboard card), never inside
**Panel 2** (transcript + composer). Concretely, it is added to the existing
Panel-1 header row in `A2APageContent` (`page.tsx` lines ~269-298), which
today holds a `Radio` icon, a label, and the Switchboard/List view-toggle
buttons:
The control must not crowd the conversation-first message stream: it lives entirely inside **Panel 1** (the list/switchboard card), never inside **Panel 2** (transcript + composer). Concretely, it is added to the existing Panel-1 header row in `A2APageContent` (`page.tsx` lines ~269-298), which today holds a `Radio` icon, a label, and the Switchboard/List view-toggle buttons:
```
Collapsed (no active filters) — Panel 1 header, unchanged height:
@@ -76,20 +35,9 @@ Collapsed (no active filters) — Panel 1 header, unchanged height:
│ ...pair cards / conversation list... │
```
The trigger is a single compact `Button variant="outline" size="sm"` reading
`Filters` (funnel icon, `lucide-react`'s `SlidersHorizontal`), matching the
view-toggle buttons' height (`h-7`) so the header row's height never changes
— that's what keeps it from crowding the list below. It shows an active-count
badge inline (`Filters · 2`) instead of a separate counter chip when >=1
filter is set, same abbreviation `TaskFilters` already uses for its
per-dimension triggers (`"${n} statuses"`).
The trigger is a single compact `Button variant="outline" size="sm"` reading `Filters` (funnel icon, `lucide-react`'s `SlidersHorizontal`), matching the view-toggle buttons' height (`h-7`) so the header row's height never changes — that's what keeps it from crowding the list below. It shows an active-count badge inline (`Filters · 2`) instead of a separate counter chip when >=1 filter is set, same abbreviation `TaskFilters` already uses for its per-dimension triggers (`"${n} statuses"`).
Clicking the trigger opens **one** `Popover` (not four separate popovers
like the full-width `/tasks` page — Panel 1 is too narrow at 4/12 columns
for a row of triggers) containing all four dimension controls stacked
vertically, each in its own labeled section with a small `Clear` link when
that dimension has a selection — directly modeled on each section inside
`TaskFilters`' existing per-dimension `PopoverContent` blocks:
Clicking the trigger opens **one** `Popover` (not four separate popovers like the full-width `/tasks` page — Panel 1 is too narrow at 4/12 columns for a row of triggers) containing all four dimension controls stacked vertically, each in its own labeled section with a small `Clear` link when that dimension has a selection — directly modeled on each section inside `TaskFilters`' existing per-dimension `PopoverContent` blocks:
```
Expanded (popover open), anchored bottom-right of the trigger:
@@ -113,25 +61,13 @@ Expanded (popover open), anchored bottom-right of the trigger:
└─────────────────────────┘
```
Filters apply live as each control changes (no separate "Apply" button) —
consistent with `TaskFilters`, whose `onStatusChange`/`onTeamChange` etc.
fire immediately. The popover's max height is capped (`max-h-[70vh]
overflow-y-auto`, same idea as `TaskFilters`' `max-h-64 overflow-y-auto`
project/product lists) so it never grows taller than the viewport on small
screens.
Filters apply live as each control changes (no separate "Apply" button) — consistent with `TaskFilters`, whose `onStatusChange`/`onTeamChange` etc. fire immediately. The popover's max height is capped (`max-h-[70vh] overflow-y-auto`, same idea as `TaskFilters`' `max-h-64 overflow-y-auto` project/product lists) so it never grows taller than the viewport on small screens.
On mobile (`<lg`, where Panel 1 is the only visible pane per the page's
existing `onDetailLevel` show/hide split), the trigger and popover behave
identically — the popover already clamps to the viewport, so no separate
mobile layout is needed.
On mobile (`<lg`, where Panel 1 is the only visible pane per the page's existing `onDetailLevel` show/hide split), the trigger and popover behave identically — the popover already clamps to the viewport, so no separate mobile layout is needed.
## 3. Active-filter chips + clear-all
When one or more filters are active, a **chip row** appears directly below
the Panel-1 header (above the list/switchboard content), pushing the list
down by exactly the chip row's own height — it does not overlay content and
it collapses to zero height (not rendered at all) when no filters are set,
so the empty/default state is pixel-identical to today's layout:
When one or more filters are active, a **chip row** appears directly below the Panel-1 header (above the list/switchboard content), pushing the list down by exactly the chip row's own height — it does not overlay content and it collapses to zero height (not rendered at all) when no filters are set, so the empty/default state is pixel-identical to today's layout:
```
┌─────────────────────────────────────────────┐
@@ -142,29 +78,16 @@ so the empty/default state is pixel-identical to today's layout:
│ ...filtered pair cards / conversation list...│
```
Each chip is a `Badge variant="secondary"` with a trailing `X`
(`lucide-react`) icon button, exactly `TaskFilters`' existing chip markup
(`<Badge variant="secondary" className="gap-1">{label}<X className="h-3 w-3
cursor-pointer hover:text-destructive" onClick={...} /></Badge>`). One chip
per active value:
Each chip is a `Badge variant="secondary"` with a trailing `X` (`lucide-react`) icon button, exactly `TaskFilters`' existing chip markup (`<Badge variant="secondary" className="gap-1">{label}<X className="h-3 w-3 cursor-pointer hover:text-destructive" onClick={...} /></Badge>`). One chip per active value:
- **Agent**: one chip per selected agent, labeled with `getAgentDisplayName()`.
- **Task**: one chip for the id-fragment text (`Task: <fragment>`) if set, one
chip labeled `No linked task` if that toggle is on.
- **Task**: one chip for the id-fragment text (`Task: <fragment>`) if set, one chip labeled `No linked task` if that toggle is on.
- **Status**: one chip per selected status (`Active` / `Archived`).
- **Date range**: up to two chips, `From <date>` and `To <date>`, each
independently removable.
- **Date range**: up to two chips, `From <date>` and `To <date>`, each independently removable.
Clicking a chip's `X` removes only that value (unchecking the matching
control inside the popover, same two-way binding `TaskFilters` uses between
its checkbox state and its chip `onClick`). The row wraps (`flex flex-wrap
gap-2`) rather than truncating or scrolling horizontally, so every active
filter stays visible without an extra interaction.
Clicking a chip's `X` removes only that value (unchecking the matching control inside the popover, same two-way binding `TaskFilters` uses between its checkbox state and its chip `onClick`). The row wraps (`flex flex-wrap gap-2`) rather than truncating or scrolling horizontally, so every active filter stays visible without an extra interaction.
**Clear all** is a `Button variant="ghost" size="sm"` at the end of the chip
row, visible only when >=1 filter is active (same condition that gates the
whole chip row and mirrors `TaskFilters`' own "Clear all" button), and it
resets every one of the four dimensions in a single click.
**Clear all** is a `Button variant="ghost" size="sm"` at the end of the chip row, visible only when >=1 filter is active (same condition that gates the whole chip row and mirrors `TaskFilters`' own "Clear all" button), and it resets every one of the four dimensions in a single click.
## 4. Accessibility
@@ -182,12 +105,7 @@ resets every one of the four dimensions in a single click.
### WCAG AA contrast
The control introduces zero new colors — every state below reuses the
app's existing shadcn/ui tokens (`panel/src/app/globals.css`), which are
already in production use across the panel, so this control carries no new
contrast risk. Stated minimums (per WCAG 2.1 AA): **4.5:1** for body/label
text, **3:1** for large text (≥18px/14px-bold) and for non-text UI
components (focus rings, icon-only button boundaries).
The control introduces zero new colors — every state below reuses the app's existing shadcn/ui tokens (`panel/src/app/globals.css`), which are already in production use across the panel, so this control carries no new contrast risk. Stated minimums (per WCAG 2.1 AA): **4.5:1** for body/label text, **3:1** for large text (≥18px/14px-bold) and for non-text UI components (focus rings, icon-only button boundaries).
| Element | Tokens | Notes |
|---|---|---|
@@ -199,32 +117,10 @@ components (focus rings, icon-only button boundaries).
| Status toggle button (selected) | `--primary-foreground` on `--primary` (light: `oklch(0.985 0 0)` on `oklch(0.205 0 0)`) | Near-white on near-black — the app's own primary-button pair |
| Focus-visible ring (all controls) | `--ring` outline, ≥3:1 against `--background` and `--card` | Radix + Tailwind's default `focus-visible:ring` treatment already applied to `Button`/`Checkbox`/`Input` across the panel |
Because every pair above is an existing, already-shipped token combination
(not a new color introduced by this spec), no new contrast audit tooling is
required — QA can spot-check with devtools' contrast inspector against this
table rather than measuring from scratch. Dark mode uses the same token
names with their dark-mode values (`globals.css` `.dark` block), which
preserve the same relative-lightness relationships (e.g. `--secondary` /
`--secondary-foreground` stay a light-text-on-darker-chip pair), so no
dark-mode-specific override is needed.
Because every pair above is an existing, already-shipped token combination (not a new color introduced by this spec), no new contrast audit tooling is required — QA can spot-check with devtools' contrast inspector against this table rather than measuring from scratch. Dark mode uses the same token names with their dark-mode values (`globals.css` `.dark` block), which preserve the same relative-lightness relationships (e.g. `--secondary` / `--secondary-foreground` stay a light-text-on-darker-chip pair), so no dark-mode-specific override is needed.
## 5. Empty and edge states
- **Zero results after filtering**: the list/switchboard content area shows
the same empty-state idiom the components already use for "no data at all"
(`MessagesSquare`/`Radio` icon + one line of `text-muted-foreground`), but
with copy that names the cause: `"No conversations match the current
filters"` plus an inline `Clear all` link — distinct from today's `"No A2A
conversations yet"` (zero data) and `"No allowed A2A pairs configured"`
(zero pairs), so the CEO isn't told there's no data when there's just no
match.
- **Agent list is empty on first load** (conversations/pairs still loading):
the Agent checkbox section shows 2 `Skeleton` rows (same `Skeleton`
component the list/switchboard already use for their own loading state)
instead of an empty list, so the popover doesn't imply there are zero
agents.
- **Filters persist across live updates**: the page already invalidates and
refetches conversations on every `a2a.message` WebSocket frame
(`page.tsx` lines 131-140); filter *state* is local component state, not
derived from the fetch, so an incoming live message does not reset active
filters — it's re-evaluated against the refreshed list.
- **Zero results after filtering**: the list/switchboard content area shows the same empty-state idiom the components already use for "no data at all" (`MessagesSquare`/`Radio` icon + one line of `text-muted-foreground`), but with copy that names the cause: `"No conversations match the current filters"` plus an inline `Clear all` link — distinct from today's `"No A2A conversations yet"` (zero data) and `"No allowed A2A pairs configured"` (zero pairs), so the CEO isn't told there's no data when there's just no match.
- **Agent list is empty on first load** (conversations/pairs still loading): the Agent checkbox section shows 2 `Skeleton` rows (same `Skeleton` component the list/switchboard already use for their own loading state) instead of an empty list, so the popover doesn't imply there are zero agents.
- **Filters persist across live updates**: the page already invalidates and refetches conversations on every `a2a.message` WebSocket frame (`page.tsx` lines 131-140); filter *state* is local component state, not derived from the fetch, so an incoming live message does not reset active filters — it's re-evaluated against the refreshed list.