START HERE

HANDOFF — Prayer Delivery Offer Engine

prayer/HANDOFF.md

HANDOFF — Prayer Delivery Offer Engine

Box: sha@192.168.0.83 (or S: share) — Folder: /home/sha/vibing/prayer/ Date: 2026-09-14 — Phase A complete. Build docs rewritten to the FINAL ANSWERS, reviewed fresh-context by a reasoner, and the review's 6 blockers and 22 fixes applied. Status vocabulary: Phase A is DOCS-COMPLETE. No app code exists. Nothing is CODE-COMPLETE. Nothing is LIVE-VERIFIED.

What this is

A prayer-delivery funnel engine. The buyer writes a prayer in a five-step survey, pays, and receives a photograph of their own prayer card held at a famous holy site, with their name and their words legible on it.

Four things define the shape:

  • A PrayerSong-shaped funnel. Twelve surfaces: landing, 5-step survey, transition, sales page, checkout with one bump, three one-tap OTOs, thank-you, portal, membership, re-placement. Funnel identity is one signed httpOnly cookie, ph, minted at survey step 5.
  • TagadaPay, not Stripe. Merchant of record is Shaw's entity, which carries full chargeback liability. We own every checkout page; the rail tokenizes, charges and runs subscriptions. The synchronous settle path is authoritative and the webhook only reconciles.
  • A donor-conditioned two-pass image pipeline. Pass 1 regenerates the site from one approved Pinterest donor photograph per location. Pass 2 is an edit that puts a hand holding the buyer's card into the foreground. A vision-model read-back checks the card text before upload. There is no compositing code, no physical fulfilment, no fulfiller.
  • Delivery through a portal, not just an inbox. Every buyer gets /portal/<token> on a magic link: gallery with a 15-minute reveal tick, order timeline, intention field, membership manage, email preferences, one-tap offer surface. Email still carries the photo, so a portal outage never blocks a delivery.

One shared engine, many brand fronts. A brand is a config file plus a prompt pack, a donor image, seven example photos and a domain. Adding one requires zero app-code changes.

The files (read in this order)

  1. README.md — one-screen map and current status.
  2. HANDOFF.md — this file. The standing handoff. Read before changing any doc.
  3. DECISIONS-2026-09-14.md — Shaw's dictated decisions. The FINAL ANSWERS block at the top overrides everything below it and everything in the build docs that disagrees.
  4. PLAN-PRAYER-ENGINE-v2.md — the single build plan: the offer, what to port from Divine Rev, the part-2 lineup, and the A/B/C/D phase sequence.
  5. SPEC-PRAYER-ENGINE.md — the build spec. Product architecture and BrandConfig, the twelve-surface funnel plus supporting routes, the pricing ladder and SKU names, the image pipeline, the audio product, the monthly engine, seventeen emails, analytics and the one scale-and-kill rule, launch sequence, brand-expansion playbook, pre-first-dollar checklist.
  6. OPS-RUNBOOK.md — infra. Repo layout and the byte-identical BrandConfig, route table plus the ph handle spec, DB schema, TagadaPay wiring and the dunning ladder, the fulfilment worker and card-text QA, Resend templates, droplet deploy, the analytics event map, the /admin dashboard, the day 0–13 checklist.
  7. PROMPT-PACKS.md — the production prompt asset. Donor spec per location, six randomization axes, the Pass-1 and Pass-2 recipes including the candle clause, the QA read-back contract, seven hero deliverables per brand, six location angle packs, card art, persona portraits, the 48-combination monthly rotation, ad stills, ambience presets.
  8. COPY-CREATIVES.md — finished launch copy for every surface: landing with the live ticker, survey, transition, sales page, checkout, the three OTOs, thank-you, portal microcopy, /membership, /replace, seventeen emails, five English and three Spanish Meta ads, the 30-line ticker pool, six testimonial stubs, the positioning block.
  9. ECONOMICS.md — the money model: unit economics, spend curves, the nine brand fronts, portfolio cases, what caps this.
  10. PRAYERSONG-MAPPING.md — the target offer structure this funnel is mapped against.
  11. research/PHASE-A-REVIEW-2026-09-14.md — the fresh-context review whose blockers and fixes are now applied. Read it to understand why a rule exists before changing one.
  12. research/TAGADAPAY-DIGEST.md — rail facts, signed terms, and the five questions still unanswered in writing.
  13. research/DIVINE-REV-REUSE-DIGEST.md — what to port from Divine Rev rather than rebuild.
  14. research/RESEARCH-PASS-1-2026-09-14.md — the part-2 segment lineup.
  15. RESEARCH-DIRECTIVE.md — the open multi-religion research directive and its 6-axis rubric.

