@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.
Files changed (28) hide show
  1. package/.claude/commands/warnyin/build.md +29 -29
  2. package/.claude/commands/warnyin/design.md +24 -24
  3. package/.claude/commands/warnyin/discovery.md +17 -17
  4. package/.claude/commands/warnyin/init.md +1 -1
  5. package/.claude/commands/warnyin/verify.md +19 -19
  6. package/AGENTS.md +48 -48
  7. package/CLAUDE.md +40 -40
  8. package/package.json +1 -1
  9. package/warnyin/template/stages/[topic]/build.md +58 -58
  10. package/warnyin/template/stages/[topic]/business.md +21 -21
  11. package/warnyin/template/stages/[topic]/design.md +42 -42
  12. package/warnyin/template/stages/[topic]/discovery.md +69 -69
  13. package/warnyin/template/stages/[topic]/proposal.md +43 -43
  14. package/warnyin/template/stages/[topic]/research.md +49 -49
  15. package/warnyin/template/stages/[topic]/tasks/[task-name]/rule.md +13 -13
  16. package/warnyin/template/stages/[topic]/tasks/[task-name]/spec.md +36 -36
  17. package/warnyin/template/stages/[topic]/tasks/[task-name]/standard.md +21 -21
  18. package/warnyin/template/stages/[topic]/tasks/[task-name]/task.md +39 -39
  19. package/warnyin/template/stages/[topic]/test.md +46 -46
  20. package/warnyin/template/stages/[topic]/troubleshooting.md +34 -34
  21. package/warnyin/template/stages/[topic]/verify.md +44 -44
  22. package/warnyin/workflow/README.md +94 -94
  23. package/warnyin/workflow/init.md +68 -4
  24. package/warnyin/workflow/scripts/build-wave.mjs +107 -107
  25. package/warnyin/workflow/stages/build.md +94 -94
  26. package/warnyin/workflow/stages/design.md +116 -116
  27. package/warnyin/workflow/stages/discovery.md +77 -77
  28. package/warnyin/workflow/stages/verify.md +71 -71
