@omega.js/backend 0.1.0

package/test/email/consent-lifecycle.test.js

@@ -0,0 +1,258 @@
+/**
+ * Test: Marketing Provider Lifecycle (end-to-end against live SendGrid + Beehiiv)
+ *
+ * Walks two long-lived test accounts through their full lifecycle and verifies
+ * provider state at every transition:
+ *
+ *   1. Pre-check    — both accounts should be absent from SendGrid + Beehiiv
+ *   2. Sync         — flip consent.marketing.status and call Marketing.sync()
+ *   3. Verify       — granted account present in both, declined account absent from both
+ *   4. Unsubscribe  — hit the email-preferences endpoint for the granted account
+ *   5. Verify       — granted account now absent from both
+ *
+ * The two accounts use the `_test.allow_*` prefix so they bypass the
+ * blocked-local-patterns gate (which blocks plain `_test.*` from reaching
+ * providers). They are the only accounts intentionally allowed to round-trip
+ * through SendGrid + Beehiiv.
+ *
+ * Run with TEST_EXTENDED_MODE=true (no-op otherwise). Requires SENDGRID_API_KEY
+ * and BEEHIIV_API_KEY in env. Total runtime is ~60-90s — most of it spent waiting
+ * for SendGrid's async upsert/delete background jobs to surface.
+ */
+const sendgridProvider = require('../../dist/manager/libraries/email/providers/sendgrid.js');
+const beehiivProvider = require('../../dist/manager/libraries/email/providers/beehiiv.js');
+const defineCases = require('../../dist/vendor/devkit/test/define-cases.js');
+
+const SETTLE_MS = 5000; // Beehiiv settles in 1-2s; SendGrid's background-job upsert can take 10-20s+
+const POLL_INTERVAL_MS = 2000;
+const POLL_MAX_MS = 90000; // SendGrid's delete-contact job can take 30-60s+ to surface
+
+function sleep(ms) {
+  return new Promise((resolve) => setTimeout(resolve, ms));
+}
+
+/**
+ * Poll a provider lookup until it matches the expected state (present/absent).
+ * Returns the resolved value (contact object or null) once condition is met, or
+ * the last value seen after timing out.
+ *
+ * @param {Function} fetchFn - async function that returns contact or null
+ * @param {boolean} expectPresent - true = wait until present, false = wait until absent
+ */
+async function pollProvider(fetchFn, expectPresent) {
+  const start = Date.now();
+  let lastValue = null;
+
+  while (Date.now() - start < POLL_MAX_MS) {
+    lastValue = await fetchFn();
+    const present = !!lastValue;
+    if (present === expectPresent) {
+      return lastValue;
+    }
+    await sleep(POLL_INTERVAL_MS);
+  }
+
+  return lastValue;
+}
+
+module.exports = defineCases({
+  description: 'Marketing provider lifecycle (live SendGrid + Beehiiv round-trip)',
+  type: 'group',
+  skip: !process.env.TEST_EXTENDED_MODE
+    ? 'TEST_EXTENDED_MODE not set (this test hits live SendGrid + Beehiiv APIs)'
+    : false,
+  tests: [
+    // ─────────────────────────────────────────────────────────────────────
+    // Phase 1 — Pre-check: both accounts should be absent from providers
+    // ─────────────────────────────────────────────────────────────────────
+    {
+      name: 'phase-1-pre-check-both-accounts-absent',
+      auth: 'admin',
+      timeout: 180000,
+
+      async run({ accounts, assert }) {
+        const granted = accounts['consent-granted'];
+        const declined = accounts['consent-declined'];
+
+        // Force-clean any leftovers from a prior run (e.g. the previous phase-2a
+        // left a contact in SendGrid that THIS run's phase-1 needs to start
+        // without). SendGrid's delete is an async job, so wait for absence.
+        await sendgridProvider.removeContact(granted.email);
+        await sendgridProvider.removeContact(declined.email);
+        await beehiivProvider.removeContact(granted.email);
+        await beehiivProvider.removeContact(declined.email);
+
+        const grantedSg = await pollProvider(() => sendgridProvider.findContact(granted.email), false);
+        const declinedSg = await pollProvider(() => sendgridProvider.findContact(declined.email), false);
+        const grantedBh = await pollProvider(() => beehiivProvider.findContact(granted.email), false);
+        const declinedBh = await pollProvider(() => beehiivProvider.findContact(declined.email), false);
+
+        assert.equal(grantedSg, null, 'granted account should be absent from SendGrid');
+        assert.equal(declinedSg, null, 'declined account should be absent from SendGrid');
+        assert.equal(grantedBh, null, 'granted account should be absent from Beehiiv');
+        assert.equal(declinedBh, null, 'declined account should be absent from Beehiiv');
+      },
+    },
+
+    // ─────────────────────────────────────────────────────────────────────
+    // Phase 2 — Sync granted account → both providers
+    // ─────────────────────────────────────────────────────────────────────
+    {
+      name: 'phase-2a-granted-account-syncs-to-both-providers',
+      auth: 'admin',
+      timeout: 180000,
+
+      async run({ accounts, assert, Manager, ctx, config }) {
+        const granted = accounts['consent-granted'];
+        const admin = Manager.libraries.admin;
+
+        // Set consent.marketing.status = 'granted' on the user doc
+        await admin.firestore().doc(`users/${granted.uid}`).set({
+          consent: {
+            marketing: {
+              status: 'granted',
+              grantedAt: {
+                timestamp: new Date().toISOString(),
+                timestampUNIX: Math.floor(Date.now() / 1000),
+                source: 'test',
+                ip: null,
+                text: 'consent-lifecycle test',
+              },
+            },
+            legal: {
+              status: 'granted',
+              grantedAt: {
+                timestamp: new Date().toISOString(),
+                timestampUNIX: Math.floor(Date.now() / 1000),
+                source: 'test',
+                ip: null,
+                text: 'consent-lifecycle test',
+              },
+            },
+          },
+        }, { merge: true });
+
+        // Trigger marketing sync via the Email() surface
+        const result = await Manager.Email(ctx).sync(granted.uid);
+        assert.ok(result, 'sync should return a result');
+        assert.notEqual(result.blocked, 'validation', 'sync should not be blocked by validation (uses _test.allow_*)');
+
+        // Poll providers until they reflect the upsert. SendGrid's upsert is
+        // an async background job (returns a job_id, not the inserted contact)
+        // so a single check 5s later isn't enough — it can take 10-20s to
+        // surface. Beehiiv is usually instant but uses the same poll for symmetry.
+        const sgContact = await pollProvider(() => sendgridProvider.findContact(granted.email), true);
+        const bhContact = await pollProvider(() => beehiivProvider.findContact(granted.email), true);
+
+        assert.ok(sgContact, 'granted account should now exist in SendGrid');
+        if (config.marketing?.newsletter?.providers?.beehiiv?.publicationId) {
+          assert.ok(bhContact, 'granted account should now exist in Beehiiv');
+        }
+      },
+    },
+
+    // ─────────────────────────────────────────────────────────────────────
+    // Phase 2b — Declined account: verify it stays out of providers when we
+    // DON'T call sync (which is what the signup route does for declined
+    // marketing consent).
+    // ─────────────────────────────────────────────────────────────────────
+    {
+      name: 'phase-2b-declined-account-stays-out-of-providers',
+      auth: 'admin',
+      timeout: 180000,
+
+      async run({ accounts, assert, Manager, ctx }) {
+        const declined = accounts['consent-declined'];
+        const admin = Manager.libraries.admin;
+
+        // Set consent.marketing.status = 'revoked' on the user doc.
+        // We deliberately do NOT call sync — the production signup route gates
+        // on consent.marketing.status === 'granted' before calling sync, so a
+        // declined user simply never gets a sync call. We verify that contract
+        // by NOT calling sync and asserting the user stays absent.
+        await admin.firestore().doc(`users/${declined.uid}`).set({
+          consent: {
+            marketing: {
+              status: 'revoked',
+              grantedAt: { timestamp: null, timestampUNIX: null, source: null, ip: null, text: null },
+              revokedAt: {
+                timestamp: new Date().toISOString(),
+                timestampUNIX: Math.floor(Date.now() / 1000),
+                source: 'test',
+                ip: null,
+                text: null,
+              },
+            },
+            legal: {
+              status: 'granted',
+              grantedAt: {
+                timestamp: new Date().toISOString(),
+                timestampUNIX: Math.floor(Date.now() / 1000),
+                source: 'test',
+                ip: null,
+                text: 'consent-lifecycle test',
+              },
+            },
+          },
+        }, { merge: true });
+
+        await sleep(SETTLE_MS);
+
+        const sgContact = await sendgridProvider.findContact(declined.email);
+        const bhContact = await beehiivProvider.findContact(declined.email);
+
+        assert.equal(sgContact, null, 'declined account should remain absent from SendGrid');
+        assert.equal(bhContact, null, 'declined account should remain absent from Beehiiv');
+      },
+    },
+
+    // ─────────────────────────────────────────────────────────────────────
+    // Phase 3 — Unsubscribe: granted account is removed via Manager.Email().remove
+    // ─────────────────────────────────────────────────────────────────────
+    {
+      name: 'phase-3-granted-account-unsubscribe-removes-from-both',
+      auth: 'admin',
+      timeout: 180000,
+
+      async run({ accounts, assert, Manager, ctx }) {
+        const granted = accounts['consent-granted'];
+
+        // Trigger removal — simulates the email-preferences opt-out flow
+        const result = await Manager.Email(ctx).remove(granted.email);
+        assert.ok(result, 'remove should return a result');
+
+        // Poll for absence — SendGrid's contact delete is also an async job.
+        const sgContact = await pollProvider(() => sendgridProvider.findContact(granted.email), false);
+        const bhContact = await pollProvider(() => beehiivProvider.findContact(granted.email), false);
+
+        assert.equal(sgContact, null, 'granted account should now be absent from SendGrid');
+        assert.equal(bhContact, null, 'granted account should now be absent from Beehiiv');
+      },
+    },
+
+    // ─────────────────────────────────────────────────────────────────────
+    // Phase 4 — Validation gate: _test.* (non-allow) is blocked by validate()
+    // ─────────────────────────────────────────────────────────────────────
+    {
+      name: 'phase-4-non-allow-test-email-blocked-by-validation',
+      auth: 'admin',
+      timeout: 30000,
+
+      async run({ assert, Manager, ctx }) {
+        // _test.never-reaches-providers@... is NOT _test.allow_* → should be blocked
+        const blockedEmail = '_test.never-reaches-providers@somiibo.com';
+
+        const result = await Manager.Email(ctx).add({ email: blockedEmail });
+
+        assert.equal(result.blocked, 'validation', 'non-allow _test.* email should be blocked by validation');
+
+        // And the provider lookup should show nothing
+        const sgContact = await sendgridProvider.findContact(blockedEmail);
+        const bhContact = await beehiivProvider.findContact(blockedEmail);
+
+        assert.equal(sgContact, null, 'blocked email should never appear in SendGrid');
+        assert.equal(bhContact, null, 'blocked email should never appear in Beehiiv');
+      },
+    },
+  ],
+});

