@warnyin/agents 0.2.0 → 0.5.0

package/warnyin/workflow/codemap.md

@@ -0,0 +1,91 @@
+# CODEMAP — สแกนโครงสร้างโปรเจกต์ + สร้าง architecture codemap แบบ token-lean
+
+> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
+> เป้าหมาย: `docs/codemap/` ที่ **ประหยัด token** สำหรับให้ AI โหลดเข้า context — โครงสร้างระดับสูง ไม่ใช่ implementation detail
+
+---
+
+## 1. ใช้เมื่อไหร่
+
+- หลังเพิ่ม feature ใหญ่ / refactor ครั้งสำคัญ
+- `/warnyin:init` ใช้ playbook นี้ตอนสร้าง codemap ครั้งแรก
+- **SHIP** ใช้ตอนขั้น "อัปเดต code map ทั้งหมด"
+
+---
+
+## 2. ขั้นตอน
+
+### Step 1: สแกนโครงสร้างโปรเจกต์
+- ระบุชนิดโปรเจกต์: monorepo / single app / library / microservice
+- หา source directory ทั้งหมด (`src/`, `lib/`, `app/`, `packages/`, ...)
+- map entry points (`main.ts`, `index.ts`, `app.py`, `main.go`, ...)
+- สแกนขนานได้: fan-out sub-agent (read-only) ต่อ component/พื้นที่ — เครื่องที่ไม่มี sub-agent → ไล่ทีละส่วน
+
+### Step 2: สร้าง/อัปเดต codemap ใน `docs/codemap/`
+
+| ไฟล์ | เนื้อหา |
+|---|---|
+| `index.md` | สารบัญทั้งชุด + ภาพรวม component + จุดเข้า |
+| `architecture.md` | system diagram ระดับสูง, service boundary, data flow |
+| `backend.md` | API routes, middleware chain, service → repository mapping |
+| `frontend.md` | page tree, component hierarchy, state management flow |
+| `data.md` | ตาราง DB, relationship, migration history |
+| `dependencies.md` | external service, third-party integration, shared library |
+
+**สร้างเฉพาะไฟล์ที่ relevant** — โปรเจกต์ไม่มี frontend → ไม่ต้องมี `frontend.md`
+
+#### รูปแบบ codemap (token-lean)
+
+```markdown
+# Backend Architecture
+
+## Routes
+POST /api/users → UserController.create → UserService.create → UserRepo.insert
+GET  /api/users/:id → UserController.get → UserService.findById → UserRepo.findById
+
+## Key Files
+src/services/user.ts (business logic, 120 lines)
+src/repos/user.ts (database access, 80 lines)
+
+## Dependencies
+- PostgreSQL (primary data store)
+- Redis (session cache, rate limiting)
+- Stripe (payment processing)
+```
+
+### Step 3: Diff detection
+- มี codemap เดิมอยู่ → คำนวณ % การเปลี่ยนแปลง
+- เปลี่ยน **> 30%** → แสดง diff + **ขอ user อนุมัติก่อนเขียนทับ**
+- เปลี่ยน **≤ 30%** → อัปเดต in place ได้เลย
+
+### Step 4: Metadata
+ใส่ freshness header บนสุดของทุกไฟล์:
+```html
+<!-- Generated: YYYY-MM-DD | Files scanned: N | Token estimate: ~X -->
+```
+
+### Step 5: Analysis report → `.reports/codemap-diff.txt`
+- ไฟล์ added / removed / modified ตั้งแต่สแกนครั้งล่าสุด
+- dependency ใหม่ที่ตรวจพบ
+- architecture changes (route ใหม่, service ใหม่ ฯลฯ)
+- คำเตือน staleness: doc ที่ไม่ถูกอัปเดต 90+ วัน
+
+---
+
+## 3. หลักการ (tips)
+
+- โฟกัสโครงสร้างระดับสูง — **ไม่ใช่** implementation detail
+- ใช้ file path + function signature แทน code block เต็ม
+- แต่ละ codemap **< 1000 tokens** เพื่อโหลดเข้า context ได้ถูก
+- ใช้ ASCII diagram แทนคำบรรยาย data flow ยืดยาว
+- **ทุกอย่างต้องมาจากโค้ดจริง ณ วันสแกน — ห้ามเดา/ห้ามเขียนจากความจำ**
+
+---
+
+## 4. Gate — จบเมื่อ
+
+- [ ] codemap ทุกไฟล์ตรงโค้ดจริง + มี freshness header
+- [ ] `index.md` ลิงก์ครบทุกไฟล์ codemap ที่มี
+- [ ] ทุกไฟล์ token-lean (< 1000 tokens)
+- [ ] diff > 30% ผ่านการอนุมัติจาก user แล้ว
+- [ ] `.reports/codemap-diff.txt` เขียนแล้ว

package/warnyin/workflow/explore.md

@@ -0,0 +1,32 @@
+# EXPLORE — สำรวจ/ตอบคำถามแบบ read-only (ไม่สร้าง artifact)
+
+> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
+> เป้าหมาย: ตอบคำถาม/สำรวจข้อมูล โค้ด และเอกสารของโปรเจกต์แบบ **grounded** โดย **ไม่สร้างหรือแก้ไฟล์ใดๆ** — จบที่คำตอบในแชท
+
+---
+
+## 1. EXPLORE คืออะไร / ใช้เมื่อไหร่
+
+EXPLORE คือโหมด **อ่านอย่างเดียว (read-only)** — ไม่ใช่ stage ใน workflow, ไม่มี gate, ไม่มี output ไฟล์
+
+- ใช้เมื่อ: อยากเข้าใจข้อมูล/โค้ด/พฤติกรรมระบบ, ถามเช็คความเข้าใจ, หาว่าอะไรอยู่ตรงไหน, เปรียบเทียบทางเลือกแบบเร็วๆ — **ยังไม่แน่ใจว่าจะกลายเป็นงานจริงหรือไม่**
+- ต่างจาก Discovery: Discovery เป็น stage ที่ผลิต `discovery.md` + `research.md` เพื่อเข้า DESIGN — EXPLORE แค่ตอบ ไม่จดอะไรลงไฟล์
+
+---
+
+## 2. Input ที่อ่านเพื่อ ground ตัวเอง (เท่าที่เกี่ยวกับคำถาม — ไม่ต้องครบทุกไฟล์)
+
+1. `docs/project.md` — โปรเจกต์นี้คืออะไร เป้าหมาย ขอบเขต
+2. `docs/codemap/index.md` — แผนที่โค้ด (ไปอ่านโค้ดจริงต่อได้)
+3. `docs/rule.md`, `docs/infra.md`, `docs/features/*`, `docs/techstack/*` — ตามที่คำถามแตะ
+4. `warnyin/stages/context.md` + topic ใน `warnyin/stages/` และ `achieved/` ที่ใกล้เคียง — งานที่เคยทำ/กำลังทำ
+
+---
+
+## 3. หลักการทำงาน
+
+1. **Read-only เด็ดขาด:** ใช้เฉพาะการอ่าน/ค้น (read, grep, glob, sub-agent แบบ read-only) — **ห้ามสร้าง แก้ หรือลบไฟล์ใดๆ** รวมถึงไฟล์ใน `warnyin/stages/` และ `docs/`
+2. **โค้ดตอบได้ → ไปอ่านโค้ด:** อ้างอิงคำตอบด้วย `path:line` หรือชื่อไฟล์จริงเสมอ ไม่ตอบจากการเดา
+3. **คำถามกว้าง → fan-out:** ถ้าต้องกวาดหลายพื้นที่ ให้กระจาย sub-agent แบบ read-only (เช่น Explore) ขนานกัน แล้วสังเคราะห์คำตอบเดียว
+4. **ตอบในแชทเท่านั้น:** สรุปกระชับ ชี้ไฟล์/บรรทัดให้ user ไปต่อเองได้
+5. **เจอประเด็นที่ควรเก็บเป็นงาน → เสนอ ไม่ทำเอง:** ถ้าการสำรวจชี้ว่าควรเปิด topic จริง ให้เสนอ `/warnyin:discovery <topic>` (scope ยังกว้าง) หรือ `/warnyin:design <slug> <change>` (scope ชัดแล้ว) — ให้ user เป็นคนตัดสินใจ

