backend-manager 5.2.15 → 5.2.17

package/CHANGELOG.md

@@ -14,6 +14,33 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
 - `Fixed` for any bug fixes.
 - `Security` in case of vulnerabilities.
 
+# [5.2.17] - 2026-05-29
+
+### Added
+
+- **Newsletter-driven blog articles (`marketing.beehiiv.content.article`).** When enabled, the newsletter generator expands its **lead section** (`structure.sections[0]`) into a full blog article via the Ghostii engine, publishes it to the website repo through the `admin/post` route, and injects a "Read the full article" CTA (`section.cta = { label, url }`) onto that section so the newsletter links to the long-form post. The article build runs **concurrently** with SVG image generation (both are slow AI calls) and is **failure-isolated** — if it throws, no CTA is injected and the newsletter ships normally. The published URL (`{brand.url}/blog/{slug}`) is surfaced on the generator return as `assets.articleUrl` and `meta.article`. New config block: `content.article = { enabled, author }` (`enabled` default `false`). See `docs/marketing-campaigns.md`.
+- **`section.cta` rendering.** Both the MJML template (`sectionCard`, already supported) and the markdown renderer (`lib/markdown-renderer.js`, new) now render `section.cta = { label, url }` when present. `getBodySections` passes `cta` through for both classic and field-report shapes. CTAs are still never authored by the AI — they're injected by code post-publish with a real, verified URL.
+- **Generate/publish split on the linked article (`opts.publishArticle`).** When `config.article.enabled` is on, the article is always **generated** (Ghostii writes it + the public URL is computed from the title slug + the CTA is injected), but it's only **committed** to the website repo via `admin/post` when `opts.publishArticle` is true. The production cron passes `publishArticle: true`. The newsletter iteration test (`test/marketing/newsletter-generate.js`) leaves it false by default — so a full `TEST_EXTENDED_MODE=1` run exercises the Ghostii write + CTA path without committing a real post — and opts in with `NEWSLETTER_CREATE_ARTICLE=1`. The CTA URL is valid either way (derived from the same slugify `admin/post` uses). `meta.article.published` records whether the post was actually committed.
+
+### Changed
+
+- **Extracted the Ghostii article engine into `src/manager/libraries/content/ghostii.js`** (`writeArticle` + `publishArticle`) as the SSOT for the Ghostii API request shape and the `admin/post` publish payload. Both the standalone `ghostii-auto-publisher.js` daily cron and the new newsletter linked-article flow import it (DRY). No behavior change to the standalone cron.
+- **Standalone Ghostii is now disabled by default** (`ghostii[0].articles: 0` in `templates/backend-manager-config.json`). The daily `ghostii-auto-publisher.js` cron remains fully functional — set `articles >= 1` to opt back into independent article publishing. For newsletter-linked articles, use `content.article.enabled` instead.
+
+# [5.2.16] - 2026-05-28
+
+### Removed
+
+- **Dropped the legacy top-level `affiliateCode` field from `/user/signup`.** UJM and all current consumers send the referral code as `attribution.affiliate.code`; the top-level `affiliateCode` (and the normalize-to-`attribution` shim + the `processAffiliate` fallback that read it) was a dead legacy path. Removed from `src/manager/schemas/user/signup/post.js`, the `buildUserRecord` normalize block, and the `processAffiliate` lookup in `src/manager/routes/user/signup/post.js`. The route now reads referral codes exclusively from `attribution.affiliate.code`. (The legacy `bm_api` sign-up action `functions/core/actions/api/user/sign-up.js` is unchanged.)
+
+### Fixed
+
+- **Consent: never downgrade an existing granted consent on `/user/signup`** (`src/manager/routes/user/signup/post.js`). A legacy account — signed up before the `flags.signupProcessed` completion flow existed, so the flag was never set — re-fires `/user/signup` on every page load until the flag flips. Its consent payload arrives empty (the original is long gone from `localStorage`), which previously computed `'revoked'` and, on the `{ merge: true }` write, wiped the consent the user actually granted months ago. `buildConsentRecord` now reads the existing doc's consent and preserves any already-`granted` status when the incoming payload doesn't explicitly re-grant it. A genuine new grant still applies; an at-signup decline with no prior grant still records the decline. Added `consent-empty-payload-preserves-existing-grant` and `consent-explicit-decline-does-not-downgrade-existing-grant` tests (+ a dedicated `consent-preserve` test account). See `docs/consent.md`.
+
+### Changed
+
+- **`user/signup` schema: shaped the `consent` field.** `src/manager/schemas/user/signup/post.js` now declares the nested `consent.{legal,marketing}.{granted,text}` shape instead of a bare passthrough object, documenting the input contract at the schema layer (the SSOT for request shape). Each sub-object is optional — omitting it leaves existing consent untouched (see the downgrade guard above).
+
 # [5.2.15] - 2026-05-28
 
 ### Changed