package/test/email/content-html-policy.test.js

@@ -0,0 +1,270 @@
+/**
+ * Internal-only send-field policy test — four fields hand the renderer raw HTML (or
+ * the trust to render it), and none of them may arrive over the API.
+ *
+ * - `data.content.html` skips markdown entirely (the transactional/campaign body).
+ * - `html` is the top-level override that replaces the rendered MJML document outright
+ *   — a documented MCP `send_email` parameter until Ian's #125 ruling closed it.
+ * - `contentHtml` is the pre-rendered campaign HTML the newsletter generator hands to
+ *   `sendCampaign()` — read AHEAD of the escaped renderer, and it persists into the
+ *   stored campaign doc that cron sends later.
+ * - `trustedContent: true` flips the body renderer to `html: true`.
+ *
+ * First-party callers depend on all three, but a caller arriving over the API —
+ * including an admin-authenticated AI on the MCP `send_email` / `create_campaign` /
+ * `update_campaign` tools — must be turned away with a coded-400 permanent fault, or
+ * the escaped lane is one field away from being bypassed (#90).
+ *
+ * The external lanes assert the boundary through `prepare.internalOnlyFieldFault()`; the
+ * internal lane never calls it, so its passthrough must still work end to end.
+ *
+ * Plain-node unit test (no emulator, no network). The route round-trips that prove the
+ * boundary is WIRED live in test/routes/admin/email-content-html.test.js and
+ * test/routes/marketing/campaign.test.js.
+ */
+const assert = require('node:assert');
+const prepare = require('../../dist/manager/libraries/email/prepare.js');
+const { buildCampaignDoc } = require('../../dist/manager/routes/marketing/campaign/utils.js');
+const defineCases = require('../../dist/vendor/devkit/test/define-cases.js');
+
+// The internal lane's build runs for real so the passthrough is proven all the way to
+// the SendGrid payload, not just at renderContent().
+function transactionalBuild(settings) {
+  process.env.UNSUBSCRIBE_HMAC_KEY = process.env.UNSUBSCRIBE_HMAC_KEY || 'test-key';
+
+  const Transactional = require('../../dist/manager/libraries/email/transactional/index.js');
+  const Manager = {
+    config: {
+      brand: { id: 'testbrand', name: 'Test Brand', url: 'https://test.dev', contact: { email: 'hello@test.dev' }, images: {} },
+      // The account's unsubscribe group ids (#649) — every send resolves one from config
+      marketing: { campaigns: { providers: { sendgrid: { groups: { orders: 900001, hello: 900002, account: 900003, marketing: 900004, security: 900005, newsletter: 900006, internal: 900007 } } } } },
+    },
+    project: { websiteUrl: 'https://test.dev' },
+    libraries: { admin: {} },
+    User: () => ({ properties: {} }),
+  };
+  const ctx = { Manager, log: () => {}, error: () => {} };
+
+  return new Transactional(ctx).build({
+    to: 'user@test.dev',
+    template: 'card',
+    ...settings,
+  }).then((email) => email.content[0].value);
+}
+
+module.exports = defineCases({
+  description: 'Email internal-only send fields (content.html, html, contentHtml, trustedContent)',
+  type: 'group',
+  tests: [
+    // ---------- The external lanes reject it ----------
+
+    {
+      name: 'external lane rejects data.content.html with a coded 400',
+
+      run() {
+        const fault = prepare.internalOnlyFieldFault({
+          to: 'user@test.dev',
+          subject: 'Probe',
+          data: { content: { html: '<img src=x onerror="alert(1)">' } },
+        });
+
+        assert.ok(fault instanceof Error, 'no fault returned for data.content.html');
+        assert.equal(fault.code, 400, `fault must be a permanent 400, got ${fault.code}`);
+        assert.ok(fault.message.includes('data.content.html'), `message must name the field: ${fault.message}`);
+        assert.ok(/internal-caller only/.test(fault.message), `message must state the rule: ${fault.message}`);
+      },
+    },
+
+    {
+      name: 'external lane rejects the field even when it is empty',
+
+      run() {
+        // An external caller has no legitimate reason to send the key at all — the
+        // presence of it is the fault, not its contents.
+        assert.ok(prepare.internalOnlyFieldFault({ data: { content: { html: '' } } }) instanceof Error, 'empty html passed');
+        assert.ok(prepare.internalOnlyFieldFault({ data: { content: { html: null } } }) instanceof Error, 'null html passed');
+      },
+    },
+
+    {
+      name: 'external lane passes ordinary markdown settings through clean',
+
+      run() {
+        assert.equal(prepare.internalOnlyFieldFault({ data: { content: { message: '**hi**' } } }), null);
+        assert.equal(prepare.internalOnlyFieldFault({ data: {} }), null);
+        assert.equal(prepare.internalOnlyFieldFault({}), null);
+        assert.equal(prepare.internalOnlyFieldFault(undefined), null);
+      },
+    },
+
+    {
+      name: 'external lane rejects the top-level html override with a coded 400',
+
+      run() {
+        // `settings.html` replaces the rendered MJML body outright (transactional
+        // build()) — the same bypass as data.content.html, one level up. Ian's #125
+        // ruling put it on the internal-only list: the admin/MCP lane now matches the
+        // API lane exactly, and the MCP send_email tool no longer advertises it.
+        const fault = prepare.internalOnlyFieldFault({
+          to: 'user@test.dev',
+          subject: 'Probe',
+          html: '<img src=x onerror="alert(1)">',
+        });
+
+        assert.ok(fault instanceof Error, 'no fault returned for top-level html');
+        assert.equal(fault.code, 400, `fault must be a permanent 400, got ${fault.code}`);
+        assert.ok(fault.message.includes('html'), `message must name the field: ${fault.message}`);
+        assert.ok(/internal-caller only/.test(fault.message), `message must state the rule: ${fault.message}`);
+
+        // Presence is the fault, same as every other field on the list.
+        assert.ok(prepare.internalOnlyFieldFault({ html: '' }) instanceof Error, 'empty html passed');
+      },
+    },
+
+    {
+      name: 'the MCP send_email tool no longer advertises an html parameter',
+
+      run() {
+        // The tool schema is what an admin-authenticated AI reads. #125 removed the
+        // 'Raw HTML body (alternative to template)' parameter; if it ever comes back,
+        // the lane is advertising the bypass again.
+        const sendEmail = require('../../dist/mcp/tools.js').find((tool) => tool.name === 'send_email');
+
+        assert.ok(sendEmail, 'send_email tool not found — update this test');
+        assert.equal(sendEmail.inputSchema.properties.html, undefined, 'send_email re-advertises the html parameter');
+      },
+    },
+
+    {
+      name: 'external lane rejects top-level contentHtml with a coded 400',
+
+      run() {
+        // The campaign lane reads settings.contentHtml AHEAD of the escaped renderer
+        // (marketing/index.js) — a caller-supplied one is the same bypass.
+        const fault = prepare.internalOnlyFieldFault({
+          name: 'Probe campaign',
+          subject: 'Probe',
+          contentHtml: '<img src=x onerror="alert(1)">',
+        });
+
+        assert.ok(fault instanceof Error, 'no fault returned for contentHtml');
+        assert.equal(fault.code, 400, `fault must be a permanent 400, got ${fault.code}`);
+        assert.ok(fault.message.includes('contentHtml'), `message must name the field: ${fault.message}`);
+      },
+    },
+
+    {
+      name: 'external lane rejects caller-supplied trustedContent with a coded 400',
+
+      run() {
+        // trustedContent: true flips the body renderer to html: true — raw markup and
+        // javascript: hrefs would both survive.
+        const fault = prepare.internalOnlyFieldFault({
+          subject: 'Probe',
+          trustedContent: true,
+          data: { content: { message: '<a href="javascript:alert(1)">x</a>' } },
+        });
+
+        assert.ok(fault instanceof Error, 'no fault returned for trustedContent');
+        assert.equal(fault.code, 400, `fault must be a permanent 400, got ${fault.code}`);
+        assert.ok(fault.message.includes('trustedContent'), `message must name the field: ${fault.message}`);
+      },
+    },
+
+    {
+      name: 'external lane rejects trustedContent: false too — presence is the fault',
+
+      run() {
+        assert.ok(prepare.internalOnlyFieldFault({ trustedContent: false }) instanceof Error, 'trustedContent: false passed');
+      },
+    },
+
+    // ---------- The stored campaign doc can no longer carry it ----------
+
+    {
+      name: 'a rejected campaign never reaches buildCampaignDoc, so the doc cannot carry contentHtml',
+
+      run() {
+        // buildCampaignDoc() blacklists doc-level fields rather than allowlisting, so
+        // anything the caller sends persists into doc.settings — which is why the route
+        // rejects BEFORE calling it. This asserts both halves: the persistence is real,
+        // and the guard fires on that exact payload.
+        const hostile = { name: 'Probe', subject: 'Probe', contentHtml: '<img src=x onerror=alert(1)>' };
+
+        const { campaignSettings } = buildCampaignDoc(hostile);
+
+        assert.ok('contentHtml' in campaignSettings, 'buildCampaignDoc no longer persists contentHtml — update this test');
+        assert.ok(prepare.internalOnlyFieldFault(hostile) instanceof Error, 'the payload that persists was not rejected');
+      },
+    },
+
+    // ---------- Belt: the route schemas do not admit the two top-level fields ----------
+
+    {
+      name: 'the admin/email + campaign schemas strip html, contentHtml and trustedContent',
+
+      run() {
+        // These three never reach the handler over HTTP today, because a zod object
+        // strips unknown keys and none of them is declared (#125 removed the last one,
+        // `html`, from the admin/email schema). That strip is the BELT;
+        // internalOnlyFieldFault() in the handler is the BRACES — the moment either
+        // field is declared on a schema (or a consumer route forwards raw settings),
+        // the guard is what stops it. If this test ever fails, the guard is live.
+        const emailSchema = require('../../dist/manager/schemas/admin/email/post.js')();
+        const email = emailSchema.parse({
+          to: 'a@b.co',
+          subject: 's',
+          html: '<img src=x onerror=alert(1)>',
+          contentHtml: '<img src=x>',
+          trustedContent: true,
+          data: { content: { html: '<img src=x onerror=alert(1)>' } },
+        });
+
+        assert.equal(email.html, undefined, 'admin/email schema admitted the top-level html override');
+        assert.equal(email.contentHtml, undefined, 'admin/email schema admitted contentHtml');
+        assert.equal(email.trustedContent, undefined, 'admin/email schema admitted trustedContent');
+
+        // ...but data is a passthrough, which is exactly why data.content.html needs
+        // the handler guard rather than a schema strip.
+        assert.equal(email.data.content.html, '<img src=x onerror=alert(1)>', 'data.content.html no longer passes the schema — update this test');
+
+        const campaignSchema = require('../../dist/manager/schemas/marketing/campaign/post.js')();
+        const campaign = campaignSchema.parse({ name: 'n', subject: 's', contentHtml: '<img src=x>', trustedContent: true });
+
+        assert.equal(campaign.contentHtml, undefined, 'campaign schema admitted contentHtml');
+        assert.equal(campaign.trustedContent, undefined, 'campaign schema admitted trustedContent');
+      },
+    },
+
+    // ---------- The internal lane keeps working ----------
+
+    {
+      name: 'internal caller still gets its pre-rendered html into the payload',
+
+      async run() {
+        const html = await transactionalBuild({
+          subject: 'Internal',
+          data: { content: { html: '<p id="prerendered">first-party <b>html</b></p>' } },
+        });
+
+        assert.ok(html.includes('id="prerendered"'), `pre-rendered html did not reach the payload: ${html}`);
+        assert.ok(/<b>html<\/b>/.test(html), 'pre-rendered markup was escaped for an internal caller');
+      },
+    },
+
+    {
+      name: 'internal caller still gets the top-level html override into the payload',
+
+      async run() {
+        // #125 closed the override to the API lane only — build() still honors it for
+        // a first-party caller that hands over a complete document.
+        const html = await transactionalBuild({
+          subject: 'Internal',
+          html: '<html><body id="whole-document">first-party</body></html>',
+        });
+
+        assert.equal(html, '<html><body id="whole-document">first-party</body></html>', `the override did not replace the body: ${html}`);
+      },
+    },
+  ],
+});