package/{workflow → warnyin/workflow}/init.md

@@ -36,6 +36,8 @@
 
 ## 4. Output (เขียน/เติมที่ `docs/`)
 
+> โฟลเดอร์ component จริงให้ copy จาก template `warnyin/template/docs/techstack/[component]/` เป็นชื่อจริง (เช่น `api-service/`) — ห้ามทิ้งโฟลเดอร์ `[component]` ว่างไว้เฉยๆ โดยไม่สร้างของจริง
+
 | ไฟล์ | เนื้อหา | แหล่งข้อมูล |
 |---|---|---|
 | `docs/project.md` | โปรเจกต์คืออะไร เป้าหมาย ลูกค้า ขอบเขต | สัมภาษณ์ user (+ README เดิมเป็น recommended) |
@@ -44,7 +46,7 @@
 | `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/codemap/` | แผนที่โค้ดทั้งชุด — สร้างตาม playbook `warnyin/workflow/codemap.md` (token-lean) | โค้ดจริง |
 | `docs/infra.md` | local env: service ที่ต้องรัน, วิธีรัน, env vars | config จริง |
 | `docs/rule.md`, `docs/troubleshooting.md` | วางโครงหัวข้อ รอเติมระหว่างใช้งานจริง | — |
 

package/warnyin/workflow/next.md

@@ -0,0 +1,47 @@
+# NEXT — เช็คงานค้าง + แนะนำขั้นตอนถัดไป (read-only)
+
+> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
+> เป้าหมาย: ตอบคำถาม "ตอนนี้มีงานอะไรค้าง และควรไปต่อยังไง" จากสถานะจริงในไฟล์ — **ไม่สร้างหรือแก้ไฟล์ใดๆ**
+
+---
+
+## 1. NEXT คืออะไร / ใช้เมื่อไหร่
+
+NEXT คือโหมด **อ่านอย่างเดียว (read-only)** — ไม่ใช่ stage, ไม่มี gate, ไม่มี output ไฟล์
+ใช้เมื่อ: กลับมาทำงานต่อแล้วจำไม่ได้ว่าค้างตรงไหน, อยากเห็นภาพรวมทุก topic, หรืออยากรู้ว่า command ถัดไปคืออะไร
+
+---
+
+## 2. วิธีหาสถานะ (สแกนจากไฟล์จริง — ไม่ถาม user ก่อน)
+
+1. **หา topic ที่ active:** โฟลเดอร์ใน `warnyin/stages/<slug>/` ทั้งหมด ยกเว้น `achieved/` และ `context.md`
+   - ไม่มี topic เลย → รายงานว่า "ไม่มีงานค้าง" + แนะนำเริ่มงานใหม่ด้วย `/warnyin:discovery` หรือ `/warnyin:design`
+2. **อ่าน `warnyin/stages/context.md`** — บริบทงานที่จดไว้ (ถ้ามี)
+3. **ต่อ topic — ระบุ stage ปัจจุบันจาก artifact ที่ "ถูกเติมจริง":**
+   ไฟล์ที่ยังเป็นโครง template (มี placeholder `<...>` / ตารางว่าง) = **ยังไม่ทำ** — ดูเนื้อหา ไม่ใช่แค่ว่าไฟล์มีอยู่
+
+   | artifact ที่เติมแล้วล่าสุด | stage ปัจจุบัน | ขั้นถัดไป |
+   |---|---|---|
+   | ยังไม่มีอะไรเติม | ยังไม่เริ่ม | `/warnyin:discovery <slug>` หรือ `/warnyin:design <slug> <change>` ถ้า scope ชัด |
+   | `discovery.md` / `research.md` | Discovery | เช็ค gate ของ `stages/discovery.md` → ผ่านแล้วไป `/warnyin:design` |
+   | `proposal.md` / `design.md` / `tasks/` | DESIGN | เช็ค gate ของ `stages/design.md` → ผ่านแล้วไป `/warnyin:build` |
+   | `build.md` / task มีสถานะ `กำลังทำ`-`เสร็จ` | BUILD | task ค้าง → `/warnyin:build` ต่อ; ครบแล้ว → `/warnyin:verify` |
+   | `test.md` / `verify.md` | VERIFY | เช็ค gate ของ `stages/verify.md` → ผ่านแล้วไป `/warnyin:ship` |
+   | `ship.md` เติมแล้วแต่ topic ยังไม่ถูก archive | SHIP ยังไม่จบ | รัน `/warnyin:ship` ให้จบ (promote ขึ้น `docs/` + ย้ายไป `achieved/`) |
+
+4. **งานค้างระดับ task (เฉพาะ topic ที่อยู่ BUILD):** ไล่ `tasks/*/task.md` — ช่อง **สถานะ** (`รอ build` / `กำลังทำ` / `เสร็จ`) + checkbox ของ sub-tasks/acceptance ที่ยังไม่ติ๊ก
+5. **เช็ค gate ของ stage ปัจจุบัน:** เปิด playbook ของ stage นั้นใน `warnyin/workflow/stages/` แล้วไล่ checklist gate ว่าข้อไหนยังไม่ครบ — ข้อที่ขาดคือ "งานค้าง" ที่แท้จริง
+
+---
+
+## 3. รูปแบบรายงาน (ตอบในแชทเท่านั้น)
+
+1. **ตารางภาพรวม:** topic · stage ปัจจุบัน · งานค้าง/gate ที่ขาด · command ถัดไปที่แนะนำ
+2. **รายละเอียดต่อ topic** (เฉพาะที่มีงานค้าง): ข้อ gate ที่ยังไม่ผ่าน, task ที่ยัง `รอ build`/`กำลังทำ`, open question
+3. **คำแนะนำลำดับงาน:** ถ้ามีหลาย topic ให้เสนอว่าควรทำอันไหนก่อนพร้อมเหตุผลสั้นๆ — ตัดสินใจสุดท้ายเป็นของ user
+
+## 4. หลักการ
+
+1. **Read-only เด็ดขาด** — ห้ามสร้าง/แก้/ลบไฟล์ รวมถึง `context.md`; ถ้าพบว่าสถานะในไฟล์ล้าสมัย ให้รายงานเป็นข้อเสนอ ไม่แก้เอง
+2. **สรุปจาก evidence:** ทุกข้อสรุปอ้างไฟล์/บรรทัดจริง ไม่เดา
+3. **แนะนำแล้วหยุด:** ไม่รัน stage ถัดไปให้เอง — เสนอ command ให้ user เป็นคนสั่ง

