Skip to content
Adventive Adventive Engineering

Admin Dashboard Cloudflare Migration

Replace Adventive’s legacy internal admin dashboard with an API-first architecture: a Cloudflare Workers backend API and a separately-deployed presentation layer aligned with current Adventive brand guidelines.

Status

Section titled “Status”
  • Owner: Jeffrey Lambert
  • Status: Phase 1 prototype shipped (2026-04-30) · Phase 2 admin-api scaffolded
  • Started: 2026-04-23
  • Repository (legacy, read-only): ~/Repositories/BitBucket/adventive-admin
  • Repository (new UI): ~/Repositories/GitHub/Adventive/adventive-admin-ui (local, dev preview at genesis-admin.adventive.dev)
  • Repository (new API): ~/Repositories/GitHub/Adventive/adventive-admin-api (local, scaffold; deploys to admin-api.adventive.dev)

What this project delivers

Section titled “What this project delivers”

A full planning artifact set in the standard Adventive Engineering format, followed by implementation handoff to Claude Code (matching the Public API migration pattern).

Functional scope of the target system:

  • Customer service-level management (existing admin responsibility)
  • Billing operations UI — scope negotiated with the Stripe Billing Transition project (this project’s sibling)
  • Operator workflows currently served by the legacy admin

Architectural scope:

  • Clean separation of API (Cloudflare Worker, TypeScript/Hono) from presentation (static SPA or Workers-rendered — decided in 01-architecture-assessment)
  • Brand-guideline-aligned UI refresh (not a cosmetic reskin of the legacy layout)
  • Auth/authz model appropriate for internal operator tooling

What’s in this folder

Section titled “What’s in this folder”
File / FolderPurpose
00-context.mdExecutive summary and problem statement
01-architecture-assessment.mdCurrent legacy admin audit + serverless target architecture
02-code-updates.mdMigration/rewrite plan: API surface, UI stack, data contracts
03-deployment-management.mdHow the two services ship and stay shipped
04-runbook.mdOperational procedures for the new admin
05-appendix.mdReferences, inputs, decisions, open questions
06-phase-1-prototype.mdPhase 1 UI prototype — what shipped, stack, brand tokens, swap surface
Adventive_Admin_Dashboard_Migration_Plan.pdfOriginal deliverable (v1.0, 2026-04-23)
Adventive_Admin_Dashboard_Migration_Plan_v2.pdfCurrent deliverable (v1.1, 2026-04-30) — chapters 00–06 with Phase 1 prototype + locked Phase 2 decisions
build_pdf_v2.pyMarkdown-driven PDF generator — picks up chapter edits automatically. Run python3 build_pdf_v2.py to regenerate
code/Scaffold + reference implementations (actual code lives in its own repo)
inputs/Legacy admin screenshots, route inventory, brand guidelines PDF, feature list
decisions/ADR files: YYYY-MM-DD-title.md

Serverless viability summary

Section titled “Serverless viability summary”

The admin’s API layer is a strong fit for Cloudflare Workers. All 14 controllers are stateless request-handlers with no persistent process state; no operation exceeds Workers’ CPU time or memory limits; the largest models (Account_model.php at 1,321 lines, Report_model.php at 5,333 lines) are pure SQL wrappers that port cleanly to typed query functions behind Hyperdrive. The one exception is Report_model.php — 24 bespoke partner SQL report functions that represent the most complex single file in the codebase; these are deferred to a dedicated analytics Worker in Phase 4 rather than ported to admin-api inline. The presentation layer is a clean Cloudflare Pages SPA deployment: no server-side rendering is required, and the existing PHP views are pure data-presentation with no business logic that must move to the UI. Incremental monthly cost for the two new services (Worker + Pages) is estimated at under $6/month on the existing Workers Paid plan.

Dependencies and adjacencies

Section titled “Dependencies and adjacencies”
  • Sibling project: ../Stripe Billing Transition/ — billing functionality currently lives in this admin. Decisions made there will shrink or reshape the billing surface area of the new admin.
  • Upstream pattern: ../Public API Cloudflare Migration/ — auth model, deployment pipeline, observability approach should mirror this project where sensible.
  • Shared infrastructure: ../Cloudflare Tunnel/ — if the new admin terminates behind Cloudflare Access/Tunnel for operator auth.
Section titled “Quick links”