package/test/email/feedback-and-plain-send.test.js

@@ -0,0 +1,54 @@
+/**
+ * Test: Send feedback + plain template emails
+ * Quick visual test — sends one of each to verify rendering.
+ */
+
+const defineCases = require('../../dist/vendor/devkit/test/define-cases.js');
+module.exports = defineCases({
+  description: 'Feedback + plain template send',
+  type: 'group',
+  skip: !process.env.TEST_EXTENDED_MODE ? 'TEST_EXTENDED_MODE not set' : false,
+  tests: [
+    {
+      name: 'feedback-template',
+      auth: 'admin',
+      timeout: 30000,
+      async run({ http, assert, config }) {
+        const response = await http.post('backend-manager/admin/email', {
+          subject: '[TEST] Feedback template',
+          to: `_test-email-send@${config.domain}`,
+          template: 'feedback',
+          sender: 'hello',
+          copy: false,
+          data: { signoff: { type: 'personal' } },
+        });
+
+        assert.isSuccess(response, 'Should send feedback email');
+        assert.equal(response.data.status, 'sent', 'Status should be sent');
+      },
+    },
+    {
+      name: 'plain-template-with-markdown',
+      auth: 'admin',
+      timeout: 30000,
+      async run({ http, assert, config }) {
+        const response = await http.post('backend-manager/admin/email', {
+          subject: '[TEST] Plain template with markdown',
+          to: `_test-email-send@${config.domain}`,
+          template: 'plain',
+          sender: 'hello',
+          copy: false,
+          data: {
+            content: {
+              message: '# Quick Update\n\nHey Ian,\n\nJust wanted to let you know that your **account settings** have been updated successfully.\n\nHere is what changed:\n\n- Email notifications: **enabled**\n- Two-factor auth: **enabled**\n- API key: [regenerated](https://example.com/account)\n\nIf you didn\'t make these changes, please [contact support](https://example.com/support) immediately.\n\nThanks!',
+            },
+            signoff: { type: 'personal' },
+          },
+        });
+
+        assert.isSuccess(response, 'Should send plain email');
+        assert.equal(response.data.status, 'sent', 'Status should be sent');
+      },
+    },
+  ],
+});

