@warnyin/agents 0.4.0 → 0.5.1

package/.claude/commands/warnyin/build.md

@@ -1,29 +1,29 @@
----
-description: รัน BUILD stage — fan-out sub-agent ต่อ task ตาม dependency (Workflow + worktree) แล้ว integrate
-argument-hint: "[slug ของ topic]"
----
-
-ทำหน้าที่เป็น BUILD orchestrator ตาม **playbook กลาง** ของ workflow มาตรฐาน
-
-0. **★ เช็ค context window ก่อนเริ่ม:** ถ้า context ของ session ถูกใช้ไปเยอะหรือ**เกินครึ่ง** → เสนอ user ให้ `/compact` หรือ `/clear` ก่อนเสมอ แล้วค่อยรัน `/warnyin:build <slug>` ใหม่ใน context ที่โล่ง (สถานะงานอยู่ในไฟล์ `warnyin/stages/<slug>/` ครบ) — อย่าเริ่ม fan-out ทั้งที่ context ใกล้เต็ม
-1. อ่าน `warnyin/workflow/stages/build.md` ให้ครบก่อน แล้วทำตามทุกหลักการอย่างเคร่งครัด
-2. slug: $ARGUMENTS — ถ้าไม่ระบุให้ถามก่อน ว่าจะ build topic ไหน (ดูโฟลเดอร์ใน `warnyin/stages/`)
-3. **อ่าน task ทั้งหมด** ใน `warnyin/stages/<slug>/tasks/*/task.md` + `design.md` → ดึง dependency → สร้าง DAG → จัด **wave** ด้วย topological order
-4. **Pre-check:** target เป็น git repo ไหม (จำเป็นสำหรับ worktree isolation) — ถ้าไม่ใช่ → fallback sequential shared-tree (`isolate:false`) และแจ้ง user. สร้าง build branch ใหม่ก่อนเริ่ม
-5. **ขออนุมัติครั้งเดียว** — ใช้ AskUserQuestion แสดง execution plan: แต่ละ wave มี task อะไร, อันไหน parallel, isolation mode, build branch → รอ go/no-go (อย่าเริ่มก่อนได้ไฟเขียว)
-6. **เดินทีละ wave** (หลังอนุมัติ):
-   - เรียก **Workflow** ด้วย `{ scriptPath: "warnyin/workflow/scripts/build-wave.mjs", args: { slug, tasks: [<task ใน wave นี้>], isolate } }`
-   - เมื่อ workflow คืนผล: ถ้า `isolate` → **merge** branch ที่แต่ละ agent รายงาน (`result.branch`) เข้า build branch ทีละอัน, แก้ conflict ถ้ามี; ถ้า shared-tree → review + commit ให้
-   - ถ้ามี task `failed` หรือ `skipped` → **หยุด** รายงาน user ก่อนไป wave ถัดไป
-   - **รวม troubleshooting:** ดึงฟิลด์ `troubleshooting` จากผลของทุก agent ในรอบนี้ → เขียนรวมลง `warnyin/stages/<slug>/troubleshooting.md` (main loop เขียนเอง กันไฟล์ชนกันใน worktree)
-7. **★ Full build & test gate (หลัง merge ทุก wave):** บน build branch ที่ integrate แล้ว รัน build ทั้งหมด + test suite ทั้งหมด (รวม unit test) ของทุก component ที่กระทบ
-   - **เจอ error → อ่าน `docs/troubleshooting.md` ก่อน** เผื่อเคยแก้แล้ว
-   - มี build error / test แดง → **แก้จนเขียวหมด (loop)**: วิเคราะห์ error, แก้ (จะ delegate fix ให้ sub-agent ทีละจุดก็ได้), rerun build/test ใหม่ ทำซ้ำจนผ่าน
-   - ปัญหา **ยาก/เจอซ้ำ** ที่แก้สำเร็จในรอบนี้ → บันทึกลง `warnyin/stages/<slug>/troubleshooting.md`
-   - ห้ามปิด BUILD ถ้ายังแดง; ถ้าวนหลายรอบยังไม่ผ่าน → หยุด รายงาน user พร้อม error log
-8. **ปิดงาน:** เขียน `warnyin/stages/<slug>/build.md` (ผลต่อ task + ผล full build/test + integration notes), อัปเดตสถานะใน `task.md` แต่ละใบ → เสนอเข้า VERIFY ด้วย `/warnyin:verify`
-
-หมายเหตุ:
-- ห้ามแก้ rule/standard กลางใน `docs/` (rule ใหม่ที่เสนอถูก note ไว้ใน `tasks/<task>/rule.md` รอ SHIP)
-- ปัญหายาก/ซ้ำที่แก้ได้ → `warnyin/stages/<slug>/troubleshooting.md` (SHIP จะยกขึ้น `docs/troubleshooting.md`)
-- เกณฑ์ปิด BUILD ดู Gate ข้อ 7 ของ playbook
+---
+description: รัน BUILD stage — fan-out sub-agent ต่อ task ตาม dependency (Workflow + worktree) แล้ว integrate
+argument-hint: "[slug ของ topic]"
+---
+
+ทำหน้าที่เป็น BUILD orchestrator ตาม **playbook กลาง** ของ workflow มาตรฐาน
+
+0. **★ เช็ค context window ก่อนเริ่ม:** ถ้า context ของ session ถูกใช้ไปเยอะหรือ**เกินครึ่ง** → เสนอ user ให้ `/compact` หรือ `/clear` ก่อนเสมอ แล้วค่อยรัน `/warnyin:build <slug>` ใหม่ใน context ที่โล่ง (สถานะงานอยู่ในไฟล์ `warnyin/stages/<slug>/` ครบ) — อย่าเริ่ม fan-out ทั้งที่ context ใกล้เต็ม
+1. อ่าน `warnyin/workflow/stages/build.md` ให้ครบก่อน แล้วทำตามทุกหลักการอย่างเคร่งครัด
+2. slug: $ARGUMENTS — ถ้าไม่ระบุให้ถามก่อน ว่าจะ build topic ไหน (ดูโฟลเดอร์ใน `warnyin/stages/`)
+3. **อ่าน task ทั้งหมด** ใน `warnyin/stages/<slug>/tasks/*/task.md` + `design.md` → ดึง dependency → สร้าง DAG → จัด **wave** ด้วย topological order
+4. **Pre-check:** target เป็น git repo ไหม (จำเป็นสำหรับ worktree isolation) — ถ้าไม่ใช่ → fallback sequential shared-tree (`isolate:false`) และแจ้ง user. สร้าง build branch ใหม่ก่อนเริ่ม
+5. **ขออนุมัติครั้งเดียว** — ใช้ AskUserQuestion แสดง execution plan: แต่ละ wave มี task อะไร, อันไหน parallel, isolation mode, build branch → รอ go/no-go (อย่าเริ่มก่อนได้ไฟเขียว)
+6. **เดินทีละ wave** (หลังอนุมัติ):
+   - เรียก **Workflow** ด้วย `{ scriptPath: "warnyin/workflow/scripts/build-wave.mjs", args: { slug, tasks: [<task ใน wave นี้>], isolate } }`
+   - เมื่อ workflow คืนผล: ถ้า `isolate` → **merge** branch ที่แต่ละ agent รายงาน (`result.branch`) เข้า build branch ทีละอัน, แก้ conflict ถ้ามี; ถ้า shared-tree → review + commit ให้
+   - ถ้ามี task `failed` หรือ `skipped` → **หยุด** รายงาน user ก่อนไป wave ถัดไป
+   - **รวม troubleshooting:** ดึงฟิลด์ `troubleshooting` จากผลของทุก agent ในรอบนี้ → เขียนรวมลง `warnyin/stages/<slug>/troubleshooting.md` (main loop เขียนเอง กันไฟล์ชนกันใน worktree)
+7. **★ Full build & test gate (หลัง merge ทุก wave):** บน build branch ที่ integrate แล้ว รัน build ทั้งหมด + test suite ทั้งหมด (รวม unit test) ของทุก component ที่กระทบ
+   - **เจอ error → อ่าน `docs/troubleshooting.md` ก่อน** เผื่อเคยแก้แล้ว
+   - มี build error / test แดง → **แก้จนเขียวหมด (loop)**: วิเคราะห์ error, แก้ (จะ delegate fix ให้ sub-agent ทีละจุดก็ได้), rerun build/test ใหม่ ทำซ้ำจนผ่าน
+   - ปัญหา **ยาก/เจอซ้ำ** ที่แก้สำเร็จในรอบนี้ → บันทึกลง `warnyin/stages/<slug>/troubleshooting.md`
+   - ห้ามปิด BUILD ถ้ายังแดง; ถ้าวนหลายรอบยังไม่ผ่าน → หยุด รายงาน user พร้อม error log
+8. **ปิดงาน:** เขียน `warnyin/stages/<slug>/build.md` (ผลต่อ task + ผล full build/test + integration notes), อัปเดตสถานะใน `task.md` แต่ละใบ → เสนอเข้า VERIFY ด้วย `/warnyin:verify`
+
+หมายเหตุ:
+- ห้ามแก้ rule/standard กลางใน `docs/` (rule ใหม่ที่เสนอถูก note ไว้ใน `tasks/<task>/rule.md` รอ SHIP)
+- ปัญหายาก/ซ้ำที่แก้ได้ → `warnyin/stages/<slug>/troubleshooting.md` (SHIP จะยกขึ้น `docs/troubleshooting.md`)
+- เกณฑ์ปิด BUILD ดู Gate ข้อ 7 ของ playbook

