Wednesday Launch Plan

Launch Wednesday only if the Tuesday 5:00 PM gate is green. The staging deployment proves the broad architecture can run, but it does not yet prove production configuration, manual migration, or the final admission boundary. If any hard gate remains unresolved Tuesday evening, move the launch rather than debugging identity or billing authority in production.

Desired outcome

Qualified Academy members sign in through Memberstack, receive the correct Prompt Studio or Full Automations result, and can purchase only through the approved native surfaces. Existing Profiles, credits, provider evidence, and history remain intact.

In scope

AiM-Apps Memberstack ingress, mirror, admission, access, credits, and Profile Slots
Theme Memberstack-native offer and launch surfaces
Production migrations, webhooks, settings, and exact Plan mappings
Private manual migration of the approved internal cohort

Out of scope

Restoring custom Stripe recurring membership authority
Deleting historical data, migrations, events, or provider objects
Automatic account merging or bulk legacy-to-Memberstack inference
Theme pause redesign and middleware database-relocation work

Launch principle

Configure from exact production identifiers, verify from current provider evidence, and fail closed on ambiguity. Email, Price IDs, legacy billing rows, browser returns, and plan names are not access authority.

Current readiness

The implementation base is strong, but the release gate is not yet complete. This is the short list that should drive Monday and Tuesday.

Hard blocker: release HITL remains open

Epic 28 Issue 0017 is still the required manual migration and prelaunch verification gate. The Theme’s coordinated release Issue 0012 also remains blocked on that evidence and operator approval.

Hard blocker: proposed admission gaps

The current prelaunch analysis identifies three code gates: enforce Academy confirmation before session/provisioning, include Bundles in login classification, and remove the Prompt Studio standalone bypass.

Decision: administrator inventory

Production contains four admin-marked accounts while the approved internal cohort is three. The fourth account needs a private, explicit disposition before the manifest is approved.

Risk: release candidate drift

Both repositories have active local work. Record immutable AiM-Apps and Theme commit SHAs and deploy only those candidates; do not deploy from a dirty checkout or “whatever is current.”

Risk: environment fan-out

Staging required separate Vercel, Supabase, Trigger.dev, Memberstack, Stripe, WordPress-option, origin, and webhook configuration. Production needs one reviewed ledger across all of them.

Not a blocker: Epic 26 Issue 0039

The open middleware story is an investigation with no runtime behavior change. Keep it out of Wednesday’s cutover unless a separate security review finds a concrete release defect.

Countdown schedule

Recommended windows are in Eastern Time. Shift the clock if needed, but preserve the dependency order and the Tuesday decision deadline.

Monday July 27 · T−2

Freeze the question set

Name the release operator, provider operator, Theme operator, and QA observer.
Approve the admission contract, including whether internal admins require Academy qualification.
Resolve the three proposed admission gaps in a focused story and run independent Standards and Spec review.
Identify the fourth admin-marked account privately and record its approved disposition.
Create the environment ledger with values sourced from production dashboards—not copied from staging by convention.
Choose immutable candidate SHAs for both repositories; inventory every migration after the current production frontier.

Tuesday AM July 28 · T−1

Close engineering and data gates

Run focused Vitest suites, relevant Supabase SQL suites, contract checks, TypeScript, PHP tests/PHPStan, and repository diff checks.
Run the guarded Supabase production migration dry-run against the exact expected production project reference.
Prepare pre-change row counts, checksums, migration history, active Profile/credit/slot inventories, and the private per-member migration manifest.
Review Trigger.dev environment behavior; decide whether Wednesday needs a Trigger deployment and whether production schedules are enabled.

Tuesday PM Dress rehearsal

Repeat the launch sequence on staging

Deploy the exact candidates and synchronize Theme PHP, built assets, and saved header/template state.
Read back every non-secret configuration value and a redacted presence/fingerprint for every secret.
Send signed provider test events to each staging endpoint; verify HTTP response, logs, journal row, projection, duplicate delivery, and retry behavior.
Run the minimum smoke matrix below with clean member states and record links to evidence.
Review the private migration manifest and preservation snapshot with the owner.

