Raxx v1.0 Production Release — Ship Plan

Authored: 2026-05-04 UTC
Owner: Kristerpher
Status: Operator review required before Wave 1 dispatch
Parent epic: #94 Production Release v1.0

1. What v1.0 Means

Raxx v1.0 is not a feature-completeness milestone. It is a trust milestone.

The product thesis (from memory: project_structure_gap_thesis.md, project_strategic_position.md): Raxx fills the structure gap — it enforces the entry/credit/exit structure the user already decided on, before emotion gets a vote. That is not an AI product and it is not an Alpaca product. It is an automation layer that the user controls, backed by their own broker.

Three things must be true on launch day:

1. A real user can self-onboard. Kristerpher can walk through raxx.app as a first-time visitor, hit the same door every customer will hit, connect a paper-trading broker account, and have a working dashboard. The operator shortcut path is not launch.

2. MBT v1 (securities-only) is shippable and stable. This is the launch flagship per #256. Options-backtest stays gated behind ENABLE_OPTIONS_BACKTEST=false. The backtesting and trading surfaces are polished — not prototypes.

3. The operator can run the platform safely. Token rotation does not fail silently (#907). Deploys are traceable (#731). The console shows real status for every surface (#146). The operator is not manually SSH-ing or running ad hoc heroku config:set to recover from incidents.

What v1.0 explicitly is NOT:

• Paying customers (no Stripe integration required for launch)
• Full RBAC / SAML / Workspace OIDC cutover (Phase 2)
• iOS companion (#167 — post-v1.0)
• AI-assisted trading (#80 — post-v1.0)
• Billing console for customer revenue (#403 — post-v1.0)
• Multi-tenant Alpaca architecture (#183 — post-v1.0)
• Options backtesting (#256 gate — blocked on ORATS licensing)
• Obfuscate mode, advanced analytics, Founders promo mechanics (#204 — post-v1.0)

The epic #94 was written when the platform was "runs on my laptop." The intent is unchanged but the scope is now larger. The original #94 scope (Heroku deploy, docs site, marketing site, platform live) is subsumed into the wave structure below.

2. Epic Categorization

2a. Critical Path — must ship before public launch

These epics block the first real user from self-onboarding or the operator from running the platform safely.

2b. Launch-Window — ship in first 30 days post-launch

Not blocking first user, but needed before the platform feels complete for early adopters.

2c. Post-v1.0 — defer; not required for first paying customer

Note on #148 and #161: per memory feedback_human_to_human_drive.md, attorney-bound items get separate handling and must not block engineering work that can proceed independently. Entity formation and NDA portal are on a parallel legal track; the engineering wave plan does not wait on them.

3. Critical-Path Wave Sequence

Four waves of parallelizable work. Each wave is a logical grouping of work that can be dispatched simultaneously once its prior-wave gate is cleared. Wave duration is in feature-dev-days, defined as one agent-fleet working day (single developer + agents; no external team).

Wave 1 — Platform Foundation (Days 1–6)

Theme: Get the infrastructure layer safe so every subsequent wave can ship without incident.

Gate: Wave 1 must be complete before Wave 2 dispatches. These are the pre-conditions for everything else.

Dependencies: None — Wave 1 is the root.
Pending input: #988 architect output (in flight — do not block Wave 1 start; proceed with Velvet and Market Calendar in parallel while design resolves).
Estimated duration: 5–6 feature-dev-days.

Operator decisions required before Wave 1 dispatches:

• [ ] OQ4 (Velvet): Partial distribute threshold — block all if any consumer fails, or per-consumer required: true/false flag? Current design blocks all; recommend Option B (per-consumer flag) so a low-priority consumer failure does not block a critical Heroku rotation.
• [ ] OQ5 (Velvet): Force-revoke authorization — single-operator confirm, or 4-eyes? Option A (single operator with type-to-confirm) is appropriate for a solo-operator platform at v1.0.
• [ ] OQ7 (Velvet): Cloudflare token rotation — Velvet-guided manual flow (Option A) vs OPERATOR_MANUAL form (Option B)? Subscription manifest has CF entry as active: false pending this decision.
• [ ] OQ9 (Velvet): rotation_leaked escalation — Slack alert only (current design), or auto-FreeScout ticket too? Recommend Option B for a solo operator (fewer places to check).
• [ ] #988 architecture decision: CF Pages edge worker approach (Option A) vs cross-env polling approach — architect output pending. Kristerpher reviews and approves the approach before the card is dispatched to feature-developer.
• [ ] #987 operational action: CF_PAGES_DEPLOY_TOKEN expiry — operator must manually rotate this token before Wave 1 CI is reliable. This is a same-day operator action, not a feature card.

Wave 2 — Rotation Completion + Console Stability (Days 7–12)

Theme: Velvet is functional for real rotations; console is a stable operator surface.

Gate: Wave 1 complete (Velvet scaffold live, B3 service bus shipped, #731 deploy flow working, #988 web layer shipped).

Dependencies: Wave 1 complete.
Pending input: #984 FreeScout module install research (in flight — if the right install path is confirmed, cards dispatch; if blocked, FreeScout module work moves to interim and the email-pipeline portion of #707 proceeds without it).
Estimated duration: 5–6 feature-dev-days.

Operator decisions required before Wave 2 dispatches:

• [ ] OQ2 (Velvet): Healthcheck timeout per consumer — 15s uniform (Option A) or per-consumer configurable (Option B)? This is a B3 card but resolving it now prevents a later manifest format change. Recommend Option B; it is a YAML field addition, not an API change.
• [ ] OQ3 (Velvet): Distribute fan-out — parallel with max_concurrency=4 (current design) or sequential? Recommend parallel; Heroku dyno restarts triggered by config-var PATCH are expected and intentional.
• [ ] #984 resolution: Once the FreeScout module install research returns, Kristerpher approves the proposed install path (artisan command vs direct DB vs SSH) before feature-developer dispatches the fix card.

Wave 3 — Customer-Facing Surfaces (Days 13–20)

Theme: The surfaces a customer actually touches. Self-onboarding works. Marketing site is live. Status page is up.

Gate: Wave 2 complete (Velvet rotation is functional and safe; console is stable; FreeScout email pipeline is green).

Dependencies: Wave 2 complete. For #581: #707 must be at email-pipeline-green before the FreeScout ticket-mirror feature is built.
Estimated duration: 6–8 feature-dev-days (largest wave; most customer-facing work).

Operator decisions required before Wave 3 dispatches:

• [ ] #582 attorney gate: Privacy Policy and ToS copy requires attorney review before the noindex header is removed. This is on the legal track (parallel), not an engineering blocker — but Kristerpher must confirm attorney approval has been received (or explicitly decide to launch with placeholder copy under a named risk). Do not allow this to block the engineering work; file the copy in docs/legal/ and await attorney sign-off.
• [ ] #469 broker connect UX decision: Onboarding Wizard broker-connect step — paper trading only at v1.0 (Alpaca paper), or does it also offer live account connection? If live, what's the copy when no live credentials are present? Decision needed before the wizard's broker-connect card is written.
• [ ] #256 options-backtest copy decision: The "coming soon — data licensing in progress" panel text needs approval before #256 ships. Options-backtest gate is already in the epic; operator approves the user-facing message.

Wave 4 — Launch Gate + Go-Live (Days 21–26)

Theme: Every critical-path item is shipped and smoke-tested. The noindex header is removed. The waitlist is open.

Gate: Wave 3 complete. All critical-path acceptance criteria pass. Attorney sign-off on marketing copy received.

Dependencies: Wave 3 complete.
Estimated duration: 4–5 feature-dev-days.

Operator decisions required before Wave 4 dispatches:

• [ ] Go/no-go call: Kristerpher does a personal walkthrough of the self-onboarding flow on staging before Wave 4 begins. If rough edges remain, they are explicitly triaged as "fix now" vs "fix in first 30 days." No external users see the platform until this call is made.
• [ ] #148 / #161 status: Business formation and NDA portal are on a parallel legal track. Before the noindex header is removed and the waitlist goes live, Kristerpher confirms whether entity formation is complete (or explicitly accepts the risk of launching as a sole proprietor / personal IP holder). This is not a code dependency.

Total estimated duration: 21–26 feature-dev-days

With a solo developer plus agent fleet at current velocity, this maps to approximately 5–7 calendar weeks assuming no major architectural re-work.

4. Operator Decisions Master List

Every decision below has a wave dependency. The "blocks" column shows which wave cannot start (or cannot close) until the decision is made. Decisions are ordered by urgency.

Immediate (before Wave 1 dispatches)

Before Wave 2

Before Wave 3

Before Wave 4

5. In-Flight Work Mapped to Waves

#988 Console self-deploy web layer (architect designing, in flight)

Wave assignment: Wave 1 (output gates Wave 1 #731 sub-cards).
Status: Architect has the design brief; three options enumerated (CF Pages edge worker, cross-env polling, other). Design output expected before Wave 1 dispatches.
Action: Do not block Wave 1 on this. Start Velvet (#908) and Market Calendar (#270) immediately. When the architect returns the design, Kristerpher approves the approach and #731 cards dispatch in parallel.
If delayed past Wave 1: #731 deploy flow ships without the self-deploy web layer; the operator accepts the "kicked off the platform on self-deploy" behavior until Wave 2.

#907 Velvet (fast-track plan confirmed, in flight)

Wave assignment: Wave 1 (B1–B5, B10) + Wave 2 (B6–B9, B12–B13) + Wave 4 (B11, B14, B15).
Status: Design locked 2026-05-03. Subscription manifest committed. ADRs 0037–0040 filed. B1 (#908) is the immediate first card.
Action: Dispatch B1 (#908) as soon as OQ4, OQ5, OQ7, OQ9 decisions are made (D2–D5 above). These are the only pre-conditions for B1.
Open questions still blocking B3 specifically: OQ1 (static manifest only — current design is locked per ADR-0040; no decision needed unless Kristerpher wants to reopen), OQ6 (testing flow audit logging — propose Option A: log with label; no decision needed unless Kristerpher disagrees).

#984 FreeScout module install redesign (research in flight)

Wave assignment: Wave 2 (FreeScout module fix), but #707 email-pipeline work in Wave 2 can proceed without the module fix.
Status: Research dispatched 2026-05-04. FreeScout instance is rebuilt (54.146.13.200). Ten paid modules are unattributed; correct install procedure under investigation.
Action: If research returns before Wave 2 dispatch, include the fix card in Wave 2 alongside #707. If research is still unresolved at Wave 2 dispatch, ship #707 email-pipeline work and tag the module install as an interim operational gap tracked separately. Do not hold the full #707 epic for module attribution.
Risk: If modules require a specific install path (e.g., SSH access, specific artisan invocation), the research output may generate a new card rather than a simple fix. Wave 2 scope absorbs that card.

6. Epic Dependency Graph (critical path only)

Wave 1 (Days 1-6)
  #908 Velvet scaffold ──────────────────────────────────────────┐
    └─ B2 DB schema                                              │
        └─ B3 Service bus core ───────────────────────────────── ├─ Wave 2
            ├─ B4 Postmark adapter (Wave 1 proof)                │
            └─ B5 Heroku adapter (Wave 1)                        │
  #988 Self-deploy design ──────────────────────────────────────┘
    └─ #731 Console deploy flow (Wave 1 close / Wave 2 start)
  #270 Market Calendar v1 (Wave 1, independent)
  #925 GH token provision (Wave 1, immediate, independent)

Wave 2 (Days 7-12)
  B6 GH Actions adapter ──────────────────────────────────────── ┐
  B7 Stage-wizard UI ─────────────────────────────────────────── ├─ Wave 3
  B8 CF DNS adapter ──────────────────────────────────────────── │
  B9 Revocation flow ─────────────────────────────────────────── │
  #146 Console stability ──────────────────────────────────────── │
  #798 Flag promotion flow ────────────────────────────────────── │
  #707 FreeScout email pipeline ──────────────────────────────── ┘

Wave 3 (Days 13-20)
  #256 MBT v1 polish ─────────────────────────────────────────── ┐
  #469 Onboarding Wizard ──────────────────────────────────────── ├─ Wave 4
  #582 getraxx.com readiness ──────────────────────────────────── │
  #581 status.raxx.app ────────────────────────────────────────── ┘

Wave 4 (Days 21-26)
  Smoke testing → go/no-go → noindex removal → waitlist open

7. Epics Explicitly Superseded or De-Duplicated

The following epics should be commented on and closed after the named replacement ships:

Kristerpher should not dispatch any work against #417 or #253. They are dead epics as of the Velvet v2 design lock.

8. Solo-Developer Constraint Notes

All sequencing above assumes: - One developer (Kristerpher) reviewing and approving agent-output PRs - Agent fleet (architect, feature-developer, card-groomer) operating on isolated worktrees - PRs branch from main per memory feedback_pr_base_main.md - No external team members; all decisions are Kristerpher's

Practical implications: - Wave 1 can dispatch multiple parallel cards simultaneously (Velvet B1, #988 design, #270, #925) without blocking — the agent fleet handles parallel execution - The bottleneck is Kristerpher's PR review queue. At peak parallelism (Wave 2, ~4–5 open PRs simultaneously), review cadence is the critical path, not the engineering work itself - Recommend: batch PR reviews at 2x daily rather than reviewing each immediately; this keeps agent throughput high without context-switching overhead

9. Immediate Actions for Kristerpher (Today, 2026-05-04 UTC)

In priority order:

1. Rotate CF_PAGES_DEPLOY_TOKEN (#987) manually in the CF dashboard. Enter new value in Infisical. This unblocks internal-docs deploys and is a 10-minute operator task.

2. Make OQ4, OQ5, OQ7, OQ9 decisions (D2–D5 above). These are the only gates before #908 (Velvet scaffold) dispatches. Each is a one-line decision; all recommendations are in Section 4.

3. Review #988 architect output when it arrives and approve the web-layer approach (D6). Do not wait on this before starting the rest of Wave 1.

4. Book attorney consult for marketing copy review (#582 attorney gate, D13). This must be in flight by end of this week so approval is in hand by Wave 3 close (~Day 20).

5. Confirm #148 entity formation status (D15). Even if formation is incomplete, confirm whether you are proceeding to launch as a sole proprietor so that decision is made explicitly, not by accident.

Appendix: Open Questions from Velvet v2-rotation-flows.md

For reference: the Velvet OQ table from the design doc, with v1.0 ship-plan disposition: