@warnyin/agents 0.13.0 → 0.15.0

package/src/.warnyin/template/stages/[topic]/design.md

@@ -1,63 +1,63 @@
-# Design (How) — <ชื่อ change>
-
-> Output ของ DESIGN stage · playbook: `.warnyin/workflow/stages/design.md`
-> ออกแบบเชิงเทคนิคแบบ **vertical slice architecture** — แต่ละ slice ตัดผ่านทุก layer ทำงาน end-to-end
-
-## 1. ภาพรวมสถาปัตยกรรม
-- component/service ที่เกี่ยวข้อง (อิง `docs/techstack/*`):
-- แนวทางหลัก:
-
-## 2. Vertical slices
-> หนึ่ง slice = หนึ่งหน่วยคุณค่า end-to-end (UI → API → domain → data → test) → จะกลายเป็น 1 task
-> **ไม่แบ่งตาม layer แนวนอน**
-
-| # | Slice (ส่งมอบคุณค่าอะไร) | ตัดผ่าน layer ไหน | → task |
-|---|---|---|---|
-| 1 | | UI · API · domain · data · test | `tasks/<task-1>/` |
-| 2 | | | `tasks/<task-2>/` |
-
-## 3. Data model / schema
-- entity / ตาราง / field ที่เพิ่มหรือแก้:
-- migration (ถ้ามี):
-
-## 4. Interface / contract
-- API contract / event / interface ระหว่าง component:
-
-## 5. Flow
-- data-flow:
-- user-flow:
-
-## 6. ผลกระทบต่อระบบเดิม
-- จุดที่ต้องระวัง / backward compatibility:
-
-## 7. Dependency ระหว่าง slice/task
-> slice/task เชื่อมกันยังไง ลำดับการทำ — วาด DAG แล้ววัด width (กัน chain เผลอ)
-
-```
-task-1 ──▶ task-2 ──▶ task-3
-              └──▶ task-4
-```
-
-- **critical-path depth (longest chain):** <จำนวน wave ของ chain ที่ยาวที่สุด>
-- **max wave width:** <จำนวน task สูงสุดใน wave เดียว — >1 = ขนานได้>
-- **เหตุผลถ้า task ใดถูก serialize:** <ถ้า DAG เป็น chain เส้นตรง (ทุก wave 1 task) → ทำไม decouple ด้วย DAG-width toolkit (design.md §3 ข้อ 2) ไม่ได้>
-
-
-
-## 8. Test strategy ระดับ design
-- จะยืนยันว่า design ทำงานถูกอย่างไร (ภาพรวม — รายละเอียดอยู่ใน task spec):
-
-## 9. Spec delta (เทียบ docs/features/<name>/spec.md ปัจจุบัน)
-> พฤติกรรมที่ change นี้ เพิ่ม/แก้/ลบ — SHIP จะ merge ตามนี้แบบกึ่ง mechanical
-> change ไม่แตะพฤติกรรม feature (refactor/docs/tooling) → เขียน "ไม่มี delta" บรรทัดเดียวพอ
-
-### ADDED
-#### Requirement: <ชื่อ> (→ feature: <feature-name>)
-<พฤติกรรม + scenario ตาม format ของ spec.md>
-
-### MODIFIED
-#### Requirement: <ชื่อใหม่> (→ feature: <feature-name>) [เดิมชื่อ: <ชื่อเก่า> — ใส่เฉพาะกรณี rename]
-<เวอร์ชันใหม่เต็ม> _(เดิม: <สรุปสั้น>)_
-
-### REMOVED
-#### Requirement: <ชื่อเดิมใน spec> (→ feature: <feature-name>) — เหตุผลที่เลิก
+# Design (How) — <ชื่อ change>
+
+> Output ของ DESIGN stage · playbook: `.warnyin/workflow/stages/design.md`
+> ออกแบบเชิงเทคนิคแบบ **vertical slice architecture** — แต่ละ slice ตัดผ่านทุก layer ทำงาน end-to-end
+
+## 1. ภาพรวมสถาปัตยกรรม
+- component/service ที่เกี่ยวข้อง (อิง `docs/techstack/*`):
+- แนวทางหลัก:
+
+## 2. Vertical slices
+> หนึ่ง slice = หนึ่งหน่วยคุณค่า end-to-end (UI → API → domain → data → test) → จะกลายเป็น 1 task
+> **ไม่แบ่งตาม layer แนวนอน**
+
+| # | Slice (ส่งมอบคุณค่าอะไร) | ตัดผ่าน layer ไหน | → task |
+|---|---|---|---|
+| 1 | | UI · API · domain · data · test | `tasks/<task-1>/` |
+| 2 | | | `tasks/<task-2>/` |
+
+## 3. Data model / schema
+- entity / ตาราง / field ที่เพิ่มหรือแก้:
+- migration (ถ้ามี):
+
+## 4. Interface / contract
+- API contract / event / interface ระหว่าง component:
+
+## 5. Flow
+- data-flow:
+- user-flow:
+
+## 6. ผลกระทบต่อระบบเดิม
+- จุดที่ต้องระวัง / backward compatibility:
+
+## 7. Dependency ระหว่าง slice/task
+> slice/task เชื่อมกันยังไง ลำดับการทำ — วาด DAG แล้ววัด width (กัน chain เผลอ)
+
+```
+task-1 ──▶ task-2 ──▶ task-3
+              └──▶ task-4
+```
+
+- **critical-path depth (longest chain):** <จำนวน wave ของ chain ที่ยาวที่สุด>
+- **max wave width:** <จำนวน task สูงสุดใน wave เดียว — >1 = ขนานได้>
+- **เหตุผลถ้า task ใดถูก serialize:** <ถ้า DAG เป็น chain เส้นตรง (ทุก wave 1 task) → ทำไม decouple ด้วย DAG-width toolkit (design.md §3 ข้อ 2) ไม่ได้>
+
+
+
+## 8. Test strategy ระดับ design
+- จะยืนยันว่า design ทำงานถูกอย่างไร (ภาพรวม — รายละเอียดอยู่ใน task spec):
+
+## 9. Spec delta (เทียบ docs/features/<name>/spec.md ปัจจุบัน)
+> พฤติกรรมที่ change นี้ เพิ่ม/แก้/ลบ — SHIP จะ merge ตามนี้แบบกึ่ง mechanical
+> change ไม่แตะพฤติกรรม feature (refactor/docs/tooling) → เขียน "ไม่มี delta" บรรทัดเดียวพอ
+
+### ADDED
+#### Requirement: <ชื่อ> (→ feature: <feature-name>)
+<พฤติกรรม + scenario ตาม format ของ spec.md>
+
+### MODIFIED
+#### Requirement: <ชื่อใหม่> (→ feature: <feature-name>) [เดิมชื่อ: <ชื่อเก่า> — ใส่เฉพาะกรณี rename]
+<เวอร์ชันใหม่เต็ม> _(เดิม: <สรุปสั้น>)_
+
+### REMOVED
+#### Requirement: <ชื่อเดิมใน spec> (→ feature: <feature-name>) — เหตุผลที่เลิก

