สร้าง “เงินเข้าเงินออก”
ทีละขั้นจนขึ้นระบบทดลอง

ทำ Skill Scout แบบ READ-ONLY สำหรับโปรเจกต์นี้ก่อนเขียนโค้ด

1. ผู้เรียนรัน /memory และ /context แยกเองแล้ว ห้ามพยายามเรียก interactive slash command เอง
2. จาก context ปัจจุบันและ filesystem ให้อ่าน CLAUDE.md ทุกระดับที่เกี่ยวข้อง
3. ตรวจรายชื่อและ description ของ Skills/Plugins ที่ติดตั้งอยู่แล้ว
4. เทียบความต้องการ React/Vite, Supabase/RLS, Cloudflare, testing, security และ browser verification
5. หากยังขาด ให้ค้นจาก official Claude Code/Cloudflare/Supabase docs และ trusted catalogs ต่อไปนี้เท่านั้นในรอบแรก:
   - https://github.com/mattpocock/skills
   - https://github.com/multica-ai/andrej-karpathy-skills
6. เสนอไม่เกิน 5 รายการ โดยระบุ source, maintainer, capability, install method, reviewed version/commit, scope, files/scripts/hooks/MCP/dependencies, permissions, auto-update policy, duplicate/conflict risk และเหตุผลที่จำเป็น
7. เลือกวิธีติดตั้งเพียงวิธีเดียวต่อ bundle ห้ามติดตั้ง plugin และ skills.sh ซ้ำกัน
8. แยก Marketplace registration, Plugin install และ setup/config เป็นคนละ approval
9. ก่อน C3 เสนอได้เฉพาะ user-scope action ที่ยืนยันว่าไม่เขียน Project root; project/local-scope action, setup และ MCP config ต้องรอหลัง Scaffold
10. ห้าม install, update, clone, execute third-party script หรือแก้ settings ในขั้นนี้
11. จบด้วยรายการ exact approvals ที่ต้องการ แล้วหยุดรอ GATE S

คุณคือ Lead Full-Stack Engineer, UX Engineer และ Security Reviewer
ให้สร้างเว็บแอป “เงินเข้าเงินออก” สำหรับบันทึกรายรับ–รายจ่ายส่วนบุคคล ตั้งแต่เริ่มต้นจน Deploy บน Production infrastructure เพื่อการเรียน โดยทำงานใน workspace ปัจจุบัน

เป้าหมายการทำงาน
- เริ่มและควบคุมงานทั้งหมดจาก Prompt นี้ได้เลย
- ไม่ถามคำถามทั่วไปซ้ำ ให้ใช้ค่าเริ่มต้นที่ระบุไว้
- Initial Build ต้องหยุดรออนุมัติที่ GATE S, GATE A, GATE B และ GATE C; ถ้าผู้ใช้เริ่ม Optional Custom Domain Add-on หลัง Smoke Test ต้องหยุดเพิ่มที่ GATE D1, D2-A, D2-B (เมื่อจำเป็น) และ D3 ตาม exact action
- ห้ามอ้างว่าเชื่อมต่อ Migration หรือ Deploy สำเร็จ หากไม่มีหลักฐานจากระบบจริง
- Custom Domain ไม่ใช่ส่วนของ Initial Deploy: ห้ามเปลี่ยน Nameserver, DNS, Domain binding หรือ Canonical/Auth URL จนกว่าผู้ใช้จะเริ่ม Custom Domain Add-on และอนุมัติ GATE D ที่ระบุ exact hostname

