Builders

เริ่มจากความแตกต่างที่ควบคุมทุกสิ่ง: ใน Astro โค้ดของคอมโพเนนต์ .astro ทำงานในช่วง BUILD (บนเครื่องของคุณหรือบน CI) ไม่ใช่ในเบราว์เซอร์ ผลลัพธ์ที่ได้คือ HTML ธรรมดา MOONKEY เป็นเช่นนี้ทุกประการ: ไฟล์ `astro.config.mjs` ประกาศ `i18n` พร้อม `fallbackType: 'rewrite'` และไม่ใช้ SSR เมื่อคุณรัน `npm run build` Astro จะไล่ไปทั่ว `src/pages/` รันไฟล์ .astro แต่ละไฟล์หนึ่งครั้งต่อหนึ่ง locale แล้วเขียน HTML ลงใน `dist/` ไม่มีเซิร์ฟเวอร์ในโปรดักชัน Cloudflare Pages เพียงเสิร์ฟไฟล์เท่านั้น นี่คือเหตุผลที่ทำให้ `moonkeylab.pages.dev` โหลดได้ภายในเสี้ยววินาที

สร้างโครงสร้างพื้นฐานขึ้นมาจากศูนย์เพื่อให้เห็นโดยไม่มีเวทมนตร์: `npm create astro@latest mi-sitio -- --template minimal --no-install` จากนั้น `cd mi-sitio && npm install && npm run dev` แล้วเปิด `http://localhost:4321` แก้ไข `src/pages/index.astro` แล้วสังเกตว่า `const hoy = new Date()` ที่พิมพ์ออกมาด้วย `{hoy}` จะถูกตรึงไว้ ณ ช่วงเวลาที่ build เมื่อคุณรัน `npm run build` นี่คือช่วงเวลาแห่งความกระจ่าง: JS ใน frontmatter (ส่วนที่อยู่ระหว่าง `---`) ทำงานเพียงครั้งเดียว ไม่ได้ทำงานในทุกครั้งที่มีผู้เข้าชม

ทีนี้มาถึงการควบคุมอย่างละเอียด: นั่นคือ islands โดยค่าเริ่มต้น คอมโพเนนต์จากเฟรมเวิร์ก (React/Svelte) ใน Astro จะถูก render เป็น HTML แบบ static โดยไม่มี JS ของมันมาด้วย จะถูก hydrate ก็ต่อเมื่อคุณใส่ directive `client:*` เท่านั้น โดย `client:load` hydrate เมื่อหน้าโหลด, `client:visible` เมื่อเข้าสู่ viewport, และ `client:idle` เมื่อ thread ว่าง กฎของช่างฝีมือคือ: เริ่มต้นโดยไม่ใส่ directive เพิ่ม `client:visible` เฉพาะเมื่อคอมโพเนนต์นั้นจำเป็นต้องมีการโต้ตอบจริงเท่านั้น ใน MOONKEY ตัว `IntersectionObserver` ของ reveal อยู่ใน `Layout.astro` ในรูปของ `<script>` ระดับ global ไม่ใช่ island แยกต่อหน้า นั่นคือการตัดสินใจที่ถูกต้อง: script ความยาว 15 บรรทัด แทนที่จะ hydrate ทั้งเฟรมเวิร์ก

Vite คือเครื่องยนต์ที่อยู่เบื้องล่าง Astro และยังเป็นเครื่องยนต์ของ Espejo (ซึ่งเป็น SPA React ล้วน: `vite.config.ts`, `@vitejs/plugin-react`) ความแตกต่างคือ Espejo ส่ง React ไปยังเบราว์เซอร์จริง เพราะมันต้องการ state แบบโต้ตอบสดๆ (การอ่านค่าจากกล้องด้วย MediaPipe, การนำทางด้วย react-router) นี่คือเส้นแบ่งที่แท้จริงของวิชาชีพนี้: เนื้อหานั้นเป็นการอ่านเป็นหลัก (เว็บของ XNLAB, MOONKEY) หรือเป็นแอปที่มี state หนาแน่น (Espejo) อย่างแรกต้องใช้ Astro/SSG อย่างหลังใช้ Vite+SPA อย่าผสมความเชื่อสองสาย: อย่ายัด SPA ทั้งตัวเข้าไปใน Astro เมื่อ 95% ของงานเป็นเนื้อหา

