@warnyin/agents 0.17.0 → 0.18.1

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.
Files changed (86) hide show
  1. package/CHANGELOG.md +168 -153
  2. package/README.md +160 -160
  3. package/package.json +38 -38
  4. package/src/.claude/agents/warnyin-infra.md +13 -13
  5. package/src/.claude/agents/warnyin-qa.md +13 -13
  6. package/src/.claude/agents/warnyin-sa.md +13 -13
  7. package/src/.claude/agents/warnyin-security.md +13 -13
  8. package/src/.claude/agents/warnyin-tech-lead.md +13 -13
  9. package/src/.claude/agents/warnyin-ux.md +14 -0
  10. package/src/.claude/commands/warnyin/build.md +31 -31
  11. package/src/.claude/commands/warnyin/design.md +27 -27
  12. package/src/.claude/commands/warnyin/discovery.md +22 -22
  13. package/src/.claude/commands/warnyin/explore.md +14 -14
  14. package/src/.claude/commands/warnyin/feedback/issue.md +14 -14
  15. package/src/.claude/commands/warnyin/init.md +12 -12
  16. package/src/.claude/commands/warnyin/install-skill.md +19 -14
  17. package/src/.claude/commands/warnyin/next.md +17 -17
  18. package/src/.claude/commands/warnyin/ship.md +28 -28
  19. package/src/.claude/commands/warnyin/triage.md +14 -14
  20. package/src/.claude/commands/warnyin/update-codemaps.md +12 -12
  21. package/src/.claude/commands/warnyin/verify.md +20 -20
  22. package/src/.claude/skills/explore/SKILL.md +8 -8
  23. package/src/.claude/skills/next/SKILL.md +8 -8
  24. package/src/.claude/skills/update-codemaps/SKILL.md +8 -8
  25. package/src/.warnyin/installer/templates/CLAUDE.global.md +5 -5
  26. package/src/.warnyin/installer/templates/CLAUDE.md +35 -35
  27. package/src/.warnyin/template/docs/codemap/index.md +18 -18
  28. package/src/.warnyin/template/docs/features/[feature-name]/business.md +5 -5
  29. package/src/.warnyin/template/docs/features/[feature-name]/feature.md +5 -5
  30. package/src/.warnyin/template/docs/features/[feature-name]/spec.md +16 -16
  31. package/src/.warnyin/template/docs/infra.md +16 -16
  32. package/src/.warnyin/template/docs/project.md +18 -18
  33. package/src/.warnyin/template/docs/rule.md +7 -7
  34. package/src/.warnyin/template/docs/techstack/[component]/about.md +6 -6
  35. package/src/.warnyin/template/docs/techstack/[component]/rule.md +6 -6
  36. package/src/.warnyin/template/docs/techstack/[component]/standard.md +6 -6
  37. package/src/.warnyin/template/docs/techstack/[component]/structure.md +7 -7
  38. package/src/.warnyin/template/docs/techstack/[component]/test.md +7 -7
  39. package/src/.warnyin/template/docs/troubleshooting.md +32 -32
  40. package/src/.warnyin/template/stages/[topic]/build.md +58 -58
  41. package/src/.warnyin/template/stages/[topic]/business.md +21 -21
  42. package/src/.warnyin/template/stages/[topic]/design.md +63 -63
  43. package/src/.warnyin/template/stages/[topic]/discovery.md +69 -69
  44. package/src/.warnyin/template/stages/[topic]/proposal.md +43 -43
  45. package/src/.warnyin/template/stages/[topic]/research.md +49 -49
  46. package/src/.warnyin/template/stages/[topic]/ship.md +32 -32
  47. package/src/.warnyin/template/stages/[topic]/tasks/[task-name]/issue.md +19 -19
  48. package/src/.warnyin/template/stages/[topic]/tasks/[task-name]/rule.md +13 -13
  49. package/src/.warnyin/template/stages/[topic]/tasks/[task-name]/spec.md +36 -36
  50. package/src/.warnyin/template/stages/[topic]/tasks/[task-name]/standard.md +21 -21
  51. package/src/.warnyin/template/stages/[topic]/tasks/[task-name]/task.md +40 -40
  52. package/src/.warnyin/template/stages/[topic]/test.md +46 -46
  53. package/src/.warnyin/template/stages/[topic]/troubleshooting.md +34 -34
  54. package/src/.warnyin/template/stages/[topic]/verify.md +44 -44
  55. package/src/.warnyin/template/stages/[topic]/wireframe.md +104 -0
  56. package/src/.warnyin/workflow/README.md +106 -106
  57. package/src/.warnyin/workflow/api-doc.md +93 -93
  58. package/src/.warnyin/workflow/codemap.md +91 -91
  59. package/src/.warnyin/workflow/contexts/README.md +51 -51
  60. package/src/.warnyin/workflow/contexts/build.md +25 -25
  61. package/src/.warnyin/workflow/contexts/research.md +25 -25
  62. package/src/.warnyin/workflow/contexts/review.md +25 -25
  63. package/src/.warnyin/workflow/explore.md +32 -32
  64. package/src/.warnyin/workflow/feedback.md +212 -212
  65. package/src/.warnyin/workflow/init.md +136 -136
  66. package/src/.warnyin/workflow/next.md +48 -48
  67. package/src/.warnyin/workflow/roles/README.md +52 -47
  68. package/src/.warnyin/workflow/roles/ba.md +25 -25
  69. package/src/.warnyin/workflow/roles/developer.md +31 -31
  70. package/src/.warnyin/workflow/roles/infra.md +24 -24
  71. package/src/.warnyin/workflow/roles/po.md +28 -28
  72. package/src/.warnyin/workflow/roles/qa.md +36 -35
  73. package/src/.warnyin/workflow/roles/sa.md +28 -28
  74. package/src/.warnyin/workflow/roles/security.md +39 -39
  75. package/src/.warnyin/workflow/roles/tech-lead.md +28 -28
  76. package/src/.warnyin/workflow/roles/ux.md +76 -0
  77. package/src/.warnyin/workflow/scripts/build-wave.mjs +145 -145
  78. package/src/.warnyin/workflow/scripts/validate-topic.mjs +378 -378
  79. package/src/.warnyin/workflow/stages/build.md +98 -98
  80. package/src/.warnyin/workflow/stages/design.md +174 -154
  81. package/src/.warnyin/workflow/stages/discovery.md +256 -256
  82. package/src/.warnyin/workflow/stages/ship.md +94 -94
  83. package/src/.warnyin/workflow/stages/verify.md +82 -82
  84. package/src/.warnyin/workflow/triage.md +74 -74
  85. package/src/AGENTS.md +54 -54
  86. package/src/bin/cli.mjs +357 -333
