Deliver useful travel outcomes in dependency order. Existing source is inventoried in features; its evidence state is not replaced by this roadmap. Review checkpoints should track acceptance, not promised launch dates. The current October 6, 2026 scope selects Clerk identity, Drizzle/TypeScript, Supabase PostgreSQL preparation, AWS Secrets Manager, Docker and ECS/Fargate; Kubernetes preparation is separate.
flowchart LR
A[Release identity and data safely] --> B[First useful real portfolio]
B --> C[Repeatable consented updates]
C --> D[Qualified travel decisions]
D --> E[Monitoring worth returning for]
E --> F[Measured commercial offering]
C -. approved provider access .-> G[Broader automatic sync]
B -. independent operational track .-> K[Kubernetes preparation]
The dependency is user trust and genuine data, not the number of services. Provider research can run alongside delivery, but missing access must remain visible and must not block the supported manual path.
Outcome: the modern application serves a real signed-in user while preserving the retained legacy site and snapshot for recovery. The selected launch is fresh; legacy identity/data import is outside launch scope.
- Reconcile the canonical source, qualify the exact artifact, and publish the approved semantic source release.
- Configure actual Clerk production identity, origins and selected social providers; use AWS Secrets Manager for application configuration.
- Launch a verified empty Supabase target with new Clerk identities. Retain the old site and snapshot; future legacy import requires its own lineage/mapping/recovery plan.
- Apply Drizzle migrations under the candidate journal/backup gate; correlate container/source receipts with deployment and live health.
Acceptance: exact deployed source and images, working TLS/DNS, real sign-in, owned portfolio reads/writes, correct account isolation, and an exercised recovery route. Local demo checks, snapshots, schema preparation and bootstrap resources are partial evidence. Track this in JCK-333 and the dedicated release records; JCK-128 retains authenticated capture/model qualification and JCK-234 retains provider-access work. Do not mark all three complete from one successful rollout.
Outcome: a new user organizes one real membership and sees a useful next step.
Current account/history/goal/export functionality is implemented. Prioritize the onboarding and empty-state experience, source/freshness wording and visible program selection over additional widgets.
Acceptance: a person completes sign-in → membership → observed balance → trip goal without developer instructions; can explain the estimate and update method; and can export or undo the relevant action. Record where users stop, what they misunderstand and whether the portfolio remains useful on return.
Dependency: production identity/persistence or an explicitly labeled local qualification environment. Manual entry requires no automatic provider adapter.
Outcome: updating the portfolio is easier than starting again.
Qualify a small named set of actual extension/agent program flows before widening claims. Reduce token/connection friction, preserve original observation time, make consent/revocation understandable and handle uncertain submissions visibly.
Acceptance: real supported signed-in page, bounded consent, correct canonical account, confirmed observed value/time, no duplicate effects on exact replay, revocation and interruption recovery. Browser fixtures and host rules do not satisfy this alone. A device-vault or connector authorization flow requires its own source implementation and acceptance; it is not inferred from an API port.
Outcome: the user can choose or reject a plan for understandable reasons.
The transfer graph, card resolver, valuations and deterministic planner already exist. Improve explanation and freshness, test representative real-user plans, and qualify actual award data only after vendor access is approved.
Acceptance: plans agree with owned balances and supported card/date rules; unknown eligibility cannot produce invented transfer yield; bonus verification, shortfall, taxes/fees limitations and availability uncertainty stay visible. Compare the displayed plan with provider terms before a user acts. PointUp does not execute irreversible transfers, bookings or purchases.
Outcome: a notification helps the user protect points or revisit a useful plan.
Use existing digest/watch/alert/event machinery. Qualify actual sender delivery, notification preferences, repeat suppression, page/vendor reliability and quiet failure behavior. Watch pages are not comprehensive award-seat inventory.
Acceptance: a real recipient receives a timely, attributable useful change; can control/revoke notifications; unchanged or unavailable data does not masquerade as a new opportunity; support can trace delivery without exposing private data.
Dependency: reliable current data and approved channels. This can begin with known expiry/manual portfolios before broad automatic sync.
Outcome: a person pays for a dependable result whose service cost is understood.
Run the business experiments, then select packaging and an explicit usage policy. Billing, entitlements and distributed paid quotas are new implementation work. Household portfolios and mobile parity need evidence of a user problem before expanding scope.
Acceptance: willingness-to-pay evidence, measured cost-to-serve, clear limits, implemented entitlement/account lifecycle, privacy/export support and reliable service delivery. No revenue or acquisition forecast is established today.
| Track | Continue when | Required evidence |
|---|---|---|
| Legitimate provider integrations | Documented wallet capabilities and approved access exist | Exact vendor/program/data coverage, fees/terms, freshness, isolation and failure behavior |
| ECS/Fargate operations | The selected release needs container runtime capacity | Real configuration, health, telemetry, recovery and migration-before-activation |
| Supabase transition | Source identity/data and provider recovery route are established | Separate application/migration roles/URLs, verified schema/data, backup/restore and live acceptance |
| Kubernetes | There is a selected cluster/operations requirement | Manifest render plus cluster/IAM/ingress/secrets, job ordering and live runtime acceptance; not part of the current ECS release gate |
| Scaling and usage | Measured workload or paid offering exceeds per-process protections | Shared rate/usage ownership, bounded fan-out, costs and failure recovery |
| Catalog maintenance | A rule or source changes | Dated source, confidence and qualifications; no silent upgrade to verified availability |
Keep speculative features as hypotheses until their user outcome and dependencies are selected. Review completed acceptance and unresolved blockers before adding a new phase. Historical release/test receipts remain in their owning documents.