กติกาก่อนแก้ไฟล์
1. ยืนยันว่า workspace คือ Project root ถ้ายังไม่มี Git repo และเป็นโฟลเดอร์งานนี้จริง ให้รัน git init ก่อน แล้วอ่าน CLAUDE.md ทุกระดับที่เกี่ยวข้อง, AGENTS.md ถ้ามี, project instructions, package files และ git status
2. รักษาไฟล์เดิมของผู้ใช้ ห้าม reset หรือเขียนทับโดยไม่ตรวจ
3. ถ้า workspace มีโปรเจกต์เดิม ให้ต่อยอดด้วย minimum diff
4. ถ้า workspace ว่าง ชื่อโฟลเดอร์ต้องใช้เฉพาะ a-z, 0-9 และ hyphen ไม่ขึ้น/ลงท้ายด้วย hyphen และยาวไม่เกิน 58 ตัวอักษร ก่อน C3 ให้ root มีเพียง .git/.gitignore ที่อนุญาต ห้ามสร้าง CLAUDE.md, CLAUDE.local.md, .mcp.json, package.json, package-lock.json หรือ node_modules
5. หลัง Gate S สำหรับ exact reviewed C3 version ให้เรียก npm exec --package=create-cloudflare@<EXACT_REVIEWED_VERSION> -- create-cloudflare . --framework=react --platform=workers --lang=ts --accept-defaults --no-auto-update --no-deploy --no-open --no-git เท่านั้น ห้ามใช้ @latest หรือ unqualified npx
6. เมื่อ C3 จบแล้ว ให้สร้าง Project CLAUDE.md จาก Goal, Stack, Commands, Data rules, Gates และ Definition of Done ใน Prompt นี้ แล้วค่อยเพิ่ม .mcp.json และ project dependencies ผ่าน Gate S ของแต่ละ exact item
7. ถ้ามีความเสี่ยงทับงานอื่น ให้หยุดรายงานก่อนแก้ไฟล์
8. ใช้ package stable ที่เข้ากันได้ และตรวจ official documentation เมื่อไม่แน่ใจ
9. ห้ามใช้ TypeScript any, @ts-ignore, TODO, placeholder, mock integration หรือ hardcoded secret
10. ห้ามรัน production build ขณะที่ dev server ยังทำงาน

ขอบเขตระบบ V1
- UI ภาษาไทย สกุลเงิน THB
- สมัครสมาชิก เข้าสู่ระบบ ออกจากระบบ และรักษา session ด้วย Supabase Auth
- Protected routes สำหรับหน้าที่ต้องล็อกอิน
- เพิ่ม แก้ไข ลบ และค้นหารายรับ–รายจ่าย
- ข้อมูลหนึ่งรายการมี kind, amount, category, date และ note
- เลือกเดือนและกรองประเภทได้
- Dashboard แสดงรายรับรวม รายจ่ายรวม คงเหลือสุทธิ และยอดตามหมวดหมู่
- มือถือใช้ cards และจอใหญ่ใช้ table
- Export เฉพาะเดือนที่เลือกเป็น CSV ภาษาไทย
- มี loading, empty, validation และ error states
- ยืนยันก่อนลบ
- ใช้ keyboard ได้ มี label และ visible focus state
- แสดง disclaimer ว่าเป็นเครื่องมือบันทึกส่วนบุคคล ไม่ใช่คำแนะนำด้านบัญชี ภาษี หรือกฎหมาย
- ใช้เฉพาะข้อมูลจำลอง ห้ามอ้างว่าพร้อมรับข้อมูลจริงจนกว่าจะมี Privacy Notice, retention/deletion policy, backup/restore, account deletion, incident response และผู้เชี่ยวชาญตรวจระบบ

Tech stack บังคับ
- Frontend: React + Vite + TypeScript
- Routing: React Router
- Styling: Tailwind CSS
- Validation: Zod
- Backend/Auth/Database: Supabase Auth + PostgreSQL
- Client: @supabase/supabase-js
- Hosting: Cloudflare Workers + Static Assets
- Tests: Vitest + React Testing Library
- Lint: ESLint
- Package scripts ต้องมี typecheck, lint, test, test:coverage, build และ deploy

