Skip to main content

Plural SMS Lead Alerts — Expected Output Spec

§1 Expected output​

  • New optional pref notification_phone_cc (comma-separated E.164-normalizable numbers), exactly parallel to notification_email_cc: parsed with the same clean/dedupe/primary-exclusion posture (a shared or twin parser).
  • Engine (server/notifications.ts): when SMS fires, it sends to the primary notification_phone AND each CC number — one send per number, primary first, CCs after, failures per-number isolated (one bad number never blocks the rest). sms_urgent_only applies to ALL SMS recipients alike.
  • Card: an "additional SMS numbers" add/remove list beside the existing phone field, same idiom as the email recipients list. API (lead-recipients route) validates each number as E.164-normalizable.
  • Existing single-phone tenants are untouched until they add a CC (absent key = today's behaviour, byte-for-byte).

§2 Acceptance checks​

  1. With a CC set, a qualifying lead produces one SMS per number (unit-test the fan-out list construction; do NOT send real SMS in tests).
  2. Absent key → engine path identical to today (regression pin).
  3. Invalid CC rejected at the API with a per-field message.
  4. Removing all CCs restores single-phone behaviour.
  5. Watcher-vote rule parity: if email CCs are excluded from any dedupe/claim logic ("watcher copies do not vote", notifications.ts ~657), SMS CCs get the same treatment — verify what that rule does and mirror it.

§3 Out of scope​

Per-recipient quiet hours; SMS for non-lead events; church parity.