5:00 PM hard gate: every hard criterion must be green, with no “we’ll fix it during launch.” Otherwise, announce the slip and preserve the candidate for the next window.

Wednesday July 29 · launch

Recommended 8:30 AM–12:00 PM window

8:30: confirm operator availability, provider health, backups/preservation evidence, candidate SHAs, and clean deployment sources.
9:00: apply additive Supabase migrations with the guarded production script; verify the remote migration frontier.
9:15: deploy AiM-Apps with the reviewed production environment.
9:30: deploy Trigger.dev only if the candidate requires it; verify profile/account and schedule registration.
9:45: deploy the Theme candidate and synchronize assets/templates; read back WordPress configuration.
10:00: create or update production webhook endpoints, capture each new signing secret once, and verify delivery.
10:20: perform the approved manual internal-cohort migration and exact account linking.
10:40: run smoke tests, compare preservation evidence, and make the final traffic decision.
11:00–12:00: hold the launch room open for first-hour monitoring and remediation.

Production configuration ledger

Store actual values and fingerprints in a private operator document. This public-safe runbook names the required surfaces without including secrets, member identifiers, or private URLs.

Surface	Required configuration	How to verify	Owner / gate
AiM-Apps origins	`NEXT_PUBLIC_APP_URL`, Academy base, upgrade destination, optional support destination, cookie domain	Read rendered origins; verify HTTPS, host, callback/return destination, and no staging host	App operator · before deploy
Supabase	Exact production URL, public key, service-role key, linked project reference	Project-ref guard, migration list, one bounded read, no key disclosure	Database operator · hard gate
Memberstack app	Public client key, server secret, App ID, exact Academy monthly/annual, Automations, internal, and Bundle Plan IDs	Read back App ID and sorted Plan-ID fingerprints; test exact `ACTIVE`/`TRIALING` classification	Provider + app operators · hard gate
AiM-Apps Memberstack webhook	Production endpoint, Svix signing secret, five lifecycle event types	Signed delivery, 2xx response, durable claim/journal, current provider reread, mirror update, duplicate replay	Provider operator · hard gate
Stripe retained lanes	Live secret/public keys, AiM-Apps webhook secret, exact Profile Slot Product/Price/cadence/amount/currency	Read endpoint events and API version; signed test delivery; verify membership events cannot grant access	Provider + app operators · hard gate if Slots launch
Trigger.dev	Correct project/profile, production Supabase credentials, required app secrets, `SCHEDULED_TASKS_ENABLED`	Read deployed version and registered schedules; inspect one bounded run/skip result	Worker operator · before traffic
Outbound email safety	`OUTBOUND_EMAIL_ENVIRONMENT`, application email URL, production delivery approval	Confirm intended direct-vs-QA behavior before Trigger deploy; never let a billing launch silently arm unrelated campaigns	Release owner · explicit decision
Theme origin and catalog	`AIM_APPS_URL`, Memberstack admin secret, exact Plan/Price catalog settings	Read server-rendered opaque launch targets and cohort offer; verify no stale local/staging origin	Theme operator · hard gate
Theme webhooks/options	Theme Memberstack and Stripe endpoints and their matching WordPress signing-secret options	Signed delivery, Theme-local logs/side effects, duplicate behavior, no AiM-Apps snapshot forwarding	Theme + provider operators
Authentication safety	Internal Supabase auth and legacy WordPress bridge disabled unless separately approved	Read configuration; negative login tests prove no legacy admission bypass	App operator · hard gate

Webhook rule: endpoint creation may be automated through provider APIs, but the operation must capture the signing secret once, write it to the matching deployment surface, redeploy or refresh as required, send a signed event, and read back endpoint status. Creating an endpoint without proving the secret/receiver pair is not completion.

Production launch order

This order keeps schema ahead of code, backend authority ahead of customer presentation, and provider events behind verified receivers.

Freeze candidates + config Snapshot preservation evidence Apply migrations Deploy AiM-Apps Deploy workers Deploy Theme Activate webhooks Migrate pilot cohort Smoke + open traffic

