govoplan-campaign/docs/EXAMPLE_CAMPAIGNS_AND_RELEASE_CHECKLIST.md

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, a credential-free campaign with one active recipient and no attachments; its automated acceptance check physically blocks Mail and Files imports, denies network connections, and validates/builds from an unrelated temporary workspace
• 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
• greenmail-delivery, a credential-free real-delivery Campaign materialized with a temporary Mail-owned profile by the loopback acceptance runner

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 python -m unittest discover -s tests -p 'test_example_campaigns.py' and retain its isolated validate/build result as release evidence.
• 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.
• Run dev/mail-testbed/run_campaign_acceptance.py and retain its bounded JSON projection. It must show one SMTP acceptance, one IMAP append, no duplicate effect from a repeated ordinary send, matching Campaign report/audit state, and no resolved transport material in Campaign JSON or its execution snapshot. Its controlled endpoint evidence must also show explicit SMTP 451, partial RCPT refusal, post-DATA ambiguity, and task-process interruption classifications without retaining addresses or provider diagnostics.
• Treat the task-process restart proof separately from the still-open Redis/Celery broker redelivery and daemon-supervision check; the coverage projection must keep celery_broker_redelivery false.
• Run dev/mail-testbed/run_celery_redelivery_acceptance.py as a separate destructive worker-loss check. Retain its bounded evidence only when the same broker task is observed at both workers, the durable state is outcome_unknown, broker queue/unacked counts are zero, and the controlled SMTP endpoint observed one connection and one DATA transaction. This closes local Redis/Celery redelivery coverage, while production supervisor and target-provider coverage remain false until separately tested.
• 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.