I decided to keep cf-friction-log as a lightweight Payload-on-Cloudflare deployment and treat it as an operational friction log first, not a platform build-out: the recent commits show this moved from MVP to deployable by adding real Cloudflare resource config, custom domain routing, Access JWT verification, and seed data that captures process limitations.

What We Built

• A working Payload Cloudflare template baseline focused on fast local iteration and direct Workers deployment (feat: initial commit, then feat: implement Cloudflare Access friction log MVP).
• A deployment-ready Cloudflare setup with real resource wiring and domain routing (chore: configure Cloudflare resources for deployment, chore: disable workers.dev and bind custom domain).
• Access-aware request verification in the app path (feat: verify Cloudflare Access JWT claims) so protected usage is enforced through Cloudflare Access claims instead of relying on app-only assumptions.
• A feedback loop for operational learning by logging discovered process limits into seed/demo content (chore: log Access policy limitation as friction seed).

Why We Built It

• I optimized for a practical operator workflow: use the template’s minimal surface and ship on Workers quickly, rather than introducing extra services.
• The README intent is explicit: this is a bare-minimum Cloudflare starter; I kept that direction and only added what was necessary to run in production conditions.
• The work addressed concrete friction discovered during deployment, especially around real D1/R2 bindings and Access setup requirements.
• The latest session focus (“Plan how to build a Payload CMS friction log on Cloudflare Workers…”) aligns with this outcome: make friction observable, reproducible, and captured in project memory.

How It Works

• Build and deploy are split into predictable stages: deploy runs deploy:database (Payload migration + D1 optimize) before deploy:app (OpenNext Cloudflare build/deploy), reducing drift between schema and runtime.
• Local development stays simple with next dev, while Cloudflare typing and Payload typing are generated via generate:types to keep bindings and schema in sync.
• Cloudflare Access verification activates only when both CF_ACCESS_TEAM_DOMAIN and CF_ACCESS_AUD are present as Worker secrets; this makes auth behavior explicit across environments.
• Current operational changes are concentrated in README.md, src/scripts/seed.ts, and MEMORY.md, which together document prerequisites, encode friction examples, and preserve deployment decisions for the next iteration.