จงวัด อย่าเดา รัน `npm run build` แล้วดูขนาดของ `dist/` ใน MOONKEY การ build หน้าเนื้อหาควรมี JS ของหน้าราว ~0KB (มีเพียง script ของ reveal ที่ใช้ร่วมกัน) เปิด DevTools → Network แล้ว reload โดยล้าง cache และกรองเฉพาะ JS ถ้าคุณเห็น bundle ของเฟรมเวิร์กในหน้าที่มีแต่ข้อความ แสดงว่าคุณใส่ directive `client:*` เกินมาหนึ่งตัว หรือมี import ที่ลากไลบรารีหนักไปยังฝั่ง client คำสั่ง `npx astro build --verbose` จะแสดงรายการว่าอะไรถูก prerender บ้าง

failure mode คลาสสิก: import ไลบรารีวันที่/markdown/ไอคอนใน frontmatter โดยคิดว่าเป็น build-only แต่กลับนำไปใช้ภายใน `<script>` ของ client หรือส่งต่อให้ island แล้วทันใดนั้นมันก็ไปอยู่ใน bundle อีกกรณีหนึ่ง: ลืมว่า `import.meta.env` ใน Astro แยกระหว่าง `PUBLIC_*` (ไปฝั่ง client) กับตัวอื่นๆ (อยู่ใน build) ถ้าตัวแปรที่คุณคิดว่าเป็นความลับไปปรากฏใน `dist/` แสดงว่าคุณใส่ prefix ผิด และกับดักของ Vite: ทุกสิ่งที่อยู่ภายใต้ `public/` จะถูกคัดลอกแบบ verbatim โดยไม่ประมวลผล อย่าวางความลับไว้ตรงนั้น และอย่าคาดหวังว่า Vite จะ optimize asset เหล่านั้น

design token คือตัวแปรที่มีชื่อเชิงความหมาย ไม่ใช่ค่าดิบที่ถูกเขียนซ้ำ MOONKEY กำหนด token ของตัวเองไว้ใน `src/styles/global.css`: `--surface-base: #f8fafc`, `--text-primary: #0f172a` พร้อมพาเลตต์ emerald/violet/amber กฎทองคือ: คอมโพเนนต์จะไม่ใช้ค่า hex โดยตรงเด็ดขาด แต่ใช้ token ดังนั้น `--surface-base` จึงปรากฏเพียงครั้งเดียว ถ้าพาเลตต์เปลี่ยน ก็เปลี่ยนที่เดียว antipattern คือการเขียน `color: #0f172a` ในทุก card คุณได้ผูก 30 ไฟล์เข้ากับค่าหนึ่งที่ควรมีชื่อ

กรณีที่ให้บทเรียนมากที่สุดของวิชาชีพอยู่ที่ Espejo เพราะ token ตรงนั้นเป็นแบบ DYNAMIC ต่อ tenant ลองดู `src/brand/BrandProvider.tsx`: ฟังก์ชัน `applyTheme(brand)` ทำ `root.style.setProperty('--brand', brand.accent)` แล้วได้มาซึ่ง `--brand-soft`, `--brand-line`, `--brand-glow` ผ่านฟังก์ชัน `withAlpha(hex, a)` ที่แปลง hex ของแบรนด์เป็น rgba พร้อมความโปร่งใส UI สาธารณะทั้งหมดของ Espejo วาดด้วย `var(--brand)` ผลลัพธ์คือ: โค้ดชุดเดียวกันรองรับ Luna Rosa (สีชมพู `#e58fb0`) และ influencer คนใดก็ได้ เพียงเปลี่ยนฟิลด์ `accent` เดียว นั่นคือ design system ที่เป็นเครื่องยนต์ของ white-label ไปในตัว

คอมโพเนนต์ เทียบกับ คลาสกระจัดกระจาย: คอมโพเนนต์ห่อหุ้มโครงสร้าง + tokens + พฤติกรรมไว้ภายใต้ชื่อเดียว MOONKEY มี `PromptBlock`, `AnimalIcon`, `MoonkeyLogo`, `FlowDiagram` ใน `src/components/` สัญญาณที่บอกว่าคุณต้องการคอมโพเนนต์คือ: คุณคัดลอกบล็อก markup+คลาสชุดเดิมเป็นครั้งที่สาม สองครั้งแรกให้ทำซ้ำไป พอครั้งที่สามจึงค่อยแยกออกมา อย่า abstract ก่อนหน้านั้น เพราะการ abstract คอมโพเนนต์ที่มี 8 props 'เผื่อไว้' ก่อนเวลาอันควรนั้นแย่กว่าการทำซ้ำอย่างซื่อสัตย์

