@warnyin/agents 0.5.0 → 0.5.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude/commands/warnyin/build.md +29 -29
- package/.claude/commands/warnyin/design.md +24 -24
- package/.claude/commands/warnyin/discovery.md +17 -17
- package/.claude/commands/warnyin/init.md +1 -1
- package/.claude/commands/warnyin/verify.md +19 -19
- package/AGENTS.md +48 -48
- package/CLAUDE.md +40 -40
- package/package.json +1 -1
- package/warnyin/template/stages/[topic]/build.md +58 -58
- package/warnyin/template/stages/[topic]/business.md +21 -21
- package/warnyin/template/stages/[topic]/design.md +42 -42
- package/warnyin/template/stages/[topic]/discovery.md +69 -69
- package/warnyin/template/stages/[topic]/proposal.md +43 -43
- package/warnyin/template/stages/[topic]/research.md +49 -49
- package/warnyin/template/stages/[topic]/tasks/[task-name]/rule.md +13 -13
- package/warnyin/template/stages/[topic]/tasks/[task-name]/spec.md +36 -36
- package/warnyin/template/stages/[topic]/tasks/[task-name]/standard.md +21 -21
- package/warnyin/template/stages/[topic]/tasks/[task-name]/task.md +39 -39
- package/warnyin/template/stages/[topic]/test.md +46 -46
- package/warnyin/template/stages/[topic]/troubleshooting.md +34 -34
- package/warnyin/template/stages/[topic]/verify.md +44 -44
- package/warnyin/workflow/README.md +94 -94
- package/warnyin/workflow/init.md +68 -4
- package/warnyin/workflow/scripts/build-wave.mjs +107 -107
- package/warnyin/workflow/stages/build.md +94 -94
- package/warnyin/workflow/stages/design.md +116 -116
- package/warnyin/workflow/stages/discovery.md +77 -77
- package/warnyin/workflow/stages/verify.md +71 -71
|
@@ -1,42 +1,42 @@
|
|
|
1
|
-
# Design (How) — <ชื่อ change>
|
|
2
|
-
|
|
3
|
-
> Output ของ DESIGN stage · playbook: `warnyin/workflow/stages/design.md`
|
|
4
|
-
> ออกแบบเชิงเทคนิคแบบ **vertical slice architecture** — แต่ละ slice ตัดผ่านทุก layer ทำงาน end-to-end
|
|
5
|
-
|
|
6
|
-
## 1. ภาพรวมสถาปัตยกรรม
|
|
7
|
-
- component/service ที่เกี่ยวข้อง (อิง `docs/techstack/*`):
|
|
8
|
-
- แนวทางหลัก:
|
|
9
|
-
|
|
10
|
-
## 2. Vertical slices
|
|
11
|
-
> หนึ่ง slice = หนึ่งหน่วยคุณค่า end-to-end (UI → API → domain → data → test) → จะกลายเป็น 1 task
|
|
12
|
-
> **ไม่แบ่งตาม layer แนวนอน**
|
|
13
|
-
|
|
14
|
-
| # | Slice (ส่งมอบคุณค่าอะไร) | ตัดผ่าน layer ไหน | → task |
|
|
15
|
-
|---|---|---|---|
|
|
16
|
-
| 1 | | UI · API · domain · data · test | `tasks/<task-1>/` |
|
|
17
|
-
| 2 | | | `tasks/<task-2>/` |
|
|
18
|
-
|
|
19
|
-
## 3. Data model / schema
|
|
20
|
-
- entity / ตาราง / field ที่เพิ่มหรือแก้:
|
|
21
|
-
- migration (ถ้ามี):
|
|
22
|
-
|
|
23
|
-
## 4. Interface / contract
|
|
24
|
-
- API contract / event / interface ระหว่าง component:
|
|
25
|
-
|
|
26
|
-
## 5. Flow
|
|
27
|
-
- data-flow:
|
|
28
|
-
- user-flow:
|
|
29
|
-
|
|
30
|
-
## 6. ผลกระทบต่อระบบเดิม
|
|
31
|
-
- จุดที่ต้องระวัง / backward compatibility:
|
|
32
|
-
|
|
33
|
-
## 7. Dependency ระหว่าง slice/task
|
|
34
|
-
> slice/task เชื่อมกันยังไง ลำดับการทำ
|
|
35
|
-
|
|
36
|
-
```
|
|
37
|
-
task-1 ──▶ task-2 ──▶ task-3
|
|
38
|
-
└──▶ task-4
|
|
39
|
-
```
|
|
40
|
-
|
|
41
|
-
## 8. Test strategy ระดับ design
|
|
42
|
-
- จะยืนยันว่า design ทำงานถูกอย่างไร (ภาพรวม — รายละเอียดอยู่ใน task spec):
|
|
1
|
+
# Design (How) — <ชื่อ change>
|
|
2
|
+
|
|
3
|
+
> Output ของ DESIGN stage · playbook: `warnyin/workflow/stages/design.md`
|
|
4
|
+
> ออกแบบเชิงเทคนิคแบบ **vertical slice architecture** — แต่ละ slice ตัดผ่านทุก layer ทำงาน end-to-end
|
|
5
|
+
|
|
6
|
+
## 1. ภาพรวมสถาปัตยกรรม
|
|
7
|
+
- component/service ที่เกี่ยวข้อง (อิง `docs/techstack/*`):
|
|
8
|
+
- แนวทางหลัก:
|
|
9
|
+
|
|
10
|
+
## 2. Vertical slices
|
|
11
|
+
> หนึ่ง slice = หนึ่งหน่วยคุณค่า end-to-end (UI → API → domain → data → test) → จะกลายเป็น 1 task
|
|
12
|
+
> **ไม่แบ่งตาม layer แนวนอน**
|
|
13
|
+
|
|
14
|
+
| # | Slice (ส่งมอบคุณค่าอะไร) | ตัดผ่าน layer ไหน | → task |
|
|
15
|
+
|---|---|---|---|
|
|
16
|
+
| 1 | | UI · API · domain · data · test | `tasks/<task-1>/` |
|
|
17
|
+
| 2 | | | `tasks/<task-2>/` |
|
|
18
|
+
|
|
19
|
+
## 3. Data model / schema
|
|
20
|
+
- entity / ตาราง / field ที่เพิ่มหรือแก้:
|
|
21
|
+
- migration (ถ้ามี):
|
|
22
|
+
|
|
23
|
+
## 4. Interface / contract
|
|
24
|
+
- API contract / event / interface ระหว่าง component:
|
|
25
|
+
|
|
26
|
+
## 5. Flow
|
|
27
|
+
- data-flow:
|
|
28
|
+
- user-flow:
|
|
29
|
+
|
|
30
|
+
## 6. ผลกระทบต่อระบบเดิม
|
|
31
|
+
- จุดที่ต้องระวัง / backward compatibility:
|
|
32
|
+
|
|
33
|
+
## 7. Dependency ระหว่าง slice/task
|
|
34
|
+
> slice/task เชื่อมกันยังไง ลำดับการทำ
|
|
35
|
+
|
|
36
|
+
```
|
|
37
|
+
task-1 ──▶ task-2 ──▶ task-3
|
|
38
|
+
└──▶ task-4
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
## 8. Test strategy ระดับ design
|
|
42
|
+
- จะยืนยันว่า design ทำงานถูกอย่างไร (ภาพรวม — รายละเอียดอยู่ใน task spec):
|
|
@@ -1,69 +1,69 @@
|
|
|
1
|
-
# Discovery — <ชื่อหัวข้องาน>
|
|
2
|
-
|
|
3
|
-
> Output ของ Discovery stage · playbook: `warnyin/workflow/stages/discovery.md`
|
|
4
|
-
|
|
5
|
-
| | |
|
|
6
|
-
|---|---|
|
|
7
|
-
| **Slug** | `<kebab-case>` |
|
|
8
|
-
| **สถานะ** | `กำลังทำ` / `ผ่าน gate แล้ว` |
|
|
9
|
-
| **วันที่** | `YYYY-MM-DD` |
|
|
10
|
-
| **ผู้ร่วมตัดสินใจ** | `<ชื่อ>` |
|
|
11
|
-
| **เริ่มจาก** | อ้างอิง `docs/project.md` ส่วนไหน |
|
|
12
|
-
|
|
13
|
-
---
|
|
14
|
-
|
|
15
|
-
## 1. สรุปความเข้าใจร่วมกัน (one-liner)
|
|
16
|
-
> เราจะทำ **อะไร** ให้ **ใคร** เพื่อแก้ปัญหา **อะไร** — สรุปได้ใน 1-3 บรรทัด
|
|
17
|
-
|
|
18
|
-
## 2. Problem & Why now
|
|
19
|
-
- ปัญหา / โอกาส:
|
|
20
|
-
- ทำไมต้องทำตอนนี้:
|
|
21
|
-
- ผูกกับเป้าหมายโปรเจกต์ (จาก `docs/project.md`) อย่างไร:
|
|
22
|
-
|
|
23
|
-
## 3. Scope (กว้าง → แคบ)
|
|
24
|
-
**In scope (จะทำ)**
|
|
25
|
-
-
|
|
26
|
-
|
|
27
|
-
**Out of scope (จะไม่ทำในรอบนี้)**
|
|
28
|
-
-
|
|
29
|
-
|
|
30
|
-
## 4. Decision Log (เดินทีละกิ่งของ decision tree)
|
|
31
|
-
> หนึ่งแถว = หนึ่งการตัดสินใจ บันทึกทันทีที่ตกลงได้
|
|
32
|
-
|
|
33
|
-
| # | คำถาม / ประเด็น | ทางเลือก | คำตอบที่แนะนำ | ที่เลือกจริง | เหตุผล |
|
|
34
|
-
|---|---|---|---|---|---|
|
|
35
|
-
| 1 | | | | | |
|
|
36
|
-
| 2 | | | | | |
|
|
37
|
-
|
|
38
|
-
## 5. สมมติฐาน & ข้อจำกัด
|
|
39
|
-
- สมมติฐาน:
|
|
40
|
-
- ข้อจำกัด (เทคนิค/เวลา/ทรัพยากร/ระบบเดิม):
|
|
41
|
-
|
|
42
|
-
## 6. เกณฑ์ความสำเร็จ (วัดผลได้)
|
|
43
|
-
-
|
|
44
|
-
|
|
45
|
-
## 7. Feature ideas / ทางเลือกของวิธีแก้
|
|
46
|
-
> ไอเดียคร่าวๆ ที่จะส่งต่อให้ DESIGN พิจารณา (ยังไม่ลงรายละเอียดออกแบบ)
|
|
47
|
-
-
|
|
48
|
-
|
|
49
|
-
## 8. Open questions (ที่ยังค้าง)
|
|
50
|
-
> ต้องปิดทุกข้อที่ block การออกแบบ ก่อนผ่าน gate
|
|
51
|
-
- [ ]
|
|
52
|
-
|
|
53
|
-
## 9. ความเสี่ยงหลัก
|
|
54
|
-
-
|
|
55
|
-
|
|
56
|
-
## 10. ลิงก์ที่เกี่ยวข้อง
|
|
57
|
-
- Research: `./research.md`
|
|
58
|
-
- เอกสารโปรเจกต์: `docs/project.md`, `docs/...`
|
|
59
|
-
- โค้ด/ไฟล์ที่ตรวจสอบ:
|
|
60
|
-
|
|
61
|
-
---
|
|
62
|
-
|
|
63
|
-
## ✅ Gate → DESIGN (ดู `warnyin/workflow/stages/discovery.md` ข้อ 6)
|
|
64
|
-
- [ ] Problem / why-now ชัด ผูกกับ project.md
|
|
65
|
-
- [ ] Scope in/out ชัด
|
|
66
|
-
- [ ] Decision log ปิดทุกประเด็นสำคัญ ไม่มี open question ที่ block
|
|
67
|
-
- [ ] success criteria วัดผลได้
|
|
68
|
-
- [ ] สมมติฐาน/ข้อจำกัด/ความเสี่ยง บันทึกครบ
|
|
69
|
-
- [ ] user ยืนยัน "เข้าใจตรงกันแล้ว"
|
|
1
|
+
# Discovery — <ชื่อหัวข้องาน>
|
|
2
|
+
|
|
3
|
+
> Output ของ Discovery stage · playbook: `warnyin/workflow/stages/discovery.md`
|
|
4
|
+
|
|
5
|
+
| | |
|
|
6
|
+
|---|---|
|
|
7
|
+
| **Slug** | `<kebab-case>` |
|
|
8
|
+
| **สถานะ** | `กำลังทำ` / `ผ่าน gate แล้ว` |
|
|
9
|
+
| **วันที่** | `YYYY-MM-DD` |
|
|
10
|
+
| **ผู้ร่วมตัดสินใจ** | `<ชื่อ>` |
|
|
11
|
+
| **เริ่มจาก** | อ้างอิง `docs/project.md` ส่วนไหน |
|
|
12
|
+
|
|
13
|
+
---
|
|
14
|
+
|
|
15
|
+
## 1. สรุปความเข้าใจร่วมกัน (one-liner)
|
|
16
|
+
> เราจะทำ **อะไร** ให้ **ใคร** เพื่อแก้ปัญหา **อะไร** — สรุปได้ใน 1-3 บรรทัด
|
|
17
|
+
|
|
18
|
+
## 2. Problem & Why now
|
|
19
|
+
- ปัญหา / โอกาส:
|
|
20
|
+
- ทำไมต้องทำตอนนี้:
|
|
21
|
+
- ผูกกับเป้าหมายโปรเจกต์ (จาก `docs/project.md`) อย่างไร:
|
|
22
|
+
|
|
23
|
+
## 3. Scope (กว้าง → แคบ)
|
|
24
|
+
**In scope (จะทำ)**
|
|
25
|
+
-
|
|
26
|
+
|
|
27
|
+
**Out of scope (จะไม่ทำในรอบนี้)**
|
|
28
|
+
-
|
|
29
|
+
|
|
30
|
+
## 4. Decision Log (เดินทีละกิ่งของ decision tree)
|
|
31
|
+
> หนึ่งแถว = หนึ่งการตัดสินใจ บันทึกทันทีที่ตกลงได้
|
|
32
|
+
|
|
33
|
+
| # | คำถาม / ประเด็น | ทางเลือก | คำตอบที่แนะนำ | ที่เลือกจริง | เหตุผล |
|
|
34
|
+
|---|---|---|---|---|---|
|
|
35
|
+
| 1 | | | | | |
|
|
36
|
+
| 2 | | | | | |
|
|
37
|
+
|
|
38
|
+
## 5. สมมติฐาน & ข้อจำกัด
|
|
39
|
+
- สมมติฐาน:
|
|
40
|
+
- ข้อจำกัด (เทคนิค/เวลา/ทรัพยากร/ระบบเดิม):
|
|
41
|
+
|
|
42
|
+
## 6. เกณฑ์ความสำเร็จ (วัดผลได้)
|
|
43
|
+
-
|
|
44
|
+
|
|
45
|
+
## 7. Feature ideas / ทางเลือกของวิธีแก้
|
|
46
|
+
> ไอเดียคร่าวๆ ที่จะส่งต่อให้ DESIGN พิจารณา (ยังไม่ลงรายละเอียดออกแบบ)
|
|
47
|
+
-
|
|
48
|
+
|
|
49
|
+
## 8. Open questions (ที่ยังค้าง)
|
|
50
|
+
> ต้องปิดทุกข้อที่ block การออกแบบ ก่อนผ่าน gate
|
|
51
|
+
- [ ]
|
|
52
|
+
|
|
53
|
+
## 9. ความเสี่ยงหลัก
|
|
54
|
+
-
|
|
55
|
+
|
|
56
|
+
## 10. ลิงก์ที่เกี่ยวข้อง
|
|
57
|
+
- Research: `./research.md`
|
|
58
|
+
- เอกสารโปรเจกต์: `docs/project.md`, `docs/...`
|
|
59
|
+
- โค้ด/ไฟล์ที่ตรวจสอบ:
|
|
60
|
+
|
|
61
|
+
---
|
|
62
|
+
|
|
63
|
+
## ✅ Gate → DESIGN (ดู `warnyin/workflow/stages/discovery.md` ข้อ 6)
|
|
64
|
+
- [ ] Problem / why-now ชัด ผูกกับ project.md
|
|
65
|
+
- [ ] Scope in/out ชัด
|
|
66
|
+
- [ ] Decision log ปิดทุกประเด็นสำคัญ ไม่มี open question ที่ block
|
|
67
|
+
- [ ] success criteria วัดผลได้
|
|
68
|
+
- [ ] สมมติฐาน/ข้อจำกัด/ความเสี่ยง บันทึกครบ
|
|
69
|
+
- [ ] user ยืนยัน "เข้าใจตรงกันแล้ว"
|
|
@@ -1,43 +1,43 @@
|
|
|
1
|
-
# Proposal — <ชื่อ change>
|
|
2
|
-
|
|
3
|
-
> Output ของ DESIGN stage · playbook: `warnyin/workflow/stages/design.md`
|
|
4
|
-
> **what & why** ของ change นี้
|
|
5
|
-
|
|
6
|
-
| | |
|
|
7
|
-
|---|---|
|
|
8
|
-
| **Slug** | `<kebab-case>` |
|
|
9
|
-
| **ประเภท** | `feature` / `bugfix` / `refactor` / `docs` |
|
|
10
|
-
| **ขนาด** | `เล็ก` / `กลาง` / `ใหญ่` |
|
|
11
|
-
| **วันที่** | `YYYY-MM-DD` |
|
|
12
|
-
| **มาจาก Discovery?** | `./discovery.md` หรือ `ไม่มี` |
|
|
13
|
-
|
|
14
|
-
## 1. สรุป change (what)
|
|
15
|
-
> เราจะเปลี่ยน/สร้าง/แก้อะไร — 1-3 บรรทัด
|
|
16
|
-
|
|
17
|
-
## 2. ทำไม (why)
|
|
18
|
-
- ปัญหา/โอกาส:
|
|
19
|
-
- ผลถ้าไม่ทำ:
|
|
20
|
-
|
|
21
|
-
## 3. ทางเลือกที่พิจารณา
|
|
22
|
-
| ทางเลือก | ข้อดี | ข้อเสีย | เลือก? |
|
|
23
|
-
|---|---|---|---|
|
|
24
|
-
| A (แนะนำ) | | | ✅ |
|
|
25
|
-
| B | | | |
|
|
26
|
-
|
|
27
|
-
- เหตุผลที่เลือก:
|
|
28
|
-
|
|
29
|
-
## 4. Scope
|
|
30
|
-
**In scope**
|
|
31
|
-
-
|
|
32
|
-
|
|
33
|
-
**Out of scope**
|
|
34
|
-
-
|
|
35
|
-
|
|
36
|
-
## 5. ผลกระทบ & ความเสี่ยง
|
|
37
|
-
- ระบบ/ฟีเจอร์เดิมที่กระทบ:
|
|
38
|
-
- ความเสี่ยง + วิธีลดความเสี่ยง:
|
|
39
|
-
|
|
40
|
-
## 6. ลิงก์
|
|
41
|
-
- Design (how): `./design.md`
|
|
42
|
-
- Tasks: `./tasks/`
|
|
43
|
-
- Business: `./business.md` (ถ้ามี)
|
|
1
|
+
# Proposal — <ชื่อ change>
|
|
2
|
+
|
|
3
|
+
> Output ของ DESIGN stage · playbook: `warnyin/workflow/stages/design.md`
|
|
4
|
+
> **what & why** ของ change นี้
|
|
5
|
+
|
|
6
|
+
| | |
|
|
7
|
+
|---|---|
|
|
8
|
+
| **Slug** | `<kebab-case>` |
|
|
9
|
+
| **ประเภท** | `feature` / `bugfix` / `refactor` / `docs` |
|
|
10
|
+
| **ขนาด** | `เล็ก` / `กลาง` / `ใหญ่` |
|
|
11
|
+
| **วันที่** | `YYYY-MM-DD` |
|
|
12
|
+
| **มาจาก Discovery?** | `./discovery.md` หรือ `ไม่มี` |
|
|
13
|
+
|
|
14
|
+
## 1. สรุป change (what)
|
|
15
|
+
> เราจะเปลี่ยน/สร้าง/แก้อะไร — 1-3 บรรทัด
|
|
16
|
+
|
|
17
|
+
## 2. ทำไม (why)
|
|
18
|
+
- ปัญหา/โอกาส:
|
|
19
|
+
- ผลถ้าไม่ทำ:
|
|
20
|
+
|
|
21
|
+
## 3. ทางเลือกที่พิจารณา
|
|
22
|
+
| ทางเลือก | ข้อดี | ข้อเสีย | เลือก? |
|
|
23
|
+
|---|---|---|---|
|
|
24
|
+
| A (แนะนำ) | | | ✅ |
|
|
25
|
+
| B | | | |
|
|
26
|
+
|
|
27
|
+
- เหตุผลที่เลือก:
|
|
28
|
+
|
|
29
|
+
## 4. Scope
|
|
30
|
+
**In scope**
|
|
31
|
+
-
|
|
32
|
+
|
|
33
|
+
**Out of scope**
|
|
34
|
+
-
|
|
35
|
+
|
|
36
|
+
## 5. ผลกระทบ & ความเสี่ยง
|
|
37
|
+
- ระบบ/ฟีเจอร์เดิมที่กระทบ:
|
|
38
|
+
- ความเสี่ยง + วิธีลดความเสี่ยง:
|
|
39
|
+
|
|
40
|
+
## 6. ลิงก์
|
|
41
|
+
- Design (how): `./design.md`
|
|
42
|
+
- Tasks: `./tasks/`
|
|
43
|
+
- Business: `./business.md` (ถ้ามี)
|
|
@@ -1,49 +1,49 @@
|
|
|
1
|
-
# Research — <ชื่อหัวข้องาน>
|
|
2
|
-
|
|
3
|
-
> Output ของ Discovery stage · playbook: `warnyin/workflow/stages/discovery.md`
|
|
4
|
-
> ที่เก็บ "ข้อมูลที่ค้นมา + หลักฐาน" สนับสนุนการตัดสินใจใน `discovery.md`
|
|
5
|
-
|
|
6
|
-
| | |
|
|
7
|
-
|---|---|
|
|
8
|
-
| **Slug** | `<kebab-case>` |
|
|
9
|
-
| **วันที่** | `YYYY-MM-DD` |
|
|
10
|
-
|
|
11
|
-
---
|
|
12
|
-
|
|
13
|
-
## 1. คำถามวิจัย (research questions)
|
|
14
|
-
> สิ่งที่ "ยังไม่รู้" และต้องค้นให้ได้คำตอบก่อนออกแบบ
|
|
15
|
-
- [ ] RQ1:
|
|
16
|
-
- [ ] RQ2:
|
|
17
|
-
|
|
18
|
-
## 2. วิธี & แหล่งข้อมูล
|
|
19
|
-
- [ ] อ่านโค้ด/เอกสารในโปรเจกต์ (code inspection)
|
|
20
|
-
- [ ] ค้นเว็บ / เอกสารภายนอก
|
|
21
|
-
- [ ] prior art / วิธีที่ทีม/คนอื่นทำ
|
|
22
|
-
|
|
23
|
-
## 3. Findings (ผลการค้นต่อคำถาม)
|
|
24
|
-
> ทุก finding ต้องมี evidence/link อ้างอิงได้
|
|
25
|
-
|
|
26
|
-
### RQ1: <คำถาม>
|
|
27
|
-
- พบว่า:
|
|
28
|
-
- หลักฐาน:
|
|
29
|
-
- สรุป/นัยต่อการออกแบบ:
|
|
30
|
-
|
|
31
|
-
### RQ2: <คำถาม>
|
|
32
|
-
-
|
|
33
|
-
|
|
34
|
-
## 4. Code inspection (สิ่งที่ตอบได้จากโค้ดเอง โดยไม่ต้องถาม user)
|
|
35
|
-
| ไฟล์ / ส่วนของโค้ด | สิ่งที่พบ | นัยต่องาน |
|
|
36
|
-
|---|---|---|
|
|
37
|
-
| | | |
|
|
38
|
-
|
|
39
|
-
## 5. ทางเลือก & เปรียบเทียบ (ถ้ามี)
|
|
40
|
-
| ทางเลือก | ข้อดี | ข้อเสีย | เหมาะกับเคสนี้? |
|
|
41
|
-
|---|---|---|---|
|
|
42
|
-
| | | | |
|
|
43
|
-
|
|
44
|
-
## 6. ความเสี่ยง / unknown ที่ยังเหลือ
|
|
45
|
-
-
|
|
46
|
-
|
|
47
|
-
## 7. ข้อสรุป → ส่งต่อ
|
|
48
|
-
- คำแนะนำจาก research:
|
|
49
|
-
- การตัดสินใจที่ป้อนกลับเข้า `discovery.md` (Decision Log):
|
|
1
|
+
# Research — <ชื่อหัวข้องาน>
|
|
2
|
+
|
|
3
|
+
> Output ของ Discovery stage · playbook: `warnyin/workflow/stages/discovery.md`
|
|
4
|
+
> ที่เก็บ "ข้อมูลที่ค้นมา + หลักฐาน" สนับสนุนการตัดสินใจใน `discovery.md`
|
|
5
|
+
|
|
6
|
+
| | |
|
|
7
|
+
|---|---|
|
|
8
|
+
| **Slug** | `<kebab-case>` |
|
|
9
|
+
| **วันที่** | `YYYY-MM-DD` |
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## 1. คำถามวิจัย (research questions)
|
|
14
|
+
> สิ่งที่ "ยังไม่รู้" และต้องค้นให้ได้คำตอบก่อนออกแบบ
|
|
15
|
+
- [ ] RQ1:
|
|
16
|
+
- [ ] RQ2:
|
|
17
|
+
|
|
18
|
+
## 2. วิธี & แหล่งข้อมูล
|
|
19
|
+
- [ ] อ่านโค้ด/เอกสารในโปรเจกต์ (code inspection)
|
|
20
|
+
- [ ] ค้นเว็บ / เอกสารภายนอก
|
|
21
|
+
- [ ] prior art / วิธีที่ทีม/คนอื่นทำ
|
|
22
|
+
|
|
23
|
+
## 3. Findings (ผลการค้นต่อคำถาม)
|
|
24
|
+
> ทุก finding ต้องมี evidence/link อ้างอิงได้
|
|
25
|
+
|
|
26
|
+
### RQ1: <คำถาม>
|
|
27
|
+
- พบว่า:
|
|
28
|
+
- หลักฐาน:
|
|
29
|
+
- สรุป/นัยต่อการออกแบบ:
|
|
30
|
+
|
|
31
|
+
### RQ2: <คำถาม>
|
|
32
|
+
-
|
|
33
|
+
|
|
34
|
+
## 4. Code inspection (สิ่งที่ตอบได้จากโค้ดเอง โดยไม่ต้องถาม user)
|
|
35
|
+
| ไฟล์ / ส่วนของโค้ด | สิ่งที่พบ | นัยต่องาน |
|
|
36
|
+
|---|---|---|
|
|
37
|
+
| | | |
|
|
38
|
+
|
|
39
|
+
## 5. ทางเลือก & เปรียบเทียบ (ถ้ามี)
|
|
40
|
+
| ทางเลือก | ข้อดี | ข้อเสีย | เหมาะกับเคสนี้? |
|
|
41
|
+
|---|---|---|---|
|
|
42
|
+
| | | | |
|
|
43
|
+
|
|
44
|
+
## 6. ความเสี่ยง / unknown ที่ยังเหลือ
|
|
45
|
+
-
|
|
46
|
+
|
|
47
|
+
## 7. ข้อสรุป → ส่งต่อ
|
|
48
|
+
- คำแนะนำจาก research:
|
|
49
|
+
- การตัดสินใจที่ป้อนกลับเข้า `discovery.md` (Decision Log):
|
|
@@ -1,13 +1,13 @@
|
|
|
1
|
-
# Rule — <ชื่อ task>
|
|
2
|
-
|
|
3
|
-
> Output ของ DESIGN stage · playbook: `warnyin/workflow/stages/design.md`
|
|
4
|
-
> rule ที่ task นี้ต้อง **focus/follow** + rule ใหม่ที่อยากเสนอเพิ่ม
|
|
5
|
-
|
|
6
|
-
## 1. Rule ที่ต้อง follow (จาก techstack)
|
|
7
|
-
> ดึงจาก `docs/techstack/<component>/rule.md` และ `docs/rule.md` — เฉพาะข้อที่เกี่ยวกับ task นี้
|
|
8
|
-
- [ ]
|
|
9
|
-
- [ ]
|
|
10
|
-
|
|
11
|
-
## 2. เสนอเพิ่ม rule ใหม่ (⏳ รอ SHIP ค่อยอัปเดต rule กลาง)
|
|
12
|
-
> ห้ามแก้ `docs/techstack/.../rule.md` ตอนนี้ — แค่ note ไว้ก่อน ถึง SHIP ค่อยพิจารณาย้ายขึ้นไป
|
|
13
|
-
- [ ] rule ที่เสนอ: _____ — เหตุผล: _____
|
|
1
|
+
# Rule — <ชื่อ task>
|
|
2
|
+
|
|
3
|
+
> Output ของ DESIGN stage · playbook: `warnyin/workflow/stages/design.md`
|
|
4
|
+
> rule ที่ task นี้ต้อง **focus/follow** + rule ใหม่ที่อยากเสนอเพิ่ม
|
|
5
|
+
|
|
6
|
+
## 1. Rule ที่ต้อง follow (จาก techstack)
|
|
7
|
+
> ดึงจาก `docs/techstack/<component>/rule.md` และ `docs/rule.md` — เฉพาะข้อที่เกี่ยวกับ task นี้
|
|
8
|
+
- [ ]
|
|
9
|
+
- [ ]
|
|
10
|
+
|
|
11
|
+
## 2. เสนอเพิ่ม rule ใหม่ (⏳ รอ SHIP ค่อยอัปเดต rule กลาง)
|
|
12
|
+
> ห้ามแก้ `docs/techstack/.../rule.md` ตอนนี้ — แค่ note ไว้ก่อน ถึง SHIP ค่อยพิจารณาย้ายขึ้นไป
|
|
13
|
+
- [ ] rule ที่เสนอ: _____ — เหตุผล: _____
|
|
@@ -1,36 +1,36 @@
|
|
|
1
|
-
# Spec — <ชื่อ task>
|
|
2
|
-
|
|
3
|
-
> Output ของ DESIGN stage · playbook: `warnyin/workflow/stages/design.md`
|
|
4
|
-
> spec เฉพาะของ task นี้ — **ใส่เฉพาะหัวข้อที่เกี่ยวข้องกับชนิดของ task**
|
|
5
|
-
|
|
6
|
-
## 1. ชนิดของ task
|
|
7
|
-
`API` / `UX-UI` / `data` / `logic` / `infra` / ...
|
|
8
|
-
|
|
9
|
-
---
|
|
10
|
-
|
|
11
|
-
## 2. API SPEC (ถ้าเป็น API — ตามมาตรฐาน)
|
|
12
|
-
| | |
|
|
13
|
-
|---|---|
|
|
14
|
-
| Endpoint | `METHOD /path` |
|
|
15
|
-
| Auth | |
|
|
16
|
-
| Request | schema / body / params |
|
|
17
|
-
| Response | schema + ตัวอย่าง |
|
|
18
|
-
| Status / Error | 200 / 4xx / 5xx + error shape |
|
|
19
|
-
|
|
20
|
-
## 3. UX/UI SPEC (ถ้าเป็นงาน UI)
|
|
21
|
-
- Wireframe / Figma ref: `<ลิงก์ ถ้ามี>`
|
|
22
|
-
- States: default / loading / empty / error / success
|
|
23
|
-
- Responsive / accessibility:
|
|
24
|
-
|
|
25
|
-
## 4. Data-flow
|
|
26
|
-
> ข้อมูลไหลจากไหน → ผ่านอะไร → ไปไหน
|
|
27
|
-
|
|
28
|
-
## 5. User-flow
|
|
29
|
-
> ผู้ใช้เดินผ่านขั้นตอนไหนบ้าง
|
|
30
|
-
|
|
31
|
-
## 6. Persona
|
|
32
|
-
> task นี้ทำเพื่อใคร
|
|
33
|
-
|
|
34
|
-
## 7. Test-flow
|
|
35
|
-
> จะทดสอบ/ยืนยันความถูกต้องยังไง (เคสที่ต้องผ่าน, edge case)
|
|
36
|
-
- [ ]
|
|
1
|
+
# Spec — <ชื่อ task>
|
|
2
|
+
|
|
3
|
+
> Output ของ DESIGN stage · playbook: `warnyin/workflow/stages/design.md`
|
|
4
|
+
> spec เฉพาะของ task นี้ — **ใส่เฉพาะหัวข้อที่เกี่ยวข้องกับชนิดของ task**
|
|
5
|
+
|
|
6
|
+
## 1. ชนิดของ task
|
|
7
|
+
`API` / `UX-UI` / `data` / `logic` / `infra` / ...
|
|
8
|
+
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
## 2. API SPEC (ถ้าเป็น API — ตามมาตรฐาน)
|
|
12
|
+
| | |
|
|
13
|
+
|---|---|
|
|
14
|
+
| Endpoint | `METHOD /path` |
|
|
15
|
+
| Auth | |
|
|
16
|
+
| Request | schema / body / params |
|
|
17
|
+
| Response | schema + ตัวอย่าง |
|
|
18
|
+
| Status / Error | 200 / 4xx / 5xx + error shape |
|
|
19
|
+
|
|
20
|
+
## 3. UX/UI SPEC (ถ้าเป็นงาน UI)
|
|
21
|
+
- Wireframe / Figma ref: `<ลิงก์ ถ้ามี>`
|
|
22
|
+
- States: default / loading / empty / error / success
|
|
23
|
+
- Responsive / accessibility:
|
|
24
|
+
|
|
25
|
+
## 4. Data-flow
|
|
26
|
+
> ข้อมูลไหลจากไหน → ผ่านอะไร → ไปไหน
|
|
27
|
+
|
|
28
|
+
## 5. User-flow
|
|
29
|
+
> ผู้ใช้เดินผ่านขั้นตอนไหนบ้าง
|
|
30
|
+
|
|
31
|
+
## 6. Persona
|
|
32
|
+
> task นี้ทำเพื่อใคร
|
|
33
|
+
|
|
34
|
+
## 7. Test-flow
|
|
35
|
+
> จะทดสอบ/ยืนยันความถูกต้องยังไง (เคสที่ต้องผ่าน, edge case)
|
|
36
|
+
- [ ]
|
|
@@ -1,21 +1,21 @@
|
|
|
1
|
-
# Standard — <ชื่อ task>
|
|
2
|
-
|
|
3
|
-
> Output ของ DESIGN stage · playbook: `warnyin/workflow/stages/design.md`
|
|
4
|
-
> pattern การเขียนโค้ด / shared component ที่ task นี้ต้องยึด
|
|
5
|
-
> **อิงจาก** `docs/techstack/<component>/standard.md` — เพิ่มเติมเฉพาะ task ได้
|
|
6
|
-
|
|
7
|
-
## 1. Standard กลางที่ยึด (จาก techstack)
|
|
8
|
-
> อ้างอิง `docs/techstack/<component>/standard.md` — ข้อไหนเกี่ยวกับ task นี้
|
|
9
|
-
-
|
|
10
|
-
|
|
11
|
-
## 2. Pattern การเขียนโค้ดของ task นี้
|
|
12
|
-
- โครงสร้าง/naming:
|
|
13
|
-
- error handling:
|
|
14
|
-
- การจัดการ state/data:
|
|
15
|
-
|
|
16
|
-
## 3. Shared component / utility ที่ต้องใช้ (อย่าเขียนซ้ำ)
|
|
17
|
-
- component/hook/helper ที่มีอยู่แล้ว:
|
|
18
|
-
|
|
19
|
-
## 4. เพิ่มเติมเฉพาะ task (ถ้ามี)
|
|
20
|
-
> pattern ใหม่ที่ task นี้แนะนำ — ถ้าควรเป็นมาตรฐานกลาง ให้ note ใน `rule.md` (รอ SHIP อัปเดต standard กลาง)
|
|
21
|
-
-
|
|
1
|
+
# Standard — <ชื่อ task>
|
|
2
|
+
|
|
3
|
+
> Output ของ DESIGN stage · playbook: `warnyin/workflow/stages/design.md`
|
|
4
|
+
> pattern การเขียนโค้ด / shared component ที่ task นี้ต้องยึด
|
|
5
|
+
> **อิงจาก** `docs/techstack/<component>/standard.md` — เพิ่มเติมเฉพาะ task ได้
|
|
6
|
+
|
|
7
|
+
## 1. Standard กลางที่ยึด (จาก techstack)
|
|
8
|
+
> อ้างอิง `docs/techstack/<component>/standard.md` — ข้อไหนเกี่ยวกับ task นี้
|
|
9
|
+
-
|
|
10
|
+
|
|
11
|
+
## 2. Pattern การเขียนโค้ดของ task นี้
|
|
12
|
+
- โครงสร้าง/naming:
|
|
13
|
+
- error handling:
|
|
14
|
+
- การจัดการ state/data:
|
|
15
|
+
|
|
16
|
+
## 3. Shared component / utility ที่ต้องใช้ (อย่าเขียนซ้ำ)
|
|
17
|
+
- component/hook/helper ที่มีอยู่แล้ว:
|
|
18
|
+
|
|
19
|
+
## 4. เพิ่มเติมเฉพาะ task (ถ้ามี)
|
|
20
|
+
> pattern ใหม่ที่ task นี้แนะนำ — ถ้าควรเป็นมาตรฐานกลาง ให้ note ใน `rule.md` (รอ SHIP อัปเดต standard กลาง)
|
|
21
|
+
-
|
|
@@ -1,39 +1,39 @@
|
|
|
1
|
-
# Task — <ชื่อ task>
|
|
2
|
-
|
|
3
|
-
> Output ของ DESIGN stage · playbook: `warnyin/workflow/stages/design.md`
|
|
4
|
-
> หน่วยที่ **โยนให้ sub-agent ทำใน BUILD ได้** — self-contained แต่เชื่อมกับ task อื่นผ่าน dependency
|
|
5
|
-
|
|
6
|
-
| | |
|
|
7
|
-
|---|---|
|
|
8
|
-
| **Task** | `<kebab-case>` |
|
|
9
|
-
| **Slice อ้างอิง** | `design.md` slice #__ |
|
|
10
|
-
| **Component** | `admin-console` / `api-service` / ... |
|
|
11
|
-
| **สถานะ** | `รอ build` / `กำลังทำ` / `เสร็จ` |
|
|
12
|
-
|
|
13
|
-
## 1. เป้าหมายของ task (vertical slice)
|
|
14
|
-
> task นี้ส่งมอบคุณค่า end-to-end อะไร
|
|
15
|
-
|
|
16
|
-
## 2. Dependency (เชื่อมต่อกับ task อื่น)
|
|
17
|
-
- ต้องทำหลัง: `tasks/<...>` (เพราะ ...)
|
|
18
|
-
- ปลดล็อกให้: `tasks/<...>`
|
|
19
|
-
- ส่ง output อะไรต่อให้ task ถัดไป:
|
|
20
|
-
|
|
21
|
-
## 3. Sub-tasks (แตกย่อยถ้าซับซ้อน)
|
|
22
|
-
> sub-task ต้องเชื่อมต่อกัน — ระบุลำดับ/สิ่งที่ส่งต่อกัน
|
|
23
|
-
|
|
24
|
-
- [ ] 1. <sub-task> — _ผลลัพธ์:_
|
|
25
|
-
- [ ] 2. <sub-task> — _ขึ้นกับ 1:_
|
|
26
|
-
- [ ] 3. <sub-task>
|
|
27
|
-
|
|
28
|
-
## 4. ขอบเขตไฟล์/โค้ดที่จะแตะ
|
|
29
|
-
- ไฟล์/โมดูล:
|
|
30
|
-
|
|
31
|
-
## 5. Acceptance criteria (เกณฑ์ว่า task เสร็จ)
|
|
32
|
-
- [ ]
|
|
33
|
-
- [ ] ผ่าน test ตาม `spec.md` (test-flow)
|
|
34
|
-
- [ ] ทำตาม `rule.md` และ `standard.md`
|
|
35
|
-
|
|
36
|
-
## 6. อ้างอิงในโฟลเดอร์ task นี้
|
|
37
|
-
- Spec: `./spec.md`
|
|
38
|
-
- Standard (pattern โค้ด): `./standard.md`
|
|
39
|
-
- Rule ที่ต้อง follow: `./rule.md`
|
|
1
|
+
# Task — <ชื่อ task>
|
|
2
|
+
|
|
3
|
+
> Output ของ DESIGN stage · playbook: `warnyin/workflow/stages/design.md`
|
|
4
|
+
> หน่วยที่ **โยนให้ sub-agent ทำใน BUILD ได้** — self-contained แต่เชื่อมกับ task อื่นผ่าน dependency
|
|
5
|
+
|
|
6
|
+
| | |
|
|
7
|
+
|---|---|
|
|
8
|
+
| **Task** | `<kebab-case>` |
|
|
9
|
+
| **Slice อ้างอิง** | `design.md` slice #__ |
|
|
10
|
+
| **Component** | `admin-console` / `api-service` / ... |
|
|
11
|
+
| **สถานะ** | `รอ build` / `กำลังทำ` / `เสร็จ` |
|
|
12
|
+
|
|
13
|
+
## 1. เป้าหมายของ task (vertical slice)
|
|
14
|
+
> task นี้ส่งมอบคุณค่า end-to-end อะไร
|
|
15
|
+
|
|
16
|
+
## 2. Dependency (เชื่อมต่อกับ task อื่น)
|
|
17
|
+
- ต้องทำหลัง: `tasks/<...>` (เพราะ ...)
|
|
18
|
+
- ปลดล็อกให้: `tasks/<...>`
|
|
19
|
+
- ส่ง output อะไรต่อให้ task ถัดไป:
|
|
20
|
+
|
|
21
|
+
## 3. Sub-tasks (แตกย่อยถ้าซับซ้อน)
|
|
22
|
+
> sub-task ต้องเชื่อมต่อกัน — ระบุลำดับ/สิ่งที่ส่งต่อกัน
|
|
23
|
+
|
|
24
|
+
- [ ] 1. <sub-task> — _ผลลัพธ์:_
|
|
25
|
+
- [ ] 2. <sub-task> — _ขึ้นกับ 1:_
|
|
26
|
+
- [ ] 3. <sub-task>
|
|
27
|
+
|
|
28
|
+
## 4. ขอบเขตไฟล์/โค้ดที่จะแตะ
|
|
29
|
+
- ไฟล์/โมดูล:
|
|
30
|
+
|
|
31
|
+
## 5. Acceptance criteria (เกณฑ์ว่า task เสร็จ)
|
|
32
|
+
- [ ]
|
|
33
|
+
- [ ] ผ่าน test ตาม `spec.md` (test-flow)
|
|
34
|
+
- [ ] ทำตาม `rule.md` และ `standard.md`
|
|
35
|
+
|
|
36
|
+
## 6. อ้างอิงในโฟลเดอร์ task นี้
|
|
37
|
+
- Spec: `./spec.md`
|
|
38
|
+
- Standard (pattern โค้ด): `./standard.md`
|
|
39
|
+
- Rule ที่ต้อง follow: `./rule.md`
|