@warnyin/agents 0.1.0

package/warnyin-stages/[topic]/discovery.md

@@ -0,0 +1,69 @@
+# Discovery — <ชื่อหัวข้องาน>
+
+> Output ของ Discovery stage · playbook: `workflow/stages/discovery.md`
+
+| | |
+|---|---|
+| **Slug** | `<kebab-case>` |
+| **สถานะ** | `กำลังทำ` / `ผ่าน gate แล้ว` |
+| **วันที่** | `YYYY-MM-DD` |
+| **ผู้ร่วมตัดสินใจ** | `<ชื่อ>` |
+| **เริ่มจาก** | อ้างอิง `docs/project.md` ส่วนไหน |
+
+---
+
+## 1. สรุปความเข้าใจร่วมกัน (one-liner)
+> เราจะทำ **อะไร** ให้ **ใคร** เพื่อแก้ปัญหา **อะไร** — สรุปได้ใน 1-3 บรรทัด
+
+## 2. Problem & Why now
+- ปัญหา / โอกาส:
+- ทำไมต้องทำตอนนี้:
+- ผูกกับเป้าหมายโปรเจกต์ (จาก `docs/project.md`) อย่างไร:
+
+## 3. Scope (กว้าง → แคบ)
+**In scope (จะทำ)**
+-
+
+**Out of scope (จะไม่ทำในรอบนี้)**
+-
+
+## 4. Decision Log (เดินทีละกิ่งของ decision tree)
+> หนึ่งแถว = หนึ่งการตัดสินใจ บันทึกทันทีที่ตกลงได้
+
+| # | คำถาม / ประเด็น | ทางเลือก | คำตอบที่แนะนำ | ที่เลือกจริง | เหตุผล |
+|---|---|---|---|---|---|
+| 1 | | | | | |
+| 2 | | | | | |
+
+## 5. สมมติฐาน & ข้อจำกัด
+- สมมติฐาน:
+- ข้อจำกัด (เทคนิค/เวลา/ทรัพยากร/ระบบเดิม):
+
+## 6. เกณฑ์ความสำเร็จ (วัดผลได้)
+-
+
+## 7. Feature ideas / ทางเลือกของวิธีแก้
+> ไอเดียคร่าวๆ ที่จะส่งต่อให้ DESIGN พิจารณา (ยังไม่ลงรายละเอียดออกแบบ)
+-
+
+## 8. Open questions (ที่ยังค้าง)
+> ต้องปิดทุกข้อที่ block การออกแบบ ก่อนผ่าน gate
+- [ ]
+
+## 9. ความเสี่ยงหลัก
+-
+
+## 10. ลิงก์ที่เกี่ยวข้อง
+- Research: `./research.md`
+- เอกสารโปรเจกต์: `docs/project.md`, `docs/...`
+- โค้ด/ไฟล์ที่ตรวจสอบ:
+
+---
+
+## ✅ Gate → DESIGN (ดู `workflow/stages/discovery.md` ข้อ 6)
+- [ ] Problem / why-now ชัด ผูกกับ project.md
+- [ ] Scope in/out ชัด
+- [ ] Decision log ปิดทุกประเด็นสำคัญ ไม่มี open question ที่ block
+- [ ] success criteria วัดผลได้
+- [ ] สมมติฐาน/ข้อจำกัด/ความเสี่ยง บันทึกครบ
+- [ ] user ยืนยัน "เข้าใจตรงกันแล้ว"

package/warnyin-stages/[topic]/proposal.md

@@ -0,0 +1,43 @@
+# Proposal — <ชื่อ change>
+
+> Output ของ DESIGN stage · playbook: `workflow/stages/design.md`
+> **what & why** ของ change นี้
+
+| | |
+|---|---|
+| **Slug** | `<kebab-case>` |
+| **ประเภท** | `feature` / `bugfix` / `refactor` / `docs` |
+| **ขนาด** | `เล็ก` / `กลาง` / `ใหญ่` |
+| **วันที่** | `YYYY-MM-DD` |
+| **มาจาก Discovery?** | `./discovery.md` หรือ `ไม่มี` |
+
+## 1. สรุป change (what)
+> เราจะเปลี่ยน/สร้าง/แก้อะไร — 1-3 บรรทัด
+
+## 2. ทำไม (why)
+- ปัญหา/โอกาส:
+- ผลถ้าไม่ทำ:
+
+## 3. ทางเลือกที่พิจารณา
+| ทางเลือก | ข้อดี | ข้อเสีย | เลือก? |
+|---|---|---|---|
+| A (แนะนำ) | | | ✅ |
+| B | | | |
+
+- เหตุผลที่เลือก:
+
+## 4. Scope
+**In scope**
+-
+
+**Out of scope**
+-
+
+## 5. ผลกระทบ & ความเสี่ยง
+- ระบบ/ฟีเจอร์เดิมที่กระทบ:
+- ความเสี่ยง + วิธีลดความเสี่ยง:
+
+## 6. ลิงก์
+- Design (how): `./design.md`
+- Tasks: `./tasks/`
+- Business: `./business.md` (ถ้ามี)

