ClientsFlow Pipeline · Merged Whole-Journey EBO + Live Visual-QA Transcript

Merged EBO — every scenario, every test

One running document that fuses the signed Expected-Behavior Oracle (what each scenario should do) with a live visual-QA transcript per step (what it actually did). Each scenario is a toggle; each step opens a transcript that runs in real order: ① "What should I see?" (before the shot) → 📸 screenshot → ② what to look for → ③ what I see (Gemini pixel report) → 🔬 Sonnet adjudicates whenever Gemini isn't a clean pass → ④ verdict → ⑤ next action. · updated 2026-06-26 09:35:01

▦ LAYOUT A (chosen) — Integrated table · the EBO grid + a 🧪 Test column + an inline live-test transcript per step · 76 scenarios · 206 steps

⚡ Global invariants

INV-IMMEDIATEALL critical state changes must be IMMEDIATELY represented in the pipeline view (optimistic/real-time; no multi-minute lag). Critical changes: booking created, reschedule, cancellation, stage move (incl. Contacted/Negative-Replies/Booked), payment received, proposal sent, proposal signed, transcript-ready, lost, won/published. Card + board reflect within seconds. No manual refresh required.
INV-TZAll times in CRM, pipeline cards, Notion logs, and Google Calendar invites INCLUDING the invite TITLE are interpreted/displayed in Europe/Budapest timezone, regardless of the booking person's location. No tz drift. No exceptions.
⏳ UNVALIDATED ORACLE — not yet signed or run (review draft)run-trust 0.00 · 0/0 steps verified · trust in the asserted invariants, not "the system works"
You do → action You should see → on-screen result Element changes → copy · look · where What changes underneath → data/state Must NOT happen → bug guard 🕓 Touchpoint history 🧪 Test → honesty tag + verdict; expand for the live transcript (expect → shot → look → Gemini sees → 🔬 Sonnet adjudicates non-pass → verdict → next)
Jump to stage:IngestionNew Lead BoardContacted SequenceBookedSales CallProposalSign FollowupPaymentOnboardingStudio DesignCancellationInvariants

Ingestion(4 scenarios)

WJ-01 Enrichment guarantees a website URL; missing → red ❗ badge guardrail bnf-r3-S8duo2-S14studio-S1 PENDING ⏳

Who: System  ·  When: A new lead is enriched; enrichment must save a website_url. This runs upstream of Studio and gates everything downstream.

💡 Studio UX
Step 1The website URL is the single most load-bearing input for the whole Studio flow, yet it sits as plain text with no indication of how confident enrichment is in it.→ Show the URL as a clickable chip with a tiny confidence dot (green = scraped a real homepage, amber = guessed from email domain). Lets the rep sanity-check before a design is auto-built on a wrong URL.
Step 2A bare ❗ tells the rep something is wrong but not what to do about it — the fix (paste a URL) isn't reachable from the badge.→ Make the ❗ badge itself click-to-act: clicking it opens a tiny inline "Weboldal megadása" field right on the card. One click from problem to fix, no panel diving.
#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Enrichment runs on a new lead and finds + saves the prospect's website The card shows the website (favicon/domain) and NO red ❗ — Studio readiness is implicitly met Copy: domain shown on card (e.g. "beridoor.hu") · Look: normal card, optional 🌐 favicon · Where: card meta row deal.website_url persisted; Studio-readiness = true Lead must NOT exist long-term with an empty website silently; readiness must NOT be assumed without a saved URL Type: Adatdúsítás · icon: 🔎 · label: "Weboldal megtalálva" · description: "{domain} mentve" · timestamp: now · initiated_by: system (muted grey) LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Card meta row shows domain (e.g. beridoor.hu) and NO red ❗ badge

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Enrichment finds NO usable website at all A prominent red ❗ badge on the card face — the only thing that will later block the Studio auto-kick Copy: tooltip "Nincs weboldal — add meg a Studio dizájnhoz" · Look: RED ❗ badge, pinned top-right of card · Where: card corner ribbon deal.website_url empty → readiness = false; ❗ flag raised The ❗ must NOT be hidden in a panel; a no-URL deal must NOT pass as Studio-ready Type: Hiányzó adat · icon: ❗ · label: "Nincs weboldal" · description: "Az adatdúsítás nem talált weboldalt — kézi megadás szükséges a Studio dizájnhoz" · timestamp: now · initiated_by: system LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Prominent RED ❗ badge pinned top-right of card with tooltip "Nincs weboldal — add meg a Studio dizájnhoz"

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-02 Lead de-dup matches only on phone or email — never website/company failure bnf-r3-S1 PENDING ⏳

Who: System  ·  When: An existing lead A is in the pipeline (email a@x.hu, phone +3611, website klip.hu). A NEW email arrives from a different person whose signature shares only the website klip.hu, with a different sender email and a different (or random) phone.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Missive inbound webhook receives the new email (gergelykocsi20@…, random phone, body mentions klip.hu) The de-dup chain finds NO match: the sender email is new and the phone is new/ambiguous. A shared website or company name must NOT be a match key. The new email must not be linked onto lead A just because the website/company string overlaps. LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 A brand-new pipeline card is created for the new sender in the New Lead column Two SEPARATE cards on the board — lead A unchanged, and a new card for the new sender. Copy: New sender's name/email on its own card · Look: ordinary New-Lead card (no dim overlay) · Where: top of the New Lead column A new, distinct deal is stored (separate deal_id, separate notion_crm_page_id); dedup_how is NOT 'website' or 'name'. lead A's history/contact fields must not change; no second touchpoint is appended to lead A. LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Two SEPARATE cards: lead A unchanged in its column, new card for new sender in New Lead column

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-03 BUG-08 — first cold-email touchpoints tagged 'Email' not 'Note' (intermittent) edge duo2-S08duo2-S11 PENDING ⏳

Who: Mátyás  ·  When: A cold email is sent to a ZZ test address and then replied to; the operator opens the lead's history.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Send a cold email to the system from a ZZ test address, reply to it, then open the lead's touchpoint history The history shows TWO items tagged 'Email' (one Outgoing, one Incoming) with the email icon/badge and the full copy of the email body, except the additional emails in the thread Copy: Email · Look: email icon/badge (NOT a gray 'Note' badge) · Where: History feed blocks Ingestion classifies both the cold email and its reply as email touchpoints; no first touchpoints are missing The email body must NOT render with a gray 'Note' badge; touchpoints must NOT be dropped (KNOWN-INTERMITTENT — verify across repeated runs) LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

History shows TWO 'Email' tagged feed blocks (one Outgoing, one Incoming) with email icon/badge and full email body

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-04 BUG-11 — first AI reply ends with the standard signature failure duo2-S11 PENDING ⏳

Who: System  ·  When: A New Lead arrives and the automated AI first reply is generated (proposed for human approval).

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 New Lead arrives → AI first-reply draft is generated for human approval The AI reply body ends with the standard simple-text signature block Copy: the standard sign-off (e.g. 'Üdv, …') · Look: signature lines at the bottom of the body · Where: end of the email body The AI-reply template appends the same signature source used by other outbound emails (copy belongs to Mátyás — reused, not invented) The body must NOT end abruptly with no sign-off; nothing is auto-sent without the human approval gate LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

AI reply draft body ends with standard signature block (e.g. 'Üdv, …') at end of email body

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

New Lead Board(8 scenarios)

WJ-05 New-lead card renders in the new layout happy board-S1board-S3 PENDING ⏳

Who: System / Mátyás (operator)  ·  When: A new lead card appears on the board

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 New-lead card appears at the top of the 'New lead' column, pulsing red New-lead card at the top of the 'New lead' column, pulsing red RECEIVED · NEW LEAD · AI 100% api_board joins the unread reply; rank() floats it to the top; pulse-unread, active LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Card at top of 'New lead' column, pulsing red, showing RECEIVED · NEW LEAD · AI 100%

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Read Row 1: lead name + company on the left, a status dropdown in the top-right corner Row 1: lead name + company on the left, a status dropdown in the top-right corner Reorgbau Kft no sequence pill (Row 2) — New lead is sequence-free LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Lead name + company on the left; status dropdown in top-right corner

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 Read Row 3 (website + county) then Row 4 (email + phone) Row 3 and Row 4 with the correct data reorgbau.hu · Fejér megye / reorgbau@gmail.com · +36 70… LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

reorgbau.hu · Fejér megye on Row 3; reorgbau@gmail.com · +36 70… on Row 4

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

4 Read the 'Their last message' block The 'Their last message' block showing the full plain-text body Szia! Kérdőív kitöltve, többit a hétvégén küldöm… Vélemény? stripHtml() before esc(); full body incl. signature, single email only (no 600-char cut); no raw HTML tags visible LIVE ✅PENDING
Step 4 — live test transcript
① Before the shot — "What should I see?"

Plain-text message body; no raw HTML tags visible; full body (no 600-char cut)

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

5 See the action row Action row: 'Log Call' + 'Send Emails' ONLY (no Note / Move / Dani) Log Call · Send Emails Note moved to Full history; Move → status dropdown; Dani removed LIVE ✅PENDING
Step 5 — live test transcript
① Before the shot — "What should I see?"

Only 'Log Call' and 'Send Emails' buttons visible in the action row

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-06 Enrichment guarantees a website URL; missing → red ❗ badge guardrail studio-S1studio-S3bnf-r3-S8 PENDING ⏳

Who: System  ·  When: A new lead is enriched; enrichment must save a website_url. This runs upstream of Studio and gates everything downstream.

💡 Studio UX
Step 1The website URL is the single most load-bearing input for the whole Studio flow, yet it sits as plain text with no indication of how confident enrichment is in it.→ Show the URL as a clickable chip with a tiny confidence dot (green = scraped a real homepage, amber = guessed from email domain). Lets the rep sanity-check before a design is auto-built on a wrong URL.
Step 2A bare ❗ tells the rep something is wrong but not what to do about it — the fix (paste a URL) isn't reachable from the badge.→ Make the ❗ badge itself click-to-act: clicking it opens a tiny inline "Weboldal megadása" field right on the card. One click from problem to fix, no panel diving.
#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Enrichment runs on a new lead and finds + saves the prospect's website The card shows the website (favicon/domain) and NO red ❗ — Studio readiness is implicitly met Copy: domain shown on card (e.g. "beridoor.hu") · Look: normal card, optional 🌐 favicon · Where: card meta row deal.website_url persisted; Studio-readiness = true Lead must NOT exist long-term with an empty website silently; readiness must NOT be assumed without a saved URL Type: Adatdúsítás · icon: 🔎 · label: "Weboldal megtalálva" · description: "{domain} mentve" · timestamp: now · initiated_by: system (muted grey) LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Card meta row shows domain (e.g. beridoor.hu) and NO red ❗ badge

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Enrichment finds NO usable website at all A prominent red ❗ badge on the card face — the only thing that will later block the Studio auto-kick Copy: tooltip "Nincs weboldal — add meg a Studio dizájnhoz" · Look: RED ❗ badge, pinned top-right of card · Where: card corner ribbon deal.website_url empty → readiness = false; ❗ flag raised The ❗ must NOT be hidden in a panel; a no-URL deal must NOT pass as Studio-ready Type: Hiányzó adat · icon: ❗ · label: "Nincs weboldal" · description: "Az adatdúsítás nem talált weboldalt — kézi megadás szükséges a Studio dizájnhoz" · timestamp: now · initiated_by: system LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Prominent RED ❗ badge pinned top-right of card with tooltip "Nincs weboldal — add meg a Studio dizájnhoz"

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-07 Phone number click-to-copy edge board-S2 PENDING ⏳

Who: Mátyás (operator)  ·  When: A new-lead card is visible with a phone number in Row 4

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Click the phone number chip in Row 4 Phone chip clicked +36 70 … navigator.clipboard.writeText(phone) LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

navigator.clipboard.writeText(phone) called

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 A tooltip appears on the phone chip A tooltip appears on the phone chip reading 'Másolva ✓' Másolva ✓ tooltip auto-dismiss ~1.5s; clipboard holds the number LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Tooltip 'Másolva ✓' visible on the phone chip

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-08 Happy spine — post-call wizard → send proposal → card moves to Sign FUP happy board-S6duo2-S02live-S1 PENDING ⏳

Who: Mátyás (operator)  ·  When: Lead is in the Sales Call stage; operator logs a forward (proposal) outcome and sends the proposal

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Click 'Log Call' → 'Forward (proposal)' on the lead's Sales Call card Post-call wizard step 1 opens POST /dash/api/outcome {outcome:'forward'} → flows.api_outcome logs a 'call' touchpoint; stage_key=prepared (col=sales_call); a 'Sales call' touchpoint exists LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Post-call wizard Step 1 opens

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Open the post-call wizard (Step 1) and fill price + 'Kedvezmény érvényessége' (pre-filled today+7) + payment plan Step 1 form with 'Kedvezményes ár (HUF, nettó AAM)' and 'Kedvezmény érvényessége (utána +25%)' fields; 'Kedvezmény érvényessége' pre-filled to today+7 Kedvezményes ár (HUF, nettó AAM) · Kedvezmény érvényessége (utána +25%) POST /dash/api/postcall/preview → dash._postcall_persist_form sets agreed_price, price_expiry_date, proposal_due_date AND price_after_expiry (BUG-04 fix); deal.price_expiry_date set, deal.price_after_expiry = price×1.25 set LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Fields visible: 'Kedvezményes ár (HUF, nettó AAM)' · 'Kedvezmény érvényessége (utána +25%)'; 'Kedvezmény érvényessége' pre-filled today+7

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 Click 'Generate proposal preview' (Step 2) Preview HTML shows discounted price with struck-through anchor price + 'érvényes {exp}-ig' POST /dash/api/postcall/preview mode=ai → proposal_doc.generate_proposal_inner; deterministic price box (strike-through + expiry) always-appended by build_proposal_html (BUG-04) LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

Preview HTML: discounted price + <s>full price</s> + 'érvényes {exp}-ig'

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

4 Click 'Route for approval' (Step 3, pcConfirm) Button shows a spinner + disables while the request runs; review approval page opens in a new tab 📝 Jóváhagyó oldal megnyílt — nézd át és hagyd jóvá kézzel. POST /dash/api/postcall/route — button shows spinner + disables while request runs (BUG-05 fix); review approval page opens in a new tab; pcConfirm button disabled during the call LIVE ✅PENDING
Step 4 — live test transcript
① Before the shot — "What should I see?"

Button: spinner + disabled during request; toast '📝 Jóváhagyó oldal megnyílt — nézd át és hagyd jóvá kézzel.'; review page opens in new tab

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

5 On the /review page click 'Finalize' (page 2 → 3) Review page advances to page 3 flows.finalize_proposal → ensure_docuseal_submission + _sync_stage(deal,'proposal_sent'); stage_key=proposal_sent LIVE ✅PENDING
Step 5 — live test transcript
① Before the shot — "What should I see?"

Review page advances to page 3

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

6 On the /review page-3 click 'Küldés + ajánlat-emlékeztető szekvencia előkészítése →' Proposal email sent; board will show card in Sign FUP on next load flows.submit_review_page2 → _send_missive_email + log(deal,'proposal_sent',...,'email') + sequences.define('proposal_chase', un-armed); board cache busted for the web container (BUG-06 fix); stage_key=proposal_sent; 'Proposal sent' (OUT) touchpoint at send-time; proposal_chase DEFINED un-armed LIVE ✅PENDING
Step 6 — live test transcript
① Before the shot — "What should I see?"

Proposal email sent; board cache busted for web container (BUG-06 fix)

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

7 Return to the board — the card is now in the 'Sign FUP' column Card in the 'Sign FUP' column board_view.deal_col maps proposal_sent → sign_fup; loadBoard(true) ?fresh=1 reconciles; card.stage='sign_fup' (visible move) — BUG-06 send leg satisfied LIVE ✅PENDING
Step 7 — live test transcript
① Before the shot — "What should I see?"

Card in 'Sign FUP' column

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-09 S8 — B5 — Move-to dropdown persists across reload happy ext-S7ext-S8 PENDING ⏳