Business rules เรื่องจำนวนเงิน
- เก็บจำนวนเงินเป็น integer หน่วยสตางค์ใน amount_satang
- amount ต้องมากกว่า 0 และมีเพดานที่สมเหตุสมผล
- ห้ามใช้ floating-point เป็นแหล่งข้อมูลหลักของผลรวม
- สร้าง pure functions สำหรับแปลงบาทเป็นสตางค์ แสดงเงินบาท และรวมยอด
- เขียน tests สำหรับทศนิยม การปัดเศษ ค่าว่าง ค่าติดลบ และค่าที่เกินเพดาน

Database schema เป้าหมาย
ตาราง public.transactions
- id uuid primary key default gen_random_uuid()
- user_id uuid not null default auth.uid() references auth.users(id) on delete cascade
- kind text not null check kind เป็น income หรือ expense
- amount_satang bigint not null check มากกว่า 0 และไม่เกินเพดานที่กำหนด
- category text not null ความยาวหลัง trim 1–60 ตัวอักษร
- note text ไม่บังคับ ความยาวไม่เกิน 500 ตัวอักษร
- occurred_on date not null
- created_at timestamptz not null default now()
- updated_at timestamptz not null default now()
- index สำหรับ user_id และ occurred_on desc

Security และ RLS บังคับ
- เปิด RLS บน transactions
- revoke สิทธิ์ anon ที่ไม่จำเป็น และ grant CRUD ให้ authenticated เท่าที่ใช้
- SELECT: user_id = auth.uid()
- INSERT: WITH CHECK user_id = auth.uid()
- UPDATE: มีทั้ง USING และ WITH CHECK user_id = auth.uid()
- DELETE: user_id = auth.uid()
- ผู้ใช้ที่ไม่ล็อกอินอ่านหรือเขียนไม่ได้
- Frontend filter ช่วย performance แต่ไม่ใช่ security boundary
- ห้ามใช้ Supabase secret key หรือ legacy service_role ใน browser
- Browser ใช้เฉพาะ VITE_SUPABASE_URL และ VITE_SUPABASE_PUBLISHABLE_KEY
- validate ทั้ง UI และ database constraints
- ห้ามแสดง raw database error หรือข้อมูลภายในแก่ผู้ใช้

Environment และ Secret
- .env.local ต้องอยู่ใน .gitignore
- .env.example มีเฉพาะชื่อตัวแปรและค่าว่าง
- สร้าง env validator ที่แจ้งชื่อค่าที่ขาดโดยไม่พิมพ์ค่าจริง
- ห้ามขอให้ผู้ใช้ paste secret ลง chat
- ห้ามพิมพ์ credential, token, JWT หรือ key เป็น command argument หรือ plain text ใน terminal, log, screenshot หรือ report; อนุญาตให้ผู้ใช้กรอก password เองเฉพาะ masked interactive prompt ของเครื่องมือที่ตรวจสอบ target แล้ว
- ก่อน commit/deploy ให้ตรวจ diff และค้นหา secret pattern

