Reliability OS Platform Migration

// CASE RECORD

The problem

Roger is my own system. It trains personal reliability through proof feedback, not generic todo management: you make commitments (Axioms), gather evidence (Proofs), and a red/yellow/green signal lets you — and a small trusted circle — see how consistently you follow through. The original architecture put authority on a macOS home-base daemon with a local SQLite database, with a browser extension collecting telemetry into it. Single-host authority limits resilience, multi-device access, and the serverless background processing the product now needs.

What I built

A live, staged migration with a single declared authority: Firestore becomes the canonical live-state source, Cloud Functions Gen2 takes all background processing, and SES is the single email channel — no webhook mesh writing outside Firestore. The legacy daemon stays active through the migration window, the plan runs sixteen staged epics, and it ends with a hard decommission milestone: the macOS hub cleanly retired at the final epic. The constraint that matters most: no data loss and no continuity gap during cutover.

Where it stands

An active build. The measures: live-state authority consistency — agreement between surfaces with Firestore as the single source of truth; migration epics completed against the sixteen-epic plan; and telemetry capture reliability — the share of work-app signal reliably recorded as events. A governed platform move with one declared authority and a staged cutover is a pattern that reuses for any single-host system going serverless.