Who: Mátyás (operator)  ·  When: Mátyás moves a ZZ card from New Leads to Negative Replies using the 'Move to' dropdown.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Mátyás opens the 'Move to' dropdown and picks '🚫 Negative Replies' Card visually moves into the Negative Replies column immediately (optimistic UI) Copy: card now under '🚫 Negative Replies' · Look: card in Negative Replies · Where: pipeline board api_move runs; neg_reply=true AND stage_key set (the bug: only stage_key was set before) Move must NOT only set stage_key; must also set neg_reply so deal_col derives negative NEW ENTRY — Type: Státusz változás · icon: 🔀 · label: 'Áthelyezve: New Lead → Negative Replies' · description: 'Manuális áthelyezés' · timestamp: now · operator: Mátyás LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Card appears under '🚫 Negative Replies' immediately (optimistic)

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Mátyás reloads the board AFTER RELOAD the card is STILL in Negative Replies — does NOT jump back to New Leads Copy: card stays under '🚫 Negative Replies' after reload · Look: card persists · Where: pipeline board deal_col(deal)==negative survives reload because neg_reply is persisted Card must NOT jump back to New Leads after reload No new touchpoint on reload. The Státusz változás entry from step 1 remains as the record. LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Card still under '🚫 Negative Replies' after reload

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 Mátyás moves the card BACK to New Leads via Move-to, then reloads After reload, card is back under 'New Lead' — not in Negative Replies Copy: card under 'New lead' after reload · Look: card in New Leads · Where: pipeline board deal_col(deal)==new_lead after reload (neg_reply cleared) Reverse move must NOT silently leave it in Negative Replies; both directions persist NEW ENTRY — Type: Státusz változás · icon: 🔀 · label: 'Áthelyezve: Negative Replies → New Lead' · description: 'Manuális visszahelyezés' · timestamp: now · operator: Mátyás LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

Card under 'New lead' after reload

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-68 Details side panel happy 📐 Coverage board-S4 PENDING ⏳

Who: Mátyás (operator)  ·  When: A lead card is visible on the board

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Click the 'Details' button (Row 6) Right-edge drawer slides in Details openDetailDrawer(); right-edge drawer slides in LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Right-edge drawer slides in

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 See at the TOP of the panel: RECEIVED + stage + AI% badges + Missive & Notion link icons At the TOP of the panel: RECEIVED + stage + AI% badges + Missive & Notion link icons RECEIVED · NEW LEAD · AI 100% moved off the card face to here LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

RECEIVED · NEW LEAD · AI 100% badges + Missive & Notion icons at the top of the panel

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 Read the editable CRM field grid + notes below Editable CRM field grid + notes with a floating Save FAB Name · Email · Phone · Stage · … floating Save FAB → POST /dash/api/update-lead LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

Editable CRM fields (Name, Email, Phone, Stage, …) + notes; floating Save FAB visible

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-69 Full history side panel happy 📐 Coverage board-S5 PENDING ⏳

Who: Mátyás (operator)  ·  When: A lead card is visible on the board

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Click the 'Full history' button (Row 6) Drawer opens in loading state Full history openHistDrawer() → GET /dash/api/history; drawer, loading LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

History drawer opens (loading state)

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Touchpoints render newest-first Touchpoints rendered newest-first sorted descending by When LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Touchpoints rendered newest-first

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 Read each row — type tag + timestamp PILL next to the name Each row carries a type tag (email / phone call / note / payment / contract signed / appointment booked) + a timestamp PILL next to the name 📧 · ☎ · 📝 · 💳 · ✍ · 📅 type from Type/Channel; icons per type LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

Each row: type tag with icon (📧/☎/📝/💳/✍/📅) + timestamp PILL next to the name

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

4 Read an email touchpoint Email touchpoint shows DIRECTION (received-from vs sent-to), SUBJECT as the title, and full body ONCE „Reply to the proposal" subject→title; direction tag; body shown once, not truncated LIVE ✅PENDING
Step 4 — live test transcript
① Before the shot — "What should I see?"

DIRECTION tag, SUBJECT as title '„Reply to the proposal"', full body shown once (not truncated)

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

5 Add a note in the relocated Note composer inside this panel Note composer inside the Full history panel private note… POST /dash/api/note (Note button removed from the card) LIVE ✅PENDING
Step 5 — live test transcript
① Before the shot — "What should I see?"

Note composer visible inside the panel; note submitted via POST /dash/api/note

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-70 Manual move into Contacted via the status dropdown edge 📐 Coverage board-S9 PENDING ⏳

Who: Mátyás (operator)  ·  When: On any non-new-lead card with no upcoming appointment

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 On any non-new-lead card with no upcoming appointment, open the status dropdown Status dropdown opens LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Status dropdown opens

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Select 'Contacted — No Appointment Booked' Card moves to 'Contacted — No Appointment Booked' Contacted — No Appointment Booked optimistic move + bg sync; membership rule: every non-new-lead contact with no upcoming appt belongs here LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Card in 'Contacted — No Appointment Booked'

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

Contacted Sequence(7 scenarios)

WJ-10 Send Emails → arm sequence → Contacted column happy live-S2duo2-S01board-S7 PENDING ⏳

Who: Mátyás (operator)  ·  When: A New-lead card is on the board

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Click 'Send Emails' on a New-lead card Sequence edit-and-arm modal opens immediately, preloaded with all copies Send Emails opens the sequence edit-and-arm modal; modal loads immediately, preloaded with all copies LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Sequence modal opens immediately, preloaded with all copies

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Review the steps: subject, body, per-step wait, version dropdown Modal shows steps with subject, body ({first_name}/{booking_link}), per-step wait (0 = azonnal), version dropdown Automatikus szekvencia — szerkeszd és élesítsd /dash/api/seq/preview; nicer layout + a bit of colour LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Modal title 'Automatikus szekvencia — szerkeszd és élesítsd'; steps with subject, body ({first_name}/{booking_link}), per-step wait (0=azonnal), version dropdown

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 Edit a body — the 3-option save reveals; bodies auto-grow 3-option save: 'Mentés mint: Csak ennél a leadnél · Alapértelmezett · Új verzió'; textarea auto-grows Mentés mint: Csak ennél a leadnél · Alapértelmezett · Új verzió no standalone on-card 'review & arm' block exists LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

3-option save: 'Mentés mint: Csak ennél a leadnél · Alapértelmezett · Új verzió'; textarea auto-grows

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

4 Click 'Mentés és élesítés' 'Mentés és élesítés' button is the single arm entry Mentés és élesítés define(replace) → arm(); first step scheduled in the 06:12–18:00 Mon–Fri window; Q13 human-gate honored (nothing sends until armed) LIVE ✅PENDING
Step 4 — live test transcript
① Before the shot — "What should I see?"

Modal closes (or transitions); sequence armed

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

5 Card LEAVES 'New lead' → lands in 'Contacted — No Appointment Booked' Card in 'Contacted — No Appointment Booked' with dim overlay + blue dashed border + tags Auto: Nem elért lead · 1/2 · köv: 06.20 17:55 optimistic move + bg sync; dim overlay + blue dashed border + tags; New lead stays sequence-free LIVE ✅PENDING
Step 5 — live test transcript
① Before the shot — "What should I see?"

Card in 'Contacted — No Appointment Booked'; dim overlay + blue dashed border + tags: 'Auto: Nem elért lead · 1/2 · köv: 06.20 17:55'

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-11 Send Emails → arm sequence → Contacted column happy board-S7board-S10bnf-r3-S2 PENDING ⏳

Who: Mátyás (operator)  ·  When: A New-lead card is on the board

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Click 'Send Emails' on a New-lead card Sequence edit-and-arm modal opens immediately, preloaded with all copies Send Emails opens the sequence edit-and-arm modal; modal loads immediately, preloaded with all copies LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Sequence modal opens immediately, preloaded with all copies

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Review the steps: subject, body, per-step wait, version dropdown Modal shows steps with subject, body ({first_name}/{booking_link}), per-step wait (0 = azonnal), version dropdown Automatikus szekvencia — szerkeszd és élesítsd /dash/api/seq/preview; nicer layout + a bit of colour LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Modal title 'Automatikus szekvencia — szerkeszd és élesítsd'; steps with subject, body ({first_name}/{booking_link}), per-step wait (0=azonnal), version dropdown

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 Edit a body — the 3-option save reveals; bodies auto-grow 3-option save: 'Mentés mint: Csak ennél a leadnél · Alapértelmezett · Új verzió'; textarea auto-grows Mentés mint: Csak ennél a leadnél · Alapértelmezett · Új verzió no standalone on-card 'review & arm' block exists LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

3-option save: 'Mentés mint: Csak ennél a leadnél · Alapértelmezett · Új verzió'; textarea auto-grows

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

4 Click 'Mentés és élesítés' 'Mentés és élesítés' button is the single arm entry Mentés és élesítés define(replace) → arm(); first step scheduled in the 06:12–18:00 Mon–Fri window; Q13 human-gate honored (nothing sends until armed) LIVE ✅PENDING
Step 4 — live test transcript
① Before the shot — "What should I see?"

Modal closes (or transitions); sequence armed

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

5 Card LEAVES 'New lead' → lands in 'Contacted — No Appointment Booked' Card in 'Contacted — No Appointment Booked' with dim overlay + blue dashed border + tags Auto: Nem elért lead · 1/2 · köv: 06.20 17:55 optimistic move + bg sync; dim overlay + blue dashed border + tags; New lead stays sequence-free LIVE ✅PENDING
Step 5 — live test transcript
① Before the shot — "What should I see?"

Card in 'Contacted — No Appointment Booked'; dim overlay + blue dashed border + tags: 'Auto: Nem elért lead · 1/2 · köv: 06.20 17:55'

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-12 BUG-01 — follow-up sequence dispatches Email 2 (min-interval enforced) failure duo2-S01 PENDING ⏳

Who: Mátyás  ·  When: A ZZ sentinel lead is armed into a contacted-not-booked sequence. DECISION: the UI enforces a minimum interval ≥ the 3-min cron cadence (5 min); the dispatch bug (Email 2 never firing) is fixed regardless.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Open the sequence modal on a ZZ lead card by clicking the 'send emails' button, try to set a 1-minute interval between Email 1 and Email 2 The UI blocks the sub-minimum interval and tells the operator the minimum (5 min); the sequence cannot be armed with < 5 min Copy: Minimum interval is 5 minutes · Look: inline validation message near the interval field · Where: sequence modal The sequence engine only ticks every 3 min, so intervals shorter than the 5-min minimum are not honoured and are rejected at input The UI must NOT silently accept a sub-cadence interval that can never be honoured on time LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Inline validation message "Minimum interval is 5 minutes" near the interval field in the sequence modal

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Set a valid interval (5 minutes), click 'Send & schedule' Card shows the armed-sequence look (dimmed background + blue dashed border); History shows Email 1 'Sent' and Email 2 'Scheduled', and the history shows the correct dates Copy: Scheduled · Look: yellow 'Scheduled' tag · Where: right-side History panel seqflow armed; Email 1 dispatched; Email 2 enqueued with a 5-min due time; scheduled-email dates shown in history are correct No email is sent to a real lead (ZZ sentinel only); AUTOSEND is never flipped; the scheduled dates shown must NOT be wrong LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Card shows dimmed background + blue dashed border; History panel shows Email 1 with green/normal 'Sent' tag and Email 2 with yellow 'Scheduled' tag with correct due date

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 At the due time the 3-min sequence cron evaluates due steps At/after its due time, Email 2 flips from 'Scheduled' to 'Sent' in the History panel at the next cron tick Copy: Sent · Look: green/normal 'Sent' tag (no longer yellow) · Where: History panel Email 2 is dispatched and the seqflow advances to the next step or completes Email 2 must NOT remain stuck on 'Scheduled' indefinitely; the sequence must NOT silently lock with no state change LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

Email 2 shows green/normal 'Sent' tag (no longer yellow 'Scheduled') in History panel at the next cron tick after due time

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-13 Lead replies mid-sequence → resurface to New Lead top recovery board-S11 PENDING ⏳

Who: System / Lead  ·  When: Lead replies while the sequence is armed

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Lead replies while the sequence is armed Lead reply received mid-sequence Bocs a késésért — igen, érdekel, beszéljünk! sequences.cancel(); stamp last_reply_at; sequence stopped LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

sequences.cancel() called; last_reply_at stamped; sequence stopped

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Card LEAVES the Contacted column → resurfaces to the TOP of 'New lead', pulsing Card at top of 'New lead' column, pulsing; absent from Contacted rank() replyAt desc → first; pulse-unread, sequence-free again LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Card at top of 'New lead' column, pulsing; absent from Contacted column

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-14 BUG-02 — manual action on an armed-sequence lead clears the blue-dashed 'Unreachable' border failure live-S8duo2-S03 PENDING ⏳

Who: Mátyás (operator)  ·  When: A ZZ lead is on an armed 'new_lead_unreachable' sequence — card is dimmed with a blue-dashed border

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 A ZZ lead on an armed 'new_lead_unreachable' sequence — card is dimmed with a blue-dashed border Card: dimmed + blue-dashed border board_view._seqflow returns {armed:true}; isPassive(d)=true via sf.armed; card.seqflow.armed=true → dimmed/dashed LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Card: dim overlay + blue-dashed border

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Take a manual action (log a reached call, or book the call) Manual action taken the manual-action path now calls sequences.stop(deal,'manuális akció') (mirrors the inbound-reply teardown) + _cache.pop('board'); seq_steps/seq_armed_at cleared → seqflow=null LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

sequences.stop(deal,'manuális akció') called; _cache.pop('board'); seq_steps/seq_armed_at cleared; seqflow=null

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 The card reverts to a normal (non-dimmed, no-dashed-border) visual state Card: no dim overlay; no blue-dashed border isPassive(d)=false; board reconciled via fresh=1; card not dimmed — BUG-02 fixed; the dashed border tracks a live armed sequence only LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

Card: no dim overlay; no blue-dashed border

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-15 Reschedule & cancel confirmation emails use a 'kattints ide' text link happy bnf-r3-S3 PENDING ⏳

Who: System  ·  When: A booked lead opens the Google-Meet confirmation email and the reschedule/cancel emails.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Lead opens the reschedule-confirmation email A 'kattints ide' hyperlinked phrase, NOT a raw https://… URL pasted in the body. Copy: kattints ide · Look: inline text hyperlink (underlined link text), not a bare URL · Where: in the email body where the link is referenced The raw URL string must not be shown as the visible link text. LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Email body shows "kattints ide" as an inline text hyperlink (underlined), not a raw URL

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Lead opens the cancel (lemondás) email and clicks the cancel link A WORKING 'kattints ide' cancel link (today there is no working link at all). Copy: kattints ide · Look: inline text hyperlink · Where: in the cancel email body Clicking it actually cancels the booking and frees the calendar slot. The cancel email must not ship a dead/broken link or a bare URL. LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Email body shows working "kattints ide" inline hyperlink; clicking it cancels the booking

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-56 Negative-Replies misroute — card stays in Contacted-No-Alignment guardrail 🐛 Bug-fixtonight live-test-transcript-2026-06-26 PENDING ⏳

Who: System  ·  When: A cold/inbound reply triggers the Contacted-No-Alignment sequence; the card should stay there.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 ZZ lead reply/sequence start: trigger inbound reply → Contacted-No-Alignment sequence arms Card in Contacted-No-Alignment column Copy: ZZ card in Contacted-No-Alignment · Look: standard board card · Where: Contacted-No-Alignment column sequence armed; stage_key maps to Contacted-No-Alignment; no negative-reply classification event MUST NOT auto-advance to Negative Replies without a real negative-reply classification LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Card visible in Contacted-No-Alignment column

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Wait and refresh board without any further action Card REMAINS in Contacted-No-Alignment — no auto-jump occurred Copy: ZZ card still in Contacted-No-Alignment · Look: same card position · Where: Contacted-No-Alignment column no automated stage transition; Negative Replies requires an explicit negative-reply classification event Card MUST NOT auto-jump to Negative Replies with no trigger LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Card still in Contacted-No-Alignment after refresh; NOT moved to Negative Replies

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

Booked(11 scenarios)

WJ-16 Lead self-books → card moves to Booked, dim persists until day-before, scheduled emails leave history happy duo2-S04duo2-S10bnf-r3-S4 PENDING ⏳

Who: System  ·  When: A lead in Contacted (with an ARMED Booking-Follow-Up sequence) self-books a call via its unique booking link for a date in the future.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Lead picks a slot on its booking page and confirms The card moves from Contacted to the Booked column. Copy: lead name + 'Booked' / appointment date · Look: Booked-column card · Where: Booked column deal_col becomes the Booked column; the armed booking-follow-up sequence is disarmed (sf.armed=false) and its queued emails are removed. The card must not stay in Contacted; no further booking-follow-up email may send after booking. LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Card moved from Contacted to Booked column showing lead name + appointment date

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 The Booked card's dim overlay The Booked card stays DIMMED while the appointment is still far off. Copy: appointment date tag · Look: dimmed/passive card (greyed overlay) · Where: Booked column The dim persists until 00:00 of the calendar day BEFORE the appointment, then the card switches to the full (undimmed) active look. The card must not lose its dim immediately on booking (the I4 bug), and must not stay dimmed forever (the armedSeq-stuck bug). LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Booked card shows dimmed/greyed (passive) overlay while appointment is far off; dim clears at 00:00 of the day before

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 Operator opens the booked card's history panel The history panel shows the booking + real touchpoints, but NOT the now-cancelled scheduled emails. Copy: no 'Scheduled email #N' rows for the booking-fup sequence · Look: clean history timeline · Where: the card's history/timeline panel The previously-scheduled booking-follow-up emails are gone from history. Stale 'Scheduled email' entries from the disarmed sequence must not linger in history (the I6 bug). LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

