Clients own their infrastructure. TKATI manages it.

Steps only the owner can do

These can't be automated, and shouldn't be. Each one involves a login, money, a legal agreement or a credential. A 90-second human step beats risky automation (§223).

Decisions

Each decision comes with its reason. To reverse one, add a new decision that supersedes it, and leave the old one here.

Cloudflare facts, checked

The brief was written by another AI, and it says itself that its API details are claims (§181). Only what's in this table has been checked against Cloudflare's own docs, and each row gives the date. If the docs change, they win: stop, record the change here, then update the code.

All rows checked 2026-09-24 against developers.cloudflare.com. Verified = the docs say it. Differs = the docs say something the brief didn't, or say it differently. Not documented = don't build on it.

The record

Every real step, newest first. Each entry says what was done, how it was verified, and what was not done. Git history is the audit trail for this list.

1. 2026-09-29 · Project A's database is in production (M2); client files have a store

   The twelve Project A changes are in production and match the files; clients can send files; the Office writes the client's work

   • M2, done at your direction: pa1–pa12 became migrations 0039–0050 (renames without the banner, docs/cloudflare/promoted.json), and every check moved with them (tools/drafts.mjs finds each file wherever it lives). Before the push: verify.mjs --local on the promoted tree (every Project A suite green), all twelve rehearsed on production inside one transaction that was rolled back, the CLI's own push rehearsed on a local copy built through 0038 (the probe then matched it: 218 objects), 13 SQL mutations cut from the moved files all caught, a backup of production's schemas, data, history and roles, and a dry run that listed exactly 0039–0050. Pushed 19:45–19:47 UTC; the history reads 50 rows, local and remote agreeing.
   • The production probe: read-only, its certificate checked against Supabase's root CA (downloaded from Supabase and matched to the server's by fingerprint): 6 ok, 0 FAIL, 218 objects compared whole. Four differences are Supabase's own and were read before they were allowed, each with its reason in tools/prod-catalog-allow.json: the Realtime role is a member of the three API roles (it runs the other way from a hole), and Supabase's "enable RLS on new tables" event trigger function, which cannot be called (checked).
   • Found by the promotion: once the files were migrations, the grants check covered them and caught the overdue-steps view (pa12) keeping write grants for signed-in users (the 0012 mistake: a revoke that did not name authenticated). Fixed in 0050 before the push.
   • 0051, a client sends its files: a private bucket client-files (50 MB a file), each file under its client's id; a client puts and reads only its own, staff read all (proved on production in a rolled-back transaction: its own folder allowed, another client's refused, anon reads nothing); a client's file moves its own request to "Sent to us", and only its own (a trigger, proved locally). The client's account now sends files for real, with measured progress and a real Stop. Applied 19:50 UTC; the history reads 51 rows.
   • The Office writes the client's work (product map §9 item 17): the dossier's "Their work" band sends or drafts updates, keeps milestones and scope, asks for approvals (a new version asks the client again; withdrawing is the one state staff write), asks for files, opens what a client sent through a five-minute link, and accepts it or asks again with a reason. Nothing secret-shaped is sent, since the client reads all of it.
   • Billing and sign-in: Stripe returns a client to their account's Billing, which offers "Manage your card and plan at Stripe" only when a plan is already at Stripe; the old portal.html forwards there. An account with no role, or a switched-off one, sees only its message: no crew screen, no "No connection" line.
   • Before M26: the site's functions now prefer Supabase's new secret key (sb_secret_…, sent as Supabase asks, on apikey alone) and fall back to the legacy one; the tkati Worker has the new key. Revoking the legacy JWT secret (M26) no longer stops them.
   • M25, the production credentials off this machine: done last, after the pushes that needed them. The seven values that were set are in the macOS login Keychain (service tkati-production-supabase), each stored with no trusted application so every read asks you, each read back identical by hash before its line left .env.local; no worktree, shell profile, shell history or CLI cache held a copy. Still yours at M26: rotate the database password and the secret key, since sessions could read them until today.
   • Decided at your direction ("do it all, I give you authority"): M4's consent-screen name and publisher domain ("TKATI Site Management", tkati.com; the hostname waits for M24's new domain); M28's build host (the operator's machine, which Phase 10's pipeline was built for: it uploads with a TKATI person's session and tkati-infra re-checks every byte; revisit when a second builder or a client-authored repository appears); and tkati.com's "Client login" is public (the top bar from 561px up, the menu everywhere), so returning clients have a door.
   • The domains stay at Squarespace until needed (your decision): each moves to Cloudflare Registrar in the month before it expires. Checked today against the registries: all on Cloudflare's nameservers, 68 transferable now, 15 more by 2026-11-02, and 26 expiring in November 2026, which are the ones to move in October.
   • Also: the product map's "needs real rows" items answered from production's counts, its remaining §9 items built or decided; tkati.com checked to serve none of the tools, fixtures, docs, migrations or .env.local (all 404); the sixteen merged worktrees removed (their branches kept).
   • Not done: nothing called Cloudflare for Project A and tkati-infra is not deployed, so its production tables are empty (M24, M9b, M22, M18 next). The dashboard-only steps (P1 TOTP, M26's key rotation) and the pilot remain yours.
2. 2026-09-29 · Phase 12 built locally; the pilot is ready to run

   Every Project A phase that can be built is built: 86% built, and what is left is production and the pilot

   • Phase 12 → Built locally. node tools/verify.mjs --local passed on main with 0 failures (77 checks, every Project A suite among them: the SQL and HTTP suites, the cross-tenant command over every route, the secret scan, the end-to-end walk, the catalog probe's self-test, the live runner and the owner's scripts). The two Office screen checks it runs only in part passed in full against the local stub (133 and 87 checks). All 218 SQL mutations are caught on the merged tree.
   • Phase 13 → ready to run. It is an operation, not a build, so it stays a waiting status: docs/cloudflare/pilot-runbook.md (the production dry run by test identity 1, the pilot, the friction log, the stop rules) and tools/pilot-check.mjs (its twelve gates with what the owner has recorded done), which verify.mjs --local now runs.
   • Project B: every moved domain answers from Cloudflare and none from Netlify (checked today), so the deletes can go on 2026-10-08 as planned; tkati.com's registrar transfer opens 2026-10-21.
   • M25, the hard gate, was missing two values: SUPABASE_DB_POOLER_URL and SUPABASE_DB_SESSION_POOLER_URL both carry the production database password (checked by parsing them, printing only whether a password is present). The runbook, the promotion runbook and the plan now name eight values, and the check after it greps for all eight.
   • T33 names TKATI's domain only: a login at tkati.com can never be the one consenting for a client (the Worker and pa1's constraint); the owner's other domain no longer counts as TKATI's. The Cloudflare user ids in private.cf_tkati_cf_users remain the check that does not depend on an e-mail.
   • Not done: nothing called Cloudflare for Project A, nothing was deployed for it, and its drafts are not applied. Done stays at 36% until the owner steps in Needs you, the two dates and the pilot.
3. 2026-09-29 · the page speaks for TKATI; the Office's migrations applied

   TKATI is the control plane, in so many words; this page no longer names the owner's other businesses

   • The wording: the thesis, the diagram, the glossary and the tests now say what the code has done since D8: TKATI is the control plane (tkati-infra, its own Worker), and the engine code vendored from the owner's other project runs inside TKATI. Nothing in Project A connects to anything outside TKATI and the client's own Cloudflare account.
   • The owner's other sites: Project B moved several of them into the same Cloudflare account. This public page now calls them "the owner's dashboard app" and "the owner's other domains"; every line it used to say about them is kept word for word in docs/cloudflare/other-sites-record.md (the repository is private and docs/ is not served).
   • Migrations 0037 and 0038 applied to production (the Office's, not Project A's): see Steps only the owner can do. The Stripe webhook that links a typed-in plan and keeps Stripe's own status is live.
   • Not done: nothing called Cloudflare for Project A; its drafts are not applied; no client is connected.
4. 2026-09-28 · evening

   A step Cloudflare never answered now tells a person, and the ownership record refuses secrets

   • The open-step alarm (Phase 12, draft pa12 §6): each kind of Cloudflare step has a window (75 minutes for a temporary account, two days for a nameserver change, one day for a registration, 30 minutes otherwise). A step still waiting past it is listed for staff and counted on the staff overview ("A Cloudflare step never answered"). A preview whose account creation was never answered ends once Cloudflare's 60-minute claim window has certainly passed, so the client can start again; the step itself stays open, because what Cloudflare did is still unknown and is never guessed.
   • The ownership record's tripwire (pa12 §5): a system's name, address or note shaped like a password, key or token is refused by the database, for new and changed rows. The Office's new editor for these rows refuses the same shapes before sending anything.
   • Every phase's open items answered: docs/cloudflare/lead-answers-2026-09-28.md, one place, and each phase's notes point to it.
   • Verified: on the branch, 516 SQL tests, 31 HTTP tests, the static check, 189 end-to-end tests and 54 stand-in self-tests, all green; the four new mutations each caught by their own test; merged into main.
   • In the Office (not Project A): where Project A exists, the home now lists each client's Cloudflare problems in the staff overview's own words, and the rail links to every client's infrastructure. Production sets no infraOrigin, so none of it shows there yet.
   • Not done: nothing called Cloudflare, was deployed, or touched production's database. The drafts still apply only at M2.
5. 2026-09-28 · every branch merged

   Project A is one branch again: twelve of fourteen phases built, every open red-team item decided

   • Merged into main: Phases 4 and 5, Phases 6 and 10, the red team's 20 fixes, Phase 9 (the client screen), the Phase 12 suites, the owner runbook, the live-test runner and the build specs. Drafts pa1–pa12 apply in order. Phases 4, 5, 6, 9 and 10 now read "Built locally"; Phase 12 is in progress.
   • Lead decisions 8–17: the HTTPS probe may reach only the connection's own domain and www (8); Disconnect works from every state through one flow (9); staff queue actions need a live session and record who queued them (10); a confirmation holds exactly its action's details, at most 20 unspent per project (11); the rest of the red team's leftovers recorded (12, 16); a login deactivated after it made a request can no longer act on it (17, red-team finding 22). Each has a test that fails without it.
   • Cloudflare's docs checked again (2026-09-27, the new tab under Facts): 19 places where the built code assumed otherwise were fixed, including rollback never forcing past a changed secret, alerts only where webhooks exist, and a refused member-list read no longer touching the connection.
   • Red team round 2 (2026-09-27): the client screen, the Phase 12 tools, the owner runbook and the live runner; 16 findings confirmed and fixed.
   • Still true: nothing has called Cloudflare, been deployed for Project A, or touched production's database. Production's config.js sets no infraOrigin, so no client sees any of it. The live tests wait on the owner steps in the runbook.
