crosscue

Challenge Boards (#159) — implementation breakdown

Status: Living tracker — workstream states are updated as they land; flips to Historical when #159 closes. The locked architecture decision is recorded as ADR-0012.

Breakdown of the remaining work to ship private friend challenge boards (v1) per #159. Much of the design is already built; this plan covers only the gaps.

Status snapshot (2026-06-09)

Built and merged:

Architecture decision (locked): v1 keeps live-compute lifetime + bounded retention purge. We do NOT build daily_results / player_board_stats / processed_lifetime_weeks / the Monday rollover cron for v1. The issue’s acceptance criteria referencing rollover/player_board_stats are superseded by this decision and should be amended on the issue.

Update (2026-06-15) — landed since the snapshot

The snapshot above is preserved as the plan of record; these workstreams have since shipped (the per-workstream sections below were written pre-merge):

Still open: E2 custom domain (api.crosscue.app, gated on registering the apex), and the optional D3/D4 activity feed / canonical-source registry.


Workstream A — Identity recovery (backend + Flutter)

Survives device restore; an explicit v1 acceptance criterion. Currently bootstrap-only — no recovery secret exists, so identity is lost on reinstall.

Workstream B — Privacy & deletion (release gate) — DONE

Workstream C — Retention purge (replaces full rollover model)

Scope correction: under live-compute lifetime, challenge_results IS the lifetime source, so those rows must NOT be purged without a rollover step (which v1 defers). They are compact (one row per player per daily puzzle), so v1 retains them. Retention applies only to board_events, which feeds no ranking.

Workstream D — API hardening

Workstream E — Infra & provisioning (deploy gate)


Sequencing

E (infra) ─┬─> can deploy backend at all
A (recovery)│
B (privacy) ├─> release gates: must land before store submission
C (retention)
D (hardening) ─> before public beta
F (deeplink/QA) ─> final verification

Recommended order: E1–E3 → A → B → C → D → F. E unblocks real testing; A and B are the two acceptance-criteria gaps that block release; C prevents unbounded growth; D/F harden before beta.

Issue housekeeping