Decision — who is allowed to decide what happens to a tour?

Proposed — pending Fede's review · 2026-08-15 · Follows the Aug 15 RCA. Raised by Fede: "this seems like the wrong architecture."

The problem in three sentences

When a customer texts "I need to cancel my tour," three different pieces of software are each allowed to act on it: an old yes/no/cancel handler from the original phone-confirmation flow (runs first, speaks an old dialect), the modern tour pipeline (speaks the modern dialect), and Clara herself via her booking tools. All writes already funnel through one chokepoint (ADR-0106) — the database side is sound. What's triplicated is the deciding and the narrating: two dialects of "here's what I already did," and machinery that only understands one of them. That dialect gap is exactly how Ciara's correct cancellation acknowledgment got guard-blocked on Aug 15, five days after the gap was written down as a known follow-up.

Already in flight (no decision needed)

Tourniquet: one-field fix (legacy handler emits the modern action vocabulary) + an exhaustive contract test suite over deciders × actions × channels — PR in progress. Makes the three-decider world honest and tested, whatever is decided below.

The decision — pick one

	Option	What changes	Risk	Effort
A	Stop at the tourniquet. Keep three deciders; the contract suite is the permanent guarantee.	Nothing beyond the in-flight PR.	Sediment stays; every future feature must remember three interpreters exist. The next "five days later" is a matter of time.	0
B ★	Retire the old handler. The modern tour pipeline absorbs the yes/no/cancel duty (it already interprets propose/confirm/reschedule); the legacy handler is deleted. Two actors remain — pipeline before Clara's turn, Clara's tools during it — both emitting the same completed-action events.	One pre-agent interpreter, one dialect. The contract suite (built this week) becomes its regression net; the Ciara and Aug-10 replay fixtures prove parity before cutover.	The legacy handler's quirks (proposed-tour vs any-active-tour lookup, its intent classifier) must be reproduced or consciously dropped — the parity replay covers this.	Days. Shadow the pipeline's verdict against the legacy handler's on real traffic before flipping.
C	Full event-sourced turn context. Every actor (pipeline, tools, dispatcher rungs, Temporal timers) writes typed events to one ledger; Clara's turn context is rendered only from the ledger.	The most principled shape; guards/grounding read one stream.	Big refactor across the router, conversation-manager, and Temporal; weeks of migration risk for a benefit B mostly captures.	Weeks.

Recommendation: B. A is a bet that discipline outlasts sediment (Aug 15 is the counter-evidence). C is the right end-state but B captures most of its value at a tenth of the risk, and nothing in B forecloses C later. Sequence: contract suite lands (in flight) → pipeline learns yes/no/cancel behind a shadow comparison → parity proven on ≥30 days of replayed real traffic (the RCA's own gate) → legacy handler deleted.

Process rule that rides along (yes/no)

The Aug 10 session named the third decider and deferred it in prose; the prose evaporated. Rule: a "flagged as follow-up" in any PR body or session note must become a Trello card before the PR merges — the merge checklist asks for the card link.