chore: sync GovOPlaN module split state

docs/EXAMPLE_CAMPAIGNS_AND_RELEASE_CHECKLIST.md

@@ -0,0 +1,76 @@
+# 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
+- campaign using inline SMTP/IMAP settings where policy allows campaign-local
+  settings
+- 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.
+- Secret values must be represented through saved-credential placeholders or
+  secret references.
+- 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 inline SMTP/IMAP settings are hidden or blocked when policy disables
+  campaign-local mail settings.
+- 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 SMTP and IMAP settings 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.