EBO — W8 Board Experience & Design System

What W8 owns
The board's look, layout, and every animation: live push, entrance bounce, pulse, dim overlay, rotating dashed sequence ring, next-step tags, on-card AI-reply UI, the collapse arrow, the hamburger menu, and the uniform status-colour design system.

What W8 only reflects (owned elsewhere)
W1 owns whether/what actually sends (the failed-send red ring is triggered by W1; W8 only styles it). W2 owns the touchpoint-history content + the frozen scheduled copy the AI reply draws on. W4 owns raw speed. W8 never re-specs those — it renders their state.

You do → click/action/hover You should see → on-screen result Element changes → copy · look · where What changes underneath → data/state Must NOT happen → bug guard 🕓 Touchpoint history → impact on the card's history (or —) 💡 UX critique + suggestion → genuine critique + concrete improvement (owner: keep/omit)

Owner rulings folded in (ANSWERS_ROUND3, 2026-07-11) — Q3=A true real-time push board, no manual refresh · new-lead card = funky bounce-to-place entrance ~2s. Q4=B lead-facing milestones animate · NEW: an unreplied latest email is always visible on the card + a "compose AI reply" button → editable field pre-filled with an AI reply (from touchpoint history, proper greeting, canonical sign-off). Q5=B playful/obvious animations · clockwise rotating dashed border on cards with an active scheduled sequence · cards needing no action today get a uniform darker dim overlay · next step shown as uniform tags · apply a proper design system. Q11=C failed send = red dashed ring (triggered by W1 — W8 styles only). Q14 hamburger menu holds all dormant tabs + never-used parts · Q15=A remove the Create-Task button, everything else dormant. Q17=C ClickUp-colorful: bold status colours, playful, information-dense · Q18=A light theme only. EXTRA: small top-right arrow on every card collapses it to name-only + a few key icons/tags.
Invariants that hold everywhere — light theme ONLY (never apply a dark class); all four animations respect prefers-reduced-motion (motion → a static equivalent, never nothing); the board reflects state, it never invents it (W8 never sends, never advances a stage, never edits copy on its own); ≤ $30/month hosting cap (no new always-on service for the push channel); a build agent never hand-picks a hex colour — every status colour comes from one data-attribute token; colour budget (owner-approved): saturated colour is reserved for decision states (needs-action / failed / approved) — structural chrome uses quieter tints, never a rainbow.

W8-1 — Board loads with the uniform ClickUp-colorful design system (light theme) (happy path / foundation)

Who: Mátyás · When: He opens the pipeline board in the morning — his one and only working surface. Nothing has happened yet; this is the first paint. He wants the board to read instantly: which column is which, which cards are alive, all in bold, consistent colour, no visual noise.

#	You do	You should see	Element that changes copy · look · where	What changes underneath	Must NOT happen	🕓 Touchpoint history	💡 UX critique + suggestion
1	Mátyás opens the board (loads the dashboard URL)	The pipeline board paints in one consistent visual language with a disciplined colour budget: saturated colour is reserved for states that need a decision (needs-action, failed, approved); structural chrome (column headers, card frames) uses quieter tints of the same hues. Bold, but never a rainbow — colour means "look here", not "this is a column"	Copy: column titles unchanged (New leads · Scheduling · Design presented · Contract out · Paying clients) · Look: column headers in quiet accent tints; cards are light panels; saturated colour appears only on decision-state tags · Where: whole board	The board renders with the vendored design-system styles + the ClientsFlow token palette loaded; no per-element inline colours; the token map itself encodes the two-tier colour budget (saturated = decision states, tint = chrome)	Must NOT show two different visual styles side by side (old ad-hoc badges next to new ones); must NOT paint any dark-theme surface even briefly; must NOT give structural chrome the same saturation as decision-state colours (rainbow board)	—	APPLIED (owner) Critique: "Bold, colourful, information-dense" can tip into a rainbow where every colour competes and nothing stands out. Folded into this row: the saturated-for-decisions / tints-for-chrome colour budget is now normative (see You-should-see + Must-NOT).
2	Mátyás scans across the five columns	The same status always looks the same everywhere — a "scheduled sequence" tag, a "needs action" tag, a "negative" tag read identically in New leads and in Contract out	Copy: status tags e.g. "Scheduled" · "Due today" · "No action" · "Rejected" · "Failed" · "Approved" (operator UI is English-only) · Look: one colour + one icon per status, board-wide · Where: card tag row in every column	Every status renders from a single state → token map (one data-attribute per state); colours are defined once, not per column	Must NOT let the same status appear in two different colours in two columns; must NOT require a build agent to choose a colour by hand	—	Critique: A colour-only status system fails for colour-blind viewing and in a screenshot sent to Dani. Suggestion: Pair every status colour with a distinct icon AND a short word — never colour alone. Costs nothing, and it survives greyscale, small sizes, and a compressed screenshot.
3	Mátyás keeps the board open while working (does not refresh)	The board stays current on its own — new leads, status changes, and sequence activity appear without him pressing Refresh or reloading	Copy: unchanged · Look: cards appear/update in place · Where: live board	A live update channel keeps the open board in sync (see W8-2); no client-side full-page auto-reload (the standing "a refresh must never eat an in-progress edit" rule still holds)	Must NOT trigger a full-page auto-reload that could discard an in-progress edit (e.g. an open AI-reply field); must NOT silently go stale for minutes	—	Critique: "Live but never full-reload" is a real tension — a partial live update that repaints a card he is mid-edit on is just as destructive as a reload. Suggestion: Live updates must skip (queue) any card that currently has an open editor (AI-reply field, inline edit) and apply the update the moment he closes it, with a subtle "updated" flash so he knows it changed. ❓ owner: acceptable?

You do

You should see

Element that changes
copy · look · where

What changes underneath

Must NOT happen

🕓 Touchpoint history

💡 UX critique + suggestion

Mátyás opens the board (loads the dashboard URL)

The pipeline board paints in one consistent visual language with a disciplined colour budget: saturated colour is reserved for states that need a decision (needs-action, failed, approved); structural chrome (column headers, card frames) uses quieter tints of the same hues. Bold, but never a rainbow — colour means "look here", not "this is a column"

Copy: column titles unchanged (New leads · Scheduling · Design presented · Contract out · Paying clients) · Look: column headers in quiet accent tints; cards are light panels; saturated colour appears only on decision-state tags · Where: whole board

The board renders with the vendored design-system styles + the ClientsFlow token palette loaded; no per-element inline colours; the token map itself encodes the two-tier colour budget (saturated = decision states, tint = chrome)

Must NOT show two different visual styles side by side (old ad-hoc badges next to new ones); must NOT paint any dark-theme surface even briefly; must NOT give structural chrome the same saturation as decision-state colours (rainbow board)

—