Claude Code และ MCP Safety
- เริ่มด้วย Skill Scout: ตรวจ skill descriptions ที่มีอยู่ เลือกชุดเล็กที่สุด และใช้ skill ที่ตรงงานโดยอัตโนมัติเมื่อได้รับอนุญาตแล้ว
- ถ้าความสามารถยังขาด ให้ค้นแบบ read-only จาก official Claude/Cloudflare/Supabase docs และ https://github.com/mattpocock/skills; ใช้ https://github.com/multica-ai/andrej-karpathy-skills/blob/main/CLAUDE.md เป็น behavioral-rules reference ไม่ใช่ blind installer
- ถ้าต้องเพิ่ม ติดตั้ง ตั้งค่า execute หรืออัปเดต Tool/Skill/Plugin/MCP ให้รายงาน source, version/ref, scope, scripts/hooks/MCP/dependencies, permissions, duplicate risk และหยุดที่ GATE S ก่อนทุกครั้ง
- ห้าม clone, install, update หรือ execute third-party code จากผลค้นหาโดยพลการ และห้ามติดตั้ง bundle เดียวกันซ้ำหลายวิธี
- ใน Claude Desktop ให้เลือก Ask permissions จาก Mode selector และตรวจ Settings → Claude Code ห้ามเปิด Bypass permissions
- ห้ามตั้ง allow rule ครอบคลุม db push, deploy, secret, account creation หรือ production config
- ถ้าใช้ Supabase MCP ให้เชื่อมเฉพาะ Dev/Test project และจำกัดด้วย project_ref ที่ผู้ใช้ยืนยัน
- ตั้ง MCP เป็น project-scoped/local-scoped เท่าที่จำเป็น ห้ามเก็บ token จริงใน .mcp.json หรือ source control
- คง manual tool approval และให้ Supabase MCP เป็น read-only ตลอดคลาส จำกัด feature groups ให้เหลือเท่าที่งานต้องใช้; Remote write ใช้ CLI หลัง Gate B เท่านั้น
- ห้ามเชื่อม Supabase MCP กับ production data และต้องตรวจทุก tool call ที่อ่าน/เขียน remote state
- สำหรับ Cloudflare ให้ใช้ Cloudflare Skills/Docs เพื่ออ้างอิง และใช้ Wrangler หลังผู้เรียน OAuth เอง; API MCP ที่เข้าถึง account ต้องคง manual approval และห้ามเปลี่ยน remote state ก่อน Gate C

CSV export
- Export เฉพาะเดือนที่เลือก
- ใช้ UTF-8 พร้อม BOM เพื่อเปิดภาษาไทยใน Excel
- Escape comma, quote และ newline ตามมาตรฐาน CSV
- ป้องกัน formula injection สำหรับ cell ที่เริ่มด้วย =, +, - หรือ @
- ชื่อไฟล์ transactions-YYYY-MM.csv
- มี unit tests สำหรับภาษาไทย comma quote newline และ formula injection

โครงสร้างโค้ด
- แยก auth, transactions, dashboard, lib/supabase, validation และ utilities
- Supabase client อยู่จุดเดียว
- Business logic เป็น pure functions ที่ test ได้
- Component หนึ่งตัวมีหน้าที่หลักหนึ่งอย่าง
- ไม่กระจาย query/session logic ซ้ำทั่วโปรเจกต์
- Dependency น้อยที่สุดที่ยัง production-ready

PHASE 0 — INSPECT, SKILL SCOUT & BLUEPRINT
1. ผู้เรียนรัน /memory และ /context แยกเองแล้ว ห้ามพยายามเรียก interactive slash command เอง
2. ตรวจ workspace จาก context ปัจจุบันและ filesystem อ่านกติกาโปรเจกต์ รวมถึงตรวจ skills/plugins ที่ติดตั้งแล้วแบบ read-only
3. รายงาน assumptions, architecture, data flow, ไฟล์ที่จะสร้าง และ skill plan แบบสั้น
4. ถ้า skills ที่มีอยู่เพียงพอ ให้ใช้ชุดเล็กที่สุดและทำต่อได้ทันที
5. ถ้าต้อง add, install, configure, execute หรือ update สิ่งใด ให้เสนอรายการตาม Skill Safety แล้วหยุดที่ GATE S
6. Supabase CLI และ Wrangler ต้องระบุ exact reviewed version, ติดตั้งเป็น project dependency และตรวจด้วย npm ls; ห้ามใช้ unqualified npx
7. C3 เป็น one-time scaffold exception: หลัง Gate S ให้ใช้ exact-qualified npm exec ที่ destination . ก่อนสร้าง Project files พร้อม --no-auto-update --no-deploy --no-open --no-git เพื่อคง reviewed version, รักษา Gate C และไม่สร้าง nested repo
8. หลัง GATE S หรือเมื่อไม่ต้องเปลี่ยน Tool/Skill/Plugin/MCP ถือว่า Prompt นี้อนุมัติให้ implement ตามขอบเขตแล้ว
9. หยุดเพิ่มเฉพาะเมื่อเสี่ยงทับงานเดิมหรือขัด project instructions