History panel shows booking + real touchpoints only; no 'Scheduled email #N' rows for booking-fup sequence

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-17 Lead self-books → card moves to Booked, dim persists until day-before, scheduled emails leave history happy bnf-r3-S4board-S12board-S15 PENDING ⏳

Who: System  ·  When: A lead in Contacted (with an ARMED Booking-Follow-Up sequence) self-books a call via its unique booking link for a date in the future.

⚠ Merge conflict — when booked-card dim overlay lifts
bnf-r3-S4Booked card stays DIMMED until 00:00 of the calendar day BEFORE the appointment; dim lifts on the day-before, not immediately and not on appointment day
board-S15Card is ACTIVE (no overlay) when due date is today OR overdue; booked call on appointment day → ACTIVE (due ≤ today wins over sequence-dim)
✔ Resolution: pass-if-any-variant — this step passes if the observed screenshot matches ANY listed variant.
#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Lead picks a slot on its booking page and confirms The card moves from Contacted to the Booked column. Copy: lead name + 'Booked' / appointment date · Look: Booked-column card · Where: Booked column deal_col becomes the Booked column; the armed booking-follow-up sequence is disarmed (sf.armed=false) and its queued emails are removed. The card must not stay in Contacted; no further booking-follow-up email may send after booking. LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Card moved from Contacted to Booked column showing lead name + appointment date

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 The Booked card's dim overlay The Booked card stays DIMMED while the appointment is still far off. Copy: appointment date tag · Look: dimmed/passive card (greyed overlay) · Where: Booked column The dim persists until 00:00 of the calendar day BEFORE the appointment, then the card switches to the full (undimmed) active look. The card must not lose its dim immediately on booking (the I4 bug), and must not stay dimmed forever (the armedSeq-stuck bug). LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Booked card shows dimmed/greyed (passive) overlay while appointment is far off; dim clears at 00:00 of the day before

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 Operator opens the booked card's history panel The history panel shows the booking + real touchpoints, but NOT the now-cancelled scheduled emails. Copy: no 'Scheduled email #N' rows for the booking-fup sequence · Look: clean history timeline · Where: the card's history/timeline panel The previously-scheduled booking-follow-up emails are gone from history. Stale 'Scheduled email' entries from the disarmed sequence must not linger in history (the I6 bug). LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

History panel shows booking + real touchpoints only; no 'Scheduled email #N' rows for booking-fup sequence

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-18 Booking availability — gcal busy respected, weekday 08:30–18:30, 30-min slots, 15-min buffer after calls edge bnf-r3-S5 PENDING ⏳

Who: System  ·  When: A lead opens its booking page; matyas@clientsflow.hu Google Calendar has some busy blocks and an existing system-booked call.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Lead views the slot grid on the booking page Only valid 30-minute slots, all on weekdays between 08:30 and 18:30 (Europe/Budapest). Copy: 08:30, 09:00, …, 18:00 weekday slots · Look: available-slot buttons · Where: the booking page slot grid Times blocked in the Google Calendar are not offered; weekends and out-of-hours times are absent. A slot overlapping a calendar busy block, a weekend, or outside 08:30–18:30 must not be bookable. LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Slot grid shows only 30-min weekday slots between 08:30–18:30; no weekend or out-of-hours slots; no busy-block slots

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Lead looks at the slot immediately after an existing booked call No slot starts within 15 minutes after a booked call ends. Copy: the 15-min-gap slot is absent · Look: missing/disabled slot button · Where: slot grid, right after a booked call The first offered start after a booked call is ≥ 15 minutes later. A back-to-back slot (0-min gap) after a booked call must not be offered. LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

No slot button visible within 15 minutes after a booked call ends; first slot ≥ 15 min gap

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-19 S5 — B3 — Google Calendar invite reliably reaches the lead happy ext-S5ext-S6 PENDING ⏳

Who: Gergő (Lead)  ·  When: A booking is created for a ZZ lead.

⚠ Merge conflict — GCal invite delivery outcome
ext-S5Invite reaches the lead's inbox AND the rep (matyas@clientsflow.hu); Foglalás touchpoint logged with '...naptármeghívó kiküldve'
ext-S6Workspace/DWD config blocks the invite; system creates 'Naptár meghívó sikertelen' warning touchpoint (⚠️); QA does NOT mark this step green — flags as owner action
✔ Resolution: pass-if-any-variant — this step passes if the observed screenshot matches ANY listed variant.
#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 On booking, a Google Calendar invite is created with lead + rep as attendees Invite reaches the lead's inbox AND the rep (matyas@clientsflow.hu) Copy: Google Calendar invite email · Look: standard GCal invite · Where: lead inbox + rep inbox create_meet_event called with lead in attendees[] and sendUpdates='all' Booking must NOT silently succeed with no invite; invite must NOT go only to the rep NEW ENTRY — Type: Foglalás · icon: 📅 · label: 'Foglalás · {datetime}' · description: 'Időpont foglalva, naptármeghívó kiküldve' · timestamp: now LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

GCal invite email in lead inbox AND rep (matyas@clientsflow.hu) inbox

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-20 S9 — B6 — Log Call panel: two buttons, then Book appointment happy ext-S9live-S7board-S8 PENDING ⏳

Who: Mátyás (operator)  ·  When: Mátyás clicks Log Call on a ZZ card and chooses to book an appointment.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Mátyás clicks the 'Log Call' button on a card Log Call panel shows EXACTLY TWO buttons: 'Book appointment' and 'Set FUP date' — nothing else Copy: 'Book appointment' and 'Set FUP date' — only these two · Look: two buttons, no other fields by default (old redundant datetime-local GONE) · Where: inline Log Call panel under the card Panel default state renders only the two entry buttons; standalone cs-{id} datetime-local picker is removed Panel must NOT show the redundant standalone 'Book appointment (optional)' date-picker; no other fields shown until a button is clicked NEW ENTRY (at click, before choosing an action) — Type: Hívás rögzítve · icon: 📞 · label: 'Hívás' · description: 'Hívás rögzítve' · timestamp: now. Updated/replaced if the operator then books or sets FUP. LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Panel shows exactly two buttons: 'Book appointment' and 'Set FUP date'; no other fields

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Mátyás clicks 'Book appointment' Optional CRM note field AND prefilled, fully-EDITABLE Meet event fields: title, description, outgoing email(s), body text, meeting time, duration Copy: Title prefilled 'ClientsFlow konzultáció — {name}'; body text prefilled; all editable; + note + time + duration · Look: form with prefilled but editable inputs · Where: expanded under 'Book appointment' button in Log Call panel Event fields prefilled from the deal and remain user-editable before send Fields must NOT be read-only; editing must NOT be blocked No additional touchpoint yet — the touchpoint is created only when the operator clicks the blue 'Book appointment' send button (step 3). LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Expanded form: title prefilled 'ClientsFlow konzultáció — {name}', body prefilled, note field, time, duration — all editable

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 Mátyás edits a field and clicks the single blue 'Book appointment' send button The edited invite is sent only after the explicit blue 'Book appointment' click (human approve gate); booking created with edited values Copy: blue 'Book appointment' button is the single send entry · Look: one blue button · Where: Book-appointment sub-form in Log Call panel schedule_meeting runs with operator-edited event_name/email_body/time/duration; gcal invite sent NOTHING sent without explicit click; AUTOSEND never flipped; ZZ fixtures only UPDATED ENTRY — Type: Foglalás (manuális) · icon: 📅 · label: 'Foglalás · {datetime}' · description: 'Időpont rögzítve, meghívó elküldve (manuális). Megjegyzés: {note}' · timestamp: now · initiated_by: operator LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

Booking created and invite sent with operator-edited values; Foglalás (manuális) touchpoint in history

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

4 On a separate card, Mátyás clicks 'Log Call' then 'Set FUP date' 'Set FUP date' reveals a NOTE field + a follow-up DATE picker only — nothing about booking an invite Copy: note textarea + follow-up date input · Look: small form with note field + date picker · Where: expanded under 'Set FUP date' in Log Call panel Follow-up date + note captured (logCall path with FUP date) FUP path must NOT show Meet-event/booking fields; setting FUP must NOT send any invite or email NEW ENTRY — Type: Hívás + Visszahívás · icon: 📞 · label: 'Hívás · FUP: {fup_date}' · description: 'Visszahívás ütemezve: {fup_date}. Megjegyzés: {note}' · timestamp: now LIVE ✅PENDING
Step 4 — live test transcript
① Before the shot — "What should I see?"

Expanded sub-form: note textarea + follow-up date input only

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-21 S4 — B2 — Lead-side reschedule succeeds happy ext-S3ext-S4duo2-S06 PENDING ⏳

Who: Gergő (Lead)  ·  When: Gergő reschedules to a new valid time from the lead side.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Gergő picks a new valid slot and confirms Success confirmation: appointment moved to the NEW time, no error Copy: 'Időpont átütemezve {new time}' · Look: plain success, no error · Where: lead-side reschedule page Deal's appointment datetime updated; old slot cleared No error shown; no duplicate booking; old slot not still blocked No touchpoint yet — the reschedule touchpoint is created after the CRM update (step 3). At this point the history is unchanged from the operator side. LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Success confirmation 'Időpont átütemezve {new time}', no error styling

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Card STAYS in the Booked column, showing the NEW date ZZ card still under 'Booked / Sales Call Prep', updated date Copy: new appointment date/time on the card · Look: normal Booked-column card, updated · Where: 'Booked / Sales Call Prep' column stage_key stays at booked-mapped value; card does NOT leave Booked Card must NOT move to another column; date must NOT be the old one No new touchpoint for the column-stay (no column change). History is unchanged at this step. LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Card still under 'Booked / Sales Call Prep', showing new appointment date

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 History gets a RESCHEDULE entry New history entry recording the reschedule (old → new time) Copy: 'Átütemezés' · Look: reschedule-type pill · Where: card's history/touchpoints list Reschedule touchpoint appended History must NOT drop the reschedule; must not mislabel it as a fresh booking NEW ENTRY — Type: Átütemezés · icon: 🔄 · label: 'Átütemezés' · description: 'Régi: {old datetime} → Új: {new datetime}' · timestamp: now · initiated_by: lead LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

History entry: label 'Átütemezés', description 'Régi: {old datetime} → Új: {new datetime}', icon 🔄

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

4 Updated calendar invite sent to lead + rep Updated Google Calendar invite for the NEW time reaches the lead's email and the rep Copy: calendar invite with new time · Look: Google Calendar invite email · Where: lead inbox + rep inbox create_meet_event runs with attendees + sendUpdates='all' for new time; old event deleted Do NOT fake-green if invite blocked by Workspace / DWD config — FLAG as owner action NEW ENTRY — Type: Meghívó elküldve · icon: 📅 · label: 'Naptár meghívó · Átütemezés' · description: 'Naptármeghívó kiküldve az új időpontra: {new datetime}' · timestamp: now LIVE ✅PENDING
Step 4 — live test transcript
① Before the shot — "What should I see?"

Google Calendar invite email with new time in lead inbox AND rep inbox

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-22 Won deal → delivery in Studio + Cloudflare publish; ONE unified pipeline view (no separate handoff state) happy studio-S12 PENDING ⏳

Who: Mátyás  ·  When: The deal is won (deposit/payment). There is NO separate "Dev handoff" pipeline state. The old dev process is REPLACED by the ClientsFlow Studio review tool: from Studio a project is published via the Cloudflare API (already built). Pipeline management is unified — one pipeline view. When Dani is later brought in, he sees the same pipeline view and simply knows which pipeline stage he must watch.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 The deal is won; delivery continues IN the same pipeline view — no separate handoff stage is created The won deal's card keeps its approved-design link; delivery happens through the Studio review tool (no new "Dev handoff" column/task spawns) Copy: "Megnyitás Studióban — jóváhagyott dizájn" stays on the card · Look: the SAME pipeline card, advanced to the won/delivery stage · Where: the single unified pipeline board No studio_handoff stage or separate handoff task; the approved Studio project id stays bound to the deal; delivery is driven from Studio Must NOT create a separate dev-handoff pipeline state or a parallel task list; must NOT split delivery out of the pipeline view; must NOT link to an unapproved/older version Type: reschedule · icon: 🔁 · label: "Manuális átütemezés" · description: "Az egyeztetett időpont manuálisan módosítva: {old_time} → {new_time} (forrás: Google Calendar)" · source: manual · timestamp: gcal_watch event time · initiated_by: operator LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Same unified pipeline card advanced to won/delivery stage; "Megnyitás Studióban — jóváhagyott dizájn" link present; no new "Dev handoff" column or task spawned

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 From Studio, the project is published live The approved design is published to the web via the Cloudflare API (already built); the live URL is reflected back on the deal Copy: chip/marker "🌐 Publikálva" + live URL · Look: published-state marker on the card · Where: card status + Details panel Studio → Cloudflare publish (existing capability); resulting live URL stored on the deal and reflected in the pipeline Must NOT require a manual out-of-band deploy; must NOT publish an unapproved version; must NOT lose the live URL on the deal record Type: Studio · icon: 🌐 · label: "Publikálva (Cloudflare)" · description: "A jóváhagyott dizájn élesítve a Cloudflare API-n keresztül — {live_url}" · timestamp: now · initiated_by: operator LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Card shows "🌐 Publikálva" marker with live URL on card status and Details panel

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 (Later) Dani is brought in to help with delivery Dani opens the same pipeline view — no special handoff surface; he simply watches the pipeline stage he is responsible for Copy: same board, same cards · Look: identical unified pipeline view · Where: the single shared pipeline board Dani has access to the same pipeline (no separate handoff app/view); his focus is a known pipeline stage, not a bespoke handoff task Must NOT build a second, Dani-only view or a parallel handoff board; must NOT fragment the pipeline into separate sales/delivery tools No new touchpoint for Dani viewing the board. The won/published entries above remain the delivery record. LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

Dani sees the identical unified pipeline board and same cards — no separate handoff surface

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-23 BUG-05 — booking widget gives instant (zero-latency) feedback happy duo2-S05 PENDING ⏳

Who: System  ·  When: A lead picks a slot on the booking widget and confirms.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Select a date/time on the booking widget and click submit/confirm The button immediately disables and a spinner renders; an optimistic success state appears within ~2 seconds, independent of backend completion Copy: Booking… → Confirmed ✓ · Look: disabled button + spinner, then a success check · Where: centre of the booking widget Optimistic UI shown on click; the backend transaction completes in the background The UI must NOT appear frozen with no feedback for several seconds after the click LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Button immediately disabled with spinner; optimistic "Confirmed ✓" success state appears within ~2 seconds

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-60 Timezone — Budapest everywhere (CRM, pipeline, Notion, GCal incl. invite title) guardrail 🐛 Bug-fixtonight live-test-transcript-2026-06-25 PENDING ⏳

Who: System  ·  When: A booking is made by a person in any timezone; times are displayed in CRM, board, Notion, and GCal.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Book a ZZ appointment for a specific Budapest time (e.g. 14:00 Budapest/Europe/Budapest) Card on board shows the correct Budapest time; Notion log shows the correct Budapest time Copy: '14:00' (or the booked Budapest time) · Look: time displayed Budapest-local · Where: board card + Notion log booking stored and displayed as Europe/Budapest; no tz drift MUST NOT show a time offset from Budapest (no ±1–6h drift); MUST NOT show booker's local tz Booking touchpoint: time shown as Budapest-local LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Board card and Notion log both show the correct Budapest time (no tz drift)

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Open the Google Calendar invite for the booked appointment GCal invite BODY and TITLE both show the correct Budapest time — not the booker's local timezone Copy: GCal event title includes Budapest time · Look: invite body and title Budapest-local · Where: Google Calendar event GCal event created with Europe/Budapest timezone; title uses Budapest-local time string GCal invite TITLE must NOT show the booker's local timezone; invite must NOT show a different time than Budapest LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

GCal invite title AND body show Budapest-local time; no booker-tz string in title

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-71 No-show + reschedule (fast modal) recovery 📐 Coverage board-S13 PENDING ⏳

Who: Mátyás (operator)  ·  When: A lead has a Sales Call card on the board; the lead did not show

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 On a Sales-call card, click 'No show + reschedule' 'No show + reschedule' button clicked No show + reschedule logs the no-show outcome in the background LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

'No show + reschedule' button clicked

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 The call-scheduler modal opens ALMOST INSTANTLY Call-scheduler modal 'Hívás ütemezése' opens almost instantly Hívás ütemezése reuses the Log Call inline framework + the same input fields; no ~1-min wait FAIL -> opens only after ~1 min (current blocking await) LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Modal 'Hívás ütemezése' open almost instantly

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 Set a new time and submit Booking created with new time Esemény létrehozása /dash/api/call/schedule LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

