Summary

Three confirmed Pirros/Vooma incidents where meeting recordings got misrouted or silently discarded when Cedar couldn't confidently attribute them to a conversation:

• Calendar backstop window too tight , a real, already-linked calendar event started 3m15s after the recorder's reported meeting time; the prior 2-minute window excluded it. Widened to 7 minutes.
• Domain-identification misattributing to tools/vendor platforms , a TMS tool mentioned 28x in a transcript got fuzzy-matched as the counterparty (Vooma/McLeod); a meeting-notetaker's own recording-platform domain got used as a fallback answer when no sender existed to check (Pirros/Reza). Both fixed with eval-validated prompt instructions.
• Unattributed meetings vanished with no trace , pre-execution-setup.ts threw before createAndLinkEvents() ever ran, so a meeting Cedar couldn't attribute left no crm_events row at all , nothing to notify about, nothing to fix later. Extended the nullable-conversation_id model email already uses (docs/unknown-removal.md) to meetings: the event is now recorded unattributed, and a single-button Slack ping lets the rep resolve it (reusing the existing move_event mutation and the existing agent_prompt/operation-registry machinery , no new plumbing).

Two real Pirros meetings (Reza/K2M Design, JEO Consulting) that were sitting on the generic "Fathom" vendor bucket were moved to their correct conversations as a worked example of the resolution path.

Full design doc: apps/server/docs/design/ambiguous-meeting-company-assignment.md.

What changed

1. calendar-events.ts , 2min → 7min matching window + decision-point logging.
2. domain-identification.ts , two instructions (competitor/tool-role rule, meeting-has-no-sender rule), validated via the playbook-instruction-eval harness against real production transcripts (both went from ~4-12% failure to 0/8-24 trials).
3. meeting-events.ts , findOrCreateMeetingEvent accepts conversationId: string | null; never downgrades an already-linked event to unattributed on a failed re-resolution (shouldUpdateEventConversationId).
4. pre-execution-setup.ts , records the meeting unattributed and pings before the (unchanged) ExpectedTerminationError throw, meetings only.
5. New meeting-ambiguity-ping{,-message}.ts , decision (dedupe on new-event-only, no kill switch) + message/send, mirroring the existing services/aop/ambiguity-ping{,-message}.ts pattern.

Review

Ran this repo's thermo-review skill against the full diff. One real bug found and fixed during review: the ping rendered meeting times in the server's local timezone instead of the recipient's own (every other time-formatting call site in this codebase resolves slackNotifications.digestTimezone) , fixed, with a deterministic test proving the same UTC instant renders correctly in two different timezones. Also added the dependency-direction justification comment the AOP-ping file carries for its equivalent type-only import. No blocking issues.

Two open questions from the review, left to reviewer judgment rather than answered unilaterally:

• No feature flag ships with this (explicit decision , the ping only fires on a rare failure branch, not a hot path). No per-org escape hatch exists if it turns out noisier than expected for some org's meeting mix.
• Whether any existing "all meetings" list surface reads crm_events without filtering on conversation_id IS NOT NULL wasn't traced , if one exists, an unattributed meeting could surface somewhere unexpected before a human resolves it.

Test plan

• pnpm --filter @zero/server run types , clean
• pnpm --filter @zero/server run types:test , clean except pre-existing unrelated failures (confirmed via git show HEAD:... predate this branch)
• pnpm deps:check , 0 violations
• New/touched test files: 36/36 passing (meeting-ambiguity-ping.test.ts, meeting-ambiguity-ping-message.test.ts, `meeting-events.shouldUp