APPLIED (owner) Critique: "Bold, colourful, information-dense" can tip into a rainbow where every colour competes and nothing stands out.
Folded into this row: the saturated-for-decisions / tints-for-chrome colour budget is now normative (see You-should-see + Must-NOT).

Mátyás scans across the five columns

The same status always looks the same everywhere — a "scheduled sequence" tag, a "needs action" tag, a "negative" tag read identically in New leads and in Contract out

Copy: status tags e.g. "Scheduled" · "Due today" · "No action" · "Rejected" · "Failed" · "Approved" (operator UI is English-only) · Look: one colour + one icon per status, board-wide · Where: card tag row in every column

Every status renders from a single state → token map (one data-attribute per state); colours are defined once, not per column

Must NOT let the same status appear in two different colours in two columns; must NOT require a build agent to choose a colour by hand

—

Critique: A colour-only status system fails for colour-blind viewing and in a screenshot sent to Dani.
Suggestion: Pair every status colour with a distinct icon AND a short word — never colour alone. Costs nothing, and it survives greyscale, small sizes, and a compressed screenshot.

Mátyás keeps the board open while working (does not refresh)

The board stays current on its own — new leads, status changes, and sequence activity appear without him pressing Refresh or reloading

Copy: unchanged · Look: cards appear/update in place · Where: live board

A live update channel keeps the open board in sync (see W8-2); no client-side full-page auto-reload (the standing "a refresh must never eat an in-progress edit" rule still holds)

Must NOT trigger a full-page auto-reload that could discard an in-progress edit (e.g. an open AI-reply field); must NOT silently go stale for minutes

—

Critique: "Live but never full-reload" is a real tension — a partial live update that repaints a card he is mid-edit on is just as destructive as a reload.
Suggestion: Live updates must skip (queue) any card that currently has an open editor (AI-reply field, inline edit) and apply the update the moment he closes it, with a subtle "updated" flash so he knows it changed. ❓ owner: acceptable?

W8-2 — New lead pushed to the board → funky bounce-to-place entrance (~2s), no refresh (happy path)

Who: System (a new lead arrives) + Mátyás (watching) · When: A fresh lead enters the pipeline while Mátyás already has the board open. He should notice it land — the arrival is the signal, no refresh, no hunting.

# You do You should see Element that changes
copy · look · where What changes underneath Must NOT happen 🕓 Touchpoint history 💡 UX critique + suggestion

1 Nothing — Mátyás is just watching the board when a new lead arrives A new card drops into the New-leads column and bounces to settle into place over about 2 seconds — playful, impossible to miss, and it lands exactly where it belongs Copy: the lead's name + first status tag · Look: bounce-to-place entrance (a springy overshoot that settles), ~2s · Where: top of the New-leads column The live channel pushes the new lead to every open board; the card is inserted and the entrance animation class is applied at insert time (transform-only, so it never fights the dim/pulse overlays) Must NOT require a refresh to see the lead; must NOT animate by fading opacity (a fade pins opacity and defeats the dim/pulse overlays — the D6 bug); must NOT drop the card in the wrong column The new lead's history begins per W2's rules (first-contact entry). W8 draws attention to the card; it does not author the history entry. Critique: A 2s bounce is delightful once, but if several leads arrive together the column turns into a bouncing pile and the animation becomes the noise it was meant to cut through.
Suggestion: Stagger simultaneous arrivals (each starts ~150ms after the last) and cap concurrent bounces; beyond a few, later cards just slide in quietly. Keeps the "something arrived" delight without a slot-machine board.

2 Mátyás has reduced-motion enabled at the OS level The new card still clearly appears and draws the eye — but with a gentle highlight instead of the bounce Copy: same · Look: brief static highlight ring / soft colour flash, no bounce · Where: New-leads column The entrance respects prefers-reduced-motion: reduce — swaps the bounce for a static attention cue Must NOT simply skip the arrival cue for reduced-motion users (they still need to notice the lead); must NOT keep bouncing against the OS preference — Critique: Reduced-motion is often treated as "turn animation off" and then the arrival becomes invisible — worse than the animation.
Suggestion: Treat reduced-motion as "same information, no movement" — a 1.5s static glow that fades is calm AND noticeable. Never let the accessibility path lose the signal.

#	You do	You should see	Element that changes copy · look · where	What changes underneath	Must NOT happen	🕓 Touchpoint history	💡 UX critique + suggestion
1	Nothing — Mátyás is just watching the board when a new lead arrives	A new card drops into the New-leads column and bounces to settle into place over about 2 seconds — playful, impossible to miss, and it lands exactly where it belongs	Copy: the lead's name + first status tag · Look: bounce-to-place entrance (a springy overshoot that settles), ~2s · Where: top of the New-leads column	The live channel pushes the new lead to every open board; the card is inserted and the entrance animation class is applied at insert time (transform-only, so it never fights the dim/pulse overlays)	Must NOT require a refresh to see the lead; must NOT animate by fading opacity (a fade pins opacity and defeats the dim/pulse overlays — the D6 bug); must NOT drop the card in the wrong column	The new lead's history begins per W2's rules (first-contact entry). W8 draws attention to the card; it does not author the history entry.	Critique: A 2s bounce is delightful once, but if several leads arrive together the column turns into a bouncing pile and the animation becomes the noise it was meant to cut through. Suggestion: Stagger simultaneous arrivals (each starts ~150ms after the last) and cap concurrent bounces; beyond a few, later cards just slide in quietly. Keeps the "something arrived" delight without a slot-machine board.
2	Mátyás has reduced-motion enabled at the OS level	The new card still clearly appears and draws the eye — but with a gentle highlight instead of the bounce	Copy: same · Look: brief static highlight ring / soft colour flash, no bounce · Where: New-leads column	The entrance respects `prefers-reduced-motion: reduce` — swaps the bounce for a static attention cue	Must NOT simply skip the arrival cue for reduced-motion users (they still need to notice the lead); must NOT keep bouncing against the OS preference	—	Critique: Reduced-motion is often treated as "turn animation off" and then the arrival becomes invisible — worse than the animation. Suggestion: Treat reduced-motion as "same information, no movement" — a 1.5s static glow that fades is calm AND noticeable. Never let the accessibility path lose the signal.

W8-3 — Cards needing action today pulse; cards needing none get a uniform dim overlay (happy path)

Who: Mátyás · When: Mid-morning, the board holds a mix of leads — some need a reply/call/decision today, most don't. He wants his eye pulled only to the ones that need him, and the rest visually pushed back.