New booking created with the new time

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-72 No-show + no answer → rebook (slide + modal + long seq) recovery 📐 Coverage board-S14 PENDING ⏳

Who: Mátyás (operator)  ·  When: A lead has a Sales Call card; the lead did not show and did not answer

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Click 'No show + no answer → rebook seq.' 'No show + no answer → rebook seq.' button clicked No show + no answer → rebook seq. /dash/api/outcome {no_show} LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

'No show + no answer → rebook seq.' button clicked

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Card SLIDES (animated) into 'Contacted — No Appointment Booked' immediately Card slides (animated) into 'Contacted — No Appointment Booked' immediately — instant visual feedback optimistic move + animation; instant visual feedback FAIL -> long blocking with no feedback (current) LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Card slides (animated) into 'Contacted — No Appointment Booked' immediately

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 After ~1s the redesigned sequence modal opens for the rebook copies Sequence modal 'Automatikus szekvencia — szerkeszd és élesítsd' opens ~1s after the slide Automatikus szekvencia — szerkeszd és élesítsd openSeqModal LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

Sequence modal 'Automatikus szekvencia — szerkeszd és élesítsd' opens ~1s after slide

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

4 Set a LONG rebook sequence, click 'Mentés és élesítés' Card lands as an on-sequence card in the Contacted column Mentés és élesítés define + arm; lands as an on-sequence card in the Contacted column LIVE ✅PENDING
Step 4 — live test transcript
① Before the shot — "What should I see?"

Card shows on-sequence visual state (dim + blue dashed border) in Contacted column

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

Sales Call(9 scenarios)

WJ-24 Transcription on a Google Meet call (Fireflies bot-free, else auto-join Note Taker) edge bnf-r3-S6 PENDING ⏳

Who: System  ·  When: A Google Meet sales call has ≥2 real participants present.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Research gate: confirm whether Fireflies can record the Meet WITHOUT a visible joining bot (bot-free capture) and whether every criterion for it is met A recorded decision: bot-free recording is available & all criteria met → use it; otherwise fall back to the Note Taker bot. Branch A (bot-free) if criteria met; Branch B (auto-join bot) otherwise. Do not ship a guessed integration — the bot-free criteria must be actually verified. LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

A recorded decision: bot-free OR Note Taker bot path selected and documented

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Branch B fallback — Fireflies notetaker bot auto-joins when ≥2 people are already in the meeting If the bot path is used: a participant named 'Note Taker' with a boring profile image joins once ≥2 real people are present. Copy: Note Taker · Look: plain/boring profile avatar · Where: the Meet participant list The transcript is captured and lands in the CRM for that call. The bot must not join an empty/1-person call; it must not show the default Fireflies branding/name. LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Participant named 'Note Taker' with plain/boring profile image joins once ≥2 real people are present

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-25 Sales-call card shows a 'call done' tag (+ duration) and a transcript-status tag happy bnf-r3-S7 PENDING ⏳

Who: Mátyás  ·  When: A lead is in the Sales Call / Proposal column and the sales call has happened.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Operator looks at the card in the Sales Call/Proposal column A tag stating the sales call happened, with the call duration if known. Copy: pl. 'Sales call megvolt · 32 perc' · Look: status pill/tag · Where: on the Sales-Call/Proposal card The tag reflects the logged call-completed touchpoint + duration. The tag must not appear before the call actually happened. LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Status pill/tag reads e.g. "Sales call megvolt · 32 perc" on the card

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 A second tag below it shows transcript status A second tag under the call tag showing transcript state: a loading animation while fetching, 'hiányzik/missing' if none, or 'megvan/done' once the transcript text file is in the CRM. Copy: 'Transcript: betöltés…' / 'Transcript: hiányzik' / 'Transcript: megvan' · Look: secondary tag; loading variant has a spinner/animation · Where: directly beneath the 'sales call done' tag on the card The tag tracks the real transcript ingestion state for that call. It must not show 'done' when no transcript file exists in the CRM. LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Second tag directly beneath call-done tag shows one of: 'Transcript: betöltés…' (with spinner) / 'Transcript: hiányzik' / 'Transcript: megvan'

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-26 After the call: transcript saved into the CRM + auto-pushed into Studio (Phase ②) happy studio-S6 PENDING ⏳

Who: System  ·  When: The sales call happened and a Fireflies transcript exists. The transcript is (a) saved into the CRM and (b) auto-pushed into Studio to feed Phase-② refinement (Q7). Owner requirement S61: both the full transcript AND the summary are stored inside collapsible toggles, in BOTH the touchpoint-history panel AND the 'Details' panel.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 (Automatic) the sales-call transcript becomes available after the call The transcript is saved into the CRM (this deal) AND pushed into the Studio project's intake; a summary is generated alongside the full transcript Copy: CRM-side "Hívás jegyzőkönyv" + "Összefoglaló"; Studio intake resource "Sales hívás jegyzőkönyv" · Look: classified resource card in Studio + saved transcript on the deal · Where: CRM deal (history + Details) AND Studio project intake panel Transcript + summary persisted on the deal (CRM); Pipeline → Studio POST /api/projects/{id}/resources {text, kind_hint:"transcript"}; classify chain runs in Studio Must NOT require the rep to copy-paste the transcript; must NOT push the warmup/no-show noise — only the real call transcript; must NOT push to Studio WITHOUT also saving it into the CRM; must NOT store the transcript/summary in only ONE of the panels (both touchpoint-history AND Details panel must show the collapsible toggles); must NOT flatten the content (it MUST be inside collapsible ▸ toggles) Type: Studio · icon: 📝 · label: "Hívás jegyzőkönyv mentve + átküldve" · description: "Sales-hívás jegyzőkönyv a CRM-be mentve és a Studio intake-be került (Phase ② finomításhoz)" · timestamp: now · initiated_by: system · Toggles in this entry: ▸ "Teljes jegyzőkönyv" (collapsible full transcript) · ▸ "Összefoglaló" (collapsible summary) LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

CRM deal shows "Hívás jegyzőkönyv" + "Összefoglaló"; Studio intake panel shows "Sales hívás jegyzőkönyv" resource card

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Mátyás opens the deal's touchpoint-history panel and/or the 'Details' panel In BOTH panels: two collapsible toggles — ▸ Teljes jegyzőkönyv (full transcript) and ▸ Összefoglaló (summary) — collapsed by default, expand on click Copy: toggle labels "Teljes jegyzőkönyv" / "Összefoglaló" · Look: disclosure-triangle toggles, body hidden until expanded · Where: (a) the call's entry in the touchpoint-history panel AND (b) the 'Details' panel of the deal Both panels read the SAME stored CRM transcript + summary (single source on the deal); no duplication of the underlying data Must NOT show the long transcript inline un-collapsed (it would flood the timeline); must NOT put the toggles in only one of the two panels; must NOT diverge the two copies — both render the same saved transcript/summary The history entry from row 1 IS where the history-panel toggles live (full transcript + summary). The 'Details' panel mirrors the same two toggles. No additional touchpoint is created for opening a toggle. LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

BOTH panels show two collapsed disclosure-triangle toggles: "▸ Teljes jegyzőkönyv" and "▸ Összefoglaló"

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-27 BUG-07 — manual log-call timestamp shows Budapest local time failure duo2-S07 PENDING ⏳

Who: Mátyás  ·  When: The operator logs a manual call at a known wall-clock time (e.g. 14:15 Budapest).

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Log a manual call via the modal at a known local time (e.g. 14:15 Budapest) The touchpoint in the History feed shows the LOCAL Budapest time (14:15), matching the wall clock Copy: 14:15 · Look: timestamp in the feed block · Where: right-side History panel The timestamp is stored as UTC but RENDERED converted to Europe/Budapest The feed must NOT render the raw UTC instant 2 hours behind local time LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

History panel shows the touchpoint timestamp in LOCAL Budapest time (e.g. 14:15), matching wall clock

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-28 BUG-09 — logged call shows the 'Phone call' label failure duo2-S09 PENDING ⏳

Who: Mátyás  ·  When: The operator logs a call with specific notes.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Log a call with specific notes via the Log-call panel The touchpoint history header reads 'Phone call' with the exact notes entered below Copy: Phone call · Look: human-readable label · Where: top-left of the History feed block The event_type is mapped to a human-readable label in the touchpoint renderer The header must NOT render a raw backend string/UUID (e.g. 'event_type_sales_call_init') LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

History feed block header reads 'Phone call' with exact notes below

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-58 No cancel of an occurred meeting — meeting-happened tracking independent of schedule guardrail 🐛 Bug-fixtonight live-test-transcript-2026-06-25 PENDING ⏳

Who: System  ·  When: A sales call has already occurred (participants joined); a later booking or reschedule event fires.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Sales call occurs (participants joined) — system records the meeting-happened event 'Hívás megtörtént' touchpoint on the card with participant names and timestamp Copy: 'Hívás megtörtént' touchpoint row · Look: type=call_occurred, participants listed · Where: card history meeting-happened flag stored independent of scheduled_at; participant list saved MUST NOT be confused with the scheduled slot; occurrence is independent of calendar time NEW ENTRY — Type: Hívás megtörtént · icon: ✅ · participant names · timestamp: actual join time (Budapest) LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

'Hívás megtörtént' touchpoint visible in card history with participant list

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 A later new booking or reschedule event fires for the same lead The occurred meeting touchpoint REMAINS; NO cancellation email is sent for it Copy: history still shows 'Hívás megtörtént' row unchanged · ZZ inbox: NO cancellation email for the past event cancel-event logic MUST check occurred flag before sending cancellation; occurred meetings are never auto-cancelled MUST NOT send a cancellation email for the already-occurred meeting; MUST NOT remove the 'hívás megtörtént' touchpoint LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

'Hívás megtörtént' touchpoint still in history; ZZ inbox has NO cancellation email for the past meeting

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-59 Transcript→Notion save latency — transcript saves promptly (no multi-minute lag) edge 🐛 Bug-fixtonight live-test-transcript-2026-06-25 PENDING ⏳

Who: System  ·  When: After a sales call, the Fireflies transcript is ingested and saved to Notion.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Fireflies transcript webhook fires after the call Transcript appears in the correct Notion Call-recordings DB PROMPTLY (within expected window) Copy: Notion Call-recordings DB entry for the call · Look: transcript saved promptly · Where: Notion DB + card history Fireflies webhook → transcript_ingest → Notion write → card update; all within acceptable latency MUST NOT require a multi-minute wait before transcript appears; MUST NOT save to wrong DB NEW ENTRY — Type: Átírás kész · icon: 📝 · label: 'Átírás kész' · timestamp: promptly after ingest LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Notion Call-recordings DB shows transcript entry; card shows 'transcript ready' touchpoint promptly

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-64 Sales-call 'ready' card — visual effect + tag + signing button after processing happy 🆕 Build tonighttonight owner-directive-2026-06-25 PENDING ⏳

Who: System  ·  When: After a sales call occurs, transcript + summary processing completes.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Sales call processing completes (transcript + summary available) Card on pipeline board shows visual effect (glow/highlight) indicating 'ready' Copy: visual effect on card (glow, highlight, colour change) · Look: visually distinct from unprocessed cards · Where: pipeline board card processing complete flag set; card re-renders with visual effect in pipeline view MUST NOT require page reload to see the visual effect; must appear within seconds (INV-IMMEDIATE) NEW ENTRY — Type: Sales call feldolgozva · icon: ✅ · label: 'Sales call feldolgozva' · timestamp: now LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Card shows visual effect (glow/highlight/colour) indicating processing complete

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Read the tag on the card '✅ Sales call feldolgozva — küldhető az ajánlat' tag visible on the card IN the pipeline view Copy: '✅ Sales call feldolgozva — küldhető az ajánlat' · Look: tag/badge on card face · Where: pipeline board card (not a separate link/tab) tag rendered from processing-complete state; surfaced in pipeline view MUST NOT require navigating to a separate page/link to see the tag; must be IN the pipeline/CRM view LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

'✅ Sales call feldolgozva — küldhető az ajánlat' tag visible on card in pipeline view

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 Click the 'saját aláíró link' button on the card Issuer signing link opens (our own DocuSeal signing link for the proposal) Copy: 'saját aláíró link' button · Look: button on card face · Where: pipeline board card button opens the issuer's DocuSeal signing link for the proposal associated with this lead MUST NOT open a blank page; MUST NOT require a separate navigation step LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

Issuer DocuSeal signing link opens for the associated proposal

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-65 KEEP — next-contact follow-up option remains available after sales call edge 📌 Keep owner-directive-2026-06-25 PENDING ⏳

Who: Mátyás (operator)  ·  When: At the end of a sales call, the operator decides what to do next.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 After a ZZ sales call, inspect the post-call card options BOTH options visible: 'Send proposal' path AND 'Next contact meeting' booking option Copy: 'Ajánlat küldése' + 'Következő kontakt' (or equivalent) · Look: both action options on card · Where: pipeline board card post-call Both proposal-send and next-contact paths available; neither removed MUST NOT have removed the next-contact option; both paths must remain accessible LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Both 'Send proposal' and 'Next contact meeting' options visible on the post-call card

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Choose 'Next contact meeting' and book a follow-up slot Follow-up meeting booked + reminders armed Copy: 'Következő kontakt' booking confirmed · Look: new booking card or confirmation · Where: pipeline board next-contact booking created; reminders armed (same reminder chain as other bookings) MUST NOT fail silently; reminders must arm on next-contact booking same as on other bookings NEW ENTRY — Type: Következő kontakt · icon: 📅 · label: 'Következő kontakt ütemezve' · timestamp: now LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Follow-up meeting booked; 'Következő kontakt ütemezve' touchpoint on card; reminders armed

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

Proposal(6 scenarios)

WJ-29 Happy spine — post-call wizard → send proposal → card moves to Sign FUP happy live-S1live-S9 PENDING ⏳

Who: Mátyás (operator)  ·  When: Lead is in the Sales Call stage; operator logs a forward (proposal) outcome and sends the proposal

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Click 'Log Call' → 'Forward (proposal)' on the lead's Sales Call card Post-call wizard step 1 opens POST /dash/api/outcome {outcome:'forward'} → flows.api_outcome logs a 'call' touchpoint; stage_key=prepared (col=sales_call); a 'Sales call' touchpoint exists LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Post-call wizard Step 1 opens

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Open the post-call wizard (Step 1) and fill price + 'Kedvezmény érvényessége' (pre-filled today+7) + payment plan Step 1 form with 'Kedvezményes ár (HUF, nettó AAM)' and 'Kedvezmény érvényessége (utána +25%)' fields; 'Kedvezmény érvényessége' pre-filled to today+7 Kedvezményes ár (HUF, nettó AAM) · Kedvezmény érvényessége (utána +25%) POST /dash/api/postcall/preview → dash._postcall_persist_form sets agreed_price, price_expiry_date, proposal_due_date AND price_after_expiry (BUG-04 fix); deal.price_expiry_date set, deal.price_after_expiry = price×1.25 set LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Fields visible: 'Kedvezményes ár (HUF, nettó AAM)' · 'Kedvezmény érvényessége (utána +25%)'; 'Kedvezmény érvényessége' pre-filled today+7

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 Click 'Generate proposal preview' (Step 2) Preview HTML shows discounted price with struck-through anchor price + 'érvényes {exp}-ig' POST /dash/api/postcall/preview mode=ai → proposal_doc.generate_proposal_inner; deterministic price box (strike-through + expiry) always-appended by build_proposal_html (BUG-04) LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

Preview HTML: discounted price + <s>full price</s> + 'érvényes {exp}-ig'

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

4 Click 'Route for approval' (Step 3, pcConfirm) Button shows a spinner + disables while the request runs; review approval page opens in a new tab 📝 Jóváhagyó oldal megnyílt — nézd át és hagyd jóvá kézzel. POST /dash/api/postcall/route — button shows spinner + disables while request runs (BUG-05 fix); review approval page opens in a new tab; pcConfirm button disabled during the call LIVE ✅PENDING
Step 4 — live test transcript
① Before the shot — "What should I see?"

Button: spinner + disabled during request; toast '📝 Jóváhagyó oldal megnyílt — nézd át és hagyd jóvá kézzel.'; review page opens in new tab

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

5 On the /review page click 'Finalize' (page 2 → 3) Review page advances to page 3 flows.finalize_proposal → ensure_docuseal_submission + _sync_stage(deal,'proposal_sent'); stage_key=proposal_sent LIVE ✅PENDING
Step 5 — live test transcript
① Before the shot — "What should I see?"

Review page advances to page 3

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

