Update to MailChannels

{
  "description": "Design and implement MailChannels production controls for downstream or multi-tenant outbound email. Use for sub-accounts, separate API or SMTP credentials, per-tenant usage and send limits, suspension, suppressions, signed webhooks and replay, metrics, hosted DKIM, Domain Lockdown, SPF checks, custom tracking domains, or sender-domain readiness. Verify current account limits and do not claim reputation isolation.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 287
    },
    {
      "relative_path": "references/control-plane.md",
      "size_in_bytes": 2905
    }
  ],
  "name": "mailchannels-platform-operations",
  "skill_md_contents": "---\nname: mailchannels-platform-operations\ndescription: Design and implement MailChannels production controls for downstream or multi-tenant outbound email. Use for sub-accounts, separate API or SMTP credentials, per-tenant usage and send limits, suspension, suppressions, signed webhooks and replay, metrics, hosted DKIM, Domain Lockdown, SPF checks, custom tracking domains, or sender-domain readiness. Verify current account limits and do not claim reputation isolation.\n---\n\n# MailChannels Platform Operations\n\nUse this skill for the delivery control plane regardless of application\nlanguage. Read\n[references/control-plane.md](references/control-plane.md) before implementing\nsub-accounts, webhooks, quotas, or domain operations.\n\n## Model boundaries first\n\nMap each tenant, customer, workload, or trust boundary to:\n\n- an authenticated application identity and owner;\n- an account or sub-account credential;\n- an application budget plus any provider-side limit;\n- a suppression and webhook scope;\n- an active, paused, suspended, or closed lifecycle state;\n- auditable credential issuance, rotation, and revocation.\n\nTreat separate credentials, limits, suppressions, and webhooks as operational\nboundaries. Do not call them reputation isolation unless current MailChannels\ndocumentation or support confirms the exact required behavior.\n\n## Provision safely\n\n1. Verify current account limits and resource behavior.\n2. Create a stable, non-secret tenant-to-provider mapping.\n3. Issue the narrowest credential into a secret store and retain only metadata.\n4. Set a provider-side send limit and an application-owned atomic budget.\n5. Enroll and validate the correct webhook scope.\n6. Configure DKIM and other required DNS, then run the domain check.\n7. Test independent pause, suspension, credential rotation, and recovery.\n\n## Operate delivery state\n\n- Treat send acceptance as submission rather than final delivery.\n- Verify raw webhook bytes, digest, freshness, key ID, and RFC 9421 Ed25519\n  signature before parsing events.\n- Store event identity transactionally before applying side effects.\n- Inspect and resend failed webhook batches only after confirming receiver\n  failure; never replay business effects blindly.\n- Reconcile complaints, opt-outs, and permanent failures with the correct\n  suppression scope.\n- Alert before tenant or parent capacity blocks critical traffic.\n\nTreat domain checks as configuration evidence, not a delivery or inbox-placement\nguarantee.\n"
}