pal-e-docs

Review: Game status UI + email receipts

review-799-2026-04-03 Doc

review needs-refinement
Project

Verdict: NEEDS_REFINEMENT

Template Completeness

  • [x] Type -- Feature
  • [x] Lineage -- Sub-ticket of #7, depends on #10 + #11
  • [x] Repo -- forgejo_admin/twitch-2k-wager
  • [x] User Story -- clear challenger wants real-time status + email receipts
  • [x] Context -- sufficient background referencing scaffold (#8) and DB state
  • [x] File Targets -- 3 specific paths listed
  • [x] Acceptance Criteria -- 5 testable conditions
  • [x] Test Expectations -- 2 expectations with test email target
  • [x] Constraints -- email sender question + poll vs SSE decision noted
  • [x] Checklist -- standard PR/tests/no-unrelated
  • [x] Related -- parent #7, story notes, arch note linked

Traceability

  • [x] story:game-status -- "Game Status Visibility" (story-twitch-2k-wager-game-status, id 1159)
  • [x] story note verified -- found in project-twitch-2k-wager user-stories table
  • [x] story:winner-payout -- "Winner Payout and Receipt" (story-twitch-2k-wager-winner-payout, id 1160)
  • [x] story note verified -- found in project-twitch-2k-wager user-stories table
  • [ ] arch:deployment-twitch-2k-wager -- MISMATCH. Note exists (id 1156) but this ticket is about game status UI + email sending, not deployment topology. The issue body itself references arch-dataflow-twitch-2k-wager in its Related section. Label should be arch:dataflow-twitch-2k-wager or arch:twitch-2k-wager-app.
  • [x] Forgejo issue -- forgejo_admin/twitch-2k-wager#13, open

File Targets

  • [x] src/routes/game/[id]/+page.server.ts -- does not exist yet (to be created). Parent directory exists with +page.svelte from scaffold (#8). Correct target.
  • [x] src/routes/game/[id]/+page.svelte -- EXISTS in repo from scaffold (#8). Will be updated with real data + auto-refresh. Correct.
  • [x] src/lib/email.ts -- does not exist yet (to be created). src/lib/ directory exists with db.ts, schema.sql, types.ts. Correct target.
Targets are specific enough for an agent to act without guessing.

Repo Placement

OK. Issue filed on forgejo_admin/twitch-2k-wager, all file targets are in that repo. Single-repo change. No multi-repo concerns.

Dependencies

  • [ ] #10 Keycloak OIDC auth (Twitch login) -- OPEN, in next_up column. Ticket Lineage declares dependency. NOT satisfied.
  • [ ] #11 Stripe Checkout + webhook -- OPEN, in next_up column. Ticket Lineage declares dependency. NOT satisfied.
  • [x] #8 SvelteKit scaffold + Dockerfile -- in needs_approval column. Files confirmed present in repo (game/[id]/+page.svelte exists). Effectively satisfied.
  • [x] #9 Postgres schema + db.ts -- in needs_approval column. Files confirmed present in repo (db.ts, schema.sql exist). Effectively satisfied.
Blocking: This ticket CANNOT be dispatched until #10 and #11 are complete. Both are in next_up, not done. This is correctly documented in the Lineage section ("Last in sequence").

Acceptance Criteria

5 AC, all testable:
  • [x] "Game status page shows: payment confirmed -> game queued -> in progress -> result -> payout status" -- testable via DB state manipulation + page load assertion
  • [x] "Status updates without manual page refresh (poll every 5s or SSE)" -- testable via code inspection for setInterval/SSE
  • [x] "Winner email" content -- testable via email send to draneylucas@gmail.com
  • [x] "Loser email" content -- testable via email send to draneylucas@gmail.com
  • [x] "Works on mobile" -- needs manual or viewport test, acceptable for feature ticket
AC are specific and testable. No ambiguous language.

Blast Radius

Low. Greenfield app with no downstream consumers. The email module (src/lib/email.ts) is new and self-contained. No sibling services share game status patterns. Rollback is straightforward (revert single PR). Only cross-cutting concern: which Gmail account sends twitch-2k-wager emails -- per feedback_email_architecture.md, email is per-project via gmail-sdk.

Decomposition Assessment

Apply the three-thing limit and five-minute rule:
  • 3 file targets in 1 repo -- at the limit but not over
  • 5 acceptance criteria -- at the limit but not over
  • 2 discrete subsystems: (1) game status polling UI, (2) email sending -- these are coupled (email fires on game completion which is displayed on status page)
  • Estimated agent work: ~5 minutes -- borderline
No decomposition needed. The two subsystems are tightly coupled (game result triggers both status display and email). Splitting would create artificial coordination overhead.

Recommendation

  • [LABEL] Fix arch label on board item #799: change arch:deployment-twitch-2k-wager to arch:dataflow-twitch-2k-wager. The ticket is about game status data flow and email sending, not deployment topology. The issue body itself references arch-dataflow-twitch-2k-wager.
  • [SCOPE] Resolve email sender: the Constraints section says "check if westsidebasketball@gmail.com Gmail OAuth works for this, or if we need a separate sender." Per platform convention (feedback_email_architecture.md), email is per-project via gmail-sdk. Decision needed: which Gmail account sends twitch-2k-wager emails? Agent cannot execute with an open question in constraints.
  • [BODY] Once email sender is decided, update the Constraints section to state the decision definitively (e.g., "Email sent via {account} using gmail-sdk") and clarify the src/lib/email.ts file target description accordingly.