package/src/.warnyin/template/stages/[topic]/discovery.md

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

package/src/.warnyin/template/stages/[topic]/proposal.md

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

package/src/.warnyin/template/stages/[topic]/research.md

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

package/src/.warnyin/template/stages/[topic]/ship.md

@@ -1,32 +1,32 @@
-# Ship — <ชื่อ topic>
-
-> Output ของ SHIP stage · playbook: `.warnyin/workflow/stages/ship.md`
-> สรุปการส่งมอบ — เขียนหลังย้าย topic เข้า `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` แล้ว
-
-## 1. สรุป topic
-- ทำอะไร: <!-- หนึ่งย่อหน้า: topic นี้ทำอะไร ทำอย่างไร -->
-- ประเภท: ☐ feature ใหม่ / ☐ ปรับปรุง feature เดิม → `docs/features/<feature-name>/`
-
-## 2. เอกสารกลางที่อัปเดต
-| ไฟล์ | สาระที่ promote |
-|---|---|
-| `docs/features/<feature-name>/` | |
-| `docs/features/<feature-name>/spec.md` | <!-- merge Spec delta จาก design.md §9 --> |
-| `docs/techstack/<component>/rule.md` | |
-| `docs/techstack/<component>/standard.md` | |
-| `docs/techstack/<component>/structure.md` | |
-| `docs/techstack/<component>/test.md` | |
-| `docs/rule.md` | |
-| `docs/troubleshooting.md` | |
-| `docs/infra.md` / `docs/project.md` | <!-- ถ้าเกี่ยวข้อง --> |
-| `docs/codemap/` | |
-
-## 3. Learned rules (planned + emergent)
-> กฎ generalize ที่จับจาก topic นี้ — planned (`tasks/*/rule.md` §2) + emergent (บทเรียนตอน build/verify/troubleshooting). evidence บังคับ; ไม่มี evidence = ไม่ promote. ครอบทั้งที่ promote และที่ตัด.
-
-| rule (generalize) | evidence (pointer + artifact) | scope (`component:<c>` / `project`) | promote? (✅ / ✂️ + เหตุผล) |
-|---|---|---|---|
-| | | | |
-
-## 4. Archive
-- ย้ายจาก `docs/stages/<slug>/` → `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` เมื่อ <YYYY-MM-DD>
+# Ship — <ชื่อ topic>
+
+> Output ของ SHIP stage · playbook: `.warnyin/workflow/stages/ship.md`
+> สรุปการส่งมอบ — เขียนหลังย้าย topic เข้า `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` แล้ว
+
+## 1. สรุป topic
+- ทำอะไร: <!-- หนึ่งย่อหน้า: topic นี้ทำอะไร ทำอย่างไร -->
+- ประเภท: ☐ feature ใหม่ / ☐ ปรับปรุง feature เดิม → `docs/features/<feature-name>/`
+
+## 2. เอกสารกลางที่อัปเดต
+| ไฟล์ | สาระที่ promote |
+|---|---|
+| `docs/features/<feature-name>/` | |
+| `docs/features/<feature-name>/spec.md` | <!-- merge Spec delta จาก design.md §9 --> |
+| `docs/techstack/<component>/rule.md` | |
+| `docs/techstack/<component>/standard.md` | |
+| `docs/techstack/<component>/structure.md` | |
+| `docs/techstack/<component>/test.md` | |
+| `docs/rule.md` | |
+| `docs/troubleshooting.md` | |
+| `docs/infra.md` / `docs/project.md` | <!-- ถ้าเกี่ยวข้อง --> |
+| `docs/codemap/` | |
+
+## 3. Learned rules (planned + emergent)
+> กฎ generalize ที่จับจาก topic นี้ — planned (`tasks/*/rule.md` §2) + emergent (บทเรียนตอน build/verify/troubleshooting). evidence บังคับ; ไม่มี evidence = ไม่ promote. ครอบทั้งที่ promote และที่ตัด.
+
+| rule (generalize) | evidence (pointer + artifact) | scope (`component:<c>` / `project`) | promote? (✅ / ✂️ + เหตุผล) |
+|---|---|---|---|
+| | | | |
+
+## 4. Archive
+- ย้ายจาก `docs/stages/<slug>/` → `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` เมื่อ <YYYY-MM-DD>

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

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

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

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