Pipeline Live-Test Bug Backlog — EBO for sign-off

6 fixes from the 06-24 test (Mátyás + Gergely). Read it, then say 'done' to start the build.

Master summary — the gist in 30 seconds

TL;DRAn answer-key for 6 board bugs you found in the live test. Approve it once and the factory builds + QA-proves all 6 hands-off.

Input: your live-test notes (cancel routing, reschedule error, missing calendar invites, wrong buttons, a move that won't stick, a messy Log Call panel). Output: one signed 'Expected-Behavior Oracle' (EBO) that says EXACTLY how each should behave — the contract every fix and every test is checked against.

Why this mattersNothing gets built until you sign this. The EBO is the single place where 'correct' is defined, so the AI can't quietly decide its own success criteria — it has to hit the behaviors you approved. This is the first of the two times you touch this run; the second is accepting the finished build.

flowchart LR
  T["Your live-test<br/>notes (B1-B6)"] --> E["EBO answer-key<br/>(9 scenarios)"]
  E --> S{"You sign off?"}
  S -->|"not yet"| E
  S -->|"done"| B["Factory builds<br/>+ QA-proves all 6"]
  B --> A["You accept<br/>the result"]

B1 · Cancellation should clean up after itself

TL;DRLead cancels from the email link → card moves back, gets a red 'Lemondás' label + date, and the history says 'cancelled' — not 'booked'.

Input: lead clicks the cancel link in the booking email. Output: the card leaves 'Booked', lands in 'Contacted — No Appointment Booked', wears a RED Lemondás label with the date, and the history logs a proper cancellation. No email goes out.

Why it mattersToday the card stays in Booked and the history mis-tags it as 'Call booked' — so the board lies about who's still coming. A cancellation must visibly demote the lead so you can follow up ('I cancelled, what now?'). The red label is the at-a-glance truth.

flowchart TD
  C["Lead clicks<br/>cancel link"] --> M["Card: Booked<br/>-> Contacted/No-Appt"]
  C --> L["RED 'Lemondás'<br/>label + date"]
  C --> H["History: 'cancelled'<br/>(not 'Call booked')"]
  C --> X["NO email sent"]

B2 · Reschedule should actually reschedule

TL;DRLead picks a new time → the appointment really moves, card stays in Booked with the new date, an updated invite goes out.

Input: lead reschedules from the lead page. Output: appointment updated to the new time, card stays in Booked (new date), history logs the reschedule, and an UPDATED calendar invite is sent. Today it just throws an error and does nothing.

Why it mattersA broken reschedule means a lead silently keeps the old slot or drops off — a lost call. If the invite can't be delivered because of a Google Workspace setting, the run flags it for you to fix — it will NOT pretend it worked.

flowchart LR
  O["Old time<br/>(Booked)"] -->|"lead picks<br/>new slot"| N["New time<br/>(still Booked)"]
  N --> I["Updated invite<br/>to lead + rep"]
  N --> Hh["History:<br/>reschedule"]
  I -.->|"if Workspace<br/>blocks it"| F["Flag for<br/>owner, not fake-pass"]

B3 · Calendar invites must arrive

TL;DRWhen a call is booked, the Google Calendar invite reliably reaches the lead's inbox (and yours).

Input: a booking is created. Output: a calendar invite lands in the lead's email and the rep's. Today no invite arrives at the test email.

Why it mattersThe invite IS the appointment for the lead — no invite, no call. The code already asks Google to notify all attendees, so if it still fails the cause is almost certainly a Workspace permission (domain-wide delegation) the run will surface as your action, not silently swallow.

flowchart TD
  B["Booking created"] --> G["Google Calendar<br/>invite (sendUpdates=all)"]
  G --> Le["Lead inbox<br/>(your ProtonMail test)"]
  G --> Re["Rep inbox"]
  G -.->|"if blocked"| Cf["Owner action:<br/>enable DWD / config"]

B4 · Negative Replies should look like New Leads

TL;DRSame buttons in both columns: the 'Send Emails' button present, no stray booking button.

Input: a card sits in the Negative Replies column. Output: it shows exactly the same actions as a New Leads card — Send Emails yes, stray Book-appointment no.

Why it mattersRight now a leftover booking button shows where it makes no sense and the Send-emails button is missing — so the same job needs different clicks in different columns. Consistency means you never have to relearn a card.

flowchart LR
  subgraph New Leads
  n1["Send Emails"]
  n2["Log Call"]
  end
  subgraph Negative Replies
  g1["Send Emails"]
  g2["Log Call"]
  end
  n1 -.->|"must match"| g1
  n2 -.->|"must match"| g2

B5 · A move should stick

TL;DRDrag a card New Leads → Negative Replies via the dropdown and it stays there after a reload — both directions.

Input: you pick 'Negative Replies' from a card's Move-to dropdown. Output: the card is in Negative Replies, and STILL there after you refresh the page. Today it snaps back.

Why it mattersThe board derives the 'Negative' column from a hidden flag, not the stage you set — so the move looked done but wasn't saved where the board reads it. A move that doesn't persist makes the board untrustworthy.

flowchart LR
  Mv["Move-to:<br/>Negative Replies"] --> Sv["Save the flag<br/>the board reads"]
  Sv --> Rl{"Reload"}
  Rl -->|"fixed"| Stay["Stays in<br/>Negative Replies"]
  Rl -.->|"today (bug)"| Back["Jumps back to<br/>New Leads"]

B6 · Log Call: two clean choices

TL;DRLog Call shows just two buttons — 'Book appointment' (editable invite, still approve-gated) and 'Set FUP date'. The redundant date-picker is gone.

Input: you click Log Call on a card. Output: two buttons. 'Book appointment' reveals an optional note + the prefilled, fully-editable Meet fields (title, body, recipients, time, duration) and sends only when you click the blue button. 'Set FUP date' reveals a note + a follow-up date. No duplicate date-picker.

Why it mattersToday there are two ways to book and a leftover date-picker — confusing and error-prone. One clear entry, editable so you can personalise the invite ('we agreed X on the phone'), and the send still passes the human approve gate so nothing leaves without your click.

flowchart TD
  Lc["Click 'Log Call'"] --> Two{"Two buttons"}
  Two --> Ba["Book appointment"]
  Two --> Fu["Set FUP date"]
  Ba --> Ed["Optional note +<br/>editable Meet fields"]
  Ed --> Gate["Blue button =<br/>your approve gate"]
  Fu --> Fd["Note +<br/>follow-up date"]

How this run is kept safe

TL;DRTest fixtures only (ZZ-named), the human approve gate stays on, AUTOSEND is never flipped, nothing is pushed until you accept.

Input: the signed EBO. Output: builders fix each item test-first, a separate QA agent verifies each against your answer-key, everything merges + re-tests, then waits at PENDING_REVIEW. Real deals and the live send switch are never touched.

Why it mattersThe whole point is that you sign once at the start and accept once at the end — and in between the safety rails are mechanical, not promises. Your real leads, your live email switch, and the remote repo are all off-limits until you say go.

flowchart LR
  Sign["You sign EBO"] --> Build["Builders (TDD)"]
  Build --> Qa["QA twin checks<br/>vs your answer-key"]
  Qa --> Mg["Merge + re-test"]
  Mg --> Pr["PENDING_REVIEW"]
  Pr --> Acc["You accept -> deploy"]
  Build -.->|"never"| Bad["real deals /<br/>AUTOSEND / push"]

The full EBO answer-key (markdown) →Click-by-click journeys (HTML) →Edit/sign in Notion →