package/.claude/commands/warnyin/design.md

@@ -1,24 +1,24 @@
----
-description: รัน DESIGN stage — เสนอ change พร้อมผลิต proposal/design/tasks ครบในขั้นเดียว
-argument-hint: "[slug ของ topic] [อธิบาย change สั้นๆ]"
----
-
-ทำหน้าที่เป็น DESIGN architect ตาม **playbook กลาง** ของ workflow มาตรฐาน
-
-1. อ่าน `warnyin/workflow/stages/design.md` ให้ครบก่อน แล้วทำตามทุกหลักการอย่างเคร่งครัด
-   - **ห้ามเดาเอง** — ไม่ชัดให้ถามทีละข้อ + เสนอคำตอบที่แนะนำทุกข้อ
-   - ออกแบบแบบ **vertical slice architecture**
-   - **Gate ก่อนเขียนไฟล์ task** แล้วค่อยโยนให้ sub-agent
-2. อ่าน Input ตามข้อ 2 ของ playbook — โดยเฉพาะ `docs/techstack/<component>/rule.md` และ `standard.md`
-3. งาน: $ARGUMENTS
-   - ระบุ slug → ใช้/สร้าง `warnyin/stages/<slug>/` (ถ้ามาจาก Discovery ใช้โฟลเดอร์เดิม)
-   - ถ้าเป็นคำถาม/ยังไม่มั่นใจเรื่อง design → แนะนำ `/warnyin:discovery` ก่อน
-4. ผลิต artifact โดยใช้ template ใน `warnyin/template/stages/[topic]/` เป็นโครง: `business.md` (ข้ามได้ถ้า change เล็ก), `proposal.md`, `design.md` (lens `warnyin/workflow/roles/sa.md`), แล้วแตก `tasks/<task-name>/` (lens `warnyin/workflow/roles/tech-lead.md`) แต่ละใบมี `spec.md` `standard.md` `rule.md` `task.md`
-   - **Review panel (ถาม user ก่อน):** หลัง `design.md` เสร็จ ก่อนแตก task — ใช้ AskUserQuestion ถามว่าจะให้ panel รีวิวไหม ถ้า ok → fan-out subagent `warnyin-sa`, `warnyin-tech-lead`, `warnyin-qa`, `warnyin-security`, `warnyin-infra` (Agent tool, ขนาน, read-only) รีวิว proposal+design → รวมความเห็น สรุปให้ user → แก้ blocker ให้ครบ (ห้ามเดา) → บันทึก section "Design review" ท้าย `design.md`
-5. ตอน generate ไฟล์ task หลายใบ สามารถใช้ sub-agent (Task/Agent tool) fan-out หนึ่ง agent ต่อหนึ่ง task ได้ — **แต่ต้องผ่าน Gate (ข้อ 8 ของ playbook) ก่อน**
-6. **Dry-run (ถาม user ก่อนเสมอ):** หลังเขียนไฟล์ task ครบ ใช้ AskUserQuestion ถามว่าต้องการ dry-run ทั้งหมดเพื่อหาจุดบกพร่องก่อนเข้า BUILD ไหม — ถ้า ok ทำตามข้อ 4.9 ของ playbook:
-   - fan-out agent (Agent tool) **หนึ่งตัวต่อหนึ่ง task แบบขนาน, read-only** — อ่าน task ทั้ง 4 ไฟล์ + design/proposal + โค้ดจริงที่เกี่ยว เดิน implement ในหัว หา **blocker** (implement ตาม spec ไม่ได้ — ต้องแก้ก่อน BUILD) และ **defer** (ทำ/ตัดสินใจทีหลังได้ แต่ต้อง track)
-   - task ที่พบ issue → เขียน `warnyin/stages/<slug>/tasks/<task>/issue.md` (ตาม template); รันครบทุก task → **สรุปผลรวม** ให้ user
-   - **หาวิธีแก้ DESIGN ตาม issue โดยห้ามเดา ห้ามคิดขึ้นเอง** — ติดจริงๆ → สัมภาษณ์ user ทีละข้อ + เสนอคำตอบแนะนำทุกครั้ง; คำถามที่โค้ดตอบได้ → ไปอ่านโค้ดเอง
-   - แก้แล้ว rerun dry-run เฉพาะ task ที่กระทบ วนจน **ไม่มี blocker ค้าง**
-7. เมื่อพร้อม implement → บอกให้รัน `/warnyin:build`
+---
+description: รัน DESIGN stage — เสนอ change พร้อมผลิต proposal/design/tasks ครบในขั้นเดียว
+argument-hint: "[slug ของ topic] [อธิบาย change สั้นๆ]"
+---
+
+ทำหน้าที่เป็น DESIGN architect ตาม **playbook กลาง** ของ workflow มาตรฐาน
+
+1. อ่าน `warnyin/workflow/stages/design.md` ให้ครบก่อน แล้วทำตามทุกหลักการอย่างเคร่งครัด
+   - **ห้ามเดาเอง** — ไม่ชัดให้ถามทีละข้อ + เสนอคำตอบที่แนะนำทุกข้อ
+   - ออกแบบแบบ **vertical slice architecture**
+   - **Gate ก่อนเขียนไฟล์ task** แล้วค่อยโยนให้ sub-agent
+2. อ่าน Input ตามข้อ 2 ของ playbook — โดยเฉพาะ `docs/techstack/<component>/rule.md` และ `standard.md`
+3. งาน: $ARGUMENTS
+   - ระบุ slug → ใช้/สร้าง `warnyin/stages/<slug>/` (ถ้ามาจาก Discovery ใช้โฟลเดอร์เดิม)
+   - ถ้าเป็นคำถาม/ยังไม่มั่นใจเรื่อง design → แนะนำ `/warnyin:discovery` ก่อน
+4. ผลิต artifact โดยใช้ template ใน `warnyin/template/stages/[topic]/` เป็นโครง: `business.md` (ข้ามได้ถ้า change เล็ก), `proposal.md`, `design.md` (lens `warnyin/workflow/roles/sa.md`), แล้วแตก `tasks/<task-name>/` (lens `warnyin/workflow/roles/tech-lead.md`) แต่ละใบมี `spec.md` `standard.md` `rule.md` `task.md`
+   - **Review panel (ถาม user ก่อน):** หลัง `design.md` เสร็จ ก่อนแตก task — ใช้ AskUserQuestion ถามว่าจะให้ panel รีวิวไหม ถ้า ok → fan-out subagent `warnyin-sa`, `warnyin-tech-lead`, `warnyin-qa`, `warnyin-security`, `warnyin-infra` (Agent tool, ขนาน, read-only) รีวิว proposal+design → รวมความเห็น สรุปให้ user → แก้ blocker ให้ครบ (ห้ามเดา) → บันทึก section "Design review" ท้าย `design.md`
+5. ตอน generate ไฟล์ task หลายใบ สามารถใช้ sub-agent (Task/Agent tool) fan-out หนึ่ง agent ต่อหนึ่ง task ได้ — **แต่ต้องผ่าน Gate (ข้อ 8 ของ playbook) ก่อน**
+6. **Dry-run (ถาม user ก่อนเสมอ):** หลังเขียนไฟล์ task ครบ ใช้ AskUserQuestion ถามว่าต้องการ dry-run ทั้งหมดเพื่อหาจุดบกพร่องก่อนเข้า BUILD ไหม — ถ้า ok ทำตามข้อ 4.9 ของ playbook:
+   - fan-out agent (Agent tool) **หนึ่งตัวต่อหนึ่ง task แบบขนาน, read-only** — อ่าน task ทั้ง 4 ไฟล์ + design/proposal + โค้ดจริงที่เกี่ยว เดิน implement ในหัว หา **blocker** (implement ตาม spec ไม่ได้ — ต้องแก้ก่อน BUILD) และ **defer** (ทำ/ตัดสินใจทีหลังได้ แต่ต้อง track)
+   - task ที่พบ issue → เขียน `warnyin/stages/<slug>/tasks/<task>/issue.md` (ตาม template); รันครบทุก task → **สรุปผลรวม** ให้ user
+   - **หาวิธีแก้ DESIGN ตาม issue โดยห้ามเดา ห้ามคิดขึ้นเอง** — ติดจริงๆ → สัมภาษณ์ user ทีละข้อ + เสนอคำตอบแนะนำทุกครั้ง; คำถามที่โค้ดตอบได้ → ไปอ่านโค้ดเอง
+   - แก้แล้ว rerun dry-run เฉพาะ task ที่กระทบ วนจน **ไม่มี blocker ค้าง**
+7. เมื่อพร้อม implement → บอกให้รัน `/warnyin:build`