package/warnyin-stages/[topic]/research.md

@@ -0,0 +1,49 @@
+# Research — <ชื่อหัวข้องาน>
+
+> Output ของ Discovery stage · playbook: `workflow/stages/discovery.md`
+> ที่เก็บ "ข้อมูลที่ค้นมา + หลักฐาน" สนับสนุนการตัดสินใจใน `discovery.md`
+
+| | |
+|---|---|
+| **Slug** | `<kebab-case>` |
+| **วันที่** | `YYYY-MM-DD` |
+
+---
+
+## 1. คำถามวิจัย (research questions)
+> สิ่งที่ "ยังไม่รู้" และต้องค้นให้ได้คำตอบก่อนออกแบบ
+- [ ] RQ1:
+- [ ] RQ2:
+
+## 2. วิธี & แหล่งข้อมูล
+- [ ] อ่านโค้ด/เอกสารในโปรเจกต์ (code inspection)
+- [ ] ค้นเว็บ / เอกสารภายนอก
+- [ ] prior art / วิธีที่ทีม/คนอื่นทำ
+
+## 3. Findings (ผลการค้นต่อคำถาม)
+> ทุก finding ต้องมี evidence/link อ้างอิงได้
+
+### RQ1: <คำถาม>
+- พบว่า:
+- หลักฐาน:
+- สรุป/นัยต่อการออกแบบ:
+
+### RQ2: <คำถาม>
+-
+
+## 4. Code inspection (สิ่งที่ตอบได้จากโค้ดเอง โดยไม่ต้องถาม user)
+| ไฟล์ / ส่วนของโค้ด | สิ่งที่พบ | นัยต่องาน |
+|---|---|---|
+| | | |
+
+## 5. ทางเลือก & เปรียบเทียบ (ถ้ามี)
+| ทางเลือก | ข้อดี | ข้อเสีย | เหมาะกับเคสนี้? |
+|---|---|---|---|
+| | | | |
+
+## 6. ความเสี่ยง / unknown ที่ยังเหลือ
+-
+
+## 7. ข้อสรุป → ส่งต่อ
+- คำแนะนำจาก research:
+- การตัดสินใจที่ป้อนกลับเข้า `discovery.md` (Decision Log):

package/warnyin-stages/[topic]/ship.md

@@ -0,0 +1,29 @@
+# Ship — <ชื่อ topic>
+
+> Output ของ SHIP stage · playbook: `workflow/stages/ship.md`
+> สรุปการส่งมอบ — เขียนหลังย้าย topic เข้า `warnyin-stages/achieved/<YYYY-MM-DD>-<slug>/` แล้ว
+
+## 1. สรุป topic
+- ทำอะไร: <!-- หนึ่งย่อหน้า: topic นี้ทำอะไร ทำอย่างไร -->
+- ประเภท: ☐ feature ใหม่ / ☐ ปรับปรุง feature เดิม → `docs/features/<feature-name>/`
+
+## 2. เอกสารกลางที่อัปเดต
+| ไฟล์ | สาระที่ promote |
+|---|---|
+| `docs/features/<feature-name>/` | |
+| `docs/techstack/<component>/rule.md` | |
+| `docs/techstack/<component>/standard.md` | |
+| `docs/techstack/<component>/structure.md` | |
+| `docs/techstack/<component>/test.md` | |
+| `docs/rule.md` | |
+| `docs/troubleshooting.md` | |
+| `docs/infra.md` / `docs/project.md` | <!-- ถ้าเกี่ยวข้อง --> |
+| `docs/codemap/` | |
+
+## 3. note "รอ SHIP" ที่ตัดทิ้ง (ไม่ promote)
+| note | เหตุผลที่ตัด |
+|---|---|
+| | |
+
+## 4. Archive
+- ย้ายจาก `warnyin-stages/<slug>/` → `warnyin-stages/achieved/<YYYY-MM-DD>-<slug>/` เมื่อ <YYYY-MM-DD>

