Read the engineering.

What's actually running

Phase 1, in production today, entirely on Cloudflare — the API on Workers (Hono); the admin, subscriber portal, and Catalyst integration on Pages; with D1 (the primary database), KV, and Queues behind them. For the exact, always-current bindings, read the generated C4 container diagram in Architecture diagrams below — it is derived directly from the deploy config and drift-gated in CI, so it can't fall out of sync the way a hand-maintained list would.

The ratified next step is a move to Google Cloud Platform — Cloud Run, Cloud SQL, Pub/Sub, and Terraform-managed infrastructure — once the product outgrows what a single edge platform gives it. That migration target is a formally recorded architecture decision, not a live surface today. SeeDecisions below for how it and every other structural choice got made.

How to review the code

Code review & architecture assessmentis the reviewer's entry point — repo orientation, where to start reading, and the runnable checks a reviewer can execute themselves rather than take on faith. Actual repo read-access for an external reviewer is an operator-arranged grant, not something this page substitutes for — it orients a reviewer who already has access, it doesn't replace reading the code.

Architecture diagrams

The connective architecture set — C4 context and container views, the as-built Cloudflare sequence diagrams, the five process/functional flows (subscribe · renewal · dunning · cancel · gift), the system-integration topology, and thedata-model ERD. Each element is pinned to a mechanical source (a binding, a handler, a scenario); the container and topology views are mechanically generated frominfra/cloudflare/wrangler.toml+ the Worker Env bindings with a CI drift-gate, like the ERD. All render natively on GitHub (mermaid does not render in this portal today).

• C4 system context — actors + external systems
• C4 container — deployables + datastores (generated)
• As-built sequence diagrams — renewal · subscribe · dunning
• Process & functional flows — the five lifecycle flows
• System-integration topology — external seams (generated)
• Consolidated test strategy — the five-gate verification ladder (spec → prototype → presence → behavior → live)

The C4, sequence, flow, and topology diagrams encode structure an engineer should confirm — they carry sign_off: pendingin frontmatter until reviewed, and should not yet be cited as authoritative.

Decisions

81 ratified architecture decision records — ADRs, the standard written form for "we chose X over Y and here's why" — cover the structural choices in this system, from the Cloudflare-to-GCP migration path to the payment-rail design. SeeDecisions for the full log.

Threat model & compliance

Structured threat models (using the STRIDE framework — Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) exist for both the payment flows and the subscription lifecycle, alongside a compliance pack covering PCI scope, GDPR, and penetration testing under docs/attestations/security-compliance/. Several of these are still pending formal sign-off — naming that pending state honestly is itself part of the handoff, not a gap to paper over. TheSecurity & Compliance space renders the full pack with each item's sign-off status derived live from the attestation substrate; the operational-readiness side (SLOs, on-call, runbooks, status page) lives inOperations & Reliability. SeeOpen items for the flat outstanding list.