Mirror CMP application notifications and review confirmation copy

Start by reading _docs/specs/05-events-registration-email.md and _docs/architecture/app-boundaries.md, then study CourseRegistrationAdmin.approve_registrations/reject_registrations, core/mail_templates.py, and the course_management.package_mail Relay adapter. Note this issue is explicitly blocked on a separate CMP primary intake and must mirror that landed behavior, plus coordinate with overlapping email and contacts workstreams. Done means operator and applicant notifications with idempotency, pending/approved copy distinction in _registration_done.html and course-registration-confirmation.md, tests, and a DEV-before-prod deploy with evidence — far beyond a first contribution, and it also mandates pushing directly to main with no PR.

Intake and outcome

Hub intake 6d92d0cd-6b36-45c4-9dff-3ed60b28a903, mirror of CMP intake 4d0452a8. CMP is primary: implement CMP first, then mirror its landed notification behavior on dtc-website. Notify operators of pending applications, notify applicants of review decisions, and distinguish pending applications from accepted registrations in page/email confirmation copy.

Authority

• Agent notes
• Development process
• Course specification
• Email specification
• Application boundaries
• Selective verification

The operator acceptance below controls this bounded mirror; these references do not expand the requested product behavior.

Repository evidence and scope

At website base 35a023da73e9f61173f82e273eea8c001b11830c, RegistrationCampaign.requires_approval, pending/approved/rejected registration states, and admin approve/reject actions already exist. CourseRegistrationAdmin.approve_registrations and reject_registrations use queryset.update without notifications. The admin also exposes a status field; preserve existing decision semantics while covering the operator's approve/reject behavior, including bulk actions.

courses/templates/courses/_registration_done.html already identifies pending applications but promises an email only after approval. email_templates/course-registration-confirmation.md declares registration confirmed unconditionally. The existing course_management.package_mail adapter and package EmailDelivery/durable jobs supply the current Relay sending boundary. core/mail_templates.py loads existing per-site markdown templates for publishing to Relay. Reuse that mechanism and existing old per-site layout; do not duplicate the new per-client branding work.

Scope is the requested operator/applicant notifications, operator recipients, idempotency, pending/approved confirmation distinction, safe visible failures, template publication, tests, and deployment/evidence.

Dependencies and coordination

Blocked for implementation on CMP intake 4d0452a8: obtain its landed SHA and final triggers, recipient configuration, digest/per-application choice, template wording, and idempotency behavior before implementing the website mirror. Expected primary report: /home/alexey/tmp/agent-reports/cmp-application-notifications-2026-10-24.md. A draft is not the accepted primary contract.

Coordinate with Relay branding intake bac87da0; do not duplicate its new layout. Use the website client for template publication. Related website email-verification work owns overlapping verification copy; contacts work owns its registration contacts hook; public course audit work owns approval access gates. Isolate edits and preserve those scopes through coordination and fresh-main integration.

Non-goals

Do not decide which registration form is canonical. Do not change approval semantics beyond notifications/copy. Do not add a new provider or template-rendering stack, redesign branding, delete files/features, create a PR, expose secrets, or email real applicants during verification.

Acceptance criteria

• Notify operators on every new pending registration for a campaign with requires_approval: email via Relay transactional API to [email protected] plus configured operators, with a setting/admin-configurable list and [email protected] as default. An hourly/daily digest with admin review links is acceptable if that is the primary's selected behavior. Notify at most once per registration.
• Email the applicant when an operator approves and when an operator rejects, including bulk admin actions, once per decision. Use Relay templates in the website's existing old-layout per-site template style (core/mail_templates), not the new per-client branding layout.
• Post-submit confirmation distinguishes pending applications (application received, awaiting review, email after review, no acceptance implication) from approved/auto-approved registration (current registered wording). Make the same distinction in any registration confirmation email the website sends.
• Publish Relay templates on Relay DEV and prod under the website client and list their keys in the report. Relay failures are loud through failed state, sanitized log, and alert; no fail_silently.
• Preserve canonical-form ownership and existing approval semantics beyond notification/copy changes.
• Unit tests cover operator notification/digest once, operator recipients, approve/reject emails, idempotency, pending versus approved confirmation text, and Relay failure. Existing suite and CI are green.
• Deploy DEV first and verify in Relay DEV logs, then deploy prod. Verify prod only with test registrations using the single operator-approved test address in the original intake; never email real applicants. Cite CI/deploy run IDs.
• Use a fresh origin/main worktree, push HEAD:main with no PR, follow AGENTS.md, remove task worktree/branch afterward, make no deletions, and print no secrets. Write /home/alexey/tmp/agent-reports/website-application-notifications-2026-10-24.md with SHAs and evidence.
• Match the landed CMP behavior for triggers, recipients, digest choice, wording, and idempotency. CMP is primary and goes first.

Verification scenarios

Django/integration: a new pending application creates the primary-selected operator notification/digest once with the configured/default recipients and review links; repeated processing does not duplicate it. Approve and reject through existing admin decision paths, including bulk, and verify applicant messages once per decision. Confirm pending/approved page and registration-email copy differ as specified. Exercise Relay failure and inspect failed state, safe log, and alert. Preserve existing approval effects and verify the existing suite.

Browser: follow repository verification for the changed confirmation template, including desktop/mobile pending and approved states, independent screenshot inspection, and the applicable Playwright tier. These checks verify the requested copy; they do not authorize unrelated UI changes.

Operations: record the primary receipt, published website-client template keys, sanitized Relay DEV verification, DEV-before-prod deployment/CI receipts, test-only prod verification, and task cleanup. Independent tester PASS precedes final PM acceptance under repository process.