Sequenced to retire the highest risk first. Backend work begins in Phase 2 but is intentionally paired with one real test artwork from Phase 3 so the catalogue can be exercised end‑to‑end.

Phase 0 — Technical proof of concept

Hardcoded local artworks, full CustomPainter render path, zoom / pan via InteractiveViewer, spatial‑index hit testing, palette selection, local progress save / load, performance instrumentation. No backend, no auth, no networking.

Test fixtures (must all pass on the same build)

• F‑small: 50 regions · 10 palette colours · 1024×1024 canvas
• F‑typical: 500 regions · 16 palette colours · 2048×2048 canvas
• F‑stress: 2 000 regions · 20 palette colours · 2048×2048 canvas

Exit criteria — quantitative, on a Pixel 6a (or equivalent mid‑range Android)

Metric	Threshold	Measured on	How
Cold start to library	≤ 1.8 s	release build	Tracing.app_start + 5‑run median
Artwork open from cache	≤ 600 ms	F‑stress	Tap → first paint with regions visible, 5‑run median
Steady‑state frame time	≤ 16 ms (p95)	F‑stress	60 s scripted pan/zoom test, Flutter perf overlay + custom timer
Frame‑drop excursion	0 frames > 50 ms	F‑stress	Same 60 s scripted test
Tap → fill latency	≤ 50 ms (p95)	F‑stress	Synthetic taps via integration test, measured to fill commit
Tap accuracy at 4× zoom	≥ 99% correct hits	F‑stress	1 000 scripted taps on known region centroids
Resident memory	≤ 220 MB	F‑stress loaded + 5 min play	adb shell dumpsys meminfo
Battery drain	≤ 6% / 30 min	F‑typical play	Device battery historian

Pass rule: all rows must hit threshold on the same build, with the device on Wi‑Fi and screen brightness at 50%. A failure on any single row means the stack choice is revisited before Phase 1 begins — no partial pass.

Deliverables: the PoC build, the three fixture artworks committed to the repo (used later as test fixtures per §15.2), the measurement harness, and a one‑page Phase 0 result document recording the numbers row‑by‑row.

Phase 1 — MVP app shell

Home, library, artwork detail, downloaded artworks screen, settings, local artwork opening, local progress tracking.

Phase 2 — Backend integration

InsForge schema and RLS, catalogue API, storage buckets, download URL function, auth, progress sync. Includes one manually uploaded test artwork to exercise the full path.

Phase 3 — Content pipeline

Bundle generator, validator (including cultural‑review hooks), upload tooling, internal preview, publish / unpublish workflow.

Phase 4 — Monetisation

Premium gating, content pack products only (subscription deferred post-MVP — see §4.7), server‑side receipt validation (Apple ASSN v2 / Google Play API), entitlement checks, restore purchases, paywall analytics.

Phase 5 — Production hardening

Analytics, Sentry, performance dashboards, accessibility audit, store compliance, retry / offline polish, content versioning, staged rollout.