# Example Campaigns And Release Checklist

This document defines the campaign examples and release gates that should be
kept working before a GovOPlaN Campaign release is tagged.

## Example Campaign Set

Maintain fixtures or guided examples for these scenarios. The canonical
scenario catalogue lives in `examples/README.md`; committed fixture files should
be added under `examples/` only when they validate against the current campaign
schema and are safe to run in non-production environments.

- simple announcement with one active recipient and no attachments
- multi-recipient message with To, CC, BCC, Reply-To, bounce, and disposition
  notification fields
- campaign with global attachments and recipient-specific attachment rules
- campaign with password-protected ZIP attachments
- campaign using a reusable mail profile from the mail module
- legacy inline SMTP/IMAP campaign rejected with an actionable profile-migration
  error and no returned transport data
- campaign with validation warnings that may be sent only after explicit review
- campaign with blocked recipients or attachment errors that must not be sent
- mock delivery campaign that captures SMTP and IMAP append messages in the mail
  development mailbox
- real non-production delivery campaign against the GreenMail test bed

## Fixture Rules

- Examples must not contain production recipient data or production credentials.
- Attachment examples should use deterministic small files and checksums.
- Mail secrets belong only to encrypted Mail profiles and must never appear in
  a campaign fixture, placeholder, or campaign-local secret reference.
- Examples that require optional modules must declare the required modules and
  capabilities in their README or fixture metadata.
- Examples must stay valid when files or mail modules are physically absent,
  with optional behavior disabled instead of import failures.

## Release Gates

Before tagging a campaign release:

- Review `examples/README.md` and update the scenario catalogue when a release
  adds or removes delivery behavior.
- Run core module permutation tests with campaign installed both with and
  without files/mail.
- Validate and build each maintained example campaign.
- Run the mock delivery example when the mail development mailbox capability is
  enabled.
- Run the GreenMail SMTP/IMAP smoke for a non-production real delivery path.
- Confirm reusable mail profile selection is revalidated after campaign owner
  transfer.
- Confirm every inline SMTP/IMAP field is rejected on import/write, omitted
  from responses, and blocked from legacy execution until explicitly migrated.
- Confirm execution snapshots store only the Mail profile reference and
  opaque Mail-owned transport revisions, not resolved transport material.
- Confirm delivery reports include SMTP outcome, IMAP append outcome, latest
  error, generated EML reference, and attachment evidence.
- Confirm retries cannot resend messages already accepted by SMTP unless an
  explicit reconciliation path allows it.

## Ownership Transfer Check

Reusable user/group mail profiles are owner-context-sensitive. When campaign
ownership changes, the editable current version must require profile reselection
and validation before live delivery. A locked delivery-final version should not
be silently rewritten.

## Delivery Checklist

Use the Review & Send preflight panel and the delivery runbook together:

1. Validate and resolve all blocking policy/data issues.
2. Build exact messages.
3. Review warnings, generated recipients, body content, and attachment evidence.
4. Run mock delivery if available for the release channel.
5. Test the selected Mail profile against non-production infrastructure.
6. Send only after queue, rate limit, and append-to-Sent behavior are understood.
7. Reconcile failed, unknown, or pending jobs from the report/audit surfaces.