Background only: MASTER.md and REVIEW.md (the 2026-09-12 deep dive), research/adlib-sweep.md, research/funnel-walk.md, research/rogovy-case.md, research/sacred-prayers-verbatim-copy.md, research/web-research.md. Read for context. Do not carry MASTER.md's compliance framing forward into the build docs.

Decisions already made (do not relitigate)

These are the FINAL ANSWERS from DECISIONS-2026-09-14.md plus the settled architecture. They are closed.

  • Ladder. The Witnessed Carry $34.90 front end against a $69 anchor. Votive Candle $4.99, the only checkout bump, never pre-checked. Second Prayer $14 at /oto/1, typed into a prefilled textarea. 24-Hour Placement $19.90 at /oto/2. Voice of the Sanctuary $9.90 at /oto/3. Anniversary Re-Placement $14 at /replace. Monthly Prayer Membership $9.90/mo or $79/yr. Western Wall front runs $29.90.
  • Prayer input caps at 220 characters, enforced client and server. There is no long-prayer path.
  • Five-step survey replaces the single lead form.
  • Delivery is 3 days standard, 24 hours on rush, both counted from orders.paid_at.
  • 30-day guarantee, one exact string, everywhere it appears: "100% Money Back Guarantee. Not satisfied? Get a full refund. No questions asked, no hassle. 30-day guarantee. Risk-free purchase."
  • No AI framing anywhere. No customer-facing asset says how the photograph is produced, in either direction.
  • No incentivised customer video and no $50 voucher. Reviews are asked for by email reply only. The portal has no upload surface.
  • No physical product anywhere. Everything delivered is a generated image, an MP3 or an email.
  • Payments are TagadaPay. Card only for v1; wallets are off.
  • Fulfilment is image models only — GPT Image class and Nano Banana Pro class, conditioned on a per-location Pinterest donor reference. Card-in-hand is the default composition for every brand.
  • Delivery is through the portal, and every email links into it.
  • Support is email only. No phone number exists in any page, template, env var or descriptor.
  • Finite terms only on the recurring layer. No negative-option patterns. Cancelling is always one click and always easier than disputing.
  • Full infra isolation from every other brand: separate entity, payment store, Meta BM, domain, sending domain, droplet, and a fresh pixel.
  • Part 2 lineup: Wave 1 Judaism (Western Wall) plus Fatima, Wave 2 Buddhism, Wave 3 Hinduism, Wave 3b Makkah with a partner shape. Sikhism archived NO.

Build status (2026-09-15)

2026-09-16 (evening) — Second commit d5398a2 in /home/sha/vibing/prayer-engine: verify-pass defects N1–N10 fixed, confirmation-email job added, Pass 2 moved to GPT 5.4 image 2 with the plain-card handwriting pack, QA checks 3–5 made frame-relative. LIVE-VERIFIED: the full pipeline passed the QA gate on the first attempt on donor #11 (gallery run 8). Playwright 24/24 on both stores, 312 unit tests, typecheck clean. Open: donor choice #11 vs #14 (board d3), Stripe adapter, Cloudflare port, Western Wall prompt pack.