6. 2026-09-26 · paused overnight

   Where Project A stopped: six phases merged, five more built on branches, a red team done

   • On main and live: Phases 1, 2, 3, 7, 8 and 11, with verify.mjs --local green (the one screenshot that timed out when Chrome hung under load passed on its own).
   • Built on branches, backed up to GitHub, not yet merged: Phase 4 and 5 (project-a/wave2-a), Phase 6 and 10 (project-a/wave2-b, Phase 10 still in progress), Phase 9, the client screen (project-a/phase-9, 1,223 checks green), Phase 12 prep (project-a/phase-12-prep: the cross-tenant gate over every route, the secret scan, and a production catalog probe that has never been run against production), the owner runbook (docs/owner-runbook), and the live-test runner (project-a/live-harness: 111 real-Cloudflare tests placed, 25 fully automated).
   • Red team: five independent attackers read the merged code; 22 findings (1 high, 8 medium, 13 low), 20 confirmed by two skeptics each and fixed on project-a/redteam-fixes with a test per fix; the list is in docs/cloudflare/redteam-2026-09-26.md there.
   • Next: finish Phase 10, then one merge of every branch into main, the full local check and all mutations, then this page. Nothing has called Cloudflare, been deployed for Project A, or touched production's database.
7. 2026-09-26 · The merge's audit, applied

   Main takes the page's two-figure top, Phases 7, 8 and 11 count as built, and the audit's findings are fixed

   • Found: local main had diverged from GitHub (40 commits ahead and 1 behind, not "64 ahead" as the merge's report said): the page worktree had pushed the two figures at the top of this page. Main now includes it. Rows 7, 8 and 11 read "Built locally" in grey, so the new built figure left them out; they are blue now, and Project A is built 7 of 14 (13 of 22 in all). The progress check now fails when a status's words and its colour disagree, and it was shown to fail on the merged page before this fix.
   • Fixed, each with a test that fails without the fix: Disconnect from an error state is offered and accepted only while TKATI holds an OAuth grant (a temporary account in error has none, and the flow used to fail after asking for the second factor); a preview whose account was recorded but whose job finished after its lease ran out is no longer stopped by the reaper before its deploy (SQL mutation 30); the five tools that build Project A's database take one list read off the disk, in number order, so pa10 can never apply before pa2. The merge entry below said "every check" used one list; the queue check was still on pa1–pa3, and that is true only from this entry. The PostgREST check now reads and refuses Phase 7's site profiles and Phase 11's handoff record and views over the wire; the static check's bare-fetch rule tests itself; verify.mjs --local reads the same local cluster as its sub-tools.
   • Worded to match the code: Phase 8 creates no zone, and creates a DNS record only to put back a website record it deleted when an attach fails (once, with the same type, name and content). Lead decision 6 says "no DNS record", so the lead is asked to confirm it allows this; if not, the put-back is removed.
   • Checked: node tools/verify.mjs --local passed (67 checks; only the production tier skipped, as --local means); the SQL suite's 320 tests with pa1–pa7, and 76 of 76 SQL mutations caught; the PostgREST check's 20; the queue check's 19, and its 6 mutations; 166 Worker unit tests; the end-to-end run against local stand-ins (88 scenarios, 23 stand-in self-tests); the handoff check's 18, and its 24 mutations; the static check's 31. Nothing called Cloudflare.
   • Not done: nothing was pushed, deployed or sent to Cloudflare, and production is untouched. The 111 live tests still wait for their owner steps. Decisions 1 and 2 wait for Phases 5 and 6. Two things are for the lead: whether decision 6 allows the put-back, and whether "disconnect from any state" also covers the temporary states (Phase 4).
8. 2026-09-26 · Project A Phases 7, 8 and 11 merged into main

   D1 and R2, the domain, and ownership and handoff now sit on top of Phase 3 in one tree, with the lead's decisions 3, 4 and 5 applied

   • Merged (locally, not pushed): the second-cluster switch, then Phase 7 (draft pa5), Phase 8 (pa6) and Phase 11 (pa7), each conflict resolved keeping both sides. Every check now builds its database from one ordered list, pa1–pa7, and the end-to-end check reads every phase-N-deferred.md on disk. Phase 11's SQL mutations are renumbered 111–131 (Phase 3 had 17–29).
   • Found at the merge, and fixed with a test that fails without the fix: a double click on "set up storage" could send two create calls to Cloudflare (the create is now journalled under a lock on the run), and its loser got a generic sentence; the domain's HTTPS check would have read Phase 3's outbound guard as "no valid certificate" once deployed (it now says "not checked" until the lead decides whether the guard may reach a client's own address); Phase 11's fixtures built rows Phases 7 and 8 now refuse.
   • The lead's decisions applied: Disconnect works from ERROR too, and the Cloudflare panel's button opens the handoff section's confirmation (one flow); a job whose lease has lapsed can't be finished by its old holder (the reaper settles it); the preview refusal says one temporary preview per client. Decisions 1 and 2 (one source of truth for what a site needs; Phase 6's intake) wait for Phases 5 and 6.
   • Checked: SQL suite 319 tests with pa1–pa7, and all 75 SQL mutations caught; the queue check with its six mutations; the Worker's unit tests; the end-to-end run against local stand-ins (88 scenarios, 23 stand-in self-tests), its flaky concurrent-refresh scenario now built on a barrier; node tools/verify.mjs --local passed. Nothing called Cloudflare, nothing was deployed, production untouched.
   • Not done: 111 live tests across Phases 2, 3, 7, 8 and 11 are listed, each with the owner step that unlocks it, and none has run. The Phase 7 and 8 plan entries (plan §5.2, §5.7) and a Phase 8 "Certificate packs" card are still the lead's.
9. 2026-09-26 · Project A Phase 11 review applied

   Phase 11 no longer calls a project client-owned while TKATI still holds its keys, and its handoff document prints no free text

   • Fixed (security): a connection in error still holds TKATI's grant, and the level now says so (it had read "Client owned" with two sealed tokens held); the break-glass document prints no label and no address path from the ownership record (a plain password and a webhook URL got through before), escapes every value so nothing can be a disguised link, and keeps only the client's own rows; the handoff record states the document's level and is refused when it is stale; records are one per document and at most twenty a day per project.
   • Fixed (fidelity): "ready for handoff" follows §112's five facts (it was wrong both ways) and is shown in the portal and the document; a claimed temporary account and a missing Worker are judged correctly; the document always has a registrar line; the mutation proofs are committed: SQL 17–37 in cloudflare-check --mutations, and 24 portal-module mutations in tools/handoff-mutations.mjs.
   • Tests now: 19 SQL, 18 unit and 5 portal tests, and the end-to-end scenario, all green on the second local cluster; every committed mutation caught.
   • Not done: nothing touched Cloudflare or production. A tripwire on the ownership record's free text is proposed for Phase 12, and the registrar waits for Phase 8's domain tables (docs/cloudflare/phase-11-deferred.md). Phase 11 was built ahead of its plan entry (Phases 6–8): the facts its level reads are written by tests until a real reconcile writes them.
10. 2026-09-26 · Project A Phase 11 built locally

    Ownership and handoff: the database says how owned a project is, and a client can leave without losing anything

    • Built: the draft pa7 — a per-project ownership level (§204) computed from the connection, the resources and the ownership record, Client owned only when all of §203 holds and every missing fact named; §153's exit checklist, each item with its evidence; and a record that a break-glass document was made (its hash, never the text). In the portal, behind infraOrigin (so absent in production): an "Ownership and handoff" section under the Cloudflare panel with the level, what TKATI can still do, the checklist, a break-glass document the client downloads (no password, key, token or claim link: every value checked, and the whole document refused if one slips through), the steps to invite a new developer in the client's own accounts, and a disconnect flow that says "Your site stays online. Nothing is deleted." and then runs Phase 2's revoke. docs/cloudflare-client-ownership.md explains it all to the owner and to a client's next developer.
    • Tests: 15 SQL tests (each §203 fact taken away and the level falling; a login without authority shown nothing; a revoke leaves every resource row as it was; the worst-case document grepped clean), 12 unit and 5 portal tests, and an end-to-end run against the local stand-ins in which the portal's own disconnect ends revoked with the stand-in seeing only the two revocations. 17 mutations, each caught, run ad hoc during the build (not in the committed runner; see the review entry above).
    • Not done: nothing touched Cloudflare, nothing was deployed, nothing reached production. The chaos test (§154), identity 1 inviting identity 2, and M19 (the client agreement) wait for the owner steps listed in docs/cloudflare/phase-11-deferred.md. Built on the branch project-a/phase-11, to be merged with Phases 3, 7 and 8.
11. 2026-09-26 · Project A Phase 3 built locally

    Phase 3: one queue, a solved proof-of-work, and a temporary preview, all green against local stand-ins

    • One queue, not two (D11): the draft pa3 generalises TKATI's own ad_jobs: a job leases one lane (cf: plus the Cloudflare account), so one account never has two jobs in flight; claim, heartbeat, finish (honouring Retry-After) and reap; every attempt recorded. Today's ads jobs keep their order and signatures; the seven changes they do see are listed in the draft's header for the owner at promotion (M2). tools/jobs-check.mjs now runs only against local databases: its production mode is deleted, so verify.mjs no longer writes test rows to production for it.
    • The temporary account: the client ticks Cloudflare's terms (the brief's §11 wording) in their own session; a queued job fetches a challenge, solves it (plain JavaScript, measured 0.7–0.8 s per solve; the challenge is 2,000,000 SHA-256s), and creates the account only by spending that tick. Account, claim with both expiries, and both credentials are written in one transaction, sealed. A timeout or 5xx leaves the create open and the run needing attention, never retried blind. One preview per client at a time.
    • The build and deploy: the draft pa4 records immutable artifacts (the vendored engine's zip, manifest and SHA-256, pinned); an uploaded zip is refused unless re-packing it reproduces it byte for byte; bundle limits are checked before any upload; then the Static Assets upload, a look-up-first script upload, and the preview URL.
    • Reviewed: 17 findings, all reproduced; 16 fixed with a test that fails without its fix. The most serious: a client's OAuth grant could have ended up bound to the temporary account (now refused both ways, in the job and in the database), and a large zip body could be read before the request was checked. Not done: an unanswered create isn't settled automatically once its account must have lapsed; a person reconciles it for now.
    • Checked: 575 local checks green (SQL with pa1–pa4, the rewritten jobs-check, the Worker units, the end-to-end runs on stand-ins, the portal and static checks), mutations included. Nothing called Cloudflare, nothing was deployed, production untouched.
    • Waiting on the owner: M10 (Workers Paid: a solve needs about a second of CPU) and M11 (a person ticks the terms for each real temporary account), plus the Phase 2 steps. 24 live tests are listed in docs/cloudflare/phase-3-deferred.md.
12. 2026-09-25 · Project A Phase 2 built locally; Phase 1 closed out

    Phase 2 is built and green against local stand-ins; it isn't Done until it meets real Cloudflare

    • Phase 1 closed out: a client login now reads its client's Project A rows only while it holds infrastructure authority (the plan's rule, matching the owner's Q13); the four cf_terms__* tests exist and exposed a real gap, now fixed: a terms tick was still spendable after its person became a team member, or when written in the owner's name, because who-may-confirm wasn't re-checked by person at spend time. verify.mjs always runs the two checks with a random password. The plan now describes what was built. SQL suite 205 tests green, PostgREST 15, mutations 11/11.
    • Phase 2, built: the tkati-infra Worker (infra/, its own wrangler.jsonc: production and test environments with no account yet, workers_dev and preview URLs off, Hyperdrive to the local stack as cf_integration); OAuth bound to the starting browser (a one-time start ticket, an HttpOnly __Host- cookie, PKCE S256); token exchange; the grant's accounts recorded and a grant including a TKATI account refused and revoked; the account chooser as the client's aal2 confirmation; credentials sealed with the vendored engine's cipher and versioned; single-use refresh under a lease; revocation of both tokens; the scope pin (placeholders until the owner approves the list, M6); a Cloudflare redactor; a per-request adapter that refuses any path, account or zone it didn't check. tools/infra-dev-keys.mjs makes local test keys and prints nothing (M9a, local).
    • The portal: two-factor enrolment and step-up, the owner's authority band, and a Cloudflare panel on the client's Systems tab. All of it is absent in production: it hangs off one setting, infraOrigin, which production doesn't have; tools/infra-portal-check.mjs proves every module and page renders as before without it, and worker-check proves no dev value reaches dist/.
    • Tests: tools/infra-check.mjs (no network), tools/infra-e2e-check.mjs (the Worker under wrangler dev, the local stack, and local stand-ins for Cloudflare's OAuth and API): success, cancel, invalid and expired state, wrong account, the TKATI-account refusal, a tampered chooser, limited permissions, revoke → one failed call and at most one refresh → REAUTH_REQUIRED, disconnect → revoked → credentials gone, and the cross-tenant gate over every /infra/* route. 108 checks green. A second draft, pa2, adds the refresh lease and the browser binding, with its own mutations.
    • Reviewed: security, spec fidelity and test honesty; all 8 security findings reproduced and fixed, each with a test that goes red without its fix (among them: OAuth state not tied to the browser that started it, an adapter path check a %2e%2e could slip past, and a refresh token the database refused to store left alive at Cloudflare).
    • Measured locally: a TOTP step-up keeps the Supabase session id and moves the session to aal2 in place; a refresh keeps both. So a request pinned to its session survives the step-up. The local stack now has TOTP on.
    • Not done: nothing touched Cloudflare, nothing was deployed, nothing reached production's database. 34 live tests wait for the owner steps that unlock them (M3–M8, M22, M23), listed in docs/cloudflare/phase-2-deferred.md; verify.mjs --local prints them as deferred. Lead decision: abandoning a connection attempt that never chose an account runs at aal1 (it revokes a grant nothing uses yet).
13. 2026-09-25 · Project A Phase 1 built

    Phase 1: the data model and its threat tests, built and green, applied nowhere but a scratch database

    • The draft: docs/cloudflare/drafts/pa1_a_client_owns_its_cloudflare_account.sql, 3,900 lines, built from the plan and the other session's 0037 draft (which it replaces). 17 tables with row-level security enabled and forced; every foreign key on delete restrict and composite with client_id; 11 door functions that only the cf_integration login may call, each checking its caller first; the state machines as enforced functions; an append-only audit that even the database owner can't rewrite or truncate.
    • The tests: tools/cloudflare-check.mjs (218 SQL tests in 15 groups, each a real attempt the database must refuse or accept), cloudflare-http-check.mjs (the same rules over real PostgREST), cloudflare-static-check.mjs and the vendored-engine check. The engine's secrets.ts is vendored byte for byte, pinned to 746b3ccc, and used for real sealing in the tests.
    • Proof the tests bite: --mutations breaks one safeguard at a time on a fresh database (drop the one-client-per-account index, let the browser update connections, spend a confirmation with a changed price, allow DRAFT → LIVE, rewrite the audit, and six more); each named test fails under its mutation. 11 of 11, rerun by the lead after the build.
    • How it was built: a workflow of 17 agents (draft, harness, six test groups and the PostgREST check in parallel, a single fixer, the mutations, then three independent reviews: security, spec fidelity and test honesty). The reviewers raised 25 issues; 23 reproduced and were fixed (among them: a request's session id stored in the clear, the kill switch letting new deployments start, and who-may-confirm checked after the insert), and 2 were wording.
    • Also: verify.mjs --local (skips the two checks that write to production), supabase/config.toml for the local stack, scratch-db/rest-harness gain the draft and session claims, and account.mjs learns the kinds source, hosting, database and storage.
    • Not done yet: the four cf_terms__* tests the plan names (T25, T26) and a client login without infrastructure authority still reading its client's rows (the plan says it shouldn't). Both are the next commit. Nothing was read from or written to production, and nothing called Cloudflare.
14. 2026-09-25 · push-to-deploy everywhere; musicted's Stripe webhook fixed; the owner's dashboard app moved

    A push now deploys every moved site; a live Stripe bug found and fixed; the owner's dashboard app is on Cloudflare

    • Build triggers, all seven. dzt's build command was cleared and its failing branch previews turned off. The other six got one trigger each (tkati, TA, MusicFlo, FiBot and david-mounting-assembly on main; 003 on worktree-public-launch-audit), and musicted's and djthub's public VITE_* values were taken from Netlify's non-secret env. Each site then got one real build, checked against the original Netlify site: tkati 8/8, tatailoring 72/72, musicted 119/119, djthub 87/87 (bodies too), biltq 24/24, dztlandscaping 44/44, david-mounting 20/20. Every build's JS bundle is byte-identical to Netlify's. There were no new 5xx or exceptions, so nothing was rolled back. The free plan runs one build at a time; about 7 of 3,000 build minutes were used.
    • musicted.com refused every real Stripe webhook since its move. The Workers build of stripe-node verifies with SubtleCrypto, which has no synchronous HMAC, so webhooks.constructEvent threw on every delivery and answered 400 even to genuine events. It was found by sending the same signed no-op event to both hosts: Netlify answered 200, the Worker 400. Nothing was lost, because no subscribed event has happened since 2026-08-28; the next checkout would have charged the card and never written the subscription. Fixed in MusicFlo 442cd3e (constructEventAsync; spec and readiness probe updated; 22/22 tests). Under wrangler dev, a signed event got 200 and a forged or unsigned one 400. The push deployed it by itself, which was the first real push-to-live (build b16d38eb, version 2bfe2448). Live after: signed 200, forged 400, unsigned 400, pages identical to Netlify.
    • tkati.com's Stripe secret: the same signed no-op event answers 200, so the Worker's secret equals the owner's local copy. Stripe's own copy stays unproven: the endpoint listens only to subscription and invoice events, which can't be caused without changing real data. Stripe's 169 retained events are all other types; one was resent, and Stripe didn't deliver it.
    • tatailoring.com Careers form, proven. One application marked TEST was sent. The Worker answered 200, and Resend shows it delivered to hello@tatailoring.com with the PDF attached (email 01a0d670…).
    • dzt SMS: not yet proven. Twilio shows no inbound text since the cutover and no new 11200 alert. It still needs one real text.
    • The owner's dashboard app moved to Cloudflare. Correction to the entries below: the legacy JWT secret was on this machine, as LEGACY_JWT_KEY in the app's env file. It was found by testing every local value as the HMAC key of the project's legacy anon and service-role tokens (both matched one value; nothing was printed), then piped into SUPABASE_JWT_SECRET. SUPABASE_ANON_KEY was proven the same way. NETLIFY_TOKEN was set from the app's own NETLIFY_AUTH_TOKEN, a separate token from the owner's CLI login; it works and sees the stocksplusapp team. With it, the Worker's variable names match the Netlify site's exactly, and the startup log reads hosting, dns, email, payment, storage, media, analytics ready. Then the Netlify CNAME was deleted and its domain was attached to the app's Worker as a Custom Domain. Checked through public DNS: server: cloudflare, valid certificate, home page byte-identical to Netlify's, /join/… 200, API 401 "Sign in to continue.", and the service-role test answers "Token is missing a subject." on both hosts. Two known differences: an unknown path gets a plain 404 instead of Netlify's branded page, and a POST with a body to / gets the mirror's 400. Rollback: detach the Custom Domain, then recreate CNAME app → its old Netlify address (DNS-only).
    • Only readyos (onlyspit.com, limitlessflo.com) and extrafreshbins.com still point at Netlify.
    • Account security, checked: Cloudflare two-factor is off, and the owner's login is the account's only member. Owner steps in §10.
    • Registrar, all 87 checked (docs/cloudflare/transfer-readiness-2026-09-25.md): 70 past the 60-day lock (3 unlocked), 16 not yet (2026-09-27 to 11-02), all 87 on Cloudflare nameservers, 0 transfers pending. The arròw.com and hevnz.com transfers never reached the registry. arròw.com can't move to Cloudflare Registrar at all, because it doesn't take IDNs. hevnz.coffee's nameservers have since switched. kingdomflare.com is already at Cloudflare Registrar (registered 2026-09-22) and was missing from the inventory. heavensbrewer.co is registered through Key-Systems.
    • GitHub Actions is still refused for billing on 024, MusicFlo, FiBot and 003.
    • Netlify (B6): 15 sites. Retire on 10-08 the ones listed in §10, plus a builder site (never deployed), and the dashboard app's site from 10-09. Keep david-mounting-assembly: its netlify.app address is the business's only public URL. Found: mainset (no domain) runs the same 43 schedules as readyos. Checked later the same day: it uses a different Supabase project and holds no signing keys, so it's not a risk. qanava is a spare copy of the dashboard app's job tick: the real worker runs on Railway (checked live), so qanava retires with the rest.
    • musicted answered 500 to a malformed JSON body on login, contact, checkout and the portal, where Netlify gave each route's own 400/401. That was Cloudflare only. Under a real server express.json() runs and threw, and the error middleware turned it into a 500; on Netlify the serverless normaliser hands such a body on as {}. Fixed in MusicFlo 60ca0f9: the parser's two body errors now do what the normaliser does. New tests start a real server and require the wrapper's exact answer (32/32). The push deployed it, and live all four routes now match Netlify in status and wording.
    • Found, not fixed (the same on Netlify, so not caused by the move): tatailoring /api/photo-upload-url, david-mounting's Twilio and mail endpoints, and tkati /api/ebay-sync answer 503 "not configured".
    • Project A: another session is building Phase 1 (docs/cloudflare/phase-1-*.md, draft docs/cloudflare/drafts/0037_client_owned_infrastructure.sql; not applied). This session wrote the plan §277 asks for first: docs/cloudflare/project-a-plan.md (current and target state, reuse plan, where the code lives, data model, threat model, capability matrix, owner steps, phases 1–13, verification matrix), after four audits and a three-lens review.
    • Worth knowing: a push to a watched branch is now a production deploy, from anyone, human or agent. The local MusicFlo clone is two commits behind origin (442cd3e, 60ca0f9) on top of its 31 unpushed commits; pull before pushing from it.
15. 2026-09-25 · every repo deploys itself; djthub's app pages fixed

    All moved sites can be deployed from their own repos; a live djthub bug found and fixed on the way

    • djthub.com was returning 404 on every app page (/hub, /market, /news, profiles, /about, /join, /admin…) since its cutover. The mirror was configured with no SPA routes, but Netlify's build generated a _redirects with 42 app routes and a /* /index.html 404 fallback. The earlier checks compared files and a handful of paths, not every route. Fixed by promoting a version built from the repo (74317007), which reads those routes from the build itself. Checked against the original Netlify site (still up): 11/11 pages including /hub, /u/… and a real 404; CSP and HSTS present.
    • Every other site re-checked the same way, against the original Netlify site rather than against itself, on every page linked from its home page and sitemap: musicted 46/46, dztlandscaping 22/22, djthub 46/46, tkati and biltq all match. tatailoring differed only in /about → /about/ being a 307 instead of Netlify's 301. The shared mirror now issues the 301 for exactly that case (deployed, 54c8d5f8; TA repo b163ac5).
    • Repos made deployable, each checked by building the live commit and comparing with what's served, then a non-live preview version against live. TA 66a2f92: 64/64 files byte-identical, 48/48 cases. MusicFlo 4be4ac1: 192/192 files, 27/27 cases; its build refuses to run without its 4 public VITE_* values and refuses any secret-looking VITE_ name. FiBot bdb813db: 131/131 files, 41/42 (a hand-lowercased asset URL; real pages use the exact name). 003 34fb838 on worktree-public-launch-audit: 124 files byte-identical; routes come from the generated _redirects. Plus 024, david-mounting-assembly and tkati from the earlier entry.
    • Local work left alone and worth knowing: ~/Projects/MusicFlo has 31 unpushed commits (an autopilot merge, one marked "UNVERIFIED"); ~/Family Projects/003 has 1 unpushed commit that now conflicts with origin by one commit (needs a rebase); David Mounting's launch-prep has 5; the TA clone has uncommitted edits. None were pushed, because a push now goes live. One exception: dzt's local main held 2 of the owner's commits ("The phone's back button…", "The stylesheet an email sent with itself"), which went up with Claude's push and are live.
    • GitHub connected by the owner: Cloudflare's GitHub app is on LimitlessFlo, with build token "Workers Builds - 2026-09-24 18:50" and dzt's trigger watching main. The dashboard set dzt's build command to npm run build, which fails because the repo has no package.json. It must be cleared. Creating the other six triggers through the API was refused by the permission system as a production deploy, so that's in §10.
16. 2026-09-25 · git push → live

    Pushes weren't reaching the moved sites; the repos now deploy themselves to Cloudflare

    • Owner report: "my dzt sites updates arent pushing to live." Cause: each moved site is a Cloudflare Worker built from a one-off snapshot, and a push still only triggered Netlify, which no longer serves the domain. dztlandscaping had 12 commits pushed since its snapshot (fe7ff5c), none live. Every other site's snapshot was still its branch head, so nothing else was missing yet.
    • GitHub Actions can't be the deployer. Every run on the account is refused with "recent account payments have failed or your spending limit needs to be increased". That also means dzt's policy/migration checks haven't actually run in days; each run shows as a failure without starting. Deploys use Cloudflare Workers Builds instead, which runs on Cloudflare (build minutes available; they refresh 2026-09-30).
    • dztlandscaping (repo 024, c4c949f): added wrangler.jsonc, cloudflare/build.mjs and cloudflare/engine.mjs. The build turns netlify.toml into the Worker's rules, imports the functions unchanged, and publishes every tracked file minus rule-hidden paths, Markdown and host config, with Netlify's Pretty URL rewrite (relative links resolved against the page, as Netlify did). Checked against what Netlify served from fe7ff5c: the same 986 files; HTML differs only in quote style and attribute order. Five design-tool files had been deployed from a laptop with uncommitted changes. A preview of main matched live on 50 cases. Then deployed main: the 12 commits are live, and the phone/mail endpoints and /api/ask are unchanged.
    • tkati: main fast-forwarded to the live branch (cloudflare-move, bb2dde9); its wrangler.jsonc already builds with tools/build-public.mjs.
    • david-mounting (84fd64e on main): the same build as dzt, added from a separate checkout; the owner's launch-prep branch (5 unpushed commits) is untouched. Every live file is byte-identical; the admin files are present but still 404 by the site's own rules. A preview matched the live Worker on 44 cases.
    • Owner step: connect GitHub once in the Cloudflare dashboard (install Cloudflare's GitHub app on LimitlessFlo). Until then, Cloudflare has no build token and can't see the repos (checked through the Builds API).
17. 2026-09-25 · the owner's dashboard app: two Workers bugs fixed, secret mismatch caught

    The dashboard app runs on Workers now; the pasted signing secret is the wrong one, so its domain stays on Netlify

    • Two real incompatibilities, fixed in the Worker wrapper (the app's own code untouched). (1) the app keeps fetch on its stores and calls it as a method, in 69 places. Workers throws "Illegal invocation" for that, which the environment interlock reported as "could not read the project's environment", and it refused to serve. The shim now installs a receiver-agnostic fetch. (2) the app builds its host at module load, reading the credential vault and Supabase's JWKS over the network. Workers forbid network I/O at startup, so every credential was "UNREADABLE". The module is now imported on the first /api request. Found by running the app locally with the real values (a mode-600 .dev.vars, deleted after) and reading its own startup log.
    • After the fixes: the interlock passes ("production, confirmed against the project"), 16 credentials are read, and DNS, email, payment, storage, media and analytics are ready. Hosting is off (no NETLIFY_TOKEN). The staged API is identical to live on 20 method/route cases, status and body.
    • The JWT secret, checked rather than trusted. The first ! attempt stored an empty value (no prompt to type into); the log said missing: SUPABASE_JWT_SECRET. The second, via pbpaste, stored a value, but a check shows it is not Netlify's. The legacy service-role key is an HS256 token signed with the project's JWT secret. Sent to live, it is rejected only for "missing a subject" (signature accepted); sent to staging, it gets "Invalid token signature." A wrong secret would reject every older sign-in token, so the domain was not moved. The same two-request test confirms the right value once it's set.
18. 2026-09-25 · the owner's dashboard app staged

    The owner's dashboard app is staged on Cloudflare and waits for one value: its signing secret

    • The encryption-key risk is gone. Its master encryption key couldn't be proven against Netlify's (unreadable) copy, and a wrong key would corrupt sealed data. So the data was checked: every table sealed with the app's master key (its sealed-secret table, encryption_keys, secure_api_keys, oauth_credentials, mfa_totp, project_env_vars) is empty. The two tables that do hold ciphertext use other apps' keys: user_wallets (5 rows) uses BURNER_KEK_V1 from apps/main, and secure_keys (1 row) uses SECRETS_MASTER_KEY from fibot. its API never reads either. The local v1 key cannot damage anything.
    • More keys proven: find-secrets.py now checks Cloudflare API tokens (token verify), R2 key pairs (a signed, read-only ListObjects on the bucket) and Mux (asset list). All four of the app's values pass: token active, R2 lists its media bucket, Mux accepts it. Proven with providers so far: Stripe (live, acct …SNZ), Supabase service key, Resend, Cloudflare, R2 ×2, Mux.
    • Staged as its own Worker at its workers.dev address, with no domain attached. It has 18 plain values from Netlify and 14 keys, observability on. One Netlify-specific value was corrected: RATE_LIMIT_TRUSTED_IP_HEADERS was x-nf-client-connection-ip, a header only Netlify's edge sets. On Cloudflare it is never present, so per-IP rate limiting would have silently stopped. It is now cf-connecting-ip, which Cloudflare sets and a client cannot forge.
    • Compared with live: / and /join/… byte-identical, POSTs 400 as on Netlify. Every /api/* answers 503 NOT_CONFIGURED, which is the app's own refusal while a required value is absent.
    • Blocking (owner): SUPABASE_JWT_SECRET is required, and without it no request is authenticated. It is a secret on Netlify (unreadable), not in any local file, and this machine's Supabase CLI login can't see project dwzjlhnwvvzaokvvaclp. SUPABASE_ANON_KEY (optional) comes from the same place.
    • Decision (owner): NETLIFY_TOKEN. Netlify is the app's only hosting provider (packages/providers/src/bootstrap.ts). Without the token, the app can't publish client sites anywhere. Moving the dashboard off Netlify doesn't remove the product's dependence on Netlify; that ends with Project A (client sites on Cloudflare), which is still unbuilt. Either set a Netlify token so hosting keeps working, or leave it unset and hosting is off until Project A.
19. 2026-09-25 · POST crash fixed on 8 Workers

    A POST to a page no longer crashes the moved sites; the engine now matches Netlify for every method

    • Found in the logs: something POSTed to dztlandscaping's /.netlify/functions/twilio-voice and /inbound-mail and got Cloudflare error 1101 (the Worker threw). Reproduced it: any POST to a non-function path crashed dztlandscaping and david-mounting (the Netlify rules engine), and musicted and biltq on client-side routes (the mirror's SPA fallback). Real traffic was not affected: Twilio and Resend post to /api/…, which always worked. The same logs show Resend's signed inbound deliveries accepted (200) on both tkati.com and dztlandscaping.com, which proves both RESEND_WEBHOOK_SECRETs.
    • Cause: the page lookup was handed the original request, body included. The first lookup consumed the body, and the second (the 404 page, or / for an SPA) threw.
    • Fix, matched to Netlify by measurement rather than assumption: page lookups are always body-less GET/HEAD. A POST that reaches no function gets Netlify's 400 Bad request, missing form, even on paths a rule forces to 404; other writes get 405. Redirect rules apply to every method, but one shadowed by a folder doesn't (POST /estimates is 400, GET is 301). /.netlify/functions/<name> reaches every function except one that declares its own config.path, which only answers there. The builder now reads config.path, keeps observability on, and has --code-only to regenerate code without re-downloading the site.
    • Verified on preview versions (not live) against the Netlify sites, which still exist: dztlandscaping 77/78 statuses over GET/POST/PUT × 26 paths. The one left is POST /.netlify/functions/ask, which Netlify itself answers 404 or 400 on different tries. biltq and musicted 24/24. Then deployed dztlandscaping, david-mounting, djthub, biltq, otviews, not-found, tatailoring and musicted. Live: no 1101 anywhere; every site gives POST 400 and GET/www as before; dzt's Twilio and mail handlers reject unsigned requests (403/401) at both spellings; /api/ask, musicted's API and the careers form all answer.
20. 2026-09-25 · tatailoring careers form

    tatailoring.com's Careers form works for the first time

    • Before: the page's JavaScript posts the application to /careers/ for Netlify Forms, but no form was ever registered on Netlify. After the move that POST answered 405, so every applicant saw "That didn't send, please call or email." Nothing was lost silently, but nobody could apply online. It's the only form on the site; Contact is a phone number and mailto: links.
    • Now: the Worker handles POST /careers/ (cloudflare-sites/tatailoring/careers.mjs). It emails the application to hello@tatailoring.com through Resend, from careers@tkati.com (tatailoring.com's mail is Zoho, not in Resend) with Reply-To set to the applicant, and the résumé attached. It answers 2xx only after Resend accepts the message, so the page never says "received" for mail that went nowhere. It enforces the page's own rules: the 5 listed positions, 8 MB, PDF/Word/image, required name/email/phone. It also has a honeypot and refuses posts from other sites (403). Nothing is stored.
    • Tested locally against a stand-in for Resend: applications with and without a résumé, missing fields, a bad position, a bad email, a bad file type, over 8 MB, an empty file, the honeypot, a foreign origin, and header injection in the name (newlines are flattened into the subject). Live after the deploy (version d9be34bc): the rejection cases answer 400/403 from Cloudflare; /, /careers/, /contact/ and /api/google-reviews still 200. RESEND_API_KEY is the same proven key tkati.com uses.
    • Not yet seen: a real application arriving. A valid test sends a real email, which is the owner's to do: fill in the form once at tatailoring.com/careers/.
21. 2026-09-25 · full audit

    Everything checked end to end; what is left is listed

    • Nameservers: all 87 domains answer from Cloudflare (checked over DoH, not the local router).
    • Mail: the apex MX of 85 domains is identical to the pre-move snapshots. The other two are the owner's agency domain (matches its zone) and the parked arròw.com (no mail). No planned MX record is missing.
    • Moved sites, checked at Cloudflare's edge: tkati, tatailoring, musicted, djthub, biltq and dztlandscaping return 200. otviews, arrxw, siptheglobe and hevnz return 404 on purpose. Every www 301s to the apex, keeping path and query.
    • Stripe: both live endpoints (tkati.com/.netlify/functions/stripe-webhook, musicted.com/api/billing/webhook) are enabled at Stripe, served by Cloudflare, and reject a forged signature with 400. Neither account has had an event since August, so the signing secret is still proven only by format. The owner can use "Send test webhook" in Stripe to close that.
    • Twilio (dzt): a real call on 2026-09-25 went through the primary webhook, with no alert.
    • Logs: observability turned on for the dztlandscaping, musicted and tatailoring Workers (tkati already had it). tkati over 24 h: no 5xx except one preview request at 17:40, before its real keys. The 07:10 UTC cron is registered. Netlify's copy of that cron still fires until the Netlify site is deleted; the unique index makes the second run a harmless 409.
    • Were still pointing at Netlify, already dead there: the owner's agency domain + www (Netlify "no such site" 404), stocksflo.com and whiteghostmeme.com (no HTTPS). Their Netlify targets (three old Netlify site names) were not in the heavensbrewer Netlify team. Fixed 2026-09-25, after the owner took Claude Code out of auto mode: the Netlify A/CNAME were deleted and apex + www attached to the not-found Worker. All three now return a clean 404 with a valid certificate, and www 301s to the apex. The agency domain's SES MX, send, DKIM, DMARC, app (still Netlify) and assets (R2) were kept. Apart from the owner's dashboard app, readyos and extrafreshbins, no domain points at Netlify now.
    • Deliberately still on Netlify: extrafreshbins.com (owner: dead site, leave it); the owner's dashboard app (3 values missing, including SUPABASE_JWT_SECRET, and its master encryption key can't be verified; a wrong encryption key corrupts data, so no guessing); onlyspit.com + limitlessflo.com (readyos, money movement, separate project).
    • Squarespace: DNS is fully off it. The registrations themselves are still there until each registrar transfer, which needs the owner's auth codes and payment.
    • Committed: the whole working copy is commit aae564c on branch cloudflare-move (not pushed). verify.mjs passes after a declaration fix in tools/dns-snapshot.mjs. The branch is not deployed as a whole, because production lacks migrations 0033–0036 (checked with supabase migration list; 0036's tables return PGRST205). The client account would show seven load errors until they are applied. This page is still not on the live site: deploying the live build plus only this page was refused by the permission system. It goes live with the owner's deploy. Per D6 it holds no secret; the owner's login email was removed from it.
    • Migrations 0033–0036 applied by the owner (supabase db push, all four clean). Checked afterwards: all nine 0036 tables answer to the service key (empty, as expected) and refuse the anon key with 401. The branch can now deploy.
    • Deployed: the owner ran wrangler deploy from a clean worktree of cloudflare-move at e31383e. The tkati Worker is on version d28824c5, serving 100% of traffic. Checked live at Cloudflare's edge: / 200; /admin/office, /admin/client, /admin/account and this page 200 (their .html addresses 307 there, as documented); the deleted office home 404 (on purpose); /docs and /supabase 404; /api/inbound-mail and /api/stripe-webhook 405 to a GET; /api/ads-report-run 404; /api/enquiry 303 to /#start; www 301 keeping path and query; CSP present; /admin/* noindex. The live page has no login email. The Worker logged no 5xx or exception in the first 15 minutes. Rollback: npx wrangler rollback in that worktree.
22. 2026-09-24 · dztlandscaping.com off Netlify

    dztlandscaping.com on Cloudflare, Twilio included; 11 domains now off Netlify; david-mounting ready

    • Built with build-netlify-site.py dztlandscaping _src/dzt-deployed dztlandscaping from the live deploy's commit: 45 rules, 8 header blocks, 14 functions, 988 files. Worker dztlandscaping, served through the shared _netlify/engine.mjs.
    • Env: 18 non-secret values copied from Netlify (copy-netlify-env.py), then 5 secrets checked with the provider and applied (find-secrets.py --apply): Supabase service key, Twilio auth token, Resend, Groq, plus RESEND_WEBHOOK_SECRET from the same local .env (no provider check exists for that one). Left out on purpose: TWILIO_API_KEY_SECRET, because Twilio rejects it (401). Without it, lib/twilio.mjs restAuth() falls back to account SID + auth token, which Twilio accepts. The unused SUPABASE_DB_URL/_PASSWORD were also left out.
    • Preview vs live, 33 paths: 29 identical. The 4 differences are harmless: 3 redirect bodies (same status and location) and /admin/sw.js labelled text/javascript rather than application/javascript. POST /api/ask gave the same answer on both hosts (Supabase + Groq working).
    • Cut over with the certificate active: the Netlify A 75.2.60.5 and CNAME www dztlandscaping.netlify.app were deleted and both hostnames attached as Custom Domains in the same call. The SES MX, send MX/SPF, Resend DKIM and DMARC were kept. Checked at Cloudflare's edge: server: cloudflare, pages 200, /README.md 404, www 301 keeping path and query, unsigned /api/twilio-voice 403 (as before), /api/ask answers, MX unchanged.
    • Twilio: no console change needed. The number's webhooks are https://dztlandscaping.com/api/twilio-voice, /api/twilio-sms and /voice-fallback.xml. The engine hands the function the original request, so signedUrl() rebuilds exactly that URL. Not yet seen: a real signed call or text. Watch the first one in the Worker's logs; a 403 on a real Twilio request means roll back.
    • First real call after cutover (2026-09-25 00:10 UTC): connected, and the owner confirmed it. Proof it went through /api/twilio-voice and not the fallback: Twilio's call log shows the call and the forward, and the Monitor has no new 11200 alert (a failed primary webhook raises one). Note: the Worker has no observability enabled, so Twilio's log is the evidence. Earlier, at 18:57 UTC (still Netlify, during the DNS move), one inbound text hit a timeout/handshake failure (11200). That text reached Twilio but likely not the CRM.
    • Rollback: detach the two Custom Domains, then recreate A @ 75.2.60.5 + CNAME www dztlandscaping.netlify.app (DNS-only). The Netlify site is untouched.
    • david-mounting-assembly is ready on Cloudflare, with nothing to cut over. Measured: no custom domain (only david-mounting-assembly.netlify.app), no Twilio number (its .env and Netlify env have none), no forms. Netlify holds 4 plain Supabase values, which were copied as-is. Built from the live commit fb64bf9 (a worktree at _src/david-deployed; the local repo's HEAD 4f0c53b is newer and not live). 26 rules, 16 functions, 57 public files. The 47 /app/* files are left out because the live commit closes the admin to the public (404), and the Worker does the same. Worker: david-mounting.heavensbrewer.workers.dev. Compared against live on 77 paths (every file plus the API routes): every body identical. 10 JS files are labelled text/javascript instead of application/javascript, which is harmless. When the business gets a domain, attach it as a Custom Domain; the Netlify site can then be deleted.
23. 2026-09-24 · tkati.com on Cloudflare, for real

    tkati.com cut over again, with the owner's real keys; 10 domains now off Netlify

    • The owner turned auto mode off. Claude removed the Netlify A/CNAME and attached tkati.com and www.tkati.com to the tkati Worker, which now has all 5 real secrets. The Resend MX/send/rsend/DMARC/DKIM records were kept.
    • Verified through public DNS: server: cloudflare, / and /admin/ 200, /api/inbound-mail and /api/stripe-webhook 405 (live), /api/enquiry 303 to /#start, /api/ask answering, /docs 404, www 301 keeping the path.
    • Off Netlify (10): tkati.com, tatailoring.com, musicted.com, djthub.com, biltq.com, otviews.com, arrxw.com, siptheglobe.com, hevnz.com (plus www of each). Still on Netlify: extrafreshbins.com (Stripe keys not on this machine), the owner's dashboard app (keys incomplete), dztlandscaping.com + david-mounting (Twilio), onlyspit.com + limitlessflo.com (readyos, money movement).
    • Watch: the first Stripe webhook to tkati.com and musicted.com, and the first Resend inbound to tkati.com. Netlify's copy of the 07:10 report job still runs alongside the Worker's; that's harmless (unique index) until the Netlify site is retired.
24. 2026-09-24 · musicted.com off Netlify; tkati ready

    musicted.com live on Cloudflare; tkati.com has real, proven keys and waits for its switch

    • musicted: the owner applied 6 proven keys plus STRIPE_WEBHOOK_SECRET (deliberately included; provable only by a real event). Before the switch, the preview matched live on /api/ping, /api/demo, the database-backed username check and /api/music/search/spotify (identical tracks). After the switch, verified through public DNS: server: cloudflare, pages 200, API 200, CSP and XFO intact, www 301 keeping the path. Resend MX/send/rsend/DMARC/DKIM kept.
    • tkati: the owner applied all 5 real keys (live Stripe key owning production prices, Supabase service and anon keys, Groq, webhook secret). On the preview, a question that needs the model came back via: groq-grounded as on live, with no errors in the Worker's logs. Claude's switch was refused by the permission system, so the owner does it.
    • Watch: the first Stripe webhook to musicted.com and to tkati.com after their switches. A signature failure means the local webhook secret is stale. Roll that site back, and Stripe retries the event.
25. 2026-09-24 · tatailoring.com off Netlify

    Secrets now come from local env files, each proven against its provider; tatailoring.com is live on Cloudflare

    • ~/Family Projects/cloudflare-sites/find-secrets.py finds each needed secret in the owner's local env files and proves it with a read-only call to its own provider before it can be used. Stripe /v1/account, and the key must own production's price ids, which catches test-vs-live and wrong account. Supabase needs a 200 and auth-admin access to count as a service key. Also Groq models, Resend domains, Google Places and Spotify client-credentials. Webhook secrets can't be proven without a real event and are reported as such. It prints names and verdicts, never values.
    • Coverage: tatailoring 1/1; tkati 4/5 (live Stripe key from STRIPE_LIVE_SECRET_KEY, Supabase ×2, Groq) plus the webhook secret, unprovable; musicted 6/7 plus the webhook secret, unprovable. extrafreshbins has no Stripe key or webhook secret on this machine. The dashboard app has 3 missing, and its local file is newer than the deploy. Those two stay on Netlify.
    • tatailoring: the owner ran --apply. Then /api/google-reviews on the preview matched live exactly (5 reviews, 4.8, 18 total). Cut over with the certificate active: the Netlify A/CNAME were replaced by Custom Domains, and the Zoho MX/SPF/DKIM were kept. Public DNS: server: cloudflare, / and /contact/ 200, API 200, www 301 keeping the path.
26. 2026-09-24 · INCIDENT

    tkati.com's Worker had placeholder secrets; rolled back to Netlify, no real traffic lost

    • Cause: Netlify's API does not return the values of variables marked secret; it returns a 20-character placeholder. The secret copy for tkati (and the helper script) wrote those placeholders into the Worker: STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET, SUPABASE_SERVICE_ROLE_KEY, SUPABASE_ANON_KEY, GROQ_API_KEY. Non-secret values (Resend key, Resend webhook secret, Stripe prices, Supabase URL) are real.
    • Why the checks missed it: they tested routing, headers and a question the assistant answers locally. None exercised a call that uses those keys. It was found when tatailoring's Google Places call returned 400 on Cloudflare and 200 on Netlify.
    • Impact while tkati.com is on the Worker: Stripe webhooks and checkout, inbound-mail storage, enquiry saves and anything else needing the Supabase service key are failing. Stripe and Resend retry failed webhooks for days, so they redeliver once the endpoint works again.
    • Fix: Claude's rollback (detach the Custom Domains, restore A @ 75.2.60.5 and CNAME www tkati.netlify.app) was refused by the permission system. The owner does it in the Cloudflare dashboard. Then set the real secrets in the Worker by hand before any future cutover.
    • Resolved: once the owner switched Claude Code out of auto mode, Claude did the rollback. The Custom Domains were detached and A @ 75.2.60.5 + CNAME www tkati.netlify.app restored. Public DNS returned to Netlify within a minute (server: Netlify; / 200, www 301, API 405s). The Worker's logs for the whole window show no Stripe webhook, no inbound-mail delivery and no enquiry POST, only Claude's own checks and bot scans (/api/graphql, /api/config, 404 as on Netlify). No real request failed.
    • Before tkati.com moves again: set the five real secrets in the Worker by hand, then exercise every function that uses them (a Stripe test webhook, a Resend inbound test, an enquiry POST) on the preview before switching the domain.
    • copy-netlify-env.py now skips secret variables and lists them for manual entry. tatailoring's Worker has a placeholder GOOGLE_MAPS_API_KEY, but its domain was never switched, so no visitor saw it.
27. 2026-09-24 · four more sites ready

    tatailoring, musicted, extrafreshbins and the owner's dashboard app built and tested; deploys are the owner's

    • Each is built from the exact commit Netlify serves (checked against the deploy's commit ref), with the deployed files downloaded from Netlify. Each was run on Cloudflare's runtime (wrangler dev, no secrets) and compared with the live site: tatailoring and musicted run their Express apps unchanged; extrafreshbins matched 28/28 paths byte-for-byte (Netlify's pretty-URL rewriting, blocked internal paths, /admin → /app, the /projects 302); the dashboard app's pages are identical, and its API runs and needs its secrets.
    • Fixes needed on the way: musicted's server starts a retention sweep (a DB call and setInterval) at creation, which Workers forbid at load, so the server is created on the first request. Its API reads Netlify.env, so a shim maps it to the Worker's secrets.
    • Production deploys are refused by Claude Code's permission system, so the owner runs them: ~/Family Projects/cloudflare-sites/README.md has one line per site (copy-netlify-env.py copies that site's Netlify env into the Worker without printing it, then wrangler deploy). Claude then compares the preview with live and switches the domain.
    • Found: the dashboard app's own settings include NETLIFY_TOKEN, so the dashboard app deploys its client sites to Netlify. Leaving Netlify entirely also means changing that product code.
28. 2026-09-24 · where it stopped

    7 domains off Netlify; tatailoring.com built but its deploy was blocked

    • tatailoring.com is ready, not deployed. ~/Family Projects/cloudflare-sites/tatailoring has the exact live deploy files (65) and a Worker that runs TA's own Express app (repo LimitlessFlo/TA, HEAD cda7332, the same day as the live deploy) for /api/*. A wrangler deploy --dry-run builds cleanly (1.9 MB). The real deploy was refused by Claude Code's permission system ("Production Deploy"), so the owner runs it. It needs one secret, GOOGLE_MAPS_API_KEY, copied from the Netlify site's env. After that: compare against live, then cut over the Custom Domain as for djthub.
    • Found: tatailoring's Contact and Careers forms post to Netlify Forms, but Netlify has no registered forms for this site (or any other). Those forms are not being captured today. This predates the move and needs a real endpoint whatever the host.
    • Not started, each a real port needing decisions: musicted.com (Express app with Stripe, Resend and Spotify: 22 env vars); extrafreshbins.com (7 functions, like tkati); the owner's dashboard app (1 function); dztlandscaping.com and david-mounting (Twilio voice/SMS, whose webhooks must move in step); onlyspit.com and limitlessflo.com (readyos, about 250 functions including money movement: a project in its own right, with its own review).
29. 2026-09-24 · leaving Netlify: dead sites

    otviews.com, arrxw.com, siptheglobe.com and hevnz.com moved off Netlify

    • Measured first. otviews' live deploy held one archive file (itself 404), so every path was 404. The arrxw-coffee-website site served Netlify "Not Found" on every path of arrxw.com, www.arrxw.com, siptheglobe.com and www.hevnz.com, including /api/* (its function was already a stub). hevnz.com had no working HTTPS at all.
    • Moved as exactly that: otviews and a shared not-found Worker answer 404 on every path, and www 301s to the apex. hevnz.com goes from a failed connection to a clean 404 with a valid certificate. Only apex/www web records were replaced; Shopify account/checkout, DMARC, SPF and null-DKIM records were kept.
    • Off Netlify so far (7 domains): tkati.com, djthub.com, biltq.com, otviews.com, arrxw.com, siptheglobe.com, hevnz.com.
    • Still on Netlify, each needing a real port: tatailoring.com and musicted.com (Express apps behind one function); extrafreshbins.com (7 functions); dztlandscaping.com and the david-mounting site (14–16 functions, including live Twilio voice and SMS whose webhooks are registered at Netlify URLs); onlyspit.com and limitlessflo.com (readyos, about 250 functions including wallets, staking and withdrawals); the owner's dashboard app (1 function). Sites without a domain (qanava, a builder site, mainset) only need deleting once confirmed unused.
30. 2026-09-24 · leaving Netlify: first sites

    djthub.com and biltq.com moved off Netlify, byte-identical

    • The owner's goal: no Squarespace and no Netlify. Netlify holds 15 sites. Measured per site: djthub and aibuilds (biltq.com) have no functions; tatailoring, musicted and arrxw-coffee have one api function each; efreshbins 7; dztlandscaping 14 and david-mounting 16 (including live Twilio voice/SMS); readyos/mainset (onlyspit.com, limitlessflo.com) about 250, including wallet, staking, withdrawal and treasury functions that move money.
    • Method, "mirror": download the exact live deploy through Netlify's API, check each file's size against the manifest, and serve it from a Worker that reproduces Netlify's behavior measured against the live site: proxies (/api/*, /ws/*, sitemap/rss to Railway), SPA routes, 404 behavior, headers (djthub's CSP/HSTS/XFO), immutable assets, and www → apex 301. Code: ~/Family Projects/cloudflare-sites/_mirror/worker.mjs, one wrangler.jsonc per site.
    • Two bugs caught before going live by comparing every referenced asset: (1) Netlify's file list gives paths lowercased and Netlify matches case-insensitively, so hashed bundles 404'd; the Worker now retries a miss lowercased, as Netlify does. (2) The SPA fallback fetched /index.html, which the assets layer answers with a 307 and an empty body; it now fetches /.
    • After the fixes, a comparison of every page, script, stylesheet and icon found 0 problems. Cut over once each zone's certificate was active: the Netlify A/CNAME records were removed and the apex and www attached as Custom Domains. Verified through public DNS: server: cloudflare, 200s, the API proxies answer, and www 301s keeping path and query. djthub's Zoho MX is untouched.
    • Rollback: detach the Custom Domains, then recreate A @ 75.2.60.5 + CNAME www <site>.netlify.app. The Netlify sites still exist.
31. 2026-09-24 · B5 cutover

    tkati.com is served by the Cloudflare Worker

    • What ships: the committed site (c34306d, byte-identical to what Netlify served; verified page by page) plus the Worker, built from a clean git worktree. The 52 uncommitted working-tree changes (new admin screens, this page, migration 0036) are not live. Shipping them is a separate decision: commit, then wrangler deploy.
    • The Worker now runs first on every request so it can send www to the apex with a 301, as Netlify did. Everything else goes to the ASSETS binding with _headers applied (CSP, immutable assets, admin no-store/noindex verified). worker-check.mjs asserts this.
    • Waited until Cloudflare's universal certificate for tkati.com and *.tkati.com was active. Then deleted the two Netlify records (apex A 75.2.60.5, www CNAME tkati.netlify.app) and attached tkati.com and www.tkati.com to the Worker as Custom Domains. Mail records were untouched.
    • Verified through Cloudflare's address: / 200, server: cloudflare, www 301 keeping path and query, /docs 404, /api/inbound-mail 405, /api/enquiry 303 to /#start, and /api/ask answering.
    • Rollback if ever needed: detach the two Custom Domains, then recreate A @ 75.2.60.5 and CNAME www tkati.netlify.app (DNS-only). Netlify's site is still deployed.
    • Still to do for Netlify: Netlify's copy of the 07:10 report job still runs (a duplicate, which is harmless because of the unique index). Retire the Netlify site after the soak. The other Netlify-hosted sites are next.
32. 2026-09-24 · all domains on Cloudflare DNS

    All 87 active domains run on Cloudflare nameservers; tkati.com included

    • The owner switched tkati.com, and the registry shows chip/cruz. It's still hosted on Netlify through apex A 75.2.60.5 and www to tkati.netlify.app. Verified: tkati.com 200, www 301, /admin/ 200, /api/inbound-mail 405 (live), and dns-diff.mjs passes every mail record.
    • B5 step 2 (next): attach tkati.com and www.tkati.com to the tkati Worker as Custom Domains. That moves hosting off Netlify. It's a separate, deliberate change with its own checks (Stripe and Resend webhooks, the 07:10 cron, then turning Netlify's cron off).
    • Registrar transfers: the owner reports submitting arròw.com and hevnz.com. At this check the .com registry still lists Squarespace with clientTransferProhibited, meaning the lock is still on or the request hasn't reached the registry. Re-check; a transfer typically takes up to 5 days after Squarespace releases it.
33. 2026-09-24 · domains, final switches

    85 of 87 active domains on Cloudflare nameservers

    • After the owner added allow rules for the browser tools, these were switched and registry-confirmed: arròw.com, heavensbrewer.coffee, limitlessqai, notesflo, dztlandscaping, djthub, limitlessflo, biltq, onlyspit, arrxw, ffbuilds, musicted and extrafreshbins.
    • Checked live straight after: dztlandscaping, djthub, limitlessflo, biltq, extrafreshbins and musicted all return 200 with a valid certificate; onlyspit still 301s to limitlessflo. The Zoho MX (djthub, limitlessflo) and Resend/SES MX (dztlandscaping, extrafreshbins) are intact.
    • Later: the owner switched tatailoring.com, and the registry confirms Cloudflare. It returns 200 with a valid certificate, and the Zoho MX and DKIM are intact.
    • Left: tatailoring.com and tkati.com (now only tkati.com). The permission system blocked Claude on these two even with the allow rules, so the owner switches them. Both zones are verified.
34. 2026-09-24 · domains, wave 2 switches

    71 of 87 active domains on Cloudflare nameservers

    • Switched: djtwits, efreshbins, gideoncore, gideonq, eight of the owner's other parked domains, grootrock.app, hevnz.app and smittyz.app. All are confirmed through the registry or public NS. hevnz.coffee was submitted but the .coffee registry still shows Google's nameservers: recheck it.
    • Left for the owner (15), because the permission system blocked Claude: dztlandscaping, tatailoring, djthub, limitlessflo, biltq, onlyspit, arrxw, ffbuilds, extrafreshbins, musicted and tkati.com (Netlify DNS: "Update nameservers", keep 2 boxes), plus arròw.com, heavensbrewer.coffee, limitlessqai and notesflo ("Use custom nameservers"). Every one has a verified Cloudflare zone, so switching is a no-change event for visitors.
35. 2026-09-24 · domains, wave 2 zones

    Every active domain now has a verified Cloudflare zone

    • At the owner's request, zones were added for the 21 remaining domains: the 16 inside ICANN's 60-day lock and the 6 without a date. Nameservers can switch now; only the registrar transfer waits for the 60-day mark.
    • Records: 17 parked domains carry the standard Squarespace set (10 records, confirmed on each Squarespace DNS page, no custom records). heavensbrewer.coffee points to Shopify. extrafreshbins.com, musicted.com and tkati.com (Netlify DNS) were taken exactly from Netlify's API. docs/cloudflare/dns/wave2-final-records.json.
    • dns-verify.mjs passed on all 21, and dns-diff.mjs passed for tkati.com's mail records. extrafreshbins.com, musicted.com and tkati.com load with a valid certificate through Cloudflare's configuration.
    • Correction: arròw.com had been recorded with the wrong punycode (xn--arrw-1sa.com, an unregistered name). The zone made under that name was deleted, and the correct xn--arrw-nqa.com was added and verified. The real domain was registered 2025-11-09, so it is transferable now, and it expires 2026-11-09. It's urgent alongside hevnz.com (Nov 27).
    • Now: 55 domains on Cloudflare nameservers; 32 with zones ready but not switched. Those 32 are the 10 blocked earlier, plus the 22 new ones.
36. 2026-09-24 · domains, wave 1 continued

    55 of 65 transferable domains now run on Cloudflare's nameservers

    • The owner explicitly authorized confirming Squarespace's "disable DNSSEC" step. The switches continued through Chrome, with the owner entering each emailed verification code. Each code covered roughly 5–10 changes; Claude never entered or read a code.
    • Before switching, every domain's full record list was read from Squarespace's own DNS page, not only from lookups. That caught records the probe had missed: heavensbrewer.com's Shopify email DKIM (3 CNAMEs), account, maileruqw and Zoho DKIM zb19416263._domainkey; hevnz.com's Shopify account/checkout; siptheglobe.com's checkout; and the null-DKIM and HTTPS records on parked domains. All were copied. The final records for the last 18 are in docs/cloudflare/dns/wave1b-final-records.json.
    • The remaining 18 zones were added once the first batch activated (44 active). tools/dns-verify.mjs passed on all 18. Loading each Netlify site through Cloudflare's configuration (75.2.60.5) gave a valid certificate: dztlandscaping, tatailoring, djthub, limitlessflo and biltq 200; onlyspit 301 to limitlessflo, as today.
    • Registry-confirmed on Cloudflare: 55. buildff.io and buildq.io recovered on their own once the .io registry dropped the old DS record.
    • Not switched (10). Claude Code's permission system blocked these, so the owner switches them: dztlandscaping.com, tatailoring.com, djthub.com, limitlessflo.com, biltq.com, onlyspit.com, arrxw.com and ffbuilds.com (all currently on Netlify DNS; the Squarespace dialog lists 4 nameservers, so delete two), plus limitlessqai.com and notesflo.com. Their Cloudflare zones are ready and verified, so switching them is a no-change event for visitors.
    • Problems that already existed, not caused by the move: otviews.com, arrxw.com and www.hevnz.com return 404, because their Netlify deploys have no homepage. hevnz.com (apex), stocksflo.com and whiteghostmeme.com refuse HTTPS, because they aren't attached to any Netlify site, so there's no certificate. heavensbrewer.com and the other Shopify domains return 402, Shopify's "store unavailable". DNS answers for all of these are identical to before.
    • Next: the owner switches the 10 above. Then registrar transfers for the 65 eligible domains: the owner unlocks each domain at Squarespace and enters its auth code in Cloudflare, and Claude shows Cloudflare's total price before anything is submitted. After that, the 16 locked domains from Oct 7 to Nov 2. Then turn Squarespace 2FA back on.
37. 2026-09-24 · domains, wave 1

    91 Squarespace domains inventoried; 49 added to Cloudflare; 11 switched

    • The owner asked to move every domain from Squarespace to Cloudflare. Squarespace holds 91: 87 active, 4 expired and left to lapse (arrxw.store, heavensbistro.com, rectifly.com, stocktruths.com). The full list, with each 60-day date, is in docs/cloudflare/domains-inventory-2026-09-24.md. 65 are transferable now, 16 from Oct 7 to Nov 2, and 6 get confirmed at transfer time. extrafreshbins and dztlandscaping are family clients, held in TKATI's account "for now" by owner decision; they could move to their own accounts later (§30–31).
    • The Cloudflare plugin (MCP) was authorized with Custom scope. The DNS snapshot of every eligible domain was taken from its own nameservers (tools/dns-snapshot.mjs → docs/cloudflare/dns/wave1-snapshot-2026-09-24.json). The 9 Netlify-DNS domains were taken from Netlify's API, which is exact. The plan is in docs/cloudflare/dns/wave1-plan.json. Netlify sites use apex A 75.2.60.5 plus www CNAME to *.netlify.app, all DNS-only.
    • 47 zones were created, with identical records, all DNS-only. For the parked ones, Squarespace's HTTPS hint and null-DKIM record were added after reading its DNS page. Cloudflare's pending-zone cap (error 1118) stopped further additions. The 18 still to add include dztlandscaping, tatailoring, djthub, limitlessflo, heavensbrewer and hevnz, and they go in as zones activate.
    • tools/dns-verify.mjs compares each zone's answers from Cloudflare's own nameservers with today's, before any switch. All 47 passed. Caveat: this network's router (192.168.40.1) rewrites some plain DNS lookups (djthq.com, limitlessff.com); those were confirmed over DNS-over-HTTPS instead.
    • Switched at Squarespace (11): buildbilt.com, buildff.io, buildq.io, carribeanz.com, cryptosflo.com, cubuilds.com, djtbull.com, djtbulls.com, djtgalaxy.com, djthq.com, djtspace.com. The registry confirms the change for all 11. 9 resolve worldwide with identical answers.
    • Incident, parked domains only: buildff.io and buildq.io return SERVFAIL to validating resolvers. Squarespace's switch turns DNSSEC off, but the .io registry still publishes the old DS record (TTL 3600). The records are correct when validation is skipped. It should clear once the registry drops the DS. Lesson, now the rule: on a domain with DNSSEC, remove it first, wait until the registry's DS is gone (TTL up to 6 h on .com), then switch.
    • DNSSEC is on for 11 of the remaining parked domains: dsflo, ffscape, lfbuilder, limitlessff, limitlessqai, notesflo, qqbuild, spitcoinflo, spitcoinglobal, tenscar, trustplanit. None of the live or mail domains have DNSSEC, so they can switch with no DNSSEC step and no downtime.
    • Stopped: Claude Code's permission system blocked further switches, because each one confirms "disable DNSSEC" (classed as weakening security). 36 are left in this batch. The owner decides how to continue.
    • The owner turned off Squarespace 2FA to speed this up. It must be turned back on when the move is finished. Squarespace still sends email or SMS codes for sensitive changes, and the owner enters those, never Claude.
38. 2026-09-24 · night, last

    DNS prepared; the registrar transfer has a date

    • Snapshot of tkati.com from Netlify's DNS API: 7 records. That's 5 for mail (MX, send/rsend CNAMEs, DKIM, DMARC) and 2 Netlify-hosting rows (apex, www). Saved to docs/cloudflare/tkati-dns-snapshot-2026-09-24.json. It's public DNS data, no secret. The other 15 domains on that Netlify account were not touched.
    • docs/cloudflare/tkati.com.zone holds the 5 mail records in BIND format, for import, DNS-only. Apex and www become Worker Custom Domains.
    • tools/dns-diff.mjs asks any nameserver for every record and fails on a difference. It warns specifically about a proxied mail CNAME. It passes against today's live DNS.
    • The owner wants the registration moved too. whois: created 2026-08-22, clientTransferProhibited, DNSSEC unsigned. ICANN's 60-day rule makes 2026-10-21 the earliest date (B5b).
    • Blocked: the zone can't be added from here. Wrangler's OAuth has no zone-write scope, and the Chrome window available to Claude isn't signed in to Cloudflare. Claude won't enter the password.
39. 2026-09-24 · night, later

    Secrets set: the preview is fully configured

    • With the owner's permission, 12 secrets were copied directly from Netlify's production environment into the Worker (wrangler secret bulk from a mode-600 temp file, deleted straight after). The values never appeared in the conversation.
    • Copied: SUPABASE_URL, SUPABASE_SERVICE_ROLE_KEY, SUPABASE_ANON_KEY, SUPABASE_PUBLISHABLE_KEY, RESEND_API_KEY, RESEND_WEBHOOK_SECRET, STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET, STRIPE_PRICE_* (3), GROQ_API_KEY.
    • Deliberately not copied: the DB password, JWT secret and DB/pooler URLs. No function reads them.
    • ASK_*, EBAY_*, GROQ_MODEL and STRIPE_API_VERSION aren't set on Netlify either, so both hosts use the code defaults.
    • Verified: all 8 routes answer 405 to a GET (configured), and /api/enquiry 303s to /#start exactly as Netlify does.
    • The same question was put to /api/ask on both hosts: identical answer, 3.4 s on Netlify and 0.7 s on Cloudflare. This logged two ordinary rows in the assistant's question log.
    • Next, B4: add the tkati.com zone to Cloudflare. That's harmless until the nameservers change. Then diff every record against today's DNS, especially mail.
40. 2026-09-24 · night

    B1 done, B3 deployed: tkati is on Cloudflare at a preview address

    • The owner gave the account (9a2e…8c2e). wrangler login was run and approved in the browser, and whoami confirmed the right account. Cloudflare's agent setup was also run: the cloudflare@cloudflare Claude Code plugin (skills + MCP) is installed.
    • wrangler deploy created the Worker at https://tkati.heavensbrewer.workers.dev (version 9bd7c906): 96 assets, cron 10 7 * * *. No route, so tkati.com is untouched.
    • Verified live:
      • Home and sign-in render in Chrome under the real CSP.
      • /docs, /tools, /supabase and netlify.toml are 404.
      • Assets are immutable; /admin/* is noindex + no-store.
      • /api/ads-report-run is 404.
      • /api/inbound-mail is 500, which is correct with no secrets.
    • Not done: the secrets. Copying them from Netlify into the Worker was blocked by Claude Code's permission system, correctly, since it's a secret-store write. The owner runs it (§10). Only the names the functions actually read should go across; the DB password, JWT secret and DB URLs stay out.
    • A side effect to know about: once secrets exist, the preview's 07:10 cron runs alongside Netlify's. That's safe, because migration 0024's unique index refuses a second snapshot for the same period (a 409, reported as "already"). But it is two schedulers until cutover.
41. 2026-09-24 · evening

    The separate office home was deleted; staff land on the Office

    • At the owner's request, admin/home.html and its renderer were removed. Sign-in, the sidebar's Dashboard link, the client dossier's back link and this page's back link all go to /admin/office.html now.
    • office-home.mjs and office-home.css stay, because the client dossier (admin/client.html) is built on them. routing-check.mjs caught that the dossier had become unreachable; client names in the Office's Clients list now open it.
    • routing-check.mjs now fails if anything links to the deleted office home. verify.mjs passes.
42. 2026-09-24 · later

    B2: the Worker runs locally, and the admin got its doors back

    • Owner report: "admin@tkati.com opens a client view." Checked in the database: the account is owner, active, and the only user, so the role was already right. The real cause was that admin/home.html had no navigation. Its top line held the date and Sign out and nothing else, so there was no route to the Mailbox, Clients, Invoices, Ads or eBay. A nav row was added under the dateline, and an "Other screens" group in the Office sidebar. Ads and eBay had never been linked from anywhere; routing-check.mjs now covers both, and this page too.
    • Added wrangler.jsonc, worker/index.mjs and tools/build-public.mjs. The Worker imports the same function modules Netlify runs.
    • Verified under wrangler dev (Wrangler 4.138):
      • Pages return 200.
      • /docs, /tools, /supabase, netlify.toml, .env.local and admin/README.md return 404.
      • The CSP is byte-identical to Netlify's.
      • /admin/* gets noindex and no-store; /assets/* gets immutable.
      • Every /api/* route returns 405 to a GET, as the Office's route probe expects.
      • Unknown routes and /api/ads-report-run return 404.
      • The cron fired the job, which read process.env unmodified and failed only on the deliberately unreachable dummy database.
    • Bug found and fixed during the check: assets were served with two contradictory Cache-Control values.
    • tools/worker-check.mjs added and wired into verify.mjs: every function routed or scheduled, no routes before cutover, no secret in config, allow-list holds, CSP identical, overrides detach. verify.mjs passes.
    • Not done: nothing deployed. There's no Cloudflare login on this machine, and B3 needs the owner's wrangler login. No real endpoint was written to; the live-key run of wrangler dev was used for GETs only. Supabase is unchanged (D3 is still awaiting the owner). No commit was made, because the working tree holds other uncommitted work.
43. 2026-09-24

    The record was set up; inventory and research started

    • The owner's brief was saved verbatim to docs/cloudflare/directive.md (5,662 lines as pasted).
    • This page was created at /admin/infrastructure.html and linked from the office home's top line. Registered in tools/routing-check.mjs so it can't become unreachable.
    • Project B inventory taken from the repo and live DNS (dig, whois, curl). Results are in §8.
    • Found: the repo root is publicly served (decision D5).
    • Phase 0 research: the brief's Cloudflare claims were checked against official docs. Results are in §9.
    • Not done: nothing on Cloudflare has been created, deployed or changed. No DNS was touched and no Netlify setting changed. There's no Cloudflare credential on this machine.

Map of the original brief

The brief has 277 numbered sections. This groups them by topic so you can go straight to the right part of docs/cloudflare/directive.md in the repo.