@warnyin/agents 0.9.0 → 0.10.0

package/src/.warnyin/workflow/stages/discovery.md

@@ -1,78 +1,78 @@
-# Stage: DISCOVERY (optional)
-
-> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
-> เป้าหมาย: เปลี่ยนความต้องการที่ยังคลุมเครือ ให้เป็น **ความเข้าใจร่วมกัน (shared understanding)** ที่ชัดพอจะเข้า DESIGN ได้
-> **Context profile:** สวมโหมด `research` (`.warnyin/workflow/contexts/research.md`) — session-level posture ของ stage นี้
-
----
-
-## 1. Discovery คืออะไร / ใช้เมื่อไหร่
-
-Discovery คือขั้นตอน **ค้นหาข้อมูล + deep research + สัมภาษณ์** เพื่อตี scope สิ่งที่ user ต้องการ
-จากภาพกว้าง → แคบลงเรื่อยๆ จนทุกฝ่ายเข้าใจตรงกันก่อนลงมือออกแบบ
-
-- **optional** — ข้ามได้ถ้า scope ชัดอยู่แล้ว (งานเล็ก/ชัดเจน) แล้วไป DESIGN ตรงๆ
-- ใช้เมื่อ: โจทย์กว้าง/กำกวม, มีหลายทางเลือก, มี trade-off ที่ต้องตัดสินใจ, หรือ user พิมพ์ **"ซักถามฉันหน่อย" / "grill me"**
-
----
-
-## 2. Input ที่ต้องอ่านก่อนเริ่ม (เรียงลำดับ)
-
-อ่านเพื่อ "ground" ตัวเองในบริบทโปรเจกต์ — **อย่าเพิ่งถาม user สิ่งที่หาเองได้**
-
-1. `docs/project.md` — ★ จุดเริ่มเสมอ: โปรเจกต์นี้คืออะไร เป้าหมาย ลูกค้า ขอบเขต
-2. `docs/rule.md`, `docs/infra.md` — กฎและโครงสร้างพื้นฐาน
-3. `docs/codemap/index.md` — แผนที่โค้ด (ไปอ่านโค้ดจริงต่อได้)
-4. `docs/features/*`, `docs/techstack/*` — ฟีเจอร์เดิม + tech stack ของแต่ละ component
-5. `docs/stages/context.md` และ topic ที่ `achieved/` ที่ใกล้เคียง — เคยทำอะไรไปแล้ว
-
----
-
-## 3. หลักการทำงาน (operating principles)
-
-1. **กว้าง → แคบ:** เริ่มจากภาพรวม แล้วค่อยๆ ตี scope ให้แคบลงทีละชั้น (problem → goal → ขอบเขต → ทางเลือก → รายละเอียด)
-2. **ถามทีละข้อ (one question at a time):** ห้ามถามรัวหลายข้อพร้อมกัน รอคำตอบก่อนค่อยถามข้อถัดไป
-3. **เสนอคำตอบที่แนะนำทุกครั้ง:** ทุกคำถามต้องแนบ *recommended answer* + เหตุผลสั้นๆ ให้ user แค่ยืนยัน/แก้ ไม่ใช่คิดเองทั้งหมด
-4. **โค้ดตอบได้ → ไปอ่านโค้ด ไม่ต้องถาม:** ถ้าคำถามไหนตอบได้ด้วยการ inspect โค้ด/เอกสาร ให้ไปหาคำตอบเองแล้วรายงานสิ่งที่พบ แทนการถาม user
-5. **เดินทีละกิ่งของ decision tree:** ไล่ทุกแขนงของการตัดสินใจ แก้ความสัมพันธ์ระหว่างการตัดสินใจทีละจุด ไม่ข้าม
-6. **บันทึกทันทีที่ตกลงได้:** พอได้ข้อสรุปที่ชัดเจนในประเด็นไหน ให้จดลง `discovery.md` (decision log) เลย ไม่รอจบ
-7. **ทุกข้อสรุปต้องสอดคล้องกับโปรเจกต์:** อ้างอิงกลับไปที่ `docs/project.md` และข้อจำกัดจริงเสมอ
-8. **ใช้ role lens ตอนตั้งคำถาม:** มอง scope ผ่าน checklist ของ **BA** (`.warnyin/workflow/roles/ba.md` — business process, ข้อยกเว้น, ข้อมูล, ข้อจำกัด) และ **PO** (`.warnyin/workflow/roles/po.md` — คุณค่า, priority, MVP, scope out, success metric) เพื่อให้คำถามครบมุมไม่หลุดประเด็น
-
-### โหมด "ซักถามฉันหน่อย" (grill mode)
-เมื่อ user สั่ง grill → **ซักถามอย่างไม่หยุดหย่อนทุกแง่มุมของแผน** จนเข้าใจตรงกัน:
-ความถูกต้องของสมมติฐาน, edge case, ทางเลือกที่ตัดทิ้งและทำไม, ผลกระทบต่อระบบเดิม, ต้นทุน/เวลา, ความเสี่ยง, เกณฑ์ความสำเร็จ — ยังคงถามทีละข้อ + เสนอคำตอบที่แนะนำ
-
----
-
-## 4. ลำดับขั้นการทำงาน (process loop)
-
-1. **เตรียมพื้นที่:** ถ้ายังไม่มีโฟลเดอร์ topic → copy `.warnyin/template/stages/[topic]/` เป็น `docs/stages/<slug>/` (slug = kebab-case ของหัวข้องาน)
-2. **Ground:** อ่าน Input ในข้อ 2 ให้ครบ สรุปความเข้าใจเริ่มต้น 3-5 บรรทัด ให้ user ยืนยัน
-3. **ตี scope กว้าง→แคบ ผ่านการสัมภาษณ์:** วนลูป — ถาม 1 ข้อ (พร้อม recommended answer) → user ตอบ → จดผลลง decision log → ถ้าตอบได้ด้วยโค้ดให้ไปอ่านเอง
-4. **research คู่ขนาน:** สิ่งที่ต้องค้นจริง (prior art, ทางเลือก technical, ข้อจำกัด) → จดลง `research.md` พร้อม evidence/links
-5. **เช็ค gate (ข้อ 6):** เมื่อครบเกณฑ์ → สรุปและเสนอ "พร้อมเข้า DESIGN"
-
----
-
-## 5. Output (สร้างที่ `docs/stages/<slug>/`)
-
-| ไฟล์ | เนื้อหา | template |
-|---|---|---|
-| `discovery.md` | decision log + shared understanding + scope + PRD ย่อ + feature ideas | `.warnyin/template/stages/[topic]/discovery.md` |
-| `research.md` | คำถามวิจัย + วิธี/แหล่ง + findings + code inspection + implication | `.warnyin/template/stages/[topic]/research.md` |
-
-> เริ่มจาก template (ไฟล์ใน `.warnyin/template/stages/[topic]/`) เป็นโครง แล้วเติมเนื้อหาจริง อัปเดตทุกครั้งที่ได้ข้อสรุปใหม่
-
----
-
-## 6. Gate → เข้า DESIGN ได้เมื่อ
-
-- [ ] Problem / why-now ชัด และผูกกับ `docs/project.md`
-- [ ] Scope in / out ระบุชัด (สิ่งที่จะทำ และจะไม่ทำ)
-- [ ] Decision log ปิดทุกประเด็นสำคัญ — ไม่มี open question ที่ block การออกแบบ
-- [ ] เกณฑ์ความสำเร็จ (success criteria) วัดผลได้
-- [ ] สมมติฐาน/ข้อจำกัด/ความเสี่ยงหลัก ถูกบันทึก
-- [ ] user ยืนยันว่า "เข้าใจตรงกันแล้ว"
-
-ยังไม่ครบ → อยู่ Discovery ต่อ ห้ามข้ามไป DESIGN
+# Stage: DISCOVERY (optional)
+
+> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
+> เป้าหมาย: เปลี่ยนความต้องการที่ยังคลุมเครือ ให้เป็น **ความเข้าใจร่วมกัน (shared understanding)** ที่ชัดพอจะเข้า DESIGN ได้
+> **Context profile:** สวมโหมด `research` (`.warnyin/workflow/contexts/research.md`) — session-level posture ของ stage นี้
+
+---
+
+## 1. Discovery คืออะไร / ใช้เมื่อไหร่
+
+Discovery คือขั้นตอน **ค้นหาข้อมูล + deep research + สัมภาษณ์** เพื่อตี scope สิ่งที่ user ต้องการ
+จากภาพกว้าง → แคบลงเรื่อยๆ จนทุกฝ่ายเข้าใจตรงกันก่อนลงมือออกแบบ
+
+- **optional** — ข้ามได้ถ้า scope ชัดอยู่แล้ว (งานเล็ก/ชัดเจน) แล้วไป DESIGN ตรงๆ
+- ใช้เมื่อ: โจทย์กว้าง/กำกวม, มีหลายทางเลือก, มี trade-off ที่ต้องตัดสินใจ, หรือ user พิมพ์ **"ซักถามฉันหน่อย" / "grill me"**
+
+---
+
+## 2. Input ที่ต้องอ่านก่อนเริ่ม (เรียงลำดับ)
+
+อ่านเพื่อ "ground" ตัวเองในบริบทโปรเจกต์ — **อย่าเพิ่งถาม user สิ่งที่หาเองได้**
+
+1. `docs/project.md` — ★ จุดเริ่มเสมอ: โปรเจกต์นี้คืออะไร เป้าหมาย ลูกค้า ขอบเขต
+2. `docs/rule.md`, `docs/infra.md` — กฎและโครงสร้างพื้นฐาน
+3. `docs/codemap/index.md` — แผนที่โค้ด (ไปอ่านโค้ดจริงต่อได้)
+4. `docs/features/*`, `docs/techstack/*` — ฟีเจอร์เดิม + tech stack ของแต่ละ component
+5. `docs/stages/context.md` และ topic ที่ `achieved/` ที่ใกล้เคียง — เคยทำอะไรไปแล้ว
+
+---
+
+## 3. หลักการทำงาน (operating principles)
+
+1. **กว้าง → แคบ:** เริ่มจากภาพรวม แล้วค่อยๆ ตี scope ให้แคบลงทีละชั้น (problem → goal → ขอบเขต → ทางเลือก → รายละเอียด)
+2. **ถามทีละข้อ (one question at a time):** ห้ามถามรัวหลายข้อพร้อมกัน รอคำตอบก่อนค่อยถามข้อถัดไป
+3. **เสนอคำตอบที่แนะนำทุกครั้ง:** ทุกคำถามต้องแนบ *recommended answer* + เหตุผลสั้นๆ ให้ user แค่ยืนยัน/แก้ ไม่ใช่คิดเองทั้งหมด
+4. **โค้ดตอบได้ → ไปอ่านโค้ด ไม่ต้องถาม:** ถ้าคำถามไหนตอบได้ด้วยการ inspect โค้ด/เอกสาร ให้ไปหาคำตอบเองแล้วรายงานสิ่งที่พบ แทนการถาม user
+5. **เดินทีละกิ่งของ decision tree:** ไล่ทุกแขนงของการตัดสินใจ แก้ความสัมพันธ์ระหว่างการตัดสินใจทีละจุด ไม่ข้าม
+6. **บันทึกทันทีที่ตกลงได้:** พอได้ข้อสรุปที่ชัดเจนในประเด็นไหน ให้จดลง `discovery.md` (decision log) เลย ไม่รอจบ
+7. **ทุกข้อสรุปต้องสอดคล้องกับโปรเจกต์:** อ้างอิงกลับไปที่ `docs/project.md` และข้อจำกัดจริงเสมอ
+8. **ใช้ role lens ตอนตั้งคำถาม:** มอง scope ผ่าน checklist ของ **BA** (`.warnyin/workflow/roles/ba.md` — business process, ข้อยกเว้น, ข้อมูล, ข้อจำกัด) และ **PO** (`.warnyin/workflow/roles/po.md` — คุณค่า, priority, MVP, scope out, success metric) เพื่อให้คำถามครบมุมไม่หลุดประเด็น
+
+### โหมด "ซักถามฉันหน่อย" (grill mode)
+เมื่อ user สั่ง grill → **ซักถามอย่างไม่หยุดหย่อนทุกแง่มุมของแผน** จนเข้าใจตรงกัน:
+ความถูกต้องของสมมติฐาน, edge case, ทางเลือกที่ตัดทิ้งและทำไม, ผลกระทบต่อระบบเดิม, ต้นทุน/เวลา, ความเสี่ยง, เกณฑ์ความสำเร็จ — ยังคงถามทีละข้อ + เสนอคำตอบที่แนะนำ
+
+---
+
+## 4. ลำดับขั้นการทำงาน (process loop)
+
+1. **เตรียมพื้นที่:** ถ้ายังไม่มีโฟลเดอร์ topic → copy `.warnyin/template/stages/[topic]/` เป็น `docs/stages/<slug>/` (slug = kebab-case ของหัวข้องาน)
+2. **Ground:** อ่าน Input ในข้อ 2 ให้ครบ สรุปความเข้าใจเริ่มต้น 3-5 บรรทัด ให้ user ยืนยัน
+3. **ตี scope กว้าง→แคบ ผ่านการสัมภาษณ์:** วนลูป — ถาม 1 ข้อ (พร้อม recommended answer) → user ตอบ → จดผลลง decision log → ถ้าตอบได้ด้วยโค้ดให้ไปอ่านเอง
+4. **research คู่ขนาน:** สิ่งที่ต้องค้นจริง (prior art, ทางเลือก technical, ข้อจำกัด) → จดลง `research.md` พร้อม evidence/links
+5. **เช็ค gate (ข้อ 6):** เมื่อครบเกณฑ์ → สรุปและเสนอ "พร้อมเข้า DESIGN"
+
+---
+
+## 5. Output (สร้างที่ `docs/stages/<slug>/`)
+
+| ไฟล์ | เนื้อหา | template |
+|---|---|---|
+| `discovery.md` | decision log + shared understanding + scope + PRD ย่อ + feature ideas | `.warnyin/template/stages/[topic]/discovery.md` |
+| `research.md` | คำถามวิจัย + วิธี/แหล่ง + findings + code inspection + implication | `.warnyin/template/stages/[topic]/research.md` |
+
+> เริ่มจาก template (ไฟล์ใน `.warnyin/template/stages/[topic]/`) เป็นโครง แล้วเติมเนื้อหาจริง อัปเดตทุกครั้งที่ได้ข้อสรุปใหม่
+
+---
+
+## 6. Gate → เข้า DESIGN ได้เมื่อ
+
+- [ ] Problem / why-now ชัด และผูกกับ `docs/project.md`
+- [ ] Scope in / out ระบุชัด (สิ่งที่จะทำ และจะไม่ทำ)
+- [ ] Decision log ปิดทุกประเด็นสำคัญ — ไม่มี open question ที่ block การออกแบบ
+- [ ] เกณฑ์ความสำเร็จ (success criteria) วัดผลได้
+- [ ] สมมติฐาน/ข้อจำกัด/ความเสี่ยงหลัก ถูกบันทึก
+- [ ] user ยืนยันว่า "เข้าใจตรงกันแล้ว"
+
+ยังไม่ครบ → อยู่ Discovery ต่อ ห้ามข้ามไป DESIGN

