Mirror CMP registration contacts and newsletter sync through Relay

Start at courses/views/registration.py::_save_registration_if_valid and trace how accepted_newsletter is persisted, then read community_base.mail.relay_contacts.RelayContactsClient and configured_contacts_client to see the Relay contacts API the sync should use. Verify the actual website client identity (audience dtc, client dtc-website) against the deployment docs. But this issue is blocked on CMP intake 64569174 landing, demands agent-process artifacts, deploy evidence, and a non-PR direct-push workflow — not something a newcomer can start now.

Intake and outcome

Hub intake 9f153998-97e3-4d7b-9a92-3d82e905b3d0, mirror of CMP intake 64569174. CMP is primary: do CMP first and mirror its accepted registration behavior on this website. Verify how registration synchronizes contacts, consent, and newsletter acceptance (accepted_newsletter), and ensure it goes through the Relay contacts API using the website client and Relay naming.

Authority

• Agent notes
• Development process
• Application boundaries
• Course specification
• Security, privacy, operations
• Selective verification

The explicit intake controls this bounded mirror; these references do not expand its scope.

Research and scope

At website base 35a023da73e9f61173f82e273eea8c001b11830c, courses/views/registration.py::_save_registration_if_valid saves the registration and schedules confirmation mail. The form persists accepted_newsletter; there is no contact synchronization call in that submit function. The shared package already provides community_base.mail.relay_contacts.RelayContactsClient and configured_contacts_client, including POST /api/contacts using Relay configuration.

Trace the actual registration contact/consent/newsletter path. Add the missing synchronization or, if the complete path already complies, record code-path evidence and a Relay log of an approved test upsert and rename only leftovers. Use the established website identity rather than silently substituting the CMP identity. Relay production provisioning documentation names audience dtc, client dtc-website; development deployment documentation still refers to dtc-courses, so establish the actual website scope before claiming live acceptance.

Failures must produce a sanitized log and operator alert and never break registration submit. Existing observability events/logging must not be mistaken for proof of a configured alert. Keep personal data and untrusted provider/exception details out of diagnostics.

Dependencies

Blocked for implementation on CMP intake 64569174: the active primary owner must provide its landed SHA and final contact/consent/newsletter payload and failure behavior. Inspecting a primary draft is allowed; mirroring it before it lands is not. Record the accepted primary receipt and any necessary website-specific identity adaptation.

Sibling website registration sessions run in parallel. Use an isolated fresh-main worktree and rebase on fresh origin/main immediately before each push.

Non-goals

No change to which registration form is canonical, registration form policy, account verification policy, approval behavior, confirmation copy, or unrelated integrations. No deletions, PR, shared git stash, or emails to real users. A live test recipient may only be the single address explicitly allowlisted in the intake; its address is omitted from this public issue.

Acceptance criteria

• Verify website registration contact/consent/newsletter (accepted_newsletter) synchronization and ensure it uses the Relay contacts API with the website client and Relay naming: no DataMailer-named import, setting, environment variable, or dependency on the registration path. If already compliant, record code-path evidence plus a Relay log of an approved test upsert and only rename leftovers.
• Failures are loud through both a sanitized log and operator alert and never break registration submit.
• Tests cover registration to Relay contacts request/payload, its failure path, and a guard against DataMailer-named imports on the registration path. Existing suite remains green.
• Follow repository process, including independent tester and PM acceptance and required verification evidence. Work from an isolated worktree based on fresh origin/main; rebase on fresh origin/main immediately before every HEAD:main push. Push directly with no PR, preserve canonical-form ownership, make no deletions, and remove the task worktree/branch after delivery.
• Deploy DEV before prod and cite CI/deploy run IDs and SHAs. Never print secrets. Live email tests use only the intake allowlisted address.
• Produce /home/alexey/tmp/agent-reports/website-registration-relay-contacts-2026-10-24.md with SHAs and the required sanitized Hub-result JSON. Use uv or uv-backed Make targets for Python. Use project-local .tmp/ for scratch evidence.
• Throwaway containers use docker run --rm and agent.session=task-hub-4b69d917-add9-4098-962e-bbad05740ad1; install cleanup before creation, clean all created resources including failed starts, and preserve sibling and Coolify resources.

Verification scenarios

Django/integration: submit a valid registration and inspect the contacts request and payload under the website identity, including the accepted primary consent/newsletter mapping. Induce synchronization failure and verify the saved registration/submit remain successful while log and alert are emitted. Exercise the import guard on the actual registration path. Run the existing suite and the repository-required verification plan.

Browser: backend-only changes use the process-required Playwright smoke tier. Preserve existing registration success/error behavior; this issue does not require UI changes. Determine screenshot applicability from the verification plan.

Operations: obtain sanitized Relay-side evidence of the approved test upsert; record the primary and website SHAs and DEV then prod CI/deploy run IDs. Clean only resources created by this task.