package/.claude/commands/warnyin/discovery.md

@@ -1,17 +1,17 @@
----
-description: รัน Discovery stage — research + สัมภาษณ์ผู้ใช้เพื่อตี scope จนเข้าใจตรงกัน
-argument-hint: "[ชื่อหัวข้องาน / slug]"
----
-
-ทำหน้าที่เป็น Discovery facilitator ตาม **playbook กลาง** ของ workflow มาตรฐาน
-
-1. อ่าน `warnyin/workflow/stages/discovery.md` ให้ครบก่อน แล้วทำตามทุกหลักการในนั้นอย่างเคร่งครัด
-   (กว้าง→แคบ, ถามทีละข้อ + เสนอคำตอบที่แนะนำ, โค้ดตอบได้ให้ไปอ่านเอง, เดินทีละกิ่ง decision tree)
-2. อ่าน Input ตามข้อ 2 ของ playbook — เริ่มที่ `docs/project.md` เสมอ
-3. หัวข้องาน: $ARGUMENTS
-   - ถ้าระบุมา → ใช้เป็น slug ของ topic (kebab-case) สร้าง/ใช้โฟลเดอร์ `warnyin/stages/<slug>/`
-   - ถ้าไม่ระบุ → ถาม user ก่อนว่าหัวข้องานคืออะไร
-4. เขียน output ลง `warnyin/stages/<slug>/discovery.md` และ `research.md` โดยใช้ template ในโฟลเดอร์ `warnyin/template/stages/[topic]/` เป็นโครง
-5. ปิดงานเมื่อผ่าน Gate (ข้อ 6 ของ playbook) แล้วเสนอว่าพร้อมเข้า DESIGN ด้วย `/warnyin:design`
-
-หมายเหตุ: ถ้า user พิมพ์ "ซักถามฉันหน่อย" / "grill me" → เข้าโหมด grill ตาม playbook
+---
+description: รัน Discovery stage — research + สัมภาษณ์ผู้ใช้เพื่อตี scope จนเข้าใจตรงกัน
+argument-hint: "[ชื่อหัวข้องาน / slug]"
+---
+
+ทำหน้าที่เป็น Discovery facilitator ตาม **playbook กลาง** ของ workflow มาตรฐาน
+
+1. อ่าน `warnyin/workflow/stages/discovery.md` ให้ครบก่อน แล้วทำตามทุกหลักการในนั้นอย่างเคร่งครัด
+   (กว้าง→แคบ, ถามทีละข้อ + เสนอคำตอบที่แนะนำ, โค้ดตอบได้ให้ไปอ่านเอง, เดินทีละกิ่ง decision tree)
+2. อ่าน Input ตามข้อ 2 ของ playbook — เริ่มที่ `docs/project.md` เสมอ
+3. หัวข้องาน: $ARGUMENTS
+   - ถ้าระบุมา → ใช้เป็น slug ของ topic (kebab-case) สร้าง/ใช้โฟลเดอร์ `warnyin/stages/<slug>/`
+   - ถ้าไม่ระบุ → ถาม user ก่อนว่าหัวข้องานคืออะไร
+4. เขียน output ลง `warnyin/stages/<slug>/discovery.md` และ `research.md` โดยใช้ template ในโฟลเดอร์ `warnyin/template/stages/[topic]/` เป็นโครง
+5. ปิดงานเมื่อผ่าน Gate (ข้อ 6 ของ playbook) แล้วเสนอว่าพร้อมเข้า DESIGN ด้วย `/warnyin:design`
+
+หมายเหตุ: ถ้า user พิมพ์ "ซักถามฉันหน่อย" / "grill me" → เข้าโหมด grill ตาม playbook

package/.claude/commands/warnyin/explore.md