GATE S — TOOL / SKILL / PLUGIN / MCP CHANGE
ห้ามหยุดที่ Gate นี้ถ้าใช้เฉพาะสิ่งที่ติดตั้งอยู่แล้วและไม่เปลี่ยน configuration

ก่อนหยุด:
- แสดง exact name, source URL, maintainer, install method, reviewed version/commit และ scope
- สรุป files/scripts/hooks/MCP/dependencies, permission และเหตุผลที่จำเป็น
- ตรวจชื่อซ้ำและยืนยันว่าจะไม่ติดตั้ง bundle เดียวกันสองวิธี
- ขออนุมัติครั้งละหนึ่ง exact action ID และ exact item; การรัน setup/config หลังติดตั้งต้อง review และขอ Gate S ใหม่
- การเพิ่ม Marketplace และการติดตั้ง Plugin ต้องแยกเป็น Gate S คนละรอบ
- ก่อน C3 อนุญาตเฉพาะ user-scope action ที่พิสูจน์ว่าไม่เขียน Project root; project/local action, setup, MCP config และ project dependencies ต้องรอหลัง Scaffold
- Git marketplace ต้องใช้ full Git URL#<reviewed-tag-or-branch>; หลัง add ให้ตรวจ resolved commit เทียบกับที่ review หากไม่ตรงหรือพิสูจน์ไม่ได้ให้ remove marketplace และหยุดก่อนติดตั้ง Plugin
- ระบุ auto-update policy; สำหรับคลาสให้ปิด auto-update และทุก update ต้องกลับมาทำ Trust Review + Gate S

รอข้อความนี้โดยต้องระบุรายการจริง:
APPROVE GATE S <ACTION-ID>: <add|install|configure|execute|update> <exact-name> จาก <source> version/ref <reviewed-version-or-commit> ด้วย <method> ที่ scope <user|project|local> โดย auto-update <disabled|manual-review>

หลังอนุมัติ:
1. ทำเฉพาะ action, รายการ และวิธีที่อนุมัติ
2. ถ้าพบ dependency, script, hook, MCP หรือ permission เพิ่มจากรายงาน ให้หยุดก่อน
3. ตรวจว่า skill พร้อมใช้, version/ref ตรงกับที่อนุมัติ และ auto-update policy ถูกต้อง โดยไม่รัน workflow ที่เปลี่ยน remote state
4. ทำต่อที่ PHASE 1

PHASE 1 — LOCAL IMPLEMENTATION
1. ถ้า workspace ว่าง ให้ execute C3 exact version ด้วยคำสั่งและ safe flags ที่กำหนดก่อนสร้าง Project files
2. หลัง Scaffold ให้สร้าง Project CLAUDE.md แล้วอ่านไฟล์ใหม่นี้โดยตรงใน session เดิม ผู้เรียนใช้ /memory และ /context แยกเองเพื่อตรวจ Global + Project rules; ถ้า Project file ไม่ปรากฏจึงใช้ Rescue Prompt ใน session ใหม่
3. ขอ Gate S แยกตาม action ID สำหรับ project/local setup, MCP config และ dependency แต่ละ exact item ที่จำเป็น เช่น S-MATT-SETUP, S-SUPABASE-MCP, S-SUPABASE-CLI และ S-WRANGLER
4. ติดตั้ง dependencies ตาม exact versions ที่ review แล้ว ยืนยัน Supabase CLI/Wrangler ด้วย npm ls และใช้เฉพาะ project-local binary หรือ npm script ห้ามให้ npx ดาวน์โหลด package
5. สร้าง UI, routing, auth state, validation และ data layer
6. สร้าง versioned migration ใน supabase/migrations แต่ยังห้าม apply remote
7. สร้าง RLS policies และ database tests
8. สร้าง .env.example, README, security notes และขั้นตอนสร้าง Local .env.local จาก supabase status โดยไม่คัดลอกค่าเข้า Prompt
9. สร้าง unit/component tests
10. รัน typecheck, lint และ tests ที่ไม่ต้องเชื่อม remote
11. แก้ทุก failure ก่อนเดินหน้า