Freeze the release record. Record both candidate SHAs, build/deployment IDs, migration frontier, operator names, and the approved scope. Confirm all unrelated dirty work is excluded.
Capture preservation evidence. Take pre-change counts/digests for accounts, Profiles, credits/top-ups, billing/provider history, work, support evidence, mirrors, links, and Profile Slot bindings.
Apply migrations with an exact project guard. Use the repository’s production migration script with the expected project reference. Stop on any unexpected pending migration or history divergence.
Deploy AiM-Apps. Verify health, configuration presence, Memberstack session exchange, safe billing reader, and that removed custom recurring routes remain unreachable.
Deploy Trigger.dev only when required. Confirm the account/profile and review the environment sync. Verify the credit-month and Profile Slot maintenance schedules are intentionally enabled or intentionally stopped.
Deploy the Theme candidate. Synchronize PHP, compiled assets, dependency manifests, and saved template/header state. Purge relevant caches before browser acceptance.
Configure provider endpoints. Point Memberstack directly to AiM-Apps for lifecycle projection and retain the Theme endpoint for Theme-local behavior. Configure Stripe only for the retained financial/Profile lanes.
Prove webhook delivery. For each endpoint, record provider delivery ID, event type, timestamp, response code, application log correlation, journal/claim state, and resulting projection. Replay one exact event.
Migrate the approved pilot/internal cohort. Use authenticated linking and exact current provider evidence. Do not email-match, auto-merge, or manufacture mirror state from legacy rows.
Run smoke tests and compare evidence. Open customer presentation only after the backend results, Theme surfaces, history preservation, and negative-authority checks agree.

Immediate stop conditions: wrong project/account, unexpected migration, secret mismatch, webhook 4xx/5xx, duplicate account/Profile creation, unexplained access expansion/loss, stale Theme assets/templates, missing first credits, or any need to restore custom Stripe recurring authority.

Minimum launch smoke matrix

Run with dedicated approved test identities. Record expected and actual results, timestamps, deployment IDs, and evidence links in the private launch record.

Scenario	Expected result	Evidence
Academy-only, exact eligible Plan	Application session succeeds; free Prompt Studio is usable; Automations upgrade is presented	Session result, mirror row, Profile balance, Theme surface
Eligible Bundle	One connection independently grants Academy and Automations; no synthetic second connection	Provider read, mirror, access result, Theme launch
Automations/internal-only without Academy	Follows the approved admin/admission decision; no accidental general-member bypass	Session response and policy log
Unknown Plan, Price lookalike, or non-qualifying status	No Academy/Automations authority; no account/Profile mutation before admission	Negative response and before/after counts
Existing exact account link	Reuses account and Profile; refreshes mirror idempotently	Stable IDs and row counts
Conflicting link	Fails closed, creates durable support follow-up, does not block other members	Typed response and support evidence
New eligible Automations member	Full access and base Profile credits converge immediately; no 15-minute first-use gap	Mirror, binding, Credit Month, ledger, spendable balance
Native checkout return	Return navigation triggers fresh reconciliation; URL/browser state does not prove payment	Fresh provider read and post-return UI
Cancellation or payment failure	Access revokes from verified state; new work stops; history and admitted work semantics remain	Webhook claim, Access Version, admission result
Profile Slot increase and decrease	Exact quantity 0–2, permanent binding, immediate usable Profile, safe inactivation on decrease	Stripe item, reducer, binding, Profile/credit state
Duplicate/retry/out-of-order lifecycle event	Exact replay is idempotent; conflicting digest fails closed; current provider state wins	Provider delivery and journal/claim rows
Theme presentation	Sidebar, campaign, profile, and dashboard surfaces use the same server model and opaque intents	Desktop/mobile browser capture and console check

Rollback and containment

This is a forward authority cutover. Rollback means containing traffic and restoring known-good application presentation—not reviving the removed billing authority or erasing evidence.

Presentation failure

Contain at the Theme edge

Restore the known-good Theme release or suppress the affected customer entry surface. Keep Memberstack and AiM-Apps authority intact while the UI is corrected.

