Architecture

One operator action drives a six-stage pipeline in the adapter's `triageEmail`: clean (strip signature + quoted history), language-detect (script + stopword signals across en/fr/de/es/ja), classify (multilingual keyword scoring → category, with priority + sentiment heuristics), enrich (join to booking/guest/property/loyalty from shared-core), draft (a per-category reply framed + signed in the detected language with the booking reference filled), and QC (flag a missing reference or apply an empathetic tone on negative sentiment).

The app reads shared-core `booking`, `guest`, `property`, and loyalty for enrichment, and reads/writes the C2-owned entities `support_email` (with its embedded triage), `conversation`, `message`, and `ticket`. The data invariant holds throughout: an owner's triage is canonical — it mutates the email record and mirrors durably — while a viewer's run is ephemeral, returned for display with a credential-tagged cost row that resets and never mutates the shared email.

Emits `email.triaged`, `email.replied`, and (on route) `ticket.created` / `ticket.routed` on the in-process event bus, persisted to the durable event log. It shares the ticket/conversation/message model with #16 and #38, so an escalation here is an inbox item there. The sent reply hands off to #35's notification path.

The one metered stage is `email-triage`, dual-mode by design: Cloud `claude-haiku-4-5` (cost-capped, fail-closed) or OSS recorded at $0 on local hardware. The prototype runs OSS-only with no API key and is honestly labelled simulated — deterministic classification and curated localized drafts behind the same adapter surface a real model run swaps into in Stage-2. Out of scope and clearly labelled: real email send (no SMTP — replies land in the in-app sent viewer), and any real PII or copyrighted content. Cost, mode, and trace are inspector-only.