qa(plan): play every depth x question-count + consumer mindset; add Future.md (QA backlog)

- Pass B: cover the full depth x round-length matrix (Light/Everyday/Deep/All x 5/10/15), not one combo;
  short+long, shallow+deep, every answer type.
- Methodology: THINK AS A CONSUMER (approach from many angles); capture works-but-could-be-better /
  feature ideas to Future.md '## QA' (kept separate from the ClaudeReport.md bug log).
- New Future.md seeded with 5 grounded QA improvement ideas (inclusive onboarding options, turn-aware
  'waiting to play' copy, rate-limit exemption for high-value pushes, suppress redundant results push,
  friendlier paywall error state).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

ClaudeQAPlan.md

@@ -59,6 +59,16 @@ confirms + enumerates this; the fix phase applies couple-shared everywhere.
 - Premium toggled via `scratchpad/set_premium.js` (admin, **user-authorized each time**).
 - Theme toggled via **Settings → Appearance (Light/Dark)** (`MainActivity` `ThemeMode`).
 - **REPORT-ONLY during passes — never fix mid-pass.**
+- **THINK AS A CONSUMER — approach everything from different angles.** Beyond "does it work", constantly ask *"is this
+  what a real person would expect / want here? is this delightful, confusing, or annoying?"* Come at each flow from
+  multiple angles (first-time user, returning user, the partner who didn't start it, someone tapping fast, someone
+  reading carefully, the skeptic, the impatient). Vary inputs, depths, orders, and entry points (don't repeat one
+  happy path). A thing can be bug-free yet still *worse than it should be* — notice that too.
+- **CAPTURE IMPROVEMENT / FEATURE IDEAS → `Future.md` (section `## QA`).** Bugs (broken/incorrect behavior) go to
+  `ClaudeReport.md` as always. But anything that *works yet could be better* — confusing copy, a missing affordance,
+  a rough-but-not-broken flow, a "it'd be great if…" feature idea — append it to **`Future.md` under `## QA`** with a
+  short title, what prompted it, and the suggested improvement. This is an idea backlog, **not** the bug log; logging
+  here is never a substitute for filing an actual defect in `ClaudeReport.md`.
 - **Environment (senior-QA rec):** prefer the **Firebase Local Emulator Suite or a dedicated staging project** over
   production — isolates test data, makes seeding / entitlement toggles / D3 negative tests **free** (no gated prod
   writes), and avoids polluting real users. Caveat: App Check, RevenueCat IAP, and real FCM/APNs push need real
@@ -156,8 +166,12 @@ Games: This or That, How Well Do You Know Me, Desire Sync, Connection Challenges
 - The session lifecycle is exercised by the real playthrough: `status` active→completed; reveal/results correct on both.
 - **VARY THE STYLE OF PLAY (don't just repeat the happy path):** across runs, deliberately exercise *different* ways a
   real couple would play each game, because different inputs hit different code paths:
-  - **Different option/length/mood choices** — every round length (5/10/15), every mood/category, the "All topics"/
-    shuffle option, and **each distinct answer type** (A/B, Yes/No, True/False, 1–5 scale, multi-select, free-text).
+  - **Different DEPTHS and QUESTION COUNTS — cover the matrix, don't settle for one combo:** play each game across
+    **every depth/mood** (Light, Everyday, Deep, All-topics/shuffle) AND **every round length / number of questions**
+    (5 / 10 / 15), in *different pairings* across runs (e.g. Light×5, Deep×15, Everyday×10, All×5) — short *and* long
+    sessions, shallow *and* deep content. Different depths surface different question sets, tones, and edge content
+    (e.g. Deep/Desire-Sync sensitive prompts); different counts stress pacing, progress, and the both-answered gate.
+    Also exercise **each distinct answer type** (A/B, Yes/No, True/False, 1–5 scale, multi-select, free-text).
   - **Different answer *patterns* that change the result** — all-match vs all-mismatch vs partial; both-yes vs both-no
     vs split (so reveals show "shared", "all private", "0 matches", "perfect/zero score" — verify each renders right).
   - **Different turn orders / who-starts** — partner A starts vs partner B starts; the guesser opens before vs after

Future.md

@@ -0,0 +1,26 @@
+# Future — ideas & improvements backlog
+
+Non-blocking ideas: things that work today but could be better, plus feature ideas. Actual bugs
+(broken/incorrect behavior) live in `ClaudeReport.md`, not here.
+
+## QA
+
+Improvement & feature ideas surfaced while QA-testing as a consumer (each works today — none are defects).
+
+- **Inclusive sex/gender options in onboarding.** Profile step 2 ("What's your sex?") offers only **Female / Male**,
+  and it drives Desire Sync question tailoring. For a couples app, consider adding a non-binary / "prefer to
+  self-describe" / "prefer not to say" option (with a sensible tailoring fallback). *Prompted by:* Pass G sign-up flow.
+- **Home "waiting to play" copy doesn't say whose turn it is.** Both partners' Home shows "**Your** partner is waiting
+  to play" for the *same* session, so each thinks the other is mid-game. Consider turn-aware copy ("Your turn —
+  finish your part" vs "Waiting on {partner}"). *Prompted by:* B-002 (resume is fixed; this is the copy nuance).
+- **Exempt high-value/user-initiated pushes from the promotional rate limit.** Game-completion ("results ready") and
+  similar pushes share the same 20/day, 100/week cap as reminders/re-engagement. During normal heavy use a legitimate
+  results-ready push was suppressed. Consider a separate (higher/uncapped) budget for partner-action/results pushes vs
+  promotional reminders. *Prompted by:* Round 5 E-003 results-ready verification.
+- **Suppress the redundant "tap to see results" push when the recipient is already on the results screen.** When both
+  partners finish a game at nearly the same time, both are already viewing results yet both still receive the
+  results-ready push. Mirror the existing chat-message guard (`activeThreadMonitor`) for the active game/results screen.
+  *Prompted by:* Round 5 results-ready test.
+- **Friendlier paywall empty/error state.** A-OBS fixed the raw SDK error leak; as a follow-up, when plans genuinely
+  can't load, consider a retry-with-backoff + an offline-aware message, and hide the disabled "Continue" until plans
+  load. *Prompted by:* A-OBS (env had no RevenueCat sandbox, but the state is worth polishing for real failures).