package/test/email/fixtures/clean.json

@@ -0,0 +1,30 @@
+{
+  "_comment": "Predefined fixture for the `clean` template. Loaded via NEWSLETTER_FIXTURE=clean. Edit freely — no AI involved. Classic content shape: intro + sections[{title, body, cta, image_prompt}].",
+  "subject": "Identity is the new growth lever",
+  "preheader": "Three platform shifts to lock in this week.",
+  "summary": "LinkedIn, YouTube, and the broader creator stack are all tightening identity controls this week. The operators with documented attribution histories will outrun the rest. Documentation is no longer overhead — it's the moat.",
+  "tags": ["linkedin", "youtube", "platform-policy", "creator-economy", "operator-tools"],
+  "intro": "Identity matters because trust is the new growth lever. Teams that handle this well will spend less time cleaning up later.",
+  "sections": [
+    {
+      "title": "LinkedIn ships verified-profile gates for business accounts",
+      "body": "LinkedIn now requires verified identity attestations on any business profile claiming more than 500 followers. Accounts with documented attribution histories sail through verification in under twelve hours. The practical implication is to lock down your attribution log this week, not next.",
+      "image_prompt": "Abstract geometric illustration of a verification checkmark inside a layered profile card."
+    },
+    {
+      "title": "Documentation is the new operator moat",
+      "body": "Operator playbooks are now the difference between an account that recovers from a flag and one that gets permanently restricted. Teams running documented processes recover in days. The ones without burn weeks negotiating with support queues.",
+      "image_prompt": "Stack of geometric document layers casting clean shadows on a flat surface."
+    },
+    {
+      "title": "YouTube tests creator-attribution metadata on uploads",
+      "body": "A subset of channels saw a new upload checkbox this week asking whether content was assisted by automation. The checkbox is optional today. Reading the room: it will not stay optional. Creators with clear internal workflows will adapt in an afternoon.",
+      "image_prompt": "Minimalist play button morphing into a label tag, flat geometric style."
+    }
+  ],
+  "signoff": "Best,\nThe Somiibo Team",
+  "citations": [
+    { "note": "LinkedIn flagged 12,000 impersonation attempts in the verified-profile beta.", "source": "Reported by LinkedIn product team, May 2026" },
+    { "note": "Operator playbook adoption up 38% week-over-week in Q2.", "source": "Per platform analytics, May 2026" }
+  ]
+}