กับ Tailwind มีกับดักเฉพาะตัวที่ MOONKEY ระบุไว้อย่างชัดเจน: อย่า interpolate คลาสอย่าง `bg-${theme}` เด็ดขาด Tailwind ทำ tree-shaking โดยสแกนหา string ของคลาสที่สมบูรณ์ในช่วง build คลาสที่ถูกสร้างขึ้นในช่วง runtime จะไม่มีอยู่ใน CSS ที่ถูก generate และจะถูก render โดยไม่มีสไตล์ ด้วยเหตุนี้ `galaxy.ts` จึงมี object `THEME` ที่ map แต่ละ constellation ไปยังคลาสที่เขียนตรงตัว (`violet`, `amber`, `emerald`…) ไว้แล้ว บทเรียนคือ: คลาสแบบ dynamic แก้ได้ด้วย MAP ของ string ที่เขียนตรงตัว ไม่ใช่ด้วย interpolation

typography ในฐานะ token ของระบบ: MOONKEY กำหนด `font-display` = Space Grotesk สำหรับ h1–h3, Inter สำหรับ body, JetBrains Mono สำหรับ labels (`.label` = mono uppercase tracking-widest emerald-600) นั่นไม่ใช่การตกแต่งกระจัดกระจาย แต่เป็นการตัดสินใจที่ถูกเข้ารหัสไว้ครั้งเดียวซึ่งทั้งแอปสืบทอดมา ถ้าทุก heading เลือกฟอนต์ของตัวเอง คุณก็จะไม่มีแบรนด์ มีแต่ความวุ่นวาย ระบบอยู่ที่ชั้นของ token/utility ไม่ใช่ที่ `<h1>` แต่ละตัว

วิธีตรวจสอบความสอดคล้อง: ทำ grep หาค่าดิบที่ไม่ควรมีอยู่นอกไฟล์ token `grep -rn '#[0-9a-fA-F]\{6\}' src/components/` ใน MOONKEY ควรคืนค่าแทบไม่มีอะไรเลย ถ้ามี hex ปรากฏในคอมโพเนนต์ นั่นคือ token ที่รั่วออกมาและต้องแทนที่ด้วย `var(--token)` grep นี้คือ linter ความสอดคล้องเชิงภาพที่คุณทำขึ้นเอง และควรรันก่อนทุกครั้งที่ merge

multi-tenant หมายถึง: ซอฟต์แวร์หนึ่ง instance ลูกค้า (tenant) จำนวนมากที่รับรู้ว่ามันเป็นของตน white-label เพิ่มเข้ามาว่า: tenant แต่ละรายเห็นมันเป็นแบรนด์ของตน โดยไม่มีร่องรอยของแบรนด์คุณเลย Espejo คือกรณีตัวอย่างมาตรฐาน `src/brand/types.ts` ระบุไว้ในคอมเมนต์ว่า 'influencer แต่ละรายคือ tenant ที่มีแบรนด์ของตน' tenant ถูกระบุด้วย `slug` ใน URL (`/r/<slug>`) และทุกสิ่ง ทั้งชื่อ, accent, glyph, น้ำเสียง, ว่าจะเสนอการอ่านแบบใด, CTA ของการ upsell ล้วนมาจาก object `Brand` แอปสาธารณะทั้งตัวถูกวาดขึ้นจาก object นั้น

หัวใจเชิงสถาปัตยกรรมคือ SEAM ของข้อมูล ลองดู `src/brand/store.ts`: มันนิยาม `interface Store` ด้วย signature แบบ async (`getBrand`, `listBrands`, `saveBrand`, `addSubscriber`, `listSubscribers`) และ implementation ชื่อ `LocalStore` บน localStorage คอมเมนต์ระบุชัดว่า: 'วันนี้: localStorage พรุ่งนี้: Supabase (signature เดียวกัน) UI จะไม่แตะที่จัดเก็บข้อมูลโดยตรง มีแต่ผ่าน interface นี้เท่านั้น' interface นั้นคือรอยต่อ: UI พึ่งพา ABSTRACTION ไม่ใช่ implementation การเปลี่ยน backend = เขียนคลาสใหม่ที่ implement `Store` โดยไม่ต้องแตะคอมโพเนนต์แม้แต่ตัวเดียว

