@warnyin/agents 0.9.1 → 0.10.0

package/src/.claude/commands/warnyin/ship.md

@@ -1,28 +1,28 @@
----
-description: รัน SHIP stage — ส่งมอบ: promote ความรู้ของ topic ขึ้นเอกสารกลางใน docs/ + archive topic
-argument-hint: "[slug ของ topic]"
----
-
-ทำหน้าที่เป็นผู้ส่งมอบ (SHIP) ตาม **playbook กลาง** ของ workflow มาตรฐาน
-
-1. อ่าน `.warnyin/workflow/stages/ship.md` ให้ครบก่อน แล้วทำตามทุกหลักการอย่างเคร่งครัด
-2. slug: $ARGUMENTS — ถ้าไม่ระบุให้ถามก่อน ว่าจะ ship topic ไหน (ดูโฟลเดอร์ใน `docs/stages/`)
-3. **อ่านทำความเข้าใจ topic + รวบรวม learned-rule candidate:** อ่าน `docs/stages/<slug>/` ทุกไฟล์ — topic นี้ทำอะไร ทำอย่างไร เกิดความรู้ใหม่อะไรบ้าง; เช็คว่า VERIFY ผ่าน Gate แล้ว (`verify.md` สรุปผลผ่าน) — ถ้ายังไม่ผ่าน → หยุด แจ้ง user. ทำตาม playbook §4 step 1 — ถ้ารัน node ได้ validate `<slug>` ก่อน promote (มี ✖ ควรแก้ก่อน — รายการเช็คอยู่ใน script + playbook). รวบรวม learned-rule candidate เป็นตาราง (`rule + evidence + scope + promote?`): **planned** จาก `tasks/*/rule.md` §2 "รอ SHIP" + `standard.md` · **emergent** สแกนบทเรียนใน `build.md`/`verify.md`/`troubleshooting.md`/diff — `rule` ต้อง generalize (ไม่ใช่ incident), `evidence` บังคับ (pointer + ลิงก์ artifact; ไม่มี = ไม่ promote), `scope` = `component:<c>` หรือ `project`
-4. **จำแนก feature:** feature ใหม่ หรือปรับปรุง feature เดิม (เทียบกับ `docs/features/` ที่มีอยู่)
-5. **ขออนุมัติครั้งเดียว** — ใช้ AskUserQuestion สรุป promotion plan: feature ใหม่/ปรับปรุง, ไฟล์กลางที่จะอัปเดต + สาระที่จะใส่, ชื่อโฟลเดอร์ archive — **fold ตาราง learned-rule (rule + evidence + scope) เข้า approval เดียวกัน ให้ user ยืนยัน per-rule** (✅ promote / ✂️ ตัด + เหตุผล) → รอ go/no-go (อย่าแก้ไฟล์ใดก่อนได้ไฟเขียว)
-6. **★ Archive ก่อน:** ย้ายทั้งโฟลเดอร์ `docs/stages/<slug>/` → `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` (ใช้ `git mv`; วันที่ = วันที่ ship) แล้วอ่านเนื้อหาจาก path ใหม่ระหว่าง promote
-7. **อัปเดตเอกสารกลาง** (กลั่นเข้าโครงสร้างไฟล์เดิม ไม่ copy ดิบ, ระวัง duplicate):
-   - `docs/features/<feature-name>/` — ใหม่ → สร้าง (feature.md + business.md); เดิม → อัปเดต โดยใช้ business/proposal/design ของ topic — **และ merge `spec.md` ตาม Spec delta** ใน `design.md` §9 (ADDED ต่อท้าย · MODIFIED แทนที่ · REMOVED ลบ; **key ไม่เจอ → STOP ถาม user ห้าม merge เงียบ** — กติกาเต็มดู playbook §4 step 5)
-   - `docs/techstack/<component>/{rule,standard}.md` — learned-rule ที่ยืนยันแล้ว scope `component:<c>` + note "รอ SHIP" (พิจารณาครบทุกข้อ: promote หรือตัดทิ้งพร้อมเหตุผล); learned-rule scope `project` → `docs/rule.md`
-   - `docs/techstack/<component>/structure.md` + `test.md` — โครงสร้างที่เปลี่ยน (ดูโค้ดจริง) + merge แผนเทสจาก `test.md` ของ topic
-   - `docs/rule.md` — global rule ใหม่/ที่เปลี่ยน (เฉพาะกฎระดับโปรเจกต์)
-   - `docs/troubleshooting.md` — merge entry จาก `troubleshooting.md` ของ topic
-   - `docs/infra.md` + `docs/project.md` — เฉพาะถ้ามีข้อมูลเกี่ยวข้อง
-   - `docs/codemap/` ทั้งหมด — อัปเดตให้ตรงโค้ดจริงปัจจุบัน ตาม `.warnyin/workflow/codemap.md` (= ขั้นตอนเดียวกับ `/warnyin:update-codemaps`)
-8. **เขียนสรุป** `achieved/<YYYY-MM-DD>-<slug>/ship.md` (feature ใหม่/ปรับปรุง + ตารางเอกสารที่อัปเดต + note ที่ตัดทิ้งพร้อมเหตุผล) → รายงาน user ว่าส่งมอบครบ topic ปิดสมบูรณ์
-
-หมายเหตุ:
-- SHIP เป็นเรื่อง **เอกสาร + archive เท่านั้น** — ไม่ merge โค้ด (build branch → main จัดการเองนอก workflow)
-- เนื้อหาที่ไม่แน่ใจว่าควร promote/วางไฟล์ไหน → ถามทีละข้อ + เสนอคำตอบที่แนะนำ อย่าเดา
-- เกณฑ์ปิดดู Gate ข้อ 6 ของ playbook
-- คงเป็น command (user-only) โดยตั้งใจ — SHIP เป็น stateful/irreversible (archive ด้วย git mv, promote เอกสารกลาง) ต้องให้ user สั่งชัด ไม่ทำเป็น skill auto-invoke
+---
+description: รัน SHIP stage — ส่งมอบ: promote ความรู้ของ topic ขึ้นเอกสารกลางใน docs/ + archive topic
+argument-hint: "[slug ของ topic]"
+---
+
+ทำหน้าที่เป็นผู้ส่งมอบ (SHIP) ตาม **playbook กลาง** ของ workflow มาตรฐาน
+
+1. อ่าน `.warnyin/workflow/stages/ship.md` ให้ครบก่อน แล้วทำตามทุกหลักการอย่างเคร่งครัด
+2. slug: $ARGUMENTS — ถ้าไม่ระบุให้ถามก่อน ว่าจะ ship topic ไหน (ดูโฟลเดอร์ใน `docs/stages/`)
+3. **อ่านทำความเข้าใจ topic + รวบรวม learned-rule candidate:** อ่าน `docs/stages/<slug>/` ทุกไฟล์ — topic นี้ทำอะไร ทำอย่างไร เกิดความรู้ใหม่อะไรบ้าง; เช็คว่า VERIFY ผ่าน Gate แล้ว (`verify.md` สรุปผลผ่าน) — ถ้ายังไม่ผ่าน → หยุด แจ้ง user. ทำตาม playbook §4 step 1 — ถ้ารัน node ได้ validate `<slug>` ก่อน promote (มี ✖ ควรแก้ก่อน — รายการเช็คอยู่ใน script + playbook). รวบรวม learned-rule candidate เป็นตาราง (`rule + evidence + scope + promote?`): **planned** จาก `tasks/*/rule.md` §2 "รอ SHIP" + `standard.md` · **emergent** สแกนบทเรียนใน `build.md`/`verify.md`/`troubleshooting.md`/diff — `rule` ต้อง generalize (ไม่ใช่ incident), `evidence` บังคับ (pointer + ลิงก์ artifact; ไม่มี = ไม่ promote), `scope` = `component:<c>` หรือ `project`
+4. **จำแนก feature:** feature ใหม่ หรือปรับปรุง feature เดิม (เทียบกับ `docs/features/` ที่มีอยู่)
+5. **ขออนุมัติครั้งเดียว** — ใช้ AskUserQuestion สรุป promotion plan: feature ใหม่/ปรับปรุง, ไฟล์กลางที่จะอัปเดต + สาระที่จะใส่, ชื่อโฟลเดอร์ archive — **fold ตาราง learned-rule (rule + evidence + scope) เข้า approval เดียวกัน ให้ user ยืนยัน per-rule** (✅ promote / ✂️ ตัด + เหตุผล) → รอ go/no-go (อย่าแก้ไฟล์ใดก่อนได้ไฟเขียว)
+6. **★ Archive ก่อน:** ย้ายทั้งโฟลเดอร์ `docs/stages/<slug>/` → `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` (ใช้ `git mv`; วันที่ = วันที่ ship) แล้วอ่านเนื้อหาจาก path ใหม่ระหว่าง promote
+7. **อัปเดตเอกสารกลาง** (กลั่นเข้าโครงสร้างไฟล์เดิม ไม่ copy ดิบ, ระวัง duplicate):
+   - `docs/features/<feature-name>/` — ใหม่ → สร้าง (feature.md + business.md); เดิม → อัปเดต โดยใช้ business/proposal/design ของ topic — **และ merge `spec.md` ตาม Spec delta** ใน `design.md` §9 (ADDED ต่อท้าย · MODIFIED แทนที่ · REMOVED ลบ; **key ไม่เจอ → STOP ถาม user ห้าม merge เงียบ** — กติกาเต็มดู playbook §4 step 5)
+   - `docs/techstack/<component>/{rule,standard}.md` — learned-rule ที่ยืนยันแล้ว scope `component:<c>` + note "รอ SHIP" (พิจารณาครบทุกข้อ: promote หรือตัดทิ้งพร้อมเหตุผล); learned-rule scope `project` → `docs/rule.md`
+   - `docs/techstack/<component>/structure.md` + `test.md` — โครงสร้างที่เปลี่ยน (ดูโค้ดจริง) + merge แผนเทสจาก `test.md` ของ topic
+   - `docs/rule.md` — global rule ใหม่/ที่เปลี่ยน (เฉพาะกฎระดับโปรเจกต์)
+   - `docs/troubleshooting.md` — merge entry จาก `troubleshooting.md` ของ topic
+   - `docs/infra.md` + `docs/project.md` — เฉพาะถ้ามีข้อมูลเกี่ยวข้อง
+   - `docs/codemap/` ทั้งหมด — อัปเดตให้ตรงโค้ดจริงปัจจุบัน ตาม `.warnyin/workflow/codemap.md` (= ขั้นตอนเดียวกับ `/warnyin:update-codemaps`)
+8. **เขียนสรุป** `achieved/<YYYY-MM-DD>-<slug>/ship.md` (feature ใหม่/ปรับปรุง + ตารางเอกสารที่อัปเดต + note ที่ตัดทิ้งพร้อมเหตุผล) → รายงาน user ว่าส่งมอบครบ topic ปิดสมบูรณ์
+
+หมายเหตุ:
+- SHIP เป็นเรื่อง **เอกสาร + archive เท่านั้น** — ไม่ merge โค้ด (build branch → main จัดการเองนอก workflow)
+- เนื้อหาที่ไม่แน่ใจว่าควร promote/วางไฟล์ไหน → ถามทีละข้อ + เสนอคำตอบที่แนะนำ อย่าเดา
+- เกณฑ์ปิดดู Gate ข้อ 6 ของ playbook
+- คงเป็น command (user-only) โดยตั้งใจ — SHIP เป็น stateful/irreversible (archive ด้วย git mv, promote เอกสารกลาง) ต้องให้ user สั่งชัด ไม่ทำเป็น skill auto-invoke

