Sprint plan — T-2 launch window (2026-05-21 → 2026-05-30 UTC)

Owner: Kristerpher Produced: 2026-05-21 UTC Sprint window: 2026-05-21 00:00 UTC → 2026-05-30 23:59 UTC Launch gate: 2026-05-23 UTC Epics in scope: #78 #79 #80 #81 epic:launch-readiness State at planning: 13 open pre-launch-blocker, 7 ready-for-dev, 11 open PRs (10 docs awaiting review, #2636 conflicting)

Capacity assumptions

Sprint A — T-2 to launch (2026-05-21 → 2026-05-23 UTC)

Hard definition: every item here is a launch gate. If it does not close, launch slips or ships with a known critical gap.

A1 — #2636: Broker-key rename hard cutover (SC-ERR-3)

• Owner: feature-dev
• Confidence: HIGH — PR already written, conflict is minor (one package.json line per its own body)
• Action: rebase onto main, resolve conflict, merge
• Dependency: #2634 and #2635 both merged — dependency satisfied as of 2026-05-20/21 UTC
• Why it gates launch: Customer-visible API responses still contain alpaca_api_* keys. Ships vendor name in prod JSON. Per feedback_no_backend_branding this is a pre-launch blocker.
• Risk: Trivial conflict on package.json test script line. Mitigation: conflict is documented in PR body; resolution is a two-line cherry-pick or manual merge.

A2 — #2648 (PR): Flag-promotions backfill script merge

• Owner: operator (review + merge) / feature-dev (already built)
• Confidence: HIGH — PR is mergeable, 24 unit tests passing, dry-run validated
• Action: Kristerpher reviews PR #2648, approves, merges; then runs --dry-run on prod; then --apply
• Dependency: None. PR is ready. Operator execution step needed post-merge.
• Why it gates launch: Without this backfill, the flag reconciler drift kill-switch sees all 64 pre-existing FLAG_* rows as synced=false and will disable the flag promotion UI on day one.
• Risk: Script touches DB directly. Mitigation: --dry-run is mandatory first step; --apply requires --confirm flag; script is read-only against Heroku.

A3 — #2641 / #1023: Set Alpaca paper-mode env vars on raxx-api-prod

• Owner: operator (Kristerpher) — Heroku config:set; SRE verifies
• Confidence: HIGH — straightforward config:set; SRE already in flight per brief
• Action: Set ALPACA_API_KEY, ALPACA_API_SECRET, ALPACA_BASE_URL (paper) on raxx-api-prod; silence stdout per feedback_heroku_config_set_echoes_secrets
• Dependency: None; SRE config:set wave already in flight
• Why it gates launch: Trading routes fail auth without these vars. Paper-mode is v1; live-mode fallback is blocked by absent creds.
• Risk: Wrong key scope (live vs paper). Mitigation: double-check ALPACA_BASE_URL=https://paper-api.alpaca.markets before apply.
• Note: #2641 and #1023 are duplicate cards tracking the same action. Both close on execution.

A4 — #2601 / #1022: Verify WEBAUTHN_ORIGIN on raxx-api-prod