#	You do	You should see	Element that changes copy · look · where	What changes underneath	Must NOT happen	🕓 Touchpoint history	💡 UX critique + suggestion
1	Mátyás scans the board for what needs him today	Cards that need an action today stand out (a gentle pulse / bright state); cards that need nothing today are pushed back under a uniform darker dim overlay — same darkness on every dimmed card	Copy: unchanged · Look: needs-action = full-colour + soft pulse; no-action = a single, consistent dark wash over the card · Where: every card, in every column	Each card's "needs action today?" flag decides pulse vs dim; the dim is a non-opacity darkening wash (so it composes with other layers), applied via one reusable class	Must NOT dim a card that actually needs action today; must NOT vary the dim darkness card to card (it must read as one uniform layer); must NOT use opacity-fade to dim (breaks other overlays)	—	Critique: "Needs action today" is a strong claim; if the rule is even slightly wrong, a dimmed card hides a real task and he loses trust in the dim entirely. Suggestion: Make the dim reversible on hover (hovering a dimmed card lifts the wash so he can read it fully) and show a one-line "why dimmed" on hover (e.g. "next action: Jul 18"). Trust the dim only if he can instantly audit it.
2	A dimmed card's situation changes so it now needs action today (e.g. the lead replies)	The dim overlay lifts and the card becomes bright / starts pulsing — live, without a refresh	Copy: may gain a "Due today" tag · Look: dim wash removed, pulse begins · Where: the card, in place	The live channel updates the card's needs-action flag; the dim class is removed and the pulse class added	Must NOT keep the card dimmed after it becomes actionable; must NOT require a refresh for the transition to show	The underlying event (e.g. reply received) is logged per W2. W8 only flips the visual state.	Critique: If both pulse (needs-action) and the rotating sequence ring (W8-5) can apply at once, a card could pulse AND spin AND be bright — three animations competing. Suggestion: Declare a precedence: needs-action pulse always wins the card's "loudness" budget; if a pulsing card also has an armed sequence, keep the ring but calm it (slower/thinner) so one card never runs two loud animations. ❓ owner: agree pulse > ring?

You do

You should see

Element that changes
copy · look · where

What changes underneath

Must NOT happen

🕓 Touchpoint history

💡 UX critique + suggestion

Mátyás scans the board for what needs him today

Cards that need an action today stand out (a gentle pulse / bright state); cards that need nothing today are pushed back under a uniform darker dim overlay — same darkness on every dimmed card

Copy: unchanged · Look: needs-action = full-colour + soft pulse; no-action = a single, consistent dark wash over the card · Where: every card, in every column

Each card's "needs action today?" flag decides pulse vs dim; the dim is a non-opacity darkening wash (so it composes with other layers), applied via one reusable class

Must NOT dim a card that actually needs action today; must NOT vary the dim darkness card to card (it must read as one uniform layer); must NOT use opacity-fade to dim (breaks other overlays)

—

Critique: "Needs action today" is a strong claim; if the rule is even slightly wrong, a dimmed card hides a real task and he loses trust in the dim entirely.
Suggestion: Make the dim reversible on hover (hovering a dimmed card lifts the wash so he can read it fully) and show a one-line "why dimmed" on hover (e.g. "next action: Jul 18"). Trust the dim only if he can instantly audit it.

A dimmed card's situation changes so it now needs action today (e.g. the lead replies)

The dim overlay lifts and the card becomes bright / starts pulsing — live, without a refresh

Copy: may gain a "Due today" tag · Look: dim wash removed, pulse begins · Where: the card, in place

The live channel updates the card's needs-action flag; the dim class is removed and the pulse class added

Must NOT keep the card dimmed after it becomes actionable; must NOT require a refresh for the transition to show

The underlying event (e.g. reply received) is logged per W2. W8 only flips the visual state.

Critique: If both pulse (needs-action) and the rotating sequence ring (W8-5) can apply at once, a card could pulse AND spin AND be bright — three animations competing.
Suggestion: Declare a precedence: needs-action pulse always wins the card's "loudness" budget; if a pulsing card also has an armed sequence, keep the ring but calm it (slower/thinner) so one card never runs two loud animations. ❓ owner: agree pulse > ring?

W8-4 — Active scheduled sequence → clockwise rotating dashed border; clears when the sequence ends (happy path)

Who: Mátyás · When: A lead has an armed email sequence quietly running in the background (emails scheduled to go out over days). He wants to see, at a glance, which cards are "on autopilot" right now versus which are idle.

#	You do	You should see	Element that changes copy · look · where	What changes underneath	Must NOT happen	🕓 Touchpoint history	💡 UX critique + suggestion
1	Mátyás looks at a lead that has a scheduled sequence armed	The card wears a dashed border that travels clockwise around it — a living "sequence running" halo, distinct from a plain static dashed line	Copy: optional "Scheduled" tag · Look: dashed border rotating clockwise around the card edge · Where: the card's outer border	The card carries the "active sequence" flag; the rotating-ring class is layered additively over the existing static dashed border (so a browser without the animation still shows a dashed border)	Must NOT show the rotating ring on a card with no armed sequence; must NOT replace the static dashed fallback (it must degrade gracefully); must NOT confuse it with the failed-send red ring (that one is red — see W8-9)	The sequence's scheduled steps live in the touchpoint history / outbox (W2). The ring reflects that a sequence is armed; it adds no history of its own.	Critique: A moving border and a red failed-send ring are both "rings" — under a glance they can be mistaken, especially if the sequence ring's colour is warm. Suggestion: Keep the sequence ring a calm cool colour (blue/indigo) that moves, and the failure ring a static hot red — differ on BOTH colour and motion so they can never be confused. Add a hover tooltip "next scheduled: Jul 14, 09:00".
2	The sequence ends (the lead replies, or it is stopped/completed)	The rotating dashed border disappears — the card visibly stops being "on autopilot"	Copy: "Scheduled" tag removed · Look: rotating ring gone, normal card border · Where: the card	The live channel clears the "active sequence" flag; the ring class is removed	Must NOT keep spinning after the sequence stopped (a false "still sending" signal); must NOT require a refresh to clear	The stop/complete/reply event is logged by W1/W2. W8 only removes the ring.	Critique: The disappearance is silent — he may not register that a lead just came off autopilot (which often means "reply arrived, now needs you"). Suggestion: When the ring clears because a reply stopped the sequence, hand off directly to the needs-action pulse (W8-3) in the same beat, so "autopilot ended" visually becomes "your turn". One continuous story, not two disconnected changes.

You do

You should see

Element that changes
copy · look · where

What changes underneath

Must NOT happen

🕓 Touchpoint history

💡 UX critique + suggestion

Mátyás looks at a lead that has a scheduled sequence armed

The card wears a dashed border that travels clockwise around it — a living "sequence running" halo, distinct from a plain static dashed line

Copy: optional "Scheduled" tag · Look: dashed border rotating clockwise around the card edge · Where: the card's outer border

The card carries the "active sequence" flag; the rotating-ring class is layered additively over the existing static dashed border (so a browser without the animation still shows a dashed border)