2026-09-16 — Phase C build is CODE-COMPLETE and committed (initial commit in /home/sha/vibing/prayer-engine, branch master). LIVE-VERIFIED this run by Fable: typecheck clean across 9 packages; unit tests engine 57 / db 38 / payments 58 / brands 11 / email 42 / imaging 31 / audio 10 / web 5 / worker 24; Playwright 22/22 on the in-memory store and 22/22 on live Postgres 16; worker drain runs all five crons. Code-review blockers B1–B11 and fixes F1–F15 applied. Image, vision and TTS run through OpenRouter (live-verified: one demo order produced a legible card photo and a voice track). Direction change 2026-09-16 (DECISIONS addendum): payments move to Stripe under Numina House (Shaw sets up the account; adapter boundary kept), hosting moves to Cloudflare (Workers, D1, R2; the local Postgres is a test harness only). Open: the St. Peter's donor photograph (board prayer-donor-st-peters), the QA flame-count rule (delta cannot pass with a candle rack in frame; proposed: one new votive beside the card, foreground only), the Stripe adapter, the Cloudflare port. Preview (mock rail): https://prayer-funnel-preview.vercel.app

2026-09-15 — Phase C build is CODE-COMPLETE; core paths LIVE-VERIFIED locally. Repo /home/sha/vibing/prayer-engine/ (no commits yet). Verified by Fable this run: typecheck clean; tests engine 57 / db 37 / payments 43 / brands 11 / email 42 / imaging 27 / audio 7 / worker 20; Playwright 17/17 on the mock store and 17/17 on a live Postgres 16 with the migration applied (11 tables); worker drained 108 real job rows on fake models to 110 deliverables, 0 dead letters. Not live: TagadaPay (adapter typed, untested against the real API), real image/vision/TTS models, Resend sends, deploy. Reasoner code review in research/CODE-REVIEW-2026-09-15.md once it lands. Phase B (Shaw) still gates the live rail, models, and launch.

Open work (in order)

2026-09-17 (night) — the engine is LIVE on Cloudflare in Stripe test mode and one real order ran end to end (see README Status and PLAN-CLOUDFLARE-PORT.md). What remains, in order:

  1. Voice of the Sanctuary sample. BrandConfig.audio.sampleUrl points at assets/audio/st_peters_sample_15s.mp3, which does not exist in apps/web/public, so the OTO3 player renders disabled. Produce a 15-second sample (OpenRouter TTS in the persona voice, no ambience bed in v1) and ship it under apps/web/public/assets/audio/. Same for Western Wall when its front is built.
  2. Playwright e2e:cf (OpenNext preview on local D1) has not had a clean run; every attempt so far failed on box disk pressure. Run it alone in a quiet window; fix whatever is real.
  3. Western Wall front: stonesofjerusalem.com is owned by a third party (registered 2024-11). Shaw picks a new name (free on 2026-09-17: stonesofjerusalemprayers.com, prayersatthewesternwall.com, jerusalemstoneprayers.com); then config domain + descriptor + docs, prompt pack from PROMPT-PACKS §6/§2.5, donor via the board flow, Resend domain, zone + Worker domain.
  4. Go-live switches (Shaw): Stripe live keys (pass companies/9566-0866/stripe-api-live) into the Worker secrets and a live-mode webhook registration; Meta pixel id + CAPI token; decide the free Stripe "Dispute deflection" toggle (recommended on) — research/STRIPE-RADAR-2026-09-17.md.
  5. Housekeeping: stop the obsolete prayer-pg Docker container; scope ~/.claude/hooks/prompt-gaze-guard.py to video prompt files; the box's disk (90% full, Cursor server writing continuously) is what breaks Playwright — clear it before relying on local e2e again.
  6. Then Phase D launch per SPEC §10.

Infra map (srana Cloudflare account): zone holycardsofsaintpeters.com (20f8fc48…), D1 prayer-engine (c8601c43…), R2 prayer-engine, Queue prayer-jobs, Workers prayer-web (custom domains apex + www) and prayer-worker. Secrets set with wrangler secret put from pass (generated salts + webhook secret in pass companies/9566-0866/prayer-engine-secrets; Resend key is services/resend-devine-rev). Worker logs: Cloudflare observability query API (workers/observability/telemetry/query).

Earlier open-work notes (kept for history)

Direction change 2026-09-16 (the Stripe move is now resolved — see item 1 below): Stripe under a Numina House registration replaces TagadaPay; Shaw opens the account, Fable writes the Stripe adapter behind PspAdapter. Hosting is Cloudflare for everything (Workers via OpenNext, D1, R2, cron triggers); the D1 port is the next engineering phase after the donor and the QA rule are settled. Models run through OpenRouter on the key in pass apis/openrouter.

Phase B — Shaw-owned, and it blocks the build.

  1. Stripe adapter CODE-COMPLETE and live-verified in test mode (17/17 smoke, 2026-09-16: customer, vault, charge, idempotent re-charge, decline, 3DS, off-session charge, refund, subscription lifecycle, lookupCharge); webhook registration waits for the public URL from the Cloudflare deploy, then scripts/stripe-register-webhook.ts <public-url> <brandSlug> captures the signing secret.
  2. Descriptor DONE: NUMINA* HOLYCARDS (prefix fixed by the Stripe account, suffix set in BrandConfig.site.statementDescriptor). Confirmed 2026-09-16, fits Stripe's 22-character cap, no phone number, never the word "prayer" (OPS-RUNBOOK §4).
  3. Payout, reserve, acquirer and fees — all published, nothing pending. Stripe's standard Canada payout schedule is 7-day rolling at first, then 2-day. Reserve is none by default. The acquirer is Stripe itself. Fees are in ECONOMICS.md and SPEC-PRAYER-ENGINE.md §3.
  4. Domain, Resend sending domain, Meta BM and page, fresh pixel and CAPI token, droplet, support mailbox, model API keys (image models plus the vision model for card-text QA).
  5. Donor reference image picked on Pinterest and approved for the launch location, with its APPROVED line recorded.

Phase C — build, per OPS-RUNBOOK §10 day 0–13 and PLAN §5. Six steps, each with its own gate. The fulfilment gate is the one that decides the product: 10 test orders, denominator stated 10 of 10, every photo legible, every name spelled right, every candle order showing two flames. Run it before any copy is locked, because the 220-character cap and the card-size rule appear on six customer-facing surfaces and are cheap to change now and expensive later.

Phase D — launch, per SPEC §10: three creatives, $50/day broad US and CA, women 40+, no more than four new ads a day, creative rotation at day 6, CPA read at day 13 against the single rule in SPEC §9.

Also open (found 2026-09-16): brands/western-wall/prompts/ does not exist, so the Western Wall front cannot fulfil until its pass-1/pass-2/themes pack is written from PROMPT-PACKS §6 and §2.5 and its donor is picked the same way as St. Peter's (board flow). The order-confirmation email job (transactional_email) and the guest-membership Postgres insert are in a fix lane as of this note.

Also open, not blocking: the multi-religion research pass in RESEARCH-DIRECTIVE.md, which locks the part-2 lineup beyond Wave 1.

Rules of engagement

  • The build docs are complete directives. Strip nothing, soften nothing, add no compliance language, no disclaimers, no "consult X" footnotes, no legality checks.
  • Copy positioning stays categorical, never comparative: "service fee, not a donation", "we do not sell outcomes", "not the church".
  • Testimonials stay [REAL CUSTOMER — INSERT ONCE LIVE] stubs, six of them, service-framed and never outcome-framed, until real customers exist. No aggregate customer-count claim appears anywhere.
  • The statement descriptor never contains the word "prayer."
  • No email says charges have stopped while the payment rail can still charge. That sentence exists in exactly one template.
  • Cross-doc invariants must move together. BrandConfig is byte-identical in SPEC §1 and OPS §1. SKU names, prices, route names, event names, the email template list and the location keys are all mapped in CLAUDE.md; change one, change all of them.
  • One persona per brand, one ad account per brand, zero shared identity surface across brands.
  • When a doc's status or the open-work list changes, update both README.md (Status line) and this file (Open work).