6 On the /review page-3 click 'Küldés + ajánlat-emlékeztető szekvencia előkészítése →' Proposal email sent; board will show card in Sign FUP on next load flows.submit_review_page2 → _send_missive_email + log(deal,'proposal_sent',...,'email') + sequences.define('proposal_chase', un-armed); board cache busted for the web container (BUG-06 fix); stage_key=proposal_sent; 'Proposal sent' (OUT) touchpoint at send-time; proposal_chase DEFINED un-armed LIVE ✅PENDING
Step 6 — live test transcript
① Before the shot — "What should I see?"

Proposal email sent; board cache busted for web container (BUG-06 fix)

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

7 Return to the board — the card is now in the 'Sign FUP' column Card in the 'Sign FUP' column board_view.deal_col maps proposal_sent → sign_fup; loadBoard(true) ?fresh=1 reconciles; card.stage='sign_fup' (visible move) — BUG-06 send leg satisfied LIVE ✅PENDING
Step 7 — live test transcript
① Before the shot — "What should I see?"

Card in 'Sign FUP' column

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-30 Happy spine — post-call wizard → send proposal → card moves to Sign FUP happy bnf-r3-S9live-S1 PENDING ⏳

Who: Mátyás (operator)  ·  When: Lead is in the Sales Call stage; operator logs a forward (proposal) outcome and sends the proposal

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Click 'Log Call' → 'Forward (proposal)' on the lead's Sales Call card Post-call wizard step 1 opens POST /dash/api/outcome {outcome:'forward'} → flows.api_outcome logs a 'call' touchpoint; stage_key=prepared (col=sales_call); a 'Sales call' touchpoint exists LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Post-call wizard Step 1 opens

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Open the post-call wizard (Step 1) and fill price + 'Kedvezmény érvényessége' (pre-filled today+7) + payment plan Step 1 form with 'Kedvezményes ár (HUF, nettó AAM)' and 'Kedvezmény érvényessége (utána +25%)' fields; 'Kedvezmény érvényessége' pre-filled to today+7 Kedvezményes ár (HUF, nettó AAM) · Kedvezmény érvényessége (utána +25%) POST /dash/api/postcall/preview → dash._postcall_persist_form sets agreed_price, price_expiry_date, proposal_due_date AND price_after_expiry (BUG-04 fix); deal.price_expiry_date set, deal.price_after_expiry = price×1.25 set LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Fields visible: 'Kedvezményes ár (HUF, nettó AAM)' · 'Kedvezmény érvényessége (utána +25%)'; 'Kedvezmény érvényessége' pre-filled today+7

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 Click 'Generate proposal preview' (Step 2) Preview HTML shows discounted price with struck-through anchor price + 'érvényes {exp}-ig' POST /dash/api/postcall/preview mode=ai → proposal_doc.generate_proposal_inner; deterministic price box (strike-through + expiry) always-appended by build_proposal_html (BUG-04) LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

Preview HTML: discounted price + <s>full price</s> + 'érvényes {exp}-ig'

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

4 Click 'Route for approval' (Step 3, pcConfirm) Button shows a spinner + disables while the request runs; review approval page opens in a new tab 📝 Jóváhagyó oldal megnyílt — nézd át és hagyd jóvá kézzel. POST /dash/api/postcall/route — button shows spinner + disables while request runs (BUG-05 fix); review approval page opens in a new tab; pcConfirm button disabled during the call LIVE ✅PENDING
Step 4 — live test transcript
① Before the shot — "What should I see?"

Button: spinner + disabled during request; toast '📝 Jóváhagyó oldal megnyílt — nézd át és hagyd jóvá kézzel.'; review page opens in new tab

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

5 On the /review page click 'Finalize' (page 2 → 3) Review page advances to page 3 flows.finalize_proposal → ensure_docuseal_submission + _sync_stage(deal,'proposal_sent'); stage_key=proposal_sent LIVE ✅PENDING
Step 5 — live test transcript
① Before the shot — "What should I see?"

Review page advances to page 3

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

6 On the /review page-3 click 'Küldés + ajánlat-emlékeztető szekvencia előkészítése →' Proposal email sent; board will show card in Sign FUP on next load flows.submit_review_page2 → _send_missive_email + log(deal,'proposal_sent',...,'email') + sequences.define('proposal_chase', un-armed); board cache busted for the web container (BUG-06 fix); stage_key=proposal_sent; 'Proposal sent' (OUT) touchpoint at send-time; proposal_chase DEFINED un-armed LIVE ✅PENDING
Step 6 — live test transcript
① Before the shot — "What should I see?"

Proposal email sent; board cache busted for web container (BUG-06 fix)

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

7 Return to the board — the card is now in the 'Sign FUP' column Card in the 'Sign FUP' column board_view.deal_col maps proposal_sent → sign_fup; loadBoard(true) ?fresh=1 reconciles; card.stage='sign_fup' (visible move) — BUG-06 send leg satisfied LIVE ✅PENDING
Step 7 — live test transcript
① Before the shot — "What should I see?"

Card in 'Sign FUP' column

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-31 Happy spine — post-call wizard → send proposal → card moves to Sign FUP happy live-S1 PENDING ⏳

Who: Mátyás (operator)  ·  When: Lead is in the Sales Call stage; operator logs a forward (proposal) outcome and sends the proposal

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Click 'Log Call' → 'Forward (proposal)' on the lead's Sales Call card Post-call wizard step 1 opens POST /dash/api/outcome {outcome:'forward'} → flows.api_outcome logs a 'call' touchpoint; stage_key=prepared (col=sales_call); a 'Sales call' touchpoint exists LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Post-call wizard Step 1 opens

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Open the post-call wizard (Step 1) and fill price + 'Kedvezmény érvényessége' (pre-filled today+7) + payment plan Step 1 form with 'Kedvezményes ár (HUF, nettó AAM)' and 'Kedvezmény érvényessége (utána +25%)' fields; 'Kedvezmény érvényessége' pre-filled to today+7 Kedvezményes ár (HUF, nettó AAM) · Kedvezmény érvényessége (utána +25%) POST /dash/api/postcall/preview → dash._postcall_persist_form sets agreed_price, price_expiry_date, proposal_due_date AND price_after_expiry (BUG-04 fix); deal.price_expiry_date set, deal.price_after_expiry = price×1.25 set LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Fields visible: 'Kedvezményes ár (HUF, nettó AAM)' · 'Kedvezmény érvényessége (utána +25%)'; 'Kedvezmény érvényessége' pre-filled today+7

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 Click 'Generate proposal preview' (Step 2) Preview HTML shows discounted price with struck-through anchor price + 'érvényes {exp}-ig' POST /dash/api/postcall/preview mode=ai → proposal_doc.generate_proposal_inner; deterministic price box (strike-through + expiry) always-appended by build_proposal_html (BUG-04) LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

Preview HTML: discounted price + <s>full price</s> + 'érvényes {exp}-ig'

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

4 Click 'Route for approval' (Step 3, pcConfirm) Button shows a spinner + disables while the request runs; review approval page opens in a new tab 📝 Jóváhagyó oldal megnyílt — nézd át és hagyd jóvá kézzel. POST /dash/api/postcall/route — button shows spinner + disables while request runs (BUG-05 fix); review approval page opens in a new tab; pcConfirm button disabled during the call LIVE ✅PENDING
Step 4 — live test transcript
① Before the shot — "What should I see?"

Button: spinner + disabled during request; toast '📝 Jóváhagyó oldal megnyílt — nézd át és hagyd jóvá kézzel.'; review page opens in new tab

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

5 On the /review page click 'Finalize' (page 2 → 3) Review page advances to page 3 flows.finalize_proposal → ensure_docuseal_submission + _sync_stage(deal,'proposal_sent'); stage_key=proposal_sent LIVE ✅PENDING
Step 5 — live test transcript
① Before the shot — "What should I see?"

Review page advances to page 3

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

6 On the /review page-3 click 'Küldés + ajánlat-emlékeztető szekvencia előkészítése →' Proposal email sent; board will show card in Sign FUP on next load flows.submit_review_page2 → _send_missive_email + log(deal,'proposal_sent',...,'email') + sequences.define('proposal_chase', un-armed); board cache busted for the web container (BUG-06 fix); stage_key=proposal_sent; 'Proposal sent' (OUT) touchpoint at send-time; proposal_chase DEFINED un-armed LIVE ✅PENDING
Step 6 — live test transcript
① Before the shot — "What should I see?"

Proposal email sent; board cache busted for web container (BUG-06 fix)

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

7 Return to the board — the card is now in the 'Sign FUP' column Card in the 'Sign FUP' column board_view.deal_col maps proposal_sent → sign_fup; loadBoard(true) ?fresh=1 reconciles; card.stage='sign_fup' (visible move) — BUG-06 send leg satisfied LIVE ✅PENDING
Step 7 — live test transcript
① Before the shot — "What should I see?"

Card in 'Sign FUP' column

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-32 (Verify) New lead entry triggers scraper + AI legal/CRM extraction → auto-fills the contract edge bnf-r3-S8 PENDING ⏳

Who: System  ·  When: A brand-new lead enters the pipeline from zero (not a manual move). NOTE: explicitly a next-round VERIFICATION task — needs a real new lead end-to-end.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 A new lead is ingested onto the pipeline After ingestion, the lead's CRM record carries scraped business fields AND legal info (entity type, tax number). enrich_deal + enrich_legal ran and populated the fields. Enrichment must not silently no-op (the live test saw it not run because the lead was moved manually, not ingested from zero). LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Contract generation pulls the enriched legal data The generated contract is pre-populated with the legal entity + tax data from the CRM. The contract's party fields come from the enriched CRM record, no manual typing. The contract must not be left with blank legal fields when the CRM has them. LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Generated contract pre-populated with legal entity + tax data from CRM

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-33 BUG-07 — self-sent proposal email re-ingested by Missive must NOT become an 'Incoming reply' or cancel the sequence failure live-S6 PENDING ⏳

Who: System  ·  When: Missive re-delivers the just-sent proposal mail (from matyas@clientsflow.hu → the lead) to /missive/incoming

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Missive re-delivers the just-sent proposal mail (from matyas@clientsflow.hu → the lead) to /missive/incoming Incoming webhook received flows.handle_missive_incoming; the newest message from_field is one of OUR addresses (_is_ours(from)=True); direction = outbound (self-sent) LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

_is_ours(from_addr)=True; direction=outbound (self-sent)

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 The direction guard drops/marks the message as outbound BEFORE classify + route_inbound No 'Incoming reply' row created for the self-sent mail (no 'Incoming reply' row is created for the self-sent mail) new guard: if _is_ours(from_addr) → return {dropped:'outbound (self-sent)'} (the proposal_sent log already exists from send-time); no reply_received touchpoint minted; classify_email NOT called on our own mail LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

No 'Incoming reply' row created for the self-sent mail

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 The proposal_chase sequence is still armed and the card is still in Sign FUP Card still in Sign FUP; proposal_chase sequence still armed sequences.cancel('lead replied') is NOT reached; _sync_stage(deal,'new_lead',force=True) resurfacing is NOT reached; seq_armed_at intact; stage_key stays proposal_sent (BUG-06 not regressed) — BUG-07 cascade neutralised LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

Card still in Sign FUP; no column change

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-61 Pre-signed proposal — issuer pre-signs + photo/draw sig required + auto-send on both-signed happy 🆕 Build tonighttonight owner-directive-2026-06-25 PENDING ⏳

Who: System  ·  When: A proposal/contract is generated and sent to the client for signing.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Generate and send a proposal/contract via the system Sent DocuSeal document has the issuer signature ALREADY filled in (pre-signed) Copy: issuer signature field shows Mátyás's pre-filled signature · Look: signature already present on the doc · Where: DocuSeal document preview DocuSeal submission created via API with issuer field pre-filled; client is the only remaining signer MUST NOT send a blank issuer signature field requiring Mátyás to sign again; client must be the only outstanding signer LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

DocuSeal document shows issuer signature pre-filled; client-side signature field is empty awaiting client

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Inspect the client-side signature field type on the DocuSeal document Signature field accepts PHOTO or DRAWN signature only — typed text is disabled Copy: signature field type indicator · Look: photo/draw-only signature input · Where: DocuSeal client signing page DocuSeal field definition type=signature (draw/photo); type=text disabled for signature field MUST NOT accept typed-text as a valid signature; typed-text option must be disabled LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Signature field shows photo/draw-only input; no typed-text option visible

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 Both parties sign the document; DocuSeal auto-sends the signed PDF Both parties (issuer + client) receive the signed document automatically via DocuSeal — no manual download/send step Copy: both parties' email inboxes show a DocuSeal 'signed document' email · Look: automatic delivery · Where: issuer + client email inboxes DocuSeal submission config: send_completed_document_to_submitters=true (or equivalent); fires automatically on completion MUST NOT require a manual step to send the signed doc; signed doc must NOT only be downloadable (not emailed) LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

Both issuer and client receive signed PDF email from DocuSeal automatically on completion

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

Sign Followup(2 scenarios)

WJ-34 Sign-Follow-Up card shows offer-validity + reminder index tags happy bnf-r3-S10 PENDING ⏳

Who: Mátyás  ·  When: A lead is in the Sign-Follow-Up column with a proposal that has a validity deadline and an active reminder sequence.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Operator looks at a Sign-Follow-Up card In addition to the next-call-date tag: a tag for how long the offer is valid, and a tag for which reminder of how many this is (e.g. '3/5'). Copy: pl. 'Ajánlat érvényes: jún. 30' és 'Emlékeztető 3/5' · Look: two extra status pills · Where: on the Sign-Follow-Up card, near the existing date tag Tags read the proposal_due_date and the reminder step index/count. The card must not show only the next-call-date tag (the current state). LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Card shows two extra status pills: offer-validity tag (e.g. 'Ajánlat érvényes: jún. 30') and reminder index tag (e.g. 'Emlékeztető 3/5') alongside the existing date tag

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-35 FR-01a overdue — card sits in 'Proposal Signed' > X days with no payment → red border edge live-S5 PENDING ⏳

Who: System  ·  When: A ZZ deal with stage_key=contract_signed and entered_stage_at older than PAYMENT_OVERDUE_DAYS (default 3)

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 A ZZ deal with stage_key=contract_signed and entered_stage_at older than PAYMENT_OVERDUE_DAYS (default 3) Deal in the overdue state (payment_overdue=true computed) board_view computes payment_overdue = (col=='proposal_signed' and days_in_stage > PAYMENT_OVERDUE_DAYS); card.payment_overdue=true LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

payment_overdue=True computed by board_view

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Look at the card on the board — it carries the red overdue border Red overdue border on the card in 'Proposal Signed / Fizetés FUP' dealCard renders the .overdue red-border class when d.payment_overdue; red border visible only for overdue signed-unpaid cards (a fresh-signed card has none) LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Red overdue border visible on the card

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

Payment(5 scenarios)

WJ-36 FR-01a + BUG-06 sign leg — client signs DocuSeal → card moves to 'Proposal Signed / Fizetés FUP' happy bnf-r3-S11live-S3 PENDING ⏳

Who: Lead / System  ·  When: Lead opens the DocuSeal link and signs; rep counter-signs

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Lead opens the DocuSeal link and signs; rep counter-signs DocuSeal signing completed DocuSeal fires submission.completed → flows.handle_docuseal_event → deal.signed=True + _sync_stage(deal,'contract_signed') + log('proposal_signed'); stage_key=contract_signed; 'Contract signed' (doc) touchpoint LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Signing completed in DocuSeal

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Webhook pushes a dash_event so the 'what changed' popup nudges a refresh 'What changed' popup / notification visible on the dash push_dash_event('sign', ...) (added so the webhook-driven move is surfaced despite no client auto-reload); dash_events ring carries the sign event LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

'What changed' popup / notification appears nudging a refresh

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 Refresh / loadBoard(true): the card is now in the 'Proposal Signed / Fizetés FUP' column (NOT Sign FUP) Card in 'Proposal Signed / Fizetés FUP' — NOT in Sign FUP board_view._STAGE_TO_COL maps contract_signed → 'proposal_signed' (split out of sign_fup); BCOLS + STAGES + _COL_TO_STAGE updated in lockstep; card.stage='proposal_signed' — BUG-06 sign leg + FR-01 col 1 satisfied LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

Card in 'Proposal Signed / Fizetés FUP' (not in Sign FUP)

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-37 On both-signed, the payment sequence self-arms & auto-sends; Stripe link pre-filled happy bnf-r3-S11 PENDING ⏳