Must NOT show the rotating ring on a card with no armed sequence; must NOT replace the static dashed fallback (it must degrade gracefully); must NOT confuse it with the failed-send red ring (that one is red — see W8-9)

The sequence's scheduled steps live in the touchpoint history / outbox (W2). The ring reflects that a sequence is armed; it adds no history of its own.

Critique: A moving border and a red failed-send ring are both "rings" — under a glance they can be mistaken, especially if the sequence ring's colour is warm.
Suggestion: Keep the sequence ring a calm cool colour (blue/indigo) that moves, and the failure ring a static hot red — differ on BOTH colour and motion so they can never be confused. Add a hover tooltip "next scheduled: Jul 14, 09:00".

The sequence ends (the lead replies, or it is stopped/completed)

The rotating dashed border disappears — the card visibly stops being "on autopilot"

Copy: "Scheduled" tag removed · Look: rotating ring gone, normal card border · Where: the card

The live channel clears the "active sequence" flag; the ring class is removed

Must NOT keep spinning after the sequence stopped (a false "still sending" signal); must NOT require a refresh to clear

The stop/complete/reply event is logged by W1/W2. W8 only removes the ring.

Critique: The disappearance is silent — he may not register that a lead just came off autopilot (which often means "reply arrived, now needs you").
Suggestion: When the ring clears because a reply stopped the sequence, hand off directly to the needs-action pulse (W8-3) in the same beat, so "autopilot ended" visually becomes "your turn". One continuous story, not two disconnected changes.

W8-5 — Unreplied latest email is always shown on the card + "compose AI reply" flow (happy path / new feature)

Who: Mátyás · When: A lead sent an email and it hasn't been replied to yet. Mátyás wants to read what they said and fire back a good reply without opening anything — right on the card, with the AI doing the first draft.

# You do You should see Element that changes
copy · look · where What changes underneath Must NOT happen 🕓 Touchpoint history 💡 UX critique + suggestion

1 Mátyás looks at a card whose latest email from the lead is unreplied The text of that latest email is always visible on the card face (not hidden behind a click) plus a "Compose AI reply" button Copy: the lead's email text + button "Compose AI reply" · Look: quoted email block on the card + a primary button · Where: card body, only while the latest email is unreplied The card reads the latest-inbound + reply-status from the same lead state W2 maintains; no new send happens Must NOT hide the unreplied email behind a click/hover; must NOT show the block once a reply has been sent; must NOT show a stale/older email as "latest" The inbound email is already a touchpoint (W2). W8 surfaces its text on the card face; it does not create a new entry for showing it. Critique: A long inbound email printed in full on the card could blow up the card height and wreck the column scan.
Suggestion: Show the first ~2 lines with a "több" expander; the full text expands inline on demand. Keeps the card scannable while honouring "always visible". ❓ owner: full text vs. 2-line preview acceptable?

2 Mátyás clicks "Compose AI reply" An editable reply field appears right on the card, already pre-filled with an AI-written reply — proper Hungarian greeting at the top, the canonical sign-off at the bottom, written from this lead's history Copy: AI draft — {{greeting}} resolved (e.g. "Kedves János,") + body + canonical sign-off · Look: inline editable textarea + "Send" / "Cancel" buttons · Where: in place, on the card An AI reply is generated from the touchpoint history; greeting + sign-off applied by the existing copy rules (W2/W6 own the copy correctness — W8 renders the field). Nothing sends yet Must NOT auto-send the AI draft; must NOT show a raw {{token}} in the draft; must NOT drop the canonical sign-off; must NOT lose the draft if the live board updates the card underneath No entry yet — a draft is not a send. The touchpoint is written only when he actually sends (step 3), owned by W1/W2. Critique: Generating the draft takes a moment; a button that appears to do nothing for 1–2s invites a double-click and a double draft.
Suggestion: Disable the button on click and show a "drafting…" state within 300ms; only then reveal the field. Cheap, and it kills the double-generate cost.

3 Mátyás edits the draft if needed and clicks "Send" The reply sends; the card's unreplied block + AI field disappear (it's answered now); the send is recorded in the history Copy: card returns to normal (no unreplied block) · Look: field closes, brief "Sent" confirmation · Where: the card The send fires through the W1 send path (human-gated — the click is the gate); the touchpoint history gains the sent reply (W2), with the exact text he sent Must NOT send without the explicit "Send" click; must NOT keep showing the unreplied block after a successful send; the recorded history copy must match what was sent exactly (parity) NEW ENTRY (owned by W2)
The sent reply is logged as an outbound touchpoint with the resolved greeting + sign-off — 100% parity with what left. W8 triggers the send; W1/W2 own the record. Critique: If the send fails after he clicks Send, the on-card flow could quietly close and he'd believe it went.
Suggestion: On a failed send, keep the field open, show the failure inline, and apply the failed-send red ring (W8-9) to the card — never let a failure look like a success. (Failure behaviour owned by W1; W8 must render it, not swallow it.)

#	You do	You should see	Element that changes copy · look · where	What changes underneath	Must NOT happen	🕓 Touchpoint history	💡 UX critique + suggestion
1	Mátyás looks at a card whose latest email from the lead is unreplied	The text of that latest email is always visible on the card face (not hidden behind a click) plus a "Compose AI reply" button	Copy: the lead's email text + button "Compose AI reply" · Look: quoted email block on the card + a primary button · Where: card body, only while the latest email is unreplied	The card reads the latest-inbound + reply-status from the same lead state W2 maintains; no new send happens	Must NOT hide the unreplied email behind a click/hover; must NOT show the block once a reply has been sent; must NOT show a stale/older email as "latest"	The inbound email is already a touchpoint (W2). W8 surfaces its text on the card face; it does not create a new entry for showing it.	Critique: A long inbound email printed in full on the card could blow up the card height and wreck the column scan. Suggestion: Show the first ~2 lines with a "több" expander; the full text expands inline on demand. Keeps the card scannable while honouring "always visible". ❓ owner: full text vs. 2-line preview acceptable?
2	Mátyás clicks "Compose AI reply"	An editable reply field appears right on the card, already pre-filled with an AI-written reply — proper Hungarian greeting at the top, the canonical sign-off at the bottom, written from this lead's history	Copy: AI draft — `{{greeting}}` resolved (e.g. "Kedves János,") + body + canonical sign-off · Look: inline editable textarea + "Send" / "Cancel" buttons · Where: in place, on the card	An AI reply is generated from the touchpoint history; greeting + sign-off applied by the existing copy rules (W2/W6 own the copy correctness — W8 renders the field). Nothing sends yet	Must NOT auto-send the AI draft; must NOT show a raw `{{token}}` in the draft; must NOT drop the canonical sign-off; must NOT lose the draft if the live board updates the card underneath	No entry yet — a draft is not a send. The touchpoint is written only when he actually sends (step 3), owned by W1/W2.	Critique: Generating the draft takes a moment; a button that appears to do nothing for 1–2s invites a double-click and a double draft. Suggestion: Disable the button on click and show a "drafting…" state within 300ms; only then reveal the field. Cheap, and it kills the double-generate cost.
3	Mátyás edits the draft if needed and clicks "Send"	The reply sends; the card's unreplied block + AI field disappear (it's answered now); the send is recorded in the history	Copy: card returns to normal (no unreplied block) · Look: field closes, brief "Sent" confirmation · Where: the card	The send fires through the W1 send path (human-gated — the click is the gate); the touchpoint history gains the sent reply (W2), with the exact text he sent	Must NOT send without the explicit "Send" click; must NOT keep showing the unreplied block after a successful send; the recorded history copy must match what was sent exactly (parity)	NEW ENTRY (owned by W2) The sent reply is logged as an outbound touchpoint with the resolved greeting + sign-off — 100% parity with what left. W8 triggers the send; W1/W2 own the record.	Critique: If the send fails after he clicks Send, the on-card flow could quietly close and he'd believe it went. Suggestion: On a failed send, keep the field open, show the failure inline, and apply the failed-send red ring (W8-9) to the card — never let a failure look like a success. (Failure behaviour owned by W1; W8 must render it, not swallow it.)

