Claude
47c8b37d45
Engagement Phase 1 (docs/website/ENGAGEMENT.md §1.2a, §3.1, §3.2). A subtraction and a replacement in one commit, because leaving the OAuth2 flow half-wired across a release is worse than either end state. Deleted, per the §1.2a inventory: GET /admin/email/connect/start and /connect/callback, the connectStart/connectCallback controllers with the email_oauth_tx signed cookie, the PKCE verifier and CSRF nonce plumbing, the https://mail.google.com/ scope, the borrowed `google` auth-providers client, the OAuth2 nodemailer transport with its smtp.gmail.com:465 literals, the refresh-token decrypt in the model, and the client's Connect Gmail button, redirect banner and six Gmail error strings. `provider` and `refresh_token_enc` stay as columns under the additive-only discipline, unread. Added: a mail transport registry (server/src/engagement/transports) with `smtp` as the sole registration. `credentialFields` is the single declaration the admin form renders, the sanitizer filters against, and the "is it secret" answer comes from, so adding a transport is a registration rather than four edits. email_config gains transport / credential_enc (one encrypted JSON blob, since the field list is the transport's to declare) / reply_to. All six call sites keep their exact failure contracts: the contact form's mailto fallback, the invite's copyable link, the reset's generic 200, and sendTeamNotification's never-throws. One deliberate behaviour change: `enabled` now gates every sender rather than only isConfigured() — the connect flow used to set it as a side effect, and with a credential form the toggle has to mean what it says. Send-test becomes the real verification. Under OAuth2 the sender came back from Google and was guaranteed to belong to the credential; operator-typed, it can be refused, so failures name the sender and the SPF/DMARC reason (§1.2a consequence 2). G22, the silent degradation: an upgraded deployment backfills to smtp with no credentials and every sink politely does nothing. The admin dashboard now warns when the deprecated Gmail token is present and no replacement credential is, so the one deployment this happens to is told. A fresh install has never had mail and is not nagged. Guardrails: new `npm run check:hosts` (§3.2 rule 4) with its own self-test, wired into pr-checks before the install; routes.manifest and routes.guards regenerated (-2 routes). Co-Authored-By: Claude <noreply@anthropic.com>
23 lines
1.1 KiB
JavaScript
23 lines
1.1 KiB
JavaScript
// ── The engagement subsystem — one door ────────────────────────────────────
|
|
//
|
|
// ENGAGEMENT.md Phase 1. Today this is the mail transport registry and core's
|
|
// own transports; the trigger registry, the rules engine and the delivery
|
|
// channels arrive in later phases and hang here too.
|
|
//
|
|
// **Core's transports register through the same door a module's would**, and
|
|
// they register HERE rather than at the bottom of the registry file. That keeps
|
|
// the registry free of any knowledge of its registrants — the same reason
|
|
// `registerCore()` is called from app.js rather than from inside
|
|
// `modules/registries.js` (MODULE_API.md §7.6) — and it means requiring the
|
|
// registry never has the side effect of populating it.
|
|
//
|
|
// Requiring this module is what makes `smtp` available. Everything that resolves
|
|
// a transport goes through here, so there is exactly one place a transport can
|
|
// come into existence.
|
|
|
|
require('./transports/smtp')
|
|
|
|
const transports = require('./transports')
|
|
|
|
module.exports = { transports }
|