control tower / journal
Journal
engine connected
← Journal
Proposed -- needs human approval

This tower does not push to git. To approve, a human makes this exact edit and commits it:

1. Open docs/marketing/journal/001-engine-lives-in-boat-os-growth-module.md in the docs repo.
2. Change the line "- **Status:** proposed" to "- **Status:** active".
3. Commit and push. The journal's git history is the audit trail; this tower does not commit on your behalf.

001: Marketing Engine v1 core lives in a new boat-os module, modules/growth

  • Date: 2026-08-30
  • Decider: engine proposal (Claude, from the v1 build plan), pending Daud sign-off per boat-os DEVELOPMENT_RULES.md §11.1
  • Status: proposed
  • Review by: 2026-09-30

Decision

The engine's code core (Stripe conversion webhook, Meta CAPI + Google Data Manager feeds, decay scoring, weekly digest) is built as a new module modules/growth in tripshepherd-backend. It ships unregistered; at activation the recommended host app is boat-api (billing/promotions precedent, rawBody already enabled, Stripe already delivers there), with tripshepherd-api as the alternative (needs a one-line rawBody: true in its main.ts). Specs, campaign docs, and this journal live in seesight-tours-web docs/marketing/. No new repo.

Evidence

  • Everything the engine consumes lives in boat-os already: Stripe events, guest PII for hashed match keys, comms/notifications send infra, promotions analytics, BullMQ, Prisma (recon 2026-08-30, see v1 plan §1).
  • The §12 review gate on billing/booking/payments/finance is avoided structurally: growth registers its own second Stripe webhook endpoint per Stripe account instead of editing modules/billing.
  • §11.1 directs non-transactional/analytics work to an OS-layer repo or requires CTO sign-off. The mission brief names boat-os as the engine's long-term home; this entry is the written sign-off request.

Predicted effect

CAPI and Enhanced Conversions emit real (non-dry-run) events within 2 weeks of credentials landing, with zero changes to checkout latency or Core Web Vitals (no client-side code added). Measured by: events visible in Meta Events Manager / Google Ads diagnostics, and unchanged CWV in CrUX.

Measured effect

(pending)