Who: System  ·  When: DocuSeal reports BOTH parties have signed the contract. (Owner-approved explicit exception to the one-click human gate — the signing event is the human action that releases this sequence.)

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 DocuSeal both-signed webhook fires The card enters the signed / awaiting-payment state and the payment sequence is armed automatically (no manual arm click). On both-signed, the payment-reminder sequence self-arms (owner-approved exception, recorded). It must not wait for a manual arm; and the human gate stays one-click everywhere ELSE — only this signed-trigger sequence self-arms. LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Card enters signed/awaiting-payment state; payment sequence armed automatically

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 The first payment email sends immediately A warm thank-you-for-signing email goes out at once, containing BOTH the Stripe pay link AND the bank-transfer details with the exact amount; short reminders follow every 1–2 days until paid. Copy: thank-you + 'fizess itt' Stripe link + utalási adatok + pontos összeg · Look: normal outbound email · Where: the lead's inbox / the card history as an outbound touchpoint A ~5-email reminder sequence runs; it stops once payment (Stripe or transfer) is detected. Reminders must not keep sending after payment is detected; the email must not omit the Stripe link or the transfer amount. LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Thank-you email in lead's inbox contains Stripe pay link + bank transfer details + exact amount; card history shows outbound touchpoint

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 Lead clicks the Stripe pay link The Stripe checkout opens with the lead's email already filled in — the lead types no contact data. Copy: prefilled email field · Look: Stripe checkout page · Where: Stripe-hosted checkout The checkout session carries the contact email (prefilled_email); no billing address is requested (it's already on the contract). The lead must not have to re-enter their email; the checkout must not block on a billing address. LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

Stripe checkout page opens with lead's email pre-filled; no billing address input required

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-38 FR-01b — Stripe TEST payment → card moves to 'Payment Arrived / Adatbekérő FUP' happy live-S4bnf-r3-S12 PENDING ⏳

Who: Lead / System  ·  When: Lead completes the Stripe TEST checkout for the deposit link

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Lead completes the Stripe TEST checkout for the deposit link Stripe checkout completed Stripe fires checkout.session.completed → flows.handle_stripe_event → _process_stripe_session sets deposit_paid + _sync_stage(deal,'deposit_paid'); stage_key=deposit_paid; deposit_paid touchpoint LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Stripe checkout completed

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Refresh / loadBoard(true): the card is now in the 'Payment Arrived / Adatbekérő FUP' column Card in 'Payment Arrived / Adatbekérő FUP' board_view._STAGE_TO_COL maps deposit_paid/full_paid → 'payment_arrived' (split out of ongoing_build); later stages (waiting_dev+) stay ongoing_build; Stripe stays in TEST mode this round; card.stage='payment_arrived' — FR-01 col 2 satisfied LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Card in 'Payment Arrived / Adatbekérő FUP'

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-39 FR-02 — rename 'Megbízó dátum' → 'Aláírás dátuma' on the contract signature-date field happy live-S11 PENDING ⏳

Who: Lead / Mátyás (operator)  ·  When: The DocuSeal contract part is opened

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Open the DocuSeal contract part — the client's signature date field Client's signature date field labeled 'Aláírás dátuma' proposal_doc.build_contract_html renders the client date field with name 'Aláírás dátuma' (was 'Megbízó dátum'); field label reads 'Aláírás dátuma' (the one approved live-copy exception) LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Field label reads 'Aláírás dátuma'

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-62 Post-sign payment email — payment link sent on both-signed happy 🆕 Build tonighttonight owner-directive-2026-06-25 PENDING ⏳

Who: System  ·  When: The contract is signed by both parties (DocuSeal both-signed webhook fires).

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Fire DocuSeal both-signed webhook for a ZZ lead Payment email arrives in the ZZ lead's inbox with a payment link Copy: 'köszönjük a bizalmat' + payment link URL · Look: standard workflow email · Where: ZZ lead's inbox DocuSeal both-signed webhook → payment email trigger → email sent to client with payment link MUST NOT omit the payment link; AUTOSEND must NOT be flipped; human gate preserved NEW ENTRY — Type: Fizetési link elküldve · icon: 💳 · label: 'Fizetési link elküldve' · timestamp: now LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

ZZ inbox shows payment email with 'köszönjük a bizalmat' copy and payment link URL

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

Onboarding(2 scenarios)

WJ-40 FR-01b — Stripe TEST payment → card moves to 'Payment Arrived / Adatbekérő FUP' happy live-S4 PENDING ⏳

Who: Lead / System  ·  When: Lead completes the Stripe TEST checkout for the deposit link

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Lead completes the Stripe TEST checkout for the deposit link Stripe checkout completed Stripe fires checkout.session.completed → flows.handle_stripe_event → _process_stripe_session sets deposit_paid + _sync_stage(deal,'deposit_paid'); stage_key=deposit_paid; deposit_paid touchpoint LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Stripe checkout completed

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Refresh / loadBoard(true): the card is now in the 'Payment Arrived / Adatbekérő FUP' column Card in 'Payment Arrived / Adatbekérő FUP' board_view._STAGE_TO_COL maps deposit_paid/full_paid → 'payment_arrived' (split out of ongoing_build); later stages (waiting_dev+) stay ongoing_build; Stripe stays in TEST mode this round; card.stage='payment_arrived' — FR-01 col 2 satisfied LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Card in 'Payment Arrived / Adatbekérő FUP'

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-63 Onboarding email fires on successful payment (Stripe checkout.session.completed) happy 🆕 Build tonighttonight owner-directive-2026-06-25 PENDING ⏳

Who: System  ·  When: Stripe checkout.session.completed fires (successful payment).

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Fire Stripe checkout.session.completed webhook via Test Drive sim for a ZZ lead Onboarding email arrives in the ZZ lead's inbox with 'sikeres fizetés, köszönjük' copy Copy: 'sikeres fizetés' / 'köszönjük' + next steps content (placeholder) · Look: standard workflow email · Where: ZZ inbox Stripe checkout.session.completed → onboarding email trigger → email sent to client MUST NOT omit the trigger; onboarding email must fire on payment (not on a manual step) NEW ENTRY — Type: Onboarding email elküldve · icon: 🎉 · label: 'Onboarding email elküldve' · timestamp: now LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

ZZ inbox shows onboarding email with 'sikeres fizetés, köszönjük' copy and next-steps content

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

Studio Design(10 scenarios)

🎨 Studio integration — UX themes & touchpoint principles
UX Themes
One chip, never a widget cluster — the whole Studio life of a deal must read from a single, icon+colour status chip on the card face.
Silent cross-system steps are invisible — auto-create, auto-kick, transcript push, and archive each need a brief positive confirmation (toast or chip change) so the rep trusts the integration is working.
The human gate must be felt, not just enforced — the 'Send to client' modal and the approval glow + explicit hover buttons exist so the rep always makes the send/advance decision deliberately.
The website URL is the load-bearing input — surface its presence/absence loudly (red ❗, click-to-fix) because the entire Phase-① auto-flow depends on it.
Reflect, don't duplicate — the pipeline mirrors Studio state (chip, glow, history milestones) but never re-implements Studio's comment/edit UI; Studio stays the single source of truth for the design.
Touchpoint Principles
Every cross-system milestone produces exactly one pipeline touchpoint: (1) a human-readable type label under a 'Studio' family (never a raw API/state string), (2) an icon mapping to the milestone (🎨 created · ⚙️ generating · ✅ ready/approved · 📤 sent · 💬 commenting · 🗄️ archived · 🎯 won/delivery · 🌐 published · 🔁 reschedule), (3) a description with the key delta, (4) a Budapest-local timestamp, and (5) an initiated_by / source field (system / operator / client; reschedules use source=manual).
In-Studio micro-events (each section edit, each comment) belong to Studio's OWN history — the pipeline logs only the milestones, so the card's timeline stays scannable.
System/auto entries render muted grey.
Long bodies (e.g. the S6 call transcript + summary) live inside collapsible toggles on the history entry AND in the deal's 'Details' panel.
WJ-41 Sales call booked + URL present → auto-create project + auto-kick the Lab (Phase ①) happy studio-S2 PENDING ⏳

Who: System  ·  When: A deal with a saved website URL has its sales call booked. This is the Phase-① "sell with it" kickoff.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 The sales call is booked (lead self-books or operator logs a booking) on a URL-present deal A Studio project is auto-created, bound to this deal; the status chip appears reading "Studio: dizájn készül" Copy: status chip "🎨 Dizájn készül" · Look: indigo chip on the card · Where: card status-chip slot Studio POST /api/projects with {source_url, client_name, crm_ref=deal_id}; project id stored on the deal Must NOT create a second project for the same deal (idempotent); must NOT block the booking if Studio is slow/down (fail-open) Type: Studio · icon: 🎨 · label: "Studio projekt létrehozva" · description: "Dizájn projekt összekötve ezzel a leaddel" · timestamp: now · initiated_by: system LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Card status-chip slot shows indigo chip "🎨 Dizájn készül"

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

💡 UX The project is created silently — the rep may not realise a Studio design is now spinning up and tied to this lead. → Fire a one-time bottom-left toast on the board: "🎨 Studio dizájn elindult — {company}". Non-blocking, disappears in 4s, links to the project.
2 (Automatic) the Lab is kicked to generate the Phase-① draft Studio begins generating a home-page design + SEO audit + suggested new site structure from the saved URL Copy: chip stays "🎨 Dizájn készül" with a subtle progress shimmer · Look: animated chip · Where: card status chip Lab run started in Studio (scrape → SEO audit → structure → homepage generate); Gemini/DataForSEO spend incurred on this paying-intent lead Must NOT auto-send anything to the prospect; Lab kick is internal-only; no new Modal cron added Type: Studio · icon: ⚙️ · label: "Dizájn generálás elindítva" · description: "Homepage dizájn + SEO audit + javasolt oldalstruktúra generálása folyamatban" · timestamp: now · initiated_by: system LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Chip "🎨 Dizájn készül" with animated shimmer on card status chip

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

💡 UX Generation can take minutes; a single "készül" chip gives no sense of stage (scraping vs. SEO vs. generating) or ETA, so the rep can't tell if it'll be ready before the call. → Let the chip carry a sub-label that mirrors the Lab node ("SEO audit…", "Homepage generálás…") and a rough ETA. Pulled from Studio's existing run state — no new data needed.
3 (Automatic) generation finishes The chip flips to "Studio: kész — megnézhető" and the design becomes openable from the card Copy: chip "✅ Dizájn kész" · Look: sage/green chip + "Megnyitás Studióban" action · Where: card status chip + action row Studio run state → ready; status synced back to the pipeline (reflection, not copy) Must NOT mark ready before the homepage actually rendered; must NOT lose the SEO audit / structure artifacts Type: Studio · icon: ✅ · label: "Dizájn elkészült" · description: "Homepage dizájn, SEO audit és oldalstruktúra elérhető a Studióban" · timestamp: now · initiated_by: system LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

Chip flips to sage/green "✅ Dizájn kész" with "Megnyitás Studióban" action on card

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

💡 UX "Kész" doesn't tell the rep WHAT is ready (just homepage? audit too?) right before they need it in a call. → Expand the ready chip on hover into a 3-item checklist ("✓ Homepage ✓ SEO audit ✓ Struktúra javaslat") so the rep knows exactly what they can show.
WJ-42 Sales call booked + URL present → auto-create project + auto-kick the Lab (Phase ①) happy studio-S3 PENDING ⏳

Who: System  ·  When: A deal with a saved website URL has its sales call booked. This is the Phase-① "sell with it" kickoff.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 The sales call is booked (lead self-books or operator logs a booking) on a URL-present deal A Studio project is auto-created, bound to this deal; the status chip appears reading "Studio: dizájn készül" Copy: status chip "🎨 Dizájn készül" · Look: indigo chip on the card · Where: card status-chip slot Studio POST /api/projects with {source_url, client_name, crm_ref=deal_id}; project id stored on the deal Must NOT create a second project for the same deal (idempotent); must NOT block the booking if Studio is slow/down (fail-open) Type: Studio · icon: 🎨 · label: "Studio projekt létrehozva" · description: "Dizájn projekt összekötve ezzel a leaddel" · timestamp: now · initiated_by: system LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Card status-chip slot shows indigo chip "🎨 Dizájn készül"

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

💡 UX The deferral is correct, but the rep might not connect "I have a booked call tomorrow" with "no design will be ready because of a missing URL" — the cost of the ❗ is now time-critical. → Escalate the ❗ to an amber "⏰ Dizájn nem készül el a hívásig — add meg a weboldalt" banner once a call is booked, so the urgency is explicit relative to the appointment date.
2 (Automatic) the Lab is kicked to generate the Phase-① draft Studio begins generating a home-page design + SEO audit + suggested new site structure from the saved URL Copy: chip stays "🎨 Dizájn készül" with a subtle progress shimmer · Look: animated chip · Where: card status chip Lab run started in Studio (scrape → SEO audit → structure → homepage generate); Gemini/DataForSEO spend incurred on this paying-intent lead Must NOT auto-send anything to the prospect; Lab kick is internal-only; no new Modal cron added Type: Studio · icon: ⚙️ · label: "Dizájn generálás elindítva" · description: "Homepage dizájn + SEO audit + javasolt oldalstruktúra generálása folyamatban" · timestamp: now · initiated_by: system LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Chip "🎨 Dizájn készül" with animated shimmer on card status chip

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

💡 UX After the rep pastes a URL there's a leap of faith that the deferred flow actually picked it up. → Confirm the resume explicitly: "✓ Weboldal mentve — dizájn generálás elindult" toast, so the rep sees the deferred state convert to an active run.
3 (Automatic) generation finishes The chip flips to "Studio: kész — megnézhető" and the design becomes openable from the card Copy: chip "✅ Dizájn kész" · Look: sage/green chip + "Megnyitás Studióban" action · Where: card status chip + action row Studio run state → ready; status synced back to the pipeline (reflection, not copy) Must NOT mark ready before the homepage actually rendered; must NOT lose the SEO audit / structure artifacts Type: Studio · icon: ✅ · label: "Dizájn elkészült" · description: "Homepage dizájn, SEO audit és oldalstruktúra elérhető a Studióban" · timestamp: now · initiated_by: system LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

Chip flips to sage/green "✅ Dizájn kész" with "Megnyitás Studióban" action on card

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-43 Phase-① draft openable from the card for the sales call happy studio-S4 PENDING ⏳

Who: Mátyás  ·  When: The Phase-① design is ready and Mátyás is about to run / is running the sales call.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Mátyás clicks "Megnyitás Studióban" / "Open in Studio" on the card Studio opens directly on this deal's project — homepage design, SEO audit, and suggested structure all there Copy: "Open in Studio" → opens project · Look: Studio project page in a new tab · Where: card action row Deep-link via stored project id; no re-auth dance for the rep Must NOT open a blank Studio home; must NOT 404 if the project exists No new touchpoint for viewing. The "Dizájn elkészült" entry from S2 remains the record. (Viewing is not a deal-state change, so it is intentionally not logged.) LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Studio project page opens in a new tab showing homepage design, SEO audit, and suggested structure

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Mátyás presents the homepage + SEO audit during the sales call A polished homepage design and a concrete SEO/structure story to impress the prospect Copy: SEO audit + structure suggestions · Look: Studio present view · Where: Studio (rep-controlled) No state change in the pipeline; Phase-① is a sales aid, not a client send Nothing is sent to the prospect automatically; the design is shown, not emailed, at this stage No touchpoint — presenting in a call is not a tracked pipeline event unless the rep logs the call (handled by the existing Log Call flow). LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Studio present view shows polished homepage design and SEO/structure story

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-44 Status chip lifecycle happy studio-S5 PENDING ⏳

Who: Mátyás  ·  When: Across the whole Studio life of a deal — the single chip is the rep's at-a-glance signal (Q4).

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Mátyás glances at the card at any point in the Studio journey Exactly ONE Studio status chip reflecting the current state — never a cluster of Studio widgets Copy: one of: "🎨 Dizájn készül" / "📤 Elküldve" / "💬 Ügyfél véleményez" / "✅ Jóváhagyva" · Look: single chip, colour per state · Where: card status-chip slot Chip text derived from the synced Studio state (read-only reflection) Must NOT show two conflicting chips; chip must NOT be editable on the pipeline side (Studio owns the state) The chip mirrors history but is not itself a touchpoint. Each underlying transition (created / sent / commenting / approved) already logged its own entry in S2/S7/S8/S9. LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Exactly ONE chip in the card status-chip slot; text is one of the four valid states

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

💡 UX Four states in one chip means the colour alone must carry meaning; colour-blind reps or a crowded board could misread "sent" vs "approved". → Pair each state with a distinct icon AND colour (🎨 indigo / 📤 blue / 💬 amber / ✅ green) and keep the text label — never colour-only. Matches the touchpoint colour-coding so the board and history stay visually consistent.
2 Studio state changes on the Studio side (e.g. rep sends, client comments) The pipeline chip updates to match within a short delay — no manual refresh needed for the chip to be roughly current Copy: chip text follows the Studio state · Look: chip recolours · Where: card Studio → pipeline status sync (event/outbox or pull on board load); reflection only Must NOT require a Studio-side cron; must NOT let the chip go permanently stale No extra touchpoint for a chip refresh itself; the meaningful transitions are logged where they happen. LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Pipeline chip updates to match Studio state within a short delay without manual refresh

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