package/warnyin-stages/[topic]/tasks/[task-name]/issue.md

@@ -0,0 +1,19 @@
+# Issue — <ชื่อ task>
+
+> Output ของ DESIGN dry-run · playbook: `workflow/stages/design.md` (ข้อ 4.9)
+> ผลสแกนหา defer/blocker ของ task นี้ก่อนเข้า BUILD — **สร้างเฉพาะเมื่อพบ issue**
+
+## 1. สรุป
+- ผลสแกน: blocker __ ข้อ · defer __ ข้อ
+- สถานะรวม: ☐ แก้ครบ ไม่มี blocker ค้าง / ☐ มี blocker ค้าง (ห้ามเข้า BUILD)
+
+## 2. รายการ issue
+| # | ประเภท | จุดที่พบ (ไฟล์/spec/โค้ด) | รายละเอียด | แนวทางแก้ / ข้อสรุป | สถานะ |
+|---|---|---|---|---|---|
+| 1 | blocker / defer | | | | open / resolved |
+
+> - **blocker** — ทำให้ implement ตาม spec ไม่ได้ (ขัดแย้งกับโค้ดจริง/task อื่น, ข้อมูลขาด, dependency ผิด) → ต้องแก้ DESIGN ก่อนเข้า BUILD
+> - **defer** — ตัดสินใจ/ทำทีหลังได้ ไม่ block การเริ่ม BUILD แต่ต้องบันทึกและให้ user รับทราบ
+
+## 3. ผลการแก้ไข
+<!-- แก้อะไรใน design.md / task ไหนบ้าง + ผล rerun dry-run; ข้อสรุปจากการสัมภาษณ์ user (ถ้ามี) -->

package/warnyin-stages/[topic]/tasks/[task-name]/rule.md

@@ -0,0 +1,13 @@
+# Rule — <ชื่อ task>
+
+> Output ของ DESIGN stage · playbook: `workflow/stages/design.md`
+> rule ที่ task นี้ต้อง **focus/follow** + rule ใหม่ที่อยากเสนอเพิ่ม
+
+## 1. Rule ที่ต้อง follow (จาก techstack)
+> ดึงจาก `docs/techstack/<component>/rule.md` และ `docs/rule.md` — เฉพาะข้อที่เกี่ยวกับ task นี้
+- [ ]
+- [ ]
+
+## 2. เสนอเพิ่ม rule ใหม่ (⏳ รอ SHIP ค่อยอัปเดต rule กลาง)
+> ห้ามแก้ `docs/techstack/.../rule.md` ตอนนี้ — แค่ note ไว้ก่อน ถึง SHIP ค่อยพิจารณาย้ายขึ้นไป
+- [ ] rule ที่เสนอ: _____ — เหตุผล: _____

package/warnyin-stages/[topic]/tasks/[task-name]/spec.md

@@ -0,0 +1,36 @@
+# Spec — <ชื่อ task>
+
+> Output ของ DESIGN stage · playbook: `workflow/stages/design.md`
+> spec เฉพาะของ task นี้ — **ใส่เฉพาะหัวข้อที่เกี่ยวข้องกับชนิดของ task**
+
+## 1. ชนิดของ task
+`API` / `UX-UI` / `data` / `logic` / `infra` / ...
+
+---
+
+## 2. API SPEC (ถ้าเป็น API — ตามมาตรฐาน)
+| | |
+|---|---|
+| Endpoint | `METHOD /path` |
+| Auth | |
+| Request | schema / body / params |
+| Response | schema + ตัวอย่าง |
+| Status / Error | 200 / 4xx / 5xx + error shape |
+
+## 3. UX/UI SPEC (ถ้าเป็นงาน UI)
+- Wireframe / Figma ref: `<ลิงก์ ถ้ามี>`
+- States: default / loading / empty / error / success
+- Responsive / accessibility:
+
+## 4. Data-flow
+> ข้อมูลไหลจากไหน → ผ่านอะไร → ไปไหน
+
+## 5. User-flow
+> ผู้ใช้เดินผ่านขั้นตอนไหนบ้าง
+
+## 6. Persona
+> task นี้ทำเพื่อใคร
+
+## 7. Test-flow
+> จะทดสอบ/ยืนยันความถูกต้องยังไง (เคสที่ต้องผ่าน, edge case)
+- [ ]

