Divine Revelations — Reusable Systems Digest

Scout digest for the prayer-delivery funnel (buyer submits a prayer, pays $34.90, receives an AI-generated photo of the prayer card at St. Peter's Basilica; OTO chain; monthly membership; separate brand, separate infra). Goal: identify what to REUSE from /home/sha/vibing/devine_rev instead of rebuilding. Read-only recon; absolute paths throughout. Two landing-pages/ dirs exist in that repo: top-level (/home/sha/vibing/devine_rev/landing-pages/, live funnel apps) and 04-FUNNEL-EXECUTION/landing-pages/ (worker + reply-engine + docs) — disambiguated below.

1. Reply engine (auto-replies, gates, escalation)

v1 (currently live): n8n, not code in this repo. Three cloned workflows — Venus JNXnfFZf7pCiGP7V (137 nodes), SS 0DjMpm3Ypj7k5yyB, CR Xdkx7zD3HoXr0m8S — sharing 130/137 nodes. Flow: GHL webhook → Filter (drop on ai-off/wrong brand tag) → GHL thread fetch → Turso context reads → AI Classifier (deepseek/deepseek-chat-v3.1 via OpenRouter) → one of 13 intent agent nodes → Humanizer → INSERT scheduled_messages → separate n8n sender polls every 5 min → GHL send. Gates (ai-off, dnd, monitor_active) documented in /home/sha/.claude/commands/check-escalations.md:78-127. Full map: /home/sha/vibing/devine_rev/00-PROJECT-HQ/N8N-REPLY-AGENT-MAP.md. Portability: NOT portable as-is — policy is prompt text baked into a 137-node graph, brand-specific by construction, three-way duplicated for every rule change.

Reply engine v2 (built, not yet live): /home/sha/vibing/devine_rev/04-FUNNEL-EXECUTION/landing-pages/reply-engine/ — a Cloudflare Worker with a Durable Object (ContactThread) per contact, two Queues (replies-in/replies-out), and policy-as-data in Turso (policy_docs, directives, policy_versions, reply_runs, shadow_replies). Deterministic gates in src/gates/pre.ts (aiOff, cooldown, crisisFlagTag, dnd, emailDnd, hardshipLexicon, leadGate, monitorActive, openEscalation, retentionExhausted, safetyLexicon) and src/gates/post.ts (billingAssertion, emDash, forbiddenPhrases, htmlStructure, ownership, priceAndLink, refundVolunteer). wrangler.toml: CLASSIFY_MODEL/DRAFT_MODEL = anthropic/claude-sonnet-5, fallback deepseek/deepseek-chat-v3.1, MAX_REPLIES_7D=3, COOLDOWN_HOURS=4, ENGINE_MODE="shadow" (not cut over to live sends yet). Design doc (best single reference for reuse): /home/sha/vibing/devine_rev/00-PROJECT-HQ/REPLY-ENGINE-V2-SCOPE-20260912.md. Depends on: Turso, GHL (contact/conversation API), OpenRouter via CF AI Gateway, Cloudflare Queues + Durable Objects (needs Workers Paid plan). Portability: port with config. The gate/queue/DO/policy architecture is brand-agnostic; only the policy_docs/directives row contents and the Turso DB name (cosmicwhispers) are Divine-Rev-specific. This is the strongest reuse candidate in the whole repo if the prayer engine wants automated customer-message handling from day one.

2. Escalation flow to Telegram + daily digest + check-escalations command

/home/sha/.claude/commands/check-escalations.md (1255 lines total; read through line 760 of the file — the remainder covers Phase 4 execution mechanics for refunds/sub-cancels/tag ops, not new architecture). Pulls from three independent sources every run: Turso agent_audit_log (human_flag=1), the MediaZip Gmail support inbox (via gog gmail), and dm_threads/dm_messages (FB/IG DMs) plus ad_comments. Implements a Tier 0–4 system (charge confusion → soft doubt → hard refund demand → threatening/legal → retention accepted), a "365-day guarantee = burden of proof" script, a mystical word-replacement table (subscription→moon cycle renewal, refund→reversed the energetic exchange, etc.), and a hardship→free-product retention play (grants a free reading instead of a refund when a customer states financial hardship). Three separate reply "identities" are kept apart: Divine Rev brand voice (GHL scheduled_messages), MediaZip Support voice (plain billing English via Gmail, this is the merchant-of-record/publisher persona), and FB/IG DM (answered by outbound GHL email, never via the DM channel itself).

Depends on: Turso cosmicwhispers, GHL API skill (~/.claude/skills/ghl-api/scripts/), Stripe MCP tools (stripe_api_read/stripe_api_search/create_refund), gog gmail/ gmail-send CLI wrapper, n8n workflow JNXnfFZf7pCiGP7V. Portability: port with config. The command-file structure (phased investigation → present findings → collect approvals → execute in one pass) is directly reusable; the brand voice, tier language, and guarantee script are Divine-Rev-specific and would need a prayer-engine rewrite (no mystical language; the prayer engine's own guarantee framing per its SPEC). The MediaZip merchant-of-record split pattern is worth studying if the prayer brand also uses a separate statement-descriptor entity.

3. Upsell Checkout v2 (portal token, one-tap off-session charge, decline recovery, failed-yes follow-up)

Spec: /home/sha/vibing/devine_rev/00-PROJECT-HQ/SPEC-UPSELL-CHECKOUT-V2.md. Reference implementation (Venus, LIVE) at /home/sha/vibing/devine_rev/landing-pages/venus-funnel/ — verified present on disk:

• api/upsell-context.ts — resolves portal-token → identity/card server-side only (customer ids never sent to the client).
• api/create-oto-payment.ts — tokenized branch does the one-tap off-session charge.
• src/pages/OfferPage.tsx — the sales page; the buy button is a confirmation ("uses card ending •1234"), not a checkout form.
• src/components/offer/DeclineRecovery.tsx — the failure ladder: authentication_required → proper 3DS confirm; insufficient_funds → downsell offer, else "try again later" + follow-up email; hard declines → friendly message + inline new-card entry on the SAME page. Never auto-navigates away from a failure (this was an explicit fix — the OTO pages used to auto-redirect 3s after failure and lose recoverable sales).

Pattern: every upsell link is /offer?product=<id>&s=<portal_sessions.token>. Every attempt (success or fail) logs to Turso upsell_charge_attempts; a failed "yes" gets exactly one follow-up email at T+2-4h with the same tokenized link.

Stripe-specific parts: off-session PaymentIntent confirm, invoice_settings .default_payment_method resolution, setup_future_usage:'off_session', the Stripe decline-code → friendly-message map. Portability: port with config, high value. The prayer engine's own SPEC already proposes Stripe, so the Stripe API calls themselves transfer close to verbatim; only the product catalog, copy, and portal-token table names need to change. The page pattern (confirmation-not-checkout, persistent failure ladder, one follow-up email, ownership pre-check, per-token rate limits) is exactly the shape a $34.90 FE + OTO chain needs and is worth copying wholesale rather than redesigning.

4. Client-portal-worker crons (delivery, pre-delivery offer, outbound, dunning, fulfilment scheduling)

/home/sha/vibing/devine_rev/04-FUNNEL-EXECUTION/landing-pages/client-portal-worker/ — Cloudflare Worker devine-portal-jobs. Full cron list from wrangler.toml:7-16:

Other relevant cron files present: src/cron/pre-delivery-offer.ts (T+90min one-shot upsell offer), src/cron/failed-yes-followup.ts (self-gated to run once/hour, confirmed FAILED_YES_FOLLOWUP_ENABLED="true" in wrangler.toml:50), src/cron/escalation-ops.ts (SLA alarm, unanswered sweep, auto-resolve), src/cron/deliverable-sweep.ts, src/cron/intake.ts, src/cron/curse.ts, src/cron/sketch.ts (per-offer variants of the same reveal/generation pattern).

Full architecture docs in that same dir: ARCHITECTURE.md (router structure, data-flow diagrams, service module interfaces, DB schema, error-handling matrix, env interface) and FLOW.md (mermaid sequence diagrams for purchase flow, daily tips, push broadcast, recovery flow, webhook contract with exact request/response JSON shapes). These two files are close to a build-ready spec for a Cloudflare-Worker-based prayer fulfilment worker.

Core generation pattern (the directly reusable piece): GHL/Stripe webhook → upsert portal_sessions (nanoid token) → INSERT portal_deliverables status='pending' → status ='generating' → build prompt → call AI with retry (2x, 1s/4s backoff) → status='ready' + html_content (or status='failed' + rate-limited alert email to admin, max 10/hr). Every webhook is idempotent via UNIQUE(session_id, product_id) upsert. Env vars: TURSO_DATABASE_URL/TURSO_AUTH_TOKEN, OPENROUTER_API_KEY, RESEND_API_KEY, GHL_API_KEY, GHL_WEBHOOK_SECRET, VAPID_PUBLIC_KEY/VAPID_PRIVATE_KEY. Portability: port with config. Swap the reading-prompt system for an image-generation call (the prayer engine's actual fulfilment step), keep the worker skeleton, the retry/ alert pattern, the */15 reveal-tick convention, and the pre-delivery-offer/failed-yes- followup crons almost unchanged.

5. Meta ads strategy + ops

Config file: /home/sha/vibing/devine_rev/meta-ads-config.json — account act_835410478659228, pixel 1215600593388165, USA-only targeting (explicit note: "Canadian corp GST/HST avoidance; never add CA or other geos to NEW campaigns"), a cost-cap lane (cap_ratio: 0.75, cap_amount: 13.00), target_cpr: 15.00, Lowest-Cost bidding (no bid cap). Not directly reusable data (brand-specific ids), but the config shape and the "USA-only for tax reasons" rule are worth carrying forward as a pattern.

Ops doctrine: /home/sha/vibing/devine_rev/06-ANALYTICS-OPTIMIZATION/ad-ops/AUTOPILOT-SPEC.md — a 4-loop system: Loop 1 account manager (daily/weekly pulls, auto-pauses only the hot ad under a "Golden Rule" guard that never touches an ad already at/under target CPA), Loop 2 creative strategist (weekly competitor/own-data research → Wave Plan), Loop 3 production lanes (statics via image-ad-forge, video as brief-only, human-produced), Loop 4 deploy (/ads-deploy + Telegram 1-tap approval). Wave Plan modes: NEW-THESIS, EXPAND-ANGLE, VARY-WINNER, REFRESH, HOLD. Rules with numbers: prune eligibility = CPA > 2× best AND > 1.5× target; scale rule = <0.7× target for 7d+ → +15-20% every 3 days; new-ads-per-day cap ≤ 4 (explicitly to protect a Meta-restricted account from review pileup — see §11); zero- purchase kill grace is time+spend based (≥15× target spend AND ≥7 days), not purchase-count based. System is currently V1 (report-only, Telegram-approval, no autonomous writes) with a promotion ladder to V2/V3 auto-execution gated on ≥90% shadow agreement over 4+ weeks. Portability: doctrine only, not code. No committed autopilot implementation was found in the repo — only the spec and supporting scripts (scripts/ad-comments-monitor/, 06-ANALYTICS-OPTIMIZATION/ad-ops/loop1-pull.sh). A prayer-engine Meta rollout would need its own fresh ad account and pixel, but the rule thresholds (Golden Rule, prune/scale formulas, new-ads/day cap) are reusable as-written.

6. Email (GHL templates, transactional vs marketing, sending, suppression)

/home/sha/vibing/devine_rev/ghl-email-templates/: BASE_TEMPLATE.html (header/body/ footer wrapper), FOOTER.html (project-specific footer with typo disclaimer + privacy policy), config.json (mailing address 222 New York St, Scranton PA 18509, default_preheader), README.md documenting the email_builder.py skill workflow (plain- text content file → built HTML email, **bold**, [text](url) links, --- for hr).

No explicit transactional-vs-marketing list-split file was found; suppression is handled per-contact via GHL tags rather than list segmentation. The most reusable code is in /home/sha/vibing/devine_rev/04-FUNNEL-EXECUTION/landing-pages/lead-nurture-worker/: a dedicated src/lib suppression module (referenced as ghl-suppression.ts in the reply- engine-v2 scope doc) with test coverage in test/suppression.test.ts and test/ghl-suppression.test.ts, implementing DND / ai-off / crisis-flag / monitor_active / fail-closed suppression logic before any send. Portability: the base-template + footer + email_builder.py pattern is portable as-is (swap address/footer copy). The suppression module is portable with config (new GHL location id).

7. Organic social pipeline

/home/sha/vibing/devine_rev/04-FUNNEL-EXECUTION/organic-social/. Spec: ORGANIC-SOCIAL-AUTOMATION-SPEC.md. It is a faceless-brand TikTok/IG/FB content engine (no personas), targeting near-$0 ongoing cost. Stack: Postiz Cloud as publisher ($29/mo, FB+IG full-auto, TikTok notify/draft-mode only — auto-publish from a server IP is documented as a ban risk), OpenRouter google/gemini-3-pro-image-preview for bespoke imagery ($0.02-0.04/img), google/lyria-3-pro-preview for music (~$0.08/track), google/veo-3.1-lite for hero video, MiniMax for voiceover, Pexels for stock filler, n8n for orchestration (4 flows in n8n/flow1..4-*.json), Turso for the content queue/log, and Node @napi-rs/canvas + FFMPEG for local rendering (src/render-slideshow.ts, src/render-video.ts). Six content pillars are tuned specifically to a heartbreak/crisis- state avatar (Cosmic Weather, Emotional Mirror, Signs & Synchronicities, Sacred Knowledge, Ritual Whispers, Quiet Proof) — this content strategy does NOT fit a prayer-delivery brand. Portability: port with config. The render/publish/orchestration pipeline (src/, scripts/, n8n/ flows, Postiz integration) is content-agnostic and reusable; the content pillars and prompts would need a full prayer-brand-specific rewrite (devotional/faith content instead of romantic-crisis content).

8. Finance / dashboards / analytics

Turso cosmicwhispers.transactions (Stripe mirror) columns confirmed via check-escalations.md queries: email, stripe_created_at, amount_cents, status, disputed, amount_refunded_cents, product_slug, payment_intent_id, customer_id. subscriptions table: id (holds the sub_... id directly), status, amount_cents, product_slug, current_period_end, canceled_at.

Private live dashboard: /pulse route in the client-portal-worker (04-FUNNEL-EXECUTION/landing-pages/client-portal-worker/src/routes/pulse.ts + src/services/pulse-data.ts) — a single server-rendered HTML page, zero external requests, dark-mode-only, built for a phone. Auth is a URL-segment secret (env.PULSE_SECRET); a miss returns a plain 404 rather than 401 so the route's existence is never advertised. CPA color bands: green ≤$15, amber ≤$25, red above. Formats money across 8 currencies (usd/cad/eur/gbp/brl/mxn/ron/bgn/czk/rsd).

A separate rosaluna-dashboard/ exists at /home/sha/vibing/devine_rev/00-PROJECT-HQ/rosaluna-dashboard/ (static Vercel site, spec/ wireframes/index.html) — appears to belong to a different sub-brand, not directly relevant.

/home/sha/vibing/devine_rev/finance/ holds only tax/compliance documents (W8-BEN-E forms for MediaZip, a PayFresco Merchant Service Agreement PDF), not dashboard code. Portability: port with config. The transactions/subscriptions schema and the /pulse route pattern (secret-in-URL-segment auth, phone-first single-page dashboard, semantic color-coded CPA/health bands) are directly reusable for a Stripe-based prayer engine's own money dashboard.

9. Fulfilment image/reading generation pipeline

The reveal mechanism is src/cron/reveal.ts, firing every 15 minutes (*/15 * * * * in wrangler.toml), which flips portal_deliverables rows from generated- but-hidden to customer-visible once status='ready' AND the estimated-ready timestamp has passed. This is also the mechanism used for the "hardship → free product" retention grant (see §2/§11): a support agent INSERTs a portal_deliverables row directly via SQL with status='pending' and an estimated_ready_at a few hours out, and the existing cron/reveal pipeline picks it up and delivers it exactly like a paid product — no special-case code needed for goodwill grants.

Actual AI generation happens inline on the purchase webhook (routes/ghl-webhook.ts for the older pattern, routes/cr-stripe-webhook.ts/ss-stripe-webhook.ts for newer per-offer webhooks), calling OpenRouter (anthropic/claude-sonnet-4 for readings, google/gemini-2.5-flash-preview for lighter content) via services/ai.ts → generateWithRetry(), with the pending → generating → ready|failed status lifecycle and rate-limited (10/hr) failure alerting described in §4.

No refund/satisfaction-guarantee code was found in the worker itself — guarantee handling (the 365-day burden-of-proof framework) lives entirely in the escalation command file as a human-executed script, not as automated logic. A prayer engine wanting an automated satisfaction-guarantee flow would need to build that from scratch; only the generation/reveal mechanics are reusable.

10. "Tagged Pay" / "taggedpay" / "tagged-pay"

No literal match anywhere in the repo for "Tagged Pay", "taggedpay", or "tagged-pay" (checked all files excluding node_modules/.git/.wrangler, case-insensitive, with and without separators).

The near-certain intended reference is "TagadaPay" (a payment processor, marketed under the brand "PayFresco"), which the team evaluated as a possible second payment rail. Full write-up: /home/sha/vibing/devine_rev/00-PROJECT-HQ/PAYFRESCO-SCOPE-20260901.md. Verbatim quote (line 9):

"PayFresco has no API of its own. docs.payfresco.com states verbatim that published SDK names and API hosts 'retain their TagadaPay identifiers.' It is a brand skin (partner: retryhub) over TagadaPay (api.tagada.io / docs.tagada.io, 280-page docs)."

Rate card (lines 22-31): weekly base fee $75/week (~$325/mo), approved transactions 5.5% + $0.30, declined transactions $0.30 each, 3DS verification $0.07 each, order bumps +2.00%, subscriptions +2.00%, Apple/Google Pay 6.50%, custom domain $2/wk. Effective cost table (lines 35-43) shows this running 2.2×-3.4× more expensive than Stripe per ticket, worst on small recurring rebills (~11.3% all-in on a $7.77/mo sub). Verdict (line 99):

"Proceed, scoped: membership/trial lane (Numina House product line) on PayFresco MoR; Stripe untouched for one-time offers."

Related paths: /home/sha/vibing/devine_rev/00-PROJECT-HQ/tagada-docs-20260906/, /home/sha/vibing/devine_rev/00-PROJECT-HQ/tagada-dash-20260906/, /home/sha/vibing/devine_rev/00-PROJECT-HQ/TAGADA-MAPPING-DIGEST-20260906.md. This is a Divine-Rev-specific merchant-of-record evaluation for a DIFFERENT product line ("Numina House") — not directly applicable to the prayer engine unless it also wants a Stripe-alternative MoR rail. Flag the name discrepancy ("Tagged Pay" vs "TagadaPay") back to whoever originated the request in case a different, unfound system was actually meant.

11. Lessons-learned / compliance incidents (facts only)

Meta pixel restriction (not a full account ban). The Venus/"exback" pixel is Religion-flagged by Meta, resulting in an EU block, with a re-appeal pending as of mid-2026:

• /home/sha/vibing/devine_rev/00-PROJECT-HQ/BRAND-DOSSIER-FULL-20260717.md:130 — "Venus/ exback pixel is Religion-flagged by Meta (EU blocked; re-appeal pending, escalation ~early Aug). New offers get fresh pixels: Curse shared pixel + Sketch pixel both live with CAPI (server-side) wired and verified; CAPI values on STANDARD events only."
• /home/sha/vibing/devine_rev/00-PROJECT-HQ/INTEL-DIEDEREN-CRO-ADVERTORIAL-20260724.md:111 — "We are constrained on Meta. The exback pixel is Religion-flagged with an EU block..."
• /home/sha/vibing/devine_rev/06-ANALYTICS-OPTIMIZATION/ad-ops/AUTOPILOT-SPEC.md:73 — the new-ads/day cap of ≤4 is explicitly there to "protect Religion-flagged account from review pileup."
• Directly relevant to the prayer engine: a prayer/religious-imagery funnel should expect the SAME kind of Meta religion-content flagging from day one (pixel restriction, EU blocking, appeal friction) and should budget review-pileup mitigation (low new-ad cadence, fresh pixels per new offer) into the launch plan rather than treating it as a one-off Divine Rev problem.

Chargeback root-cause audit — /home/sha/vibing/devine_rev/00-PROJECT-HQ/SPRINT-CHARGEBACK-REDUCTION-2026-05.md:1-22. 4-week window (2026-04-17 to 2026-05-17): 91 disputes / 42 contacts / ~$1,534 disputed / 4 lost. Root cause ranking: (1) ~75% of dispute volume traced to one silent $7.77/mo recurring membership sub that delivered nothing recurring and wasn't recognizable on bank statements — 85% reason-coded "fraudulent"; (2) disputes cluster day 31 to 6 months (rebill #2-6), not new buyers or ancient customers; (3) 85% never contacted support before disputing — straight to the bank; (4) international cards billed in USD via a US/EN funnel inflated "unrecognized charge" complaints. Notably, disputers were NOT disengaged — 88% had opened at least one email, 76% had clicked a link, reframing the true driver as "value not delivered" rather than "forgot about it."

Card-brand rail rule (from PAYFRESCO-SCOPE-20260901.md, §5 point 7): re-routing a Stripe-declined charge for the SAME product to a second processor is flagged as "the load-balancing pattern the card brands prohibit" — any dual-rail setup must be split by product line, never used as a retry path for the same product.

Not fully read, flagged for follow-up if needed: /home/sha/vibing/devine_rev/00-PROJECT-HQ/ANALYSIS-DECLINE-CODES-20260820.md, /home/sha/vibing/devine_rev/00-PROJECT-HQ/ANALYSIS-DUNNING-RETRIES-20260820.md, /home/sha/vibing/devine_rev/00-PROJECT-HQ/SPEC-DECLINE-RECOVERY-V3-AUDIT-20260807.md.

Not covered / not read in full

Time-boxed against the ~2,500-word target for the original inline digest (this file is the full unabridged version): 02-STRATEGY-CORE/ deep copywriting frameworks (directory tree only, not opened), scripts/ and tools/ subtool internals beyond directory listing, the tail of check-escalations.md (lines 761-1255 — Phase 4 execution mechanics only, no new architecture), and 00-PROJECT-HQ/DIVINE-PULSE-PROFIT-ACCURACY-20260913.md (69KB, not opened).