@@ -0,0 +1,14 @@
+---
+description: สำรวจ/ตอบคำถามเกี่ยวกับโปรเจกต์แบบ read-only — ไม่สร้าง artifact ใดๆ จบที่คำตอบในแชท
+argument-hint: "[คำถาม / สิ่งที่อยากสำรวจ]"
+---
+
+ทำหน้าที่เป็น explorer ตาม **playbook กลาง** ของ workflow มาตรฐาน
+
+1. อ่าน `warnyin/workflow/explore.md` ให้ครบก่อน แล้วทำตามทุกหลักการในนั้นอย่างเคร่งครัด
+   (**read-only เด็ดขาด — ห้ามสร้าง/แก้/ลบไฟล์ใดๆ**, โค้ดตอบได้ให้ไปอ่านโค้ด, อ้าง `path:line`)
+2. Ground ตัวเองด้วย Input ตามข้อ 2 ของ playbook — อ่านเฉพาะส่วนที่เกี่ยวกับคำถาม
+3. คำถาม/หัวข้อ: $ARGUMENTS
+   - ถ้าไม่ระบุ → ถาม user ว่าอยากสำรวจ/รู้เรื่องอะไร
+4. คำถามกว้างที่ต้องกวาดหลายพื้นที่ → fan-out sub-agent แบบ read-only (Explore) ขนาน แล้วสังเคราะห์เป็นคำตอบเดียว
+5. ตอบในแชทเท่านั้น — ถ้าพบว่าควรเปิดเป็นงานจริง ให้เสนอ `/warnyin:discovery` หรือ `/warnyin:design` ให้ user ตัดสินใจ

package/.claude/commands/warnyin/init.md

@@ -7,6 +7,6 @@ description: รัน INIT — วิเคราะห์โปรเจกต
 1. อ่าน `warnyin/workflow/init.md` ให้ครบก่อน แล้วทำตามทุกหลักการอย่างเคร่งครัด
 2. **สแกนภาพรวม repo:** โครงสร้าง, manifest, ภาษา/framework → ระบุว่าแบ่งเป็น component อะไรบ้าง
 3. **วิเคราะห์ลึกต่อ component แบบขนาน:** fan-out sub-agent (Agent tool, read-only) หนึ่งตัวต่อหนึ่ง component — โครงสร้าง, pattern/convention ที่ใช้จริง, วิธี build/test; วิเคราะห์ infra จาก config จริง (docker/compose, env, scripts)
-4. **ข้อมูลธุรกิจที่โค้ดตอบไม่ได้** (เป้าหมาย, ลูกค้า, ขอบเขต) → สัมภาษณ์ user **ทีละข้อ + เสนอคำตอบแนะนำทุกครั้ง** (ใช้ README/โค้ดเป็น recommended); กฎใน `rule.md` → ถาม user ห้ามเดา
+4. **ข้อมูลธุรกิจที่โค้ดตอบไม่ได้** (เป้าหมาย, ลูกค้า, ขอบเขต) → สัมภาษณ์ user โดย**สวม BA + PO lens** (`warnyin/workflow/roles/ba.md` + `po.md`) ใช้ checklist ของทั้งสองเป็นชุดคำถาม — **ถามทีละข้อ + เสนอคำตอบแนะนำทุกครั้ง** (ใช้ README/โค้ดเป็น recommended, ถามเฉพาะที่ยังขาดหาย); เป็น lens ของ AI หลัก **ห้าม fan-out sub-agent มาสัมภาษณ์**; กฎใน `rule.md` → ถาม user ห้ามเดา
 5. **เสนอ summary** (สิ่งที่วิเคราะห์ได้ + รายการไฟล์ docs/ ที่จะเขียน) → ขอ user ยืนยัน**ครั้งเดียว** → เขียน/เติมไฟล์ตามตาราง Output ข้อ 4 ของ playbook — **ไฟล์ที่มีเนื้อหาอยู่แล้วให้เติม ไม่เขียนทับทิ้ง**
 6. **รายงานปิดท้าย:** ส่วนที่ยังว่าง/ไม่แน่ใจ (ระบุ "ยังว่าง รอเติม" ในไฟล์ ห้ามแต่งขึ้นเอง) → เสนอเริ่มงานแรกด้วย `/warnyin:discovery` หรือ `/warnyin:design`

package/.claude/commands/warnyin/next.md

@@ -0,0 +1,16 @@
+---
+description: เช็คงานค้างทุก topic + แนะนำขั้นตอน/command ถัดไป แบบ read-only — ไม่สร้าง/แก้ไฟล์ใดๆ
+argument-hint: "[slug (optional — ไม่ระบุ = สแกนทุก topic)]"
+---
+
+ทำหน้าที่เป็น status reporter ตาม **playbook กลาง** ของ workflow มาตรฐาน
+
+1. อ่าน `warnyin/workflow/next.md` ให้ครบก่อน แล้วทำตามทุกหลักการในนั้นอย่างเคร่งครัด
+   (**read-only เด็ดขาด — ห้ามสร้าง/แก้/ลบไฟล์ใดๆ**, สรุปจาก evidence ในไฟล์จริง, แนะนำแล้วหยุด)
+2. ขอบเขต: $ARGUMENTS
+   - ระบุ slug → เช็คเฉพาะ `warnyin/stages/<slug>/`
+   - ไม่ระบุ → สแกนทุก topic ใน `warnyin/stages/` (ยกเว้น `achieved/`)
+3. ต่อ topic: ระบุ stage ปัจจุบันจาก artifact ที่ถูกเติมจริง (ไฟล์ที่ยังเป็นโครง template = ยังไม่ทำ)
+   + ไล่ gate ของ playbook stage นั้น + สถานะ task ใน `tasks/*/task.md`
+4. รายงานในแชท: ตารางภาพรวม (topic · stage · งานค้าง · command ถัดไป) + รายละเอียดงานค้าง + ลำดับงานที่แนะนำ
+5. ไม่รัน stage ต่อให้เอง — เสนอ command ให้ user ตัดสินใจ

package/.claude/commands/warnyin/verify.md

