# Next Session: Phone Ordering Parity

## What
Port Fixes 1 (cheese routing), 2 (past-date validation), 3 (layered login diagnosis), and 6 (re-entry guard) from the coffee-fragility-fixes plan to the phone voice channel. Phone runs `scripts/phone_call.py` on Panda with its own LLM loop — verified by grep it does NOT share `_detect_tool_choice` or ordering tools with `annie-voice`.

## Why deferred from main plan
The main plan (`~/.claude/plans/coffee-fragility-fixes.md`) claimed phone was IN-SCOPE via shared `text_llm.py`. Adversarial review (ARCH-HIGH-7) flagged this as unverified. Verification by grep confirmed phone does NOT import the shared routing code. A parallel change set is required for the phone LLM loop.

## Scope
1. **Routing parity** — if phone receives "order me some bocconcini", it must route to `order_from_cremeitalia`. Current phone tool dispatch is a separate path (probably Panda-local LLM with its own prompt + tool list). Work requires:
   - Reading `scripts/phone_call.py` + whatever Panda-local dispatch module it uses.
   - Porting the `_compile_cheese_pattern` / `_CHEESE_STATIC_TERMS` logic into the phone path.
   - Porting the 5s `_DispatchGuard`.
2. **Date validation parity** — phone path to `schedule_coffee_delivery` (if any) must also run `_parse_and_validate_date`.
3. **Login diagnosis parity** — if phone can trigger coffee ordering, the `_diagnose_login` codepath must serve it (single implementation in `browser_agent_tools.py` — phone calls into it via HTTP).

## Open questions (research first, before coding)
- Does phone actually call `schedule_coffee_delivery` at all? If no → this reduces to a Fix-1 routing change only.
- Does phone's LLM loop use its own intent regexes? If yes → port cheese terms. If no (pure LLM-driven tool selection) → verify the LLM has correct tool descriptions.
- Is there a shared library between annie-voice and phone that could be factored out for DRY routing?

## Non-goals
- Rewriting phone to share `annie-voice` tool dispatch. That's a bigger consolidation, separate effort.

## Acceptance
- "order me some bocconcini" via phone → dispatches `order_from_cremeitalia`.
- "order me coffee for 01/01/2020" via phone → returns `VALIDATION_ERROR: date '01/01/2020' is in the past ...`
- Double-dispatch within 5s on phone is suppressed with the same error message as browser.

## Prerequisites
Main plan (`~/.claude/plans/coffee-fragility-fixes.md`) must be merged + deployed first. This session builds on top of it.

## Preview-flow requirement (from `annie-screenshots-and-selfheal.md` Phase B)

When coffee is wired from Annie's phone channel, the preview-then-Telegram-approval
flow from Phase B must ship at the same time. Do NOT route phone coffee intent
to any direct-execution path — always go through `preview_coffee_delivery`.

The Telegram Confirm/Cancel card is the approval surface regardless of which
Annie channel initiated the request. This is a load-bearing architectural
decision: it keeps a single human-in-the-loop gate in one place (Telegram)
rather than scattering approval surfaces across channels.

Screenshots are N/A for the phone channel itself (no photo delivery over the
voice call) — the phone session should instead listen to Context Engine memory
updates for order completion. The screenshot appears in Telegram, not on the
phone.