💡 UX If the sync is pull-on-load, a rep staring at the board won't see a client comment land until they refresh — the chip can silently lag reality. → Show a tiny "frissítve {n} perce" timestamp on hover, and refresh the chip on board focus, so the rep knows how trustworthy the chip currently is.
WJ-45 Dual "Send to client" button → AI-drafted modal, human reviews & sends happy studio-S7 PENDING ⏳

Who: Mátyás  ·  When: The design is ready to go to the client; Mátyás sends the review link from EITHER the pipeline card OR inside Studio (Q6). Human gate is the whole point.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Mátyás clicks "Küldés ügyfélnek" / "Send to client" — present on BOTH the pipeline card AND inside Studio A modal opens, pre-filled with an AI-drafted message + the client review link — NOT an immediate send Copy: AI-drafted Hungarian message + review URL · Look: editable modal, "Küldés" button at the bottom · Where: modal over the card / over Studio Studio GET /api/projects/{id}/links mints the review link; AI draft generated; nothing sent yet Must NOT auto-send on button click; the modal MUST appear first; AUTOSEND never flipped No touchpoint yet — opening the modal is not a send. The touchpoint is created only on the explicit "Küldés" in step 2. LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Editable modal appears pre-filled with AI-drafted Hungarian message + review URL and a "Küldés" button

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

💡 UX Two entry points (card + Studio) risk drift — the rep might send twice from two surfaces, or the two modals could differ in copy quality. → Both buttons must open the SAME modal/component with the same AI draft; once sent, both surfaces immediately reflect "📤 Elküldve" to prevent a double send.
2 Mátyás edits the draft if needed and clicks "Küldés" The message + review link is sent to the client; the chip flips to "📤 Elküldve"; Studio publishes the version + locks the client view Copy: chip "📤 Elküldve ügyfélnek" · Look: blue chip; modal closes with a success toast · Where: card status chip Send fires via the human-reviewed copy; Studio "Ügyfélnek küldés" publish runs (working → published, client view unlocks) Nothing sent without the explicit "Küldés" click; must NOT send a stale/empty draft; must NOT double-fire from the other surface Type: Studio · icon: 📤 · label: "Elküldve ügyfélnek" · description: "Dizájn review link elküldve az ügyfélnek (jóváhagyott szöveggel)" · timestamp: now · initiated_by: operator LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Chip flips to blue "📤 Elküldve ügyfélnek"; modal closes with success toast; both card and Studio reflect sent state

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

💡 UX The send couples two big actions (email + Studio publish/lock) behind one button; if one half fails the rep may not know which. → Show a 2-line success state: "✓ Üzenet elküldve · ✓ Studio publikálva / ügyfél nézet feloldva". If either half fails, surface a precise "⚠️ Email ment, de a Studio publikálás nem" so the rep can recover the right half.
WJ-46 Design approved → pulsing green card overlay + hover buttons happy studio-S9 PENDING ⏳

Who: System  ·  When: The client approves the design in Studio. The pipeline makes this VERY obvious but keeps stage advancement human-gated (Q5).

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 The client approves the design in Studio The deal card gains a glowing / pulsing GREEN overlay signalling "design approved" — impossible to miss on the board Copy: overlay label "✅ Dizájn jóváhagyva" · Look: pulsing green glow around the whole card · Where: card on the board Studio "approved" state → pipeline; overlay rendered; chip "✅ Jóváhagyva" Must NOT auto-advance the pipeline stage; the glow is a prompt for a human decision, not an action Type: Studio · icon: ✅ · label: "Ügyfél jóváhagyta a dizájnt" · description: "Az ügyfél jóváhagyta a dizájnt a Studióban — készen áll a következő lépésre" · timestamp: now · initiated_by: client LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Card shows pulsing green glow around whole card with overlay label "✅ Dizájn jóváhagyva"; chip reads "✅ Jóváhagyva"

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

💡 UX A pulsing glow is great for grabbing attention but can become noise if several cards glow at once, and pure animation can be missed by reduced-motion users. → Respect prefers-reduced-motion (swap the pulse for a solid green ring + "✅ Jóváhagyva" badge), and cap simultaneous pulses so the board doesn't turn into a disco.
2 Mátyás hovers the glowing card Two buttons appear: "Move to next pipeline stage" and "Move to next pipeline stage + open in Studio" Copy: "Következő szakaszba" · "Következő szakaszba + Studio megnyitása" · Look: two buttons on hover over the green overlay · Where: card hover state Neither button has fired yet; advancement waits for the explicit click Buttons must NOT be hidden so deep they're undiscoverable; hover must reveal BOTH No touchpoint on hover. The advancement touchpoint is created only on the click (step 3). LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Two hover buttons visible: "Következő szakaszba" and "Következő szakaszba + Studio megnyitása"

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

💡 UX Hover-only actions are invisible on touch devices and easy to miss; a rep may not realise the glow is actionable. → Also expose the two actions in the card's normal action row (not hover-only) when approved, and keep the hover affordance as a fast path. Add a tooltip on first appearance explaining the two-option choice.
3 Mátyás clicks one of the two buttons The deal advances to the next pipeline stage (and, for option 2, Studio opens too); the green overlay clears Copy: card now in the next stage column · Look: glow removed, normal card · Where: board Stage advanced by the human click; Studio advance (presented→won) reflected if applicable Stage must NOT have moved before the click; option 2 must NOT advance twice or open the wrong project Type: Státusz változás · icon: 🔀 · label: "Áthelyezve: {előző} → {következő}" · description: "Dizájn jóváhagyás után, kézi továbbléptetés" · timestamp: now · initiated_by: operator LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

Card moves to next stage column; green glow overlay removed; normal card look

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

💡 UX suggestion dropped per owner
WJ-47 Won deal → delivery in Studio + Cloudflare publish; ONE unified pipeline view (no separate handoff state) happy studio-S11 PENDING ⏳

Who: Mátyás  ·  When: The deal is won (deposit/payment). There is NO separate "Dev handoff" pipeline state. The old dev process is REPLACED by the ClientsFlow Studio review tool: from Studio a project is published via the Cloudflare API (already built). Pipeline management is unified — one pipeline view. When Dani is later brought in, he sees the same pipeline view and simply knows which pipeline stage he must watch.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 The deal is won; delivery continues IN the same pipeline view — no separate handoff stage is created The won deal's card keeps its approved-design link; delivery happens through the Studio review tool (no new "Dev handoff" column/task spawns) Copy: "Megnyitás Studióban — jóváhagyott dizájn" stays on the card · Look: the SAME pipeline card, advanced to the won/delivery stage · Where: the single unified pipeline board No studio_handoff stage or separate handoff task; the approved Studio project id stays bound to the deal; delivery is driven from Studio Must NOT create a separate dev-handoff pipeline state or a parallel task list; must NOT split delivery out of the pipeline view; must NOT link to an unapproved/older version; must NOT create a separate dev-handoff state / second view Type: Studio · icon: 🎯 · label: "Megnyerve — szállítás a Studióban" · description: "A deal megnyerve; a szállítás a ClientsFlow Studio review eszközben folytatódik (nincs külön handoff szakasz)" · timestamp: now · initiated_by: system LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Same unified pipeline card advanced to won/delivery stage; "Megnyitás Studióban — jóváhagyott dizájn" link present; no new "Dev handoff" column or task spawned

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 From Studio, the project is published live The approved design is published to the web via the Cloudflare API (already built); the live URL is reflected back on the deal Copy: chip/marker "🌐 Publikálva" + live URL · Look: published-state marker on the card · Where: card status + Details panel Studio → Cloudflare publish (existing capability); resulting live URL stored on the deal and reflected in the pipeline Must NOT require a manual out-of-band deploy; must NOT publish an unapproved version; must NOT lose the live URL on the deal record Type: Studio · icon: 🌐 · label: "Publikálva (Cloudflare)" · description: "A jóváhagyott dizájn élesítve a Cloudflare API-n keresztül — {live_url}" · timestamp: now · initiated_by: operator LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Card shows "🌐 Publikálva" marker with live URL on card status and Details panel

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 (Later) Dani is brought in to help with delivery Dani opens the same pipeline view — no special handoff surface; he simply watches the pipeline stage he is responsible for Copy: same board, same cards · Look: identical unified pipeline view · Where: the single shared pipeline board Dani has access to the same pipeline (no separate handoff app/view); his focus is a known pipeline stage, not a bespoke handoff task Must NOT build a second, Dani-only view or a parallel handoff board; must NOT fragment the pipeline into separate sales/delivery tools No new touchpoint for Dani viewing the board. The won/published entries above remain the delivery record. LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

Dani sees the identical unified pipeline board and same cards — no separate handoff surface

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-48 Design approved → pulsing green card overlay + hover buttons happy studio-S10 PENDING ⏳

Who: System  ·  When: The client approves the design in Studio. The pipeline makes this VERY obvious but keeps stage advancement human-gated (Q5).

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 The client approves the design in Studio The deal card gains a glowing / pulsing GREEN overlay signalling "design approved" — impossible to miss on the board Copy: overlay label "✅ Dizájn jóváhagyva" · Look: pulsing green glow around the whole card · Where: card on the board Studio "approved" state → pipeline; overlay rendered; chip "✅ Jóváhagyva" Must NOT auto-advance the pipeline stage; the glow is a prompt for a human decision, not an action Type: Studio · icon: ✅ · label: "Ügyfél jóváhagyta a dizájnt" · description: "Az ügyfél jóváhagyta a dizájnt a Studióban — készen áll a következő lépésre" · timestamp: now · initiated_by: client LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Card shows pulsing green glow around whole card with overlay label "✅ Dizájn jóváhagyva"; chip reads "✅ Jóváhagyva"

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

💡 UX suggestion dropped per owner
2 Mátyás hovers the glowing card Two buttons appear: "Move to next pipeline stage" and "Move to next pipeline stage + open in Studio" Copy: "Következő szakaszba" · "Következő szakaszba + Studio megnyitása" · Look: two buttons on hover over the green overlay · Where: card hover state Neither button has fired yet; advancement waits for the explicit click Buttons must NOT be hidden so deep they're undiscoverable; hover must reveal BOTH No touchpoint on hover. The advancement touchpoint is created only on the click (step 3). LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Two hover buttons visible: "Következő szakaszba" and "Következő szakaszba + Studio megnyitása"

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 Mátyás clicks one of the two buttons The deal advances to the next pipeline stage (and, for option 2, Studio opens too); the green overlay clears Copy: card now in the next stage column · Look: glow removed, normal card · Where: board Stage advanced by the human click; Studio advance (presented→won) reflected if applicable Stage must NOT have moved before the click; option 2 must NOT advance twice or open the wrong project Type: Státusz változás · icon: 🔀 · label: "Áthelyezve: {előző} → {következő}" · description: "Dizájn jóváhagyás után, kézi továbbléptetés" · timestamp: now · initiated_by: operator LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

Card moves to next stage column; green glow overlay removed; normal card look

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-75 Phase-① draft openable from the card for the sales call happy 📐 Coverage studio-S4 PENDING ⏳

Who: Mátyás  ·  When: The Phase-① design is ready and Mátyás is about to run / is running the sales call.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Mátyás clicks "Megnyitás Studióban" / "Open in Studio" on the card Studio opens directly on this deal's project — homepage design, SEO audit, and suggested structure all there Copy: "Open in Studio" → opens project · Look: Studio project page in a new tab · Where: card action row Deep-link via stored project id; no re-auth dance for the rep Must NOT open a blank Studio home; must NOT 404 if the project exists No new touchpoint for viewing. The "Dizájn elkészült" entry from S2 remains the record. (Viewing is not a deal-state change, so it is intentionally not logged.) LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Studio project page opens in a new tab showing homepage design, SEO audit, and suggested structure

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

💡 UX suggestion dropped per owner
2 Mátyás presents the homepage + SEO audit during the sales call A polished homepage design and a concrete SEO/structure story to impress the prospect Copy: SEO audit + structure suggestions · Look: Studio present view · Where: Studio (rep-controlled) No state change in the pipeline; Phase-① is a sales aid, not a client send Nothing is sent to the prospect automatically; the design is shown, not emailed, at this stage No touchpoint — presenting in a call is not a tracked pipeline event unless the rep logs the call (handled by the existing Log Call flow). LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Studio present view shows polished homepage design and SEO/structure story

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

💡 UX suggestion dropped per owner
WJ-76 Client review loop stays in Studio (pipeline shows "client commenting" only) happy 📐 Coverage studio-S8 PENDING ⏳

Who: System  ·  When: The client opens the review link and comments; Studio runs its section-scoped edit loop. The pipeline only reflects the state — it never duplicates the comment UI.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 The client opens the review link and leaves comments in Studio On the pipeline, the chip flips to "💬 Ügyfél véleményez" — the comments themselves live only in Studio Copy: chip "💬 Ügyfél véleményez" · Look: amber chip · Where: card status chip Studio comment activity → status sync → pipeline chip; pipeline does NOT store the comments Must NOT reproduce Studio's comment overlay in the pipeline; must NOT lose the "commenting" signal Type: Studio · icon: 💬 · label: "Ügyfél megjegyzést írt" · description: "Az ügyfél véleményezi a dizájnt a Studióban" · timestamp: now · initiated_by: client LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Card status chip shows amber "💬 Ügyfél véleményez"

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

💡 UX "Ügyfél véleményez" doesn't convey volume or sentiment — 1 minor comment looks the same as 20 blocking ones, so the rep can't prioritise. → Let the chip carry a count badge ("💬 3") sourced from Studio's open-comment count, and on hover show the newest comment snippet. Still a reflection, not a duplicated UI.
2 Mátyás opens Studio to resolve comments + run section edits The full comment/revision loop in Studio (unchanged); the pipeline keeps showing "💬 Ügyfél véleményez" until approval Copy: Studio reviewer UI · Look: Studio (not pipeline) · Where: Studio project Studio section-scoped edits; client view locks "🔧 Feldolgozás alatt" during edits (existing Studio behavior) Must NOT advance the pipeline stage on its own while commenting/refining No pipeline touchpoint for each in-Studio edit — those belong to Studio's own history. The pipeline logs only the milestone transitions (sent / approved). LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Studio reviewer UI shows full comment/revision loop; pipeline chip remains "💬 Ügyfél véleményez"

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

💡 UX The rep round-trips between two tools during the revision loop; the pipeline gives no nudge when the loop is taking too long (stalled deals). → If a deal sits in "💬 Ügyfél véleményez" beyond N days, surface a gentle "⏳ {n} napja véleményezés alatt" hint on the card so stalled reviews get a follow-up nudge.

Cancellation(3 scenarios)

WJ-49 Cancellation — intermediate confirm page before cancel happy 🆕 Build tonighttonight ext-S1ext-S2 PENDING ⏳

Who: Réka (Lead)  ·  When: Réka has a Booked appointment and opens the booking email; the card sits in the Booked column.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Réka clicks the 'Lemondás' / cancel link in her booking email INTERMEDIATE confirmation page: 'Biztosan le szeretnéd mondani az időpontot?' with TWO buttons Copy: 'Biztosan le szeretnéd mondani az időpontot?' · Buttons: 'Időpont lemondása' (red/destructive) + 'Inkább átütemezem' (neutral/secondary) · Where: full-page booking app cancel link renders the confirm page — cancel_booking NOT yet called MUST NOT immediately delete/cancel the event; must NOT show 'Időpont lemondva' directly on first link click LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Intermediate page 'Biztosan le szeretnéd mondani az időpontot?' with buttons 'Időpont lemondása' and 'Inkább átütemezem'

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Réka clicks 'Inkább átütemezem' on the confirmation page The reschedule/booking page opens (same page as the reschedule link) — NOT a cancellation Copy: reschedule page — date/time picker · Look: booking-style picker · Where: full-page booking app redirect to the reschedule flow; cancel_booking is NOT called MUST NOT proceed to cancel; MUST NOT show a cancellation success page LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Reschedule page opens (same page as the reschedule link) with date/time picker

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 Réka goes back (or a fresh cancel link) and this time clicks 'Időpont lemondása' Success page 'Időpont lemondva'; card moves to Contacted — No Appointment Booked; RED Lemondás badge; 🚫 touchpoint logged; no auto-email sent Copy: 'Időpont lemondva' · Look: plain confirmation success page · Where: full-page booking app cancel_booking runs; stage_key → booking_fup; Lemondás touchpoint created No error thrown; no new booking confirmation email sent; AUTOSEND stays OFF NEW ENTRY — Type: Lemondás · label: 'Lemondás · {date}' · icon: 🚫 · timestamp: now (Budapest) LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

Success page 'Időpont lemondva'; card visible under 'Contacted — No Appointment Booked'; RED 'Lemondás · {date}' badge on card; 🚫 touchpoint in history

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-50 S1 — B1 — Cancellation via the email link happy ext-S1 PENDING ⏳