package/test/email/fixtures/editorial.json

@@ -0,0 +1,30 @@
+{
+  "_comment": "Predefined fixture for the `editorial` template. Loaded via NEWSLETTER_FIXTURE=editorial. Same classic content shape as clean.json — both templates render the same data.",
+  "subject": "Identity is the new growth lever",
+  "preheader": "Three platform shifts to lock in this week.",
+  "summary": "LinkedIn, YouTube, and the broader creator stack are all tightening identity controls this week. The operators with documented attribution histories will outrun the rest. Documentation is no longer overhead — it's the moat.",
+  "tags": ["linkedin", "youtube", "platform-policy", "creator-economy", "operator-tools"],
+  "intro": "Identity matters because trust is the new growth lever. Teams that handle this well will spend less time cleaning up later, and the patterns emerging this week tell you exactly where to focus.",
+  "sections": [
+    {
+      "title": "LinkedIn ships verified-profile gates for business accounts",
+      "body": "LinkedIn now requires verified identity attestations on any business profile claiming more than 500 followers. The rollout is fast and uneven — some accounts hit the gate inside two days of profile activity, others sit unchallenged for weeks. The pattern that matters is this: accounts with documented attribution histories sail through verification in under twelve hours. Accounts without get queued. The practical implication is to lock down your attribution log this week, not next.",
+      "image_prompt": "Abstract geometric illustration of a verification checkmark inside a layered profile card."
+    },
+    {
+      "title": "Documentation is the new operator moat",
+      "body": "Operator playbooks — once dismissed as overhead — are now the difference between an account that recovers from a flag and one that gets permanently restricted. The teams already running on documented processes recover in days. The ones without burn weeks negotiating with support queues. Treat your playbook as a compliance artifact, not a knowledge-management nice-to-have.",
+      "image_prompt": "Stack of geometric document layers casting clean shadows on a flat surface."
+    },
+    {
+      "title": "YouTube tests creator-attribution metadata on uploads",
+      "body": "A subset of channels saw a new upload checkbox this week asking whether content was assisted by automation. The checkbox is optional today. Reading the room: it will not stay optional. Creators with clear internal workflows already labeled will adapt in an afternoon. Everyone else will spend a quarter retrofitting.",
+      "image_prompt": "Minimalist play button morphing into a label tag, flat geometric style."
+    }
+  ],
+  "signoff": "Best,\nThe Somiibo Team",
+  "citations": [
+    { "note": "LinkedIn flagged 12,000 impersonation attempts in the verified-profile beta.", "source": "Reported by LinkedIn product team, May 2026" },
+    { "note": "Operator playbook adoption up 38% week-over-week in Q2.", "source": "Per platform analytics, May 2026" }
+  ]
+}