tenant เดินทางไปยัง UI ได้อย่างไร: `BrandProvider.tsx` รับ `slug` เข้ามา เรียก `store.getBrand(slug)` และถ้ามีอยู่ก็ทำ `applyTheme(brand)` แล้วใส่ brand ลงใน React Context (`useBrand()`) ถ้าไม่มี ก็ทำเครื่องหมาย `notFound` รูปแบบที่สะอาด: จุดเข้าหนึ่งจุดแก้ปัญหา tenant นำ theme ของมันมาใช้ แล้วส่งต่อไปทั้งต้นไม้ คอมโพเนนต์ใดก็ทำ `const brand = useBrand()` แล้ววาดสิ่งที่เป็นของตน ไม่มีใครอื่นแตะ storage หรือตัดสินใจเรื่อง theme

การแยก tenant ออกจากกันคือเส้นแดงของ white-label และนี่คือความเสี่ยงที่แท้จริง: `listSubscribers(slug)` กรองด้วย `brandSlug` ใน localStorage นั่นเป็นเรื่องง่าย แต่ FRAGILE เพราะทุกอย่างอยู่ในเบราว์เซอร์เดียวกัน ไม่มีพรมแดนความปลอดภัยที่แท้จริง ช่วงเวลาวิกฤตคือการย้ายไป Supabase ตรงนั้นการแยกข้อมูล MUST ย้ายไปอยู่ที่ Postgres RLS (แถวของ subscriber มองเห็นได้เฉพาะ tenant ของตน) ซึ่งเป็นวินัยเดียวกับที่ MOONKEY ใช้กับ `is_admin()` และ policy แบบ self-or-admin ใน multi-tenant ที่แท้จริง การกรอง `WHERE slug = ...` ที่ฝั่ง client ไม่ใช่ความปลอดภัย ความปลอดภัยคือ RLS ที่ฐานข้อมูล

การตั้งค่าต่อ tenant โดยไม่แตกแขนงโค้ด: สังเกตว่า Espejo ไม่มี `if (tenant === 'lunarosa')` อยู่ที่ใดเลย ความหลากหลายคือ DATA (`Brand.readings`, `Brand.voice`, `Brand.offer`) ไม่ใช่ตรรกะแบบมีเงื่อนไข นั่นคือกฎของ white-label ที่ดี: ความแตกต่างระหว่างลูกค้าอยู่ในการตั้งค่า (ข้อมูล) ไม่อยู่ในการแตกแขนงของโค้ดเลย ทันทีที่คุณเขียน `if (ลูกค้า X)` ตัวแรก คุณก็เริ่ม fork ผลิตภัณฑ์และเริ่มสูญเสียเศรษฐศาสตร์ของโมเดลนี้

มี guardrail เชิงจริยธรรมเฉพาะตัวใน Espejo ที่ไม่ใช่ทางเลือก: หน่วยความจำของโปรเจกต์ระบุว่าจะไม่สร้างกลไกดูดข้อมูล lead อย่างลับๆ หรือขายข้อมูลส่วนบุคคล/ข้อมูลชีวภาพ มีแต่ข้อมูล first-party ที่ได้รับความยินยอมและข้อมูลรวมแบบนิรนามเท่านั้น ในผลิตภัณฑ์ multi-tenant ที่จัดการข้อมูลของผู้ใช้ปลายทางของลูกค้าคุณ โมเดลความยินยอม (`types.ts` มีเวอร์ชันของข้อความความยินยอมที่ถูกตอบรับ และ `Brand.legal.responsible`) เป็นส่วนหนึ่งของสถาปัตยกรรม ไม่ใช่ส่วนเสริมทางกฎหมายที่เพิ่มมาทีหลัง ผู้ควบคุมการประมวลผลข้อมูลคือ influencer-tenant และสิ่งนั้นต้องถูกออกแบบไว้ในข้อมูล