package/src/.claude/commands/warnyin/update-codemaps.md

@@ -1,12 +1,12 @@
----
-description: Scan project structure and generate token-lean architecture codemaps (docs/codemap/)
----
-
-ทำหน้าที่เป็น codemap generator ตาม **playbook กลาง** ของ workflow มาตรฐาน
-
-1. อ่าน `.warnyin/workflow/codemap.md` ให้ครบก่อน แล้วทำตามทุกขั้นอย่างเคร่งครัด
-2. **Step 1 — สแกน:** ระบุชนิดโปรเจกต์, source dirs, entry points — fan-out sub-agent (Explore, read-only) ขนานต่อ component/พื้นที่ได้
-3. **Step 2 — สร้าง/อัปเดต `docs/codemap/`:** index / architecture / backend / frontend / data / dependencies — **เฉพาะไฟล์ที่ relevant**, รูปแบบ token-lean (< 1000 tokens/ไฟล์, path + signature, ASCII diagram)
-4. **Step 3 — diff detection:** มี codemap เดิม → คำนวณ % เปลี่ยนแปลง; **> 30% → แสดง diff + AskUserQuestion ขออนุมัติก่อนเขียนทับ**; ≤ 30% → อัปเดตเลย
-5. **Step 4 — metadata:** ใส่ freshness header `<!-- Generated: YYYY-MM-DD | Files scanned: N | Token estimate: ~X -->` ทุกไฟล์
-6. **Step 5 — report:** เขียน `.reports/codemap-diff.txt` (added/removed/modified, dependency ใหม่, architecture changes, staleness 90+ วัน) → สรุปผลให้ user
+---
+description: Scan project structure and generate token-lean architecture codemaps (docs/codemap/)
+---
+
+ทำหน้าที่เป็น codemap generator ตาม **playbook กลาง** ของ workflow มาตรฐาน
+
+1. อ่าน `.warnyin/workflow/codemap.md` ให้ครบก่อน แล้วทำตามทุกขั้นอย่างเคร่งครัด
+2. **Step 1 — สแกน:** ระบุชนิดโปรเจกต์, source dirs, entry points — fan-out sub-agent (Explore, read-only) ขนานต่อ component/พื้นที่ได้
+3. **Step 2 — สร้าง/อัปเดต `docs/codemap/`:** index / architecture / backend / frontend / data / dependencies — **เฉพาะไฟล์ที่ relevant**, รูปแบบ token-lean (< 1000 tokens/ไฟล์, path + signature, ASCII diagram)
+4. **Step 3 — diff detection:** มี codemap เดิม → คำนวณ % เปลี่ยนแปลง; **> 30% → แสดง diff + AskUserQuestion ขออนุมัติก่อนเขียนทับ**; ≤ 30% → อัปเดตเลย
+5. **Step 4 — metadata:** ใส่ freshness header `<!-- Generated: YYYY-MM-DD | Files scanned: N | Token estimate: ~X -->` ทุกไฟล์
+6. **Step 5 — report:** เขียน `.reports/codemap-diff.txt` (added/removed/modified, dependency ใหม่, architecture changes, staleness 90+ วัน) → สรุปผลให้ user

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