package/CLAUDE.md

@@ -34,7 +34,7 @@ All `npx mgr <cmd>` aliases work: `npx bm <cmd>`, `npx bem <cmd>`, `npx backend-
 1. `npm install` — install BEM's own deps
 2. `npm run prepare` — build once: copies `src/` → `dist/` via prepare-package
 3. `npm run prepare:watch` — watch mode
-4. Test in a consumer project: from inside the consumer's `functions/` dir, run `npx mgr install local` (swaps BEM to the local repo via the `install` CLI). Reverse with `npx mgr install prod`.
+4. Test in a consumer project: from inside the consumer, run `npx mgr install dev` to swap BEM to this local repo — required whenever you edit the framework source and want the consumer to pick up the changes (the consumer otherwise keeps its installed `node_modules/backend-manager`). Reverse with `npx mgr install prod`. If `npx mgr` then errors with "could not determine executable to run", the local install skipped bin-linking — re-run `npm install` to relink, or call `node node_modules/backend-manager/bin/backend-manager <cmd>` directly.
 
 ## Architecture
 
@@ -119,9 +119,9 @@ Deep references live in `docs/`. **Whenever you make a behavioral change, update
 
 ### Built-in Routes
 
-- [docs/admin-post-route.md](docs/admin-post-route.md) — `POST/PUT /admin/post` blog creation via GitHub (image extraction + resize at ingest + `@post/` rewriting)
+- [docs/admin-post-route.md](docs/admin-post-route.md) — `POST/PUT /admin/post` blog creation via GitHub (image extraction + resize at ingest + `@post/` rewriting). Also the publish target for the Ghostii article engine (`libraries/content/ghostii.js`).
 - [docs/payment-system.md](docs/payment-system.md) — full payment pipeline: Intent → Webhook → On-Write → Transition; subscription model, statuses, `resolveSubscription()`, transition handlers, processor interface, product config, test processor
-- [docs/marketing-campaigns.md](docs/marketing-campaigns.md) — campaign CRUD routes, recurring campaigns, generator pipeline (newsletter), template-owned schemas, asset hosting, seed campaigns
+- [docs/marketing-campaigns.md](docs/marketing-campaigns.md) — campaign CRUD routes, recurring campaigns, generator pipeline (newsletter), newsletter-driven blog article (`content.article.enabled`), template-owned schemas, asset hosting, seed campaigns
 - [docs/consent.md](docs/consent.md) — marketing consent capture: canonical `consent.{legal,marketing}` user-doc shape, signup-form capture, account-page toggle, HMAC unsub link, SendGrid+Beehiiv webhook receivers, parent forwarder (`/marketing/webhook/forward`), migration script template
 - [docs/mcp.md](docs/mcp.md) — Model Context Protocol server: 19 tools, stdio + HTTP transports, OAuth, Claude Chat/Code configuration
 

package/README.md

@@ -412,6 +412,7 @@ Built-in marketing system with multi-provider support (SendGrid + Beehiiv + FCM
 - **Campaign CRUD** — `POST/GET/PUT/DELETE /marketing/campaign` with calendar-backed scheduling
 - **Recurring campaigns** — seasonal sales, newsletters with automatic sendAt advancement
 - **Newsletter generator** — AI-assembled newsletters from parent server content sources
+- **Newsletter-driven blog articles** — `content.article.enabled` expands the newsletter's lead section into a full blog post (via Ghostii → `admin/post`) and links to it with a "Read the full article" CTA
 - **Segment SSOT** — 22 segment definitions resolved to provider IDs at runtime
 - **UTM auto-tagging** — brand domain links tagged automatically in marketing + transactional emails
 - **Contact pruning** — monthly 2-stage re-engagement + deletion of inactive contacts

package/docs/admin-post-route.md

@@ -2,6 +2,8 @@
 
 The `POST /admin/post` route creates blog posts via GitHub's API. It handles image extraction, resize, upload, and body rewriting.
 
+**Consumers.** Besides direct admin/blogger HTTP calls, this route is the publish target for the **Ghostii article engine** (`src/manager/libraries/content/ghostii.js` → `publishArticle()`), which is used by two paths: the standalone daily `ghostii-auto-publisher.js` cron (off by default), and the newsletter generator's linked-article flow (`marketing.beehiiv.content.article.enabled`). Both POST `title`/`url`/`description`/`headerImageURL`/`body`/`author`/`categories`/`tags`/`postPath`/`githubUser`/`githubRepo` with a `backendManagerKey`. Note: `headerImageURL` MUST resolve to a `.jpg` (the downloader rejects non-`.jpg` headers); Ghostii's `unsplash` hero satisfies this. See [docs/marketing-campaigns.md](marketing-campaigns.md).
+
 ## Image Processing Flow
 
 1. Receives markdown body with external image URLs (e.g., `![alt](https://images.unsplash.com/...)`)

package/docs/ai-library.md

@@ -14,6 +14,23 @@ Return shape (same for all providers): `{ content, output, tokens, raw }`.
 
 API keys: `BACKEND_MANAGER_OPENAI_API_KEY`, `BACKEND_MANAGER_ANTHROPIC_API_KEY` (process.env or config).
 
+## Tools / web search (OpenAI)
+
+`options.tools` (and optional `options.toolChoice`) are passed through to the OpenAI Responses API verbatim. Opt-in — when omitted, no tools are sent and behavior is identical to a plain request. Use this to enable OpenAI's built-in **web search** so the model finds and cites real, currently-live URLs instead of hallucinating them:
+
+```js
+const r = await ai.request({
+  model: 'gpt-5.4',
+  response: 'json',
+  reasoning: { effort: 'medium' },
+  tools: [{ type: 'web_search' }],
+  prompt: { path: '.../research/system.md', settings },
+  message: { path: '.../research/user.md', settings },
+});
+```
+
+When tools are active, the response `output` array may contain tool-call items (e.g. `web_search_call`) alongside the `message`; the message-text extractor ignores non-message items, so `r.content` is unaffected. URL citations live in the returned `output` (message content) as `annotations` of type `url_citation`.
+
 ## `claude-code` provider — subscription billing
 
 The `claude-code` provider hits the same Claude Messages API as `anthropic`, but authenticates with a **Claude Code OAuth token** (`Authorization: Bearer ...` + `anthropic-beta: oauth-2025-04-20`) so usage bills the Claude Pro/Max subscription tied to the token rather than API credits.

package/docs/consent.md

@@ -67,16 +67,19 @@ There are four places where consent gets recorded or updated. All four converge
 }
 ```
 
-`buildConsentRecord(assistant, settings.consent)` translates this into the canonical user-doc shape:
+`buildConsentRecord(assistant, settings.consent, creationTime, existingConsent)` translates this into the canonical user-doc shape:
 
-- `legal.granted: true` → `legal.status = 'granted'`, `grantedAt` populated with `source: 'signup'` + **server timestamp** + server-detected IP + exact label text.
+- `legal.granted: true` → `legal.status = 'granted'`, `grantedAt` populated with `source: 'signup'` + **timestamp from Auth `creationTime`** + server-detected IP + exact label text.
 - `marketing.granted: false` → `marketing.status = 'revoked'`, `grantedAt` all-null, `revokedAt` populated with `source: 'signup'`. (Records the explicit decline.)
-- Missing `consent` block (legacy client) → both default to `'revoked'`.
 
-**Server time is authoritative.** Client-supplied timestamps are ignored — defends against clock manipulation by malicious clients.
+**Timestamps come from Firebase Auth `creationTime`,** not request time, so `consent.grantedAt` matches `metadata.created` (the OMEGA user migration treats `metadata.created` as the SSOT and reconciles `grantedAt` against it — stamping from request time made every new signup drift by a few seconds and get re-fixed on the next migration run).
+
+**Server-derived time is authoritative.** Client-supplied timestamps are ignored — defends against clock manipulation by malicious clients.
 
 **Strict boolean check.** Only `granted === true` counts as granted. `'true'`, `1`, or other truthy values are rejected.
 
+**Never downgrades an existing grant (data-loss guard).** A legacy account — one signed up before the `flags.signupProcessed` completion flow existed, so its flag was never set — re-fires `/user/signup` on every page load until the flag flips. Its consent was captured months ago and is long gone from `localStorage`, so the payload arrives empty. Without protection, `buildConsentRecord` would compute `'revoked'` and the `{ merge: true }` write would wipe the consent the user actually granted. The guard reads the existing doc's consent (`existingConsent`) and **preserves any already-`granted` status when the incoming payload does not explicitly re-grant it.** A genuine new grant still applies; an at-signup decline with no prior grant still records the decline. (The primary mitigation is OMEGA migration Fix 4f, which backfills `flags.signupProcessed: true` for established accounts so they never re-fire; this guard is the backstop for the deploy-before-migration gap.)
+
 **Marketing sync gating.** After writing the user doc, the route checks `userRecord.consent.marketing.status === 'granted'` before calling `mailer.sync(uid)`. Declining the marketing checkbox means the user is created normally, gets transactional emails, but is NEVER added to SendGrid / Beehiiv marketing lists.
 
 ### 2. Account-page toggle (Phase D)

package/docs/marketing-campaigns.md

@@ -100,6 +100,22 @@ Pipeline:
 4. **mjml-template.js** — Resolves the template by name from `templates/index.js`, calls `template.build({structure, imagePaths, theme, ...})` for the MJML, compiles to email-safe HTML via the `mjml` package. Brand-domain links get UTM-tagged via the existing `tagLinks()` utility.
 5. Mark used: `PUT {parentUrl}/newsletter/sources` per source
 
+> **Step 3 runs concurrently with the linked-article build** (see below) when `article.enabled` is on — both are slow AI calls, so they share one `Promise.all`. The article URL is stamped onto the lead section before steps 4/5 render.
+
+## Newsletter-driven blog article (`article.enabled`)
+
+When `marketing.beehiiv.content.article.enabled: true`, the newsletter generator expands its **lead section** (`structure.sections[0]`) into a full blog article and links to it from the newsletter.
+
+Flow (runs in parallel with SVG generation, between structure and render):
+1. `buildLinkedArticle()` builds a brief from the lead section's title + body, folded with the shared `tone` + `instructions`.
+2. **Ghostii** (`libraries/content/ghostii.js` → `writeArticle()`) expands it into a full article + hero image.
+3. `publishArticle()` POSTs to the `admin/post` route (commits markdown + images to the website repo). Public URL = `{brand.url}/blog/{slug}`.
+4. The URL is injected as `structure.sections[0].cta = { label: 'Read the full article', url }`. The MJML `sectionCard` and the markdown renderer both render `section.cta` automatically.
+
+**Failure is isolated** — if the article build throws, it resolves to `null`, no CTA is injected, and the newsletter ships normally. The newsletter never depends on the article succeeding.
+
+The published URL is surfaced on the return as `assets.articleUrl` and `meta.article`. Config block: `marketing.beehiiv.content.article = { enabled, author }` (`enabled` default `false`; `author` is the post author slug). Standalone article publishing (independent of the newsletter) still lives in the daily `ghostii-auto-publisher.js` cron, which now shares the same `libraries/content/ghostii.js` engine — see [docs/admin-post-route.md](admin-post-route.md). Standalone Ghostii is **disabled by default** (`ghostii[0].articles: 0`).
+
 ## Template-owned schemas
 
 Each template under `lib/templates/` owns its own content shape. Templates export:
@@ -199,7 +215,7 @@ marketing-campaigns/{newId}: {
 
 Templates add their own fields on top (e.g. classic adds `intro` + `sections`; field-report adds `tldr` + `dateline` + `dispatches`).
 
-**No CTAs in generated content.** The schema intentionally does NOT include section-level CTAs / outbound links. The AI cannot author URLs reliably — it has no browse access to your site and no real source URLs to reference, so any URL it produces is invented. Newsletters are self-contained reads; outbound links come from sponsorship blocks rendered by the template shell (driven by `marketing.beehiiv.content.sponsorships[]`), not from generated section bodies.
+**No AI-authored CTAs in generated content.** The schema intentionally does NOT include section-level CTAs / outbound links. The AI cannot author URLs reliably — it has no browse access to your site and no real source URLs to reference, so any URL it produces is invented. Newsletters are self-contained reads; outbound links come from sponsorship blocks rendered by the template shell (driven by `marketing.beehiiv.content.sponsorships[]`), not from generated section bodies. The **one exception** is the linked-article CTA: when `article.enabled` is on, `section.cta = { label, url }` is injected onto the lead section by code *after* the article is published (a real, verified URL) — never authored by the AI. Both `sectionCard` (MJML) and the markdown renderer render `section.cta` when present.
 
 **Beehiiv failure → fallback alert email.** When Beehiiv draft creation fails (e.g. `SEND_API_NOT_ENTERPRISE_PLAN` on the free plan), the generator sends an internal alert email via `sender: 'internal'` (resolves to `alerts@{brandDomain}`) to `brand.contact.email` with:
 - The failure reason
@@ -249,6 +265,10 @@ marketing: {
       instructions: '',                     // free-form AI instructions
       tone: 'professional',
       template: 'clean',                    // clean | editorial | field-report
+      article: {                            // expand the lead section into a linked blog post (Ghostii → admin/post)
+        enabled: false,
+        author: 'alex-raeburn',             // author slug for the linked article
+      },
       theme: { primaryColor, secondaryColor, accentColor, font },
       sponsorships: [ ... ],
     },
@@ -270,6 +290,8 @@ marketing: {
 | Newsletter MJML → HTML | `src/manager/libraries/email/generators/lib/mjml-template.js` |
 | Newsletter asset host (GitHub upload — PNGs + newsletter.html + newsletter.md + summary.md) | `src/manager/libraries/email/generators/lib/image-host.js` |
 | Newsletter markdown renderer (programmatic, no AI) | `src/manager/libraries/email/generators/lib/markdown-renderer.js` |
+| Ghostii article engine (writeArticle + publishArticle) | `src/manager/libraries/content/ghostii.js` |
+| Standalone Ghostii article cron (off by default) | `src/manager/events/cron/daily/ghostii-auto-publisher.js` |
 | Unified AI library | `src/manager/libraries/ai/index.js` (OpenAI + Anthropic via `Manager.AI(assistant).request({ provider, ... })`) |
 | Notification library | `src/manager/libraries/notification.js` |
 | SendGrid provider | `src/manager/libraries/email/providers/sendgrid.js` |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "backend-manager",
-  "version": "5.2.15",
+  "version": "5.2.17",
   "description": "Quick tools for developing Firebase functions",
   "main": "src/manager/index.js",
   "bin": {

package/src/cli/commands/base-command.js

@@ -130,6 +130,14 @@ class BaseCommand {
       }
     }
 
+    // Non-interactive environments (CI, agents, piped stdin) have no TTY, so inquirer
+    // can't read a keypress — prompting would error or hang. Skip the prompt entirely
+    // and auto-confirm the kill so unattended `mgr test` / `mgr emulator` runs proceed.
+    if (!process.stdin.isTTY) {
+      this.log(chalk.gray('  Non-interactive shell — auto-confirming port cleanup (Y).'));
+      return this.killBlockingProcesses(blockedPorts);
+    }
+
     // Auto-confirm (Y) after a few seconds of no input so unattended test/dev loops don't
     // hang. When the timeout fires the prompt is aborted via AbortSignal and we fall back to
     // the default (true). inquirer owns the cursor and can't live-update its own message, so
@@ -142,11 +150,20 @@ class BaseCommand {
         { signal: AbortSignal.timeout(AUTO_CONFIRM_SECONDS * 1000) },
       );
     } catch (error) {
-      // AbortPromptError (timeout reached) → take the default (true). Re-throw anything else.
-      if (error?.name !== 'AbortPromptError') {
-        throw error;
+      // Any prompt failure → fall back to the safe default (auto-confirm Y) instead of
+      // crashing. This covers:
+      //   - AbortPromptError: the 5s timeout fired (no input).
+      //   - ExitPromptError / force-close: stdin is present but closed/EOF'd (the
+      //     case under `mgr test`, agents, and other wrappers that pipe a non-readable
+      //     stdin). inquirer throws "User force closed the prompt with 0 null" here.
+      // Anything unexpected is logged but still defaults to Y so unattended runs proceed.
+      const name = error?.name || '';
+      const known = name === 'AbortPromptError' || name === 'ExitPromptError';
+      if (!known) {
+        this.log(chalk.gray(`  Prompt unavailable (${name || 'unknown'}) — auto-confirming (Y).`));
+      } else {
+        this.log(chalk.gray('  No input — auto-confirming (Y).'));
       }
-      this.log(chalk.gray('  No input — auto-confirming (Y).'));
       shouldKill = true;
     }
 
@@ -155,6 +172,15 @@ class BaseCommand {
       return false;
     }
 
+    return this.killBlockingProcesses(blockedPorts);
+  }
+
+  /**
+   * Kill every process on the given blocked ports, then wait for release.
+   * @param {object[]} blockedPorts - [{ name, port, processes: [{ pid }] }]
+   * @returns {Promise<boolean>} - true if all killed (or already dead), false on failure
+   */
+  async killBlockingProcesses(blockedPorts) {
     // Kill ALL processes on each blocked port
     for (const { name, port, processes } of blockedPorts) {
       for (const { pid } of processes) {

package/src/defaults/CLAUDE.md

@@ -23,10 +23,14 @@ npx mgr deploy            # deploy to Firebase
 npx mgr logs:read         # read Cloud Functions logs (also: logs:tail to stream)
 npx mgr firestore:get     # read a doc from Firestore (also: firestore:set / :query / :delete)
 npx mgr auth:get          # read an Auth user (also: auth:list / :delete / :set-claims)
+npx mgr install dev       # use LOCAL backend-manager source (to test framework edits)
+npx mgr install prod      # restore the published backend-manager from npm
 ```
 
 All `npx mgr <cmd>` aliases — `npx bm <cmd>`, `npx bem <cmd>`, `npx backend-manager <cmd>` work too.
 
