One tour-move decider or two?

Decision page · DECIDED (Fede, 2026-08-11): keep the current solution — the refactor does not ship · Follow-up to the duplicate-reschedule RCA

Decision (Fede, 2026-08-11): Option 1 — the current solution stays.

The refactor was fully built anyway (five review rounds to a clean approval, evals passing, provably inert when off) and is parked on its branch as a ready fallback — its PR is closed, the branch stays. On first real evaluation the refactor also scored better than unmodified main on the shared pipeline check (2/10 vs 0/10), so it was not rejected on quality: it was judged not worth the risk/effort while the shipped fix holds. Tripwire stands: one more cross-decider interference incident reopens this decision, starting from the parked branch. Learnings, gaps, and the long-term vision are merged to the repo as docs/planning/tour-write-path-learnings-2026-08.md.

The question (Fede, 2026-08-10): "Why do we have 2 mechanisms to schedule/reschedule? Seems like you only let both mechanisms know about each other — but do we need 2?"

Correct on both counts. Today a tour move can be decided by two different brains: the deterministic message parser (added July, because trusting Clara alone dropped 3 of 5 real reschedules) and Clara's own tool call (needed for ambiguity, negotiation, and voice). They share one write function, and since PR #5644 they share evidence — but two independent deciders is why the duplicate-notification bug was possible at all, and any future third path could recreate the class.

Options

Option 1 — Keep two deciders, shared evidence (status quo, shipped)
Option 2 — Parser proposes, Clara executes, enforcer backstops (Recommended)
Option 3 — Parser only, strip Clara's tour tools

Pick one

A. Stay on Option 1 — the fix is enough, revisit only if the class recurs.

B. (Recommended) Option 2 as a scheduled follow-up — file it as a card, build it when tour work is next touched.

C. Option 2 now — prioritize this week.

The history investigation (2026-08-10, full git archaeology)

The track record is real, and it is not decaying. Twenty tour incidents are traceable in five months. Seven came from the agent not acting when it should (the July cluster that birthed the automatic path); seven came from the two paths interfering with each other — duplicate tours, duplicate confirmations, duplicate PM notifications, a confirmed tour silently demoted. The interference incidents cluster March (4), July (2), August (1): the July/August ones happened after the March fixes, in a system carrying far more coordination code. One known interference bug is still quarantined out of the nightly gate today.

The etiquette tax: roughly 1,100 lines across 15 files exist solely to keep the two deciders from colliding — tool-stripping, prompt rules, the new transcript record, idempotency guards, refuse-guards, counting checks. Three different mechanisms encode the same fact ("this was already done") with three different lifetimes, which is exactly how this incident happened.

Surprise finding: there are arguably three deciders, not two — an older phone-keyed confirm/cancel state machine (flagged in ADR-0090) can still commit with live side effects before the hardened pipeline runs on the same turn.

Why not refactor now: two evidence-based reasons. Today's fix has zero days of bake — and it is the first time the automatic path's actions are durable, which is the exact substrate the refactor needs; the cheap experiment is to watch it. And "parser proposes, agent executes" is only safe if the backstop can execute the move itself when the agent drops it — today every guard in the tree can block or hold a reply, but nothing can act. Handing the commit back to the agent without an executing enforcer re-opens the July failure the automatic path was built to stop (measured then at 3 of 5 real reschedules dropped).

Determination

Next quarter, sequenced — with a tripwire that promotes it to now.

Follow-ups noted while closing the incident

PropFlow Docs