# 485Tech.com — Production Release Checklist

เอกสารนี้เป็น checklist กลางสำหรับ release ทุกครั้ง. เป้าหมายคือให้ local validation, GitHub history, automated build และ Cloudflare production evidence เชื่อมกันอย่างตรวจสอบได้ โดยไม่ประกาศเกินหลักฐาน.

## Release states

| State | ความหมาย | หลักฐานขั้นต่ำ |
|---|---|---|
| Local ready | source/build/test ใน sandbox ผ่าน | build log และ test results |
| GitHub ready | commit อยู่บน `origin/main` | remote SHA ตรงกับ local SHA |
| Build queued | provider รับ commit ไปสร้าง artifact | provider build record ของ SHA |
| Deployed | provider publish Worker/version สำเร็จ | deployment/version record |
| Live verified | public routes และ key flows ใช้งานจริง | read-only route smoke + version evidence |

**Local ready หรือ GitHub ready ไม่เท่ากับ Deployed/Live verified.** ถ้าไม่มี build/deployment record ให้ใช้คำว่า “ยังไม่ยืนยัน production”.

## Pre-commit gate

รันจาก repository rootและเก็บผลลัพธ์ไว้ใน release report:

```bash
npm ci
npm run build
npm run validate:tools
npm run validate:docs
node scripts/validate_syntax.mjs
node scripts/unit-app-test.mjs
node scripts/bg-remover-test.mjs
node scripts/worker-smoke.mjs
node scripts/smoke_all_tools.mjs
node scripts/functional_extra.mjs
node scripts/functional-matrix.mjs
node scripts/deep-tool-sweep.mjs
node scripts/ui-regression.mjs
node scripts/qa-json-snapshots.mjs
node scripts/qa-capability-details.mjs
git diff --check
CI=1 npx --yes wrangler@4.127.0 deploy --dry-run --env production
```

หากแก้เฉพาะ docs สามารถลด test scope ได้ แต่ต้องระบุเหตุผลใน commit/PR. หากแตะ shared runtime, build generator, Worker, i18n, capability contract หรือ generated pages ให้รัน full gate.

## Review before staging

ตรวจว่า source changes อยู่ใน `src/`, `public/scripts/`, `scripts/`, styles หรือ docs ที่เหมาะสม. ตรวจ generated output ว่าสร้างจาก build ล่าสุด. ค้นหา placeholder, secret, token, absolute local path และ debug files. ตรวจ comment กับ docs ว่าไม่ขัด runtime behavior. ใช้ package manager และ lockfile เพียงชุดเดียว; repository นี้ใช้ npm/package-lock.json และ `build.py` เป็น compatibility bridge ไป `npm run build` เท่านั้น.

```bash
git status --short --branch
git diff --stat
git diff --check
git diff --name-only
```

## Commit and push

หนึ่ง commitควรมี intent เดียว. ชื่อ commit ใช้รูปแบบ `type: imperative summary`, เช่น `feat: add local workspace snapshots`, `fix: preserve rejected file queue`, `docs: document deployment source of truth`. ก่อน commitต้องตรวจ staged diff:

```bash
git add -A
git diff --cached --check
git diff --cached --stat
git commit -m "<intent>"
git push origin main
git ls-remote origin refs/heads/main
gh api repos/485Tech/485Tech.com/commits/main --jq '{sha: .sha, message: .commit.message, url: .html_url}'
git status --short --branch
```

ห้ามใส่ credential ใน command line หรือ commit message. หาก push ไม่สำเร็จ ให้รายงาน error จริงและขอให้ผู้ใช้ reauthenticate แทนการเปิดเผย token.

## Automated build source of truth

ต้องเลือก deployment automation เพียงหนึ่งทาง:

| Approach | ใช้เมื่อ | ต้องมีหลักฐาน |
|---|---|---|
| Cloudflare Workers Builds | Worker `home` ผูก repository/branch แล้ว | build configuration, trigger, build record และ deployment record |
| GitHub Actions | ต้องควบคุม test/build/deploy ใน repository | workflow run ของ SHA, protected secrets, environment approval และ deployment result |
| Manual Wrangler | emergency/one-off ที่มี explicit authorization | command, operator, version, rollback note; ไม่ใช่ automation ปกติ |

ห้ามเปิด Workers Builds และ GitHub Actions ให้ deploy production ซ้อนกันโดยไม่กำหนด owner/ordering/rollback. Build validation ที่ GitHub Actions อาจมีได้แม้ deploy ใช้ Workers Builds แต่ต้องแยกชื่อ job และระบุว่า workflow ไม่ publish production.

`wrangler.toml` ของโปรเจกต์ระบุ Worker `home`, assets directory `public` และ production vars. ห้ามเพิ่ม secret ลงไฟล์; ใช้ provider secret store/environment variables.

## Cloudflare verification

หลัง push ให้ตรวจแบบ read-only:

1. ตรวจ Workers Builds configuration ของ Worker `home` และ branch/repository linkage.
2. ตรวจ triggers/builds ว่ามี run จาก commit ล่าสุด.
3. ตรวจ deployment history ว่า version ที่ active สร้างหลัง commit ล่าสุด.
4. ตรวจ public routes `/`, `/tools`, `/use-cases`, `/sitemap.xml`, `/ads.txt`, `/manifest.webmanifest`, `/tools/json` และ `/tools/batch-text`.
5. ตรวจ HTML/asset version, status, security headers, CSP mode และ browser console ตามความเหมาะสม.
6. หากมี 500/1101 ให้จัดเป็น deployment blocker; อย่าแก้ source เพื่อซ่อน error และอย่า claim live.

ผลตรวจ Cloudflare ล่าสุดอยู่ที่ `docs/cloudflare-deployment-audit.md`. รอบ final พบ Workers Builds configuration และ GitHub triggers ของ `home`, code build `4656cf4` สำเร็จด้วย UUID `35a95605-6ebe-4365-aede-e98f9b6381e3` และ docs-only build `b63aa65` สำเร็จด้วย UUID `6631647b-8ee9-41b6-8c11-b1d432178d73`; public routes, Worker security headers, CSP nonce parity และ HTML `no-store` ผ่าน read-only probe โดยไม่พบ 1101. Active script metadata ยังคืน `deployment_id` ว่าง จึงต้องให้ owner ยืนยัน version history/rollback ใน dashboard ต่อ.

## Rollback

ก่อน release ต้องรู้ว่า rollback ทำผ่าน provider version/deployment record อย่างไร. เก็บ SHA, build id, deployment id และเวลาตรวจ. หาก live smoke ล้ม ให้หยุดการประกาศ, ระบุ blast radius, rollback ไป version ที่รู้ว่าใช้ได้ถ้า owner อนุญาต, แล้วสร้าง incident note. อย่าลบ deployment history หรือ force-push เพื่อซ่อนปัญหา.

## Privacy and ads gate

ตรวจว่า capability metadata และ UI disclosures ตรงกับ network behavior. `bg-remover`, `diagram` และ `excel-chat` ต้องไม่ถูกเรียกว่า fully offline หากยังมี first-use download. AdSense ต้องคง consent-gated/non-personalized default จนเจ้าของบัญชียืนยัน site ownership, account readiness และ CMP/Privacy & Messaging requirements.

## Final handoff

Release report ต้องระบุวันที่, commit SHA, changed scope, validation counts, generated assets, deployment provider/source of truth, live probe results, known limitations และ next acceptance criteria. แนบ links ไปยัง `docs/release-gate-final.md`, `docs/cloudflare-deployment-audit.md`, architecture และ test evidence.