package/{workflow → warnyin/workflow}/roles/developer.md

@@ -1,6 +1,6 @@
 # Role: Developer
 
-> ใช้ใน: **BUILD** — system prompt เสริมของ build sub-agent ทุกตัว (ผ่าน `workflow/scripts/build-wave.mjs`)
+> ใช้ใน: **BUILD** — system prompt เสริมของ build sub-agent ทุกตัว (ผ่าน `warnyin/workflow/scripts/build-wave.mjs`)
 
 ## Mission
 implement vertical slice ที่รับมอบให้ **เสร็จจริง เขียวจริง** ตาม standard — ไม่เกิน scope ไม่ต่ำกว่า spec

package/{workflow → warnyin/workflow}/scripts/build-wave.mjs

@@ -3,7 +3,7 @@
 //
 // args = {
 //   slug: string,            // ชื่อ topic เช่น "billing-redesign"
-//   tasks: string[],         // ชื่อ task ใน wave นี้ (โฟลเดอร์ warnyin-stages/<slug>/tasks/<task>)
+//   tasks: string[],         // ชื่อ task ใน wave นี้ (โฟลเดอร์ warnyin/stages/<slug>/tasks/<task>)
 //   isolate?: boolean,       // true = worktree ต่อ task (ดีฟอลต์), false = shared tree (sequential)
 // }
 