package/warnyin-stages/[topic]/tasks/[task-name]/standard.md

@@ -0,0 +1,21 @@
+# Standard — <ชื่อ task>
+
+> Output ของ DESIGN stage · playbook: `workflow/stages/design.md`
+> pattern การเขียนโค้ด / shared component ที่ task นี้ต้องยึด
+> **อิงจาก** `docs/techstack/<component>/standard.md` — เพิ่มเติมเฉพาะ task ได้
+
+## 1. Standard กลางที่ยึด (จาก techstack)
+> อ้างอิง `docs/techstack/<component>/standard.md` — ข้อไหนเกี่ยวกับ task นี้
+-
+
+## 2. Pattern การเขียนโค้ดของ task นี้
+- โครงสร้าง/naming:
+- error handling:
+- การจัดการ state/data:
+
+## 3. Shared component / utility ที่ต้องใช้ (อย่าเขียนซ้ำ)
+- component/hook/helper ที่มีอยู่แล้ว:
+
+## 4. เพิ่มเติมเฉพาะ task (ถ้ามี)
+> pattern ใหม่ที่ task นี้แนะนำ — ถ้าควรเป็นมาตรฐานกลาง ให้ note ใน `rule.md` (รอ SHIP อัปเดต standard กลาง)
+-

package/warnyin-stages/[topic]/tasks/[task-name]/task.md

@@ -0,0 +1,39 @@
+# Task — <ชื่อ task>
+
+> Output ของ DESIGN stage · playbook: `workflow/stages/design.md`
+> หน่วยที่ **โยนให้ sub-agent ทำใน BUILD ได้** — self-contained แต่เชื่อมกับ task อื่นผ่าน dependency
+
+| | |
+|---|---|
+| **Task** | `<kebab-case>` |
+| **Slice อ้างอิง** | `design.md` slice #__ |
+| **Component** | `admin-console` / `api-service` / ... |
+| **สถานะ** | `รอ build` / `กำลังทำ` / `เสร็จ` |
+
+## 1. เป้าหมายของ task (vertical slice)
+> task นี้ส่งมอบคุณค่า end-to-end อะไร
+
+## 2. Dependency (เชื่อมต่อกับ task อื่น)
+- ต้องทำหลัง: `tasks/<...>` (เพราะ ...)
+- ปลดล็อกให้: `tasks/<...>`
+- ส่ง output อะไรต่อให้ task ถัดไป:
+
+## 3. Sub-tasks (แตกย่อยถ้าซับซ้อน)
+> sub-task ต้องเชื่อมต่อกัน — ระบุลำดับ/สิ่งที่ส่งต่อกัน
+
+- [ ] 1. <sub-task> — _ผลลัพธ์:_
+- [ ] 2. <sub-task> — _ขึ้นกับ 1:_
+- [ ] 3. <sub-task>
+
+## 4. ขอบเขตไฟล์/โค้ดที่จะแตะ
+- ไฟล์/โมดูล:
+
+## 5. Acceptance criteria (เกณฑ์ว่า task เสร็จ)
+- [ ]
+- [ ] ผ่าน test ตาม `spec.md` (test-flow)
+- [ ] ทำตาม `rule.md` และ `standard.md`
+
+## 6. อ้างอิงในโฟลเดอร์ task นี้
+- Spec: `./spec.md`
+- Standard (pattern โค้ด): `./standard.md`
+- Rule ที่ต้อง follow: `./rule.md`

package/warnyin-stages/[topic]/test.md