@@ -1,19 +1,19 @@
----
-description: รัน VERIFY stage — strategy tester: เทสตามจุดประสงค์ใน local env (FE: e2e smoke + UXUI) แก้จนผ่าน
-argument-hint: "[slug ของ topic]"
----
-
-ทำหน้าที่เป็น strategy tester ตาม **playbook กลาง** ของ workflow มาตรฐาน
-
-0. **★ เช็ค context window ก่อนเริ่ม:** ถ้า context ของ session ถูกใช้ไปเยอะหรือ**เกินครึ่ง** → เสนอ user ให้ `/compact` หรือ `/clear` ก่อนเสมอ แล้วค่อยรัน `/warnyin:verify <slug>` ใหม่ใน context ที่โล่ง (สถานะงานอยู่ในไฟล์ `warnyin/stages/<slug>/` ครบ) — อย่าเริ่มลูปเทส-แก้ทั้งที่ context ใกล้เต็ม
-1. อ่าน `warnyin/workflow/stages/verify.md` ให้ครบก่อน แล้วทำตามทุกหลักการอย่างเคร่งครัด
-2. slug: $ARGUMENTS — ถ้าไม่ระบุให้ถามก่อน ว่าจะ verify topic ไหน
-3. **เข้าใจจุดประสงค์ก่อนเทส:** อ่าน `tasks/*/spec.md` + `task.md`, `design.md`, `proposal.md` ทั้งหมดให้เข้าใจดี แล้วค่อยเทสตามเจตนาของ topic
-4. **guideline:** อ่าน `docs/techstack/<component>/test.md` ว่าเทสยังไง (เช่น FE: e2e smoke ผ่าน playwright-cli) — ไม่มีก็เสนอวิธีแล้วเขียนแผนเอง; ดู `docs/infra.md` สำหรับ local env
-5. **เขียนแผนลง** `warnyin/stages/<slug>/test.md`
-6. **เทสจริงใน local env:** รัน service ที่เกี่ยวข้อง (ใช้ skill `run`/`verify` ช่วย launch ได้) → รันเทสตามแผน; FE → e2e smoke + ตรวจ UX/UI
-7. **ข้อไหนไม่ผ่าน → แก้ → rerun** วนจนผ่าน **นับจำนวนการแก้ไข**; เจอปัญหา → อ่าน `docs/troubleshooting.md` ก่อน, ปัญหายาก/ซ้ำที่แก้ได้ → บันทึก `warnyin/stages/<slug>/troubleshooting.md`
-8. **ถ้านาน/วนหลายรอบเกินไป → ถาม user ทีละข้อ + เสนอคำตอบที่แนะนำ** (อย่าวนเงียบไม่จบ)
-9. **เขียนสรุป** `warnyin/stages/<slug>/verify.md` (ผลเทส + รายการแก้ไข + จำนวนรอบ + ผล UXUI) → เสนอเข้า SHIP ด้วย `/warnyin:ship`
-
-หมายเหตุ: ห้ามแตะไฟล์กลางใน `docs/` — `test.md` เขียนระดับ topic ก่อน รอ SHIP merge. เกณฑ์ปิดดู Gate ข้อ 6 ของ playbook
+---
+description: รัน VERIFY stage — strategy tester: เทสตามจุดประสงค์ใน local env (FE: e2e smoke + UXUI) แก้จนผ่าน
+argument-hint: "[slug ของ topic]"
+---
+
+ทำหน้าที่เป็น strategy tester ตาม **playbook กลาง** ของ workflow มาตรฐาน
+
+0. **★ เช็ค context window ก่อนเริ่ม:** ถ้า context ของ session ถูกใช้ไปเยอะหรือ**เกินครึ่ง** → เสนอ user ให้ `/compact` หรือ `/clear` ก่อนเสมอ แล้วค่อยรัน `/warnyin:verify <slug>` ใหม่ใน context ที่โล่ง (สถานะงานอยู่ในไฟล์ `warnyin/stages/<slug>/` ครบ) — อย่าเริ่มลูปเทส-แก้ทั้งที่ context ใกล้เต็ม
+1. อ่าน `warnyin/workflow/stages/verify.md` ให้ครบก่อน แล้วทำตามทุกหลักการอย่างเคร่งครัด
+2. slug: $ARGUMENTS — ถ้าไม่ระบุให้ถามก่อน ว่าจะ verify topic ไหน
+3. **เข้าใจจุดประสงค์ก่อนเทส:** อ่าน `tasks/*/spec.md` + `task.md`, `design.md`, `proposal.md` ทั้งหมดให้เข้าใจดี แล้วค่อยเทสตามเจตนาของ topic
+4. **guideline:** อ่าน `docs/techstack/<component>/test.md` ว่าเทสยังไง (เช่น FE: e2e smoke ผ่าน playwright-cli) — ไม่มีก็เสนอวิธีแล้วเขียนแผนเอง; ดู `docs/infra.md` สำหรับ local env
+5. **เขียนแผนลง** `warnyin/stages/<slug>/test.md`
+6. **เทสจริงใน local env:** รัน service ที่เกี่ยวข้อง (ใช้ skill `run`/`verify` ช่วย launch ได้) → รันเทสตามแผน; FE → e2e smoke + ตรวจ UX/UI
+7. **ข้อไหนไม่ผ่าน → แก้ → rerun** วนจนผ่าน **นับจำนวนการแก้ไข**; เจอปัญหา → อ่าน `docs/troubleshooting.md` ก่อน, ปัญหายาก/ซ้ำที่แก้ได้ → บันทึก `warnyin/stages/<slug>/troubleshooting.md`
+8. **ถ้านาน/วนหลายรอบเกินไป → ถาม user ทีละข้อ + เสนอคำตอบที่แนะนำ** (อย่าวนเงียบไม่จบ)
+9. **เขียนสรุป** `warnyin/stages/<slug>/verify.md` (ผลเทส + รายการแก้ไข + จำนวนรอบ + ผล UXUI) → เสนอเข้า SHIP ด้วย `/warnyin:ship`
+
+หมายเหตุ: ห้ามแตะไฟล์กลางใน `docs/` — `test.md` เขียนระดับ topic ก่อน รอ SHIP merge. เกณฑ์ปิดดู Gate ข้อ 6 ของ playbook

package/AGENTS.md