W8-6 — Next step shown as uniform tags, per column (happy path)

Who: Mátyás · When: Scanning any column, he wants each card to tell him its next step in the same visual grammar — not a paragraph, not a different widget per stage — one tag he can read in a glance.

#	You do	You should see	Element that changes copy · look · where	What changes underneath	Must NOT happen	🕓 Touchpoint history	💡 UX critique + suggestion
1	Mátyás reads a card in any column	A single uniform "next step" tag tells him what happens next — same shape, same placement on every card, in every column (e.g. "Next: call Jul 14" / "Next: scheduled email Jul 15" / "Next: awaiting reply")	Copy: "Next: {step} {date}" · Look: one tag style, colour by step-type from the shared token map · Where: card tag row, consistent slot	The next-step is derived from the lead's scheduled/expected next action (the same data feeding the outbox/history, W2); the tag colour comes from the state→token map (W8-1)	Must NOT render the next step as free prose that varies card to card; must NOT use a different colour for the same step-type in different columns; must NOT show a next-step tag that contradicts the card's status tag	The next scheduled step lives in W2's data. The tag reflects it; it does not author history.	Critique: A next-step date with no urgency cue reads the same whether it's today or three weeks out. Suggestion: Tint the tag by proximity (overdue = red, today = bright, future = calm) using the same token scale as the rest of the board, so "when" is legible without reading the date. Ties the next-step tag into the needs-action/dim logic (W8-3) instead of duplicating it.

You do

You should see

Element that changes
copy · look · where

What changes underneath

Must NOT happen

🕓 Touchpoint history

💡 UX critique + suggestion

Mátyás reads a card in any column

A single uniform "next step" tag tells him what happens next — same shape, same placement on every card, in every column (e.g. "Next: call Jul 14" / "Next: scheduled email Jul 15" / "Next: awaiting reply")

Copy: "Next: {step} {date}" · Look: one tag style, colour by step-type from the shared token map · Where: card tag row, consistent slot

The next-step is derived from the lead's scheduled/expected next action (the same data feeding the outbox/history, W2); the tag colour comes from the state→token map (W8-1)

Must NOT render the next step as free prose that varies card to card; must NOT use a different colour for the same step-type in different columns; must NOT show a next-step tag that contradicts the card's status tag

The next scheduled step lives in W2's data. The tag reflects it; it does not author history.

Critique: A next-step date with no urgency cue reads the same whether it's today or three weeks out.
Suggestion: Tint the tag by proximity (overdue = red, today = bright, future = calm) using the same token scale as the rest of the board, so "when" is legible without reading the date. Ties the next-step tag into the needs-action/dim logic (W8-3) instead of duplicating it.

W8-7 — Collapse arrow → card folds to name-only + key icons/tags; expand restores it (happy path / EXTRA feature)

Who: Mátyás · When: A busy column has grown tall and he wants to compress the cards he's parked so he can see more of the board at once — without losing the one or two facts that matter on a folded card.

