self.add_tag_to_contact_by_id(contact_id, f'{tag_name}: {tag_value}')
# the VALUE is concatenated into the tag NAME

Why this matters — and why we are not putting it in Stripe

The quiz asks people four revealing things: what is standing in their way, what they fear if nothing changes — in their own words, their age, and their gender. It also works out whether they have mastered all nine fundamentals. Today every one of those dies at the end of the quiz. So a recovery email can say "you wanted to build muscle" and nothing more.

✅ Already done for you — the entire ActiveCampaign side

Created via the API on 6 Aug 2026 and re-confirmed present the same day. Do not create any of these; the ids are stable.

🔑 LIFE_CONTEXT is an array — send [0], do not stringify it.

🔴 Naming matters here: it is "all fundamentals mastered" — never "already-elite" or "advanced". It is a measured outcome (every one of the nine fundamentals at level 4), not a description of the person.

🔴 Why nothing has been tagged — one thing proven, two things to check

# app/apps/quiz/activecampaign_sync.py, in _apply_tags()
resp = requests.get(f"{AC_BASE_URL}/api/3/tags", headers=HEADERS,
                    params={"limit": 100}, timeout=10)   # 100 of 5,845
...
tag_id = tag_map.get(tag_name)
if not tag_id:
    continue          # no log, no error, no tag

def sync_quiz_lead(name, email, primary_path, obstacle, source="") -> bool:

Step by step

# AC custom field ids — created 6 Aug 2026, stable.
QUIZ_FIELD_IDS = {
    "persona": 61,                      # THE GOAL — PRIMARY_PATH
    "obstacle": 64, "future_stakes": 65, "age": 66,
    "gender": 67, "all_fundamentals_mastered": 68,
    "life_context": 69, "background": 70,
    "training_recency": 71, "weakest_fundamental": 77,
}

def _apply_field_values(contact_id, values):
    # Write quiz answers onto the contact. Never raises.
    for key, field_id in QUIZ_FIELD_IDS.items():
        value = values.get(key)
        if value in (None, ""):
            continue                      # never blank out a real value
        try:
            requests.post(
                f"{AC_BASE_URL}/api/3/fieldValues", headers=HEADERS,
                json={"fieldValue": {"contact": int(contact_id),
                                     "field": field_id, "value": str(value)}},
                timeout=10)
        except Exception as exc:
            logger.warning("AC field %s failed for %s: %s", key, contact_id, exc)

persona:                   (t.PRIMARY_PATH ?? "").trim(),   // THE GOAL
future_stakes:             (t.FUTURE_STAKES ?? "").trim(),
age:                       (t.AGE ?? "").trim(),
gender:                    (t.GENDER ?? "").trim(),
all_fundamentals_mastered: ctx.allMastered === true,
life_context:              (t.LIFE_CONTEXT ?? [])[0] ?? "",   // ARRAY
background:                (t.BACKGROUND ?? "").trim(),
training_recency:          (t.TRAINING_RECENCY ?? "").trim(),
weakest_fundamental:       ctx.weakest?.name ?? "",

The one structural problem

The subscription is born before the buyer exists. startCheckout() runs on page load — before any field is touched — and the server creates a Customer + Subscription right then.

Estate nuance (3 Aug audit): on v3 the mint is unconditional — startCheckout() on load, every visitor. On the quiz estate it is conditional but effectively always-on for the funnel that matters: maybePrefetch() → ensureIntent() fires on DOMContentLoaded whenever the email is prefilled — which is every arrival from the quiz handoff. Same phantom effect, different trigger — the quiz half of the fix is NIC-41 (task 7); change 1 here is the v3 half.

So every visitor who opens a checkout page and leaves mints an anonymous "trialing" subscription. The census of all 94 v3 subscriptions ever created (30 Jul evening, fully paginated — an earlier version of this page said 78/4 past_due; that scan truncated at the newest 100 subs and the adversarial re-check caught it. States churn daily — the 2 Aug re-run is in the banner above: 18 trialing all-phantom, 17 past_due, and the quiz estate adds its own pattern: 17 incomplete subs, all 17 with an email, plus 25 already expired — 42 reachable typed-email abandoners — that lane is now with Aga, AGA-57):

Bonus churn (v3): applying a coupon calls recreate() → a second customer + subscription per visitor, without cancelling the first. The quiz estate has no coupon recreate — but its plan switch remints client-side without cancelling the prior incomplete sub. Same debris class, both estates.

🔓 What this enables — honest today-vs-after (two rows already work thanks to your pay-click stamps)

The five changes — where · what · how you know it worked

# at trial-subscription creation — phantoms then die at trial end instead of going past_due
stripe.Subscription.create( ...,
    trial_period_days=7,
    trial_settings={"end_behavior": {"missing_payment_method": "cancel"}} )

# BOTH states — trialing phantoms AND the past_due junk they age into.
# auto_paging_iter matters: a limit-100 scan misses older debris (we made that mistake ourselves).
for status in ("trialing", "past_due"):
    for sub in stripe.Subscription.list(status=status, limit=100).auto_paging_iter():
        if (sub["metadata"].get("checkout_version") == "v3"
                and not sub.get("default_payment_method")
                and not stripe.Customer.retrieve(sub["customer"]).get("email")
                and time.time() - sub["created"] > 86400):
            stripe.Subscription.cancel(sub["id"])

# nginx/sites-enabled/django_project — BOTH proxy blocks (~L42-44 and ~L64-66)
# set Host, X-Real-IP and X-Forwarded-For ... and never X-Forwarded-Proto.
proxy_set_header Host              $host;
proxy_set_header X-Real-IP         $remote_addr;
proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;   # <-- add this, in BOTH blocks

# Django settings — SECURE_PROXY_SSL_HEADER appears NOWHERE in app/.
# Without it Django ignores the header even once nginx sends it.
SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")

How we'll both know the whole task worked

Next, the good news: your checkout is doing its job. We read /payments/checkouts-v3/trial/12month/ live and traced the whole path. The attribution shim is served (/static/checkouts_v3/attribution.js, 200), stripe-client.js posts attribution: getAttribution() into create-payment-intent, and your server writes it into Stripe metadata. All three legs work. We also confirmed first-touch persistence is working — one intent created on 28 Jul still carried a first_seen of 21 Jul.

The problem is what is inside it. Across the last 30 checkouts-v3 payment intents, the attribution object looks like this in 29 of 30 (the thirtieth carries no attribution at all):

{"first_seen":"2026-07-28T22:13:01.394Z",
 "landing":"/payments/checkouts-v3/normal/12month/",
 "referrer":null,
 "page":"/payments/checkouts-v3/normal/12month/",
 "ua_webview":false}

No utm_source. No utm_campaign. No gclid. Referrer null. The shim can only read UTMs from the checkout page's own URL — and visitors are arriving there with a bare URL, because whatever links them from the quiz/paywall to the checkout does not carry the query string across.

The contrast proves it is not the shim's fault. On the older /v2_checkout/ estate, where paid ads land people directly on the checkout, the same metadata comes through fully populated — utm_source=google, utm_campaign=tma_lifetime_retarg_demandgen, a real gclid, and a landing_path. Same mechanism, different journey: those visitors arrive with UTMs on the URL.

What to do — in this order

1. Run the acceptance test FIRST (10 min). One purchase with ?utm_source=nictest&utm_campaign=verify on the quiz URL → we read the Stripe metadata. This is a diagnostic, not a formality — it tells us which half is broken before you write anything.
2. If utm_source: "nictest" arrives: the quiz forward-path is proven working and closes here. The remaining loss is bare landings only → move to step 4.
3. If it does not arrive: the break is in qsAttr / create-intent, not in the handoff. Debug there. Do not rebuild the handoff blind — it already does the copy.
4. First-touch rehydrate (the genuine new work). When the current URL carries no UTMs, read the stored first touch (tma_quiz_first_touch) and use it in the handoff. Same fix conceptually for v3 bare landings, where first-touch storage exists but arrives empty.

How we will both know it worked

Two probes, not one. (a) A purchase with ?utm_source=nictest on the URL → utm_source: "nictest" in the Stripe metadata. (b) A purchase from a bare quiz URL, in a session that first arrived tagged → the metadata still carries the original source. (b) is the one that proves the rehydrate. Each takes us a minute to confirm read-only.

First, the good news: the checkout is correct on the path that matters. Verified in the shipped bundle 31 Jul — quiz.themovementathlete.com redirects to /2026-quiz-checkout-v1/, annual charges $97 today, ramps are $24.98 / $12.48, addToCartValue is populated (97 / 25 / 12), tma_ckt_out is set on hand-off, the exit modal fires, and UTMs including gclid/fbclid are forwarded. Two things turned up on the fallback route.

1. The production bundle ships a test domain. VITE_REGISTER_PAY_URL: "https://app-test.themovementathlete.com/register/yearly_2026/". This is the fallback register route — the primary (app.themovementathlete.com/payments/quiz-checkout/) is right — but if the fallback ever fires, a real buyer is sent to a test domain to pay. Point it at production, or remove the fallback.
2. The same fallback block still sends addToCartValue: 0 — on 1wk_trial (corrected 3 Aug: this card previously said monthly_trial; that entry is fine at 25, and annual_trial sends 157). Harmless while /50off/ is the live path; a Meta-optimisation bug the moment the fallback is used — a 0 teaches Meta to find people worth nothing.

The deployed bundle greps clean: zero hits for app-test, and no plan object left carrying addToCartValue: 0 (check the 1wk_trial entry specifically). Companion: task 4 (the dead-button trace) lives in this same fallback block — do both in one sitting.

What it is, in plain terms: in the quiz checkout handler there is a branch that runs when the tapped plan doesn't match any plan object — and it does nothing. No event, no message. The visitor taps Buy, nothing happens, and they vanish from every number we have. We cannot even say how often it fires.

1. It's the same fallback block task 3 opens (the one carrying VITE_REGISTER_PAY_URL and the addToCartValue map) — do both in one sitting.
2. In the no-match branch: fire an analytics event checkout_button_dead with the plan id and screen, and render a visible error — "Something went wrong — refresh and try again." Anything but silence.
3. Test: force a mismatched plan id in a test build → the event appears in GA4 DebugView and the message renders.

A forced plan-mismatch click leaves a trace (event + visible message) instead of silence — and from that day we know whether this branch fires once a year or fifty times a week.

Aga, 3 Aug: "remove this task for Nic, I am handling this now." The lane build (Stripe abandoners → the abandonment emails, purchase exclusion evaluated at send time) is hers, tracked as AGA-57. The verified facts travel with it: 42 typed-email, reached-payment abandoners already sit in Stripe on the quiz estate (17 incomplete, all with emails, + 25 expired; ~14/day accruing), and none of the 20 scheduled jobs mails them today.

Your only related piece stays in task 1, change 2: the buyer_email stamp + Customer.modify on the v3 estate — that is what makes v3 abandoners visible to whatever lane Aga builds. Nothing else here is yours.

What the task was — all three now done, kept for the record:

1. Quiz success is dataLayer-only. It does not fire an fbq Purchase, and it does not carry an eventID. Give it the same contract v3 has: browser fbq Purchase with eventID = the PaymentIntent id, so it dedups against the webhook that is already running. Value + currency from the intent, not the page.
2. Confirm the webhook covers the quiz estate's intents too — same handler, but worth one look, since the quiz path creates its intents through quiz_checkout_stripe.py.
3. Pixel proof (5 min, ops not code): open a checkouts-v3 page with Meta Pixel Helper against GTM-TKGDZR9 and confirm the pixel actually loads — assumed, never proven. If Aga is quicker to this than you, she can do it — it needs no repo access.

A test buy on the quiz estate shows in Meta Events Manager as ONE deduplicated purchase (server + browser), matching what v3 already does today.

Why it is worth 6–8 hours: 604 buy-clicks produced 248 subscription starts. The redirect from the quiz paywall to app.themovementathlete.com is where the other 356 die. You already proved the on-page pattern on checkouts-v3 — this is a port, not an invention.

1. Mount Stripe Elements under the tiers on the quiz paywall, on the v3 contract: attribution.js + create-payment-intent/update-payment-intent — the buyer never leaves the page.
2. Inside the same build, give the dead button a voice (old task 19): the handler branch that silently no-ops when a plan doesn't match must emit an analytics event (checkout_button_dead with the plan id) and show the visitor an error — today that person vanishes from every number we have.
3. Keep the fallback register route OUT of the bundle (task 3 removes app-test; don't reintroduce a fallback that can point anywhere but production).

A test buyer completes payment without leaving the paywall, the attribution lands per task 2's acceptance test, and a forced plan-mismatch click leaves a trace instead of silence.

C — a landing-mix + measurement gap. YouTube's traffic overwhelmingly never goes near the quiz: 96% of its 3,810 sessions land on main-site lead-magnet pages, and generate_lead only exists on the quiz subdomain — so even a converting magnet visitor is structurally invisible. The numbers:

So suspect B ("the traffic doesn't convert") is unprovable either way from GA4 — conversion on the pages YouTube actually lands on is simply not instrumented. And suspect A (quiz-hop UTM loss) affects at most the ~44 quiz-host sessions. The honest reading: we cannot count YouTube's leads until the magnet pages report form submissions.

1. Log in at app.leadpages.com → left menu Conversion Tools → Pop-ups (older UI calls them Leadboxes).
2. Open each of the ten magnet pop-ups → click the form / button widget → find the after-submit / thank-you setting → choose "Go to URL" (instead of the inline thank-you message) → paste that magnet's URL from this table → Update/Publish:

One check per box while you're in there: if a pop-up currently shows a direct download link after submit (instead of "check your email"), the redirect would hide it — tell us which one and we add that file's link to the thank-you page. The delivery email from AC keeps working regardless.

1. Open /free-28-days-calisthenics-challenge/?utm_source=nictest, submit a test email in the pop-up.
2. You should land on /resource-thank-you/?magnet=challenge.
3. GA4 (analytics.google.com) → Realtime: a generate_lead event appears; in DebugView its session source reads nictest.

Magnet submissions appear as generate_lead with real sources — from that day the YouTube lane (and every magnet lane) counts. YouTube fleet gate: due 22 Aug.

Three questions about what a free member sees cannot be answered from outside the login wall (which upgrade CTAs exist, what the paywall shows a logged-in free user, whether the $9.99 step-down is reachable). Create a throwaway free account and send the credentials to Aga — the audit runs the same day.

We run two checkout estates on two different analytics contracts, and nobody has decided which survives. Every task on this page doubles in maintenance until this is ruled. Bring a recommendation to Aga (15 minutes of thought, no code); she rules; the loser gets a retirement date. Parked here so it is not invisible — do not start migrating anything until the ruling exists.

Why it left your brief: the keyword map this card waited on landed 6 Aug (marketing/seo/NIC82_FRONT_LEVER_KEYWORD_MAP_2026-08-06.md, Aga-approved) and it refuted the premise. The bare skill name is a zero-click SERP (61.8–71.8% zero-click across the clusters; planche = 135,725 impressions → 97 clicks), so consolidation is worth ≈+1.1 leads/28d [MODELLED] across all three clusters — a 20-minute hygiene task, not a project: 3 × 301 (/improve-front-lever/ · /how-to-do-a-front-lever/ · /front-lever-variation/ → /front-lever-progression/) + 6 internal-link repoints, with an explicit DO-NOT on the tempting fourth merge. The fleet applies these itself via the Redirection REST API — the same mechanism that shipped the NIC-12 batch — ranked last behind everything on this page. Stale figures corrected while we were here: 8 live pages, not nine; the 9,184/0.25% was a windowless 28-day under-read (336-day truth: 192,114 impressions / 451 clicks / 0.235%). Live spot-check 7 Aug: all four URLs still 200, so the work is real — it is just not yours.

We checked before asking — and the work no longer exists. The backlink-checked evidence list (marketing/seo/NIC83_BLOG_HYGIENE_EVIDENCE_2026-08-06.md, all 867 published documents on both sites) named 20 URLs still needing action. The fleet executed the batch under AGA-123 on 6 Aug via the Redirection REST API, and on 7 Aug we re-crawled all 20: 19 return a one-hop 301 to a 200 target — including /blogs/ → /blog/, /home-page-test/ → /, and the missed 25th promo /70-off-new-aug24/ → /start-training/ — and 1 is drafted (404, deliberate). Method note that survives: every retirement was draft + 301, never a delete, because external backlinks are unverifiable from here (no backlink tool in the estate; GSC Links is UI-only) and a 301 preserves unknown equity either way. Residuals, neither yours: (1) /calisthenics-gear/ + /freemonth/ still link the retired /50-off-black-friday/ internally — works via the 301, but the edit is Aga-gated (affiliate ruling); (2) cosmetic draft residue on BWA page 210021 under a live redirect.

The new post-purchase welcome email shows the buyer their username (email) + generated password in a credentials box. Before the first real send we need one test: buy on a test card, take the password from the email, and confirm it logs into the app. Also confirm the %EMAIL%/%PASSWORD% SendGrid substitutions are mapped. The email is rendered for you at tma-paywall-spec.netlify.app/email-welcome-noquiz. Nothing sends until this passes.

Aga took this off the task list on 2 Aug. The substance survives as an acceptance test inside task 4 (the abandonment-lane rebuild): the purchase exclusion is evaluated at send time, a test buyer never receives the abandonment mail, and a genuine abandoner still does. No standalone work item remains.

Aga, 2 Aug: "not for Nic — move it under Aga." The whole workstream (69 outdated plugins + 11 themes triage, the two Lighthouse-48 mobile scores, the bandwidth watch, the deleted themovementdev install) is now AGA-53 on Aga's queue — she coordinates the external WordPress dev directly. The PHP upgrade was already with a separate dev (target 8.2 — Divi 4.27.7 is only tested to 8.2). Nothing here is yours.

Aga's 2 Aug ruling: this is the same handler work as task 1, so it now lives there as change 5 — write the email source into Stripe at purchase, with the full step-by-step inline (nothing external to open). One correction made in the fold: the old card pointed at Analytics Brief "task 17" for the last-funnel-step export — that export is task 11; task 17 is the canonical-identity keystone. The wrong pointer is gone.

The revenue plan (task 8) held every quiz-paywall deploy behind this: "the live quiz calls /api/quiz/config, gets a 404, and runs on fallback config — nothing else starts until this reports." Live check 2 Aug: it returns 200 now. Whoever fixed it during the 31 Jul–1 Aug quiz work: thank you. The gate in front of task 6 (the on-page checkout) is open, and the revenue doc's task 8 is stale.

What happened: a Redirection-plugin 301 (added after 31 Jul) sent the assessment doorway — YouTube's #1 landing page, 1,991 sessions/28d — to the quiz root with a literal target. WP Engine's edge cache then served that cached bare 301 to every utm-only visitor, so their utm_source/_gl vanished mid-hop and the link-integrity guard regressed 19/0 → 18/1.

The fix, already live: a guarded Code Snippet (id 9, deployed with health-check + auto-rollback, verified 2 Aug) client-redirects the page to quiz.themovementathlete.com/ + location.search — the browser carries the query string, the edge can't strip it. Aga deletes the plugin rule (2 minutes, AGA-54) and the guard returns to 0 dropping. Same funnel behaviour, attribution intact. Filed here so you know why the doorway behaves differently this week.

Fix A (quiz root forwards the query string) is live — utm_* and _gl both survive. Guard moved 18/4 → 19/1 → 19/0, exit 0.

The other three were not yours, which is why they are off this list:

• Fix B /free-front-lever-training-guide/ — we proved WP Engine's edge strips utm_* and _gl before PHP ever runs (control parameters survived the same redirect that dropped the real ones). No WordPress-level fix exists for any 301 on WP Engine. The rule now is simply: link final destinations, never a WP alias. Probe retired, with the reasoning written into the guard so nobody re-opens it.
• Fix C trailing slashes — WordPress core redirect_canonical(), not nginx. Aga ruled: do not patch core to satisfy a probe.
• Fix E GA4 domains — already correct.

Only the content field errors; id, status, slug, title and meta all read fine over the API. So the wp-admin list renders and it can be trashed without WP-CLI — no server access needed. The body is unrecoverable via the API (zero revisions); a DB pull is the only route if the story is worth saving. Awaiting Aga's call.

A live article was unreachable behind a 51-hop loop on 3,821 hits — two redirect plugins pointing at each other. Fixed at source via the API: the offending rule disabled, the page's slug corrected (it had genuinely been misspelled for years), and a replacement 301 added so the old URL still resolves. …-strength/ now serves 200; …-strenght/ 301s to it in one hop.

Also live since this page was last updated: FAQ structured data on 9 pages (the estate had none), IndexNow active on both sites, and BWA's Organization schema corrected — it had been telling every AI engine our organisation was "Calisthenics Academy".

The original task is kept below for the record.

What it was, in plain terms: in static/quiz_checkout/stripe-client.js, maybePrefetch() runs on DOMContentLoaded and calls ensureIntent() whenever the email field is pre-filled — and it is always pre-filled, because it comes across from the quiz. So Stripe creates a customer, a subscription and an open $97 invoice for every page view, before the visitor has touched anything.

1. Checkout conversion is unmeasurable. requires_payment_method and "no payment method attached" are the mechanical default for every non-buyer — someone who bounced in two seconds is indistinguishable from someone who read the whole page and decided no. We spent a day reaching a wrong conclusion because of this.
2. The recovery lane is counting bounces as abandoners, so the abandoned-cart audience is inflated with people who never intended to buy.
3. Stripe fills with phantom subscriptions — 48 records for 41 distinct people in the first four days.

1. Move the ensureIntent() call out of maybePrefetch() / DOMContentLoaded.
2. Fire it on the first interaction with a card field — focus, or first keystroke on the card number. Keep the existing password-blur trigger as it is.
3. Do not create an intent on load under any condition.
4. 🔴 KEEP stampPaywallView — do not delete it along with the mint. Corrected 3 Aug by the code audit: the signal you need already exists, so this is now a "leave it alone" instruction, not a build. stamp-paywall-view already records email · plan · path · pending password into Redis/cache and queues through quiz_checkout_abandon.py. When you move ensureIntent(), stampPaywallView must still fire on load — it is what keeps the recovery lane fed once the Stripe phantom is gone. No new endpoint needed. Why this half is not optional: checked live on 3 Aug across all 44 abandoner subscriptions — every invoice reads attempted=false, attempt_count=0, and not one carries a payment_method or a last_payment_error. Nobody has ever typed a card into this checkout. So the phantom intent is currently the only record anywhere that a person reached the checkout and left. The moment "no trace in Stripe" is true and stampPaywallView has been removed with it, the recovery lane loses its entire audience feed, silently — we would fix the number and kill the lane in the same commit.
5. Also avoid orphan remints. The quiz plan-switch currently remints client-side without cancelling the prior incomplete subscription. Whatever you do to the load-time mint, make the switch cancel the one it replaces — otherwise the debris just moves rather than stopping.
6. Test (budget 15m of the 60m): load the checkout with a pre-filled email and do not touch the card form → confirm no new Stripe customer or subscription appears, and that the stamp-paywall-view record did arrive with plan/path intact. Then type one character into the card number field → confirm the intent is created and a real purchase still completes end to end. Finally switch plans twice → confirm only one incomplete subscription exists, not three.

A page load with zero card interaction leaves no trace in Stripe but does leave a stamp-paywall-view record, and a real purchase still works. From that day, checkout conversion becomes a real number and the recovery lane keeps a real audience.

Nic — nothing to do here. This came off your list on 3 Aug. Whether the deadline should truly bind is a pricing decision (binding buys honest urgency, but the person who returns on day 5 ready to pay $97 would meet $157 and may buy nothing). Aga rules first. The findings below are kept so whoever picks it up does not have to re-probe.

What is already right: the per-visitor deadline is fixed once set — the same address returns the identical timestamp on repeated requests, so the clock does not silently restart on every visit. That part works.

1. An address the server has never seen gets a fresh 48 hours. Verified with a never-seen address: exactly 48.0h. So the offer is re-obtainable with a new email — and an existing person whose cache entry has lapsed gets a brand-new window. Live example: wajackson1@gmail.com abandoned on 30 Jul and today holds a window running to 4 Aug 08:53.
2. We have never observed the expired state. TMA_QC_OFFER_EXPIRED came back false on every address tested, including a 90-hour-old abandoner — so we cannot confirm the $97 is actually killed at charge time, only in the UI. Your own comment in the page source says it plainly: "the same deadline must kill the $97 server-side (coupon dies → $157). A timer that changes nothing is banned."

1. Once an email has had a window, never mint it a second one. A lapsed cache entry must resolve to EXPIRED, not to a fresh 48h.
2. Enforce it at charge time, not just in the interface.

Take an address whose window has passed and load the checkout → TMA_QC_OFFER_EXPIRED is true and the page shows $157. Attempt the purchase → Stripe charges $157, not $97.

Why it matters to us: emails 3 and 4 of the recovery sequence tell people their window is closing, and then that it closed. If the page hands them a fresh 48 hours on arrival, we have lied to them in writing — and taught them that every deadline we ever set is theatre.

Batch this with task 3. It is the same bundle and the same redeploy, so doing them together costs almost nothing extra — and doing them apart costs a second deploy.

1. Two "4.9" star strings — 4.9 · 100,000+ plans created and ★★★★★ 4.9 · 100k+ users. The settled ruling (31 Jul) is to ship 4.7 unattributed. Measured live 3 Aug: iTunes API 4.53 across 297 ratings; the Google Play listing reads "Rated 4.7 stars". 4.9 overstates both.
2. One "Join 53,000+ people" sitting on the same funnel as six "100,000+" strings. Whichever is right, they cannot both be — a visitor who notices stops believing either.
3. Also re-export Step-1-Take-Assessment-1.png — the image bakes in "It only takes 5 minutes" against Aga's 3-minute ruling, so it cannot be fixed in copy.

A grep of the redeployed bundle returns zero "4.9" star strings and zero "53,000+", and the assessment image no longer says 5 minutes. 🔴 Do not ship 4.8 anywhere — that claim is governed separately by AGA-84 and needs Aga's written confirmation.

For the record — the original card

What travels today (verified live 3 Aug, and re-confirmed against the hand-off code): the quiz → checkout hand-off sends email, path, persona and plan (plus the utm_*/gclid/fbclid it copies off the URL). Stripe subscription metadata carries email, persona, path, plan_slug, plan_key, plan_id, offer, offer_expired, coupon, quiz_variant, screen_id, checkout_version, purchase_path, plus utm_source/medium/campaign on 33 of 48.

What does not travel, and the quiz already knows: OBSTACLE · FUTURE_STAKES (their own words for what they fear if nothing changes) · AGE · GENDER. All four die at the checkout boundary.

1. Append the four to the quiz → checkout hand-off URL exactly as path and persona already travel, and read them the same way.
2. Include them in the stamp-paywall-view record — and in intent metadata once a card is touched.
3. No Django schema work and no new tables. Same pattern as the params already flowing.

Complete the quiz, land on the checkout, and all four appear in the stamp-paywall-view record carrying the values the quiz collected.

Why it matters to us: today a recovery email can say what they wanted. With these it can say what was standing in their way, and what they told us they were afraid of. That is the difference between a template and a letter.

What it is, in plain terms: the same metric has three live values on the same day, and the rate built from it has two values 24× apart depending on which denominator you pick.

They differ for real reasons — event scope, hostname filter, AC list membership and dedup. The problem is not that they differ, it is that nothing declares which one is "the" number. Two of the four sourcing errors in the 3 Aug quiz analysis trace directly back to this.

1. Reconcile the three counts and establish why each differs.
2. Publish one canonical numerator + denominator pair as the definition of "quiz lead" and "quiz lead rate" — written into the scoreboard config, not into a doc where it can drift.
3. Keep every other counter visible, but label each explicitly as a different measure. Never mix them. Follow the precedent already set for app sign-ups: RevenueCat customers_new and GA4 onboarding are different counters, both real, never mixed.
4. Test (budget 30m of the 1.5h): kpi_15k.json and data_funnel.json report the same lead count and the same lead rate for the same window, and a third party can reproduce both from the stated query without asking which source to use.

One definition lives in config, the two scoreboard files agree, and the other counters carry an explicit label saying what they measure instead.

What it is: the R1 canary on 991 NEW Re-Engagement - For people who stopped opening hard-bounced 6.9% (33 of 478) — 3.5× the 2% hard-stop line.

1. Pre-clean the ~9,128-contact backlog: drop known-dead and bounce-history addresses.
2. Do this before enter_991_reengagement.py continues the 2k/day feed.

The backlog is cleaned and the feed resumes under the 2% line. Skipping this means domain reputation pays for hygiene we would otherwise get free from the suppression step.

What it is: three A/B splits are pre-registered and waiting — the 750 TMA | Welcome Sequence After Quiz E1 subject test, plus nurture and re-engage. They need manual setup in ActiveCampaign before they can run.

1. Build the three splits in AC. Setup specs are already written — EXPERIMENT_LEDGER.json W29 records and WEEKLY_2026-08-03.md §5.

All three are live. This is the third consecutive week the self-learning loop has run with zero live experiments, so it is currently learning nothing.

What it is: the weekly safety sweep pauses all sending at 0.10% spam complaints. That is its number-one hard stop — and complaint counts have been DARK since the loop was built, on the platform carrying roughly 100% of send volume. We cannot currently trigger the most important safety rule we have.

1. Extend tools/email-analytics/collect_metrics.py to pull ActiveCampaign spam-complaint counts.
2. Feed them into the safety sweep so the 0.10% hard-stop can actually fire.

Complaint rate appears in the weekly metrics pull and the hard-stop is armed. Flagged 27 Jul, still open.

app.themovementathlete.com/login                      X-Robots-Tag: noindex, nofollow
app.themovementathlete.com/register/*                 X-Robots-Tag: noindex, nofollow
app.themovementathlete.com/payments/quiz-checkout/    X-Robots-Tag: noindex, nofollow
app.themovementathlete.com/payments/checkouts-v3/*    X-Robots-Tag: noindex, nofollow

Context, because it changes the fix: the /register/ promo URLs are intentional unlisted-URL offers — public by design, reached only by direct link. Aga is keeping them. So the job is not to redirect or remove anything. It is to make them reachable by link and invisible in search, which is exactly what noindex does.

Verified live 3 Aug. app.'s robots.txt disallows only /survey, /skills/, /workouts/, /achievements/ — /register/ and /login are NOT blocked, so Google can crawl them and will see a noindex on the next crawl. That is the good case; no robots.txt surgery needed.

1. Send X-Robots-Tag: noindex, nofollow on app./register/* (blanket). This also covers the live main routes /register/monthly_2026/ and /register/yearly3/ — that is intended: register and checkout pages should never rank.
2. Same header on app./login — an indexed /login URL is carrying a full GA linker blob (_gl / _ga / _ga_ZBQN3P8WKW, 71 impressions). Tracking parameters should never be crawlable.
3. Same header on app-test., quiz-test. and grafana-dev.. 🔴 grafana-dev. is a monitoring dashboard, publicly reachable, and was missing from the original scope — treat that as a security item, not an SEO one. quiz-test. was also missing.
4. monitor. already serves Disallow: /, but a Disallow does not de-index — it needs the header too.
5. Basic auth on the non-production hosts is the stronger fix — it de-indexes and stops anyone reaching them. Flag it if it would break a tester or CI workflow before applying.

noindex FIRST. Never add a robots.txt Disallow first. Blocking the crawl stops Google ever seeing the noindex, which freezes the URLs in the index as bare links — the opposite of the goal. Let them be crawled, see the noindex, and drop out. Only then consider disallowing.

No effect on the offers. Anyone with a direct link still reaches these pages and can still buy. noindex only removes them from search results.

curl -I on each host and route returns X-Robots-Tag: noindex, and the hosts plus the two promo URLs fall out of the TMA Search Console property within about two weeks.

v=spf1 a mx ip4:35.214.157.236 include:spf.tapfiliate.com
       include:themovementathlete.com.spf.auto.dnssmarthost.net
       include:_spf.google.com ~all

spf=permerror (google.com: permanent error in processing)

The two faults

1. include:spf.acemsb4.com does not exist. It is NXDOMAIN. Under RFC 7208 §5.2, an include: whose target has no SPF record returns permerror — and because SPF mechanisms evaluate left to right and stop at the first match, anything not matched earlier falls into it and never reaches ~all.

2. The one that actually matters: there is no include:_spf.google.com. The record leans on mx to cover Google, and that does not work:

# what "mx" authorises — Google's INBOUND servers
aspmx.l.google.com      172.253.145.26
alt1.aspmx.l.google.com 173.194.42.27
alt2.aspmx.l.google.com 142.251.96.27

# where Workspace actually SENDS from (_spf.google.com)
ip4:74.125.0.0/16   ip4:209.85.128.0/17

# overlap: none. So every hello@ / hi@ / nic@ send walks the whole
# record and lands in the dead include above.

Step 1 — replace the root SPF record

TMA's zone is authoritative at ns1/ns2.siteground.net, so this is the SiteGround DNS zone editor. If the Cloudflare migration has already moved the zone by the time you do this, do it there — the values are identical.

Edit the TXT record on themovementathlete.com whose value starts v=spf1. Leave every other TXT record alone (the google-site-verification and _globalsign ones must stay).

FROM:

v=spf1 a mx ip4:35.214.157.236 include:spf.tapfiliate.com include:themovementathlete.com.spf.auto.dnssmarthost.net include:spf.acemsb4.com ~all

TO — copy this exactly:

v=spf1 a ip4:35.214.157.236 include:_spf.google.com include:spf.tapfiliate.com include:themovementathlete.com.spf.auto.dnssmarthost.net ~all

Three changes: the dead include:spf.acemsb4.com is removed, include:_spf.google.com is added, and mx is dropped (it only authorised Google's inbound relays, which never send our mail — dropping it buys back a DNS lookup). Keep ~all, do not change it to -all this pass.

Measured lookup budget after this change: 7 of the 10 RFC 7208 allows.

Step 2 — fix the malformed record on the app subdomain

The TXT record on app.themovementathlete.com is missing a space before ~all, which makes it an include: of a domain that does not exist — a second permerror — and leaves the record with no terminal all at all:

# current — note "themovementathlete.com~all" is being read as one hostname
v=spf1 +a +mx +ip4:35.214.157.236 +a:spf.tapfiliate.com +a:tapfiliate.com +mx:spf.tapfiliate.com +include:spf.tapfiliate.com +include:themovementathlete.com~all

Replace the whole value with:

v=spf1 include:_spf.google.com include:spf.tapfiliate.com ~all

The +a: / +mx: mechanisms pointed at Tapfiliate were burning DNS lookups to authorise hosts that never send as app.. This takes it from 9 lookups saying nothing to 3 saying something true.

Step 3 — verify (do not skip; this is the part that proves it)

Wait for the TTL to expire, then confirm the record is actually being served and that the chain resolves clean:

# 1. the new record is live
dig +short TXT themovementathlete.com @1.1.1.1 | grep spf1

# 2. the dead include is gone and Google is present
dig +short TXT themovementathlete.com @1.1.1.1 | grep -c acemsb4      # must be 0
dig +short TXT themovementathlete.com @1.1.1.1 | grep -c _spf.google  # must be 1

# 3. the app subdomain
dig +short TXT app.themovementathlete.com @1.1.1.1

Then the real test — send one email from hello@themovementathlete.com to a Gmail address you control. Open it, Show original, and confirm the header now reads:

spf=pass ... smtp.mailfrom=themovementathlete.com
dmarc=pass (p=REJECT ...)

Send us that header block and the task closes. Until an spf=pass is seen in a real message, this is not done — a correct-looking record is not the same as a passing one.

Timeline — implementation + validation

~15 min to make the two record edits, +20 min to wait out the TTL, validate the values against the live zone, run the checks and send the test message. ≈35 min total. If the SiteGround panel disagrees with anything written above, trust the panel and tell us — these values were derived by resolving the live DNS from outside, not from inside your control panel.

What to do — two writes, one sitting

1. Server: at the quiz rail’s create-intent (the handler behind /payments/quiz-checkout/), copy the checkout_version the request body already delivers into the PaymentIntent metadata at create — the same write the sub already gets, one object earlier. Genuinely one line: the client half is verified already shipping.
2. Client: in the quiz checkout’s purchase-side events (dataLayer/gtag/fbq), send checkout_version:'quiz_checkout' alongside the quiz_variant the screen events already carry — same shape v3’s analytics.js emits, so both estates report identically.

How we will both know it worked

# 1. next real quiz sale — the PI itself carries the estate
stripe payment_intents list --limit 5   # newest quiz PI: metadata.checkout_version = quiz_checkout

# 2. the served bundle carries the stamp
curl -s https://quiz.themovementathlete.com/2026-quiz-checkout-v1/assets/index-*.js | grep -c checkout_version   # must be > 0

We re-run both checks the day you say it shipped — same as every card on this page.