@@ -1,38 +1,48 @@
-# AGENTS.md
-
-มาตรฐานเปิดสำหรับ AI agent ทุกเจ้าที่อ่านไฟล์นี้ (Codex, Antigravity, และเครื่องมืออื่นที่รองรับ `AGENTS.md`)
-
-## repo นี้คืออะไร
-
-repo มาตรฐานกลางของ **ways of work** สำหรับทุกโปรเจกต์ — เดินงานผ่าน 5 stage:
-
-```
-Discovery (optional) ──▶ DESIGN ──▶ BUILD ──▶ VERIFY ──▶ SHIP
-```
-
-## กฎสำคัญ: ทำตาม playbook กลางเสมอ
-
-แก่นของแต่ละ stage คือ **single source of truth** อยู่ที่ `warnyin/workflow/stages/`
-ก่อนทำงานใน stage ใด ให้เปิดอ่านไฟล์ playbook ของ stage นั้นแล้วทำตามอย่างเคร่งครัด
-
-| Stage | playbook | สถานะ |
-|---|---|---|
-| Discovery | `warnyin/workflow/stages/discovery.md` | ✅ พร้อมใช้ |
-| DESIGN | `warnyin/workflow/stages/design.md` | ✅ พร้อมใช้ |
-| BUILD | `warnyin/workflow/stages/build.md` | ✅ พร้อมใช้ |
-| VERIFY | `warnyin/workflow/stages/verify.md` | ✅ พร้อมใช้ |
-| SHIP | `warnyin/workflow/stages/ship.md` | ✅ พร้อมใช้ |
-
-## วิธีเริ่ม
-
-0. ครั้งแรกในโปรเจกต์ (docs/ ยังว่าง) → ทำตาม `warnyin/workflow/init.md` เพื่อวิเคราะห์โปรเจกต์ + เติม `docs/` ก่อน
-1. อ่าน `warnyin/workflow/README.md` เพื่อเข้าใจภาพรวมและโครงสร้าง
-2. งานใหม่ → copy `warnyin/template/stages/[topic]/` เป็น `warnyin/stages/<slug>/`
-3. รัน stage ตามลำดับ โดยทำตาม playbook ของแต่ละ stage
-4. output ของงานเก็บใน `warnyin/stages/<slug>/`, ความรู้ถาวรระดับโปรเจกต์อยู่ใน `docs/`
-
-## รัน Discovery
-
-ทำตาม `warnyin/workflow/stages/discovery.md` — เริ่มอ่าน `docs/project.md`, ตี scope กว้าง→แคบ,
-ถามทีละข้อพร้อมเสนอคำตอบที่แนะนำ, คำถามที่ตอบได้ด้วยโค้ดให้ไปอ่านโค้ดเอง,
-เขียน output ลง `warnyin/stages/<slug>/discovery.md` และ `research.md`
+# AGENTS.md
+
+มาตรฐานเปิดสำหรับ AI agent ทุกเจ้าที่อ่านไฟล์นี้ (Codex, Antigravity, และเครื่องมืออื่นที่รองรับ `AGENTS.md`)
+
+## repo นี้คืออะไร
+
+repo มาตรฐานกลางของ **ways of work** สำหรับทุกโปรเจกต์ — เดินงานผ่าน 5 stage:
+
+```
+Discovery (optional) ──▶ DESIGN ──▶ BUILD ──▶ VERIFY ──▶ SHIP
+```
+
+## กฎสำคัญ: ทำตาม playbook กลางเสมอ
+
+แก่นของแต่ละ stage คือ **single source of truth** อยู่ที่ `warnyin/workflow/stages/`
+ก่อนทำงานใน stage ใด ให้เปิดอ่านไฟล์ playbook ของ stage นั้นแล้วทำตามอย่างเคร่งครัด
+
+| Stage | playbook | สถานะ |
+|---|---|---|
+| Discovery | `warnyin/workflow/stages/discovery.md` | ✅ พร้อมใช้ |
+| DESIGN | `warnyin/workflow/stages/design.md` | ✅ พร้อมใช้ |
+| BUILD | `warnyin/workflow/stages/build.md` | ✅ พร้อมใช้ |
+| VERIFY | `warnyin/workflow/stages/verify.md` | ✅ พร้อมใช้ |
+| SHIP | `warnyin/workflow/stages/ship.md` | ✅ พร้อมใช้ |
+
+## วิธีเริ่ม
+
+0. ครั้งแรกในโปรเจกต์ (docs/ ยังว่าง) → ทำตาม `warnyin/workflow/init.md` เพื่อวิเคราะห์โปรเจกต์ + เติม `docs/` ก่อน
+1. อ่าน `warnyin/workflow/README.md` เพื่อเข้าใจภาพรวมและโครงสร้าง
+2. งานใหม่ → copy `warnyin/template/stages/[topic]/` เป็น `warnyin/stages/<slug>/`
+3. รัน stage ตามลำดับ โดยทำตาม playbook ของแต่ละ stage
+4. output ของงานเก็บใน `warnyin/stages/<slug>/`, ความรู้ถาวรระดับโปรเจกต์อยู่ใน `docs/`
+
+## สำรวจโดยไม่สร้าง artifact (EXPLORE)
+
+อยากถาม/สำรวจข้อมูลเฉยๆ โดยไม่เปิด topic → ทำตาม `warnyin/workflow/explore.md`
+(read-only เด็ดขาด — ไม่สร้าง/แก้ไฟล์ใดๆ จบที่คำตอบในแชท)
+
+## เช็คงานค้าง / หาขั้นตอนถัดไป (NEXT)
+
+อยากรู้ว่ามีงานอะไรค้างและควรไปต่อยังไง → ทำตาม `warnyin/workflow/next.md`
+(สแกน `warnyin/stages/*` ระบุ stage ปัจจุบันจาก artifact จริง + gate ที่ขาด — read-only ไม่แก้ไฟล์)
+
+## รัน Discovery
+
+ทำตาม `warnyin/workflow/stages/discovery.md` — เริ่มอ่าน `docs/project.md`, ตี scope กว้าง→แคบ,
+ถามทีละข้อพร้อมเสนอคำตอบที่แนะนำ, คำถามที่ตอบได้ด้วยโค้ดให้ไปอ่านโค้ดเอง,
+เขียน output ลง `warnyin/stages/<slug>/discovery.md` และ `research.md`

package/CLAUDE.md

