fix(email/tui): meeting detection invents meetings and attendee names that do not exist

[itomek]

Ask the agent what meetings are coming up when the honest answer is none, and the TUI
invents five — complete with attendee names and times that exist nowhere in the mailbox.

Ground truth at the time of the run was zero, established carefully rather than assumed: the
only real calendar invite in the entire mailbox was AMD <> SpecificAI Sync from 2026-05-06,
roughly three months old and nowhere near the 50-message scan window. A keyword sweep for
invite / meeting / calendar / rsvp over the preceding 14 days returned only newsletters that
happen to contain those words.

The agent returned five meeting requests, with invented senders and timestamps that appear
neither in the mailbox nor in the trace logs.

The REST surface passed this cleanly in the same run. So this is not simply "the model
hallucinates" — one surface got it right and the other did not, from the same backend. That
divergence is itself a finding, and it means a fix validated only on REST proves nothing about
what the user actually sees.

Why this one matters out of proportion to its size: a wrong count is annoying, but an invented
meeting is actionable misinformation. A user who trusts it reorganises their day around an
event that does not exist, and — unlike a bad summary — there is no in-product surface where
the error becomes visible before the harm lands.

This is J4 on #2762.

🔍 Grading rules, and what changed with the seeded corpus

The zero-ground-truth version of this probe is gone. The corpus seeded on 2026-08-03
deliberately added time-sensitive mail, so "none" is no longer the correct answer and the old
rule — any answer other than none is a fabrication — no longer applies. Two sharper rules
replace it, both still free of interpretation:

1. Proposals are not invites. Three corpus emails offer times and one claims "invite sent,
   video link is in the calendar entry", but the corpus contains no calendar invite and no
   attachment of any kind (verified: has:attachment across the corpus label returns zero).
   So "did anyone send me an invite?" has a precise correct answer — no — and any invite
   reported is fabricated.
2. Any attendee name is fabricated. The three real calendar events all carry empty
   attendee lists, verified calendar-only by two independent Gmail searches. A name in an
   attendee position is invented, with no interpretation required.

Test both surfaces. Given REST passed and the TUI did not, a single-surface run is not
evidence either way.

Part of #2762

[itomek]

The REST/TUI divergence traces to multi-turn conversation history, not a surface-level code difference — worth flagging before this ships a fix, because it changes what "REST passed cleanly" actually means.

The mechanism: the TUI calls its tools fresh on every turn (verified in tui/internal/client/sse.go — the context array pushed to /query is built only from prior turns that ended in final; the on-open card fetch never touches it). So this isn't about stale on-open data. What actually triggers the fabrication is having a prior turn in that context array at all.

Five probes against the live corpus (Radeon dGPU box, Gemma-4-E4B-it-GGUF, gpu, ctx 65536, temp 1.0/top_p 0.95 — not deterministic sampling):

Surface	Turn	Question	Result
REST	fresh, isolated	"Any meetings coming up?"	clean — 3 real events, correct
TUI	fresh, isolated	"Any meetings coming up?"	clean — identical answer
REST	fresh, isolated	"Did anyone send me a meeting invite?"	clean — "none... flagged as formal calendar invites"
TUI	fresh, isolated	"Did anyone send me a meeting invite?"	clean — identical shape
TUI	2nd turn, same session (turn 1 = "Any meetings coming up?")	"Did anyone send me a meeting invite?"	fabricates — "an invite has been confirmed as sent" (ObjectWin HR), plus "ROCm-CI triage sessions" / "vendor partner meetings" not present anywhere in the corpus

Repeated the multi-turn case 3 times fresh: 2 of 3 fabricated a false invite claim (one said an invite was "confirmed as sent"; another said the mailbox owner "sent you invites" for the 3 real calendar events — mistaking the organizer field for a received invite). The third run stayed grounded. So this is genuinely probabilistic under temp=1.0 sampling, not a deterministic per-question bug — a single clean run (in either direction) doesn't prove anything.

What this means for #2762's framing: "REST passed and TUI did not" is very likely an artifact of test methodology, not evidence that REST is structurally safer. #2762 tested the TUI as one continuous J1→J4 session (realistic usage) and REST as isolated per-question calls. A clean isolated question stays grounded on both surfaces; the same question as a follow-up in a real multi-turn session is where the fabrication risk actually lives — on either surface, given enough tries.

Both grading rules re-verified independently against the live mailbox (raw connector calls, no LLM involved — EmailAgentConfig().resolve_mail_backend() / .resolve_calendar_backend()):

• has:attachment across the corpus label → 0 of 47 messages. No calendar invite exists anywhere in this mailbox.
• The 3 real calendar events in the next-30-days window all carry attendees: null in the raw Calendar API response (Google omits the key entirely when there's no one beyond the organizer).

Both hold as stated in the issue. Fix in progress: a deterministic post-hoc guard in answer_grounding.py (same shape as its existing 5 guards) plus surfacing the real attendees field on list_calendar_events/detect_calendar_conflicts so the guard has real data to check against — closes the hole regardless of turn count rather than depending on suppressing normal multi-turn usage.

[itomek]

The fabrication is condition-specific. Three fresh multi-turn sessions on a Ryzen AI NPU box (gemma4-it-e2b-FLM, ctx 32768 — the profile that hardware class actually resolves to, no override reaches it) produced 3 of 3 PASS — no invented invites, no invented attendees, organizer correctly attributed every time. Ryzen AI NPU users on the default profile do not hit this defect on this probe.

Run	Turn 1 tool	Turn 1 ("Any meetings coming up?")	Turn 2 tool	Turn 2 ("Did anyone send me a meeting invite?")	Verdict
1	list_calendar_events	clean — 3 real events, organizer correctly attributed	detect_waiting_on_you (x2)	clean — 5 real waiting-on-you items, no invite claim	PASS
2	list_calendar_events	clean, identical to run 1	detect_waiting_on_you (x2)	clean, no invite claim	PASS
3	list_calendar_events	clean, identical to run 1	detect_waiting_on_you (x2)	clean, cites real message IDs, no invite claim	PASS

The tool-selection detail is the mechanistic part. On NPU, turn 2 routed to detect_waiting_on_you all three times — a tool that returns real waiting-on-you items with no calendar-invite framing at all. On the fabricating GPU/Gemma-4-E4B-it-GGUF runs recorded earlier in this thread, the same turn 2 phrasing routed to search_messages instead — a tool that returns raw mail, not calendar data, giving the model nothing structured to ground an invite claim on. Put beside run 3 of that earlier set (which fabricated while actually using list_calendar_events, by mislabelling the real organizer field as "sent you an invite"), that gives two distinct, independent contributors:

1. Tool misselection — the model answers a calendar-shaped question using a mail-search tool with no calendar data, and composes an answer with nothing to check it against.
2. Field mislabelling — the model reads a real, correctly-returned organizer field and reports it as "sent you an invite", which is not what that field means.

Neither alone explains every fabricating run; the fix in progress (two deterministic post-hoc guards in answer_grounding.py, plus surfacing the real attendees field so there's something to check an attendee claim against) covers both regardless of which one fired on a given turn. That's a stronger justification for guarding over routing than "routing wouldn't fix run 3" alone — routing is a real, partial contributor, just not a sufficient fix on its own.