MOONKEY รัน 6 locale `['es','en','th','fr','it','ch']` (config อยู่ใน `src/i18n/config.ts`) ES อยู่ที่ราก ส่วนที่เหลืออยู่ใต้ prefix (`/en/`, `/th/`, `/fr/`, `/it/`, `/ch/`) ชิ้นส่วนที่หลีกเลี่ยงการทำหน้าซ้ำคือ Astro i18n พร้อม `fallbackType: 'rewrite'` ใน `astro.config.mjs` ในช่วง build Astro จะ REWRITE แต่ละหน้าด้วยบริบทของแต่ละ locale ดังนั้น `index.astro` ไฟล์เดียวจึง generate HTML ที่แปลแล้ว 6 ไฟล์ ไม่มี `pages/en/index.astro`, `pages/fr/index.astro`… มีเพียงไฟล์เดียว นั่นคือกฎหลัก: เทมเพลตเดียว ผลลัพธ์ N รายการ

fallback คือสิ่งที่ทำให้ระบบทนทานโดยไม่ต้องแปลทุกอย่างพร้อมกัน: `astro.config.mjs` ประกาศ `fallback: { en:'es', th:'es', fr:'es', it:'es', ch:'es' }` และฟังก์ชัน `useTranslations` ใน `src/i18n/utils.ts` ก็ implement ห่วงโซ่เดียวกัน: `dict[key] ?? base[key] ?? key` กล่าวคือ: ถ้าฝรั่งเศสขาด key ก็ตกไปที่สเปน ถ้าสเปนก็ไม่มี ก็คืน key นั้นเอง (มองเห็นได้ ตามจับง่าย) สิ่งนี้ทำให้คุณ LAUNCH ได้พร้อมคำแปลที่ไม่สมบูรณ์โดยไม่พังอะไร ภาษาฝรั่งเศสจะแสดงสเปนตรงที่ยังไม่ได้แปล ไม่ใช่หน้าที่พัง

MOONKEY ใช้ i18n สามรูปแบบ และ CLAUDE.md เตือนถึงความไม่สอดคล้องนี้ ซึ่งในตัวมันเองก็เป็นบทเรียนของวิชาชีพ: (1) dictionary `src/i18n/ui.ts` ที่มี `t('key')` สำหรับ chrome/nav สั้นๆ (~240 keys); (2) object เนื้อหาแบบ inline ที่มี `cLocale = (es|th) ? locale : 'en'` ซึ่งยุบ FR/IT/CH ให้เป็น EN สำหรับเนื้อหาหนักอย่างหลักสูตร; (3) หน้า `src/pages/en/*.astro` ที่ override เฉพาะภาษาอังกฤษ รูปแบบที่ 3 คือหนี้: มี 5 หน้าระดับรากที่ hardcode เป็นภาษาสเปน ดังนั้น `/th/fr/it/ch` จึงแสดง ES ในหน้าเหล่านั้น บทเรียน: เลือกรูปแบบหลักเพียงรูปแบบเดียว (dictionary พร้อม fallback) แล้วถือว่ารูปแบบอื่นเป็นหนี้ที่ต้องจ่าย ไม่ใช่ความหลากหลายที่ดีต่อสุขภาพ

บั๊กที่แพงที่สุดของ i18n ที่ใช้ prefix คือ href ดิบ ถ้าคุณเขียน `<a href='/cuenta'>` จากหน้าที่อยู่ใต้ `/fr/` คุณก็ส่งผู้ใช้ออกไปนอกภาษาของเขา ด้วยเหตุนี้ MOONKEY จึงมี `localizedPath(pathname, target)` ใน `utils.ts`: มันลบ prefix ของ locale ปัจจุบันออก สร้าง path ใหม่ แล้วเติม target นำหน้า (`/fr/cuenta`) โดยปล่อย ES ไว้ที่ราก CLAUDE.md ระบุว่านี่เป็นข้อบังคับ: 'ใช้ `localizedPath('/ruta', locale)` ไม่ใช่ `/ruta` ดิบ' จงซึมซับสิ่งนี้: ในเว็บที่มี prefix ภาษา ทุกลิงก์ต้องผ่านฟังก์ชัน localization โดยไม่มีข้อยกเว้น