• Owner: SRE / operator; SRE already in flight per brief
• Confidence: HIGH — SRE wave already executing; this is a verification step
• Action: Confirm WEBAUTHN_ORIGIN=https://raxx.app set on raxx-api-prod; run smoke test to verify passkey registration endpoint responds 200
• Dependency: None
• Why it gates launch: WebAuthn origin mismatch causes all passkey registrations to fail. Reproduces the 2026-05-20 staging incident on prod if not verified.
• Risk: Env var set but from_mapping() gap (see #2600). Mitigation: smoke test login flow end-to-end, not just env check.

A5 — #2642 / #1026: Enable FLAG_SENTRY_BACKEND + verify SENTRY_DSN_FRONTEND

• Owner: SRE / operator; SRE already in flight per brief
• Confidence: HIGH — one config:set + one smoke event
• Action: heroku config:set FLAG_SENTRY_BACKEND=1 >/dev/null on raxx-api-prod; trigger a test error; verify event appears in Sentry dashboard
• Dependency: None; Sentry integration already partially shipped
• Why it gates launch: Without Sentry active, production errors on day one are invisible. First customer bugs would be undetected.
• Risk: SENTRY_DSN missing from vault for frontend build — if REACT_APP_SENTRY_DSN was not injected at last Antlers build, frontend errors will silently drop. Mitigation: re-deploy Antlers if DSN was absent.
• Note: #2642 and #1026 are duplicate cards; both close on execution.

A6 — #2600: Audit flag-gated startup validators in create_app()

• Owner: feature-dev (qa-agent assist)
• Confidence: MEDIUM — audit + fix; size:s but could surface surprises
• Action: Enumerate all validate_*_config() calls in create_app(); cross-check each key read against from_mapping(); file or fix any gap before launch
• Dependency: #2601/#1022 (WebAuthn incident) — the incident that spawned this card is now fixed; this card prevents siblings
• Why it gates launch: A second WebAuthn-style boot failure on a different subsystem (Sentry, Alpaca, Queue) on launch day would cause an outage.
• Risk: Audit finds a gap that requires a code change, delaying close. Mitigation: if audit is clean (no gaps), card closes same-day. If gaps found, they are likely 1-2 line from_mapping() additions.

A7 — #2637: Fix test_mark_synced_kill_switch_2013 for post-#2616 chain

• Owner: feature-dev
• Confidence: HIGH — fix is documented in the issue body (commit a773b781); 4-line change
• Action: Apply documented migration-test fix (rename class, bump migration refs from 0099→0100, update downgrade target)
• Dependency: None; fix was prepared by SRE, push was blocked by bot token scope
• Why it gates launch: CI is broken on main for console tests. A broken test gate means future merges either skip CI or merge blind.
• Risk: Very low — fix is fully documented.

A8 — #2619: SC-D12 troubleshooting.md content for v1

• Owner: feature-dev (docs write)
• Confidence: MEDIUM — five scenarios to author; depends on #479 broker rejection surface decision
• Action: Write five troubleshooting scenarios into docs/customer/troubleshooting.md; remove draft: true; for broker rejection codes, if #479 is not shipping at v1, remove that TODO and describe the general Orders panel flow instead
• Dependency: Depends on #2636 being merged first (broker-key rename affects how "broker connection" errors are named in docs)
• Why it gates launch: docs.raxx.app launches at v1. A draft: true page with unresolved TODOs is not shippable customer-facing content.
• Risk: #479 ambiguity. Mitigation: broker rejection codes surface (#479) is not ready-for-dev and has no Sprint A slot — treat it as v1.1 and write the Orders panel fallback description instead.

A9 — #2621: SC-D14 noindex flip + marketing footer + README link

• Owner: feature-dev
• Confidence: HIGH — mechanical change, two-line edit
• Action: Flip X-Robots-Tag in frontend/docs/_headers; add docs.raxx.app link to marketing footer and README
• Dependency: SC-D11 (merged), SC-D13 (merged), SC-D12 (#2619 — must close first); this is the final gate card
• Why it gates launch: docs.raxx.app is invisible to search engines and not linked from the product until this merges. Must be the last docs merge before launch declared.
• Risk: If merged before #2619, docs will be indexed with a draft page. Mitigation: merge order is enforced — A9 depends on A8 closing.

A10 — #1025: Remove CF Access gate from raxx.app + api.raxx.app

• Owner: operator (Kristerpher) — Terraform apply requires vault credentials
• Confidence: HIGH — runbook exists at docs/ops/runbooks/getraxx-launch-day-cf-access-removal.md; operator-only execution
• Action: Run the Terraform destroy sequence from the runbook on launch morning (2026-05-23 UTC); verify curl -I https://raxx.app/ returns HTTP 200 without CF Access redirect
• Dependency: All A1–A9 should close first; this is a launch-day gate
• Why it gates launch: raxx.app behind CF Access = real customers see a login wall, not the product.
• Risk: Terraform state drift since PR #1643. Mitigation: run terraform plan -destroy first; review plan output before applying.
• Note: Also covers the noindex removal from #1628 (noted in #1645).

Sprint A items NOT included (and why)

Sprint B — v1.1 / first post-launch week (2026-05-24 → 2026-05-30 UTC)

These are the highest-value cards once the launch gate is closed. Ordered by impact tier.

Tier 1 — Revenue + compliance (ship within 3 days of launch)

Tier 2 — Founders Promo wave (ship once Hinch Newman engagement confirmed)

See architect PR #2609 for the reconciliation design that gates this wave.

Tier 3 — Tax-strategy v1 (informational top 5 — BLR-safe per PR #2639)

Operator decision: v1 ships informational-only. No recommendation or execution logic in v1.1.

These 5 tax-feature cards need PM filing before feature-dev dispatch. Flagged below as an operator decision.

Tier 4 — Velvet UI cluster (operator-gated deferral confirmed in PR #2611)

Tier 5 — Docs + error chain completers

Tier 6 — MBT post-engagement copy revision

WAF timeline reality check

The locked operator decision (WAF launches in Phase 1 log-only mode; challenge→block soak post-launch) is correct and is reflected in the sprint plan. The soak math for prod is:

• Phase 4b (challenge): 48-hour soak — earliest finish 2026-05-25 UTC if started immediately post-launch
• Phase 4c (block): 7-day soak — earliest finish 2026-06-01 UTC

FLAG_ENFORCE_CF_ORIGIN (#1741) cannot flip before 2026-06-01 UTC at the earliest. This is accepted risk. Prod WAF is in log-only mode; attacks are visible in Logpush but not blocked at edge until the soak completes.

Operator decisions for Monday morning (2026-05-21 UTC)

These are explicit decision points where the PM cannot make a clean call from existing locks. Operator input required before downstream agents can proceed.

Decision 1 — Tax-feature Sprint B cards: file now or defer to post-launch planning session?

The 5 BLR-safe informational tax features are confirmed for v1.1 per the locked operator decision and PR #2639. They need PM-filed cards before feature-dev can pick them up. Recommendation: greenlight PM filing of the 5 cards immediately post-launch (2026-05-24 UTC). If Kristerpher wants them filed today, say so and PM will file in the same session.

Decision 2 — #197 MBT attorney: what is the current engagement status?

As of the T-9 sprint plan (2026-05-15 UTC), attorney engagement was listed as a pending operator action. Has the Antonakakis/Lex Nova engagement been initiated? If attorney signal has not arrived by 2026-05-22 12:00 UTC, MBT v1 GA slips to v1.1 and the pre-launch-blocker label should be removed from #197 (it already is not blocking core Raxx v1, only MBT v1 GA).

Decision 3 — #1632 Stripe: EIN + out-of-test-mode timeline?

The Stripe Price ID backfill depends on the Stripe account being out of test mode. Is the EIN application in flight? What is the expected Stripe account approval date? Without this, #1632 cannot execute and founders subscribers will have null stripe_price_id until post-Sprint-B.

Decision 4 — #2636 rebase: can feature-dev proceed autonomously or does Kristerpher want to review the conflict resolution?

The conflict is documented as trivial (one package.json line). PM recommends autonomous rebase + merge by feature-dev without operator review. Confirm.

Single biggest schedule risk

MBT attorney engagement (#197). If Antonakakis or Lex Nova have not been contacted as of 2026-05-21 UTC and the engagement takes the typical 3-5 business days to produce a written review, MBT v1 GA cannot ship in Sprint B. MBT is not blocking core Raxx v1 (the launch gate is independent), but it is a revenue-impacting feature that Founders-tier customers are expecting.

Mitigation: Kristerpher makes first contact with the attorney referral today (2026-05-21 UTC). Even a scoped "is this 4 hours of review or 2 days?" call clears the ambiguity. PM brief is at PR #2633.

Label update plan

Cards moving to Sprint A (sprint:t-2-launch label):

• 2636, #2648, #2641, #1023, #2601, #1022, #2642, #1026, #2600, #2637, #2619, #2621, #1025

Cards moving to Sprint B (sprint:v1.1 label):

• 2285, #2283, #2282, #1632, #231, #232, #949, #952, #953, #954, #197

Note: sprint:t-2-launch does not yet exist as a GitHub label — it will be created as part of this sprint plan publication.