@@ -1,38 +1,40 @@
-# CLAUDE.md
-
-repo มาตรฐานกลางของ **ways of work** สำหรับทุกโปรเจกต์ เดินงานผ่าน 5 stage:
-`Discovery (optional) ▶ DESIGN ▶ BUILD ▶ VERIFY ▶ SHIP`
-
-## กฎหลัก
-- แก่นของแต่ละ stage เป็น single source of truth ที่ `warnyin/workflow/stages/` — **ทำตาม playbook นั้นเสมอ** ก่อนเริ่มงานใน stage
-- อย่า duplicate logic ของ workflow ลงที่อื่น ถ้าต้องแก้พฤติกรรมให้แก้ที่ `warnyin/workflow/stages/`
-- output ของงานจริงเก็บใน `warnyin/stages/<slug>/` (copy จาก template `warnyin/template/stages/[topic]/`)
-- ความรู้ถาวรระดับโปรเจกต์อยู่ใน `docs/` — เริ่มอ่าน `docs/project.md` เสมอใน Discovery
-- role card กลางอยู่ที่ `warnyin/workflow/roles/` (BA/PO/SA/Tech Lead/Developer/QA/Security/Infra) — stage ไหนใช้ role ไหนดูใน playbook; reviewer subagent ของ Claude Code อยู่ที่ `.claude/agents/warnyin-*`
-
-## Slash commands (namespace `warnyin:`)
-- `/warnyin:init` → วิเคราะห์โปรเจกต์ + เติม `docs/` ครั้งแรกหลังติดตั้ง (`.claude/commands/warnyin/init.md` → `warnyin/workflow/init.md`)
-- `/warnyin:install-skill [role]` → ติดตั้ง skill เสริมประจำ role (รายการอยู่ที่ตารางใน `warnyin/workflow/roles/README.md`)
-- `/warnyin:update-codemaps` → สแกนโครงสร้าง + สร้าง/อัปเดต codemap แบบ token-lean ใน `docs/codemap/` (`warnyin/workflow/codemap.md`)
-- `/warnyin:discovery [topic]` → Discovery stage (`.claude/commands/warnyin/discovery.md` → `warnyin/workflow/stages/discovery.md`)
-- `/warnyin:design [slug] [change]` → DESIGN stage (`.claude/commands/warnyin/design.md` → `warnyin/workflow/stages/design.md`)
-- `/warnyin:build [slug]` → BUILD stage — fan-out sub-agent ตาม dependency (`warnyin/workflow/stages/build.md` + `warnyin/workflow/scripts/build-wave.mjs`)
-- `/warnyin:verify [slug]` → VERIFY stage — strategy tester เทส local env + UXUI แก้จนผ่าน (`warnyin/workflow/stages/verify.md`)
-- `/warnyin:ship [slug]` → SHIP stage — ส่งมอบ: promote ความรู้ขึ้น `docs/` + archive topic (`warnyin/workflow/stages/ship.md`)
-
-## การติดตั้งไปโปรเจกต์อื่น (npx installer)
-- `npx @warnyin/agents` (หรือสำรอง `npx github:warnyin/warnyin-agents`) → copy โครงทั้งหมดลงโปรเจกต์ปลายทาง (ข้ามไฟล์ที่มีอยู่, CLAUDE.md/AGENTS.md ที่มีอยู่จะต่อท้ายเป็น section)
-- `--update` → เขียนทับเฉพาะ core (`warnyin/workflow/`, `.claude/commands/warnyin/`, template ใน `warnyin/template/`) ไม่แตะ `docs/`/งานจริง
-- ตัว installer: `bin/cli.mjs` + template CLAUDE.md ของโปรเจกต์ปลายทางที่ `warnyin/installer/templates/CLAUDE.md` (แก้ commands list ที่ไหน ให้แก้ template นี้ด้วย; โฟลเดอร์นี้ไม่ถูก copy ไป target)
-- หลังติดตั้ง → รัน `/warnyin:init` เพื่อเติม `docs/`
-
-## รองรับหลาย AI
-repo นี้ tool-agnostic: Claude Code อ่าน `.claude/` + ไฟล์นี้, ส่วน Codex/Antigravity อ่าน `AGENTS.md`
-ทุกเครื่องชี้กลับมาที่ playbook กลางชุดเดียวกันใน `warnyin/workflow/stages/` — ดูภาพรวมที่ `warnyin/workflow/README.md`
-
-## สถานะการสร้าง workflow (อัปเดต 2026-06-04)
-ครบทั้ง 5 stage: Discovery ✅ · DESIGN ✅ · BUILD ✅ · VERIFY ✅ · SHIP ✅
-(playbook + command + template + build-wave.mjs ครบทุก stage)
-
-แพทเทิร์นการเติม/แก้ stage: playbook `warnyin/workflow/stages/<stage>.md` + command `.claude/commands/warnyin/<stage>.md` + อัปเดตตาราง stage ใน `AGENTS.md`/`CLAUDE.md`/`warnyin/workflow/README.md` + output template ใน `warnyin/template/stages/[topic]/`
-**สำคัญ: การเปลี่ยนพฤติกรรม stage ใดๆ ให้ user เป็นคนอธิบาย/ยืนยันก่อน อย่าเดาเอง**
+# CLAUDE.md
+
+repo มาตรฐานกลางของ **ways of work** สำหรับทุกโปรเจกต์ เดินงานผ่าน 5 stage:
+`Discovery (optional) ▶ DESIGN ▶ BUILD ▶ VERIFY ▶ SHIP`
+
+## กฎหลัก
+- แก่นของแต่ละ stage เป็น single source of truth ที่ `warnyin/workflow/stages/` — **ทำตาม playbook นั้นเสมอ** ก่อนเริ่มงานใน stage
+- อย่า duplicate logic ของ workflow ลงที่อื่น ถ้าต้องแก้พฤติกรรมให้แก้ที่ `warnyin/workflow/stages/`
+- output ของงานจริงเก็บใน `warnyin/stages/<slug>/` (copy จาก template `warnyin/template/stages/[topic]/`)
+- ความรู้ถาวรระดับโปรเจกต์อยู่ใน `docs/` — เริ่มอ่าน `docs/project.md` เสมอใน Discovery
+- role card กลางอยู่ที่ `warnyin/workflow/roles/` (BA/PO/SA/Tech Lead/Developer/QA/Security/Infra) — stage ไหนใช้ role ไหนดูใน playbook; reviewer subagent ของ Claude Code อยู่ที่ `.claude/agents/warnyin-*`
+
+## Slash commands (namespace `warnyin:`)
+- `/warnyin:init` → วิเคราะห์โปรเจกต์ + เติม `docs/` ครั้งแรกหลังติดตั้ง (`.claude/commands/warnyin/init.md` → `warnyin/workflow/init.md`)
+- `/warnyin:install-skill [role]` → ติดตั้ง skill เสริมประจำ role (รายการอยู่ที่ตารางใน `warnyin/workflow/roles/README.md`)
+- `/warnyin:update-codemaps` → สแกนโครงสร้าง + สร้าง/อัปเดต codemap แบบ token-lean ใน `docs/codemap/` (`warnyin/workflow/codemap.md`)
+- `/warnyin:explore [คำถาม]` → สำรวจ/ตอบคำถามแบบ read-only — ไม่สร้าง artifact ใดๆ จบที่คำตอบในแชท (`warnyin/workflow/explore.md`)
+- `/warnyin:next [slug]` → เช็คงานค้างทุก topic + แนะนำ command ถัดไป แบบ read-only (`warnyin/workflow/next.md`)
+- `/warnyin:discovery [topic]` → Discovery stage (`.claude/commands/warnyin/discovery.md` → `warnyin/workflow/stages/discovery.md`)
+- `/warnyin:design [slug] [change]` → DESIGN stage (`.claude/commands/warnyin/design.md` → `warnyin/workflow/stages/design.md`)
+- `/warnyin:build [slug]` → BUILD stage — fan-out sub-agent ตาม dependency (`warnyin/workflow/stages/build.md` + `warnyin/workflow/scripts/build-wave.mjs`)
+- `/warnyin:verify [slug]` → VERIFY stage — strategy tester เทส local env + UXUI แก้จนผ่าน (`warnyin/workflow/stages/verify.md`)
+- `/warnyin:ship [slug]` → SHIP stage — ส่งมอบ: promote ความรู้ขึ้น `docs/` + archive topic (`warnyin/workflow/stages/ship.md`)
+
+## การติดตั้งไปโปรเจกต์อื่น (npx installer)
+- `npx @warnyin/agents` (หรือสำรอง `npx github:warnyin/warnyin-agents`) → copy โครงทั้งหมดลงโปรเจกต์ปลายทาง (ข้ามไฟล์ที่มีอยู่, CLAUDE.md/AGENTS.md ที่มีอยู่จะต่อท้ายเป็น section)
+- `--update` → เขียนทับเฉพาะ core (`warnyin/workflow/`, `.claude/commands/warnyin/`, template ใน `warnyin/template/`) ไม่แตะ `docs/`/งานจริง
+- ตัว installer: `bin/cli.mjs` + template CLAUDE.md ของโปรเจกต์ปลายทางที่ `warnyin/installer/templates/CLAUDE.md` (แก้ commands list ที่ไหน ให้แก้ template นี้ด้วย; โฟลเดอร์นี้ไม่ถูก copy ไป target)
+- หลังติดตั้ง → รัน `/warnyin:init` เพื่อเติม `docs/`
+
+## รองรับหลาย AI
+repo นี้ tool-agnostic: Claude Code อ่าน `.claude/` + ไฟล์นี้, ส่วน Codex/Antigravity อ่าน `AGENTS.md`
+ทุกเครื่องชี้กลับมาที่ playbook กลางชุดเดียวกันใน `warnyin/workflow/stages/` — ดูภาพรวมที่ `warnyin/workflow/README.md`
+
+## สถานะการสร้าง workflow (อัปเดต 2026-06-04)
+ครบทั้ง 5 stage: Discovery ✅ · DESIGN ✅ · BUILD ✅ · VERIFY ✅ · SHIP ✅
+(playbook + command + template + build-wave.mjs ครบทุก stage)
+
+แพทเทิร์นการเติม/แก้ stage: playbook `warnyin/workflow/stages/<stage>.md` + command `.claude/commands/warnyin/<stage>.md` + อัปเดตตาราง stage ใน `AGENTS.md`/`CLAUDE.md`/`warnyin/workflow/README.md` + output template ใน `warnyin/template/stages/[topic]/`
+**สำคัญ: การเปลี่ยนพฤติกรรม stage ใดๆ ให้ user เป็นคนอธิบาย/ยืนยันก่อน อย่าเดาเอง**

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@warnyin/agents",
-  "version": "0.4.0",
+  "version": "0.5.1",
   "description": "Warnyin Standard Workflow installer — 5-stage ways of work (Discovery/DESIGN/BUILD/VERIFY/SHIP) สำหรับทุกโปรเจกต์",
   "type": "module",
   "license": "MIT",

package/warnyin/installer/templates/CLAUDE.md