การตรวจหา locale ที่ใช้งานอยู่มีความละเอียดอ่อนที่ `utils.ts` แก้ไว้: `resolveLocale(currentLocale, pathname)` เลือก `Astro.currentLocale` มากกว่าการตรวจจาก URL เพราะในช่วง rewrite ของ fallback URL อาจสูญเสีย prefix ไป และมีเพียงบริบทของ Astro เท่านั้นที่รู้ locale ที่แท้จริง ถ้าคุณตรวจหา locale ด้วย `pathname.split('/')` อย่างเดียว คุณจะผิดพลาดตรงหน้าที่ใช้ fallback พอดี กฎคือ: เชื่อบริบทของเฟรมเวิร์กก่อน เชื่อ URL เป็นตัวสำรอง

ตัวเลือกภาษาต้องการ dictionary แยกกันสองชุด: `LOCALE_LABELS` (ES, EN, TH…) สำหรับ switcher แบบกระชับ และ `LOCALE_NAMES` (Español, ไทย, Italiano…) สำหรับ dropdown แบบเต็ม และระวังกรณีแปลก: 'ch' ตรงนี้คือ Deutsch (CH) เยอรมันสวิส ไม่ใช่ภาษาจีน คอมเมนต์ใน `config.ts` ชี้แจงไว้ ความกำกวมประเภทนี้ (รหัสที่ดูเหมือนภาษาอื่น) คือสิ่งที่คุณควรบันทึกไว้ในโค้ดเพื่อไม่ให้ใครแปลผิดเป็นภาษาที่ไม่ถูกต้องในอีกหกเดือนข้างหน้า

MOONKEY ถูก deploy บน Cloudflare Pages (`moonkeylab.pages.dev`) จาก repo `garciafradepablo-pixel/xop` ขั้นตอนพื้นฐาน: เชื่อม repo ของ GitHub เข้ากับ Cloudflare Pages กำหนด build command (`npm run build`) และ output directory (`dist/` ใน Astro) การ push ไป main แต่ละครั้งจะ trigger build บน CI แล้วเผยแพร่ คุณไม่ได้อัปโหลดไฟล์ด้วยมือ deploy เป็นผลพวงของ git push นั่นให้ความสามารถในการทำซ้ำได้แก่คุณ: สิ่งที่อยู่ในโปรดักชันคือสิ่งที่อยู่ใน commit เป๊ะ

สำหรับ SSG ล้วนอย่าง MOONKEY Cloudflare เพียงเสิร์ฟ HTML แบบ static จาก build เท่านั้น ไม่มี runtime ของเซิร์ฟเวอร์ สิ่งนี้สำคัญต่อโมเดลความปลอดภัย (คุณจะได้เห็นใน Ops): เนื่องจากไม่มี handler ฝั่งเซิร์ฟเวอร์ env เดียวที่สำคัญในโปรดักชันคือสิ่งที่ถูก inject ในช่วง BUILD ถ้าแอปของคุณต้องการตรรกะฝั่งเซิร์ฟเวอร์ (ซึ่งไม่ใช่กรณีของ MOONKEY หรือ XNLAB ที่เป็นเนื้อหา) ตรงนั้น Cloudflare Functions/Workers จึงเข้ามามีบทบาท แต่อย่าใส่มันถ้าคุณไม่ต้องการ

พรมแดนของความลับคือบทเรียนหลักของโมดูลนี้ ใน Astro/Vite ตัวแปร `PUBLIC_*` (Astro) หรือ `VITE_*` (Vite ล้วนอย่าง Espejo) ถูก inject เข้าไปใน bundle ของ client มันมองเห็นได้สำหรับทุกคนที่เปิด DevTools ส่วนที่เหลืออยู่ในช่วง build MOONKEY ตั้ง Supabase anon key เป็น public โดยตั้งใจ: CLAUDE.md ระบุ 'เฉพาะ anon key' ใน `src/lib/supabase.ts` เพราะ anon key ถูกออกแบบมาให้เป็น public (พลังของมันถูกจำกัดด้วย RLS ไม่ใช่ด้วยความลับ) กฎเด็ดขาด: `service_role` key ไม่มีวันมี prefix public และไม่มีวันไปอยู่ในเว็บ static ถ้าคุณวางมันลงไป มันก็อยู่ใน bundle และนั่นคือจบเกม

