backend-manager 5.2.15 → 5.2.17

package/src/manager/libraries/email/generators/newsletter.js

@@ -26,6 +26,8 @@ const { generateSectionImage } = require('./lib/svg-illustrator.js');
 const { renderNewsletter } = require('./lib/mjml-template.js');
 const { renderMarkdown } = require('./lib/markdown-renderer.js');
 const { uploadAssets, RAW_BASE } = require('./lib/image-host.js');
+const { buildPublicConfig } = require('../../../routes/brand/get.js');
+const { writeArticle, publishArticle } = require('../../../libraries/content/ghostii.js');
 
 /**
  * Generate newsletter content from parent server sources.
@@ -45,6 +47,11 @@ const { uploadAssets, RAW_BASE } = require('./lib/image-host.js');
  * @param {object[]} [opts.sources] - Pre-fetched sources (bypasses parent server claim)
  * @param {boolean} [opts.skipClaim] - Don't call PUT to mark sources as used
  * @param {boolean} [opts.skipImages] - Skip SVG/PNG generation (use placeholders)
+ * @param {boolean} [opts.publishArticle] - When the linked-article build runs (config.article.enabled),
+ *                                          actually COMMIT the post to the website repo via admin/post.
+ *                                          When false (default), the article is still generated and its
+ *                                          URL computed + injected as the CTA, but nothing is committed.
+ *                                          Production cron passes true; the iteration test leaves it false.
  * @returns {object|null} Updated settings with content filled in, or null if unavailable
  */
 async function generate(Manager, assistant, settings, opts = {}) {
@@ -147,11 +154,17 @@ async function generate(Manager, assistant, settings, opts = {}) {
     || (sources.length === 1 ? sources[0].id : null)
     || generatePushId();
 
-  // 2. SVG illustrations (parallel) + upload PNGs first so we have URLs
-  //    available to embed in the HTML render below.
+  // 2. SVG illustrations + (optional) linked blog article — run CONCURRENTLY.
+  //    Both are slow AI calls. The image build produces the section image URLs;
+  //    the article build expands the lead section into a full blog post and
+  //    returns its public URL, which we inject as a "Read more" CTA before render.
   let imagePaths = [];
 
-  if (!opts.skipImages) {
+  const buildImages = async () => {
+    if (opts.skipImages) {
+      return;
+    }
+
     const images = await Promise.all(
       structure.sections.map((s) => generateSectionImage({
         imagePrompt: s.image_prompt,
@@ -191,6 +204,54 @@ async function generate(Manager, assistant, settings, opts = {}) {
 
     // Stash images on the return for callers that want to access raw buffers
     opts._lastImages = images;
+  };
+
+  // The linked-article build is gated by config.article.enabled and needs a lead
+  // section to expand. Wrapped so a failure here NEVER blocks the newsletter —
+  // it resolves to null and the CTA simply isn't injected.
+  //
+  // Two phases, independently controllable:
+  //   - GENERATE: always runs when article.enabled is on. Calls Ghostii to write
+  //     the article + hero image and computes the public URL it WOULD live at.
+  //   - PUBLISH:  commits the post to the website repo via admin/post. Only when
+  //     opts.publishArticle is true. The production cron passes true; the
+  //     iteration test leaves it false (so it exercises generation without
+  //     committing a real post) unless NEWSLETTER_CREATE_ARTICLE=1 is set.
+  //
+  // The CTA URL is derived from the article title (same slugify admin/post uses),
+  // so the newsletter links correctly even in generate-only mode.
+  const wantArticle = !!config.article?.enabled
+    && Array.isArray(structure.sections)
+    && structure.sections.length > 0;
+
+  const buildArticle = async () => {
+    if (!wantArticle) {
+      return null;
+    }
+
+    return buildLinkedArticle({
+      Manager,
+      assistant,
+      brand,
+      config,
+      structure,
+      publish: !!opts.publishArticle,
+    }).catch((e) => {
+      assistant.error(`Newsletter generator: linked article failed — ${e.message}`);
+      return null;
+    });
+  };
+
+  const [, articleResult] = await Promise.all([buildImages(), buildArticle()]);
+
+  // Inject the "Read the full article" CTA onto the lead section BEFORE render.
+  // sectionCard (MJML) renders section.cta = { label, url } automatically; the
+  // markdown renderer emits it too. The URL is the post's public blog URL —
+  // present whether the article was actually published or only generated
+  // (derived from the title slug), so the newsletter links correctly either way.
+  if (articleResult?.url) {
+    structure.sections[0].cta = { label: 'Read the full article', url: articleResult.url };
+    assistant.log(`Newsletter generator: linked article ${articleResult.published ? 'published' : 'generated (not published)'} — ${articleResult.url}`);
   }
 
   // 3. MJML → HTML
@@ -342,6 +403,11 @@ async function generate(Manager, assistant, settings, opts = {}) {
       })),
     },
     totals: aggregateTotals(filterMeta, structure._meta, opts._lastImages),
+    // Linked blog article (when config.article.enabled is on). null if disabled or failed.
+    // `published` is false when the article was generated but not committed (e.g. test mode).
+    article: articleResult
+      ? { url: articleResult.url, slug: articleResult.slug, path: articleResult.path, published: !!articleResult.published }
+      : null,
   };
 
   // Public asset URLs — stamped onto the generated campaign doc by the cron
@@ -358,6 +424,7 @@ async function generate(Manager, assistant, settings, opts = {}) {
     summaryUrl,
     imageUrls: imagePaths,
     beehiivPostId,
+    articleUrl: articleResult?.url || null,  // linked blog post (config.article.enabled), null otherwise
     tags: Array.isArray(structure.tags) ? structure.tags : [],
   } : null;
 
@@ -375,9 +442,87 @@ async function generate(Manager, assistant, settings, opts = {}) {
     images: opts._lastImages || [],  // image buffers for the iteration test to persist locally
     assets,               // GitHub asset URLs (folder, html, md, summary, images) — null in local mode
     meta,                 // per-step provider/model/cost/timing telemetry
+    article: articleResult || null,  // full linked-article result { url, slug, path, published, article: {title, body, headerImageUrl, ...} } — null when disabled/failed
   };
 }
 
+/**
+ * Expand the newsletter's lead section into a full blog article via Ghostii and
+ * (optionally) publish it to the brand's website repo. Returns the post's public
+ * URL so the newsletter can link to it via a "Read the full article" CTA.
+ *
+ * The lead section (structure.sections[0]) is the same topic the newsletter
+ * leads with, so the resulting article is the long-form version.
+ *
+ * Two phases:
+ *   - GENERATE (always): Ghostii writes the article + hero image. We then compute
+ *     the public URL the post WOULD live at, using the same title→slug rule
+ *     admin/post applies. This URL is valid for the CTA whether or not we publish.
+ *   - PUBLISH (only when `publish`): commit the post to the website repo via
+ *     admin/post (GitHub). When `publish` is false, nothing is committed.
+ *
+ * Gated upstream by config.article.enabled. Any failure is caught by the caller
+ * and the CTA is simply omitted — the newsletter never depends on this.
+ *
+ * @param {object} args
+ * @param {object} args.Manager
+ * @param {object} args.assistant
+ * @param {object} args.brand - { id, name, url, ... }
+ * @param {object} args.config - marketing.beehiiv.content (tone, instructions, article.author)
+ * @param {object} args.structure - newsletter structure (sections[0] is the lead)
+ * @param {boolean} [args.publish] - Commit the post to GitHub via admin/post. Default false.
+ * @returns {Promise<{url, slug, path, published}|null>}
+ */
+async function buildLinkedArticle({ Manager, assistant, brand, config, structure, publish }) {
+  const lead = structure.sections[0] || {};
+  const publicConfig = buildPublicConfig(Manager.config);
+
+  // Build the article brief from the lead section, folded with the shared
+  // editorial steer (tone + instructions) so the blog post matches the
+  // newsletter's voice. Ghostii expands this into a full article + hero image.
+  const briefLines = [
+    `Company: ${brand?.name || ''}: ${brand?.description || ''}`,
+    config?.tone ? `Tone: ${config.tone}` : '',
+    config?.instructions ? `Instructions: ${config.instructions}` : '',
+    '',
+    `Write a full blog article expanding on this topic:`,
+    `Title: ${lead.title || ''}`,
+    `Summary: ${lead.body || ''}`,
+  ].filter(Boolean).join('\n');
+
+  assistant.log(`Newsletter generator: building linked article for "${lead.title}"`);
+
+  // Phase 1 — GENERATE (always)
+  const article = await writeArticle({
+    brand: publicConfig,
+    description: briefLines,
+  });
+
+  // Compute the public URL the post WOULD live at. admin/post slugifies the
+  // title (after stripping a `blog/` prefix that titles never have), so we
+  // mirror that here to derive the same slug without needing to publish.
+  const slug = Manager.Utilities().slugify(article.title || '');
+  const url = slug
+    ? `${(publicConfig.brand?.url || '').replace(/\/$/, '')}/blog/${slug}`
+    : null;
+
+  // Phase 2 — PUBLISH (gated). Commit to the website repo only when asked.
+  if (!publish) {
+    assistant.log(`Newsletter generator: article generated but NOT published (publish=false) — would live at ${url}`);
+    return { url, slug, path: null, published: false, article };
+  }
+
+  const result = await publishArticle(assistant, {
+    brand: publicConfig,
+    article,
+    id: Math.round(Date.now() / 1000),
+    author: config?.article?.author,
+    postPath: 'ghostii',
+  });
+
+  return { url: result.url || url, slug: result.slug || slug, path: result.path, published: true, article };
+}
+
 /**
  * Send an internal alert email when Beehiiv draft creation fails so the
  * brand team knows there's a ready newsletter waiting for manual upload.

package/src/manager/routes/user/signup/post.js

@@ -1,4 +1,5 @@
 const moment = require('moment');
+const _ = require('lodash');
 const { inferContact } = require('../../../libraries/infer-contact.js');
 const { validate: validateEmail, isDisposable } = require('../../../libraries/email/validation.js');
 
@@ -61,7 +62,14 @@ module.exports = async ({ assistant, user, settings, libraries }) => {
   // 4. Gather all data, then write once
   const email = user.auth.email;
   const inferred = await inferUserContact(assistant, email);
-  const userRecord = buildUserRecord(assistant, settings, inferred, authUser.metadata.creationTime);
+  const userRecord = buildUserRecord(assistant, {
+    settings,
+    inferred,
+    uid,
+    email,
+    creationTime: authUser.metadata.creationTime,
+    existingDoc: userDoc,
+  });
 
   assistant.log(`signup(): Writing user record for ${uid}`, userRecord);
 
@@ -111,21 +119,43 @@ async function pollForUserDoc(assistant, uid) {
 }
 
 /**
- * Build the full user record: client details, attribution, and inferred contact
+ * Build the complete user record to write at signup completion.
+ *
+ * Returns the WHOLE merged document (written without {merge}), layered deepest-first:
+ *   1. Manager.User() full schema shape — guarantees every leaf exists (so a doc created by a
+ *      partial path, e.g. onCreate never firing, still ends up schema-complete).
+ *   2. the existing doc — real values win over the schema defaults, so we never clobber the
+ *      user's api keys, subscription, roles, affiliate.code, or any custom/non-standard fields.
+ *   3. the signup data — attribution / activity / consent / flags / personal we own at signup
+ *      land on top.
+ *
+ * Why a full deep-merge instead of `.set(partial, {merge:true})`: Firestore's merge REPLACES a
+ * map field rather than deep-merging it, so writing a partial `attribution` flattened onCreate's
+ * full attribution object and the OMEGA migration had to re-add every leaf on every signup.
+ * Deep-merging in JS and writing the whole doc avoids that entirely.
  */
-function buildUserRecord(assistant, settings, inferred, creationTime) {
+function buildUserRecord(assistant, { settings, inferred, uid, email, creationTime, existingDoc }) {
   const Manager = assistant.Manager;
-  const attribution = settings.attribution;
 
-  // Legacy support: if affiliateCode exists, normalize to new format
-  if (settings.affiliateCode && !attribution.affiliate?.code) {
-    attribution.affiliate = { code: settings.affiliateCode };
+  // Inferred name/company (from AI/regex on the email) — only set when present.
+  const personal = {};
+  if (inferred?.firstName || inferred?.lastName) {
+    personal.name = {
+      ...(inferred.firstName ? { first: inferred.firstName } : {}),
+      ...(inferred.lastName ? { last: inferred.lastName } : {}),
+    };
+  }
+  if (inferred?.company) {
+    personal.company = { name: inferred.company };
   }
 
-  const record = {
-    flags: {
-      signupProcessed: true,
-    },
+  // Layer 1: full schema shape (every leaf present with defaults).
+  const schemaShape = Manager.User({ auth: { uid, email } }).properties;
+
+  // Layer 3: the data signup owns.
+  const signupData = {
+    auth: { uid, email },
+    flags: { signupProcessed: true },
     activity: {
       ...settings.context,
       geolocation: {
@@ -137,37 +167,24 @@ function buildUserRecord(assistant, settings, inferred, creationTime) {
         ...(settings.context?.client || {}),
       },
     },
-    attribution: attribution || {},
-    consent: buildConsentRecord(assistant, settings.consent, creationTime),
+    attribution: settings.attribution || {},
+    consent: buildConsentRecord(assistant, settings.consent, creationTime, existingDoc?.consent),
     metadata: Manager.Metadata().set({ tag: 'user/signup' }),
+    ...(Object.keys(personal).length ? { personal } : {}),
   };
 
-  // Stamp metadata.created from Firebase Auth's creationTime so it matches Auth's canonical
-  // value. Normally onCreate sets this, but if onCreate didn't fire this merge write is the
-  // doc's first creation — without this the doc lands with no created date and the OMEGA
-  // migration has to backfill it. Idempotent: when onCreate already wrote it, this matches.
+  // metadata.created from Auth's creationTime (canonical), matching onCreate + the migration SSOT.
   if (creationTime) {
     const createdDate = new Date(creationTime);
-    record.metadata.created = {
+    signupData.metadata.created = {
       timestamp: createdDate.toISOString(),
       timestampUNIX: Math.round(createdDate.getTime() / 1000),
     };
   }
 
-  // Add inferred name/company if available
-  if (inferred) {
-    record.personal = {
-      ...(inferred.firstName || inferred.lastName ? {
-        name: {
-          ...(inferred.firstName ? { first: inferred.firstName } : {}),
-          ...(inferred.lastName ? { last: inferred.lastName } : {}),
-        },
-      } : {}),
-      ...(inferred.company ? { company: { name: inferred.company } } : {}),
-    };
-  }
-
-  return record;
+  // Deep-merge: schema (base) ← existing doc (real values win) ← signup data (owned fields win).
+  // _.merge mutates its first arg, so start from a fresh object.
+  return _.merge({}, schemaShape, existingDoc || {}, signupData);
 }
 
 /**
@@ -184,7 +201,7 @@ function buildUserRecord(assistant, settings, inferred, creationTime) {
  * record what the client sent, but the route will not have reached this point in practice
  * (the signup-form HTML5-requires the legal checkbox).
  */
-function buildConsentRecord(assistant, clientConsent, creationTime) {
+function buildConsentRecord(assistant, clientConsent, creationTime, existingConsent) {
   const consent = clientConsent || {};
   const ip = assistant.request.geolocation?.ip || null;
 
@@ -202,7 +219,7 @@ function buildConsentRecord(assistant, clientConsent, creationTime) {
   const legalGranted = consent.legal?.granted === true;
   const legalText = typeof consent.legal?.text === 'string' ? consent.legal.text : null;
 
-  const legal = legalGranted
+  let legal = legalGranted
     ? {
       status: 'granted',
       grantedAt: { timestamp, timestampUNIX, source: 'signup', ip, text: legalText },
@@ -216,7 +233,7 @@ function buildConsentRecord(assistant, clientConsent, creationTime) {
   const marketingGranted = consent.marketing?.granted === true;
   const marketingText = typeof consent.marketing?.text === 'string' ? consent.marketing.text : null;
 
-  const marketing = marketingGranted
+  let marketing = marketingGranted
     ? {
       status: 'granted',
       grantedAt: { timestamp, timestampUNIX, source: 'signup', ip, text: marketingText },
@@ -229,6 +246,19 @@ function buildConsentRecord(assistant, clientConsent, creationTime) {
       revokedAt: { timestamp, timestampUNIX, source: 'signup', ip, text: null },
     };
 
+  // Never DOWNGRADE an existing granted consent. A legacy account (signed up before this
+  // flow, flags.signupProcessed never set) re-fires /user/signup on page load with empty
+  // consent — which would compute status 'revoked' above and, on a {merge:true} write, wipe
+  // out the consent they actually granted months ago. If the existing doc already has a
+  // consent granted and the incoming payload doesn't explicitly re-grant it, preserve the
+  // existing record. A genuine new grant or an at-signup decline (no prior grant) still applies.
+  if (existingConsent?.legal?.status === 'granted' && legal.status !== 'granted') {
+    legal = existingConsent.legal;
+  }
+  if (existingConsent?.marketing?.status === 'granted' && marketing.status !== 'granted') {
+    marketing = existingConsent.marketing;
+  }
+
   assistant.log(`buildConsentRecord: legal=${legal.status}, marketing=${marketing.status} (raw input legal.granted=${consent.legal?.granted}, marketing.granted=${consent.marketing?.granted})`);
 
   return { legal, marketing };
@@ -262,9 +292,7 @@ async function inferUserContact(assistant, email) {
  */
 async function processAffiliate(assistant, uid, email, settings) {
   const { admin } = assistant.Manager.libraries;
-  const affiliateCode = settings.attribution?.affiliate?.code
-    || settings.affiliateCode
-    || null;
+  const affiliateCode = settings.attribution?.affiliate?.code || null;
 
   if (!affiliateCode) {
     return;
@@ -358,6 +386,7 @@ function sendWelcomeEmails(assistant, uid, firstName) {
   }
 
   sendWelcomeEmail(assistant, uid, firstName).catch(e => assistant.error('signup(): sendWelcomeEmail failed:', e));
+  sendDiscountNudgeEmail(assistant, uid, firstName).catch(e => assistant.error('signup(): sendDiscountNudgeEmail failed:', e));
   sendCheckupEmail(assistant, uid, firstName).catch(e => assistant.error('signup(): sendCheckupEmail failed:', e));
   sendFeedbackEmail(assistant, uid).catch(e => assistant.error('signup(): sendFeedbackEmail failed:', e));
 }
@@ -405,6 +434,68 @@ Thank you for choosing **${Manager.config.brand.name}**. Here's to new beginning
     });
 }
 
+/**
+ * Send discount-nudge email (24 hours after signup)
+ *
+ * A warm, personal check-in that offers a discount code in exchange for a reply.
+ * Scheduled fire-and-forget via sendAt (same pattern as checkup/feedback) — there is
+ * intentionally no premium check at send time, so a user who upgrades within 24h may
+ * still receive it. The copy is deliberately worded as a friendly thank-you (not "you
+ * haven't upgraded") so it reads fine regardless of the recipient's current plan.
+ *
+ * The reply itself is the goal: replies are a strong positive sender-reputation signal,
+ * and a real human check-in lands in the Primary tab rather than Promotions. Inbound
+ * reply handling (auto-issuing the code) is out of scope here — replies are handled
+ * separately.
+ *
+ * Subject is personalized with the recipient's first name when available, and uses
+ * intrigue framing ("something for you 🎁") rather than spam-trigger words ("free",
+ * "claim", "bonus") to protect deliverability.
+ */
+function sendDiscountNudgeEmail(assistant, uid, firstName) {
+  const Manager = assistant.Manager;
+  const mailer = Manager.Email(assistant);
+  const greeting = firstName ? `Hey ${firstName}` : 'Hey there';
+  const subject = firstName
+    ? `${firstName}, I've got something for you 🎁`
+    : `I've got something for you 🎁`;
+
+  return mailer.send({
+    to: uid,
+    sender: 'hello',
+    categories: ['engagement/discount-nudge'],
+    subject: subject,
+    template: 'default',
+    copy: false,
+    sendAt: moment().add(24, 'hours').unix(),
+    data: {
+      email: {
+        preview: `Just checking in from ${Manager.config.brand.name} — and I've got a little thank-you for you.`,
+      },
+      body: {
+        title: `How's it going?`,
+        message: `${greeting},
+
+It's Ian, the founder of **${Manager.config.brand.name}**.
+
+As a thank-you for giving us a try, I'd love to send you a code for a **premium upgrade**. **Just reply to this email** and I'll get one over to you.
+
+I read every reply, so if you have any questions, feedback, or there's anything I can help with, this is the place. Looking forward to hearing from you!`,
+      },
+      signoff: {
+        type: 'personal',
+        name: 'Ian Wiedenman, CEO',
+        url: `https://ianwiedenman.com?utm_source=discount-nudge-email&utm_medium=email&utm_campaign=${Manager.config.brand.id}`,
+        urlText: '@ianwieds',
+      },
+    },
+  })
+    .then((result) => {
+      assistant.log('sendDiscountNudgeEmail(): Success', result.status);
+      return result;
+    });
+}
+
 /**
  * Send checkup email (7 days after signup)
  */

package/src/manager/schemas/user/signup/post.js

@@ -4,11 +4,6 @@ module.exports = ({ user }) => ({
     default: user?.auth?.uid,
     required: false,
   },
-  affiliateCode: {
-    types: ['string'],
-    default: undefined,
-    required: false,
-  },
   attribution: {
     types: ['object'],
     default: {},
@@ -19,9 +14,18 @@ module.exports = ({ user }) => ({
     default: {},
     required: false,
   },
+  // Consent decision captured at signup. Each sub-object is OPTIONAL — if the client omits
+  // `legal`/`marketing` (e.g. a legacy account re-firing /user/signup on page load with no
+  // fresh consent), the route leaves that consent untouched rather than downgrading it.
+  // When present, `granted` is the decision and `text` is the exact copy shown to the user.
   consent: {
-    types: ['object'],
-    default: {},
-    required: false,
+    legal: {
+      granted: { types: ['boolean'], required: false },
+      text: { types: ['string'], required: false },
+    },
+    marketing: {
+      granted: { types: ['boolean'], required: false },
+      text: { types: ['string'], required: false },
+    },
   },
 });

package/src/test/test-accounts.js

@@ -193,6 +193,31 @@ const STATIC_ACCOUNTS = {
       subscription: { product: { id: 'basic' }, status: 'active' },
     },
   },
+  // Used to verify the never-downgrade guard: the test seeds this account's doc with already-
+  // granted consent, then re-fires /user/signup with an empty consent payload and asserts the
+  // grant is preserved (not flipped to revoked). Dedicated account so the seeded state is isolated.
+  'consent-preserve': {
+    id: 'consent-preserve',
+    uid: '_test-consent-preserve',
+    email: '_test.consent-preserve@{domain}',
+    properties: {
+      roles: {},
+      subscription: { product: { id: 'basic' }, status: 'active' },
+    },
+  },
+  // Used to verify buildUserRecord's layered deep-merge: the test seeds this account's doc with
+  // real values (api keys, paid subscription, admin role, a custom non-schema field) + a partial
+  // attribution, fires /user/signup, and asserts the merge PRESERVES those real/custom values
+  // while still filling every schema leaf and applying the signup data on top.
+  'signup-merge': {
+    id: 'signup-merge',
+    uid: '_test-signup-merge',
+    email: '_test.signup-merge@{domain}',
+    properties: {
+      roles: {},
+      subscription: { product: { id: 'basic' }, status: 'active' },
+    },
+  },
 };
 
 /**

package/templates/backend-manager-config.json

@@ -153,6 +153,10 @@
         instructions: '',  // free-form text passed to the AI ("focus on X", "avoid Y", brand voice notes)
         tone: 'professional',  // 'professional', 'casual', 'actionable', 'witty', etc. — passed to AI prompt
         template: 'clean',   // 'clean' | 'editorial' | 'field-report' — layout template (each owns its own content shape and aesthetic)
+        article: {
+          enabled: false,  // when true, the newsletter's lead section is expanded into a full blog post via Ghostii, published to the website repo, and linked from the newsletter with a "Read the full article" CTA
+          author: null,  // author slug for the linked article (Ghostii/admin-post picks a default if unset)
+        },
         theme: {
           primaryColor: '#5B5BFF',   // accent color: buttons, links, brand text
           secondaryColor: '#1E1E2A', // body text color
@@ -192,9 +196,12 @@
     appId: '1:123:web:456',
     measurementId: 'G-0123456789',
   },
+  // Standalone Ghostii article publisher (daily cron). OPT-IN: disabled by
+  // default (articles: 0). Set articles >= 1 to auto-publish independent blog
+  // posts. For newsletter-linked articles, use marketing.beehiiv.content.article.enabled instead.
   ghostii: [
     {
-      articles: 1,
+      articles: 0,
       sources: [
         '$app',
         // Add more sources here
@@ -204,7 +211,7 @@
       ],
       prompt: '',
       chance: 1.0,
-      author: 'alex-raeburn',
+      author: null,
       // app: 'other-app-id',              // Optional: target a different app
       // appUrl: 'https://api.otherapp.com', // Required if app is set (fetches /backend-manager/app)
     }