@@ -0,0 +1,46 @@
+# Test Plan — <ชื่อ change>
+
+> Output ของ VERIFY stage · playbook: `workflow/stages/verify.md`
+> แผน/วิธีเทสของ topic นี้ — ตอน **SHIP** จะ merge เข้า `docs/techstack/<component>/test.md`
+> อิง guideline จาก `docs/techstack/<component>/test.md` (ถ้าไม่มี = เสนอวิธีใหม่ที่นี่)
+
+| | |
+|---|---|
+| **Slug** | `<kebab-case>` |
+| **Component** | `api-service` / `admin-console` |
+| **จุดประสงค์ที่ต้อง verify** | (สรุปจาก spec/tasks) |
+
+## 1. ขอบเขตการเทส (ตามจุดประสงค์ topic)
+- สิ่งที่ต้องยืนยันว่าทำงานถูก:
+
+## 2. ชนิดการเทส
+- [ ] Functional (ตาม test-flow ใน `tasks/*/spec.md`)
+- [ ] E2E smoke — เครื่องมือ: `playwright-cli` (ถ้าเป็น FE)
+- [ ] Integration / API
+- [ ] UX/UI verify (ถ้าเป็น FE)
+- [ ] อื่นๆ:
+
+## 3. Local env ที่ต้องรัน (จาก `docs/infra.md`)
+| Service | คำสั่งรัน | port / หมายเหตุ |
+|---|---|---|
+| | | |
+
+## 4. Test cases
+| # | สถานการณ์ (อิงจุดประสงค์) | ขั้นตอน | ผลที่คาดหวัง |
+|---|---|---|---|
+| 1 | | | |
+
+## 5. E2E smoke (FE)
+- flow ที่ smoke:
+- คำสั่ง playwright-cli:
+
+## 6. UX/UI checklist (FE)
+- [ ] layout ตรงตาม spec/wireframe
+- [ ] states: loading / empty / error / success
+- [ ] responsive
+- [ ] interaction / user-flow ลื่นไหล
+
+## 7. วิธีรันเทส (reproducible)
+```
+<คำสั่ง / ขั้นตอน>
+```

package/warnyin-stages/[topic]/troubleshooting.md

@@ -0,0 +1,34 @@
+# Troubleshooting — <ชื่อ change>
+
+> Log ปัญหา **ยาก/ซ้ำ** ที่เจอระหว่างทำงาน topic นี้ (ส่วนใหญ่ตอน BUILD) แล้วแก้สำเร็จ
+> ตอน **SHIP** จะยกรายการที่มีค่าขึ้นไปรวมที่ KB กลาง `docs/troubleshooting.md`
+> เจอปัญหาใหม่ → อ่าน `docs/troubleshooting.md` ก่อนเสมอ เผื่อเคยแก้แล้ว
+
+---
+
+## วิธีบันทึก
+บันทึกเฉพาะปัญหาที่ **ยากจะแก้** หรือ **เจอซ้ำ** (ไม่ใช่ทุก error เล็กน้อย) — หนึ่งปัญหา = หนึ่ง entry
+
+---
+
+### TS-1: <ชื่อปัญหาสั้นๆ>
+| | |
+|---|---|
+| **วันที่** | `YYYY-MM-DD` |
+| **Component / Task** | `api-service` / `tasks/<task>` |
+| **ความถี่** | เจอครั้งเดียว (ยากมาก) / เจอซ้ำ __ ครั้ง |
+| **ยกขึ้น KB กลางตอน SHIP?** | ✅ / ❌ |
+
+- **อาการ / error message:**
+  ```
+  <paste error>
+  ```
+- **บริบทที่ทำให้เกิด (trigger):**
+- **สาเหตุที่แท้จริง (root cause):**
+- **วิธีแก้ที่ได้ผล (solution):**
+- **วิธีสังเกต/ป้องกันไม่ให้เกิดซ้ำ:**
+
+---
+
+### TS-2: <...>
+> (คัดลอกบล็อกด้านบน)

package/warnyin-stages/[topic]/verify.md

@@ -0,0 +1,44 @@
+# Verify Report — <ชื่อ change>
+
+> Output ของ VERIFY stage · playbook: `workflow/stages/verify.md`
+> สรุปผลการ verify ตามจุดประสงค์ของ topic + การแก้ไขที่เกิดขึ้น
+
+| | |
+|---|---|
+| **Slug** | `<kebab-case>` |
+| **วันที่** | `YYYY-MM-DD` |
+| **ผลรวม** | ผ่าน / ไม่ผ่าน |
+| **จำนวนรอบการแก้ไข (fix iterations)** | __ รอบ |
+| **จำนวนจุดที่แก้** | __ จุด |
+
+## 1. จุดประสงค์ที่ verify (จาก spec/tasks)
+-
+
+## 2. ผลการเทส
+| # | Test case / flow | ชนิด | ผล | หมายเหตุ |
+|---|---|---|---|---|
+| 1 | | functional / e2e / uxui | ✅ / ❌→✅ (แก้แล้ว) | |
+
+## 3. UX/UI verify (ถ้าเป็น FE)
+- [ ] layout / states / responsive / user-flow — ผล:
+
+## 4. รายการแก้ไข (สรุปการแก้ระหว่าง verify)
+> นับรวมเป็น "จำนวนการแก้ไข" ด้านบน
+
+| รอบ | ปัญหาที่เจอ | วิธีแก้ | ไฟล์ที่แก้ |
+|---|---|---|---|
+| 1 | | | |
+
+## 5. ปัญหายาก/ซ้ำ → troubleshooting
+- บันทึกไว้ที่ `./troubleshooting.md` (SHIP ยกขึ้น `docs/troubleshooting.md`): มี/ไม่มี
+
+## 6. หมายเหตุถึง user (ถ้าถามระหว่างทาง)
+> กรณีวนแก้นาน/หลายรอบ แล้วถาม user — สรุปคำถาม/คำตอบ/การตัดสินใจ
+-
+
+## ✅ Gate → SHIP (ดู `workflow/stages/verify.md` ข้อ 6)
+- [ ] เทสตามจุดประสงค์ครบ (functional)
+- [ ] FE: UX/UI verify ผ่าน
+- [ ] ทุกข้อที่ไม่ผ่านถูกแก้จนผ่าน
+- [ ] test.md + verify.md เขียนครบ
+- [ ] ปัญหายากบันทึก troubleshooting.md แล้ว