ใน Cloudflare คุณตั้งค่า env vars ใน dashboard (Settings → Environment variables) โดยแยก Production จาก Preview ตัวที่ build ของคุณต้องเปิดเผยให้ client จะมี prefix ที่ถูกต้อง ส่วนตัวที่ใช้เฉพาะใน process ของ build (token ของ API บุคคลที่สามเพื่อ generate เนื้อหา) จะไม่มี prefix และไม่ไปลงเอยใน `dist/` การตรวจสอบที่บังคับหลัง deploy: ดาวน์โหลด JS ของโปรดักชันของคุณ แล้วทำ `grep -ri 'service_role\|secret\|sk_'` บน `dist/` ถ้ามีอะไรปรากฏ คุณมีการรั่วไหลที่ต้อง rotate ทันที

โดเมนของตัวเอง: ใน Cloudflare Pages ไปที่ Custom domains → เพิ่มโดเมนของคุณ Cloudflare จะสร้าง DNS records ให้ (ถ้าโดเมนอยู่ใน Cloudflare ก็อัตโนมัติ ถ้าไม่ ก็เพิ่ม CNAME ชี้ไปที่ `*.pages.dev`) HTTPS เป็นอัตโนมัติ `.pages.dev` ยังคงทำงานเป็น URL สำรอง สำหรับ preview แต่ละ PR/branch จะ generate URL ชั่วคราวของตัวเอง ใช้มันเพื่อตรวจสอบการเปลี่ยนแปลงก่อน merge เข้า main โดยไม่ต้องแตะโปรดักชัน

failure mode ของ deploy ที่เกิดขึ้นจริง: (1) build ผ่านในเครื่องแต่ล้มเหลวบน CI เพราะ dependency อยู่ใน `node_modules` ในเครื่องแต่ไม่อยู่ใน `package.json` ให้รัน `npm ci` (ไม่ใช่ `install`) ในสภาพแวดล้อมที่สะอาดเพื่อจำลอง CI (2) ตัวแปรที่มีอยู่ในเครื่อง (`.env`) แต่คุณไม่ได้ตั้งค่าใน dashboard → build ผ่านแต่แอปล้มเหลวใน runtime ด้วยค่า undefined (3) คำเตือนเชิงรูปลักษณ์ของ Astro เกี่ยวกับ `Astro.request.headers` ใน build แบบ static ที่มี i18n rewrite `astro.config.mjs` บันทึกไว้ว่าไม่เป็นอันตราย build ผ่าน อย่าไล่ตามคำเตือนที่ config ได้ระบุไว้แล้วว่าเป็นสิ่งที่คาดหมาย

ทบทวนรอยต่อจาก BD-03: ใน Espejo `src/brand/store.ts` นิยาม `interface Store` ด้วย signature แบบ async และ `LocalStore` implement มันบน localStorage คอมเมนต์คือวิทยานิพนธ์ทั้งหมดของโมดูลนี้: 'วันนี้: localStorage พรุ่งนี้: Supabase (signature เดียวกัน)' เพราะ interface เป็น async อยู่แล้ว (`Promise<Brand | null>`) UI จึงไม่สังเกตความแตกต่างระหว่างการอ่านจากหน่วยความจำกับการอ่านจากเครือข่าย เพราะ `await` อยู่ตรงนั้นแล้ว API แบบ synchronous จะทำให้การย้ายระบบเป็นไปไม่ได้โดยไม่แตะทุกการเรียก การออกแบบรอยต่อเป็น async ตั้งแต่วันแรกคือการตัดสินใจที่ให้ผลตอบแทนตรงนี้

การ swap ที่เป็นรูปธรรม: คุณเขียนคลาส `SupabaseStore implements Store` `getBrand(slug)` เปลี่ยนจากการอ่าน localStorage ไปเป็น `await supabase.from('brands').select().eq('slug', slug).single()` `addSubscriber` เปลี่ยนจาก `write()` ไปเป็น `.insert()` signature เหมือนกันทุกประการ สุดท้าย หนึ่งบรรทัดเปลี่ยนทั้งโลก: `export const store: Store = new SupabaseStore()` แทน `new LocalStore()` ไม่แตะคอมโพเนนต์แม้แต่ตัวเดียว นั่นคือความหมายของ 'การเปลี่ยนชั้นข้อมูลโดยไม่ต้องเขียนแอปใหม่': โค้ดที่เหลือพึ่งพา `Store` ไม่ใช่ localStorage

