# Open Questions

Things we must answer before/while building. Add freely; mark resolved with ✅
and link the decision in [decision-log.md](decision-log.md).

## Business / scope
- [ ] What is the **catalog** today? Real course/product names are NOT in
      `post_title` (they show "Course overview post"). Need the title source —
      likely TA stores them as a custom field or in a separate options blob.
- [ ] Which products are **active vs retired**? 27 `tva_course_overview` posts
      are all `draft` — is the live catalog elsewhere (TA admin only)?
- [ ] Are there **subscriptions / recurring** payments, or one-time only?
      (Annual/lifetime add-ons exist → may need Stripe Billing + PayPal
      Subscriptions: renewals, dunning, proration. Affects Commerce scope.)
- [ ] **Saved-card / token migration** off ThriveCart — can repeat/recurring
      buyers' payment methods transfer, or re-enter on first new purchase?
      (Stripe token import possible; PayPal billing agreements harder.)
- [ ] Confirm **LAFF's own live Stripe & PayPal accounts** (not ThriveCart-linked)
      + API keys (env-stored).
      (Affects whether we need dunning, renewals, proration.)
- [ ] Refund / dispute volume — the `laff-dispute-evidence` custom plugin
      suggests chargeback handling is a real workflow. How important is it?
- [ ] Currencies: orders are all USD so far — confirm single-currency.

## Technical
- [ ] What does `laff_data_courses2` database contain vs `laff_data`? Stale clone?
- [ ] `tva_orders.status` exact code meanings (1/4/0/2). Confirm against TA source.
- [ ] Where does TA store the **course → lesson → module** hierarchy and
      drip/scheduling rules? (`tva_drip_campaign`, postmeta?)
- [ ] How is **login / SSO** done today? Same WP users on courses site only.
- [x] ✅ Video hosting → **BunnyStream** (confirmed via Bruce's KB, 2026-06-13).
      Our DB stores metadata + Bunny IDs; playback via Bunny. (The old
      `wp_fv_player_*` / `tva_video_data` references are legacy.)
- [x] ✅ ActiveCampaign → **replace** (Amazon SES + built-in CRM + scheduler).
      Still TODO: which AC events/automations must be ported.
- [ ] Email sending: WP Mail SMTP today — what provider behind it?

## Hosting / capacity (from the 2026-06-13 hosting decision)
- [ ] **Load test before launch** — validate the ~100k sessions/day capacity
      estimate with a real test (k6/Gatling). Numbers in the doc are modelled,
      not measured.
- [ ] **Manual DB failover runbook** — write it; we traded away RDS auto-failover.
      Decide if/when to add a cheap EC2 streaming replica for faster failover.
- [ ] **WAL-G vs pgBackRest** — pick one; define base-backup cadence + WAL
      retention + restore drill schedule.
- [ ] **API tier:** stay on Elastic Beanstalk or move to ECS Fargate / App Runner?
- [x] ✅ **PgBouncer** — the fix for the *connection* limit (CPU scales with
      instance size; connections don't). **Add when the API tier autoscales wide**
      (trigger: active_connections near max, or >~3–4 API nodes), not day one.
      (Decided 2026-06-13.)
- [ ] **AWS region** (latency to main audience) + cost estimate per tier.

## Migration
- [ ] Can we get a **production DB dump** (this is a `.test` local copy — is it
      current with live data, or a snapshot)?
- [ ] Password hashes: WP uses phpass. Plan to rehash-on-login in Laravel.
- [ ] Do we need to keep WordPress running in parallel during cutover?

## Product decisions (need Berner's call)
- [x] ✅ **Front-end shape** — decoupled JSON API + customer Vue SPA + admin Vue
      SPA, so a future Flutter app reuses the same API. (Decision 2026-06-12.)
- [x] ✅ **Public marketing/funnel site** → **Nuxt (SSR)** at `www.`, on the same
      API. Topology decided 2026-06-13 (see deployment-topology.md).
- [ ] **Vue admin component library:** PrimeVue vs Vuetify vs shadcn-vue?
- [ ] **Repo shape:** monorepo (api/web/app/admin/shared) vs four separate repos?
- [ ] **Auth mode:** Sanctum *token* (leaning — works for Flutter too) vs cookie
      SPA mode. Token unless a reason appears.
- [ ] **Staging domains:** `*.staging.loveatfirstfight.com` vs separate domain?
- [x] ✅ **Payments = Stripe (primary) + PayPal**, direct through LAFF's own
      accounts. Drop ThriveCart. "ThrivePay" was ThriveCart's wrapper over
      Stripe/PayPal — re-routes to our accounts, not a 3rd gateway. (Decided
      2026-06-13 — see [../04-features/payments.md](../04-features/payments.md).)
- [x] ✅ **Database = PostgreSQL.** Functional + audit as **two databases on one
      server** (split-aware; promote audit later on a trigger) — revised
      2026-06-13 from the original two-servers plan after checking real load;
      analytics in an in-house decoupled pipeline. (Decision 2026-06-13 — see
      data-stores-and-logging.md.)
- [ ] Domain/branding: does the Super System get its own domain, or replace the
      existing `.co.za` / live domains in place?

## Logging / analytics (from the 2026-06-13 data-stores decision)
- [x] ✅ **Queue/stream tech** → **Horizon + Redis**, analytics via **Redis
      Stream** drained in batches, separate worker pools. Split by measured
      traffic (LAFF at Stage 0). See queues-and-redis.md.
- [ ] **Redis maxmemory + eviction policy** — cache keys evictable; analytics
      stream must NOT silently evict (trim explicitly or split early).
- [ ] **Horizon pool process counts + balance strategy** per environment.
- [ ] **Stream retention/trim policy** — how long raw events live in Redis
      before they're safely persisted in the store.
- [ ] **ClickHouse migration trigger** — confirm the threshold (~10M events/day,
      ~50–100M rows, or dashboard latency) and who owns watching it.
- [ ] **A/B test framework** details: sticky variant assignment keyed on user vs
      anonymous/device; server-side vs client-side assignment.
- [ ] **App/debug error tracking:** self-host (e.g. open-source error tracker) vs
      SaaS free tier? (Decided: not in SQL — but which tool?)
- [ ] **Audit DB reads:** confirm no hot path ever needs an orders↔audit JOIN
      (we use 2 databases, so JOINs aren't available — app stitches). Plus: define
      the **trigger to split `laff_audit`** onto its own server (write volume /
      backup-window impact / risk-isolation).
      (validated assumption — re-check when designing Reporting).