package/workflow/README.md

@@ -0,0 +1,90 @@
+# Warnyin Standard Workflow
+
+มาตรฐานกลางของ "วิธีทำงาน" (ways of work) สำหรับทุกโปรเจกต์ — สร้างทีม ผลิตผลงานคุณภาพ และเร็ว
+โดยเดินผ่าน 5 stage:
+
+```
+Discovery (optional) ──▶ DESIGN ──▶ BUILD ──▶ VERIFY ──▶ SHIP
+```
+
+แต่ละ stage มี **playbook กลางหนึ่งชุด** เป็น single source of truth ที่ AI ทุกเจ้าอ่านเหมือนกัน
+
+---
+
+## หลักการออกแบบ: Tool-agnostic, single source of truth
+
+แก่นของ workflow (กฎ / ขั้นตอน / เกณฑ์ผ่าน) เขียน **ครั้งเดียว** เป็น markdown ใน `workflow/stages/`
+ส่วน AI แต่ละเครื่องมีแค่ **adapter บางๆ** ที่ "ชี้กลับ" มาที่ playbook กลางชุดเดียวกัน
+
+| AI tool | Adapter (จุดเชื่อม) | อ่าน playbook จาก |
+|---|---|---|
+| **Claude Code** | `.claude/commands/*.md` + `CLAUDE.md` | `workflow/stages/*.md` |
+| **Codex** | `AGENTS.md` | `workflow/stages/*.md` |
+| **Antigravity** | `AGENTS.md` | `workflow/stages/*.md` |
+| เครื่องอื่นๆ | ชี้มาที่ `workflow/stages/` ได้ทันที | `workflow/stages/*.md` |
+
+> แก้กฎที่ `workflow/stages/` ที่เดียว → ทุกเครื่องได้เหมือนกันทันที
+> เพิ่ม AI เจ้าใหม่ = เพิ่ม adapter บางๆ อีกหนึ่งไฟล์ ไม่ต้องแตะ logic
+
+---
+
+## โครงสร้าง repo
+
+```
+bin/cli.mjs            # npx installer — ติดตั้ง workflow ลงโปรเจกต์อื่น
+installer/templates/   # template CLAUDE.md สำหรับโปรเจกต์ปลายทาง
+
+workflow/
+  README.md            # ไฟล์นี้ — ภาพรวม + วิธีรองรับหลาย AI
+  init.md              # playbook: INIT — วิเคราะห์โปรเจกต์ + เติม docs/ ครั้งแรก
+  stages/
+    discovery.md       # playbook: Discovery (optional)  ✅
+    design.md          # playbook: DESIGN  ✅
+    build.md           # playbook: BUILD  ✅
+    verify.md          # playbook: VERIFY  ✅
+    ship.md            # playbook: SHIP  ✅
+  scripts/
+    build-wave.mjs     # Workflow script: fan-out sub-agent ต่อ task ใน wave (worktree)
+
+docs/                  # ความรู้ถาวรระดับโปรเจกต์ (อ้างอิงข้ามงาน)
+  project.md           # ★ จุดเริ่มของ Discovery — อ่านก่อนเสมอ
+  rule.md  infra.md
+  troubleshooting.md   # ★ KB ปัญหา-วิธีแก้ (อ่านก่อนเมื่อ build เจอ error; SHIP ป้อนเข้า)
+  codemap/  features/  techstack/
+
+warnyin-stages/        # พื้นที่ทำงานจริง ตาม topic
+  context.md
+  [topic]/             # ★ template ของหนึ่งหน่วยงาน — copy ไปตั้งชื่อจริง
+    discovery.md  research.md       # output ของ Discovery
+    business.md  proposal.md  design.md   # output ของ DESIGN
+    tasks/[task-name]/...  build.md        # output ของ DESIGN (tasks) + BUILD (build.md)
+    test.md  verify.md                     # output ของ VERIFY
+    troubleshooting.md  ship.md            # KB ระหว่างงาน + สรุปส่งมอบของ SHIP
+  achieved/[YYYY-MM-DD-topic]/             # archive หลัง SHIP
+```
+
+---
+
+## การติดตั้งไปโปรเจกต์อื่น
+
+```bash
+cd my-project
+npx @warnyin/agents             # ติดตั้ง (ข้ามไฟล์ที่มีอยู่ ไม่เขียนทับ)
+npx @warnyin/agents --update    # อัปเดต playbook กลางเป็นเวอร์ชันล่าสุด
+npx @warnyin/agents --dry-run   # ดูก่อนว่าจะสร้าง/อัปเดตอะไร
+# ทางสำรอง (ไม่ผ่าน npm): npx github:warnyin/warnyin-agents
+```
+
+- โปรเจกต์ที่มี `CLAUDE.md`/`AGENTS.md` อยู่แล้ว → installer ต่อท้ายเป็น section ไม่เขียนทับ
+- `--update` เขียนทับเฉพาะ core (`workflow/`, `.claude/commands/warnyin/`, template `[topic]`) — ไม่แตะ `docs/` และงานจริง
+- หลังติดตั้ง → เปิด Claude Code แล้วรัน `/warnyin:init` ให้ agent วิเคราะห์โปรเจกต์ + เติม `docs/` (playbook: `workflow/init.md`)
+
+## วิธีใช้
+
+1. เริ่มงานใหม่ → copy `warnyin-stages/[topic]/` เป็น `warnyin-stages/<ชื่อ-งาน-kebab-case>/`
+2. รัน stage ตามลำดับ (Discovery ข้ามได้ถ้าเข้าใจ scope ชัดแล้ว)
+   - Claude Code: `/warnyin:discovery <topic>`, `/warnyin:design <slug> <change>`
+   - Codex / Antigravity: บอกให้ทำตาม `workflow/stages/<stage>.md`
+3. ผ่าน "gate" ของแต่ละ stage แล้วจึงไป stage ถัดไป
+4. เมื่อ SHIP (`/warnyin:ship <slug>`) → promote ความรู้ของ topic ขึ้นเอกสารกลางใน `docs/`
+   แล้วย้าย topic ไป `warnyin-stages/achieved/<YYYY-MM-DD>-<topic>/`