GATE A — CREDENTIALS & ACCOUNT CONNECTION
ต้องหยุดแม้พบ session หรือ credential พร้อมอยู่แล้ว

ก่อนหยุด ให้รายงานเฉพาะ:
- ชื่อตัวแปรที่ต้องมี ห้ามแสดงค่า
- Supabase project ref และ Cloudflare account/Worker target ที่ตั้งใจใช้
- สถานะว่ามี Supabase CLI/MCP และ Wrangler หรือไม่
- ขั้นตอนให้ผู้ใช้สลับ .env.local จาก Local เป็น Hosted Dev, หยุดและเริ่ม dev server ใหม่, ตรวจเฉพาะ hostname/project ref ว่าชี้ Hosted Dev จริง, login ผ่าน browser และรัน supabase link ด้วยตนเอง โดยกรอก Database password เฉพาะ masked interactive prompt

รอข้อความนี้:
APPROVE GATE A: ตรวจการเชื่อมต่อได้ โดยห้ามแสดง credential

หลังอนุมัติ:
1. ตรวจ presence/format ของ env แบบ mask ทั้งค่า และยืนยัน hostname/project ref โดยห้ามแสดง key
2. ตรวจ auth CLI แบบ read-only
3. ยืนยัน target project/account อีกครั้ง
4. ห้ามสร้าง project ที่มีค่าใช้จ่ายหรือเปลี่ยน secret โดยพลการ
5. ทำต่อถึง Gate B

GATE B — DATABASE MIGRATION
ก่อนหยุด:
- แสดง project ref, migration path และ SQL diff
- สรุป table, constraints, index, trigger และ RLS policies
- รัน local DB tests และ supabase db push --dry-run ถ้าทำได้
- ระบุ conflict, data risk และวิธี verify
- แสดงแผนทดสอบ User A/B และ alias ของ test accounts ที่ผู้ใช้เตรียมไว้ โดยห้ามสร้างบัญชีหรือข้อมูลทดสอบจนกว่าจะได้รับอนุญาตชัดเจน
- ห้าม DROP, TRUNCATE, remote reset หรือแก้ migration history ที่ apply แล้ว

รอข้อความนี้โดยต้องระบุ target จริง:
APPROVE GATE B: ใช้ migration <ชื่อไฟล์> กับ Supabase project <project-ref>
และอนุญาตเฉพาะ test account aliases <USER_A_ALIAS>, <USER_B_ALIAS> กับข้อมูลจำลองที่ระบุ

หลังอนุมัติ:
1. Apply เฉพาะ migration ที่อนุมัติ
2. ถ้าไม่มี authenticated tool ให้ส่งขั้นตอน SQL Editor แล้วหยุดรอผู้ใช้ยืนยัน
3. ตรวจ schema, constraints, index และ policies จาก remote จริง
4. ทดสอบ unauthenticated denial
5. ทดสอบ User A และ User B ว่าอ่าน/แก้ข้อมูลข้ามกันไม่ได้ เฉพาะ test accounts และข้อมูลจำลองที่ผู้ใช้อนุมัติใน Gate B
6. ทดสอบ Auth, CRUD, dashboard และ CSV
7. Regenerate Supabase TypeScript types

VERIFY GATE ก่อน Deploy
- typecheck ผ่าน
- lint ผ่าน
- unit/component/database tests ผ่าน
- coverage business logic สำคัญอย่างน้อย 80%
- ไม่มี skipped tests, any, TODO, placeholder หรือ mock data ใน production path
- ไม่มี hardcoded secret
- หยุด dev server ก่อน production build
- production build ผ่าน
- wrangler deploy --dry-run ผ่าน
- mobile/desktop, loading, empty, validation และ error states ผ่าน
- ถ้าข้อใดยังตรวจไม่ได้ ให้เขียน “ยังไม่ได้ verify”

หลังเขียนโค้ด ให้ code reviewer และ security reviewer ตรวจพร้อมกันถ้าระบบรองรับ แล้วแก้เฉพาะ finding ใน scope

GATE C — CLOUDFLARE PRODUCTION DEPLOY
ต้องหยุดก่อน deploy หรือเปลี่ยน production config ทุกครั้ง

ก่อนหยุด:
- แสดง account และ Worker name เป้าหมาย
- แสดง build/deploy command
- สรุปผล Verify Gate
- ยืนยันว่า VITE_* เป็น build-time public values
- ยืนยันว่าไม่มี Supabase secret/service-role key ใน client หรือ bundle
- ระบุ Supabase project ref, Auth Site URL และ redirect URLs แบบ exact ที่ต้องเปลี่ยน

รอข้อความนี้โดยต้องระบุ target จริง:
APPROVE GATE C: deploy ไป Cloudflare Worker <worker-name> ใน account <account-name/id> และตั้ง Auth URLs ของ Supabase project <project-ref> ตาม exact URLs ที่รายงาน

หลังอนุมัติ:
1. ยืนยัน Worker, account, Supabase project และ exact Auth URLs อีกครั้ง
2. หยุด dev server และ build ใหม่
3. Deploy เฉพาะ build ที่ผ่าน Verify Gate
4. เปิด Production URL จริงและทำ smoke test
5. ตรวจหน้าเว็บ, assets, deep-link refresh, login/logout, console และ responsive layout
6. ทดสอบ authenticated CRUD เฉพาะ test account และข้อมูลจำลองที่ผู้ใช้อนุญาต
7. บันทึก URL, commit SHA, migration version และสิ่งที่ยังไม่ได้ verify

CUSTOM DOMAIN BOUNDARY
- Initial Definition of Done จบได้ด้วย Cloudflare Learning URL ที่ smoke test ผ่าน
- ถ้าผู้ใช้ต้องการโดเมนจริง ให้ใช้ Custom Domain Add-on หลังจบ Gate C เท่านั้น
- Agent ทำ read-only inventory และเสนอ exact diff ก่อน ห้ามเปลี่ยน Nameserver, DNS record, Custom Domain, redirect rule หรือ Supabase Auth URL เองโดยไม่มี Gate D
- Nameserver cutover เป็นขั้นที่ผู้เรียนทำเองกับ Registrar หลังสำรอง DNS records และตรวจ DNSSEC แล้ว

Definition of Done
- V1 Deploy บน Production infrastructure เพื่อการเรียนและใช้เฉพาะข้อมูลจำลอง
- Supabase Auth และ RLS ทำงานกับ target ที่อนุมัติ
- User A เข้าถึงข้อมูล User B ไม่ได้
- Dashboard และ CSV ใช้ข้อมูลจำลองที่อ่านจาก Supabase จริง ไม่ใช่ mock data และ tests ผ่าน
- typecheck, lint, tests, coverage, build และ dry-run ผ่าน
- Cloudflare Production URL เปิดได้จริงและ smoke test ผ่าน
- ไม่มี hardcoded secret
- README อธิบาย setup, architecture, gates, security และข้อจำกัด
- UI มี disclaimer ว่าไม่ใช่ระบบบัญชี/ภาษี/กฎหมายที่ผ่านการรับรอง
- รายงานชัดว่า “ยังไม่พร้อมรับข้อมูลจริง” จนกว่า Privacy, retention/deletion, backup/restore, account deletion และ incident response จะได้รับการออกแบบและตรวจรับ

รูปแบบรายงานสุดท้าย
1. สิ่งที่สร้าง
2. Architecture และเหตุผล
3. ไฟล์สำคัญ
4. Migration/RLS ที่ตรวจจากระบบจริง
5. Verification commands พร้อมผลจริง
6. Learning deployment URL ที่เปิดตรวจแล้ว
7. สิ่งที่ยังไม่ได้ verify
8. ข้อจำกัดและคำเตือน

เริ่มจาก PHASE 0 ได้เลย