@@ -57,17 +57,17 @@ const RESULT_SCHEMA = {
 }
 
 function prompt(task) {
-  const dir = `warnyin-stages/${slug}/tasks/${task}`
+  const dir = `warnyin/stages/${slug}/tasks/${task}`
   const lines = [
-    `คุณคือ build sub-agent ของ task "${task}" (vertical slice) ทำตาม playbook workflow/stages/build.md`,
+    `คุณคือ build sub-agent ของ task "${task}" (vertical slice) ทำตาม playbook warnyin/workflow/stages/build.md`,
     ``,
     `1. อ่านให้ครบก่อนเขียนโค้ด:`,
-    `   - workflow/roles/developer.md (role card: lens + checklist ก่อนส่งงาน — ทำตามทุกข้อ)`,
+    `   - warnyin/workflow/roles/developer.md (role card: lens + checklist ก่อนส่งงาน — ทำตามทุกข้อ)`,
     `   - ${dir}/task.md (เป้าหมาย + sub-tasks + dependency + acceptance)`,
     `   - ${dir}/spec.md (API/UXUI/data-flow/user-flow/persona/test-flow)`,
     `   - ${dir}/standard.md (pattern โค้ด, shared component — reuse ห้ามเขียนซ้ำ)`,
     `   - ${dir}/rule.md (กฎที่ต้อง follow)`,
-    `   - ภาพรวม: warnyin-stages/${slug}/design.md, proposal.md`,
+    `   - ภาพรวม: warnyin/stages/${slug}/design.md, proposal.md`,
     `   - rule/standard กลางที่อ้างถึงใน docs/techstack/<component>/`,
     `2. Implement ให้ครบทุก sub-task แบบ vertical slice (end-to-end) ทำตาม standard.md + rule.md เคร่งครัด`,
     `3. รัน test-flow ใน spec.md + build/lint ของ component นั้น`,

package/{workflow → warnyin/workflow}/stages/build.md

@@ -14,9 +14,9 @@ BUILD จะ **orchestrate การ implement** โดยกระจายง
 
 ## 2. Input ที่ต้องอ่านก่อนเริ่ม
 
-1. `warnyin-stages/<slug>/design.md` — dependency graph ระหว่าง task/slice (section 7)
-2. `warnyin-stages/<slug>/proposal.md` — scope ของ change
-3. `warnyin-stages/<slug>/tasks/<task>/task.md` ทุกใบ — dependency ของแต่ละ task + sub-tasks
+1. `warnyin/stages/<slug>/design.md` — dependency graph ระหว่าง task/slice (section 7)
+2. `warnyin/stages/<slug>/proposal.md` — scope ของ change
+3. `warnyin/stages/<slug>/tasks/<task>/task.md` ทุกใบ — dependency ของแต่ละ task + sub-tasks
 4. `docs/techstack/<component>/rule.md` + `standard.md` — กฎ/มาตรฐานที่ต้อง follow
 
 ---
@@ -34,8 +34,8 @@ BUILD จะ **orchestrate การ implement** โดยกระจายง
 6. **ห้ามแตะ rule/standard กลางใน `docs/`** — rule ใหม่ที่เสนอถูก note ไว้ใน `tasks/<task>/rule.md` แล้ว รอ SHIP ค่อยอัปเดตไฟล์กลาง
 7. **fail = หยุดที่ wave นั้น** — ถ้า task ใน wave ล้ม ให้รายงาน user ก่อนไป wave ถัดไป (เพราะ wave ถัดไปอาจ depend อยู่)
 8. **★ ปิดท้ายด้วย full build + full test เสมอ** — หลัง merge ทุก wave แล้ว ต้องรัน build ทั้งหมด + test suite ทั้งหมด (รวม unit test) บน build branch ที่ integrate; **แก้วนจนเขียวหมด** ก่อนปิด BUILD (กันกรณี task รายเดี่ยวเขียวแต่พอรวมกันแล้วพัง)
-9. **ทุก build agent สวม role Developer** — ทำตาม role card `workflow/roles/developer.md` (lens + checklist ก่อนส่งงาน) — build-wave.mjs ใส่ให้ใน prompt แล้ว
-10. **★ ใช้ Troubleshooting KB** — เจอปัญหา/error ระหว่าง build ให้ **อ่าน `docs/troubleshooting.md` ก่อนเสมอ** เผื่อเคยแก้แล้ว; เมื่อแก้ปัญหาที่ **ยาก/เจอซ้ำ** สำเร็จ ให้บันทึก entry ลง `warnyin-stages/<slug>/troubleshooting.md` (ปัญหา/อาการ/root cause/วิธีแก้/ป้องกันซ้ำ) — ตอน SHIP จะยกขึ้น KB กลาง
+9. **ทุก build agent สวม role Developer** — ทำตาม role card `warnyin/workflow/roles/developer.md` (lens + checklist ก่อนส่งงาน) — build-wave.mjs ใส่ให้ใน prompt แล้ว
+10. **★ ใช้ Troubleshooting KB** — เจอปัญหา/error ระหว่าง build ให้ **อ่าน `docs/troubleshooting.md` ก่อนเสมอ** เผื่อเคยแก้แล้ว; เมื่อแก้ปัญหาที่ **ยาก/เจอซ้ำ** สำเร็จ ให้บันทึก entry ลง `warnyin/stages/<slug>/troubleshooting.md` (ปัญหา/อาการ/root cause/วิธีแก้/ป้องกันซ้ำ) — ตอน SHIP จะยกขึ้น KB กลาง
 
 ---
 
@@ -43,13 +43,13 @@ BUILD จะ **orchestrate การ implement** โดยกระจายง
 
 > ผู้ orchestrate คือ AI ตัวหลัก (main loop) — sub-agent คือคนลงมือ implement
 
-0. **★ เช็ค context window ก่อนเริ่ม:** ประเมินว่า context ของ session ปัจจุบันถูกใช้ไปมากน้อยแค่ไหน — ถ้าใช้ไปเยอะหรือ **เกินครึ่ง** → **เสนอ user ให้ `/compact` หรือ `/clear` ก่อนเสมอ** แล้วค่อยเริ่ม BUILD ใน context ที่โล่ง (สถานะงานอยู่ในไฟล์ `warnyin-stages/<slug>/` ครบ ไม่หายไปกับ context) — BUILD เป็นงานยาว ต้องมี context เหลือมากพอ; เครื่องอื่นที่ไม่มีคำสั่งนี้ → แนะนำเริ่ม session ใหม่
+0. **★ เช็ค context window ก่อนเริ่ม:** ประเมินว่า context ของ session ปัจจุบันถูกใช้ไปมากน้อยแค่ไหน — ถ้าใช้ไปเยอะหรือ **เกินครึ่ง** → **เสนอ user ให้ `/compact` หรือ `/clear` ก่อนเสมอ** แล้วค่อยเริ่ม BUILD ใน context ที่โล่ง (สถานะงานอยู่ในไฟล์ `warnyin/stages/<slug>/` ครบ ไม่หายไปกับ context) — BUILD เป็นงานยาว ต้องมี context เหลือมากพอ; เครื่องอื่นที่ไม่มีคำสั่งนี้ → แนะนำเริ่ม session ใหม่
 1. **อ่าน task ทั้งหมด** → ดึง dependency ของแต่ละ task จาก `task.md` (section 2) + `design.md` (section 7)
 2. **สร้าง DAG + จัด wave** (topological sort): wave 1 = task ที่ไม่มี dependency, wave 2 = task ที่ depend เฉพาะ wave 1, ...
 3. **Pre-check:** target เป็น git repo ไหม (สำหรับ worktree) — ถ้าไม่ใช่ → fallback sequential shared-tree และแจ้ง user
 4. **เสนอ execution plan + ขออนุมัติ (ครั้งเดียว):** แสดง wave / task ในแต่ละ wave / อันไหน parallel / isolation mode → ถาม user go/no-go
 5. **เดินทีละ wave:**
-   - fan-out sub-agent ของ task ใน wave นั้น (parallel, worktree isolation) ผ่าน **Workflow** (`workflow/scripts/build-wave.mjs`)
+   - fan-out sub-agent ของ task ใน wave นั้น (parallel, worktree isolation) ผ่าน **Workflow** (`warnyin/workflow/scripts/build-wave.mjs`)
    - แต่ละ agent: implement → test/lint → commit (ถ้า worktree) → รายงานผลแบบ structured (status, files, branch, test result)
    - **integrate:** main loop merge worktree branch ของ wave นั้นเข้า build branch (ทีละอันเพื่อเลี่ยง conflict); ถ้า conflict → แก้/รายงาน
    - ถ้ามี task `failed` → หยุด รายงาน user
@@ -66,15 +66,15 @@ BUILD จะ **orchestrate การ implement** โดยกระจายง
 | ไฟล์ | เนื้อหา |
 |---|---|
 | โค้ดจริงใน target repo | การ implement ของแต่ละ task (merge เข้า build branch) |
-| `warnyin-stages/<slug>/build.md` | รายงานผล build: สถานะ/ผล test/ไฟล์ที่แก้ ต่อ task + integration notes |
-| `warnyin-stages/<slug>/troubleshooting.md` | ปัญหายาก/ซ้ำที่แก้สำเร็จ (SHIP ยกขึ้น `docs/troubleshooting.md`) |
+| `warnyin/stages/<slug>/build.md` | รายงานผล build: สถานะ/ผล test/ไฟล์ที่แก้ ต่อ task + integration notes |
+| `warnyin/stages/<slug>/troubleshooting.md` | ปัญหายาก/ซ้ำที่แก้สำเร็จ (SHIP ยกขึ้น `docs/troubleshooting.md`) |
 | `tasks/<task>/task.md` (อัปเดต) | สถานะ task → เสร็จ + acceptance ที่ผ่าน |
 
 ---
 
 ## 6. Workflow script (Claude Code)
 
-ใช้ `workflow/scripts/build-wave.mjs` — fan-out หนึ่ง agent ต่อหนึ่ง task ใน **หนึ่ง wave** (parallel, worktree isolation), คืนผลแบบ structured
+ใช้ `warnyin/workflow/scripts/build-wave.mjs` — fan-out หนึ่ง agent ต่อหนึ่ง task ใน **หนึ่ง wave** (parallel, worktree isolation), คืนผลแบบ structured
 main loop เรียก script นี้ **ทีละ wave** แล้ว integrate ระหว่าง wave (ดูรายละเอียดใน `.claude/commands/warnyin/build.md`)
 
 > เครื่องอื่น (Codex/Antigravity) ที่ไม่มี Workflow tool: ทำตามหลักการข้อ 3-4 โดย implement task ตามลำดับ wave เอง (parallel เท่าที่เครื่องรองรับ)

package/{workflow → warnyin/workflow}/stages/design.md

@@ -21,7 +21,7 @@
 2. `docs/rule.md` + `docs/techstack/<component>/rule.md` — ★ กฎที่ต้อง follow
 3. `docs/techstack/<component>/standard.md` — ★ pattern/มาตรฐานการเขียนโค้ด
 4. `docs/techstack/<component>/{about,structure,test}.md`, `docs/codemap/index.md` — โครงสร้าง/วิธีเทสต์
-5. ถ้ามี Discovery → `warnyin-stages/<slug>/discovery.md`, `research.md`
+5. ถ้ามี Discovery → `warnyin/stages/<slug>/discovery.md`, `research.md`
 6. โค้ดจริงที่เกี่ยวข้อง (inspect เพื่อตอบคำถามแทนการเดา)
 
 ---
@@ -33,33 +33,33 @@
 3. **task = หน่วยที่โยนให้ sub-agent ได้** — แต่ละ task self-contained (มี spec + standard + rule ของตัวเอง) แต่ **เชื่อมต่อกัน** ผ่าน dependency/ลำดับที่ระบุชัด
 4. **สอดคล้องมาตรฐานเสมอ** — อิง rule + standard ของ techstack; ถ้าจะเพิ่ม rule/standard ใหม่ ให้ **note ไว้ก่อน** (ยังไม่แก้ไฟล์กลาง — รอ SHIP)
 5. **Gate ก่อนเขียนไฟล์ task จริง** — ต้องผ่านเกณฑ์ข้อ 8 ก่อนจะ generate ไฟล์ task และก่อนโยนให้ sub-agent
-6. **ใช้ role lens** — ออกแบบ (design.md) ด้วยมุม **SA** (`workflow/roles/sa.md`) และแตก/ตรวจ task ด้วยมุม **Tech Lead** (`workflow/roles/tech-lead.md`)
-7. **Review panel ก่อนแตก task (optional — ถาม user ก่อนเสมอ)** — ให้หลาย role (SA / Tech Lead / QA / Security / Infra ตาม `workflow/roles/`) รีวิว design ขนานแบบอิสระ (read-only) แล้วแก้ blocker ให้ครบก่อนแตก task (ดูขั้นตอนข้อ 4.6)
+6. **ใช้ role lens** — ออกแบบ (design.md) ด้วยมุม **SA** (`warnyin/workflow/roles/sa.md`) และแตก/ตรวจ task ด้วยมุม **Tech Lead** (`warnyin/workflow/roles/tech-lead.md`)
+7. **Review panel ก่อนแตก task (optional — ถาม user ก่อนเสมอ)** — ให้หลาย role (SA / Tech Lead / QA / Security / Infra ตาม `warnyin/workflow/roles/`) รีวิว design ขนานแบบอิสระ (read-only) แล้วแก้ blocker ให้ครบก่อนแตก task (ดูขั้นตอนข้อ 4.6)
 8. **Dry-run ก่อนเข้า BUILD (optional — ถาม user ก่อนเสมอ)** — หลังเขียนไฟล์ task ครบ เสนอ user ว่าจะ dry-run ทั้งหมดเพื่อหาจุดบกพร่องไหม ถ้า ok → สแกนทุก task แบบขนาน (read-only) หา **defer/blocker** แล้วแก้ DESIGN จนไม่มี blocker ค้าง (ดูขั้นตอนข้อ 4.10) — การแก้ **ห้ามเดา ห้ามคิดขึ้นเอง**
 
 ---
 
 ## 4. ลำดับขั้นการทำงาน (process)
 
-1. **เตรียมพื้นที่:** ใช้/สร้างโฟลเดอร์ `warnyin-stages/<slug>/` (ถ้ามาจาก Discovery ใช้อันเดิม)
+1. **เตรียมพื้นที่:** ใช้/สร้างโฟลเดอร์ `warnyin/stages/<slug>/` (ถ้ามาจาก Discovery ใช้อันเดิม)
 2. **Ground + เคลียร์ความไม่ชัด:** อ่าน Input; ทุกจุดกำกวมเรื่อง design → ถามทีละข้อ + recommended answer จนชัด (ถ้าใหญ่/ไม่ชัดมาก → แนะนำ Discovery ก่อน)
 3. **business.md** *(optional — ข้ามได้ถ้า change เล็ก เช่น fix bug นิดหน่อย)*: what & why เชิงธุรกิจ — goal, คุณค่า, persona, success metric
 4. **proposal.md** (what & why): สรุป change ที่จะทำ, เหตุผล, ทางเลือกที่พิจารณา/ตัดทิ้ง, scope in/out
-5. **design.md** (how): ออกแบบเชิงเทคนิคแบบ vertical slice — slice มีอะไรบ้าง, แต่ละ slice ตัดผ่าน layer ไหน, data model, interface/contract, flow, ผลกระทบต่อระบบเดิม (ใช้ lens `workflow/roles/sa.md`)
+5. **design.md** (how): ออกแบบเชิงเทคนิคแบบ vertical slice — slice มีอะไรบ้าง, แต่ละ slice ตัดผ่าน layer ไหน, data model, interface/contract, flow, ผลกระทบต่อระบบเดิม (ใช้ lens `warnyin/workflow/roles/sa.md`)
 6. **Review panel (optional — ถาม user ก่อน):** เสนอ user ว่าจะให้ panel หลาย role รีวิว design ก่อนแตก task ไหม — ถ้า ok:
-   1. fan-out sub-agent reviewer **ขนาน (read-only)** ตาม role card: **SA** (architecture/data model/contract), **Tech Lead** (feasibility/ขนาด task/dependency), **QA** (testability/acceptance), **Security** (ช่องโหว่/ข้อมูลอ่อนไหว), **Infra** (env/config/migration) — แต่ละตัวอ่าน `proposal.md` + `design.md` + โค้ดจริงที่เกี่ยว แล้วให้ความเห็นตาม checklist ใน `workflow/roles/<role>.md` แบ่งเป็น **blocker / suggestion**
+   1. fan-out sub-agent reviewer **ขนาน (read-only)** ตาม role card: **SA** (architecture/data model/contract), **Tech Lead** (feasibility/ขนาด task/dependency), **QA** (testability/acceptance), **Security** (ช่องโหว่/ข้อมูลอ่อนไหว), **Infra** (env/config/migration) — แต่ละตัวอ่าน `proposal.md` + `design.md` + โค้ดจริงที่เกี่ยว แล้วให้ความเห็นตาม checklist ใน `warnyin/workflow/roles/<role>.md` แบ่งเป็น **blocker / suggestion**
    2. รวมความเห็นทุก role → สรุปให้ user เห็นภาพ
    3. **blocker → แก้ design ให้ครบ** โดยห้ามเดา — ติดจริงถาม user ทีละข้อ + เสนอคำตอบแนะนำ; suggestion → พิจารณา/บันทึกเหตุผลถ้าไม่ทำ
    4. บันทึกสรุปผล panel + สิ่งที่แก้ ลงท้าย `design.md` (section "Design review")
    5. เครื่องที่ fan-out ไม่ได้ → รีวิวทีละ role ด้วย checklist เดียวกัน
 7. **แตก tasks:** แปลง design เป็น task (= vertical slice / step ที่แก้); task ซับซ้อน → แตก **sub-task** ย่อย; เขียน **dependency graph / ลำดับ** ให้ sub-task เชื่อมกัน
 8. **rule check ต่อ task:** เปิด `docs/techstack/<component>/rule.md` หา rule ที่ task นี้ต้องโฟกัส → ใส่ใน `tasks/<task>/rule.md`; rule ใหม่ที่อยากเพิ่ม → note ใน section "เสนอเพิ่ม (รอ SHIP)"
-9. **เช็ค Gate (ข้อ 8)** → เมื่อผ่าน จึง **เขียนไฟล์ task ครบทุกใบ** (แตก task ด้วย lens `workflow/roles/tech-lead.md`)
+9. **เช็ค Gate (ข้อ 8)** → เมื่อผ่าน จึง **เขียนไฟล์ task ครบทุกใบ** (แตก task ด้วย lens `warnyin/workflow/roles/tech-lead.md`)
 10. **Dry-run (optional — ถาม user ก่อน):** ถาม user ว่าต้องการ dry-run ทั้งหมดเพื่อหาจุดบกพร่องก่อนเข้า BUILD ไหม — ถ้า ok:
    1. **fan-out agent หนึ่งตัวต่อหนึ่ง task แบบขนาน (read-only — ห้ามแก้โค้ด/ไฟล์ design)** — แต่ละตัวอ่าน task ทั้ง 4 ไฟล์ + `design.md`/`proposal.md` + โค้ดจริงที่เกี่ยว แล้ว "เดิน implement ในหัว" เพื่อหา:
       - **blocker** — สิ่งที่ทำให้ implement ตาม spec ไม่ได้ (ขัดแย้งกับโค้ดจริง/กับ task อื่น, ข้อมูล/spec ขาด, dependency ผิด) — BUILD จะล้มถ้าไม่แก้
       - **defer** — จุดที่ตัดสินใจ/ทำทีหลังได้ ไม่ block การเริ่ม BUILD แต่ต้องบันทึกและ track
-   2. task ไหนพบ issue → เขียน `tasks/<task>/issue.md` (template `[topic]/tasks/[task-name]/issue.md`); ไม่พบ → ไม่ต้องสร้างไฟล์
+   2. task ไหนพบ issue → เขียน `tasks/<task>/issue.md` (template `warnyin/template/stages/[topic]/tasks/[task-name]/issue.md`); ไม่พบ → ไม่ต้องสร้างไฟล์
    3. รันครบทุก task แล้ว → **สรุปผลรวม** (จำนวน blocker/defer ต่อ task) ให้ user เห็นภาพ
    4. **หาวิธีแก้ DESIGN ตาม issue** (แก้ `design.md` / task ที่กระทบ) โดย **ห้ามเดา ห้ามคิดขึ้นเอง** — ติดจริงๆ ให้สัมภาษณ์ user **ถามทีละข้อ + เสนอคำตอบแนะนำทุกครั้ง**; คำถามที่โค้ดตอบได้ → ไปอ่านโค้ดเอง
    5. แก้แล้ว rerun dry-run เฉพาะ task ที่กระทบ วนจน **ไม่มี blocker ค้าง** (อัปเดตสถานะใน `issue.md` — defer ที่เหลือให้ user รับทราบ)
@@ -70,18 +70,18 @@
 
 ---
 
-## 5. Output (สร้างที่ `warnyin-stages/<slug>/`)
+## 5. Output (สร้างที่ `warnyin/stages/<slug>/`)
 
 | ไฟล์ | เนื้อหา | optional? | template |
 |---|---|---|---|
-| `business.md` | what & why เชิงธุรกิจ (goal, persona, success metric) | ✅ ข้ามได้ถ้า change เล็ก | `[topic]/business.md` |
-| `proposal.md` | what & why ของ change + ทางเลือก + scope | จำเป็น | `[topic]/proposal.md` |
-| `design.md` | how — vertical slice, data model, contract, flow | จำเป็น | `[topic]/design.md` |
-| `tasks/<task-name>/spec.md` | spec เฉพาะ task (ดูข้อ 6) | จำเป็นต่อ task | `[topic]/tasks/[task-name]/spec.md` |
-| `tasks/<task-name>/standard.md` | pattern โค้ด/shared component อิง techstack standard | จำเป็นต่อ task | `[topic]/tasks/[task-name]/standard.md` |
-| `tasks/<task-name>/rule.md` | rule ที่ต้อง follow + rule ที่เสนอเพิ่ม (รอ SHIP) | จำเป็นต่อ task | `[topic]/tasks/[task-name]/rule.md` |
-| `tasks/<task-name>/task.md` | รายละเอียด task + sub-tasks + dependency + acceptance | จำเป็นต่อ task | `[topic]/tasks/[task-name]/task.md` |
-| `tasks/<task-name>/issue.md` | ผล dry-run: defer/blocker ที่พบ + แนวทางแก้ + สถานะ | ✅ เฉพาะเมื่อ dry-run แล้วพบ issue | `[topic]/tasks/[task-name]/issue.md` |
+| `business.md` | what & why เชิงธุรกิจ (goal, persona, success metric) | ✅ ข้ามได้ถ้า change เล็ก | `warnyin/template/stages/[topic]/business.md` |
+| `proposal.md` | what & why ของ change + ทางเลือก + scope | จำเป็น | `warnyin/template/stages/[topic]/proposal.md` |
+| `design.md` | how — vertical slice, data model, contract, flow | จำเป็น | `warnyin/template/stages/[topic]/design.md` |
+| `tasks/<task-name>/spec.md` | spec เฉพาะ task (ดูข้อ 6) | จำเป็นต่อ task | `warnyin/template/stages/[topic]/tasks/[task-name]/spec.md` |
+| `tasks/<task-name>/standard.md` | pattern โค้ด/shared component อิง techstack standard | จำเป็นต่อ task | `warnyin/template/stages/[topic]/tasks/[task-name]/standard.md` |
+| `tasks/<task-name>/rule.md` | rule ที่ต้อง follow + rule ที่เสนอเพิ่ม (รอ SHIP) | จำเป็นต่อ task | `warnyin/template/stages/[topic]/tasks/[task-name]/rule.md` |
+| `tasks/<task-name>/task.md` | รายละเอียด task + sub-tasks + dependency + acceptance | จำเป็นต่อ task | `warnyin/template/stages/[topic]/tasks/[task-name]/task.md` |
+| `tasks/<task-name>/issue.md` | ผล dry-run: defer/blocker ที่พบ + แนวทางแก้ + สถานะ | ✅ เฉพาะเมื่อ dry-run แล้วพบ issue | `warnyin/template/stages/[topic]/tasks/[task-name]/issue.md` |
 
 ---
 

package/{workflow → warnyin/workflow}/stages/discovery.md

@@ -23,7 +23,7 @@ Discovery คือขั้นตอน **ค้นหาข้อมูล + d
 2. `docs/rule.md`, `docs/infra.md` — กฎและโครงสร้างพื้นฐาน
 3. `docs/codemap/index.md` — แผนที่โค้ด (ไปอ่านโค้ดจริงต่อได้)
 4. `docs/features/*`, `docs/techstack/*` — ฟีเจอร์เดิม + tech stack ของแต่ละ component
-5. `warnyin-stages/context.md` และ topic ที่ `achieved/` ที่ใกล้เคียง — เคยทำอะไรไปแล้ว
+5. `warnyin/stages/context.md` และ topic ที่ `achieved/` ที่ใกล้เคียง — เคยทำอะไรไปแล้ว
 
 ---
 
@@ -36,7 +36,7 @@ Discovery คือขั้นตอน **ค้นหาข้อมูล + d
 5. **เดินทีละกิ่งของ decision tree:** ไล่ทุกแขนงของการตัดสินใจ แก้ความสัมพันธ์ระหว่างการตัดสินใจทีละจุด ไม่ข้าม
 6. **บันทึกทันทีที่ตกลงได้:** พอได้ข้อสรุปที่ชัดเจนในประเด็นไหน ให้จดลง `discovery.md` (decision log) เลย ไม่รอจบ
 7. **ทุกข้อสรุปต้องสอดคล้องกับโปรเจกต์:** อ้างอิงกลับไปที่ `docs/project.md` และข้อจำกัดจริงเสมอ
-8. **ใช้ role lens ตอนตั้งคำถาม:** มอง scope ผ่าน checklist ของ **BA** (`workflow/roles/ba.md` — business process, ข้อยกเว้น, ข้อมูล, ข้อจำกัด) และ **PO** (`workflow/roles/po.md` — คุณค่า, priority, MVP, scope out, success metric) เพื่อให้คำถามครบมุมไม่หลุดประเด็น
+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 → **ซักถามอย่างไม่หยุดหย่อนทุกแง่มุมของแผน** จนเข้าใจตรงกัน:
@@ -46,7 +46,7 @@ Discovery คือขั้นตอน **ค้นหาข้อมูล + d
 
 ## 4. ลำดับขั้นการทำงาน (process loop)
 
-1. **เตรียมพื้นที่:** ถ้ายังไม่มีโฟลเดอร์ topic → copy `warnyin-stages/[topic]/` เป็น `warnyin-stages/<slug>/` (slug = kebab-case ของหัวข้องาน)
+1. **เตรียมพื้นที่:** ถ้ายังไม่มีโฟลเดอร์ topic → copy `warnyin/template/stages/[topic]/` เป็น `warnyin/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
@@ -54,14 +54,14 @@ Discovery คือขั้นตอน **ค้นหาข้อมูล + d
 
 ---
 
-## 5. Output (สร้างที่ `warnyin-stages/<slug>/`)
+## 5. Output (สร้างที่ `warnyin/stages/<slug>/`)
 
 | ไฟล์ | เนื้อหา | template |
 |---|---|---|
-| `discovery.md` | decision log + shared understanding + scope + PRD ย่อ + feature ideas | `warnyin-stages/[topic]/discovery.md` |
-| `research.md` | คำถามวิจัย + วิธี/แหล่ง + findings + code inspection + implication | `warnyin-stages/[topic]/research.md` |
+| `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 (ไฟล์ใน `[topic]/`) เป็นโครง แล้วเติมเนื้อหาจริง อัปเดตทุกครั้งที่ได้ข้อสรุปใหม่
+> เริ่มจาก template (ไฟล์ใน `warnyin/template/stages/[topic]/`) เป็นโครง แล้วเติมเนื้อหาจริง อัปเดตทุกครั้งที่ได้ข้อสรุปใหม่
 
 ---
 

package/{workflow → warnyin/workflow}/stages/ship.md

@@ -1,7 +1,7 @@
 # Stage: SHIP
 
 > **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
-> เป้าหมาย: **ส่งมอบ** — promote ความรู้ระดับ topic ขึ้นเอกสารกลางใน `docs/` + archive topic เข้า `warnyin-stages/achieved/`
+> เป้าหมาย: **ส่งมอบ** — promote ความรู้ระดับ topic ขึ้นเอกสารกลางใน `docs/` + archive topic เข้า `warnyin/stages/achieved/`
 
 ---
 
@@ -17,7 +17,7 @@
 
 ## 2. Input ที่ต้องอ่านก่อนเริ่ม
 
-1. `warnyin-stages/<slug>/` **ทุกไฟล์** — discovery, business, proposal, design, build, test, verify, troubleshooting, tasks/*
+1. `warnyin/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`,
@@ -30,7 +30,7 @@
 
 1. **เข้าใจก่อน promote** — อ่าน topic ทั้งหมดให้เข้าใจว่าทำอะไร/ทำอย่างไร แล้วค่อยตัดสินใจว่าความรู้ชิ้นไหนควรขึ้นไฟล์กลางไหน
 2. **ขอ user ยืนยัน "ครั้งเดียวก่อนลงมือ"** — สรุป promotion plan (feature ใหม่หรือปรับปรุง, ไฟล์กลางที่จะอัปเดต + สาระที่จะใส่, ชื่อโฟลเดอร์ archive) ให้ user อนุมัติ แล้วจึง execute ไม่ถามซ้ำระหว่างทาง
-3. **★ Archive ก่อนอัปเดตเอกสาร** — ย้ายทั้งโฟลเดอร์ `warnyin-stages/<slug>/` → `warnyin-stages/achieved/<YYYY-MM-DD>-<slug>/` (วันที่ของวันที่ SHIP) **ก่อน** เริ่มแก้ `docs/` แล้วอ่านเนื้อหาจาก path ใหม่ระหว่าง promote
+3. **★ Archive ก่อนอัปเดตเอกสาร** — ย้ายทั้งโฟลเดอร์ `warnyin/stages/<slug>/` → `warnyin/stages/achieved/<YYYY-MM-DD>-<slug>/` (วันที่ของวันที่ SHIP) **ก่อน** เริ่มแก้ `docs/` แล้วอ่านเนื้อหาจาก path ใหม่ระหว่าง promote
 4. **กลั่น ไม่ใช่ copy ดิบ** — merge สาระเข้าโครงสร้างของไฟล์กลางเดิม ระวัง duplicate/ขัดแย้งกับเนื้อหาที่มีอยู่; เขียนแบบ "ความรู้ถาวร" ไม่ใช่บันทึกรายงาน
 5. **เอกสารต้องตรงโค้ดจริง** — structure/codemap อัปเดตจากการดูโค้ดจริง ไม่ใช่จากความจำหรือ design เดิม
 6. **อย่าเดา** — เนื้อหาที่ไม่แน่ใจว่าควร promote หรือควรวางไว้ไฟล์ไหน → ถามทีละข้อ + เสนอคำตอบที่แนะนำ
@@ -40,17 +40,17 @@
 
 ## 4. ลำดับขั้นการทำงาน (process)
 
-1. **อ่านทำความเข้าใจ topic:** อ่าน `warnyin-stages/<slug>/` ทุกไฟล์ — topic นี้ทำอะไร ทำอย่างไร เกิดความรู้ใหม่อะไรบ้าง (เช็คก่อนว่า VERIFY ผ่าน Gate แล้ว — มี `verify.md` สรุปผลผ่าน)
+1. **อ่านทำความเข้าใจ topic:** อ่าน `warnyin/stages/<slug>/` ทุกไฟล์ — topic นี้ทำอะไร ทำอย่างไร เกิดความรู้ใหม่อะไรบ้าง (เช็คก่อนว่า VERIFY ผ่าน Gate แล้ว — มี `verify.md` สรุปผลผ่าน)
 2. **จำแนก feature:** สิ่งที่ทำเป็น **feature ใหม่** หรือ **ปรับปรุง feature เดิม** (เทียบกับ `docs/features/` ที่มีอยู่)
 3. **สรุป promotion plan + ขออนุมัติ (ครั้งเดียว):** feature ใหม่/ปรับปรุง, รายการไฟล์กลางที่จะอัปเดต + สาระ, ชื่อโฟลเดอร์ archive → รอ user ไฟเขียว
-4. **★ Archive:** ย้ายทั้งโฟลเดอร์ → `warnyin-stages/achieved/<YYYY-MM-DD>-<slug>/` (ใช้ `git mv` ถ้าเป็น git repo)
+4. **★ Archive:** ย้ายทั้งโฟลเดอร์ → `warnyin/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
    2. **`docs/techstack/<component>/`** — `rule.md` / `standard.md` (จาก note "รอ SHIP" ใน tasks), `structure.md` (โครงสร้างที่เปลี่ยน), `test.md` (merge แผนเทสจาก `test.md` ของ topic)
    3. **`docs/rule.md`** — global rule ใหม่/ที่เปลี่ยน (เฉพาะข้อที่เป็นกฎระดับโปรเจกต์ ไม่ผูกกับ component เดียว)
    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 ให้ตรงกับโค้ดจริงปัจจุบัน (ตรวจจากโค้ดจริง อย่างน้อยทุกส่วนที่ change กระทบ)
+   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 ปิดสมบูรณ์
 
@@ -66,13 +66,13 @@
 | `docs/troubleshooting.md` | KB ปัญหา-วิธีแก้ที่ merge เข้า |
 | `docs/infra.md`, `docs/project.md` | อัปเดตเฉพาะถ้ามีข้อมูลเกี่ยวข้อง |
 | `docs/codemap/` | code map ตรงกับโค้ดจริงปัจจุบัน |
-| `warnyin-stages/achieved/<YYYY-MM-DD>-<slug>/` | ทั้ง topic ที่ archive แล้ว + `ship.md` (สรุปการส่งมอบ) |
+| `warnyin/stages/achieved/<YYYY-MM-DD>-<slug>/` | ทั้ง topic ที่ archive แล้ว + `ship.md` (สรุปการส่งมอบ) |
 
 ---
 
 ## 6. Gate → topic ปิดสมบูรณ์เมื่อ
 
-- [ ] topic ถูกย้ายไป `warnyin-stages/achieved/<YYYY-MM-DD>-<slug>/` แล้ว (ไม่เหลือใน `warnyin-stages/`)
+- [ ] topic ถูกย้ายไป `warnyin/stages/achieved/<YYYY-MM-DD>-<slug>/` แล้ว (ไม่เหลือใน `warnyin/stages/`)
 - [ ] `docs/features/` สะท้อน feature ใหม่/ที่ปรับปรุงแล้ว
 - [ ] note "รอ SHIP" ทุกข้อใน `tasks/*/rule.md` + `standard.md` ถูกพิจารณาครบ — promote หรือตัดทิ้งพร้อมเหตุผล
 - [ ] `docs/troubleshooting.md` รวม entry จาก topic แล้ว

package/{workflow → warnyin/workflow}/stages/verify.md

@@ -14,7 +14,7 @@
 
 ## 2. ก่อนเทส — อ่านให้เข้าใจก่อนเสมอ
 
-1. **spec + tasks ทั้งหมด** — `warnyin-stages/<slug>/tasks/*/spec.md` + `task.md`, `design.md`, `proposal.md`
+1. **spec + tasks ทั้งหมด** — `warnyin/stages/<slug>/tasks/*/spec.md` + `task.md`, `design.md`, `proposal.md`
    → เข้าใจ **จุดประสงค์ของ topic** และสิ่งที่ต้องยืนยัน (อย่าเทสผ่านๆ โดยไม่เข้าใจ)
 2. **`docs/techstack/<component>/test.md`** — guideline ว่าเทสยังไง (เช่น frontend: e2e smoke ผ่าน **playwright-cli**)
    → ถ้า **ไม่มี** guideline → แนะนำว่าควรเทสแบบไหน/วิธีใดได้บ้าง แล้วเขียนแผนลง `test.md`
@@ -30,16 +30,16 @@
 3. **ใช้ guideline จาก `test.md`** ของ techstack; ถ้าไม่มีให้เสนอวิธีเทสที่เหมาะแล้วเขียนแผนเอง
 4. **Frontend → verify UX/UI ด้วย** (ไม่ใช่แค่ functional — ดู layout, state, flow, ความถูกต้องของหน้าจอ)
 5. **ข้อไหน verify ไม่ผ่าน → แก้จนผ่าน (loop)** และ **นับจำนวนการแก้ไข/จำนวนรอบ**
-6. **ปัญหายาก/ซ้ำในขั้นนี้ → บันทึก `warnyin-stages/<slug>/troubleshooting.md`** (เหมือน BUILD); เจอปัญหา → อ่าน `docs/troubleshooting.md` ก่อน
+6. **ปัญหายาก/ซ้ำในขั้นนี้ → บันทึก `warnyin/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 `workflow/roles/qa.md` (lens: คิดแบบผู้ใช้จริง + คนหาเรื่อง, edge case, regression; checklist ครบทุกข้อ)
+9. **สวม role QA** — ทำตาม role card `warnyin/workflow/roles/qa.md` (lens: คิดแบบผู้ใช้จริง + คนหาเรื่อง, edge case, regression; checklist ครบทุกข้อ)
 
 ---
 
 ## 4. ลำดับขั้นการทำงาน (process)
 
-0. **★ เช็ค context window ก่อนเริ่ม:** ประเมินว่า context ของ session ปัจจุบันถูกใช้ไปมากน้อยแค่ไหน — ถ้าใช้ไปเยอะหรือ **เกินครึ่ง** → **เสนอ user ให้ `/compact` หรือ `/clear` ก่อนเสมอ** แล้วค่อยเริ่ม VERIFY ใน context ที่โล่ง (สถานะงานอยู่ในไฟล์ `warnyin-stages/<slug>/` ครบ ไม่หายไปกับ context) — VERIFY เป็นลูปเทส-แก้ที่อาจยาว ต้องมี context เหลือมากพอ; เครื่องอื่นที่ไม่มีคำสั่งนี้ → แนะนำเริ่ม session ใหม่
+0. **★ เช็ค context window ก่อนเริ่ม:** ประเมินว่า context ของ session ปัจจุบันถูกใช้ไปมากน้อยแค่ไหน — ถ้าใช้ไปเยอะหรือ **เกินครึ่ง** → **เสนอ user ให้ `/compact` หรือ `/clear` ก่อนเสมอ** แล้วค่อยเริ่ม VERIFY ใน context ที่โล่ง (สถานะงานอยู่ในไฟล์ `warnyin/stages/<slug>/` ครบ ไม่หายไปกับ context) — VERIFY เป็นลูปเทส-แก้ที่อาจยาว ต้องมี context เหลือมากพอ; เครื่องอื่นที่ไม่มีคำสั่งนี้ → แนะนำเริ่ม session ใหม่
 1. **เข้าใจจุดประสงค์:** อ่าน spec/tasks/design → สรุปสิ่งที่ต้อง verify (functional + UX/UI)
 2. **วางแผนเทส → เขียน `test.md`:** ตาม guideline `docs/techstack/<component>/test.md`; ไม่มีก็เสนอวิธี (e2e smoke / integration / manual ฯลฯ) แล้วเขียนแผน
 3. **เตรียม local env:** รัน service ที่เกี่ยวข้องตาม `infra.md`
@@ -50,7 +50,7 @@
 
 ---
 
-## 5. Output (สร้างที่ `warnyin-stages/<slug>/`)
+## 5. Output (สร้างที่ `warnyin/stages/<slug>/`)
 
 | ไฟล์ | เนื้อหา | ปลายทางตอน SHIP |
 |---|---|---|