The tour decider, before and after

"Deciding" means: a prospect says something about a tour — yes, no, cancel, "can we do Thursday?" — and code has to pick what happens to the booked tour.

Before — three writers, three dialects Prospect reply text or email Phone call Clara on the line Message parser scans every reply on arrival Old yes / no / cancel matcher keyed to the phone number Clara’s own tools books & cancels mid-conversation Tour record one booking same message, both read it writes writes writes 3 writers can disagree or race each other
Three pieces of code each act on the same tour, and each speaks its own internal "dialect". The Aug 15 incident was exactly this: a safety check and the old matcher disagreed about what a cancelled tour looks like, and a customer’s true reply got deleted.
After — one decider, one doorway Prospect reply text or email Phone call Clara on the line One tour decider reads the reply, picks the action Clara’s own tools books & cancels mid-conversation One doorway applies the change Tour record decision same doorway old matcher — deleted
Every tour change is decided in one place and applied through one doorway. A fix — like the dropped-decline bug — lands once and holds everywhere. The replay proved this rewiring changes no outcomes on real conversations.

Where we are

  1. Done: the new single decider is merged, switched off everywhere; the full-history replay proved it behaves the same as today.
  2. Fede’s call: turn it on for the Willows test property for a short live trial, then delete the old matcher for good.
  3. Step 2 (parked, ~90% built): the message parser still writes tours directly today — the parked branch removes that last extra writer, finishing "one decider, period". Standing rule: the next cross-decider incident reopens it from the branch, not from zero.

Companion pages: the full-history replay report (the proof behind "behaves the same"), the consolidation decision page, and the Aug 15 incident RCA (why this exists).

PropFlow Docs