@@ -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,40 +1,40 @@
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
- | **Model tier** | `cheap` / `balanced` / `deepest` _(optional; ไม่ระบุ = `balanced` — ดู `contexts/README.md` §"Model tier")_ |
12
- | **สถานะ** | `รอ build` / `กำลังทำ` / `เสร็จ` |
13
-
14
- ## 1. เป้าหมายของ task (vertical slice)
15
- > task นี้ส่งมอบคุณค่า end-to-end อะไร
16
-
17
- ## 2. Dependency (เชื่อมต่อกับ task อื่น)
18
- - ต้องทำหลัง: `tasks/<...>` (เพราะ ...)
19
- - ปลดล็อกให้: `tasks/<...>`
20
- - ส่ง output อะไรต่อให้ task ถัดไป:
21
-
22
- ## 3. Sub-tasks (แตกย่อยถ้าซับซ้อน)
23
- > sub-task ต้องเชื่อมต่อกัน — ระบุลำดับ/สิ่งที่ส่งต่อกัน
24
-
25
- - [ ] 1. <sub-task> — _ผลลัพธ์:_
26
- - [ ] 2. <sub-task> — _ขึ้นกับ 1:_
27
- - [ ] 3. <sub-task>
28
-
29
- ## 4. ขอบเขตไฟล์/โค้ดที่จะแตะ
30
- - ไฟล์/โมดูล:
31
-
32
- ## 5. Acceptance criteria (เกณฑ์ว่า task เสร็จ)
33
- - [ ]
34
- - [ ] ผ่าน test ตาม `spec.md` (test-flow)
35
- - [ ] ทำตาม `rule.md` และ `standard.md`
36
-
37
- ## 6. อ้างอิงในโฟลเดอร์ task นี้
38
- - Spec: `./spec.md`
39
- - Standard (pattern โค้ด): `./standard.md`
40
- - 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
+ | **Model tier** | `cheap` / `balanced` / `deepest` _(optional; ไม่ระบุ = `balanced` — ดู `contexts/README.md` §"Model tier")_ |
12
+ | **สถานะ** | `รอ build` / `กำลังทำ` / `เสร็จ` |
13
+
14
+ ## 1. เป้าหมายของ task (vertical slice)
15
+ > task นี้ส่งมอบคุณค่า end-to-end อะไร
16
+
17
+ ## 2. Dependency (เชื่อมต่อกับ task อื่น)
18
+ - ต้องทำหลัง: `tasks/<...>` (เพราะ ...)
19
+ - ปลดล็อกให้: `tasks/<...>`
20
+ - ส่ง output อะไรต่อให้ task ถัดไป:
21
+
22
+ ## 3. Sub-tasks (แตกย่อยถ้าซับซ้อน)
23
+ > sub-task ต้องเชื่อมต่อกัน — ระบุลำดับ/สิ่งที่ส่งต่อกัน
24
+
25
+ - [ ] 1. <sub-task> — _ผลลัพธ์:_
26
+ - [ ] 2. <sub-task> — _ขึ้นกับ 1:_
27
+ - [ ] 3. <sub-task>
28
+
29
+ ## 4. ขอบเขตไฟล์/โค้ดที่จะแตะ
30
+ - ไฟล์/โมดูล:
31
+
32
+ ## 5. Acceptance criteria (เกณฑ์ว่า task เสร็จ)
33
+ - [ ]
34
+ - [ ] ผ่าน test ตาม `spec.md` (test-flow)
35
+ - [ ] ทำตาม `rule.md` และ `standard.md`
36
+
37
+ ## 6. อ้างอิงในโฟลเดอร์ task นี้
38
+ - Spec: `./spec.md`
39
+ - Standard (pattern โค้ด): `./standard.md`
40
+ - Rule ที่ต้อง follow: `./rule.md`
@@ -1,46 +1,46 @@
1
- # Test Plan — <ชื่อ change>
2
-
3
- > Output ของ VERIFY stage · playbook: `.warnyin/workflow/stages/verify.md`
4
- > แผน/วิธีเทสของ topic นี้ — ตอน **SHIP** จะ merge เข้า `docs/techstack/<component>/test.md`
5
- > อิง guideline จาก `docs/techstack/<component>/test.md` (ถ้าไม่มี = เสนอวิธีใหม่ที่นี่)
6
-
7
- | | |
8
- |---|---|
9
- | **Slug** | `<kebab-case>` |
10
- | **Component** | `api-service` / `admin-console` |
11
- | **จุดประสงค์ที่ต้อง verify** | (สรุปจาก spec/tasks) |
12
-
13
- ## 1. ขอบเขตการเทส (ตามจุดประสงค์ topic)
14
- - สิ่งที่ต้องยืนยันว่าทำงานถูก:
15
-
16
- ## 2. ชนิดการเทส
17
- - [ ] Functional (ตาม test-flow ใน `tasks/*/spec.md`)
18
- - [ ] E2E smoke — เครื่องมือ: `playwright-cli` (ถ้าเป็น FE)
19
- - [ ] Integration / API
20
- - [ ] UX/UI verify (ถ้าเป็น FE)
21
- - [ ] อื่นๆ:
22
-
23
- ## 3. Local env ที่ต้องรัน (จาก `docs/infra.md`)
24
- | Service | คำสั่งรัน | port / หมายเหตุ |
25
- |---|---|---|
26
- | | | |
27
-
28
- ## 4. Test cases
29
- | # | สถานการณ์ (อิงจุดประสงค์) | ขั้นตอน | ผลที่คาดหวัง |
30
- |---|---|---|---|
31
- | 1 | | | |
32
-
33
- ## 5. E2E smoke (FE)
34
- - flow ที่ smoke:
35
- - คำสั่ง playwright-cli:
36
-
37
- ## 6. UX/UI checklist (FE)
38
- - [ ] layout ตรงตาม spec/wireframe
39
- - [ ] states: loading / empty / error / success
40
- - [ ] responsive
41
- - [ ] interaction / user-flow ลื่นไหล
42
-
43
- ## 7. วิธีรันเทส (reproducible)
44
- ```
45
- <คำสั่ง / ขั้นตอน>
46
- ```
1
+ # Test Plan — <ชื่อ change>
2
+
3
+ > Output ของ VERIFY stage · playbook: `.warnyin/workflow/stages/verify.md`
4
+ > แผน/วิธีเทสของ topic นี้ — ตอน **SHIP** จะ merge เข้า `docs/techstack/<component>/test.md`
5
+ > อิง guideline จาก `docs/techstack/<component>/test.md` (ถ้าไม่มี = เสนอวิธีใหม่ที่นี่)
6
+
7
+ | | |
8
+ |---|---|
9
+ | **Slug** | `<kebab-case>` |
10
+ | **Component** | `api-service` / `admin-console` |
11
+ | **จุดประสงค์ที่ต้อง verify** | (สรุปจาก spec/tasks) |
12
+
13
+ ## 1. ขอบเขตการเทส (ตามจุดประสงค์ topic)
14
+ - สิ่งที่ต้องยืนยันว่าทำงานถูก:
15
+
16
+ ## 2. ชนิดการเทส
17
+ - [ ] Functional (ตาม test-flow ใน `tasks/*/spec.md`)
18
+ - [ ] E2E smoke — เครื่องมือ: `playwright-cli` (ถ้าเป็น FE)
19
+ - [ ] Integration / API
20
+ - [ ] UX/UI verify (ถ้าเป็น FE)
21
+ - [ ] อื่นๆ:
22
+
23
+ ## 3. Local env ที่ต้องรัน (จาก `docs/infra.md`)
24
+ | Service | คำสั่งรัน | port / หมายเหตุ |
25
+ |---|---|---|
26
+ | | | |
27
+
28
+ ## 4. Test cases
29
+ | # | สถานการณ์ (อิงจุดประสงค์) | ขั้นตอน | ผลที่คาดหวัง |
30
+ |---|---|---|---|
31
+ | 1 | | | |
32
+
33
+ ## 5. E2E smoke (FE)
34
+ - flow ที่ smoke:
35
+ - คำสั่ง playwright-cli:
36
+
37
+ ## 6. UX/UI checklist (FE)
38
+ - [ ] layout ตรงตาม spec/wireframe
39
+ - [ ] states: loading / empty / error / success
40
+ - [ ] responsive
41
+ - [ ] interaction / user-flow ลื่นไหล
42
+
43
+ ## 7. วิธีรันเทส (reproducible)
44
+ ```
45
+ <คำสั่ง / ขั้นตอน>
46
+ ```
@@ -1,34 +1,34 @@
1
- # Troubleshooting — <ชื่อ change>
2
-
3
- > Log ปัญหา **ยาก/ซ้ำ** ที่เจอระหว่างทำงาน topic นี้ (ส่วนใหญ่ตอน BUILD) แล้วแก้สำเร็จ
4
- > ตอน **SHIP** จะยกรายการที่มีค่าขึ้นไปรวมที่ KB กลาง `docs/troubleshooting.md`
5
- > เจอปัญหาใหม่ → อ่าน `docs/troubleshooting.md` ก่อนเสมอ เผื่อเคยแก้แล้ว
6
-
7
- ---
8
-
9
- ## วิธีบันทึก
10
- บันทึกเฉพาะปัญหาที่ **ยากจะแก้** หรือ **เจอซ้ำ** (ไม่ใช่ทุก error เล็กน้อย) — หนึ่งปัญหา = หนึ่ง entry
11
-
12
- ---
13
-
14
- ### TS-1: <ชื่อปัญหาสั้นๆ>
15
- | | |
16
- |---|---|
17
- | **วันที่** | `YYYY-MM-DD` |
18
- | **Component / Task** | `api-service` / `tasks/<task>` |
19
- | **ความถี่** | เจอครั้งเดียว (ยากมาก) / เจอซ้ำ __ ครั้ง |
20
- | **ยกขึ้น KB กลางตอน SHIP?** | ✅ / ❌ |
21
-
22
- - **อาการ / error message:**
23
- ```
24
- <paste error>
25
- ```
26
- - **บริบทที่ทำให้เกิด (trigger):**
27
- - **สาเหตุที่แท้จริง (root cause):**
28
- - **วิธีแก้ที่ได้ผล (solution):**
29
- - **วิธีสังเกต/ป้องกันไม่ให้เกิดซ้ำ:**
30
-
31
- ---
32
-
33
- ### TS-2: <...>
34
- > (คัดลอกบล็อกด้านบน)
1
+ # Troubleshooting — <ชื่อ change>
2
+
3
+ > Log ปัญหา **ยาก/ซ้ำ** ที่เจอระหว่างทำงาน topic นี้ (ส่วนใหญ่ตอน BUILD) แล้วแก้สำเร็จ
4
+ > ตอน **SHIP** จะยกรายการที่มีค่าขึ้นไปรวมที่ KB กลาง `docs/troubleshooting.md`
5
+ > เจอปัญหาใหม่ → อ่าน `docs/troubleshooting.md` ก่อนเสมอ เผื่อเคยแก้แล้ว
6
+
7
+ ---
8
+
9
+ ## วิธีบันทึก
10
+ บันทึกเฉพาะปัญหาที่ **ยากจะแก้** หรือ **เจอซ้ำ** (ไม่ใช่ทุก error เล็กน้อย) — หนึ่งปัญหา = หนึ่ง entry
11
+
12
+ ---
13
+
14
+ ### TS-1: <ชื่อปัญหาสั้นๆ>
15
+ | | |
16
+ |---|---|
17
+ | **วันที่** | `YYYY-MM-DD` |
18
+ | **Component / Task** | `api-service` / `tasks/<task>` |
19
+ | **ความถี่** | เจอครั้งเดียว (ยากมาก) / เจอซ้ำ __ ครั้ง |
20
+ | **ยกขึ้น KB กลางตอน SHIP?** | ✅ / ❌ |
21
+
22
+ - **อาการ / error message:**
23
+ ```
24
+ <paste error>
25
+ ```
26
+ - **บริบทที่ทำให้เกิด (trigger):**
27
+ - **สาเหตุที่แท้จริง (root cause):**
28
+ - **วิธีแก้ที่ได้ผล (solution):**
29
+ - **วิธีสังเกต/ป้องกันไม่ให้เกิดซ้ำ:**
30
+
31
+ ---
32
+
33
+ ### TS-2: <...>
34
+ > (คัดลอกบล็อกด้านบน)
@@ -1,44 +1,44 @@
1
- # Verify Report — <ชื่อ change>
2
-
3
- > Output ของ VERIFY stage · playbook: `.warnyin/workflow/stages/verify.md`
4
- > สรุปผลการ verify ตามจุดประสงค์ของ topic + การแก้ไขที่เกิดขึ้น
5
-
6
- | | |
7
- |---|---|
8
- | **Slug** | `<kebab-case>` |
9
- | **วันที่** | `YYYY-MM-DD` |
10
- | **ผลรวม** | ผ่าน / ไม่ผ่าน |
11
- | **จำนวนรอบการแก้ไข (fix iterations)** | __ รอบ |
12
- | **จำนวนจุดที่แก้** | __ จุด |
13
-
14
- ## 1. จุดประสงค์ที่ verify (จาก spec/tasks)
15
- -
16
-
17
- ## 2. ผลการเทส
18
- | # | Test case / flow | ชนิด | ผล | หมายเหตุ |
19
- |---|---|---|---|---|
20
- | 1 | | functional / e2e / uxui | ✅ / ❌→✅ (แก้แล้ว) | |
21
-
22
- ## 3. UX/UI verify (ถ้าเป็น FE)
23
- - [ ] layout / states / responsive / user-flow — ผล:
24
-
25
- ## 4. รายการแก้ไข (สรุปการแก้ระหว่าง verify)
26
- > นับรวมเป็น "จำนวนการแก้ไข" ด้านบน
27
-
28
- | รอบ | ปัญหาที่เจอ | วิธีแก้ | ไฟล์ที่แก้ |
29
- |---|---|---|---|
30
- | 1 | | | |
31
-
32
- ## 5. ปัญหายาก/ซ้ำ → troubleshooting
33
- - บันทึกไว้ที่ `./troubleshooting.md` (SHIP ยกขึ้น `docs/troubleshooting.md`): มี/ไม่มี
34
-
35
- ## 6. หมายเหตุถึง user (ถ้าถามระหว่างทาง)
36
- > กรณีวนแก้นาน/หลายรอบ แล้วถาม user — สรุปคำถาม/คำตอบ/การตัดสินใจ
37
- -
38
-
39
- ## ✅ Gate → SHIP (ดู `.warnyin/workflow/stages/verify.md` ข้อ 6)
40
- - [ ] เทสตามจุดประสงค์ครบ (functional)
41
- - [ ] FE: UX/UI verify ผ่าน
42
- - [ ] ทุกข้อที่ไม่ผ่านถูกแก้จนผ่าน
43
- - [ ] test.md + verify.md เขียนครบ
44
- - [ ] ปัญหายากบันทึก troubleshooting.md แล้ว
1
+ # Verify Report — <ชื่อ change>
2
+
3
+ > Output ของ VERIFY stage · playbook: `.warnyin/workflow/stages/verify.md`
4
+ > สรุปผลการ verify ตามจุดประสงค์ของ topic + การแก้ไขที่เกิดขึ้น
5
+
6
+ | | |
7
+ |---|---|
8
+ | **Slug** | `<kebab-case>` |
9
+ | **วันที่** | `YYYY-MM-DD` |
10
+ | **ผลรวม** | ผ่าน / ไม่ผ่าน |
11
+ | **จำนวนรอบการแก้ไข (fix iterations)** | __ รอบ |
12
+ | **จำนวนจุดที่แก้** | __ จุด |
13
+
14
+ ## 1. จุดประสงค์ที่ verify (จาก spec/tasks)
15
+ -
16
+
17
+ ## 2. ผลการเทส
18
+ | # | Test case / flow | ชนิด | ผล | หมายเหตุ |
19
+ |---|---|---|---|---|
20
+ | 1 | | functional / e2e / uxui | ✅ / ❌→✅ (แก้แล้ว) | |
21
+
22
+ ## 3. UX/UI verify (ถ้าเป็น FE)
23
+ - [ ] layout / states / responsive / user-flow — ผล:
24
+
25
+ ## 4. รายการแก้ไข (สรุปการแก้ระหว่าง verify)
26
+ > นับรวมเป็น "จำนวนการแก้ไข" ด้านบน
27
+
28
+ | รอบ | ปัญหาที่เจอ | วิธีแก้ | ไฟล์ที่แก้ |
29
+ |---|---|---|---|
30
+ | 1 | | | |
31
+
32
+ ## 5. ปัญหายาก/ซ้ำ → troubleshooting
33
+ - บันทึกไว้ที่ `./troubleshooting.md` (SHIP ยกขึ้น `docs/troubleshooting.md`): มี/ไม่มี
34
+
35
+ ## 6. หมายเหตุถึง user (ถ้าถามระหว่างทาง)
36
+ > กรณีวนแก้นาน/หลายรอบ แล้วถาม user — สรุปคำถาม/คำตอบ/การตัดสินใจ
37
+ -
38
+
39
+ ## ✅ Gate → SHIP (ดู `.warnyin/workflow/stages/verify.md` ข้อ 6)
40
+ - [ ] เทสตามจุดประสงค์ครบ (functional)
41
+ - [ ] FE: UX/UI verify ผ่าน
42
+ - [ ] ทุกข้อที่ไม่ผ่านถูกแก้จนผ่าน
43
+ - [ ] test.md + verify.md เขียนครบ
44
+ - [ ] ปัญหายากบันทึก troubleshooting.md แล้ว
@@ -0,0 +1,104 @@
1
+ # Wireframe — <ชื่อ change / กลุ่มหน้าจอ>
2
+
3
+ > Output ของ DESIGN stage · playbook: `.warnyin/workflow/stages/design.md`
4
+ > **low-fidelity wireframe** ของ change ที่มี UI surface — วาดก่อนเขียน technical design (`design.md` §5 UI layer) แล้วแตก task
5
+ > วาดโดย role/agent `warnyin-ux` (read-only generator) หรือ AI หลักสวม lens `.warnyin/workflow/roles/ux.md` (fallback) — main loop เขียนไฟล์นี้
6
+
7
+ | | |
8
+ |---|---|
9
+ | **Slug** | `<kebab-case ของ topic — ตรงกับ docs/stages/<slug>/>` |
10
+ | **วันที่** | `YYYY-MM-DD` |
11
+ | **Status** | `draft` / `approved` _(★ approve gate — user ต้องยืนยันให้เป็น `approved` ก่อนแตก task)_ |
12
+
13
+ <!--
14
+ วิธีกรอกไฟล์นี้ (อ่านก่อนเริ่ม):
15
+ - wireframe เป็น low-fidelity เท่านั้น — กล่อง/label generic พอให้เห็นโครงหน้าจอ ไม่ต้องสวย ไม่ใช่ pixel-perfect
16
+ - ★ privacy: ใช้ placeholder generic — ห้ามใส่ secret/token/credential/internal path/PII จริงลงในภาพ (ไฟล์นี้ commit ลง repo)
17
+ - แทนที่ทุก <...> และ [LABEL] ด้วยของจริงของ change นี้ แล้วลบ comment <!-- ... --> ที่เป็นคำสั่งกรอกออก
18
+ - 4 section ด้านล่าง (§1-§4) ชื่อตายตัวตาม contract — design.md/task อ้างชื่อนี้ ห้ามเปลี่ยนชื่อ/ลบ section
19
+ -->
20
+
21
+ ## 1. User flow
22
+
23
+ > เส้นทาง screen-to-screen — ผู้ใช้เดินจากจอไหนไปจอไหน (ทำอะไร → เห็นอะไร)
24
+ > วาดเป็น ASCII arrow flow; แตกแขนง (branch) ได้ตาม action/เงื่อนไข
25
+
26
+ ```
27
+ <!-- ตัวอย่าง — แทนที่ด้วย flow จริงของ change นี้ -->
28
+ [Entry / Landing]
29
+ │ กดปุ่มหลัก
30
+
31
+ [Form / Input screen] ──ใส่ข้อมูลไม่ครบ──▶ [Validation error inline]
32
+ │ submit สำเร็จ
33
+
34
+ [Result / Success screen]
35
+ │ กดย้อนกลับ
36
+
37
+ [Entry / Landing]
38
+ ```
39
+
40
+ ## 2. Wireframe ต่อ screen
41
+
42
+ > ASCII box หนึ่งกล่องต่อหนึ่ง screen — low-fidelity (กล่อง + label generic)
43
+ > ★ **ทำซ้ำ block "### Screen: ..." ด้านล่างได้หลายอัน** — หนึ่ง block ต่อหนึ่งหน้าจอใน user flow §1
44
+
45
+ ### Screen: <ชื่อจอ A — เช่น Landing>
46
+
47
+ ```
48
+ ┌─────────────────────────────────────────┐
49
+ │ [LOGO] [User menu] │ <- header / nav
50
+ ├─────────────────────────────────────────┤
51
+ │ │
52
+ │ <หัวข้อจอ / คำอธิบายสั้น> │
53
+ │ │
54
+ │ ┌─────────────────────────────────┐ │
55
+ │ │ [Primary content / list item] │ │
56
+ │ │ [Primary content / list item] │ │
57
+ │ └─────────────────────────────────┘ │
58
+ │ │
59
+ │ [ ปุ่มหลัก / CTA ] │ <- action
60
+ │ │
61
+ └─────────────────────────────────────────┘
62
+ ```
63
+
64
+ ### Screen: <ชื่อจอ B — เช่น Form>
65
+
66
+ <!-- ทำซ้ำ block นี้ต่อหนึ่งหน้าจอ; ลบ block ตัวอย่างที่ไม่ใช้ออก -->
67
+
68
+ ```
69
+ ┌─────────────────────────────────────────┐
70
+ │ ◀ กลับ <หัวข้อจอ> │
71
+ ├─────────────────────────────────────────┤
72
+ │ │
73
+ │ <Field 1 label> │
74
+ │ [____________________________] │ <- input
75
+ │ │
76
+ │ <Field 2 label> │
77
+ │ [____________________________] │
78
+ │ ( ) ตัวเลือก A ( ) ตัวเลือก B │ <- radio/option
79
+ │ │
80
+ │ [ ยกเลิก ] [ ยืนยัน ] │
81
+ │ │
82
+ └─────────────────────────────────────────┘
83
+ ```
84
+
85
+ ## 3. Screen states
86
+
87
+ > ต่อหนึ่ง screen ใน §2 ระบุหน้าตาแต่ละ state — empty / loading / error / success
88
+ > state ไหนไม่มีจริงสำหรับจอนั้น ใส่ `N/A` พร้อมเหตุผลสั้น
89
+
90
+ | Screen | empty | loading | error | success |
91
+ |---|---|---|---|---|
92
+ | `<ชื่อจอ A>` | `<ไม่มี item — แสดงอะไร>` | `<skeleton / spinner>` | `<โหลด list ไม่ได้ — แสดงอะไร>` | `<มี item — แสดงอะไร>` |
93
+ | `<ชื่อจอ B>` | `N/A (form ไม่มี empty)` | `<ขณะ submit — disable ปุ่ม>` | `<validation/server error inline>` | `<submit สำเร็จ → ไปจอไหน>` |
94
+
95
+ ## 4. Design-honor note
96
+
97
+ > สิ่งที่ `design.md` (§5 UI layer) + task ใน BUILD **ต้องทำตาม** wireframe นี้ — กัน implementation หลุดจากที่ user approve
98
+ > เขียนเป็นข้อผูกมัด (constraint) ที่ตรวจได้ ไม่ใช่คำอธิบายลอย ๆ
99
+
100
+ - [ ] design.md §5 (UI layer) **อ้าง wireframe นี้** + ทุก screen ใน §2 มี task รองรับ
101
+ - [ ] ลำดับ screen ใน task ตรงกับ user flow §1 (entry → ... → result)
102
+ - [ ] ทุก screen implement ครบ 4 state ตาม §3 (ไม่ข้าม error/empty)
103
+ - [ ] `<constraint เฉพาะ change นี้ — เช่น "ปุ่ม CTA ต้องอยู่ขวาล่างเสมอ", "field บังคับมี inline validation">`
104
+ - [ ] เปลี่ยน layout/flow จาก wireframe นี้ → ต้อง rerun approve gate (กลับ status เป็น `draft` แล้วให้ user ยืนยันใหม่)