#	You do	You should see	Element that changes copy · look · where	What changes underneath	Must NOT happen	🕓 Touchpoint history	💡 UX critique + suggestion
1	Mátyás clicks the small arrow at the top-right of a card	The card folds to a slim name-only row keeping just a few key icons/tags — the arrow now points the other way (to re-expand)	Copy: lead name stays; survivors = status dot + next-scheduled-contact date + (if armed) a small sequence icon + (if failed) the red marker · Look: full card → one-line strip; arrow flips · Where: the card, top-right arrow	The card's collapsed flag is set; the collapsed layout renders the reduced field set only	Must NOT drop the name or the "needs attention" signals (a collapsed card that's failing or needs action today must still show that); must NOT reflow the whole column jarringly	—	Critique: Owner said "a few key icons/tags, e.g. next scheduled contact date" — but which few is a real design choice, and collapsing away a "needs action today" signal would be dangerous. Suggestion (my proposed survivor set, ❓ owner to confirm): name · status colour dot · next-scheduled-contact date · sequence-active icon · failed-send marker. Everything else hides. Rule of thumb: a collapsed card must still scream if it needs him.
2	Mátyás clicks the (now-flipped) arrow on a collapsed card	The card expands back to its full self — unreplied email block, tags, buttons all return exactly as before	Copy: full card content returns · Look: strip → full card; arrow flips back · Where: the card	The collapsed flag is cleared; the full layout renders	Must NOT lose any card content or an in-progress AI-reply draft across a collapse/expand; must NOT expand a different card than the one clicked	—	Critique: If collapse state is per-session only, every board reload re-expands everything and the tidying is lost; if it's global, a live-pushed new card's default state is ambiguous. Suggestion: Persist collapse state per card so it survives a reload; new pushed cards default to expanded (they're new, they want attention). Offer a column-header "collapse all / expand all" for bulk tidying. ❓ owner: persist collapse across reloads?

You do

You should see

Element that changes
copy · look · where

What changes underneath

Must NOT happen

🕓 Touchpoint history

💡 UX critique + suggestion

Mátyás clicks the small arrow at the top-right of a card

The card folds to a slim name-only row keeping just a few key icons/tags — the arrow now points the other way (to re-expand)

Copy: lead name stays; survivors = status dot + next-scheduled-contact date + (if armed) a small sequence icon + (if failed) the red marker · Look: full card → one-line strip; arrow flips · Where: the card, top-right arrow

The card's collapsed flag is set; the collapsed layout renders the reduced field set only

Must NOT drop the name or the "needs attention" signals (a collapsed card that's failing or needs action today must still show that); must NOT reflow the whole column jarringly

—

Critique: Owner said "a few key icons/tags, e.g. next scheduled contact date" — but which few is a real design choice, and collapsing away a "needs action today" signal would be dangerous.
Suggestion (my proposed survivor set, ❓ owner to confirm): name · status colour dot · next-scheduled-contact date · sequence-active icon · failed-send marker. Everything else hides. Rule of thumb: a collapsed card must still scream if it needs him.

Mátyás clicks the (now-flipped) arrow on a collapsed card

The card expands back to its full self — unreplied email block, tags, buttons all return exactly as before

Copy: full card content returns · Look: strip → full card; arrow flips back · Where: the card

The collapsed flag is cleared; the full layout renders

Must NOT lose any card content or an in-progress AI-reply draft across a collapse/expand; must NOT expand a different card than the one clicked

—

Critique: If collapse state is per-session only, every board reload re-expands everything and the tidying is lost; if it's global, a live-pushed new card's default state is ambiguous.
Suggestion: Persist collapse state per card so it survives a reload; new pushed cards default to expanded (they're new, they want attention). Offer a column-header "collapse all / expand all" for bulk tidying. ❓ owner: persist collapse across reloads?

W8-8 — Hamburger menu holds every dormant tab; Create-Task button removed (happy path / declutter)

Who: Mátyás · When: He works almost entirely on the pipeline board. The dashboard today shows a dozen tabs he rarely opens. He wants them out of the way but still reachable — and the never-used Create-Task button gone entirely.

#	You do	You should see	Element that changes copy · look · where	What changes underneath	Must NOT happen	🕓 Touchpoint history	💡 UX critique + suggestion
1	Mátyás loads the dashboard	The top bar is stripped down to what he actually uses; a hamburger (☰) menu holds everything dormant — the rarely-used tabs (AI Usage, Health, Test drive, Flowchart, Metrics, Costs, Lead radar, Templates, and the like) all live inside it	Copy: primary bar keeps the pipeline board (his one surface) + a ☰ menu · Look: fewer top-level tabs, one ☰ · Where: dashboard top nav	The dormant tabs are relocated under the ☰ menu, not deleted; the pipeline board is the default surface	Must NOT delete/break any relocated tab (all must still open from ☰); must NOT hide something he uses daily inside the menu; must NOT lose a tab entirely	—	Critique: "He uses only the pipeline view" is the ruling, but Today/Calls/Outbox are genuinely daily surfaces too — burying those would hurt. Suggestion (❓ owner to confirm the split): Keep Pipeline + Today + Calls + Outbox top-level; move Templates, AI Usage, Health, Test drive, Flowchart, Metrics, Costs, Lead radar into ☰. If he truly wants ONLY Pipeline top-level, say so and everything else goes in the menu.
2	Mátyás clicks the ☰ menu	The menu opens listing every relocated tab; clicking any one opens it exactly as before	Copy: the relocated tab names · Look: a dropdown/side panel of items · Where: under the ☰ button	Each item deep-links to its existing tab/panel; no behaviour of those tabs changes — only their entry point moved	Must NOT change what a relocated tab does; must NOT require more than one click to reach a relocated tab; must NOT trap focus so the menu can't be closed	—	Critique: Out of sight can become out of mind — a Health or watchdog signal buried in ☰ might be missed when it matters. Suggestion: Let the ☰ button itself carry a small badge/dot when something inside needs attention (e.g. a failed-send count, a health alarm), so the menu can still shout without being on the top bar.
3	Mátyás looks for the old "Create Task" button	It's gone — removed from the interface entirely (Q15=A: only this button is removed; everything else merely relocates to ☰)	Copy: — · Look: the Create-Task button no longer rendered · Where: wherever it used to sit	The Create-Task control is removed from the UI	Must NOT leave a dead/stub Create-Task button that does nothing; must NOT accidentally remove any OTHER control (only Create-Task goes)	—	Critique: If any flow still routes the user toward "create a task", removing only the button leaves a dead end. Suggestion: Sweep for any link/hint that pointed at Create-Task and remove those too, so nothing references a control that no longer exists. (Overlaps W7's Create-Task click-guard cleanup — coordinate so it's removed once, cleanly, not guarded and hidden twice.)

You do

You should see

Element that changes
copy · look · where

What changes underneath

Must NOT happen

🕓 Touchpoint history

💡 UX critique + suggestion

Mátyás loads the dashboard

The top bar is stripped down to what he actually uses; a hamburger (☰) menu holds everything dormant — the rarely-used tabs (AI Usage, Health, Test drive, Flowchart, Metrics, Costs, Lead radar, Templates, and the like) all live inside it

Copy: primary bar keeps the pipeline board (his one surface) + a ☰ menu · Look: fewer top-level tabs, one ☰ · Where: dashboard top nav

The dormant tabs are relocated under the ☰ menu, not deleted; the pipeline board is the default surface

Must NOT delete/break any relocated tab (all must still open from ☰); must NOT hide something he uses daily inside the menu; must NOT lose a tab entirely

—

Critique: "He uses only the pipeline view" is the ruling, but Today/Calls/Outbox are genuinely daily surfaces too — burying those would hurt.
Suggestion (❓ owner to confirm the split): Keep Pipeline + Today + Calls + Outbox top-level; move Templates, AI Usage, Health, Test drive, Flowchart, Metrics, Costs, Lead radar into ☰. If he truly wants ONLY Pipeline top-level, say so and everything else goes in the menu.

Mátyás clicks the ☰ menu

The menu opens listing every relocated tab; clicking any one opens it exactly as before

Copy: the relocated tab names · Look: a dropdown/side panel of items · Where: under the ☰ button

Each item deep-links to its existing tab/panel; no behaviour of those tabs changes — only their entry point moved

Must NOT change what a relocated tab does; must NOT require more than one click to reach a relocated tab; must NOT trap focus so the menu can't be closed

—

Critique: Out of sight can become out of mind — a Health or watchdog signal buried in ☰ might be missed when it matters.
Suggestion: Let the ☰ button itself carry a small badge/dot when something inside needs attention (e.g. a failed-send count, a health alarm), so the menu can still shout without being on the top bar.

Mátyás looks for the old "Create Task" button

It's gone — removed from the interface entirely (Q15=A: only this button is removed; everything else merely relocates to ☰)

Copy: — · Look: the Create-Task button no longer rendered · Where: wherever it used to sit

The Create-Task control is removed from the UI

Must NOT leave a dead/stub Create-Task button that does nothing; must NOT accidentally remove any OTHER control (only Create-Task goes)

—

Critique: If any flow still routes the user toward "create a task", removing only the button leaves a dead end.
Suggestion: Sweep for any link/hint that pointed at Create-Task and remove those too, so nothing references a control that no longer exists. (Overlaps W7's Create-Task click-guard cleanup — coordinate so it's removed once, cleanly, not guarded and hidden twice.)

W8-9 — Failed send → red dashed ring on the card (styled by W8, triggered by W1) (failure / reference only)

Who: System (W1 detects a send failure) + Mátyás · When: An email that should have gone out failed. W1 owns the failure detection and the failures list (Q11=C); W8 owns only how the card LOOKS. Referenced here so the board's ring vocabulary is coherent and the red ring is never confused with the sequence ring.

#	You do	You should see	Element that changes copy · look · where	What changes underneath	Must NOT happen	🕓 Touchpoint history	💡 UX critique + suggestion
1	Nothing — a scheduled/triggered send fails behind the scenes (W1 detects it)	The affected card gains a static red dashed ring — visually loud, and clearly different from the moving cool-coloured sequence ring	Copy: a "Failed" status tag · Look: static red dashed ring around the card · Where: card border	W1 raises the failed-send state (+ its failures list); W8 renders the ring from that state (styling only, never suppressible by a later cosmetic override)	Must NOT let the red ring be silently overridden by another card style; must NOT look like the sequence ring (red + static, not cool + moving); must NOT clear the ring until W1 says the failure is resolved	The failure is logged by W1/W2 (failures list + history). W8 styles the card; it does not author the failure record.	Critique: A ring alone doesn't say WHAT failed or WHAT to do — the recovery action lives in W1's failures list, a step away. Suggestion: Make the red ring / "Failed" tag click-through straight into W1's failures entry for that card, so problem → detail → retry is one hop. (Behaviour owned by W1; W8 just wires the card affordance to it.)

You do

You should see

Element that changes
copy · look · where

What changes underneath

Must NOT happen

🕓 Touchpoint history

💡 UX critique + suggestion

Nothing — a scheduled/triggered send fails behind the scenes (W1 detects it)

The affected card gains a static red dashed ring — visually loud, and clearly different from the moving cool-coloured sequence ring

Copy: a "Failed" status tag · Look: static red dashed ring around the card · Where: card border

W1 raises the failed-send state (+ its failures list); W8 renders the ring from that state (styling only, never suppressible by a later cosmetic override)

Must NOT let the red ring be silently overridden by another card style; must NOT look like the sequence ring (red + static, not cool + moving); must NOT clear the ring until W1 says the failure is resolved

The failure is logged by W1/W2 (failures list + history). W8 styles the card; it does not author the failure record.

Critique: A ring alone doesn't say WHAT failed or WHAT to do — the recovery action lives in W1's failures list, a step away.
Suggestion: Make the red ring / "Failed" tag click-through straight into W1's failures entry for that card, so problem → detail → retry is one hop. (Behaviour owned by W1; W8 just wires the card affordance to it.)

W8-10 — Responsive: the board at desktop (1280), tablet (768), mobile (390) (guardrail / cross-device)

Who: Mátyás · When: He checks the board from a laptop at his desk, occasionally a tablet, and glances on his phone. Every animation, tag, the AI-reply flow, the collapse arrow, and the hamburger must hold up at each width — nothing broken, nothing overflowing.

#	You do	You should see	Element that changes copy · look · where	What changes underneath	Must NOT happen	🕓 Touchpoint history	💡 UX critique + suggestion
1	Mátyás views the board at desktop width (1280)	All five columns side by side; cards at full richness — entrance bounce, pulse, dim, rotating ring, tags, AI-reply field, collapse arrow all render cleanly	Copy: full · Look: multi-column board, full card chrome · Where: whole board	Full layout; no horizontal page scroll (any wide content scrolls inside its own container)	Must NOT overflow the page horizontally; must NOT overlap cards or clip tags	—	Critique: Five columns of information-dense cards can still feel cramped at 1280 once each card carries a ring, tags, and an email block. Suggestion: Make collapse (W8-7) the natural pressure valve at 1280 and consider defaulting parked columns (Paying clients) to collapsed cards, so live-work columns get the width.
2	Mátyás views the board at tablet width (768)	The columns adapt (fewer visible / horizontally scrollable columns); cards stay legible; the AI-reply field, collapse arrow, and ☰ all still work by touch	Copy: full · Look: reduced columns or horizontal column scroll; touch-sized controls · Where: board + nav	Responsive breakpoint reflows the board; touch targets meet a usable minimum size	Must NOT make the arrow / AI-reply buttons too small to tap; must NOT hide the hamburger; must NOT rely on hover-only affordances (dim-lift, tooltips) with no touch equivalent	—	Critique: Several W8 affordances lean on hover (dim-lift to read, ring tooltips) — on touch, hover doesn't exist, so those readouts vanish. Suggestion: Give every hover-only readout a tap equivalent on touch widths (tap a dimmed card lifts it; tap the ring shows the schedule). Decide this now, not as a mobile afterthought.
3	Mátyás glances at the board at mobile width (390)	A single-column, scannable view — one column at a time (swipe/select), cards readable, status colours + needs-action signals still obvious; the AI-reply and collapse still usable	Copy: full · Look: one-column stacked board, compact cards · Where: full-width board	Mobile breakpoint stacks to one column; card content prioritises name + status + next step + any alarm	Must NOT require pinch-zoom to read a card; must NOT let the entrance bounce push content off-screen; must NOT drop the needs-action / failed signals on the small card	—	Critique: On a phone the 2s bounce and rotating ring cost the most (battery, jank) for the least benefit — he's glancing, not working. Suggestion: At mobile width, quiet the ambient animations (keep the arrival highlight + status colours, drop the perpetual ring motion to a static dashed border) — treat 390 like a reduced-motion context by default.

You do

You should see

Element that changes
copy · look · where

What changes underneath

Must NOT happen

🕓 Touchpoint history

💡 UX critique + suggestion

Mátyás views the board at desktop width (1280)

All five columns side by side; cards at full richness — entrance bounce, pulse, dim, rotating ring, tags, AI-reply field, collapse arrow all render cleanly

Copy: full · Look: multi-column board, full card chrome · Where: whole board

Full layout; no horizontal page scroll (any wide content scrolls inside its own container)

Must NOT overflow the page horizontally; must NOT overlap cards or clip tags

—

Critique: Five columns of information-dense cards can still feel cramped at 1280 once each card carries a ring, tags, and an email block.
Suggestion: Make collapse (W8-7) the natural pressure valve at 1280 and consider defaulting parked columns (Paying clients) to collapsed cards, so live-work columns get the width.

Mátyás views the board at tablet width (768)

The columns adapt (fewer visible / horizontally scrollable columns); cards stay legible; the AI-reply field, collapse arrow, and ☰ all still work by touch

Copy: full · Look: reduced columns or horizontal column scroll; touch-sized controls · Where: board + nav

Responsive breakpoint reflows the board; touch targets meet a usable minimum size

Must NOT make the arrow / AI-reply buttons too small to tap; must NOT hide the hamburger; must NOT rely on hover-only affordances (dim-lift, tooltips) with no touch equivalent

—

Critique: Several W8 affordances lean on hover (dim-lift to read, ring tooltips) — on touch, hover doesn't exist, so those readouts vanish.
Suggestion: Give every hover-only readout a tap equivalent on touch widths (tap a dimmed card lifts it; tap the ring shows the schedule). Decide this now, not as a mobile afterthought.

Mátyás glances at the board at mobile width (390)

A single-column, scannable view — one column at a time (swipe/select), cards readable, status colours + needs-action signals still obvious; the AI-reply and collapse still usable

Copy: full · Look: one-column stacked board, compact cards · Where: full-width board

Mobile breakpoint stacks to one column; card content prioritises name + status + next step + any alarm

Must NOT require pinch-zoom to read a card; must NOT let the entrance bounce push content off-screen; must NOT drop the needs-action / failed signals on the small card

—

Critique: On a phone the 2s bounce and rotating ring cost the most (battery, jank) for the least benefit — he's glancing, not working.
Suggestion: At mobile width, quiet the ambient animations (keep the arrival highlight + status colours, drop the perpetual ring motion to a static dashed border) — treat 390 like a reduced-motion context by default.

🕓 Touchpoint-history note for W8:
W8 is a presentation workstream — it almost never authors a touchpoint. The board reflects history that W2 owns (inbound emails, scheduled steps, sent replies) and state that W1 owns (sends, failures). The only place a W8 interaction causes a history entry is the AI-reply send (W8-5 step 3), and even there the entry itself is authored by W1/W2 with exact copy parity — W8 merely triggers it via the human-gated "Send" click. Every other W8 row's history column is "—" by design: animating, dimming, collapsing, and menu-relocating change how the board looks, never what happened to the lead.

💡 UX themes across all W8 scenarios:
(1) Colour must mean "look here", not "this is a column" — reserve saturated colour for decisions (needs-action, failed, approved); quiet the structural chrome, or the ClickUp-colorful board becomes noise. (2) Never colour-only — every status is colour + icon + word, so it survives greyscale, small sizes, and a screenshot to Dani. (3) One loud thing per card — pulse, rotating ring, red ring and bounce must obey a precedence so a single card never runs three competing animations. (4) Live must never eat an edit — a live update skips any card with an open editor and applies on close; the failure mode to avoid is a repaint destroying an in-progress AI reply. (5) Accessibility keeps the signal — reduced-motion and touch get the same information without the movement/hover, never a silently dropped cue. (6) Reflect, don't invent — W8 renders W1/W2/W4's truth; it never sends, advances, or authors on its own.

Work-item → scenario-step mapping

Each build work item derived for W8, and the scenario steps that prove it works when clicked through on the staging board.

Work item	What it delivers	Proven by (scenario · step)
WI-1 · Real-time push channel	The board updates live with no manual refresh (new leads, status flips, sequence start/stop) while never full-reloading over an open edit.	W8-1·3 · W8-2·1 · W8-3·2 · W8-4·2
WI-2 · Entrance animation	New-lead bounce-to-place (~2s, transform-only) + reduced-motion static equivalent.	W8-2·1 · W8-2·2
WI-3 · Card state visuals	Needs-action pulse, uniform dim overlay, rotating dashed sequence ring, and their appear/clear + precedence rules.	W8-3·1 · W8-3·2 · W8-4·1 · W8-4·2
WI-4 · AI-reply on card	Always-visible unreplied email text + compose → editable AI draft (greeting + sign-off) → human-gated send with copy parity.	W8-5·1 · W8-5·2 · W8-5·3
WI-5 · Next-step tags	Uniform, token-coloured next-step tag on every card in every column, tinted by proximity.	W8-6·1
WI-6 · Collapse arrow	Top-right arrow folds a card to name-only + key survivors and expands it back, preserving in-progress edits.	W8-7·1 · W8-7·2
WI-7 · Hamburger menu + Create-Task removal	Dormant tabs relocate under ☰ (still reachable, unchanged behaviour); Create-Task button removed entirely.	W8-8·1 · W8-8·2 · W8-8·3
WI-8 · Design-system application	One uniform ClickUp-colorful, light-theme-only visual language: bold column accents, one state→colour+icon token map board-wide.	W8-1·1 · W8-1·2 · (failed-ring styling) W8-9·1
WI-9 · Failed-send ring styling	Render W1's failed-send state as a static red dashed ring, distinct from the sequence ring (styling only).	W8-9·1 · W8-5·3 (failure path)
WI-10 · Responsive board	Every W8 feature holds at 1280 / 768 / 390 with touch equivalents for hover-only readouts.	W8-10·1 · W8-10·2 · W8-10·3

❓ Open design decisions I made myself — please comment (keep / change) in this round:
❓ D1 Live-update vs open edit (W8-1·3): I ruled that a live update skips any card with an open editor and applies on close with an "updated" flash — rather than blocking live updates or risking eating an edit. Confirm?
❓ D2 Animation precedence (W8-3·2, W8-4): I ruled needs-action pulse outranks the rotating sequence ring (a pulsing card with an armed sequence keeps the ring but calmer). Agree pulse > ring?
❓ D3 Unreplied email length (W8-5·1): I propose a ~2-line preview + "több" expander rather than the full email always printed, to keep cards scannable. Full text always, or preview?
❓ D4 Collapsed-card survivor set (W8-7·1): I chose name · status dot · next-scheduled-contact date · sequence icon · failed marker. Add/remove any?
❓ D5 Collapse persistence (W8-7·2): I ruled collapse state persists per card across reloads; new pushed cards default expanded. OK?
❓ D6 Top-level vs hamburger split (W8-8·1): I kept Pipeline + Today + Calls + Outbox top-level and moved the other eight tabs into ☰. Your ruling reads "only the pipeline view" — do Today/Calls/Outbox stay top-level, or go into ☰ too?
❓ D7 Mobile ambient motion (W8-10·3): I ruled 390px defaults to reduced-motion (drop the perpetual ring/bounce, keep arrival highlight + colours). Confirm?
❓ D8 Ring colour split (W8-4·1): sequence ring = cool + moving, failure ring = red + static, so they can't be confused. Any preferred colours?

Sign-off — acceptance oracle. By signing, Sarudi Mátyás locks scenarios W8-1 … W8-10 and the invariants above as the acceptance answer key for the W8 Board Experience & Design System, and records his keep/change verdict on the ❓ open decisions D1–D8. No W8 code is built or deployed before this signature.
Sarudi Mátyás ✔ Draft · 2026-07-11 · awaiting sign-off