package/workflow/init.md

@@ -0,0 +1,59 @@
+# INIT — วิเคราะห์โปรเจกต์ + เติม docs/ ครั้งแรก
+
+> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
+> เป้าหมาย: ทำให้ `docs/` สะท้อนโปรเจกต์จริง — เพื่อให้ทุก stage (Discovery→SHIP) เริ่มจากความรู้ที่ถูกต้อง ไม่ใช่โครงว่างเปล่า
+
+---
+
+## 1. INIT คืออะไร / ใช้เมื่อไหร่
+
+ใช้ **ครั้งแรกหลังติดตั้ง workflow** ลงโปรเจกต์ (`npx github:warnyin/warnyin-agents`)
+หรือเมื่อ `docs/` ยังว่าง/ล้าสมัยจนใช้อ้างอิงไม่ได้ — INIT ไม่ใช่ stage ของงาน แต่เป็นการ **ปูพื้นความรู้** ให้ workflow ทำงานได้เต็มประสิทธิภาพ
+
+---
+
+## 2. หลักการทำงาน (operating principles)
+
+1. **โค้ดตอบได้ → อ่านโค้ดเอง ห้ามเดา** — structure, techstack, convention, วิธี build/test, infra วิเคราะห์จาก **โค้ดจริง + config จริง** เท่านั้น
+2. **ข้อมูลธุรกิจโค้ดตอบไม่ได้ → สัมภาษณ์ user** — เป้าหมายโปรเจกต์ ลูกค้า ขอบเขต ความสำคัญ: **ถามทีละข้อ + เสนอคำตอบแนะนำทุกครั้ง** (เดาจาก README/โค้ดเป็น recommended answer ให้ user แค่ยืนยัน/แก้)
+3. **เสนอ summary ก่อนเขียน** — สรุปสิ่งที่วิเคราะห์ได้ + รายการไฟล์ docs/ ที่จะเขียน ให้ user ยืนยัน **ครั้งเดียว** แล้วจึงเขียนจริง
+4. **ไฟล์ docs/ ที่มีเนื้อหาอยู่แล้ว → เติม/อัปเดต ไม่เขียนทับทิ้ง** — ของเดิมของ user มีค่าเสมอ
+5. **วิเคราะห์หลาย component ขนานได้** — fan-out sub-agent (read-only) หนึ่งตัวต่อหนึ่ง component; เครื่องที่ไม่มี sub-agent → วิเคราะห์ทีละ component ด้วยหลักการเดียวกัน
+6. **ไม่แน่ใจ → ระบุว่า "ยังว่าง รอเติม" ชัดเจน** — ห้ามแต่งเนื้อหาขึ้นเองเพื่อให้ไฟล์ดูเต็ม
+
+---
+
+## 3. ลำดับขั้นการทำงาน (process)
+
+1. **สแกนภาพรวม:** โครงสร้าง repo, package manifest, ภาษา/framework, แบ่งเป็น **component** อะไรบ้าง (เช่น api-service, admin-console)
+2. **วิเคราะห์ลึกต่อ component (ขนานได้, read-only):** โครงสร้างโฟลเดอร์/โมดูล, pattern/convention ที่ใช้จริงในโค้ด, วิธี build/test ที่มีอยู่
+3. **วิเคราะห์ infra:** docker/compose, env, service ที่ต้องรันสำหรับ local dev
+4. **สัมภาษณ์ user เติมส่วนธุรกิจ:** เป้าหมายโปรเจกต์ ลูกค้า ขอบเขต — ทีละข้อ + recommended answer
+5. **เสนอ summary → user ยืนยันครั้งเดียว → เขียน docs/** (ตามตาราง Output ข้อ 4)
+6. **รายงานปิดท้าย:** ส่วนไหนยังว่าง/ไม่แน่ใจ ให้ user เติมภายหลัง → พร้อมเริ่มงานแรกด้วย `/warnyin:discovery` หรือ `/warnyin:design`
+
+---
+
+## 4. Output (เขียน/เติมที่ `docs/`)
+
+| ไฟล์ | เนื้อหา | แหล่งข้อมูล |
+|---|---|---|
+| `docs/project.md` | โปรเจกต์คืออะไร เป้าหมาย ลูกค้า ขอบเขต | สัมภาษณ์ user (+ README เดิมเป็น recommended) |
+| `docs/techstack/<component>/about.md` | component นี้คืออะไร ทำหน้าที่อะไร | โค้ดจริง |
+| `docs/techstack/<component>/structure.md` | โครงสร้างโฟลเดอร์/โมดูล | โค้ดจริง |
+| `docs/techstack/<component>/standard.md` | pattern/convention ที่พบจริงในโค้ด (ยืนยันกับ user) | โค้ดจริง + user |
+| `docs/techstack/<component>/rule.md` | กฎที่ user ต้องการบังคับ (ถามก่อน ห้ามเดา) | user |
+| `docs/techstack/<component>/test.md` | วิธีเทสที่ใช้อยู่ (framework, คำสั่ง, e2e) | โค้ด/config จริง |
+| `docs/codemap/index.md` | แผนที่โค้ดภาพรวม: component, จุดเข้า, โฟลเดอร์สำคัญ | โค้ดจริง |
+| `docs/infra.md` | local env: service ที่ต้องรัน, วิธีรัน, env vars | config จริง |
+| `docs/rule.md`, `docs/troubleshooting.md` | วางโครงหัวข้อ รอเติมระหว่างใช้งานจริง | — |
+
+---
+
+## 5. Gate → จบ INIT เมื่อ
+
+- [ ] `docs/project.md` มีเป้าหมาย/ลูกค้า/ขอบเขต ที่ user ยืนยันแล้ว
+- [ ] `docs/techstack/` ครบทุก component ที่พบ (about + structure + standard + test)
+- [ ] `docs/codemap/index.md` + `docs/infra.md` ตรงกับโค้ด/config จริง
+- [ ] ทุกเนื้อหามาจากโค้ดจริงหรือคำยืนยันของ user — **ไม่มีการเดา**; ส่วนที่ไม่แน่ใจระบุ "ยังว่าง รอเติม" ชัดเจน
+- [ ] user รับทราบรายการที่ยังว่าง