Skip to content
WalkRPG Wiki

Post-Phase-12 phasing — Android-first, then VPS, then iOS, then Watch

D-015: Post-Phase-12 phasing — Android-first, then VPS, then iOS, then Watch

After the canon-hardening sprint of 2026-05-19/20 closed Phases 11+12 in their decomposed 17-sub-phase form (vertical slice + crafting), the next product surface — mobile + infrastructure — needs a re-sequenced phase log. D-009’s original phasing put Watch-native as Phase 13 post-beta-1, with VPS migration treated as a signal-based deferred undertaking. D-015 redefines this surface as four explicitly-numbered phases with strict ordering.

New ordering (Phase 13 → 14 → 15 → 16):

  1. Phase 13 — Backend + Android (incremental parallel). Backend and Android client grow together. Backend ships endpoints as Android needs them; Android ships features as backend can serve them. No sharp “backend done” milestone — full backend = the cumulative state at the end of Phase 13. Local test backend (commit 0f9b573, ADR-0006) remains the deployment target; production-spec endpoints (D-008 / D-009) land incrementally per Android demand. Lead: tech-architect + mobile-developer paired, dispatched together for each Android feature increment.

  2. Phase 14 — VPS migration (Hetzner CX22). Triggered when Phase 13 reaches a stable Android client with the backend surface that client requires. Migrates Docker Compose stack from local + Cloudflare Tunnel to a Hetzner CX22 VPS (~€5/month) with public IP. Same stack, no GCP, no Firebase prod-tier, mock auth retained. Removes Cloudflare Tunnel; enables asynchronous testing across timezones; supports test cohort growth past ~30 users. Authored as ADR-0007 at trigger time. Lead: tech-architect.

  3. Phase 15 — iOS app (native Swift). Begins only after Phase 14 ships. iOS native per D-008 §2 (Swift, sibling repo walkrpg-mobile). HealthKit integration, Apple DeviceCheck attestation, App Store Sign-In Apple compliance. iOS feature scope matches Android’s end-of-Phase-13 surface; iOS reaches Android parity by end of Phase 15. Lead: mobile-developer.

  4. Phase 16 — Watch-native (Wear OS + WatchOS together). Begins only after Phase 15 ships. Replaces the original “Phase 13 Watch-native” row of D-009 §4. Single phase covering both watch platforms because each watch surface requires its sibling phone client (Wear OS needs Android, WatchOS needs iOS), and both phones are stable at that point. Internal staging follows the 2026-05-20 watch-native research artifact (ops/research/2026-05-20-watch-native-stack.md): 16a peripheral read-only → 16b peripheral light-write → 16c autonomous mode. Lead: mobile-developer + ui-designer.

Production migration (D-007/D-008/D-009 stack with GCP, Firebase App Check, Cloud SQL EU residency, restrictive anti-cheat, reconciliation worker, real-time multiplayer): stays in “Deferred undertakings” — paused indefinitely. Re-designed after cost-redesign at production-readiness point, which is post-Phase-16 minimum under D-015. ADRs 0001-0005 still carry the production-target spec; they unfreeze when production planning unfreezes.

Why this ordering:

  • Android-first instead of dual-track: parallelism cost across two native mobile stacks (Swift + Kotlin) doubles engineering surface for a single CEO-led team. Android-first is the cheapest mobile-RPG ship under D-009’s heavy-offline + restrictive-anti-cheat constraints; Google’s Health Connect + Play Integrity match the back-end attestation contract identically to HealthKit + DeviceCheck, so the iOS port in Phase 15 inherits the validated provenance model rather than designing it cold.
  • VPS before iOS: local-tunnel test backend (D-006 / ADR-0006) constrains tester reach (single CEO machine, manual tunnel uptime). iOS development cycle benefits from a stable always-on backend; pushing VPS migration to Phase 14 — between the Android-first cohort feedback signal and the iOS engineering kickoff — keeps the VPS triggered by a real load signal, not a calendar date.
  • Watch as a single Phase 16, not split per platform: the watch-native research found that watch surface depends on the sibling phone for HealthKit/HC provenance, attestation token delegation, and offline-queue reconciliation. Splitting Wear OS into Phase 13 (Android) and WatchOS into Phase 15 (iOS) would build the autonomous-watch contract twice. Keeping watch as Phase 16, after both phones are stable, lets the contract land once.
  • Production migration stays paused: D-007’s restrictive anti-cheat + D-008’s GCP/Firebase production stack + D-009’s GDPR posture remain the canonical target, but their cost profile is fundamentally inappropriate until the product has a player base that justifies it. The VPS path of Phase 14 carries the product to “full feature surface, real cohort, asynchronous testing” at €5/month, deferring the production migration until tester data tells us scale.

Reasoning: D-009 §4’s phasing was authored before the canon-hardening sprint validated Phase 11+12 as complete vertical slice. With that slice now done, the mobile + infrastructure surface is the next real product question, and D-009’s single-line “Phase 13 = Watch-native” framing is too coarse for it. D-015 explicates four sequential phases on a clear axis (one backend + one phone first; then infrastructure to support the cohort; then second phone; then watch when both phones are stable). The ordering minimizes parallel-stack engineering cost, keeps the test-cohort signal driving VPS timing, and avoids designing the watch autonomous-contract twice.

No amendments needed to D-006 (lore pillars), D-007 (step economy / streak / attestation invariant), D-008 (stack choices — native dual remains canonical, only the order changes), D-010 (combat resolution), D-011 (quest name policy), D-012 (defining image), D-013 (walking rule), D-014 (IA / keystone gating / harvest economy). All gameplay canon stays — D-015 only re-sequences product delivery.

Open questions answered at ratification:

  1. “Full backend” scope: incremental, not a discrete milestone. Backend grows endpoint-by-endpoint per Android demand; Phase 13 ends when the Android client has the feature set the closed-beta cohort needs. No “backend done” gate.
  2. iOS in Phase 13? No. iOS is Phase 15. Android-first reduces parallel-stack cost; iOS inherits validated mobile contract from Android + benefits from VPS-stable backend.
  3. Watch split per platform? No. Watch is single Phase 16 (Wear OS + WatchOS together), staged 16a/16b/16c internally per watch-native research.

Follow-up work (post-ratification):

  • roadmap.md Phase log: add rows for Phase 13/14/15/16 with new definitions; mark old “Phase 13 (Watch-native)” row as superseded by Phase 16; update “Current phase” line.
  • mobile-developer dispatch posture: pre-Phase-13 prerequisites from watch-native research (4 items) re-scoped — backend watch-delegated token endpoint moves to Phase 16; data watch-bundle subset moves to Phase 16; UI watch vocabulary moves to Phase 16; QA watch-side anti-cheat plan moves to Phase 16.
  • tech-architect ADR-0007 draft: VPS migration spec. Authored at Phase 14 trigger, not now.
  • Triage v2 W-level dispatch (6 mechanics + 2 ui + 1 narrative + 1 qa + 1 tech-architect = 11 W-level active) re-mapped against Phase 13: most W-items live in data/ or wiki/ and do not block Phase 13; backend-touching items (W-15) become Phase 13 work. Re-assess at dispatch time.