package/warnyin/template/stages/[topic]/test.md CHANGED
@@ -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
+ ```
package/warnyin/template/stages/[topic]/troubleshooting.md CHANGED
@@ -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
+ > (คัดลอกบล็อกด้านบน)
package/warnyin/template/stages/[topic]/verify.md CHANGED
@@ -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 แล้ว
package/warnyin/workflow/README.md CHANGED
@@ -1,94 +1,94 @@
1
- # Warnyin Standard Workflow
2
-
3
- มาตรฐานกลางของ "วิธีทำงาน" (ways of work) สำหรับทุกโปรเจกต์ — สร้างทีม ผลิตผลงานคุณภาพ และเร็ว
4
- โดยเดินผ่าน 5 stage:
5
-
6
- ```
7
- Discovery (optional) ──▶ DESIGN ──▶ BUILD ──▶ VERIFY ──▶ SHIP
8
- ```
9
-
10
- แต่ละ stage มี **playbook กลางหนึ่งชุด** เป็น single source of truth ที่ AI ทุกเจ้าอ่านเหมือนกัน
11
-
12
- ---
13
-
14
- ## หลักการออกแบบ: Tool-agnostic, single source of truth
15
-
16
- แก่นของ workflow (กฎ / ขั้นตอน / เกณฑ์ผ่าน) เขียน **ครั้งเดียว** เป็น markdown ใน `warnyin/workflow/stages/`
17
- ส่วน AI แต่ละเครื่องมีแค่ **adapter บางๆ** ที่ "ชี้กลับ" มาที่ playbook กลางชุดเดียวกัน
18
-
19
- | AI tool | Adapter (จุดเชื่อม) | อ่าน playbook จาก |
20
- |---|---|---|
21
- | **Claude Code** | `.claude/commands/*.md` + `CLAUDE.md` | `warnyin/workflow/stages/*.md` |
22
- | **Codex** | `AGENTS.md` | `warnyin/workflow/stages/*.md` |
23
- | **Antigravity** | `AGENTS.md` | `warnyin/workflow/stages/*.md` |
24
- | เครื่องอื่นๆ | ชี้มาที่ `warnyin/workflow/stages/` ได้ทันที | `warnyin/workflow/stages/*.md` |
25
-
26
- > แก้กฎที่ `warnyin/workflow/stages/` ที่เดียว → ทุกเครื่องได้เหมือนกันทันที
27
- > เพิ่ม AI เจ้าใหม่ = เพิ่ม adapter บางๆ อีกหนึ่งไฟล์ ไม่ต้องแตะ logic
28
-
29
- ---
30
-
31
- ## โครงสร้าง repo
32
-
33
- ```
34
- bin/cli.mjs # npx installer — ติดตั้ง workflow ลงโปรเจกต์อื่น
35
-
36
- warnyin/ # ★ ทุกอย่างของ workflow รวมใต้โฟลเดอร์เดียว
37
- installer/templates/ # template CLAUDE.md สำหรับโปรเจกต์ปลายทาง (installer ใช้เอง — ไม่ถูก copy ไป target)
38
- workflow/ # playbook กลาง — single source of truth
39
- README.md # ไฟล์นี้ — ภาพรวม + วิธีรองรับหลาย AI
40
- init.md # playbook: INIT — วิเคราะห์โปรเจกต์ + เติม docs/ ครั้งแรก
41
- codemap.md # playbook: CODEMAP — สแกน + สร้าง codemap แบบ token-lean
42
- explore.md # playbook: EXPLORE — สำรวจ/ตอบคำถามแบบ read-only ไม่สร้าง artifact
43
- next.md # playbook: NEXT — เช็คงานค้าง + แนะนำขั้นตอนถัดไป (read-only)
44
- roles/ # role card กลาง: ba, po, sa, tech-lead, developer, qa, security, infra
45
- stages/ # discovery ✅ · design ✅ · build ✅ · verify ✅ · ship ✅
46
- scripts/
47
- build-wave.mjs # Workflow script: fan-out sub-agent ต่อ task ใน wave (worktree)
48
- template/ # ★ template ทั้งหมดรวมที่เดียว
49
- stages/[topic]/ # หนึ่งหน่วยงาน — copy เป็น warnyin/stages/<slug>
50
- discovery.md research.md # output ของ Discovery
51
- business.md proposal.md design.md # output ของ DESIGN
52
- tasks/[task-name]/... build.md # output ของ DESIGN (tasks) + BUILD
53
- test.md verify.md # output ของ VERIFY
54
- troubleshooting.md ship.md # KB ระหว่างงาน + สรุปส่งมอบของ SHIP
55
- docs/ # โครง docs — installer seed เข้า docs/ ตอนติดตั้ง
56
- project.md rule.md infra.md troubleshooting.md codemap/index.md
57
- techstack/[component]/ # copy เป็น docs/techstack/<component> (โดย /warnyin:init)
58
- features/[feature-name]/ # copy เป็น docs/features/<feature-name> (โดย SHIP)
59
- stages/ # พื้นที่ทำงานจริง ตาม topic
60
- context.md
61
- achieved/ # archive หลัง SHIP (<YYYY-MM-DD>-<slug>/)
62
-
63
- docs/ # ความรู้ถาวรระดับโปรเจกต์ — ของจริงล้วน (seed จาก warnyin/template/docs)
64
- project.md # ★ จุดเริ่มของ Discovery — อ่านก่อนเสมอ
65
- rule.md infra.md
66
- troubleshooting.md # ★ KB ปัญหา-วิธีแก้ (อ่านก่อนเมื่อ build เจอ error; SHIP ป้อนเข้า)
67
- codemap/ features/ techstack/
68
- ```
69
-
70
- ---
71
-
72
- ## การติดตั้งไปโปรเจกต์อื่น
73
-
74
- ```bash
75
- cd my-project
76
- npx @warnyin/agents # ติดตั้ง (ข้ามไฟล์ที่มีอยู่ ไม่เขียนทับ)
77
- npx @warnyin/agents --update # อัปเดต playbook กลางเป็นเวอร์ชันล่าสุด
78
- npx @warnyin/agents --dry-run # ดูก่อนว่าจะสร้าง/อัปเดตอะไร
79
- # ทางสำรอง (ไม่ผ่าน npm): npx github:warnyin/warnyin-agents
80
- ```
81
-
82
- - โปรเจกต์ที่มี `CLAUDE.md`/`AGENTS.md` อยู่แล้ว → installer ต่อท้ายเป็น section ไม่เขียนทับ
83
- - `--update` เขียนทับเฉพาะ core (`warnyin/workflow/`, `.claude/commands/warnyin/`, template ใน `warnyin/template/`) — ไม่แตะ `docs/` และงานจริง
84
- - หลังติดตั้ง → เปิด Claude Code แล้วรัน `/warnyin:init` ให้ agent วิเคราะห์โปรเจกต์ + เติม `docs/` (playbook: `warnyin/workflow/init.md`)
85
-
86
- ## วิธีใช้
87
-
88
- 1. เริ่มงานใหม่ → copy `warnyin/template/stages/[topic]/` เป็น `warnyin/stages/<ชื่อ-งาน-kebab-case>/`
89
- 2. รัน stage ตามลำดับ (Discovery ข้ามได้ถ้าเข้าใจ scope ชัดแล้ว)
90
- - Claude Code: `/warnyin:discovery <topic>`, `/warnyin:design <slug> <change>`
91
- - Codex / Antigravity: บอกให้ทำตาม `warnyin/workflow/stages/<stage>.md`
92
- 3. ผ่าน "gate" ของแต่ละ stage แล้วจึงไป stage ถัดไป
93
- 4. เมื่อ SHIP (`/warnyin:ship <slug>`) → promote ความรู้ของ topic ขึ้นเอกสารกลางใน `docs/`
94
- แล้วย้าย topic ไป `warnyin/stages/achieved/<YYYY-MM-DD>-<topic>/`
1
+ # Warnyin Standard Workflow
2
+
3
+ มาตรฐานกลางของ "วิธีทำงาน" (ways of work) สำหรับทุกโปรเจกต์ — สร้างทีม ผลิตผลงานคุณภาพ และเร็ว
4
+ โดยเดินผ่าน 5 stage:
5
+
6
+ ```
7
+ Discovery (optional) ──▶ DESIGN ──▶ BUILD ──▶ VERIFY ──▶ SHIP
8
+ ```
9
+
10
+ แต่ละ stage มี **playbook กลางหนึ่งชุด** เป็น single source of truth ที่ AI ทุกเจ้าอ่านเหมือนกัน
11
+
12
+ ---
13
+
14
+ ## หลักการออกแบบ: Tool-agnostic, single source of truth
15
+
16
+ แก่นของ workflow (กฎ / ขั้นตอน / เกณฑ์ผ่าน) เขียน **ครั้งเดียว** เป็น markdown ใน `warnyin/workflow/stages/`
17
+ ส่วน AI แต่ละเครื่องมีแค่ **adapter บางๆ** ที่ "ชี้กลับ" มาที่ playbook กลางชุดเดียวกัน
18
+
19
+ | AI tool | Adapter (จุดเชื่อม) | อ่าน playbook จาก |
20
+ |---|---|---|
21
+ | **Claude Code** | `.claude/commands/*.md` + `CLAUDE.md` | `warnyin/workflow/stages/*.md` |
22
+ | **Codex** | `AGENTS.md` | `warnyin/workflow/stages/*.md` |
23
+ | **Antigravity** | `AGENTS.md` | `warnyin/workflow/stages/*.md` |
24
+ | เครื่องอื่นๆ | ชี้มาที่ `warnyin/workflow/stages/` ได้ทันที | `warnyin/workflow/stages/*.md` |
25
+
26
+ > แก้กฎที่ `warnyin/workflow/stages/` ที่เดียว → ทุกเครื่องได้เหมือนกันทันที
27
+ > เพิ่ม AI เจ้าใหม่ = เพิ่ม adapter บางๆ อีกหนึ่งไฟล์ ไม่ต้องแตะ logic
28
+
29
+ ---
30
+
31
+ ## โครงสร้าง repo
32
+
33
+ ```
34
+ bin/cli.mjs # npx installer — ติดตั้ง workflow ลงโปรเจกต์อื่น
35
+
36
+ warnyin/ # ★ ทุกอย่างของ workflow รวมใต้โฟลเดอร์เดียว
37
+ installer/templates/ # template CLAUDE.md สำหรับโปรเจกต์ปลายทาง (installer ใช้เอง — ไม่ถูก copy ไป target)
38
+ workflow/ # playbook กลาง — single source of truth
39
+ README.md # ไฟล์นี้ — ภาพรวม + วิธีรองรับหลาย AI
40
+ init.md # playbook: INIT — วิเคราะห์โปรเจกต์ + เติม docs/ ครั้งแรก
41
+ codemap.md # playbook: CODEMAP — สแกน + สร้าง codemap แบบ token-lean
42
+ explore.md # playbook: EXPLORE — สำรวจ/ตอบคำถามแบบ read-only ไม่สร้าง artifact
43
+ next.md # playbook: NEXT — เช็คงานค้าง + แนะนำขั้นตอนถัดไป (read-only)
44
+ roles/ # role card กลาง: ba, po, sa, tech-lead, developer, qa, security, infra
45
+ stages/ # discovery ✅ · design ✅ · build ✅ · verify ✅ · ship ✅
46
+ scripts/
47
+ build-wave.mjs # Workflow script: fan-out sub-agent ต่อ task ใน wave (worktree)
48
+ template/ # ★ template ทั้งหมดรวมที่เดียว
49
+ stages/[topic]/ # หนึ่งหน่วยงาน — copy เป็น warnyin/stages/<slug>
50
+ discovery.md research.md # output ของ Discovery
51
+ business.md proposal.md design.md # output ของ DESIGN
52
+ tasks/[task-name]/... build.md # output ของ DESIGN (tasks) + BUILD
53
+ test.md verify.md # output ของ VERIFY
54
+ troubleshooting.md ship.md # KB ระหว่างงาน + สรุปส่งมอบของ SHIP
55
+ docs/ # โครง docs — installer seed เข้า docs/ ตอนติดตั้ง
56
+ project.md rule.md infra.md troubleshooting.md codemap/index.md
57
+ techstack/[component]/ # copy เป็น docs/techstack/<component> (โดย /warnyin:init)
58
+ features/[feature-name]/ # copy เป็น docs/features/<feature-name> (โดย SHIP)
59
+ stages/ # พื้นที่ทำงานจริง ตาม topic
60
+ context.md
61
+ achieved/ # archive หลัง SHIP (<YYYY-MM-DD>-<slug>/)
62
+
63
+ docs/ # ความรู้ถาวรระดับโปรเจกต์ — ของจริงล้วน (seed จาก warnyin/template/docs)
64
+ project.md # ★ จุดเริ่มของ Discovery — อ่านก่อนเสมอ
65
+ rule.md infra.md
66
+ troubleshooting.md # ★ KB ปัญหา-วิธีแก้ (อ่านก่อนเมื่อ build เจอ error; SHIP ป้อนเข้า)
67
+ codemap/ features/ techstack/
68
+ ```
69
+
70
+ ---
71
+
72
+ ## การติดตั้งไปโปรเจกต์อื่น
73
+
74
+ ```bash
75
+ cd my-project
76
+ npx @warnyin/agents # ติดตั้ง (ข้ามไฟล์ที่มีอยู่ ไม่เขียนทับ)
77
+ npx @warnyin/agents --update # อัปเดต playbook กลางเป็นเวอร์ชันล่าสุด
78
+ npx @warnyin/agents --dry-run # ดูก่อนว่าจะสร้าง/อัปเดตอะไร
79
+ # ทางสำรอง (ไม่ผ่าน npm): npx github:warnyin/warnyin-agents
80
+ ```
81
+
82
+ - โปรเจกต์ที่มี `CLAUDE.md`/`AGENTS.md` อยู่แล้ว → installer ต่อท้ายเป็น section ไม่เขียนทับ
83
+ - `--update` เขียนทับเฉพาะ core (`warnyin/workflow/`, `.claude/commands/warnyin/`, template ใน `warnyin/template/`) — ไม่แตะ `docs/` และงานจริง
84
+ - หลังติดตั้ง → เปิด Claude Code แล้วรัน `/warnyin:init` ให้ agent วิเคราะห์โปรเจกต์ + เติม `docs/` (playbook: `warnyin/workflow/init.md`)
85
+
86
+ ## วิธีใช้
87
+
88
+ 1. เริ่มงานใหม่ → copy `warnyin/template/stages/[topic]/` เป็น `warnyin/stages/<ชื่อ-งาน-kebab-case>/`
89
+ 2. รัน stage ตามลำดับ (Discovery ข้ามได้ถ้าเข้าใจ scope ชัดแล้ว)
90
+ - Claude Code: `/warnyin:discovery <topic>`, `/warnyin:design <slug> <change>`
91
+ - Codex / Antigravity: บอกให้ทำตาม `warnyin/workflow/stages/<stage>.md`
92
+ 3. ผ่าน "gate" ของแต่ละ stage แล้วจึงไป stage ถัดไป
93
+ 4. เมื่อ SHIP (`/warnyin:ship <slug>`) → promote ความรู้ของ topic ขึ้นเอกสารกลางใน `docs/`
94
+ แล้วย้าย topic ไป `warnyin/stages/achieved/<YYYY-MM-DD>-<topic>/`
package/warnyin/workflow/init.md CHANGED
@@ -3,6 +3,9 @@
3
3
  > **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
4
4
  > เป้าหมาย: ทำให้ `docs/` สะท้อนโปรเจกต์จริง — เพื่อให้ทุก stage (Discovery→SHIP) เริ่มจากความรู้ที่ถูกต้อง ไม่ใช่โครงว่างเปล่า
5
5
 
6
+ > ⚠️ **Deliverable ของ INIT = ไฟล์จริงที่ถูกเขียนลงดิสก์ใน `docs/`**
7
+ > การวิเคราะห์แล้วสรุปในแชทอย่างเดียว **ถือว่ายังไม่จบงาน** — INIT จะจบได้ก็ต่อเมื่อทุกไฟล์ในตาราง §4 ถูก write ลง `docs/` จริงและผ่าน gate §5
8
+
6
9
  ---
7
10
 
8
11
  ## 1. INIT คืออะไร / ใช้เมื่อไหร่
@@ -15,11 +18,14 @@
15
18
  ## 2. หลักการทำงาน (operating principles)
16
19
 
17
20
  1. **โค้ดตอบได้ → อ่านโค้ดเอง ห้ามเดา** — structure, techstack, convention, วิธี build/test, infra วิเคราะห์จาก **โค้ดจริง + config จริง** เท่านั้น
18
- 2. **ข้อมูลธุรกิจโค้ดตอบไม่ได้ → สัมภาษณ์ user** — เป้าหมายโปรเจกต์ ลูกค้า ขอบเขต ความสำคัญ: **ถามทีละข้อ + เสนอคำตอบแนะนำทุกครั้ง** (เดาจาก README/โค้ดเป็น recommended answer ให้ user แค่ยืนยัน/แก้)
21
+ 2. **ข้อมูลธุรกิจโค้ดตอบไม่ได้ → สัมภาษณ์ user ผ่าน role lens เฉพาะทาง** — เป้าหมายโปรเจกต์ ลูกค้า ขอบเขต ความสำคัญ: AI หลัก **สวม lens ของ BA** (`warnyin/workflow/roles/ba.md`) และ **PO** (`warnyin/workflow/roles/po.md`) ใช้ checklist ของทั้งสองเป็นชุดคำถาม — **ถามทีละข้อ + เสนอคำตอบแนะนำทุกครั้ง** (เดาจาก README/โค้ดเป็น recommended answer ให้ user แค่ยืนยัน/แก้)
22
+ - role ที่ต้องคุยกับ user เป็น **lens เสมอ ไม่ใช่ sub-agent** (sub-agent คุยกับ user ไม่ได้) — fan-out sub-agent ใช้ได้เฉพาะงานวิเคราะห์โค้ด read-only (ข้อ 5)
23
+ - ถ้าติดตั้ง skill `product-management` ไว้ (ดู `/warnyin:install-skill po`) → หยิบมาเสริมมุมตอนตั้งคำถาม scope/priority ได้
19
24
  3. **เสนอ summary ก่อนเขียน** — สรุปสิ่งที่วิเคราะห์ได้ + รายการไฟล์ docs/ ที่จะเขียน ให้ user ยืนยัน **ครั้งเดียว** แล้วจึงเขียนจริง
20
25
  4. **ไฟล์ docs/ ที่มีเนื้อหาอยู่แล้ว → เติม/อัปเดต ไม่เขียนทับทิ้ง** — ของเดิมของ user มีค่าเสมอ
21
26
  5. **วิเคราะห์หลาย component ขนานได้** — fan-out sub-agent (read-only) หนึ่งตัวต่อหนึ่ง component; เครื่องที่ไม่มี sub-agent → วิเคราะห์ทีละ component ด้วยหลักการเดียวกัน
22
27
  6. **ไม่แน่ใจ → ระบุว่า "ยังว่าง รอเติม" ชัดเจน** — ห้ามแต่งเนื้อหาขึ้นเองเพื่อให้ไฟล์ดูเต็ม
28
+ 7. **เขียนไฟล์จริงเสมอ ห้ามจบแค่สรุปในแชท** — หลัง user ยืนยัน summary ต้อง write ทุกไฟล์ในตาราง §4 ลง `docs/` ด้วย (copy template → เติมเนื้อหา); วิเคราะห์เสร็จแล้วไม่เขียนไฟล์ = งานล้มเหลว
23
29
 
24
30
  ---
25
31
 
@@ -28,9 +34,42 @@
28
34
  1. **สแกนภาพรวม:** โครงสร้าง repo, package manifest, ภาษา/framework, แบ่งเป็น **component** อะไรบ้าง (เช่น api-service, admin-console)
29
35
  2. **วิเคราะห์ลึกต่อ component (ขนานได้, read-only):** โครงสร้างโฟลเดอร์/โมดูล, pattern/convention ที่ใช้จริงในโค้ด, วิธี build/test ที่มีอยู่
30
36
  3. **วิเคราะห์ infra:** docker/compose, env, service ที่ต้องรันสำหรับ local dev
31
- 4. **สัมภาษณ์ user เติมส่วนธุรกิจ:** เป้าหมายโปรเจกต์ ลูกค้า ขอบเขต — ทีละข้อ + recommended answer
32
- 5. **เสนอ summary → user ยืนยันครั้งเดียว → เขียน docs/** (ตามตาราง Output ข้อ 4)
33
- 6. **รายงานปิดท้าย:** ส่วนไหนยังว่าง/ไม่แน่ใจ ให้ user เติมภายหลัง → พร้อมเริ่มงานแรกด้วย `/warnyin:discovery` หรือ `/warnyin:design`
37
+ 4. **สัมภาษณ์ user เติมส่วนที่โค้ดตอบไม่ได้ (สวม BA + PO lens):**
38
+ - **ก่อนถาม → สแกนสิ่งที่มีอยู่ก่อนเสมอ:** README, `docs/project.md` เดิม, comment/config ในโค้ด — เอามาเป็น recommended answer; **ถามเฉพาะช่องที่ยัง "ขาดหาย" จริง** ไม่ถามซ้ำสิ่งที่หาคำตอบได้เอง
39
+ - **สวม BA lens** (`warnyin/workflow/roles/ba.md`) ไล่ checklist: ปัญหาจริง/ใครเจ็บ, as-is→to-be, edge case ของ process, ข้อมูล/เจ้าของ, ข้อจำกัด (กฎหมาย/ระบบเดิม), acceptance วัดได้ไหม
40
+ - **สวม PO lens** (`warnyin/workflow/roles/po.md`) ไล่ checklist: persona หลัก, success metric ที่วัดได้, MVP เล็กสุด, priority (must/should/could), why-now, scope-out
41
+ - ถาม **ทีละข้อ + เสนอคำตอบแนะนำทุกครั้ง** (AskUserQuestion) — เป็น lens ของ AI หลัก **ห้าม fan-out sub-agent มาสัมภาษณ์** (คุยกับ user ไม่ได้)
42
+ - ถ้าติดตั้ง `product-management` skill ไว้ → ใช้เสริมมุม scope/priority
43
+ - คำตอบที่ได้ → ใช้เติม `docs/project.md` (เป้าหมาย/ลูกค้า/ขอบเขต) และ `rule.md` ของแต่ละ component (กฎที่ user สั่ง)
44
+ 5. **เสนอ summary → user ยืนยันครั้งเดียว**
45
+ 6. **เขียนไฟล์จริงลง `docs/` ให้ครบตาราง §4 (ขั้นบังคับ ห้ามข้าม)** — ทำตามกลไก 6.1–6.4 นี้:
46
+
47
+ **6.1 ไฟล์ root** — copy template แล้วเติม:
48
+ ```
49
+ mkdir -p docs
50
+ cp warnyin/template/docs/project.md docs/project.md
51
+ cp warnyin/template/docs/infra.md docs/infra.md
52
+ cp warnyin/template/docs/rule.md docs/rule.md
53
+ cp warnyin/template/docs/troubleshooting.md docs/troubleshooting.md
54
+ ```
55
+ - ไฟล์ไหนมีอยู่แล้วใน `docs/` → **ห้าม `cp` ทับ** ให้เปิดอ่านแล้ว Edit เติมแทน
56
+ - `project.md` → เติมจากผลสัมภาษณ์ user (ข้อ 4) · `infra.md` → เติมจาก config จริง (ข้อ 3) · `rule.md`/`troubleshooting.md` → วางโครงหัวข้อ ใส่ `<!-- ยังว่าง รอเติม -->` ในส่วนที่ยังไม่มีข้อมูล
57
+
58
+ **6.2 โฟลเดอร์ component** — วนทำ **ทุก component** ที่ได้จากข้อ 1 (สมมติชื่อจริง `<name>`):
59
+ ```
60
+ cp -R "warnyin/template/docs/techstack/[component]" "docs/techstack/<name>"
61
+ ```
62
+ - ทำซ้ำคำสั่งนี้หนึ่งครั้งต่อหนึ่ง component (เช่น `api-service`, `admin-console`) — **rename เป็นชื่อจริงเสมอ**
63
+ - หลัง copy ครบ → ต้อง **ไม่มี** โฟลเดอร์ `docs/techstack/[component]` (ที่มีวงเล็บ) หลงเหลือ; ถ้ามีให้ลบทิ้ง
64
+
65
+ **6.3 เติมเนื้อหา 5 ไฟล์ในแต่ละ component** ด้วย Write/Edit (อิงผลวิเคราะห์ข้อ 2):
66
+ - `about.md` (component คืออะไร/ภาษา/framework) · `structure.md` (โครงโฟลเดอร์) · `standard.md` (convention ที่พบจริง + ยืนยัน user) · `rule.md` (กฎที่ user สั่ง — ถามก่อน ห้ามเดา) · `test.md` (framework/คำสั่งเทส)
67
+ - ส่วนที่ข้อมูลไม่พอ → ใส่ `<!-- ยังว่าง รอเติม -->` ห้ามแต่ง
68
+
69
+ **6.4 codemap** — สร้าง `docs/codemap/` ตาม playbook `warnyin/workflow/codemap.md` (token-lean) อย่างน้อยต้องมี `index.md`
70
+
71
+ 7. **Verify ว่าเขียนจริง:** รัน `find docs -type f` เทียบกับตาราง §4 — ทุกแถวต้องมีไฟล์จริง, ทุก component มีครบ 5 ไฟล์, ไม่มีโฟลเดอร์/ไฟล์ที่ยังมี `[component]` (วงเล็บ) หลงเหลือ
72
+ 8. **รายงานปิดท้าย:** ส่วนไหนยังว่าง/ไม่แน่ใจ ให้ user เติมภายหลัง → พร้อมเริ่มงานแรกด้วย `/warnyin:discovery` หรือ `/warnyin:design`
34
73
 
35
74
  ---
36
75
 
@@ -52,8 +91,33 @@
52
91
 
53
92
  ---
54
93
 
94
+ ## 4.1 Source map — `project` / `infra` / `rule` หาจากไหนใน codebase
95
+
96
+ > หลัก: §2 ข้อ 1 **"โค้ดตอบได้ → อ่านเอง"** · §2 ข้อ 2 **"ตอบไม่ได้ → สัมภาษณ์"** — 3 ไฟล์นี้คาบเส้น จึงระบุแหล่งให้ชัด ก่อนจะไปถาม user
97
+
98
+ ### `infra.md` — ขุดจาก config จริงได้เกือบทั้งไฟล์ ✅
99
+ | field | หาจากไฟล์ไหน |
100
+ |---|---|
101
+ | Service ที่ต้องรัน | `docker-compose.yml`/`compose.yaml`, `Dockerfile`, `.devcontainer/`, `Procfile`, k8s/helm manifests, `Makefile` |
102
+ | วิธีรัน local | `package.json` scripts (`dev`/`start`), `Makefile` targets, `turbo.json`/`nx.json`, `.nvmrc`/`.node-version`, README ส่วน "Getting Started" |
103
+ | Env vars | `.env.example`/`.env.sample`, env schema ในโค้ด (zod/envalid), `environment:` ใน compose, จุดที่อ้าง `process.env.*`/`os.environ` — **อ่านชื่อ+ความหมาย ห้ามดูดค่า secret จริง** |
104
+ | staging/prod | `.github/workflows/`, `vercel.json`, `fly.toml`, terraform, deploy scripts |
105
+
106
+ ### `rule.md` (global) — โค้ดให้แค่ recommended, เจตนาต้องถาม ⚠️
107
+ - **derive เป็น recommended ได้:** linter/formatter (`eslint.config.*`, `.prettierrc`, `.editorconfig`), `tsconfig` strict flags, pre-commit (`.husky/`, `lefthook`, `.pre-commit-config`), CI gates ใน workflows, `commitlint`, `CONTRIBUTING.md` / `CLAUDE.md` / `AGENTS.md` เดิม
108
+ - **ต้องถาม user:** กฎที่ "อยากบังคับ" แต่ config ยังไม่ enforce — โค้ดบอกได้แค่ "ตอนนี้ enforce อะไร" ไม่ใช่ "อยากให้ enforce อะไร"
109
+ - ตาม template `rule.md`: SHIP เป็นคน promote กฎเข้ามา — ตอน INIT แค่วางโครง + ใส่ recommended ที่ derive ได้ ไม่ต้องเค้นเยอะ
110
+
111
+ ### `project.md` — โค้ดตอบไม่ได้ เป็นงานสัมภาษณ์ (BA/PO lens) 🗣️
112
+ - **derive เป็น recommended ได้:** ชื่อ/คำอธิบายสั้นจาก `package.json` `description` + repo name + README บรรทัดแรก · persona/ขอบเขตจาก README/landing/comment
113
+ - **ต้องสัมภาษณ์เท่านั้น:** เป้าหมาย, success metric, scope-out, why-now — โค้ดไม่มีทางรู้
114
+
115
+ ---
116
+
55
117
  ## 5. Gate → จบ INIT เมื่อ
56
118
 
119
+ - [ ] **ไฟล์ทุกแถวในตาราง §4 ถูกเขียนลง `docs/` จริง** (ยืนยันด้วย `find docs -type f`) — ไม่มีแถวไหนเหลือแค่ในแชท
120
+ - [ ] ไม่มีโฟลเดอร์ชื่อ `[component]` (มีวงเล็บ) หลงเหลือ — ถูก copy เป็นชื่อ component จริงครบทุกตัว
57
121
  - [ ] `docs/project.md` มีเป้าหมาย/ลูกค้า/ขอบเขต ที่ user ยืนยันแล้ว
58
122
  - [ ] `docs/techstack/` ครบทุก component ที่พบ (about + structure + standard + test)
59
123
  - [ ] `docs/codemap/index.md` + `docs/infra.md` ตรงกับโค้ด/config จริง