+> Editing the BEM framework source while working here? Run `npx mgr install dev` so this project picks up your uncommitted framework changes (it otherwise uses its installed `node_modules/backend-manager`). Run `npx mgr install prod` to switch back.
+
 ## Where things live
 
 - `functions/index.js` — entry point. Must call `Manager.init(exports, { ... })` to register all built-in + custom endpoints.

package/src/manager/events/cron/daily/ghostii-auto-publisher.js

@@ -3,6 +3,8 @@ const powertools = require('node-powertools');
 const moment = require('moment');
 const JSON5 = require('json5');
 
+const { writeArticle, publishArticle } = require('../../../libraries/content/ghostii.js');
+
 const PROMPT = `
   Company: {brand.brand.name}: {brand.brand.description}
   Date: {date}
@@ -151,7 +153,11 @@ async function harvest(assistant, settings) {
     assistant.log('harvest(): Get final content', final);
 
     // Request to Ghostii
-    const article = await requestGhostii(settings, final).catch((e) => e);
+    const article = await writeArticle({
+      brand: settings.brand,
+      description: final,
+      links: settings.links,
+    }).catch((e) => e);
     if (article instanceof Error) {
       assistant.error('harvest(): Error requesting Ghostii', article);
       break;
@@ -161,7 +167,13 @@ async function harvest(assistant, settings) {
     assistant.log('harvest(): Article', article);
 
     // Upload post to blog
-    const uploadedPost = await uploadPost(assistant, settings, article).catch((e) => e);
+    const uploadedPost = await publishArticle(assistant, {
+      brand: settings.brand,
+      article,
+      id: postId++,
+      author: settings.author,
+      postPath: 'ghostii',
+    }).catch((e) => e);
     if (uploadedPost instanceof Error) {
       assistant.error('harvest(): Error uploading post to blog', uploadedPost);
       break;
@@ -197,51 +209,6 @@ function isURL(url) {
   }
 }
 
-function requestGhostii(settings, content) {
-  return fetch('https://api.ghostii.ai/write/article', {
-    method: 'post',
-    timeout: 90000,
-    tries: 1,
-    response: 'json',
-    body: {
-      backendManagerKey: process.env.BACKEND_MANAGER_KEY,
-      keywords: [''],
-      description: content,
-      insertLinks: true,
-      headerImageUrl: 'unsplash',
-      url: settings.brand.brand.url,
-      sectionQuantity: powertools.random(3, 6, { mode: 'gaussian' }),
-      feedUrl: `${settings.brand.brand.url}/feeds/posts.json`,
-      links: settings.links,
-    },
-  });
-}
-
-function uploadPost(assistant, settings, article) {
-  const apiUrl = `https://api.${(settings.brand.brand.url || '').replace(/^https?:\/\//, '')}`;
-  return fetch(`${apiUrl}/backend-manager/admin/post`, {
-    method: 'POST',
-    timeout: 90000,
-    tries: 1,
-    response: 'json',
-    body: {
-      backendManagerKey: process.env.BACKEND_MANAGER_KEY,
-      title: article.title,
-      url: article.title, // This is formatted on the bm_api endpoint
-      description: article.description,
-      headerImageURL: article.headerImageUrl,
-      body: article.body,
-      id: postId++,
-      author: settings.author,
-      categories: article.categories,
-      tags: article.keywords,
-      postPath: 'ghostii',
-      githubUser: settings.brand.github.user,
-      githubRepo: settings.brand.github.repo,
-    },
-  });
-}
-
 function extractBodyContent(text, contentType, url) {
   const parsed = tryParse(text);
 

package/src/manager/events/cron/daily/marketing-newsletter-generate.js

@@ -80,10 +80,12 @@ module.exports = async ({ Manager, assistant, libraries }) => {
     // Run the generator with imageHost forced to 'github' (production cron
     // path always uploads — that's what "production" means here) and the
     // campaignId pinned so all assets land in marketing-campaigns/{newId}/'s
-    // matching folder.
+    // matching folder. publishArticle: true so the linked blog post (when
+    // config.article.enabled is on) is actually committed to the website repo.
     const generated = await generators[generator].generate(Manager, assistant, settings, {
       campaignId: newId,
       imageHost: 'github',
+      publishArticle: true,
     });
 
     if (!generated) {

package/src/manager/libraries/ai/providers/openai.js

@@ -395,6 +395,11 @@ OpenAI.prototype.request = function (options) {
     // Reasons
     options.reasoning = options.reasoning || undefined;
 
+    // Tools (e.g. built-in web_search). Opt-in — when omitted, no tools are sent
+    // and behavior is identical to a plain request.
+    options.tools = options.tools || undefined;
+    options.toolChoice = options.toolChoice || undefined;
+
     // Format prompt
     //
     // Accepts two forms:
@@ -977,6 +982,18 @@ function makeRequest(mode, options, self, promptSegments, message, user, _log) {
       if (reasoning) {
         request.body.reasoning = reasoning;
       }
+
+      // Only include tools (e.g. web_search) if provided. When present, the
+      // response output may contain tool-call items (e.g. web_search_call)
+      // alongside the message — the message extractor below already ignores
+      // non-message items, so this is purely additive.
+      if (Array.isArray(options.tools) && options.tools.length) {
+        request.body.tools = options.tools;
+
+        if (options.toolChoice) {
+          request.body.tool_choice = options.toolChoice;
+        }
+      }
     }
 
     // Request

package/src/manager/libraries/content/ghostii.js

@@ -0,0 +1,100 @@
+/**
+ * Ghostii article engine — shared helpers for AI article generation + publishing.
+ *
+ * Ghostii (api.ghostii.ai) writes a full blog article (title, body, header image,
+ * categories, keywords) from a free-form description. We then publish it to the
+ * brand's website repo via the internal `admin/post` route (commits markdown +
+ * images to GitHub).
+ *
+ * Two consumers:
+ *   - events/cron/daily/ghostii-auto-publisher.js — standalone daily article job
+ *   - libraries/email/generators/newsletter.js    — newsletter-driven linked article
+ *
+ * Both call writeArticle() then publishArticle(). Kept here as the single source
+ * of truth for the Ghostii request shape and the admin/post payload.
+ */
+const fetch = require('wonderful-fetch');
+const powertools = require('node-powertools');
+
+/**
+ * Generate an article via the Ghostii API.
+ *
+ * @param {object} args
+ * @param {object} args.brand - Public brand config ({ brand: { url, ... }, github: { ... } })
+ * @param {string} args.description - The article brief / prompt content
+ * @param {string[]} [args.links] - Optional links to inject into the article body
+ * @returns {Promise<object>} { title, description, body, headerImageUrl, categories, keywords }
+ */
+function writeArticle({ brand, description, links }) {
+  return fetch('https://api.ghostii.ai/write/article', {
+    method: 'post',
+    timeout: 90000,
+    tries: 1,
+    response: 'json',
+    body: {
+      backendManagerKey: process.env.BACKEND_MANAGER_KEY,
+      keywords: [''],
+      description: description,
+      insertLinks: true,
+      headerImageUrl: 'unsplash',
+      url: brand.brand.url,
+      sectionQuantity: powertools.random(3, 6, { mode: 'gaussian' }),
+      feedUrl: `${brand.brand.url}/feeds/posts.json`,
+      links: links || [],
+    },
+  });
+}
+
+/**
+ * Publish a Ghostii article to the brand's website repo via the admin/post route.
+ *
+ * @param {object} assistant - BEM assistant instance
+ * @param {object} args
+ * @param {object} args.brand - Public brand config ({ brand: { url, ... }, github: { user, repo } })
+ * @param {object} args.article - The article from writeArticle()
+ * @param {number} args.id - Post ID (unix timestamp)
+ * @param {string} [args.author] - Author slug (admin/post picks a default if unset)
+ * @param {string} [args.postPath='ghostii'] - Sub-folder under _posts/{year}/
+ * @returns {Promise<object>} { post, url, slug, path } — `url` is the public blog URL
+ */
+async function publishArticle(assistant, { brand, article, id, author, postPath }) {
+  const baseUrl = (brand.brand.url || '').replace(/^https?:\/\//, '').replace(/\/$/, '');
+  const apiUrl = `https://api.${baseUrl}`;
+
+  const post = await fetch(`${apiUrl}/backend-manager/admin/post`, {
+    method: 'POST',
+    timeout: 90000,
+    tries: 1,
+    response: 'json',
+    body: {
+      backendManagerKey: process.env.BACKEND_MANAGER_KEY,
+      title: article.title,
+      url: article.title, // Slugified on the admin/post endpoint
+      description: article.description,
+      headerImageURL: article.headerImageUrl,
+      body: article.body,
+      id: id,
+      author: author,
+      categories: article.categories,
+      tags: article.keywords,
+      postPath: postPath || 'ghostii',
+      githubUser: brand.github.user,
+      githubRepo: brand.github.repo,
+    },
+  });
+
+  // admin/post returns the resolved `settings` (incl. the slugified `url` and repo `path`).
+  // The post template sets no permalink, so the public URL follows the Jekyll/UJM
+  // blog convention: {brand.url}/blog/{slug}.
+  const slug = post?.url || '';
+  const publicUrl = `${(brand.brand.url || '').replace(/\/$/, '')}/blog/${slug}`;
+
+  return {
+    post,
+    url: slug ? publicUrl : null,
+    slug,
+    path: post?.path || null,
+  };
+}
+
+module.exports = { writeArticle, publishArticle };

package/src/manager/libraries/email/generators/lib/markdown-renderer.js

@@ -165,6 +165,7 @@ function getBodySections(structure, template) {
       body: d.dispatch,
       dataPoints: d.dataPoints,
       image_prompt: d.image_prompt,
+      cta: d.cta,  // injected post-generation (e.g. linked-article "Read more")
     }));
   }
 
@@ -175,6 +176,7 @@ function getBodySections(structure, template) {
       title: s.title,
       body: s.body,
       image_prompt: s.image_prompt,
+      cta: s.cta,  // injected post-generation (e.g. linked-article "Read more")
     }));
   }
 
@@ -236,6 +238,13 @@ function renderSection(section, idx, imagePaths, template) {
     lines.push(section.body);
   }
 
+  // CTA (e.g. "Read the full article →") — injected by code post-generation,
+  // never authored by the AI. The MJML template renders section.cta via
+  // sectionCard; this is the markdown equivalent for the Beehiiv-paste view.
+  if (section.cta?.url && section.cta?.label) {
+    lines.push(`[${section.cta.label} →](${section.cta.url})`);
+  }
+
   return lines.join('\n\n');
 }