package/src/.warnyin/workflow/stages/ship.md

@@ -1,90 +1,92 @@
-# Stage: SHIP
-
-> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
-> เป้าหมาย: **ส่งมอบ** — promote ความรู้ระดับ topic ขึ้นเอกสารกลางใน `docs/` + archive topic เข้า `docs/stages/achieved/`
-> **Context profile:** สวมโหมด `review` (`.warnyin/workflow/contexts/review.md`) — session-level posture ของ stage นี้
-
----
-
-## 1. SHIP คืออะไร / ใช้เมื่อไหร่
-
-ใช้หลัง VERIFY ผ่าน Gate แล้ว — SHIP ปิดวงจรของ topic โดยยกความรู้ที่เกิดขึ้นระหว่างงาน
-(feature, rule/standard ใหม่, วิธีเทส, troubleshooting, โครงสร้างโค้ดที่เปลี่ยน) ขึ้น **เอกสารกลางถาวร** ใน `docs/`
-แล้ว archive ทั้ง topic — เพื่อให้งานถัดไปเริ่มจากความรู้ล่าสุดเสมอ
-
-> SHIP เป็นเรื่อง **เอกสาร + archive เท่านั้น** — การ merge โค้ด (build branch → main / PR) จัดการเองนอก workflow
-
----
-
-## 2. Input ที่ต้องอ่านก่อนเริ่ม
-
-1. `docs/stages/<slug>/` **ทุกไฟล์** — discovery, business, proposal, design, build, test, verify, troubleshooting, tasks/*
-   → เข้าใจว่า topic นี้ **ทำอะไร ทำอย่างไร** และเกิดความรู้อะไรใหม่บ้าง
-2. `tasks/<task>/rule.md` section "เสนอเพิ่ม rule ใหม่ (รอ SHIP)" + `standard.md` — rule/standard ใหม่ที่ note ค้างไว้
-3. เอกสารกลางปลายทางที่จะอัปเดต — `docs/features/`, `docs/techstack/<component>/*`, `docs/rule.md`,
-   `docs/troubleshooting.md`, `docs/infra.md`, `docs/project.md`, `docs/codemap/`
-4. โค้ดจริงที่ change กระทบ — สำหรับอัปเดต structure + code map ให้ตรงความเป็นจริง
-
----
-
-## 3. หลักการทำงาน (operating principles)
-
-1. **เข้าใจก่อน promote** — อ่าน topic ทั้งหมดให้เข้าใจว่าทำอะไร/ทำอย่างไร แล้วค่อยตัดสินใจว่าความรู้ชิ้นไหนควรขึ้นไฟล์กลางไหน
-2. **ขอ user ยืนยัน "ครั้งเดียวก่อนลงมือ"** — สรุป promotion plan (feature ใหม่หรือปรับปรุง, ไฟล์กลางที่จะอัปเดต + สาระที่จะใส่, ชื่อโฟลเดอร์ archive) ให้ user อนุมัติ แล้วจึง execute ไม่ถามซ้ำระหว่างทาง
-3. **★ Archive ก่อนอัปเดตเอกสาร** — ย้ายทั้งโฟลเดอร์ `docs/stages/<slug>/` → `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` (วันที่ของวันที่ SHIP) **ก่อน** เริ่มแก้ `docs/` แล้วอ่านเนื้อหาจาก path ใหม่ระหว่าง promote
-4. **กลั่น ไม่ใช่ copy ดิบ** — merge สาระเข้าโครงสร้างของไฟล์กลางเดิม ระวัง duplicate/ขัดแย้งกับเนื้อหาที่มีอยู่; เขียนแบบ "ความรู้ถาวร" ไม่ใช่บันทึกรายงาน
-5. **เอกสารต้องตรงโค้ดจริง** — structure/codemap อัปเดตจากการดูโค้ดจริง ไม่ใช่จากความจำหรือ design เดิม; **ครอบ Spec delta ด้วย** — ถ้าพฤติกรรมจริง (หลัง BUILD/VERIFY) ต่างจาก delta ที่ approve ไว้ → **อัปเดต delta ใน design.md ก่อน แล้วค่อย merge**; และ re-check delta เทียบ `spec.md` ปัจจุบัน ณ เวลา ship (ไม่ใช่ ณ เวลา design)
-6. **อย่าเดา** — เนื้อหาที่ไม่แน่ใจว่าควร promote หรือควรวางไว้ไฟล์ไหน → ถามทีละข้อ + เสนอคำตอบที่แนะนำ
-7. **เก็บ learned-rule ให้หมด — planned + emergent** — รวบรวม rule ที่จะ promote ทุกตัว: ทั้ง **planned** (note "รอ SHIP" ใน `tasks/*/rule.md` §2) และ **emergent** (บทเรียนที่โผล่ตอนลงมือ — สแกน `build.md`/`verify.md`/`troubleshooting.md`/diff); ทุกตัวต้องมี **evidence (บังคับ)** + **scope** + **user ยืนยัน** ก่อน promote — ไม่มี evidence ไม่ promote (สอด "ห้ามเดา"); **learned-rule = กฎ generalize ไม่ใช่ incident** (troubleshooting = incident ที่ *อ้าง* เป็น evidence ได้). พิจารณาครบทุกข้อ (promote หรือตัดทิ้งพร้อมเหตุผล) ห้ามปล่อยค้าง
-
----
-
-## 4. ลำดับขั้นการทำงาน (process)
-
-1. **อ่านทำความเข้าใจ topic + รวบรวม learned-rule candidate:** อ่าน `docs/stages/<slug>/` ทุกไฟล์ — topic นี้ทำอะไร ทำอย่างไร เกิดความรู้ใหม่อะไรบ้าง (เช็คก่อนว่า VERIFY ผ่าน Gate แล้ว — มี `verify.md` สรุปผลผ่าน; ถ้ารัน node ได้ → รัน `node .warnyin/workflow/scripts/validate-topic.mjs <slug>` — มี ✖ ควรแก้ก่อน promote (script เช็คโครง; ความถูกของเนื้อหายังเป็นหน้าที่ผู้ ship)) — พร้อมกันนั้น **รวบรวม learned-rule candidate** เป็นตาราง (ทุกตัว = `rule + evidence + scope + promote?`):
-   - **planned:** จาก `tasks/*/rule.md` §2 "เสนอเพิ่ม rule ใหม่ (รอ SHIP)"
-   - **emergent:** สแกนบทเรียนที่โผล่ตอนลงมือ — `build.md` (pattern แก้ซ้ำ/integration), `verify.md` (รายการแก้+จำนวนรอบ), `troubleshooting.md` (ปัญหายาก→"กันซ้ำ" = candidate ชัดสุด), diff/commit
-   - **entry แต่ละตัว:** `rule` = ข้อความ **generalize** (ถ้าเป็น incident "X พังเพราะ Y" ยกเป็นกฎ "ก่อนแก้ Z เช็ค Y เสมอ") · `evidence` = **บังคับ** concrete pointer 1 บรรทัด + ลิงก์ artifact (`build.md`/`verify.md`/`troubleshooting.md`/diff/commit) — **ไม่มี evidence = ไม่ promote** · `scope` = `component:<c>`→`docs/techstack/<c>/rule.md` หรือ `project`→`docs/rule.md`
-2. **จำแนก feature:** สิ่งที่ทำเป็น **feature ใหม่** หรือ **ปรับปรุง feature เดิม** (เทียบกับ `docs/features/` ที่มีอยู่)
-3. **สรุป promotion plan + ขออนุมัติ (ครั้งเดียว):** feature ใหม่/ปรับปรุง, รายการไฟล์กลางที่จะอัปเดต + สาระ, ชื่อโฟลเดอร์ archive — **fold ตาราง learned-rule (rule + evidence + scope) เข้า approval เดียวกันนี้ ให้ user ยืนยัน per-rule** (✅ promote / ✂️ ตัด + เหตุผล) → รอ user ไฟเขียว
-4. **★ Archive:** ย้ายทั้งโฟลเดอร์ → `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` (ใช้ `git mv` ถ้าเป็น git repo)
-5. **อัปเดตเอกสารกลาง** (อ่านเนื้อหาจาก path ใน achieved):
-   1. **`docs/features/<feature-name>/`** — feature ใหม่ → สร้างโฟลเดอร์ใหม่ (`feature.md` + `business.md`); ปรับปรุง feature เดิม → อัปเดตโฟลเดอร์เดิม โดยใช้เนื้อหาจาก `business.md` / `proposal.md` / `design.md` ของ topic — **และ merge `spec.md`** ตาม Spec delta ใน `design.md` §9: **ADDED** → ต่อท้าย `spec.md` · **MODIFIED** → แทนที่ requirement ชื่อตรงกัน (rename → หาด้วย `[เดิมชื่อ:]`) · **REMOVED** → ลบ requirement; **read-modify-verify — key ไม่เจอ → STOP:** MODIFIED/REMOVED ที่หา key ไม่เจอใน `spec.md` ของ feature ที่ `(→ feature:)` ระบุ → **หยุด ถาม user ห้าม merge เงียบ** (ห้ามตีความเป็น ADDED เอง); **feature ใหม่** → สร้าง `spec.md` จาก ADDED ทั้งก้อน (template `[feature-name]/spec.md`); **feature เดิมยังไม่มี `spec.md`** → สร้างใหม่จาก delta + พฤติกรรมจริง
-   2. **`docs/techstack/<component>/`** — `rule.md` / `standard.md` (learned-rule ที่ยืนยันแล้ว scope `component:<c>` + note "รอ SHIP" ใน tasks), `structure.md` (โครงสร้างที่เปลี่ยน), `test.md` (merge แผนเทสจาก `test.md` ของ topic)
-   3. **`docs/rule.md`** — global rule ใหม่/ที่เปลี่ยน (learned-rule ที่ยืนยันแล้ว scope `project` — กฎระดับโปรเจกต์ ไม่ผูกกับ component เดียว)
-   > promote learned-rule **เฉพาะตัวที่ user ยืนยัน (step 3)** ตาม scope: `component:<c>` → `docs/techstack/<c>/rule.md` · `project` → `docs/rule.md`
-   4. **`docs/troubleshooting.md`** — merge entry จาก `troubleshooting.md` ของ topic (ปัญหา/อาการ/root cause/วิธีแก้/ป้องกันซ้ำ)
-   5. **`docs/infra.md` + `docs/project.md`** — เฉพาะถ้ามีข้อมูลที่เกี่ยวข้อง (env/service ใหม่, scope/เป้าหมายโปรเจกต์ที่ขยับ)
-   6. **`docs/codemap/` ทั้งหมด** — อัปเดต code map ให้ตรงกับโค้ดจริงปัจจุบัน ทำตาม playbook `.warnyin/workflow/codemap.md` (Claude Code: `/warnyin:update-codemaps`)
-6. **เขียนสรุปส่งมอบ:** `achieved/<YYYY-MM-DD>-<slug>/ship.md` — feature ใหม่/ปรับปรุง, เอกสารกลางที่อัปเดต (ไฟล์ → สาระ), note ที่ตัดทิ้งพร้อมเหตุผล
-7. **ปิดงาน:** รายงาน user ว่าส่งมอบครบ — topic ปิดสมบูรณ์
-
----
-
-## 5. Output
-
-| ที่ | เนื้อหา |
-|---|---|
-| `docs/features/<feature-name>/` | feature.md + business.md + spec.md (สร้างใหม่หรืออัปเดต — spec.md merge ตาม Spec delta) |
-| `docs/techstack/<component>/{rule,standard,structure,test}.md` | rule/standard ใหม่, โครงสร้าง, วิธีเทสที่ promote ขึ้น |
-| `docs/rule.md` | global rule ที่เพิ่ม/เปลี่ยน |
-| `docs/troubleshooting.md` | KB ปัญหา-วิธีแก้ที่ merge เข้า |
-| `docs/infra.md`, `docs/project.md` | อัปเดตเฉพาะถ้ามีข้อมูลเกี่ยวข้อง |
-| `docs/codemap/` | code map ตรงกับโค้ดจริงปัจจุบัน |
-| `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` | ทั้ง topic ที่ archive แล้ว + `ship.md` (สรุปการส่งมอบ) |
-
----
-
-## 6. Gate → topic ปิดสมบูรณ์เมื่อ
-
-- [ ] topic ถูกย้ายไป `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` แล้ว (ไม่เหลือใน `docs/stages/`)
-- [ ] `docs/features/` สะท้อน feature ใหม่/ที่ปรับปรุงแล้ว
-- [ ] **Spec delta merge แล้ว** — `spec.md` ของ feature ที่แตะถูก merge ตาม delta; ทุก MODIFIED/REMOVED match requirement จริง (read-modify-verify — key ไม่เจอ → STOP ถาม user แล้ว ไม่ merge เงียบ)
-- [ ] learned-rules (planned + emergent) พิจารณาครบทุกตัว — note "รอ SHIP" ใน `tasks/*/rule.md` + `standard.md` + บทเรียน emergent จาก build/verify/troubleshooting; ทุก promote มี **evidence + user ยืนยัน**, ตัดทิ้งมีเหตุผล
-- [ ] `docs/troubleshooting.md` รวม entry จาก topic แล้ว
-- [ ] `docs/techstack/`, `docs/rule.md`, `docs/infra.md`, `docs/project.md` อัปเดตตามที่เกี่ยวข้อง
-- [ ] `docs/codemap/` ตรงกับโค้ดจริงปัจจุบัน
-- [ ] `ship.md` สรุปการส่งมอบเขียนครบใน achieved
-- [ ] user รับทราบผลการส่งมอบ
-
-ยังไม่ครบ → อยู่ SHIP ต่อ topic ยังไม่ปิด
+# Stage: SHIP
+
+> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
+> เป้าหมาย: **ส่งมอบ** — promote ความรู้ระดับ topic ขึ้นเอกสารกลางใน `docs/` + archive topic เข้า `docs/stages/achieved/`
+> **Context profile:** สวมโหมด `review` (`.warnyin/workflow/contexts/review.md`) — session-level posture ของ stage นี้
+
+---
+
+## 1. SHIP คืออะไร / ใช้เมื่อไหร่
+
+ใช้หลัง VERIFY ผ่าน Gate แล้ว — SHIP ปิดวงจรของ topic โดยยกความรู้ที่เกิดขึ้นระหว่างงาน
+(feature, rule/standard ใหม่, วิธีเทส, troubleshooting, โครงสร้างโค้ดที่เปลี่ยน) ขึ้น **เอกสารกลางถาวร** ใน `docs/`
+แล้ว archive ทั้ง topic — เพื่อให้งานถัดไปเริ่มจากความรู้ล่าสุดเสมอ
+
+> SHIP เป็นเรื่อง **เอกสาร + archive เท่านั้น** — การ merge โค้ด (build branch → main / PR) จัดการเองนอก workflow
+
+---
+
+## 2. Input ที่ต้องอ่านก่อนเริ่ม
+
+1. `docs/stages/<slug>/` **ทุกไฟล์** — discovery, business, proposal, design, build, test, verify, troubleshooting, tasks/*
+   → เข้าใจว่า topic นี้ **ทำอะไร ทำอย่างไร** และเกิดความรู้อะไรใหม่บ้าง
+2. `tasks/<task>/rule.md` section "เสนอเพิ่ม rule ใหม่ (รอ SHIP)" + `standard.md` — rule/standard ใหม่ที่ note ค้างไว้
+3. เอกสารกลางปลายทางที่จะอัปเดต — `docs/features/`, `docs/techstack/<component>/*`, `docs/rule.md`,
+   `docs/troubleshooting.md`, `docs/infra.md`, `docs/project.md`, `docs/codemap/`
+4. โค้ดจริงที่ change กระทบ — สำหรับอัปเดต structure + code map ให้ตรงความเป็นจริง
+
+---
+
+## 3. หลักการทำงาน (operating principles)
+
+1. **เข้าใจก่อน promote** — อ่าน topic ทั้งหมดให้เข้าใจว่าทำอะไร/ทำอย่างไร แล้วค่อยตัดสินใจว่าความรู้ชิ้นไหนควรขึ้นไฟล์กลางไหน
+2. **ขอ user ยืนยัน "ครั้งเดียวก่อนลงมือ"** — สรุป promotion plan (feature ใหม่หรือปรับปรุง, ไฟล์กลางที่จะอัปเดต + สาระที่จะใส่, ชื่อโฟลเดอร์ archive) ให้ user อนุมัติ แล้วจึง execute ไม่ถามซ้ำระหว่างทาง
+3. **★ Archive ก่อนอัปเดตเอกสาร** — ย้ายทั้งโฟลเดอร์ `docs/stages/<slug>/` → `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` (วันที่ของวันที่ SHIP) **ก่อน** เริ่มแก้ `docs/` แล้วอ่านเนื้อหาจาก path ใหม่ระหว่าง promote
+4. **กลั่น ไม่ใช่ copy ดิบ** — merge สาระเข้าโครงสร้างของไฟล์กลางเดิม ระวัง duplicate/ขัดแย้งกับเนื้อหาที่มีอยู่; เขียนแบบ "ความรู้ถาวร" ไม่ใช่บันทึกรายงาน
+5. **เอกสารต้องตรงโค้ดจริง** — structure/codemap อัปเดตจากการดูโค้ดจริง ไม่ใช่จากความจำหรือ design เดิม; **ครอบ Spec delta ด้วย** — ถ้าพฤติกรรมจริง (หลัง BUILD/VERIFY) ต่างจาก delta ที่ approve ไว้ → **อัปเดต delta ใน design.md ก่อน แล้วค่อย merge**; และ re-check delta เทียบ `spec.md` ปัจจุบัน ณ เวลา ship (ไม่ใช่ ณ เวลา design)
+6. **อย่าเดา** — เนื้อหาที่ไม่แน่ใจว่าควร promote หรือควรวางไว้ไฟล์ไหน → ถามทีละข้อ + เสนอคำตอบที่แนะนำ
+7. **เก็บ learned-rule ให้หมด — planned + emergent** — รวบรวม rule ที่จะ promote ทุกตัว: ทั้ง **planned** (note "รอ SHIP" ใน `tasks/*/rule.md` §2) และ **emergent** (บทเรียนที่โผล่ตอนลงมือ — สแกน `build.md`/`verify.md`/`troubleshooting.md`/diff); ทุกตัวต้องมี **evidence (บังคับ)** + **scope** + **user ยืนยัน** ก่อน promote — ไม่มี evidence ไม่ promote (สอด "ห้ามเดา"); **learned-rule = กฎ generalize ไม่ใช่ incident** (troubleshooting = incident ที่ *อ้าง* เป็น evidence ได้). พิจารณาครบทุกข้อ (promote หรือตัดทิ้งพร้อมเหตุผล) ห้ามปล่อยค้าง
+
+---
+
+## 4. ลำดับขั้นการทำงาน (process)
+
+1. **อ่านทำความเข้าใจ topic + รวบรวม learned-rule candidate:** อ่าน `docs/stages/<slug>/` ทุกไฟล์ — topic นี้ทำอะไร ทำอย่างไร เกิดความรู้ใหม่อะไรบ้าง (เช็คก่อนว่า VERIFY ผ่าน Gate แล้ว — มี `verify.md` สรุปผลผ่าน; ถ้ารัน node ได้ → รัน `node .warnyin/workflow/scripts/validate-topic.mjs <slug>` — มี ✖ ควรแก้ก่อน promote (script เช็คโครง; ความถูกของเนื้อหายังเป็นหน้าที่ผู้ ship)) — พร้อมกันนั้น **รวบรวม learned-rule candidate** เป็นตาราง (ทุกตัว = `rule + evidence + scope + promote?`):
+   - **planned:** จาก `tasks/*/rule.md` §2 "เสนอเพิ่ม rule ใหม่ (รอ SHIP)"
+   - **emergent:** สแกนบทเรียนที่โผล่ตอนลงมือ — `build.md` (pattern แก้ซ้ำ/integration), `verify.md` (รายการแก้+จำนวนรอบ), `troubleshooting.md` (ปัญหายาก→"กันซ้ำ" = candidate ชัดสุด), diff/commit
+   - **entry แต่ละตัว:** `rule` = ข้อความ **generalize** (ถ้าเป็น incident "X พังเพราะ Y" ยกเป็นกฎ "ก่อนแก้ Z เช็ค Y เสมอ") · `evidence` = **บังคับ** concrete pointer 1 บรรทัด + ลิงก์ artifact (`build.md`/`verify.md`/`troubleshooting.md`/diff/commit) — **ไม่มี evidence = ไม่ promote** · `scope` = `component:<c>`→`docs/techstack/<c>/rule.md` หรือ `project`→`docs/rule.md`
+2. **จำแนก feature:** สิ่งที่ทำเป็น **feature ใหม่** หรือ **ปรับปรุง feature เดิม** (เทียบกับ `docs/features/` ที่มีอยู่)
+3. **สรุป promotion plan + ขออนุมัติ (ครั้งเดียว):** feature ใหม่/ปรับปรุง, รายการไฟล์กลางที่จะอัปเดต + สาระ, ชื่อโฟลเดอร์ archive — **fold ตาราง learned-rule (rule + evidence + scope) เข้า approval เดียวกันนี้ ให้ user ยืนยัน per-rule** (✅ promote / ✂️ ตัด + เหตุผล) → รอ user ไฟเขียว
+4. **★ Archive:** ย้ายทั้งโฟลเดอร์ → `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` (ใช้ `git mv` ถ้าเป็น git repo)
+5. **อัปเดตเอกสารกลาง** (อ่านเนื้อหาจาก path ใน achieved):
+   1. **`docs/features/<feature-name>/`** — feature ใหม่ → สร้างโฟลเดอร์ใหม่ (`feature.md` + `business.md`); ปรับปรุง feature เดิม → อัปเดตโฟลเดอร์เดิม โดยใช้เนื้อหาจาก `business.md` / `proposal.md` / `design.md` ของ topic — **และ merge `spec.md`** ตาม Spec delta ใน `design.md` §9: **ADDED** → ต่อท้าย `spec.md` · **MODIFIED** → แทนที่ requirement ชื่อตรงกัน (rename → หาด้วย `[เดิมชื่อ:]`) · **REMOVED** → ลบ requirement; **read-modify-verify — key ไม่เจอ → STOP:** MODIFIED/REMOVED ที่หา key ไม่เจอใน `spec.md` ของ feature ที่ `(→ feature:)` ระบุ → **หยุด ถาม user ห้าม merge เงียบ** (ห้ามตีความเป็น ADDED เอง); **feature ใหม่** → สร้าง `spec.md` จาก ADDED ทั้งก้อน (template `[feature-name]/spec.md`); **feature เดิมยังไม่มี `spec.md`** → สร้างใหม่จาก delta + พฤติกรรมจริง
+   2. **`docs/techstack/<component>/`** — `rule.md` / `standard.md` (learned-rule ที่ยืนยันแล้ว scope `component:<c>` + note "รอ SHIP" ใน tasks), `structure.md` (โครงสร้างที่เปลี่ยน), `test.md` (merge แผนเทสจาก `test.md` ของ topic); **`openapi.yaml` (ถ้า topic มี)** — promote `docs/stages/<slug>/openapi.yaml` → `docs/techstack/<component>/openapi.yaml` (living API contract): มีอยู่แล้ว → **merge ตาม delta** (path/schema ที่ topic แตะ) ไม่ทับทั้งไฟล์; ยังไม่มี → สร้างใหม่ — ทำตาม `.warnyin/workflow/api-doc.md` §4
+   3. **`docs/rule.md`** — global rule ใหม่/ที่เปลี่ยน (learned-rule ที่ยืนยันแล้ว scope `project` — กฎระดับโปรเจกต์ ไม่ผูกกับ component เดียว)
+   > promote learned-rule **เฉพาะตัวที่ user ยืนยัน (step 3)** ตาม scope: `component:<c>` → `docs/techstack/<c>/rule.md` · `project` → `docs/rule.md`
+   4. **`docs/troubleshooting.md`** — merge entry จาก `troubleshooting.md` ของ topic (ปัญหา/อาการ/root cause/วิธีแก้/ป้องกันซ้ำ)
+   5. **`docs/infra.md` + `docs/project.md`** — เฉพาะถ้ามีข้อมูลที่เกี่ยวข้อง (env/service ใหม่, scope/เป้าหมายโปรเจกต์ที่ขยับ)
+   6. **`docs/codemap/` ทั้งหมด** — อัปเดต code map ให้ตรงกับโค้ดจริงปัจจุบัน ทำตาม playbook `.warnyin/workflow/codemap.md` (Claude Code: `/warnyin:update-codemaps`)
+6. **เขียนสรุปส่งมอบ:** `achieved/<YYYY-MM-DD>-<slug>/ship.md` — feature ใหม่/ปรับปรุง, เอกสารกลางที่อัปเดต (ไฟล์ → สาระ), note ที่ตัดทิ้งพร้อมเหตุผล
+7. **ปิดงาน:** รายงาน user ว่าส่งมอบครบ — topic ปิดสมบูรณ์
+
+---
+
+## 5. Output
+
+| ที่ | เนื้อหา |
+|---|---|
+| `docs/features/<feature-name>/` | feature.md + business.md + spec.md (สร้างใหม่หรืออัปเดต — spec.md merge ตาม Spec delta) |
+| `docs/techstack/<component>/{rule,standard,structure,test}.md` | rule/standard ใหม่, โครงสร้าง, วิธีเทสที่ promote ขึ้น |
+| `docs/techstack/<component>/openapi.yaml` | living API contract — เฉพาะ topic ที่แตะ REST API (merge ตาม delta) |
+| `docs/rule.md` | global rule ที่เพิ่ม/เปลี่ยน |
+| `docs/troubleshooting.md` | KB ปัญหา-วิธีแก้ที่ merge เข้า |
+| `docs/infra.md`, `docs/project.md` | อัปเดตเฉพาะถ้ามีข้อมูลเกี่ยวข้อง |
+| `docs/codemap/` | code map ตรงกับโค้ดจริงปัจจุบัน |
+| `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` | ทั้ง topic ที่ archive แล้ว + `ship.md` (สรุปการส่งมอบ) |
+
+---
+
+## 6. Gate → topic ปิดสมบูรณ์เมื่อ
+
+- [ ] topic ถูกย้ายไป `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` แล้ว (ไม่เหลือใน `docs/stages/`)
+- [ ] `docs/features/` สะท้อน feature ใหม่/ที่ปรับปรุงแล้ว
+- [ ] **Spec delta merge แล้ว** — `spec.md` ของ feature ที่แตะถูก merge ตาม delta; ทุก MODIFIED/REMOVED match requirement จริง (read-modify-verify — key ไม่เจอ → STOP ถาม user แล้ว ไม่ merge เงียบ)
+- [ ] learned-rules (planned + emergent) พิจารณาครบทุกตัว — note "รอ SHIP" ใน `tasks/*/rule.md` + `standard.md` + บทเรียน emergent จาก build/verify/troubleshooting; ทุก promote มี **evidence + user ยืนยัน**, ตัดทิ้งมีเหตุผล
+- [ ] `docs/troubleshooting.md` รวม entry จาก topic แล้ว
+- [ ] `docs/techstack/`, `docs/rule.md`, `docs/infra.md`, `docs/project.md` อัปเดตตามที่เกี่ยวข้อง
+- [ ] **API contract (ถ้า topic มี `openapi.yaml`)** — promote/merge เข้า `docs/techstack/<component>/openapi.yaml` ตาม delta แล้ว (`.warnyin/workflow/api-doc.md`)
+- [ ] `docs/codemap/` ตรงกับโค้ดจริงปัจจุบัน
+- [ ] `ship.md` สรุปการส่งมอบเขียนครบใน achieved
+- [ ] user รับทราบผลการส่งมอบ
+
+ยังไม่ครบ → อยู่ SHIP ต่อ topic ยังไม่ปิด

package/src/.warnyin/workflow/stages/verify.md

@@ -1,77 +1,80 @@
-# Stage: VERIFY
-
-> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
-> เป้าหมาย: เป็น **strategy tester** — ยืนยันว่า change ที่ build แล้ว "ทำงานถูกตามจุดประสงค์ของ topic" จริง (functional + UX/UI ถ้าเป็น FE) แก้จนผ่าน
-> **Context profile:** สวมโหมด `review` (`.warnyin/workflow/contexts/review.md`) — session-level posture ของ stage นี้
-
----
-
-## 1. VERIFY คืออะไร / ใช้เมื่อไหร่
-
-ใช้หลัง BUILD ผ่าน Gate (full build/test เขียว) — VERIFY ทดสอบ **เชิงพฤติกรรม/จุดประสงค์** ในสภาพแวดล้อมจริง (local env)
-ไม่ใช่แค่ unit test ผ่าน แต่ "ของจริงทำงานตามที่ topic ตั้งใจไหม"
-
----
-
-## 2. ก่อนเทส — อ่านให้เข้าใจก่อนเสมอ
-
-1. **spec + tasks ทั้งหมด** — `docs/stages/<slug>/tasks/*/spec.md` + `task.md`, `design.md`, `proposal.md`
-   → เข้าใจ **จุดประสงค์ของ topic** และสิ่งที่ต้องยืนยัน (อย่าเทสผ่านๆ โดยไม่เข้าใจ)
-2. **`docs/features/<name>/spec.md` = regression baseline** — อ่าน behavior spec ของ feature ที่ topic แตะ (ดูจาก Spec delta ใน `design.md`); topic แตะหลาย feature → baseline = union ของ spec ทุก feature ที่ delta อ้างถึง; feature ยังไม่มี spec → ข้ามได้ (วิธีเดิม)
-3. **`docs/techstack/<component>/test.md`** — guideline ว่าเทสยังไง (เช่น frontend: e2e smoke ผ่าน **playwright-cli**)
-   → ถ้า **ไม่มี** guideline → แนะนำว่าควรเทสแบบไหน/วิธีใดได้บ้าง แล้วเขียนแผนลง `test.md`
-4. **`docs/infra.md`** — local env / service ที่ต้องรันเพื่อเทส
-5. **`docs/troubleshooting.md`** — เผื่อปัญหาที่จะเจอเคยถูกแก้แล้ว
-6. **runtime security** (`.warnyin/workflow/roles/security.md` → "Runtime / operational security") — ตอนรันเทส local env ที่มี secret จริง ทบทวน secret isolation / no-egress / identity separation ก่อนปล่อย agent แตะของจริง
-
----
-
-## 3. หลักการทำงาน (operating principles)
-
-1. **เข้าใจจุดประสงค์ก่อนเทส** — เทสตามเจตนาของ topic ไม่ใช่แค่ให้เขียว **และพฤติกรรมเดิมจาก feature spec** — scenario เดิมใน `docs/features/<name>/spec.md` = regression case (ต้องไม่พัง ยกเว้นที่ MODIFIED/REMOVED ระบุ), scenario ใน Spec delta = test case ใหม่
-2. **เทสในสภาพแวดล้อมจริง (local env)** — รัน service ที่เกี่ยวข้องใน local แล้วเทสตามแผน
-3. **ใช้ guideline จาก `test.md`** ของ techstack; ถ้าไม่มีให้เสนอวิธีเทสที่เหมาะแล้วเขียนแผนเอง
-4. **Frontend → verify UX/UI ด้วย** (ไม่ใช่แค่ functional — ดู layout, state, flow, ความถูกต้องของหน้าจอ)
-5. **ข้อไหน verify ไม่ผ่าน → แก้จนผ่าน (loop)** และ **นับจำนวนการแก้ไข/จำนวนรอบ**
-6. **ปัญหายาก/ซ้ำในขั้นนี้ → บันทึก `docs/stages/<slug>/troubleshooting.md`** (เหมือน BUILD); เจอปัญหา → อ่าน `docs/troubleshooting.md` ก่อน
-7. **นาน/หลายรอบเกินไป → พิจารณาถาม user ทีละข้อ + เสนอคำตอบที่แนะนำ** (อย่าวนแก้เงียบๆ ไม่จบ)
-8. **ห้ามแตะไฟล์กลางใน `docs/`** — แผนเทสเขียนระดับ topic ที่ `test.md` ก่อน รอ SHIP merge เข้า `docs/techstack/<component>/test.md`
-9. **สวม role QA** — ทำตาม role card `.warnyin/workflow/roles/qa.md` (lens: คิดแบบผู้ใช้จริง + คนหาเรื่อง, edge case, regression; checklist ครบทุกข้อ)
-10. **★ investigate-before-edit** (enforce ของ "ห้ามเดา") — ก่อนแก้ไฟล์ที่มีอยู่ ต้องเข้าใจก่อน — **ใครใช้/อ่านไฟล์นี้, schema/contract/สัญญาของมัน, เจตนาเดิม**; แก้โดยไม่เข้าใจ = เดา (กรณีไม่ชัด → ถาม user / อ่านโค้ดที่อ้างถึง ก่อนแก้)
-11. **★ config-protection** (enforce ของ "ห้ามเดา") — ตอน fix loop (ข้อ 5 "แก้จนผ่าน") ห้ามแก้ config (linter/formatter/test threshold) หรือ disable rule **"เพื่อให้ build/test ผ่าน"** แทนการแก้ root cause จริง — "แก้จนผ่าน" ต้องเป็นการแก้ที่ต้นเหตุ ไม่ใช่ลด bar; ถ้า config ผิดจริง แก้ได้แต่ต้องมี **เหตุผลชัด + note** (ไม่ใช่เพื่อเลี่ยง finding)
-
----
-
-## 4. ลำดับขั้นการทำงาน (process)
-
-0. **★ เช็ค context window ก่อนเริ่ม:** ประเมินว่า context ของ session ปัจจุบันถูกใช้ไปมากน้อยแค่ไหน — ถ้าใช้ไปเยอะหรือ **เกินครึ่ง** → **เสนอ user ให้ `/compact` หรือ `/clear` ก่อนเสมอ** แล้วค่อยเริ่ม VERIFY ใน context ที่โล่ง (สถานะงานอยู่ในไฟล์ `docs/stages/<slug>/` ครบ ไม่หายไปกับ context) — VERIFY เป็นลูปเทส-แก้ที่อาจยาว ต้องมี context เหลือมากพอ; เครื่องอื่นที่ไม่มีคำสั่งนี้ → แนะนำเริ่ม session ใหม่
-1. **เข้าใจจุดประสงค์ + อ่าน baseline:** อ่าน spec/tasks/design + `docs/features/<name>/spec.md` ของ feature ที่ topic แตะ (union ถ้าหลาย feature) → สรุปสิ่งที่ต้อง verify (functional + UX/UI)
-2. **วางแผนเทส → เขียน `test.md`:** ตาม guideline `docs/techstack/<component>/test.md`; ไม่มีก็เสนอวิธี (e2e smoke / integration / manual ฯลฯ) แล้วเขียนแผน — **ครอบทั้ง regression (scenario เดิมใน baseline) + test case ใหม่ (scenario ใน Spec delta)**
-3. **เตรียม local env:** รัน service ที่เกี่ยวข้องตาม `infra.md`
-4. **รันเทสตามแผน:** functional ตาม test-flow ใน spec; FE → e2e smoke (playwright-cli) + ตรวจ UX/UI
-5. **ไม่ผ่าน → แก้ → rerun:** วนจนผ่าน **นับจำนวนรอบ/จำนวนแก้**; ปัญหายาก→`troubleshooting.md`; ถ้านานเกิน→ถาม user (ทีละข้อ + recommended)
-6. **เขียนสรุป `verify.md`:** ผลเทส + รายการแก้ไข + **จำนวนการแก้ไข** + ผล UX/UI
-7. **ปิดงาน:** เสนอเข้า SHIP ด้วย `/warnyin:ship`
-
----
-
-## 5. Output (สร้างที่ `docs/stages/<slug>/`)
-
-| ไฟล์ | เนื้อหา | ปลายทางตอน SHIP |
-|---|---|---|
-| `test.md` | แผน/วิธีเทสของ topic (cases, env, e2e smoke, UXUI checklist) | merge เข้า `docs/techstack/<component>/test.md` |
-| `verify.md` | สรุปผล verify + รายการแก้ไข + จำนวนรอบที่แก้ | (เก็บใน archive) |
-| `troubleshooting.md` (อัปเดต) | ปัญหายาก/ซ้ำที่เจอตอนเทส | merge เข้า `docs/troubleshooting.md` |
-
----
-
-## 6. Gate → เข้า SHIP ได้เมื่อ
-
-- [ ] เทสตาม **จุดประสงค์ของ topic** ครบ (functional ตาม test-flow ใน spec)
-- [ ] **regression ตาม baseline** — scenario เดิมใน `docs/features/<name>/spec.md` ของ feature ที่แตะ ยังผ่าน (ยกเว้นที่ MODIFIED/REMOVED) + scenario ใน Spec delta ผ่าน
-- [ ] Frontend: **UX/UI verify ผ่าน**
-- [ ] ทุกข้อที่ไม่ผ่านถูกแก้จน **verify ผ่านหมด**
-- [ ] `test.md` (แผน) + `verify.md` (สรุป + จำนวนการแก้ไข) เขียนครบ
-- [ ] ปัญหายาก/ซ้ำถูกบันทึก `troubleshooting.md`
-
-ยังไม่ครบ → อยู่ VERIFY ต่อ ห้ามข้ามไป SHIP
+# Stage: VERIFY
+
+> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
+> เป้าหมาย: เป็น **strategy tester** — ยืนยันว่า change ที่ build แล้ว "ทำงานถูกตามจุดประสงค์ของ topic" จริง (functional + UX/UI ถ้าเป็น FE) แก้จนผ่าน
+> **Context profile:** สวมโหมด `review` (`.warnyin/workflow/contexts/review.md`) — session-level posture ของ stage นี้
+
+---
+
+## 1. VERIFY คืออะไร / ใช้เมื่อไหร่
+
+ใช้หลัง BUILD ผ่าน Gate (full build/test เขียว) — VERIFY ทดสอบ **เชิงพฤติกรรม/จุดประสงค์** ในสภาพแวดล้อมจริง (local env)
+ไม่ใช่แค่ unit test ผ่าน แต่ "ของจริงทำงานตามที่ topic ตั้งใจไหม"
+
+---
+
+## 2. ก่อนเทส — อ่านให้เข้าใจก่อนเสมอ
+
+1. **spec + tasks ทั้งหมด** — `docs/stages/<slug>/tasks/*/spec.md` + `task.md`, `design.md`, `proposal.md`
+   → เข้าใจ **จุดประสงค์ของ topic** และสิ่งที่ต้องยืนยัน (อย่าเทสผ่านๆ โดยไม่เข้าใจ)
+2. **`docs/features/<name>/spec.md` = regression baseline** — อ่าน behavior spec ของ feature ที่ topic แตะ (ดูจาก Spec delta ใน `design.md`); topic แตะหลาย feature → baseline = union ของ spec ทุก feature ที่ delta อ้างถึง; feature ยังไม่มี spec → ข้ามได้ (วิธีเดิม)
+   - **`docs/stages/<slug>/openapi.yaml` (ถ้ามี)** = API contract ที่ต้องยืนยัน — topic ที่แตะ REST API ต้อง verify ว่าโค้ดจริง **ตรง contract** (ดูข้อ 4)
+3. **`docs/techstack/<component>/test.md`** — guideline ว่าเทสยังไง (เช่น frontend: e2e smoke ผ่าน **playwright-cli**)
+   → ถ้า **ไม่มี** guideline → แนะนำว่าควรเทสแบบไหน/วิธีใดได้บ้าง แล้วเขียนแผนลง `test.md`
+4. **`docs/infra.md`** — local env / service ที่ต้องรันเพื่อเทส
+5. **`docs/troubleshooting.md`** — เผื่อปัญหาที่จะเจอเคยถูกแก้แล้ว
+6. **runtime security** (`.warnyin/workflow/roles/security.md` → "Runtime / operational security") — ตอนรันเทส local env ที่มี secret จริง ทบทวน secret isolation / no-egress / identity separation ก่อนปล่อย agent แตะของจริง
+
+---
+
+## 3. หลักการทำงาน (operating principles)
+
+1. **เข้าใจจุดประสงค์ก่อนเทส** — เทสตามเจตนาของ topic ไม่ใช่แค่ให้เขียว **และพฤติกรรมเดิมจาก feature spec** — scenario เดิมใน `docs/features/<name>/spec.md` = regression case (ต้องไม่พัง ยกเว้นที่ MODIFIED/REMOVED ระบุ), scenario ใน Spec delta = test case ใหม่
+2. **เทสในสภาพแวดล้อมจริง (local env)** — รัน service ที่เกี่ยวข้องใน local แล้วเทสตามแผน
+3. **ใช้ guideline จาก `test.md`** ของ techstack; ถ้าไม่มีให้เสนอวิธีเทสที่เหมาะแล้วเขียนแผนเอง
+4. **Frontend → verify UX/UI ด้วย** (ไม่ใช่แค่ functional — ดู layout, state, flow, ความถูกต้องของหน้าจอ)
+5. **ข้อไหน verify ไม่ผ่าน → แก้จนผ่าน (loop)** และ **นับจำนวนการแก้ไข/จำนวนรอบ**
+6. **ปัญหายาก/ซ้ำในขั้นนี้ → บันทึก `docs/stages/<slug>/troubleshooting.md`** (เหมือน BUILD); เจอปัญหา → อ่าน `docs/troubleshooting.md` ก่อน
+7. **นาน/หลายรอบเกินไป → พิจารณาถาม user ทีละข้อ + เสนอคำตอบที่แนะนำ** (อย่าวนแก้เงียบๆ ไม่จบ)
+8. **ห้ามแตะไฟล์กลางใน `docs/`** — แผนเทสเขียนระดับ topic ที่ `test.md` ก่อน รอ SHIP merge เข้า `docs/techstack/<component>/test.md`
+9. **สวม role QA** — ทำตาม role card `.warnyin/workflow/roles/qa.md` (lens: คิดแบบผู้ใช้จริง + คนหาเรื่อง, edge case, regression; checklist ครบทุกข้อ)
+10. **★ investigate-before-edit** (enforce ของ "ห้ามเดา") — ก่อนแก้ไฟล์ที่มีอยู่ ต้องเข้าใจก่อน — **ใครใช้/อ่านไฟล์นี้, schema/contract/สัญญาของมัน, เจตนาเดิม**; แก้โดยไม่เข้าใจ = เดา (กรณีไม่ชัด → ถาม user / อ่านโค้ดที่อ้างถึง ก่อนแก้)
+11. **★ config-protection** (enforce ของ "ห้ามเดา") — ตอน fix loop (ข้อ 5 "แก้จนผ่าน") ห้ามแก้ config (linter/formatter/test threshold) หรือ disable rule **"เพื่อให้ build/test ผ่าน"** แทนการแก้ root cause จริง — "แก้จนผ่าน" ต้องเป็นการแก้ที่ต้นเหตุ ไม่ใช่ลด bar; ถ้า config ผิดจริง แก้ได้แต่ต้องมี **เหตุผลชัด + note** (ไม่ใช่เพื่อเลี่ยง finding)
+
+---
+
+## 4. ลำดับขั้นการทำงาน (process)
+
+0. **★ เช็ค context window ก่อนเริ่ม:** ประเมินว่า context ของ session ปัจจุบันถูกใช้ไปมากน้อยแค่ไหน — ถ้าใช้ไปเยอะหรือ **เกินครึ่ง** → **เสนอ user ให้ `/compact` หรือ `/clear` ก่อนเสมอ** แล้วค่อยเริ่ม VERIFY ใน context ที่โล่ง (สถานะงานอยู่ในไฟล์ `docs/stages/<slug>/` ครบ ไม่หายไปกับ context) — VERIFY เป็นลูปเทส-แก้ที่อาจยาว ต้องมี context เหลือมากพอ; เครื่องอื่นที่ไม่มีคำสั่งนี้ → แนะนำเริ่ม session ใหม่
+1. **เข้าใจจุดประสงค์ + อ่าน baseline:** อ่าน spec/tasks/design + `docs/features/<name>/spec.md` ของ feature ที่ topic แตะ (union ถ้าหลาย feature) → สรุปสิ่งที่ต้อง verify (functional + UX/UI)
+2. **วางแผนเทส → เขียน `test.md`:** ตาม guideline `docs/techstack/<component>/test.md`; ไม่มีก็เสนอวิธี (e2e smoke / integration / manual ฯลฯ) แล้วเขียนแผน — **ครอบทั้ง regression (scenario เดิมใน baseline) + test case ใหม่ (scenario ใน Spec delta)**
+3. **เตรียม local env:** รัน service ที่เกี่ยวข้องตาม `infra.md`
+4. **รันเทสตามแผน:** functional ตาม test-flow ใน spec; FE → e2e smoke (playwright-cli) + ตรวจ UX/UI
+   - **★ contract validation (ถ้ามี `openapi.yaml`):** ยืนยัน implementation จริง = contract ตาม `.warnyin/workflow/api-doc.md` §4 (code-first regen → diff, หรือยิง request จริง → ตรวจ response/status/error ตรง schema); mismatch = ไม่ผ่าน → เข้า fix loop ข้อ 5
+5. **ไม่ผ่าน → แก้ → rerun:** วนจนผ่าน **นับจำนวนรอบ/จำนวนแก้**; ปัญหายาก→`troubleshooting.md`; ถ้านานเกิน→ถาม user (ทีละข้อ + recommended)
+6. **เขียนสรุป `verify.md`:** ผลเทส + รายการแก้ไข + **จำนวนการแก้ไข** + ผล UX/UI
+7. **ปิดงาน:** เสนอเข้า SHIP ด้วย `/warnyin:ship`
+
+---
+
+## 5. Output (สร้างที่ `docs/stages/<slug>/`)
+
+| ไฟล์ | เนื้อหา | ปลายทางตอน SHIP |
+|---|---|---|
+| `test.md` | แผน/วิธีเทสของ topic (cases, env, e2e smoke, UXUI checklist) | merge เข้า `docs/techstack/<component>/test.md` |
+| `verify.md` | สรุปผล verify + รายการแก้ไข + จำนวนรอบที่แก้ | (เก็บใน archive) |
+| `troubleshooting.md` (อัปเดต) | ปัญหายาก/ซ้ำที่เจอตอนเทส | merge เข้า `docs/troubleshooting.md` |
+
+---
+
+## 6. Gate → เข้า SHIP ได้เมื่อ
+
+- [ ] เทสตาม **จุดประสงค์ของ topic** ครบ (functional ตาม test-flow ใน spec)
+- [ ] **regression ตาม baseline** — scenario เดิมใน `docs/features/<name>/spec.md` ของ feature ที่แตะ ยังผ่าน (ยกเว้นที่ MODIFIED/REMOVED) + scenario ใน Spec delta ผ่าน
+- [ ] Frontend: **UX/UI verify ผ่าน**
+- [ ] **API contract (ถ้ามี `openapi.yaml`)** — implementation จริงตรง contract (path/schema/status/error/auth); mismatch ถูกแก้จนตรง (ตาม `.warnyin/workflow/api-doc.md`)
+- [ ] ทุกข้อที่ไม่ผ่านถูกแก้จน **verify ผ่านหมด**
+- [ ] `test.md` (แผน) + `verify.md` (สรุป + จำนวนการแก้ไข) เขียนครบ
+- [ ] ปัญหายาก/ซ้ำถูกบันทึก `troubleshooting.md`
+
+ยังไม่ครบ → อยู่ VERIFY ต่อ ห้ามข้ามไป SHIP