Who: Réka (Lead)  ·  When: Réka has a Booked appointment and opens the booking email; the card sits in the Booked column.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Réka clicks the 'Lemondás' / cancel link in her booking email (GET /cancel?token=… on the booking app) A confirmation page: the appointment was cancelled — not an error Copy: 'Időpont lemondva' · Look: plain confirmation, no error styling · Where: full-page on booking app cancel_booking runs on the ZZ deal No error thrown; no NEW booking confirmation email sent NEW ENTRY — Type: Lemondás · label: 'Lemondás · {date}' · icon: 🚫 · timestamp: now (Budapest) LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Full-page confirmation 'Időpont lemondva', no error styling

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Card moves OUT of Booked INTO 'Contacted — No Appointment Booked' ZZ card appears under 'Contacted — No Appointment Booked', GONE from Booked Copy: card title under 'Contacted — No Appointment Booked' · Look: normal board card in booking_fup column · Where: pipeline board stage_key set to value mapping to booking_fup; NOT ghost 'contacted' key Card must NOT stay in Booked; must NOT land in New Lead No new touchpoint for the column move itself — the cancellation touchpoint from step 1 is the record. History panel now shows the Lemondás entry at the top. LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Card under 'Contacted — No Appointment Booked', absent from Booked column

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 RED 'Lemondás' label + cancellation date appears on the card RED label reading 'Lemondás' + cancellation date on the ZZ card Copy: 'Lemondás · {date}' · Look: RED label/badge · Where: card label/badge area Deal stores cancellation flag + date → drives red label render Label must NOT be neutral/blue; date must be cancellation date, NOT original booking date History panel already shows the Lemondás entry from step 1. The red label on the card face is the board-level signal; the history entry is the detailed record. LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

RED 'Lemondás · {date}' badge visible on card

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

4 Card history shows a proper CANCELLATION entry (not 'Call booked' tag) Newest history entry tagged as a CANCELLATION — 'Lemondva' / 'Cancelled' Copy: history row tag = cancellation label · Look: visually distinct from booking tag · Where: card's history/touchpoints list Touchpoint Type is cancellation (not 'booking') → HIST_LABEL renders correctly History tag must NOT read 'Call booked'; description text stays correct Lemondás touchpoint: icon 🚫 · label 'Lemondás' · 'Időpont lemondva' as description · exact timestamp. Clicking the row expands to show full detail if any note was added. LIVE ✅PENDING
Step 4 — live test transcript
① Before the shot — "What should I see?"

Newest history entry: cancellation label (not 'Call booked'), icon 🚫, description 'Időpont lemondva'

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-57 Reschedule link succeeds — átütemezés page loads and shows success recovery 🐛 Bug-fixtonight live-test-transcript-2026-06-25 PENDING ⏳

Who: Réka (Lead)  ·  When: Lead clicks the reschedule (átütemezés) link from the booking email.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Lead clicks the reschedule (átütemezés) link from the booking email Reschedule page loads with a date/time picker — no error Copy: date/time picker with available slots · Look: booking-style page, no error text · Where: full-page booking app reschedule flow initialises with the existing booking token; GCal free-busy checked MUST NOT show 'valami nem sikerült' or any error page on link click LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Reschedule page with date/time picker open; no error text visible

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Lead picks a new slot and confirms the reschedule Success page 'Időpont átütemezve'; card history shows reschedule touchpoint Copy: 'Időpont átütemezve' · Look: plain success page · Where: full-page booking app GCal event moved to new slot; reschedule touchpoint logged on the card MUST NOT show error after confirming; GCal must NOT retain old slot NEW ENTRY — Type: Átütemezés · icon: 🔄 · label: 'Átütemezés · {new date}' · timestamp: now (Budapest) LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Success page 'Időpont átütemezve'; reschedule touchpoint 🔄 in card history

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

Invariants(9 scenarios)

WJ-51 Send Emails → arm sequence → Contacted column happy board-S7live-S2bnf-r3-S11studio-S7invariant PENDING ⏳

Who: Mátyás (operator)  ·  When: A New-lead card is on the board

💡 Studio UX
Step 1Two entry points (card + Studio) risk drift — the rep might send twice from two surfaces, or the two modals could differ in copy quality.→ Both buttons must open the SAME modal/component with the same AI draft; once sent, both surfaces immediately reflect "📤 Elküldve" to prevent a double send.
Step 2The send couples two big actions (email + Studio publish/lock) behind one button; if one half fails the rep may not know which.→ Show a 2-line success state: "✓ Üzenet elküldve · ✓ Studio publikálva / ügyfél nézet feloldva". If either half fails, surface a precise "⚠️ Email ment, de a Studio publikálás nem" so the rep can recover the right half.
#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Click 'Send Emails' on a New-lead card Sequence edit-and-arm modal opens immediately, preloaded with all copies Send Emails opens the sequence edit-and-arm modal; modal loads immediately, preloaded with all copies LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Sequence modal opens immediately, preloaded with all copies

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Review the steps: subject, body, per-step wait, version dropdown Modal shows steps with subject, body ({first_name}/{booking_link}), per-step wait (0 = azonnal), version dropdown Automatikus szekvencia — szerkeszd és élesítsd /dash/api/seq/preview; nicer layout + a bit of colour LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Modal title 'Automatikus szekvencia — szerkeszd és élesítsd'; steps with subject, body ({first_name}/{booking_link}), per-step wait (0=azonnal), version dropdown

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 Edit a body — the 3-option save reveals; bodies auto-grow 3-option save: 'Mentés mint: Csak ennél a leadnél · Alapértelmezett · Új verzió'; textarea auto-grows Mentés mint: Csak ennél a leadnél · Alapértelmezett · Új verzió no standalone on-card 'review & arm' block exists LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

3-option save: 'Mentés mint: Csak ennél a leadnél · Alapértelmezett · Új verzió'; textarea auto-grows

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

4 Click 'Mentés és élesítés' 'Mentés és élesítés' button is the single arm entry Mentés és élesítés define(replace) → arm(); first step scheduled in the 06:12–18:00 Mon–Fri window; Q13 human-gate honored (nothing sends until armed) LIVE ✅PENDING
Step 4 — live test transcript
① Before the shot — "What should I see?"

Modal closes (or transitions); sequence armed

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

5 Card LEAVES 'New lead' → lands in 'Contacted — No Appointment Booked' Card in 'Contacted — No Appointment Booked' with dim overlay + blue dashed border + tags Auto: Nem elért lead · 1/2 · köv: 06.20 17:55 optimistic move + bg sync; dim overlay + blue dashed border + tags; New lead stays sequence-free LIVE ✅PENDING
Step 5 — live test transcript
① Before the shot — "What should I see?"

Card in 'Contacted — No Appointment Booked'; dim overlay + blue dashed border + tags: 'Auto: Nem elért lead · 1/2 · köv: 06.20 17:55'

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-52 Send Emails → arm sequence → Contacted column happy board-S7invariant PENDING ⏳

Who: Mátyás (operator)  ·  When: A New-lead card is on the board

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Click 'Send Emails' on a New-lead card Sequence edit-and-arm modal opens immediately, preloaded with all copies Send Emails opens the sequence edit-and-arm modal; modal loads immediately, preloaded with all copies LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Sequence modal opens immediately, preloaded with all copies

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Review the steps: subject, body, per-step wait, version dropdown Modal shows steps with subject, body ({first_name}/{booking_link}), per-step wait (0 = azonnal), version dropdown Automatikus szekvencia — szerkeszd és élesítsd /dash/api/seq/preview; nicer layout + a bit of colour LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Modal title 'Automatikus szekvencia — szerkeszd és élesítsd'; steps with subject, body ({first_name}/{booking_link}), per-step wait (0=azonnal), version dropdown

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 Edit a body — the 3-option save reveals; bodies auto-grow 3-option save: 'Mentés mint: Csak ennél a leadnél · Alapértelmezett · Új verzió'; textarea auto-grows Mentés mint: Csak ennél a leadnél · Alapértelmezett · Új verzió no standalone on-card 'review & arm' block exists LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

3-option save: 'Mentés mint: Csak ennél a leadnél · Alapértelmezett · Új verzió'; textarea auto-grows

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

4 Click 'Mentés és élesítés' 'Mentés és élesítés' button is the single arm entry Mentés és élesítés define(replace) → arm(); first step scheduled in the 06:12–18:00 Mon–Fri window; Q13 human-gate honored (nothing sends until armed) LIVE ✅PENDING
Step 4 — live test transcript
① Before the shot — "What should I see?"

Modal closes (or transitions); sequence armed

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

5 Card LEAVES 'New lead' → lands in 'Contacted — No Appointment Booked' Card in 'Contacted — No Appointment Booked' with dim overlay + blue dashed border + tags Auto: Nem elért lead · 1/2 · köv: 06.20 17:55 optimistic move + bg sync; dim overlay + blue dashed border + tags; New lead stays sequence-free LIVE ✅PENDING
Step 5 — live test transcript
① Before the shot — "What should I see?"

Card in 'Contacted — No Appointment Booked'; dim overlay + blue dashed border + tags: 'Auto: Nem elért lead · 1/2 · köv: 06.20 17:55'

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-53 BUG-02 — manual stage change persists (no rubber-band) failure studio-S10duo2-S02invariant PENDING ⏳

Who: Mátyás  ·  When: A ZZ card sits in 'Negative Replies'; the operator drags it to 'New Lead'.

💡 Studio UX
Step 1
#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Drag a ZZ card from the 'Negative Replies' column into the 'New Lead' column The card docks in 'New Lead' and STAYS there (brief locked/loading state while saving); DECISION: every manual stage move is allowed and persists — no stage is locked Copy: <lead name> · Look: card docked under the New Lead column · Where: New Lead column The manual stage override persists in the store (deal_col → New Lead); the board reflects it after refresh; any neg_reply flag is cleared so it won't be re-classified back The card must NOT snap back to 'Negative Replies' after ~2s; the move must NOT be silently reverted LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Card docked in New Lead column and stays there; brief locked/loading state during save then stable

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 (error branch) a genuine save/network failure occurs On a real save failure a visible error toast appears and the card returns WITH an explanation — never a silent snap-back Copy: Couldn't move card — try again · Look: red toast · Where: top-right of the board The stage is unchanged and the failure is surfaced to the operator A failed network request must NOT be swallowed silently LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Red error toast "Couldn't move card — try again" at top-right of board; card returns to original column

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-54 Instantly warmup mail (campaign IDs 8ZP8HWG, i-am-happy, DMARC-related) is never logged to Notion an happy invariant PENDING ⏳

Who: Operator / System  ·  When: (distilled from behavior: Instantly warmup mail (campaign IDs 8ZP8HWG, i-am-happy, DMARC-related) is never)

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 (verify the asserted invariant/behavior) Warmup emails arriving in Missive: not visible in touchpoint history for any deal; not logged to Notion; auto-archived in Missive inbox Instantly warmup mail (campaign IDs 8ZP8HWG, i-am-happy, DMARC-related) is never logged to Notion and never appears on the pipeline board. In Missive it is auto-archived (not deleted) to preserve engagement metrics. LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Warmup emails arriving in Missive: not visible in touchpoint history for any deal; not logged to Notion; auto-archived in Missive inbox

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-55 Lead self-books → card moves to Booked, dim persists until day-before, scheduled emails leave history happy board-S15bnf-r3-S4 PENDING ⏳

Who: System  ·  When: A lead in Contacted (with an ARMED Booking-Follow-Up sequence) self-books a call via its unique booking link for a date in the future.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Lead picks a slot on its booking page and confirms The card moves from Contacted to the Booked column. Copy: lead name + 'Booked' / appointment date · Look: Booked-column card · Where: Booked column deal_col becomes the Booked column; the armed booking-follow-up sequence is disarmed (sf.armed=false) and its queued emails are removed. The card must not stay in Contacted; no further booking-follow-up email may send after booking. LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Card moved from Contacted to Booked column showing lead name + appointment date

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 The Booked card's dim overlay The Booked card stays DIMMED while the appointment is still far off. Copy: appointment date tag · Look: dimmed/passive card (greyed overlay) · Where: Booked column The dim persists until 00:00 of the calendar day BEFORE the appointment, then the card switches to the full (undimmed) active look. The card must not lose its dim immediately on booking (the I4 bug), and must not stay dimmed forever (the armedSeq-stuck bug). LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Booked card shows dimmed/greyed (passive) overlay while appointment is far off; dim clears at 00:00 of the day before

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 Operator opens the booked card's history panel The history panel shows the booking + real touchpoints, but NOT the now-cancelled scheduled emails. Copy: no 'Scheduled email #N' rows for the booking-fup sequence · Look: clean history timeline · Where: the card's history/timeline panel The previously-scheduled booking-follow-up emails are gone from history. Stale 'Scheduled email' entries from the disarmed sequence must not linger in history (the I6 bug). LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

History panel shows booking + real touchpoints only; no 'Scheduled email #N' rows for booking-fup sequence

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-66 INV-IMMEDIATE — all critical state changes reflected in pipeline view within seconds guardrail 🛡️ Invarianttonight owner-directive-2026-06-25live-test-transcript-2026-06-25 PENDING ⏳

Who: System  ·  When: Any critical pipeline state change occurs.

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Trigger a booking-created event for a ZZ lead; observe pipeline board Card appears in Booked column within seconds of the booking webhook Copy: ZZ card in Booked column · Look: card moved immediately · Where: pipeline board booking webhook → optimistic UI update → board refresh within seconds MUST NOT require a multi-minute wait; MUST NOT require manual page refresh LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Card in Booked column within seconds of booking webhook; no manual refresh needed

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Trigger a stage-move event (e.g. cancellation) for a ZZ lead; observe pipeline board Card moves to the correct column within seconds of the stage-move event Copy: ZZ card in correct post-cancel column · Look: card moved immediately · Where: pipeline board stage-move event → optimistic UI update → board reflects new column within seconds MUST NOT show stale stage on board for more than a few seconds LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Card in correct column within seconds of stage-move event

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

3 Trigger payment-received event via Test Drive sim; observe card Card reflects payment-received state within seconds (payment tag or stage move to Won) Copy: payment tag or Won stage on card · Look: immediate reflection · Where: pipeline board card Stripe payment event → pipeline update → card reflects within seconds MUST NOT require multi-minute wait for payment to appear on the card LIVE ✅PENDING
Step 3 — live test transcript
① Before the shot — "What should I see?"

Card shows payment-received state (payment tag or Won stage) within seconds

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-67 INV-TZ — Budapest time everywhere (system-wide invariant) guardrail 🛡️ Invarianttonight owner-directive-2026-06-25live-test-transcript-2026-06-25 PENDING ⏳

Who: System  ·  When: Any time is displayed in the system (CRM, board, Notion, GCal).

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Trigger any time-stamped event for a ZZ lead (booking, call, touchpoint) All time displays across board, Notion, GCal show the same Budapest-local time Copy: Budapest-local time on all surfaces · Look: consistent time display everywhere · Where: board card, Notion log, GCal event, GCal invite title all time storage and display uses Europe/Budapest; no tz conversion for display MUST NOT show a different time on any surface; MUST NOT show booker/user local tz LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Board card, Notion log, GCal event, and GCal invite title all show the same Budapest-local time

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-73 Optimistic UI — background Notion write fails failure 📐 Coverage board-S16 PENDING ⏳

Who: System / Mátyás (operator)  ·  When: Operator performs an action (status change or arm); background Notion write fails

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Perform an action (e.g. a status change or arm) UI updates instantly; card already moved UI updates instantly; the POST returns before the Notion write; card already moved LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Card moved instantly; no spinner

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 The background Notion sync fails Card stays where the rep put it; no spurious revert; UI not blocked logged as a system note + retried; the UI is NOT blocked or spuriously reverted; card stays where the rep put it; recovery: reconciled on the next board refresh LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Card stays where the rep put it; UI not blocked

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

WJ-74 BUG-08 — board load + interaction stays responsive edge 📐 Coverage live-S10 PENDING ⏳

Who: Mátyás (operator)  ·  When: Operator loads the board (#pipeline)

#You doYou should see Element that changes
copy · look · where
What changes underneathMust NOT happen 🕓 Touchpoint history🧪 Test
1 Load the board (#pipeline) Board renders under the agreed budget; payload not bloated GET /dash/api/board (120s per-container cache, warm); measure payload size + build time; board renders under the agreed budget; payload not bloated LIVE ✅PENDING
Step 1 — live test transcript
① Before the shot — "What should I see?"

Board renders under the agreed performance budget

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.

2 Open a card / the email-templates panel Interaction feels near-instant lazy reads; no redundant Notion round-trips on the hot path; interaction feels near-instant (BUG-08 perf pass — measure, then trim the worst offender) LIVE ✅PENDING
Step 2 — live test transcript
① Before the shot — "What should I see?"

Interaction feels near-instant

📸 screenshot pending

Transcript not yet available — will appear when the live run reaches this step.