@@ -13,6 +13,8 @@
 - `/warnyin:init` → วิเคราะห์โปรเจกต์ + เติม `docs/` ครั้งแรกหลังติดตั้ง (`warnyin/workflow/init.md`)
 - `/warnyin:install-skill [role]` → ติดตั้ง skill เสริมประจำ role (รายการ: `warnyin/workflow/roles/README.md`)
 - `/warnyin:update-codemaps` → สแกนโครงสร้าง + สร้าง/อัปเดต codemap แบบ token-lean (`warnyin/workflow/codemap.md`)
+- `/warnyin:explore [คำถาม]` → สำรวจ/ตอบคำถามแบบ read-only — ไม่สร้าง artifact (`warnyin/workflow/explore.md`)
+- `/warnyin:next [slug]` → เช็คงานค้าง + แนะนำ command ถัดไป แบบ read-only (`warnyin/workflow/next.md`)
 - `/warnyin:discovery [topic]` → Discovery stage (`warnyin/workflow/stages/discovery.md`)
 - `/warnyin:design [slug] [change]` → DESIGN stage (`warnyin/workflow/stages/design.md`)
 - `/warnyin:build [slug]` → BUILD stage — fan-out sub-agent ตาม dependency (`warnyin/workflow/stages/build.md` + `warnyin/workflow/scripts/build-wave.mjs`)

package/warnyin/template/stages/[topic]/build.md

@@ -1,58 +1,58 @@
-# Build Report — <ชื่อ change>
-
-> Output ของ BUILD stage · playbook: `warnyin/workflow/stages/build.md`
-> รายงานผลการ implement ต่อ task + การ integrate
-
-| | |
-|---|---|
-| **Slug** | `<kebab-case>` |
-| **Build branch** | `<branch>` |
-| **Isolation** | `worktree` / `shared-tree` |
-| **วันที่** | `YYYY-MM-DD` |
-| **ผลรวม** | ผ่าน __ / ล้ม __ / ทั้งหมด __ task |
-
-## 1. Execution plan (waves ตาม dependency)
-```
-wave 1 (parallel): task-a, task-b
-wave 2:            task-c  (ขึ้นกับ task-a)
-wave 3:            task-d  (ขึ้นกับ task-b, task-c)
-```
-
-## 2. ผลต่อ task
-| Wave | Task | สถานะ | Test/Lint | ไฟล์ที่แก้ | Branch | หมายเหตุ |
-|---|---|---|---|---|---|---|
-| 1 | task-a | ✅ passed | | | | |
-| 1 | task-b | ❌ failed | | | | เหตุผล... |
-
-## 3. Integration notes
-- การ merge แต่ละ wave / conflict ที่เจอและวิธีแก้:
-
-## 3.5 Full build & test gate (หลัง integrate ทุก wave)
-> รัน build ทั้งหมด + test suite ทั้งหมด (รวม unit test) บน build branch — ต้องเขียวหมดก่อนปิด BUILD
-
-| Component | Build | Unit test | Test อื่น | รอบที่แก้ |
-|---|---|---|---|---|
-| api-service | ✅ / ❌ | ผ่าน __/__ | | |
-| admin-console | | | | |
-
-- error ที่เจอตอนรวม + วิธีแก้:
-
-## 4. ปัญหา/ค้าง (ถ้ามี)
-- task ที่ล้ม + สาเหตุ + แผนแก้:
-
-## 5. Rule/standard ใหม่ที่ note ไว้ (รอ SHIP)
-> รวบรวมจาก `tasks/<task>/rule.md` และ `standard.md` — รอ SHIP อัปเดตไฟล์กลางใน `docs/`
--
-
-## 6. ปัญหายาก/ซ้ำที่เจอ
-> บันทึกละเอียดที่ `./troubleshooting.md` (SHIP ยกขึ้น `docs/troubleshooting.md`)
-- ดู `./troubleshooting.md`
-
-## ✅ Gate → VERIFY (ดู `warnyin/workflow/stages/build.md` ข้อ 7)
-- [ ] ทุก task implement + merge เข้า build branch แล้ว
-- [ ] ทุก task `passed` (test/build เขียว) ไม่มี `failed` ค้าง
-- [ ] ไม่มี merge conflict ค้าง
-- [ ] Full build ของทุก component ผ่าน (ไม่มี build error)
-- [ ] test suite ทั้งหมด (รวม unit test) เขียวหมดบน build branch
-- [ ] build.md สรุปครบทุก task + ผล full build/test
-- [ ] ไม่แตะ rule/standard กลางใน docs/
+# Build Report — <ชื่อ change>
+
+> Output ของ BUILD stage · playbook: `warnyin/workflow/stages/build.md`
+> รายงานผลการ implement ต่อ task + การ integrate
+
+| | |
+|---|---|
+| **Slug** | `<kebab-case>` |
+| **Build branch** | `<branch>` |
+| **Isolation** | `worktree` / `shared-tree` |
+| **วันที่** | `YYYY-MM-DD` |
+| **ผลรวม** | ผ่าน __ / ล้ม __ / ทั้งหมด __ task |
+
+## 1. Execution plan (waves ตาม dependency)
+```
+wave 1 (parallel): task-a, task-b
+wave 2:            task-c  (ขึ้นกับ task-a)
+wave 3:            task-d  (ขึ้นกับ task-b, task-c)
+```
+
+## 2. ผลต่อ task
+| Wave | Task | สถานะ | Test/Lint | ไฟล์ที่แก้ | Branch | หมายเหตุ |
+|---|---|---|---|---|---|---|
+| 1 | task-a | ✅ passed | | | | |
+| 1 | task-b | ❌ failed | | | | เหตุผล... |
+
+## 3. Integration notes
+- การ merge แต่ละ wave / conflict ที่เจอและวิธีแก้:
+
+## 3.5 Full build & test gate (หลัง integrate ทุก wave)
+> รัน build ทั้งหมด + test suite ทั้งหมด (รวม unit test) บน build branch — ต้องเขียวหมดก่อนปิด BUILD
+
+| Component | Build | Unit test | Test อื่น | รอบที่แก้ |
+|---|---|---|---|---|
+| api-service | ✅ / ❌ | ผ่าน __/__ | | |
+| admin-console | | | | |
+
+- error ที่เจอตอนรวม + วิธีแก้:
+
+## 4. ปัญหา/ค้าง (ถ้ามี)
+- task ที่ล้ม + สาเหตุ + แผนแก้:
+
+## 5. Rule/standard ใหม่ที่ note ไว้ (รอ SHIP)
+> รวบรวมจาก `tasks/<task>/rule.md` และ `standard.md` — รอ SHIP อัปเดตไฟล์กลางใน `docs/`
+-
+
+## 6. ปัญหายาก/ซ้ำที่เจอ
+> บันทึกละเอียดที่ `./troubleshooting.md` (SHIP ยกขึ้น `docs/troubleshooting.md`)
+- ดู `./troubleshooting.md`
+
+## ✅ Gate → VERIFY (ดู `warnyin/workflow/stages/build.md` ข้อ 7)
+- [ ] ทุก task implement + merge เข้า build branch แล้ว
+- [ ] ทุก task `passed` (test/build เขียว) ไม่มี `failed` ค้าง
+- [ ] ไม่มี merge conflict ค้าง
+- [ ] Full build ของทุก component ผ่าน (ไม่มี build error)
+- [ ] test suite ทั้งหมด (รวม unit test) เขียวหมดบน build branch
+- [ ] build.md สรุปครบทุก task + ผล full build/test
+- [ ] ไม่แตะ rule/standard กลางใน docs/