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 while Mail and Files are absent.
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.
legacy-inline-mail-rejected	core, access, campaigns, mail	Confirm legacy campaign-local SMTP/IMAP data fails closed and requires explicit profile migration.
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, audit, campaigns, mail	Run a credential-free Campaign through a Mail-owned profile, GreenMail SMTP/IMAP, report/audit checks, repeat-send protection, and bounded failure drills.

Fixture Rules

• Do not commit real recipients, mail credentials, or production attachment names.
• Keep attachments deterministic and small.
• Store transport secrets only in encrypted Mail profiles or local .env values consumed directly by the test bed, never in campaign JSON.
• 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. Run python -m unittest discover -s tests -p 'test_example_campaigns.py' from this repository. The acceptance test copies each maintained fixture to an unrelated temporary workspace before using Campaign's public loader, validator, and message builder.
3. Validate every committed example fixture against the current campaign schema.
4. Build exact messages for each fixture.
5. Run the mock-delivery example when the dev mailbox capability is enabled.
6. Run dev/mail-testbed/run_transport_smoke.py for low-level transport and attachment variants.
7. Run dev/mail-testbed/run_campaign_acceptance.py for the Campaign journey and bounded evidence.
8. Execute the delivery checklist in docs/EXAMPLE_CAMPAIGNS_AND_RELEASE_CHECKLIST.md.