Application failure

Restore code, preserve schema

Roll AiM-Apps back to the reviewed compatible deployment. Do not reverse additive migrations or delete journal/mirror rows. Pause new migration actions and re-run health checks.

Provider ingress failure

Pause delivery, retain events

Pause or disable the affected endpoint without deleting it. Preserve provider delivery history and signing-secret evidence, repair the receiver pair, then replay safely.

Worker failure

Stop schedules explicitly

Set SCHEDULED_TASKS_ENABLED=false in the affected deployed worker environment and verify skip behavior. Preserve queued/admitted work according to its existing run contract.

Identity ambiguity

Fail closed per member

Do not merge by email or infer from legacy records. Leave the member inaccessible or Prompt Studio-only as the approved policy requires, and create a durable support follow-up.

Forbidden rollback

Never restore old authority

Custom Stripe recurring entitlements, overrides, security blocks, legacy pro, Profile Plans, credits, and browser state remain non-authoritative.

Monitoring and launch completion

First 60 minutes

Webhook response codes, latency, retries, signature failures, and journal conflicts
Memberstack provider-read failures and stale-mirror refresh outcomes
Application session success/failure by safe reason code
Access Version grants/revocations and unexpected cohort changes
Duplicate account/Profile creation and account-link conflicts
Immediate base-credit grants and Profile Slot reducer/repair activity
Theme JavaScript errors, stale assets/templates, and broken destinations

End of day and next morning

Re-run row counts/digests and migration-history checks
Review every migrated member against the private manifest
Review scheduled credit-month and Profile Slot maintenance runs
Confirm no historical authority path produced a grant or denial
Classify every support incident and every provider retry
Record launch decision, deviations, deployment IDs, and follow-ups

Definition of launched The release is complete only when the approved cohort is accounted for, production webhooks are observably converging, the smoke matrix passes, preservation evidence matches, customer-facing Theme and AiM-Apps behavior agree, and the owner signs the final launch record. “Deployed” by itself is not “launched.”

Decisions to close before Tuesday’s gate

Decision	Recommended default	Deadline
Must internal administrators also be Academy-qualified?	Yes, unless an explicit exact internal admission rule is approved and tested	Monday before implementation freeze
What happens to the fourth admin-marked production account?	Remove admin only after private identity verification and owner approval; never infer from count alone	Before manifest approval
Does Wednesday include additional Profile Slot purchasing?	Include only if live Stripe Product/Price/webhook/schedule evidence passes; otherwise hide/defer the customer action	Tuesday noon
Does Wednesday require a Trigger.dev production deploy?	Only if the release candidate or schedule definitions require it; explicitly review email-delivery side effects first	Tuesday rehearsal
Who has final go/no-go authority?	One named release owner, informed by app, Theme, provider, data, and QA evidence	Monday

Repository basis and assumptions

Confirmed from current repository state

Epic 28 implementation stories 0001–0016 are recorded done; Issue 0017 remains the HITL release frontier.
The governing validation matrix blocks production on manual migration and joint Theme evidence.
The Theme’s coordinated release ticket remains blocked pending current AiM-Apps evidence and operator approval.
Memberstack lifecycle ingress accepts five signed member/plan event types and rereads current provider state.
Stripe remains authoritative only for retained Profile financial lanes, not recurring Academy/Automations access.
Trigger schedules default enabled in deployed environments unless explicitly disabled.

Assumptions to verify live

Wednesday means July 29, 2026, in Eastern Time.
The staging experience described by the owner is the latest deployed evidence.
No production provider objects or secrets have yet been changed for this cutover.
The production Memberstack source is accessible to an authorized operator before the Tuesday gate.
The exact production deployment mechanism for the Theme will reuse the proven staging process with a different destination.

Source set: Epic 0028 release story and validation matrix; the proposed Academy admission/prelaunch plan; Profile Slot and new-member credit handoffs; Epic 0026 current frontier; Theme Epic 0002 and its coordinated release gate; current environment examples, webhook handlers, migration guard, and schedule guard.