CUSTOM DOMAIN ADD-ON — READ-ONLY FIRST
ใช้หลัง GATE C และ Smoke Test ของ Learning URL ผ่านแล้วเท่านั้น

ข้อมูลที่ผู้เรียนกรอก
- DEPLOY_TARGET: <WORKER|PAGES>
- CLOUDFLARE_ACCOUNT: <ACCOUNT_NAME_OR_ID>
- CLOUDFLARE_TARGET: <WORKER_NAME_OR_PAGES_PROJECT>
- APEX_DOMAIN: <example.com>
- CANONICAL_HOSTNAME: <app.example.com>
- CURRENT_LEARNING_URL: <https://...workers.dev|https://...pages.dev>
- SUPABASE_PROJECT_REF: <PROJECT_REF>

กติกา
1. อ่าน CLAUDE.md ทุกระดับ, git status, deployment config และหลักฐาน Smoke Test เดิม
2. ตรวจแบบ read-only ก่อน: เจ้าของ target, Cloudflare zone status, authoritative nameservers, DNSSEC status, DNS record inventory และ hostname conflict
3. รายงานเฉพาะชื่อ record/type/target ที่จำเป็น ห้ามแสดง token, key, password, cookie หรือ credential
4. แยกเส้นทางให้ถูก:
   - WORKER: zone ต้อง Active ใน Cloudflare แล้วใช้ Worker > Settings > Domains & Routes > Add > Custom Domain
   - PAGES: ใช้ Pages project > Custom domains > Set up a domain; ถ้า DNS อยู่นอก Cloudflare ต้อง associate ใน Pages ก่อนสร้าง CNAME ไป <PROJECT>.pages.dev
5. ตรวจ MX, SPF, DKIM, DMARC, verification TXT, CAA และ record ของบริการเดิมก่อนเสนอ Nameserver cutover ห้ามลบหรือเขียนทับ record ที่ไม่เกี่ยวข้อง
6. ถ้า Registrar เปิด DNSSEC อยู่ ให้บันทึก DS TTL, ให้ผู้เรียนลบ DS/ปิด DNSSEC ที่ Registrar แล้วรอให้ DS TTL หมดจาก Parent zone ตรวจว่า old DS หายจาก public resolver อย่างน้อย 2 แห่งก่อน GATE D1 ห้ามปิดแล้วเปลี่ยน Nameserver ทันที จากนั้นค่อยเปิด DNSSEC ผ่าน Cloudflare หลัง zone Active
7. เสนอแผน exact actions, rollback, expected propagation และ evidence ที่จะตรวจ โดยยังห้ามเปลี่ยน remote state
8. เลือก Gate ตาม target โดยห้ามเหมารวม:
   - WORKER หรือ PAGES APEX/FULL SETUP: zone ต้อง Active; ถ้ายังไม่ Active ให้หยุด GATE D1 ถ้า Active แล้วจึงไป D2-A
   - PAGES + EXTERNAL DNS SUBDOMAIN: ไม่ต้องย้าย Nameserverและไม่ต้องมี Cloudflare zone Active ให้ข้าม D1 ไป D2-A เพื่อ associate hostname ใน Pages ก่อน แล้วจึงหยุด D2-B สำหรับ exact CNAME ที่ DNS provider เดิม
9. ห้ามใช้ wildcard hostname หรือ wildcard Supabase production redirect URL
10. ห้ามปิด Learning URL เดิมจน Custom Domain, HTTPS, Auth และ Critical Flow ผ่านครบ

รูปแบบคำตอบก่อนขออนุมัติ
1. Target ที่ยืนยันแล้ว
2. Current DNS/Nameserver/DNSSEC inventory
3. Record conflict และความเสี่ยงต่อเว็บ/อีเมลเดิม
4. Exact actions แยก D1, D2-A, D2-B (ถ้าจำเป็น) และ D3
5. Rollback plan
6. Verification checklist
7. Gate ถัดไปเพียงหนึ่ง Gate แล้วหยุด