แต่การย้ายที่จัดเก็บข้อมูลคือครึ่งที่ง่าย ครึ่งที่จริงจังคือ SECURITY และตรงนี้โมเดลทั้งหมดเปลี่ยน ใน localStorage ไม่มีพรมแดน ทุกอย่างอยู่ในเบราว์เซอร์ของผู้ใช้ ใน Supabase เนื่องจาก client พก anon key เท่านั้น (MOONKEY: `src/lib/supabase.ts`, 'เฉพาะ anon key') อำนาจไม่ได้อยู่ที่ client แต่อยู่ที่ Postgres RLS MOONKEY กำหนดไว้อย่างไม่กำกวม: 'อำนาจ = RLS ไม่ใช่ client' เมื่อ Espejo ย้าย subscribers ตัวกรอง `WHERE brandSlug = slug` ที่วันนี้ทำใน JS MUST กลายเป็น policy RLS ที่รับประกันว่า tenant อ่านได้เฉพาะ subscribers ของตน ตัวกรองที่ฝั่ง client เป็นเพียงความสะดวก RLS คือความปลอดภัย

รูปแบบอ้างอิงของ RLS ใน MOONKEY: ตาราง `profiles/progress/feedback/proofs` มี SELECT แบบ 'self-or-admin' ผ่าน `is_admin()` (ฟังก์ชัน SECURITY DEFINER) ตรวจสอบแล้วโดยการสวมรอย ผู้ที่ไม่ใช่ admin อ่านแถวของผู้อื่นไม่ได้ `proofs` INSERT ต้องมี session และผูก `user_id = auth.uid()` (policy `proofs_insert_self`) คอลัมน์ที่อ่อนไหว (`role`, `founder_badge`) ไม่สามารถแก้ไขได้สำหรับผู้ที่ไม่ใช่ admin ผ่าน trigger guard ดังนั้นไม่มีใคร self-escalate ได้ นั่นคือเทมเพลตทางความคิดสำหรับการย้ายระบบใดๆ: ทุก operation (SELECT/INSERT/UPDATE) ต้องการ policy ที่บังคับใช้ได้แม้ผู้โจมตีจะควบคุม client ก็ตาม

สุขอนามัยของการย้ายข้อมูล: คุณต้องการ schema (ตาราง `brands`, ตาราง `subscribers` ที่มี `brand_slug`) ที่ apply ในรูป MIGRATION ที่มีเวอร์ชัน (ไม่ใช่ SQL กระจัดกระจายใน console MOONKEY: 'การเปลี่ยนแปลง RLS/ความปลอดภัย: migration ที่มีเวอร์ชัน + `get_advisors` หลังจากนั้น') จากนั้น script ที่รันครั้งเดียวซึ่งอ่าน localStorage ที่มีอยู่แล้วทำ `insert` จำนวนมากไปยัง backend แบบ idempotent (ที่คุณรันซ้ำได้โดยไม่ทำซ้ำข้อมูล) และช่วงเวลาเขียนแบบ double-write ทางเลือก ถ้าคุณหยุดแอปไม่ได้: เขียนไปทั้งสองที่จนกว่าจะยืนยันความเท่าเทียม แล้วจึงตัด localStorage

ระวังพรมแดนจริยธรรมที่ Espejo แบกอยู่: หน่วยความจำของโปรเจกต์ห้ามดูดข้อมูลส่วนบุคคล/ชีวภาพอย่างลับๆ มีแต่ข้อมูล first-party ที่ได้รับความยินยอมและข้อมูลรวมแบบนิรนามเท่านั้น การย้ายไป backend เพิ่มพลังของข้อมูล (ตอนนี้มันคงอยู่ ถูกนำมาเชื่อมโยง ถูก export ได้) ดังนั้นโมเดลความยินยอมที่ใน localStorage แทบจะเป็นเพียงทฤษฎี กลับกลายเป็นของจริงและตรวจสอบได้ การย้ายเชิงเทคนิคและความรับผิดชอบต่อข้อมูลขึ้นไปพร้อมกัน อย่าย้ายที่จัดเก็บข้อมูลโดยไม่ย้ายหลักประกันความเป็นส่วนตัวไปด้วย