Docs: dates are capture-and-defer (in-call computation removed)

Update the call-capture section to reflect the fix — AVA takes the day/time in
the caller's words and defers exact-date confirmation to staff; the 45-day
calendar injection and in-call date validation were removed after a real call
derailed and the 8B model proved unable to compute dates reliably. Post-call
resolved_date is best-effort/staff-verified only.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

CLAUDE.md

@@ -225,11 +225,11 @@ AB_MODEL_B=
 
 ---
 
-## Call Data Capture & Date Validation
+## Call Data Capture
 
 What AVA collects on a booking call and how it's logged. Driven by the system prompt
-(`bot.py`) plus a per-call calendar injection; persisted by the post-call extractor
-(`extract.py` → `practice.py` → Odoo lead).
+(`bot.py`); persisted by the post-call extractor (`extract.py` → `practice.py` → Odoo lead).
+Replies are kept to one short sentence.
 
 ### The six captured fields
 
@@ -240,23 +240,25 @@ What AVA collects on a booking call and how it's logged. Driven by the system pr
 | Office / city | Asks city/area; never names an office unprompted | folded into `reason` prefix |
 | Reason | Captured from the conversation | `reason` |
 | Insurance | **Log only** — asks the plan, never promises/confirms/denies coverage or treatment (even a listed plan); staff verify on callback | `insurance` (note: "log only — staff to verify") |
-| Preferred date & time | Validated against the calendar (below); confirmed before booking | `preferred_time` + resolved `YYYY-MM-DD` |
+| Preferred day & time | **Capture & defer** — taken in the caller's own words; AVA does not compute or correct the date | `preferred_time` + best-effort resolved `YYYY-MM-DD` |
 
-### Date validation
+### Dates — capture & defer (do NOT compute in-call)
 
-Each call's system message is injected with an **authoritative 45-day calendar** (today +
-each upcoming date with its weekday), recomputed per call since the server is long-running
-(`_date_context()` in `bot.py`). AVA must check any date the caller names against it. On an
-impossible or weekday/number-mismatched date it pushes back and offers the correct one, e.g.
-> "Next month, Monday lands on the sixth — would you like to schedule that date?"
+AVA takes the day/time in the caller's **own words** ("next Monday", "the fifth") and tells
+them staff will confirm the exact date on the callback. It must NOT work out, state, or correct
+the calendar date, and must never argue about what today's date is.
 
-The extractor is also given today's date so it can resolve relative phrasing
-("next month, Monday") to a concrete `YYYY-MM-DD`; the caller's own words are always kept too.
+**Why:** an earlier build injected a 45-day calendar and had AVA validate/correct dates in-call.
+A real call derailed badly — AVA argued about the date, parroted the canned example, and (with
+the model's weak adherence) also hallucinated availability. Tested directly, the local 8B model
+computes appointment dates wrong ~5/5 times, so stating a computed date is a liability. The
+calendar injection and in-call validation were removed (commit on 2026-06-25).
 
-**Reliability note:** this is the local 8B model reasoning over injected facts — accurate in
-testing but not guaranteed turn-to-turn. A deterministic date-resolver tool would harden it,
-but in-call tools stay off for this model (it leaks JSON). Treat the resolved date as
-staff-verifiable, not authoritative. Overlaps Phase 2 validation work.
+The post-call extractor still gets today's date and records a **best-effort** `resolved_date`
+for staff convenience — it is staff-verified on callback, not authoritative, and never spoken to
+the caller. A deterministic (non-LLM) date resolver is the right hardening if accuracy is needed;
+tracked as a later item. Also: never claim appointment availability or that a slot is open —
+everything is a request staff confirm.
 
 ---