@@ -1,20 +1,20 @@
----
-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 ที่โล่ง (สถานะงานอยู่ในไฟล์ `docs/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
-   - **regression baseline:** อ่าน `docs/features/<name>/spec.md` ของ feature ที่ topic แตะด้วย (ดูจาก Spec delta ใน `design.md`) — scenario เดิม = regression case, scenario ใน delta = test case ใหม่ (รายละเอียดดู playbook §2/§3/§4 — ไม่ทำซ้ำที่นี่)
-4. **guideline:** อ่าน `docs/techstack/<component>/test.md` ว่าเทสยังไง (เช่น FE: e2e smoke ผ่าน playwright-cli) — ไม่มีก็เสนอวิธีแล้วเขียนแผนเอง; ดู `docs/infra.md` สำหรับ local env
-5. **เขียนแผนลง** `docs/stages/<slug>/test.md`
-6. **เทสจริงใน local env:** รัน service ที่เกี่ยวข้อง (ใช้ skill `run`/`verify` ช่วย launch ได้) → รันเทสตามแผน; FE → e2e smoke + ตรวจ UX/UI
-7. **ข้อไหนไม่ผ่าน → แก้ → rerun** วนจนผ่าน **นับจำนวนการแก้ไข**; เจอปัญหา → อ่าน `docs/troubleshooting.md` ก่อน, ปัญหายาก/ซ้ำที่แก้ได้ → บันทึก `docs/stages/<slug>/troubleshooting.md`
-8. **ถ้านาน/วนหลายรอบเกินไป → ถาม user ทีละข้อ + เสนอคำตอบที่แนะนำ** (อย่าวนเงียบไม่จบ)
-9. **เขียนสรุป** `docs/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 ที่โล่ง (สถานะงานอยู่ในไฟล์ `docs/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
+   - **regression baseline:** อ่าน `docs/features/<name>/spec.md` ของ feature ที่ topic แตะด้วย (ดูจาก Spec delta ใน `design.md`) — scenario เดิม = regression case, scenario ใน delta = test case ใหม่ (รายละเอียดดู playbook §2/§3/§4 — ไม่ทำซ้ำที่นี่)
+4. **guideline:** อ่าน `docs/techstack/<component>/test.md` ว่าเทสยังไง (เช่น FE: e2e smoke ผ่าน playwright-cli) — ไม่มีก็เสนอวิธีแล้วเขียนแผนเอง; ดู `docs/infra.md` สำหรับ local env
+5. **เขียนแผนลง** `docs/stages/<slug>/test.md`
+6. **เทสจริงใน local env:** รัน service ที่เกี่ยวข้อง (ใช้ skill `run`/`verify` ช่วย launch ได้) → รันเทสตามแผน; FE → e2e smoke + ตรวจ UX/UI
+7. **ข้อไหนไม่ผ่าน → แก้ → rerun** วนจนผ่าน **นับจำนวนการแก้ไข**; เจอปัญหา → อ่าน `docs/troubleshooting.md` ก่อน, ปัญหายาก/ซ้ำที่แก้ได้ → บันทึก `docs/stages/<slug>/troubleshooting.md`
+8. **ถ้านาน/วนหลายรอบเกินไป → ถาม user ทีละข้อ + เสนอคำตอบที่แนะนำ** (อย่าวนเงียบไม่จบ)
+9. **เขียนสรุป** `docs/stages/<slug>/verify.md` (ผลเทส + รายการแก้ไข + จำนวนรอบ + ผล UXUI) → เสนอเข้า SHIP ด้วย `/warnyin:ship`
+
+หมายเหตุ: ห้ามแตะไฟล์กลางใน `docs/` — `test.md` เขียนระดับ topic ก่อน รอ SHIP merge. เกณฑ์ปิดดู Gate ข้อ 6 ของ playbook

package/src/.claude/skills/explore/SKILL.md

@@ -1,8 +1,8 @@
----
-name: explore
-description: สำรวจ/ตอบคำถามเกี่ยวกับโปรเจกต์แบบ read-only — ไม่สร้าง artifact ใดๆ จบที่คำตอบในแชท
-when_to_use: เมื่อต้องการเข้าใจ/ตอบคำถามเกี่ยวกับโครงสร้าง โค้ด หรือ logic ของโปรเจกต์ โดยไม่ต้องสร้างหรือแก้ไฟล์
-allowed-tools: Read, Grep, Glob, Bash(find:*), Bash(ls:*), Bash(grep:*)
----
-
-ทำหน้าที่เป็น explorer ตาม **playbook กลาง** ของ workflow มาตรฐาน — อ่าน `.warnyin/workflow/explore.md` ให้ครบก่อน แล้วทำตามทุกหลักการอย่างเคร่งครัด (**read-only เด็ดขาด — ห้ามสร้าง/แก้/ลบไฟล์ใดๆ**, อ้าง `path:line`; ชี้ playbook ไม่ duplicate) — รับหัวข้อ/คำถามจาก request; ถ้าไม่ระบุ → ถาม user ว่าอยากสำรวจเรื่องอะไร
+---
+name: explore
+description: สำรวจ/ตอบคำถามเกี่ยวกับโปรเจกต์แบบ read-only — ไม่สร้าง artifact ใดๆ จบที่คำตอบในแชท
+when_to_use: เมื่อต้องการเข้าใจ/ตอบคำถามเกี่ยวกับโครงสร้าง โค้ด หรือ logic ของโปรเจกต์ โดยไม่ต้องสร้างหรือแก้ไฟล์
+allowed-tools: Read, Grep, Glob, Bash(find:*), Bash(ls:*), Bash(grep:*)
+---
+
+ทำหน้าที่เป็น explorer ตาม **playbook กลาง** ของ workflow มาตรฐาน — อ่าน `.warnyin/workflow/explore.md` ให้ครบก่อน แล้วทำตามทุกหลักการอย่างเคร่งครัด (**read-only เด็ดขาด — ห้ามสร้าง/แก้/ลบไฟล์ใดๆ**, อ้าง `path:line`; ชี้ playbook ไม่ duplicate) — รับหัวข้อ/คำถามจาก request; ถ้าไม่ระบุ → ถาม user ว่าอยากสำรวจเรื่องอะไร

package/src/.claude/skills/next/SKILL.md

@@ -1,8 +1,8 @@
----
-name: next
-description: เช็คงานค้างทุก topic + แนะนำขั้นตอน/command ถัดไป แบบ read-only — ไม่สร้าง/แก้ไฟล์ใดๆ
-when_to_use: เมื่อต้องการรู้ว่าแต่ละ topic ค้างอยู่ stage ไหน + ควรรัน command อะไรถัดไป
-allowed-tools: Read, Grep, Glob, Bash(find:*), Bash(ls:*), Bash(grep:*)
----
-
-ทำหน้าที่เป็น status reporter ตาม **playbook กลาง** ของ workflow มาตรฐาน — อ่าน `.warnyin/workflow/next.md` ให้ครบก่อน แล้วทำตามทุกหลักการอย่างเคร่งครัด (**read-only เด็ดขาด — ห้ามสร้าง/แก้/ลบไฟล์ใดๆ**, สรุปจาก evidence ในไฟล์จริง, แนะนำแล้วหยุด; ชี้ playbook ไม่ duplicate) — รับ slug จาก request (ไม่ระบุ = สแกนทุก topic ใน `docs/stages/` ยกเว้น `achieved/`)
+---
+name: next
+description: เช็คงานค้างทุก topic + แนะนำขั้นตอน/command ถัดไป แบบ read-only — ไม่สร้าง/แก้ไฟล์ใดๆ
+when_to_use: เมื่อต้องการรู้ว่าแต่ละ topic ค้างอยู่ stage ไหน + ควรรัน command อะไรถัดไป
+allowed-tools: Read, Grep, Glob, Bash(find:*), Bash(ls:*), Bash(grep:*)
+---
+
+ทำหน้าที่เป็น status reporter ตาม **playbook กลาง** ของ workflow มาตรฐาน — อ่าน `.warnyin/workflow/next.md` ให้ครบก่อน แล้วทำตามทุกหลักการอย่างเคร่งครัด (**read-only เด็ดขาด — ห้ามสร้าง/แก้/ลบไฟล์ใดๆ**, สรุปจาก evidence ในไฟล์จริง, แนะนำแล้วหยุด; ชี้ playbook ไม่ duplicate) — รับ slug จาก request (ไม่ระบุ = สแกนทุก topic ใน `docs/stages/` ยกเว้น `achieved/`)

package/src/.claude/skills/update-codemaps/SKILL.md

@@ -1,8 +1,8 @@
----
-name: update-codemaps
-description: Scan project structure and generate token-lean architecture codemaps (docs/codemap/)
-when_to_use: หลังเพิ่ม/ย้าย/ลบไฟล์ หรือเปลี่ยนโครงสร้างโปรเจกต์ → refresh docs/codemap/ ให้ตรงโครงจริง
-allowed-tools: Read, Grep, Glob, Bash(find:*), Bash(ls:*), Bash(grep:*)
----
-
-ทำหน้าที่เป็น codemap generator ตาม **playbook กลาง** ของ workflow มาตรฐาน — อ่าน `.warnyin/workflow/codemap.md` ให้ครบก่อน แล้วทำตามทุกขั้นอย่างเคร่งครัด (ชี้ playbook ไม่ duplicate ขั้นตอน)
+---
+name: update-codemaps
+description: Scan project structure and generate token-lean architecture codemaps (docs/codemap/)
+when_to_use: หลังเพิ่ม/ย้าย/ลบไฟล์ หรือเปลี่ยนโครงสร้างโปรเจกต์ → refresh docs/codemap/ ให้ตรงโครงจริง
+allowed-tools: Read, Grep, Glob, Bash(find:*), Bash(ls:*), Bash(grep:*)
+---
+
+ทำหน้าที่เป็น codemap generator ตาม **playbook กลาง** ของ workflow มาตรฐาน — อ่าน `.warnyin/workflow/codemap.md` ให้ครบก่อน แล้วทำตามทุกขั้นอย่างเคร่งครัด (ชี้ playbook ไม่ duplicate ขั้นตอน)

package/src/.warnyin/installer/templates/CLAUDE.md

@@ -1,29 +1,29 @@
-# CLAUDE.md
-
-โปรเจกต์นี้ใช้ **Warnyin Standard Workflow** — มาตรฐานกลางของ 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 ของงานจริงเก็บใน `docs/stages/<slug>/` (copy จาก template `.warnyin/template/stages/[topic]/`)
-- ความรู้ถาวรระดับโปรเจกต์อยู่ใน `docs/` — เริ่มอ่าน `docs/project.md` เสมอใน Discovery
-
-## Slash commands (namespace `warnyin:`)
-- `/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`)
-- `/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`)
-
-## รองรับหลาย AI
-Claude Code อ่าน `.claude/` + ไฟล์นี้, ส่วน Codex/Antigravity อ่าน `AGENTS.md`
-ทุกเครื่องชี้กลับมาที่ playbook กลางชุดเดียวกันใน `.warnyin/workflow/stages/` — ดูภาพรวมที่ `.warnyin/workflow/README.md`
-
-## อัปเดต workflow
-`npx @warnyin/agents --update` — เขียนทับเฉพาะ playbook กลาง (`.warnyin/workflow/`, `.claude/commands/warnyin/`, template `.warnyin/template/stages/[topic]/`) ไม่แตะ `docs/` และงานจริงใน `docs/stages/`
+# CLAUDE.md
+
+โปรเจกต์นี้ใช้ **Warnyin Standard Workflow** — มาตรฐานกลางของ 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 ของงานจริงเก็บใน `docs/stages/<slug>/` (copy จาก template `.warnyin/template/stages/[topic]/`)
+- ความรู้ถาวรระดับโปรเจกต์อยู่ใน `docs/` — เริ่มอ่าน `docs/project.md` เสมอใน Discovery
+
+## Slash commands (namespace `warnyin:`)
+- `/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`)
+- `/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`)
+
+## รองรับหลาย AI
+Claude Code อ่าน `.claude/` + ไฟล์นี้, ส่วน Codex/Antigravity อ่าน `AGENTS.md`
+ทุกเครื่องชี้กลับมาที่ playbook กลางชุดเดียวกันใน `.warnyin/workflow/stages/` — ดูภาพรวมที่ `.warnyin/workflow/README.md`
+
+## อัปเดต workflow
+`npx @warnyin/agents --update` — เขียนทับเฉพาะ playbook กลาง (`.warnyin/workflow/`, `.claude/commands/warnyin/`, template `.warnyin/template/stages/[topic]/`) ไม่แตะ `docs/` และงานจริงใน `docs/stages/`

package/src/.warnyin/template/docs/codemap/index.md

@@ -1,18 +1,18 @@
-# Code Map — Index
-
-> สารบัญ codemap ทั้งชุด — สร้าง/อัปเดตด้วย `/warnyin:update-codemaps` (playbook: `.warnyin/workflow/codemap.md`)
-> ทุกไฟล์ต้อง token-lean (< 1000 tokens) + freshness header + ตรงโค้ดจริงเสมอ
-
-## Codemap files
-<!-- ลิงก์เฉพาะไฟล์ที่ relevant กับโปรเจกต์ -->
-- [architecture.md](architecture.md) — system diagram, service boundary, data flow
-- [backend.md](backend.md) — routes, middleware, service → repo mapping
-- [frontend.md](frontend.md) — page tree, component hierarchy, state
-- [data.md](data.md) — ตาราง DB, relationship, migrations
-- [dependencies.md](dependencies.md) — external service, third-party, shared lib
-
-## Component ทั้งหมด
-<!-- ชื่อ + หน้าที่ + path — รายละเอียดต่อ component ดู docs/techstack/<component>/structure.md -->
-
-## จุดเข้า (entry points)
-<!-- main/server/cli/cron — ไฟล์ไหนคือประตูเข้าแต่ละทาง -->
+# Code Map — Index
+
+> สารบัญ codemap ทั้งชุด — สร้าง/อัปเดตด้วย `/warnyin:update-codemaps` (playbook: `.warnyin/workflow/codemap.md`)
+> ทุกไฟล์ต้อง token-lean (< 1000 tokens) + freshness header + ตรงโค้ดจริงเสมอ
+
+## Codemap files
+<!-- ลิงก์เฉพาะไฟล์ที่ relevant กับโปรเจกต์ -->
+- [architecture.md](architecture.md) — system diagram, service boundary, data flow
+- [backend.md](backend.md) — routes, middleware, service → repo mapping
+- [frontend.md](frontend.md) — page tree, component hierarchy, state
+- [data.md](data.md) — ตาราง DB, relationship, migrations
+- [dependencies.md](dependencies.md) — external service, third-party, shared lib
+
+## Component ทั้งหมด
+<!-- ชื่อ + หน้าที่ + path — รายละเอียดต่อ component ดู docs/techstack/<component>/structure.md -->
+
+## จุดเข้า (entry points)
+<!-- main/server/cli/cron — ไฟล์ไหนคือประตูเข้าแต่ละทาง -->

package/src/.warnyin/template/docs/features/[feature-name]/business.md

@@ -1,5 +1,5 @@
-# Business — <ชื่อ feature>
-
-> what & why เชิงธุรกิจของ feature — SHIP ยกมาจาก `business.md`/`proposal.md` ของ topic
-
-<!-- goal · persona/ใครได้ประโยชน์ · คุณค่า/success metric · scope ที่จงใจไม่ทำ -->
+# Business — <ชื่อ feature>
+
+> what & why เชิงธุรกิจของ feature — SHIP ยกมาจาก `business.md`/`proposal.md` ของ topic
+
+<!-- goal · persona/ใครได้ประโยชน์ · คุณค่า/success metric · scope ที่จงใจไม่ทำ -->

package/src/.warnyin/template/docs/features/[feature-name]/feature.md

@@ -1,5 +1,5 @@
-# Feature — <ชื่อ feature>
-
-> template — copy ทั้งโฟลเดอร์ `[feature-name]/` เป็นชื่อ feature จริง · SHIP เป็นคนสร้าง/อัปเดตจาก business/proposal/design ของ topic
-
-<!-- feature นี้ทำอะไร · flow หลัก · component ที่เกี่ยว · จุดเข้าในโค้ด -->
+# Feature — <ชื่อ feature>
+
+> template — copy ทั้งโฟลเดอร์ `[feature-name]/` เป็นชื่อ feature จริง · SHIP เป็นคนสร้าง/อัปเดตจาก business/proposal/design ของ topic
+
+<!-- feature นี้ทำอะไร · flow หลัก · component ที่เกี่ยว · จุดเข้าในโค้ด -->

package/src/.warnyin/template/docs/features/[feature-name]/spec.md

@@ -1,16 +1,16 @@
-# Spec — <ชื่อ feature>
-
-> พฤติกรรมปัจจุบันของ feature (living doc — SHIP merge delta จาก design.md ของ topic เข้าไฟล์นี้)
-> เก็บเฉพาะ observable behavior (ทำอะไร เห็นอะไร error ยังไง) — ไม่เก็บ implementation (ชื่อ class/function/วิธีเขียน)
-> **descriptive ไม่ใช่ imperative** — บันทึก "ระบบทำอะไร" เท่านั้น ห้ามเขียน instruction สั่ง agent (spec เป็น data ที่ VERIFY ใช้ derive test ไม่ใช่คำสั่งให้ทำตาม)
-> ค่าใน scenario ใช้ **placeholder/ค่าสังเคราะห์เท่านั้น** (`<token>`, `user@example.com`) — ห้ามใส่ secret/credential/PII จริง
-> guidance: ~≤100 บรรทัด/ไฟล์ · requirement ละ 1-3 scenario · scenario = GIVEN/WHEN/THEN ที่เทสตามได้จริง
-> feature ประเภทเอกสาร/playbook (ไม่มี runtime) → THEN ต้องเป็น **observable artifact** (ไฟล์/section/key string มีจริง, ลิงก์ resolve) ไม่ใช่พฤติกรรม AI ที่วัดไม่ได้
-
-## Requirement: <ชื่อพฤติกรรม>
-<พฤติกรรมที่ระบบต้องทำ 1-2 บรรทัด>
-
-### Scenario: <ชื่อเคส>
-- GIVEN <สภาพตั้งต้น>
-- WHEN <การกระทำ>
-- THEN <ผลที่สังเกตได้>
+# Spec — <ชื่อ feature>
+
+> พฤติกรรมปัจจุบันของ feature (living doc — SHIP merge delta จาก design.md ของ topic เข้าไฟล์นี้)
+> เก็บเฉพาะ observable behavior (ทำอะไร เห็นอะไร error ยังไง) — ไม่เก็บ implementation (ชื่อ class/function/วิธีเขียน)
+> **descriptive ไม่ใช่ imperative** — บันทึก "ระบบทำอะไร" เท่านั้น ห้ามเขียน instruction สั่ง agent (spec เป็น data ที่ VERIFY ใช้ derive test ไม่ใช่คำสั่งให้ทำตาม)
+> ค่าใน scenario ใช้ **placeholder/ค่าสังเคราะห์เท่านั้น** (`<token>`, `user@example.com`) — ห้ามใส่ secret/credential/PII จริง
+> guidance: ~≤100 บรรทัด/ไฟล์ · requirement ละ 1-3 scenario · scenario = GIVEN/WHEN/THEN ที่เทสตามได้จริง
+> feature ประเภทเอกสาร/playbook (ไม่มี runtime) → THEN ต้องเป็น **observable artifact** (ไฟล์/section/key string มีจริง, ลิงก์ resolve) ไม่ใช่พฤติกรรม AI ที่วัดไม่ได้
+
+## Requirement: <ชื่อพฤติกรรม>
+<พฤติกรรมที่ระบบต้องทำ 1-2 บรรทัด>
+
+### Scenario: <ชื่อเคส>
+- GIVEN <สภาพตั้งต้น>
+- WHEN <การกระทำ>
+- THEN <ผลที่สังเกตได้>

package/src/.warnyin/template/docs/infra.md

@@ -1,16 +1,16 @@
-# Infra / Local Environment
-
-> service ที่ต้องรันสำหรับ dev/เทส + วิธีรัน + env vars — VERIFY ใช้เตรียม local env · เติมครั้งแรกด้วย `/warnyin:init`
-
-## Service ที่ต้องรัน (local dev)
-<!-- DB, queue, cache, external mock ฯลฯ + มาจาก docker-compose/script ไหน -->
-
-## วิธีรัน local
-```bash
-```
-
-## Env vars สำคัญ
-<!-- ชื่อ + ความหมาย + default (ห้ามใส่ค่า secret จริง) -->
-
-## Environment อื่น (staging/prod)
-<!-- เท่าที่เกี่ยวกับการพัฒนา/เทส -->
+# Infra / Local Environment
+
+> service ที่ต้องรันสำหรับ dev/เทส + วิธีรัน + env vars — VERIFY ใช้เตรียม local env · เติมครั้งแรกด้วย `/warnyin:init`
+
+## Service ที่ต้องรัน (local dev)
+<!-- DB, queue, cache, external mock ฯลฯ + มาจาก docker-compose/script ไหน -->
+
+## วิธีรัน local
+```bash
+```
+
+## Env vars สำคัญ
+<!-- ชื่อ + ความหมาย + default (ห้ามใส่ค่า secret จริง) -->
+
+## Environment อื่น (staging/prod)
+<!-- เท่าที่เกี่ยวกับการพัฒนา/เทส -->

package/src/.warnyin/template/docs/project.md

@@ -1,18 +1,18 @@
-# Project — <ชื่อโปรเจกต์>
-
-> ★ จุดเริ่มของ Discovery — AI อ่านไฟล์นี้ก่อนเสมอ · เติมครั้งแรกด้วย `/warnyin:init` (สัมภาษณ์ user + วิเคราะห์โค้ด)
-
-## โปรเจกต์นี้คืออะไร
-<!-- ทำอะไร เพื่อใคร แก้ปัญหาอะไร — 2-4 บรรทัด -->
-
-## เป้าหมาย / success metric
-<!-- วัดผลได้ ไม่ใช่ "น่าจะดี" -->
-
-## ลูกค้า / ผู้ใช้หลัก (persona)
-
-## ขอบเขต
-- **in:**
-- **out (จงใจไม่ทำ):**
-
-## ข้อจำกัด / บริบทสำคัญ
-<!-- กฎหมาย/นโยบาย/ระบบเดิม/ระบบภายนอก -->
+# Project — <ชื่อโปรเจกต์>
+
+> ★ จุดเริ่มของ Discovery — AI อ่านไฟล์นี้ก่อนเสมอ · เติมครั้งแรกด้วย `/warnyin:init` (สัมภาษณ์ user + วิเคราะห์โค้ด)
+
+## โปรเจกต์นี้คืออะไร
+<!-- ทำอะไร เพื่อใคร แก้ปัญหาอะไร — 2-4 บรรทัด -->
+
+## เป้าหมาย / success metric
+<!-- วัดผลได้ ไม่ใช่ "น่าจะดี" -->
+
+## ลูกค้า / ผู้ใช้หลัก (persona)
+
+## ขอบเขต
+- **in:**
+- **out (จงใจไม่ทำ):**
+
+## ข้อจำกัด / บริบทสำคัญ
+<!-- กฎหมาย/นโยบาย/ระบบเดิม/ระบบภายนอก -->

package/src/.warnyin/template/docs/rule.md

@@ -1,7 +1,7 @@
-# Global Rules
-
-> กฎระดับโปรเจกต์ที่ **ทุก component** ต้อง follow — กฎเฉพาะ component อยู่ที่ `docs/techstack/<component>/rule.md`
-> SHIP เป็นคน promote กฎใหม่เข้ามา (จาก note "รอ SHIP" ใน tasks) — ระหว่างงานห้ามแก้ไฟล์นี้ตรงๆ
-
-<!-- ตัวอย่าง: ทุก commit ต้องผ่าน lint, ห้าม hardcode secret, error message ห้าม leak ข้อมูลภายใน -->
--
+# Global Rules
+
+> กฎระดับโปรเจกต์ที่ **ทุก component** ต้อง follow — กฎเฉพาะ component อยู่ที่ `docs/techstack/<component>/rule.md`
+> SHIP เป็นคน promote กฎใหม่เข้ามา (จาก note "รอ SHIP" ใน tasks) — ระหว่างงานห้ามแก้ไฟล์นี้ตรงๆ
+
+<!-- ตัวอย่าง: ทุก commit ต้องผ่าน lint, ห้าม hardcode secret, error message ห้าม leak ข้อมูลภายใน -->
+-

package/src/.warnyin/template/docs/techstack/[component]/about.md

@@ -1,6 +1,6 @@
-# About — <ชื่อ component>
-
-> template — copy ทั้งโฟลเดอร์ `[component]/` เป็นชื่อ component จริง (เช่น `api-service/`, `web-frontend/`)
-> ปกติ `/warnyin:init` สร้างให้อัตโนมัติจากการวิเคราะห์โปรเจกต์
-
-<!-- component นี้คืออะไร ทำหน้าที่อะไร · ภาษา/framework/runtime · ขอบเขตความรับผิดชอบ -->
+# About — <ชื่อ component>
+
+> template — copy ทั้งโฟลเดอร์ `[component]/` เป็นชื่อ component จริง (เช่น `api-service/`, `web-frontend/`)
+> ปกติ `/warnyin:init` สร้างให้อัตโนมัติจากการวิเคราะห์โปรเจกต์
+
+<!-- component นี้คืออะไร ทำหน้าที่อะไร · ภาษา/framework/runtime · ขอบเขตความรับผิดชอบ -->

package/src/.warnyin/template/docs/techstack/[component]/rule.md

@@ -1,6 +1,6 @@
-# Rule — <ชื่อ component>
-
-> กฎที่ "ต้อง" follow ของ component นี้ — DESIGN ดึงไปใส่ `tasks/<task>/rule.md`, SHIP เป็นคน promote กฎใหม่เข้ามา
-
-<!-- กฎที่บังคับ เช่น: ห้าม query ตรงจาก controller, ทุก endpoint ต้องมี auth middleware, ... -->
--
+# Rule — <ชื่อ component>
+
+> กฎที่ "ต้อง" follow ของ component นี้ — DESIGN ดึงไปใส่ `tasks/<task>/rule.md`, SHIP เป็นคน promote กฎใหม่เข้ามา
+
+<!-- กฎที่บังคับ เช่น: ห้าม query ตรงจาก controller, ทุก endpoint ต้องมี auth middleware, ... -->
+-

package/src/.warnyin/template/docs/techstack/[component]/standard.md

@@ -1,6 +1,6 @@
-# Standard — <ชื่อ component>
-
-> pattern/convention การเขียนโค้ด + shared component ที่ต้อง reuse — DESIGN ดึงไปใส่ `tasks/<task>/standard.md`
-
-<!-- เช่น: โครงสร้าง module, naming, error handling pattern, รายการ shared component ที่ห้ามเขียนซ้ำ -->
--
+# Standard — <ชื่อ component>
+
+> pattern/convention การเขียนโค้ด + shared component ที่ต้อง reuse — DESIGN ดึงไปใส่ `tasks/<task>/standard.md`
+
+<!-- เช่น: โครงสร้าง module, naming, error handling pattern, รายการ shared component ที่ห้ามเขียนซ้ำ -->
+-

package/src/.warnyin/template/docs/techstack/[component]/structure.md

@@ -1,7 +1,7 @@
-# Structure — <ชื่อ component>
-
-> โครงสร้างโฟลเดอร์/โมดูลจริงของ component — SHIP อัปเดตเมื่อโครงสร้างเปลี่ยน
-
-<!-- tree โฟลเดอร์สำคัญ + ไฟล์/โมดูลไหนรับผิดชอบอะไร + จุดเข้า (entry point) -->
-```
-```
+# Structure — <ชื่อ component>
+
+> โครงสร้างโฟลเดอร์/โมดูลจริงของ component — SHIP อัปเดตเมื่อโครงสร้างเปลี่ยน
+
+<!-- tree โฟลเดอร์สำคัญ + ไฟล์/โมดูลไหนรับผิดชอบอะไร + จุดเข้า (entry point) -->
+```
+```

package/src/.warnyin/template/docs/techstack/[component]/test.md

@@ -1,7 +1,7 @@
-# Test — <ชื่อ component>
-
-> guideline ว่า component นี้เทสยังไง — VERIFY ใช้เป็นแผนตั้งต้น, SHIP merge แผนเทสใหม่จาก topic เข้ามา
-
-<!-- framework + คำสั่งรัน unit/integration · e2e ใช้อะไร (เช่น FE: e2e smoke ผ่าน playwright-cli) · วิธี seed ข้อมูลทดสอบ -->
-- unit:
-- e2e:
+# Test — <ชื่อ component>
+
+> guideline ว่า component นี้เทสยังไง — VERIFY ใช้เป็นแผนตั้งต้น, SHIP merge แผนเทสใหม่จาก topic เข้ามา
+
+<!-- framework + คำสั่งรัน unit/integration · e2e ใช้อะไร (เช่น FE: e2e smoke ผ่าน playwright-cli) · วิธี seed ข้อมูลทดสอบ -->
+- unit:
+- e2e: