govoplan-campaign/examples/README.md

GovOPlaN Campaign Examples

These examples are the maintained scenario catalogue for campaign release checks. They are intentionally small and credential-free. Add concrete fixture files next to this README only when they can be validated by the current campaign schema and do not require production data.

Scenarios

Scenario	Required Modules	Release Check
simple-announcement	core, access, campaigns	Validate and build one active recipient without attachments.
addressing-matrix	core, access, campaigns	Exercise To, CC, BCC, Reply-To, bounce, and disposition-notification fields.
global-attachment	core, access, campaigns; optional files	Build one deterministic attachment and verify evidence.
recipient-attachment-rules	core, access, campaigns; optional files	Match recipient-specific attachment rules and verify per-recipient evidence.
zip-protected	core, access, campaigns	Build password-protected AES ZIP output and verify password-source metadata.
mail-profile-send	core, access, campaigns, mail	Select a reusable mail profile and send through the GreenMail test bed.
inline-mail-settings	core, access, campaigns, mail	Use campaign-local SMTP/IMAP settings only when policy allows it.
warnings-review	core, access, campaigns	Require explicit review before queueing jobs with warnings.
blocked-send	core, access, campaigns	Confirm blocked recipients or missing attachments cannot be queued.
mock-delivery	core, access, campaigns, mail with dev capability	Capture messages in the development mailbox.
greenmail-delivery	core, access, campaigns, mail	Send no-attachment, normal attachment, and ZIP attachment variants through dev/mail-testbed.

Fixture Rules

• Do not commit real recipients, mail credentials, or production attachment names.
• Keep attachments deterministic and small.
• Store secrets as placeholders, saved-credential references, or local .env values consumed by the test bed.
• Declare optional module requirements in fixture metadata.
• Fixtures must not import files or mail modules directly; optional behavior is discovered through core module metadata and capabilities.

Validation Flow

Before a release tag:

1. Run module permutation startup checks from core.
2. Validate every committed example fixture against the current campaign schema.
3. Build exact messages for each fixture.
4. Run the mock-delivery example when the dev mailbox capability is enabled.
5. Run dev/mail-testbed/run_transport_smoke.py.
6. Execute the delivery checklist in docs/EXAMPLE_CAMPAIGNS_AND_RELEASE_CHECKLIST.md.