@warnyin/agents 0.1.0 → 0.4.0

package/warnyin/workflow/README.md

@@ -0,0 +1,92 @@
+# Warnyin Standard Workflow
+
+มาตรฐานกลางของ "วิธีทำงาน" (ways of work) สำหรับทุกโปรเจกต์ — สร้างทีม ผลิตผลงานคุณภาพ และเร็ว
+โดยเดินผ่าน 5 stage:
+
+```
+Discovery (optional) ──▶ DESIGN ──▶ BUILD ──▶ VERIFY ──▶ SHIP
+```
+
+แต่ละ stage มี **playbook กลางหนึ่งชุด** เป็น single source of truth ที่ AI ทุกเจ้าอ่านเหมือนกัน
+
+---
+
+## หลักการออกแบบ: Tool-agnostic, single source of truth
+
+แก่นของ workflow (กฎ / ขั้นตอน / เกณฑ์ผ่าน) เขียน **ครั้งเดียว** เป็น markdown ใน `warnyin/workflow/stages/`
+ส่วน AI แต่ละเครื่องมีแค่ **adapter บางๆ** ที่ "ชี้กลับ" มาที่ playbook กลางชุดเดียวกัน
+
+| AI tool | Adapter (จุดเชื่อม) | อ่าน playbook จาก |
+|---|---|---|
+| **Claude Code** | `.claude/commands/*.md` + `CLAUDE.md` | `warnyin/workflow/stages/*.md` |
+| **Codex** | `AGENTS.md` | `warnyin/workflow/stages/*.md` |
+| **Antigravity** | `AGENTS.md` | `warnyin/workflow/stages/*.md` |
+| เครื่องอื่นๆ | ชี้มาที่ `warnyin/workflow/stages/` ได้ทันที | `warnyin/workflow/stages/*.md` |
+
+> แก้กฎที่ `warnyin/workflow/stages/` ที่เดียว → ทุกเครื่องได้เหมือนกันทันที
+> เพิ่ม AI เจ้าใหม่ = เพิ่ม adapter บางๆ อีกหนึ่งไฟล์ ไม่ต้องแตะ logic
+
+---
+
+## โครงสร้าง repo
+
+```
+bin/cli.mjs            # npx installer — ติดตั้ง workflow ลงโปรเจกต์อื่น
+
+warnyin/               # ★ ทุกอย่างของ workflow รวมใต้โฟลเดอร์เดียว
+  installer/templates/ #   template CLAUDE.md สำหรับโปรเจกต์ปลายทาง (installer ใช้เอง — ไม่ถูก copy ไป target)
+  workflow/            # playbook กลาง — single source of truth
+    README.md          #   ไฟล์นี้ — ภาพรวม + วิธีรองรับหลาย AI
+    init.md            #   playbook: INIT — วิเคราะห์โปรเจกต์ + เติม docs/ ครั้งแรก
+    codemap.md         #   playbook: CODEMAP — สแกน + สร้าง codemap แบบ token-lean
+    roles/             #   role card กลาง: ba, po, sa, tech-lead, developer, qa, security, infra
+    stages/            #   discovery ✅ · design ✅ · build ✅ · verify ✅ · ship ✅
+    scripts/
+      build-wave.mjs   #   Workflow script: fan-out sub-agent ต่อ task ใน wave (worktree)
+  template/            # ★ template ทั้งหมดรวมที่เดียว
+    stages/[topic]/    #   หนึ่งหน่วยงาน — copy เป็น warnyin/stages/<slug>
+      discovery.md  research.md            # output ของ Discovery
+      business.md  proposal.md  design.md  # output ของ DESIGN
+      tasks/[task-name]/...  build.md      # output ของ DESIGN (tasks) + BUILD
+      test.md  verify.md                   # output ของ VERIFY
+      troubleshooting.md  ship.md          # KB ระหว่างงาน + สรุปส่งมอบของ SHIP
+    docs/                                  #   โครง docs — installer seed เข้า docs/ ตอนติดตั้ง
+      project.md  rule.md  infra.md  troubleshooting.md  codemap/index.md
+      techstack/[component]/               #   copy เป็น docs/techstack/<component> (โดย /warnyin:init)
+      features/[feature-name]/             #   copy เป็น docs/features/<feature-name> (โดย SHIP)
+  stages/              # พื้นที่ทำงานจริง ตาม topic
+    context.md
+    achieved/          #   archive หลัง SHIP (<YYYY-MM-DD>-<slug>/)
+
+docs/                  # ความรู้ถาวรระดับโปรเจกต์ — ของจริงล้วน (seed จาก warnyin/template/docs)
+  project.md           # ★ จุดเริ่มของ Discovery — อ่านก่อนเสมอ
+  rule.md  infra.md
+  troubleshooting.md   # ★ KB ปัญหา-วิธีแก้ (อ่านก่อนเมื่อ build เจอ error; SHIP ป้อนเข้า)
+  codemap/  features/  techstack/
+```
+
+---
+
+## การติดตั้งไปโปรเจกต์อื่น
+
+```bash
+cd my-project
+npx @warnyin/agents             # ติดตั้ง (ข้ามไฟล์ที่มีอยู่ ไม่เขียนทับ)
+npx @warnyin/agents --update    # อัปเดต playbook กลางเป็นเวอร์ชันล่าสุด
+npx @warnyin/agents --dry-run   # ดูก่อนว่าจะสร้าง/อัปเดตอะไร
+# ทางสำรอง (ไม่ผ่าน npm): npx github:warnyin/warnyin-agents
+```
+
+- โปรเจกต์ที่มี `CLAUDE.md`/`AGENTS.md` อยู่แล้ว → installer ต่อท้ายเป็น section ไม่เขียนทับ
+- `--update` เขียนทับเฉพาะ core (`warnyin/workflow/`, `.claude/commands/warnyin/`, template ใน `warnyin/template/`) — ไม่แตะ `docs/` และงานจริง
+- หลังติดตั้ง → เปิด Claude Code แล้วรัน `/warnyin:init` ให้ agent วิเคราะห์โปรเจกต์ + เติม `docs/` (playbook: `warnyin/workflow/init.md`)
+
+## วิธีใช้
+
+1. เริ่มงานใหม่ → copy `warnyin/template/stages/[topic]/` เป็น `warnyin/stages/<ชื่อ-งาน-kebab-case>/`
+2. รัน stage ตามลำดับ (Discovery ข้ามได้ถ้าเข้าใจ scope ชัดแล้ว)
+   - Claude Code: `/warnyin:discovery <topic>`, `/warnyin:design <slug> <change>`
+   - Codex / Antigravity: บอกให้ทำตาม `warnyin/workflow/stages/<stage>.md`
+3. ผ่าน "gate" ของแต่ละ stage แล้วจึงไป stage ถัดไป
+4. เมื่อ SHIP (`/warnyin:ship <slug>`) → promote ความรู้ของ topic ขึ้นเอกสารกลางใน `docs/`
+   แล้วย้าย topic ไป `warnyin/stages/achieved/<YYYY-MM-DD>-<topic>/`

package/warnyin/workflow/codemap.md

@@ -0,0 +1,91 @@
+# CODEMAP — สแกนโครงสร้างโปรเจกต์ + สร้าง architecture codemap แบบ token-lean
+
+> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
+> เป้าหมาย: `docs/codemap/` ที่ **ประหยัด token** สำหรับให้ AI โหลดเข้า context — โครงสร้างระดับสูง ไม่ใช่ implementation detail
+
+---
+
+## 1. ใช้เมื่อไหร่
+
+- หลังเพิ่ม feature ใหญ่ / refactor ครั้งสำคัญ
+- `/warnyin:init` ใช้ playbook นี้ตอนสร้าง codemap ครั้งแรก
+- **SHIP** ใช้ตอนขั้น "อัปเดต code map ทั้งหมด"
+
+---
+
+## 2. ขั้นตอน
+
+### Step 1: สแกนโครงสร้างโปรเจกต์
+- ระบุชนิดโปรเจกต์: monorepo / single app / library / microservice
+- หา source directory ทั้งหมด (`src/`, `lib/`, `app/`, `packages/`, ...)
+- map entry points (`main.ts`, `index.ts`, `app.py`, `main.go`, ...)
+- สแกนขนานได้: fan-out sub-agent (read-only) ต่อ component/พื้นที่ — เครื่องที่ไม่มี sub-agent → ไล่ทีละส่วน
+
+### Step 2: สร้าง/อัปเดต codemap ใน `docs/codemap/`
+
+| ไฟล์ | เนื้อหา |
+|---|---|
+| `index.md` | สารบัญทั้งชุด + ภาพรวม component + จุดเข้า |
+| `architecture.md` | system diagram ระดับสูง, service boundary, data flow |
+| `backend.md` | API routes, middleware chain, service → repository mapping |
+| `frontend.md` | page tree, component hierarchy, state management flow |
+| `data.md` | ตาราง DB, relationship, migration history |
+| `dependencies.md` | external service, third-party integration, shared library |
+
+**สร้างเฉพาะไฟล์ที่ relevant** — โปรเจกต์ไม่มี frontend → ไม่ต้องมี `frontend.md`
+
+#### รูปแบบ codemap (token-lean)
+
+```markdown
+# Backend Architecture
+
+## Routes
+POST /api/users → UserController.create → UserService.create → UserRepo.insert
+GET  /api/users/:id → UserController.get → UserService.findById → UserRepo.findById
+
+## Key Files
+src/services/user.ts (business logic, 120 lines)
+src/repos/user.ts (database access, 80 lines)
+
+## Dependencies
+- PostgreSQL (primary data store)
+- Redis (session cache, rate limiting)
+- Stripe (payment processing)
+```
+
+### Step 3: Diff detection
+- มี codemap เดิมอยู่ → คำนวณ % การเปลี่ยนแปลง
+- เปลี่ยน **> 30%** → แสดง diff + **ขอ user อนุมัติก่อนเขียนทับ**
+- เปลี่ยน **≤ 30%** → อัปเดต in place ได้เลย
+
+### Step 4: Metadata
+ใส่ freshness header บนสุดของทุกไฟล์:
+```html
+<!-- Generated: YYYY-MM-DD | Files scanned: N | Token estimate: ~X -->
+```
+
+### Step 5: Analysis report → `.reports/codemap-diff.txt`
+- ไฟล์ added / removed / modified ตั้งแต่สแกนครั้งล่าสุด
+- dependency ใหม่ที่ตรวจพบ
+- architecture changes (route ใหม่, service ใหม่ ฯลฯ)
+- คำเตือน staleness: doc ที่ไม่ถูกอัปเดต 90+ วัน
+
+---
+
+## 3. หลักการ (tips)
+
+- โฟกัสโครงสร้างระดับสูง — **ไม่ใช่** implementation detail
+- ใช้ file path + function signature แทน code block เต็ม
+- แต่ละ codemap **< 1000 tokens** เพื่อโหลดเข้า context ได้ถูก
+- ใช้ ASCII diagram แทนคำบรรยาย data flow ยืดยาว
+- **ทุกอย่างต้องมาจากโค้ดจริง ณ วันสแกน — ห้ามเดา/ห้ามเขียนจากความจำ**
+
+---
+
+## 4. Gate — จบเมื่อ
+
+- [ ] codemap ทุกไฟล์ตรงโค้ดจริง + มี freshness header
+- [ ] `index.md` ลิงก์ครบทุกไฟล์ codemap ที่มี
+- [ ] ทุกไฟล์ token-lean (< 1000 tokens)
+- [ ] diff > 30% ผ่านการอนุมัติจาก user แล้ว
+- [ ] `.reports/codemap-diff.txt` เขียนแล้ว

package/{workflow → warnyin/workflow}/init.md

@@ -36,6 +36,8 @@
 
 ## 4. Output (เขียน/เติมที่ `docs/`)
 
+> โฟลเดอร์ component จริงให้ copy จาก template `warnyin/template/docs/techstack/[component]/` เป็นชื่อจริง (เช่น `api-service/`) — ห้ามทิ้งโฟลเดอร์ `[component]` ว่างไว้เฉยๆ โดยไม่สร้างของจริง
+
 | ไฟล์ | เนื้อหา | แหล่งข้อมูล |
 |---|---|---|
 | `docs/project.md` | โปรเจกต์คืออะไร เป้าหมาย ลูกค้า ขอบเขต | สัมภาษณ์ user (+ README เดิมเป็น recommended) |
@@ -44,7 +46,7 @@
 | `docs/techstack/<component>/standard.md` | pattern/convention ที่พบจริงในโค้ด (ยืนยันกับ user) | โค้ดจริง + user |
 | `docs/techstack/<component>/rule.md` | กฎที่ user ต้องการบังคับ (ถามก่อน ห้ามเดา) | user |
 | `docs/techstack/<component>/test.md` | วิธีเทสที่ใช้อยู่ (framework, คำสั่ง, e2e) | โค้ด/config จริง |
-| `docs/codemap/index.md` | แผนที่โค้ดภาพรวม: component, จุดเข้า, โฟลเดอร์สำคัญ | โค้ดจริง |
+| `docs/codemap/` | แผนที่โค้ดทั้งชุด — สร้างตาม playbook `warnyin/workflow/codemap.md` (token-lean) | โค้ดจริง |
 | `docs/infra.md` | local env: service ที่ต้องรัน, วิธีรัน, env vars | config จริง |
 | `docs/rule.md`, `docs/troubleshooting.md` | วางโครงหัวข้อ รอเติมระหว่างใช้งานจริง | — |
 

package/warnyin/workflow/roles/README.md

@@ -0,0 +1,46 @@
+# Roles — role card กลางของ workflow
+
+> **แก่นกลาง tool-agnostic** — role card แต่ละใบคือ "วิธีคิด + checklist" ของหนึ่งบทบาท
+> AI ทุกเจ้าใช้ไฟล์ชุดเดียวกัน: เป็น **lens** ของ AI หลัก หรือเป็น **system prompt** ของ sub-agent
+
+## หลักการ
+
+- **lens** = AI หลักอ่าน role card แล้วใช้มุมมอง/checklist นั้นทำงานเอง (role ที่ต้องคุยกับ user เป็น lens เสมอ — sub-agent คุยกับ user ไม่ได้)
+- **sub-agent (reviewer)** = fan-out ตัวแทน role ไปวิเคราะห์/รีวิวแบบอิสระขนานกัน (read-only) — ได้หลายมุมพร้อมกันโดยไม่ bias
+- Claude Code มี adapter ที่ `.claude/agents/warnyin-<role>.md`; เครื่องอื่นใช้ role card เป็น prompt ตรงๆ ได้
+
+## ตาราง role ↔ stage
+
+| Role | ไฟล์ | ใช้ใน stage | รูปแบบ |
+|---|---|---|---|
+| BA (Business Analyst) | `ba.md` | Discovery | lens ตอนสัมภาษณ์/ตี scope |
+| PO (Product Owner) | `po.md` | Discovery | lens ตอนจัด priority/ตัด scope |
+| SA (Solution Architect) | `sa.md` | DESIGN | lens ตอนออกแบบ + reviewer ใน panel |
+| Tech Lead | `tech-lead.md` | DESIGN | lens ตอนแตก task + reviewer ใน panel |
+| Developer | `developer.md` | BUILD | system prompt ของ build agent ทุกตัว |
+| QA | `qa.md` | VERIFY + DESIGN panel | lens ของ strategy tester + reviewer |
+| Security (DevSecOps) | `security.md` | DESIGN panel | reviewer |
+| Infra | `infra.md` | DESIGN panel | reviewer |
+
+## โครงของ role card ทุกใบ
+
+1. **Mission** — บทบาทนี้มีไว้ทำอะไร
+2. **Lens** — มองงานผ่านมุมไหน
+3. **Checklist** — สิ่งที่ต้องไล่เช็คทุกครั้ง
+4. **Output** — ต้องส่งมอบอะไร รูปแบบไหน
+
+> เพิ่ม role ใหม่ = เพิ่มไฟล์ที่นี่ + adapter `.claude/agents/warnyin-<role>.md` (ถ้าใช้เป็น sub-agent) + ระบุจุดใช้ใน playbook
+
+## Skill เสริมต่อ role (optional)
+
+แต่ละ role card มี section "Skill เสริม" — แนวทางคือ **reference ไม่ vendor**: โปรเจกต์ไหนอยากใช้ค่อยติดตั้งเอง
+
+| Role | Skill | ที่มา |
+|---|---|---|
+| SA | `architect-review` | `npx skills add sickn33/antigravity-awesome-skills@architect-review -g` |
+| PO | `product-management` | `npx skills add vasilyu1983/ai-agents-public@product-management -g` |
+| Developer | `tdd-orchestrator` | `npx skills add sickn33/antigravity-awesome-skills@tdd-orchestrator -g` |
+| QA | `browser-test` | `npx skills add ruvnet/ruflo@browser-test -g` |
+| Tech Lead | `/code-review` | Claude Code built-in |
+| Security | `/security-review` | Claude Code built-in |
+| BA, Infra | — | ยังไม่มี skill ภายนอกที่ผ่านเกณฑ์คุณภาพ (ใช้ role card พอ) |

package/warnyin/workflow/roles/ba.md

@@ -0,0 +1,25 @@
+# Role: BA (Business Analyst)
+
+> ใช้ใน: **Discovery** — เป็น lens ของ AI หลักตอนสัมภาษณ์/ตี scope (ไม่ใช่ sub-agent เพราะต้องคุยกับ user)
+
+## Mission
+เปลี่ยนความต้องการที่คลุมเครือให้เป็น requirement ที่ชัด ตรวจสอบได้ และสะท้อน business process จริง
+
+## Lens
+- business process จริง: ผู้ใช้/ระบบทำอะไร ก่อน-หลัง อย่างไร (as-is → to-be)
+- ข้อมูลที่ไหลในกระบวนการ: มาจากไหน ใครแก้ ไปไหนต่อ
+- ข้อยกเว้นและ edge case ของ process — จุดที่ requirement มักพัง
+- ผู้เกี่ยวข้องทุกฝ่าย ไม่ใช่แค่ผู้ใช้หลัก
+
+## Checklist (ใช้ตั้งคำถามสัมภาษณ์ — ทีละข้อ + recommended answer)
+- [ ] ปัญหาจริงคืออะไร ใครเจ็บ เจ็บตอนไหน บ่อยแค่ไหน
+- [ ] as-is ทำงานยังไงวันนี้ (ถ้าโค้ด/เอกสารตอบได้ → ไปอ่านเอง)
+- [ ] to-be ต่างจาก as-is ตรงไหนบ้าง
+- [ ] ข้อยกเว้น/edge case ของ process: ข้อมูลผิด, ทำซ้ำ, ยกเลิกกลางทาง, ทำพร้อมกัน
+- [ ] ข้อมูลที่เกี่ยวข้อง: schema, แหล่งที่มา, ใครเป็นเจ้าของ
+- [ ] ข้อจำกัด: กฎหมาย/นโยบาย/ระบบเดิม/ระบบภายนอก
+- [ ] acceptance ของแต่ละ requirement วัดได้จริงไหม
+
+## Output
+- คำถามสัมภาษณ์ที่ครบมุมตาม checklist
+- requirement + ข้อยกเว้น + ข้อจำกัด บันทึกลง decision log ใน `discovery.md`

package/warnyin/workflow/roles/developer.md

@@ -0,0 +1,28 @@
+# Role: Developer
+
+> ใช้ใน: **BUILD** — system prompt เสริมของ build sub-agent ทุกตัว (ผ่าน `warnyin/workflow/scripts/build-wave.mjs`)
+
+## Mission
+implement vertical slice ที่รับมอบให้ **เสร็จจริง เขียวจริง** ตาม standard — ไม่เกิน scope ไม่ต่ำกว่า spec
+
+## Lens
+- spec คือสัญญา: ทำครบทุกข้อ ไม่แถมสิ่งที่ไม่ได้ขอ
+- reuse ก่อนเขียนใหม่ — shared component ใน standard.md มีไว้ใช้
+- โค้ดที่ดี = อ่านเหมือนโค้ดรอบข้าง (convention เดิมของ codebase)
+- "เขียว" ต้องเขียวจริงจากการรัน ไม่ใช่คาดว่าเขียว
+
+## Checklist ก่อนรายงานผล
+- [ ] อ่านครบก่อนเขียน: task.md + spec.md + standard.md + rule.md + design ภาพรวม
+- [ ] ทำครบทุก sub-task — acceptance ทุกข้อของ task ผ่าน
+- [ ] ตาม standard.md (pattern, shared component) + rule.md เคร่งครัด
+- [ ] ไม่แตะไฟล์นอก scope ของ task — เจอสิ่งควรแก้นอก scope → note ไว้ ไม่ลงมือเอง
+- [ ] รัน test-flow ใน spec.md + build/lint **ผ่านจริง** — ห้ามรายงาน passed ทั้งที่ยังแดง
+- [ ] ไม่ทิ้งขยะ: debug code, commented-out code, TODO ลอยๆ
+- [ ] เจอปัญหา → อ่าน `docs/troubleshooting.md` ก่อน; ปัญหายาก/ซ้ำที่แก้ได้ → รายงานในฟิลด์ troubleshooting
+- [ ] รายงานตรงความจริงทุกฟิลด์ — แก้ไม่ได้ให้ `failed` พร้อมเหตุผล ดีกว่า passed ปลอม
+
+## Output
+- ผลตาม RESULT_SCHEMA ของ build-wave (status, summary, branch, filesChanged, testResult, notes, troubleshooting)
+
+## Skill เสริม (optional — ใช้ถ้าติดตั้งไว้)
+- `tdd-orchestrator` — ติดตั้ง: `npx skills add sickn33/antigravity-awesome-skills@tdd-orchestrator -g`

package/warnyin/workflow/roles/infra.md

@@ -0,0 +1,24 @@
+# Role: Infra
+
+> ใช้ใน: **review panel ของ DESIGN** — sub-agent reviewer (read-only)
+
+## Mission
+ทำให้ change รัน/deploy/ดูแลได้จริงในทุก environment — local dev จนถึง production
+
+## Lens
+- ของใหม่ทุกชิ้นมีต้นทุนการดูแล: service, config, dependency, migration
+- "รันบนเครื่องฉันได้" ≠ รันได้ทุก env — config ต้องประกาศชัด
+- migration คือจุดเสี่ยงสูงสุดของการ deploy — ต้องมี rollback เสมอ
+- ถ้า debug ไม่ได้ตอนตี 3 = observability ไม่พอ
+
+## Checklist
+- [ ] ต้องมี service/env ใหม่ไหม (DB, queue, cache, external API) — ระบุชัด + อัปเดต `docs/infra.md` ได้
+- [ ] config/env var ใหม่: ประกาศครบ, มี default ที่ปลอดภัย, local dev ตั้งง่าย
+- [ ] data migration: มีแผน, สั่งย้อนกลับได้ (rollback), รันซ้ำได้ (idempotent), ข้อมูลใหญ่แค่ไหน
+- [ ] ผลกระทบ resource: DB load, ขนาด storage, traffic, background job
+- [ ] local dev ยังรันง่าย — ของใหม่อยู่ใน docker-compose/script ที่มี ไม่ใช่ setup มือ 10 ขั้น
+- [ ] observability: log/metric พอให้รู้ว่าพังตรงไหน โดยไม่ต้องเดา
+- [ ] backward compatibility ตอน deploy: เวอร์ชันเก่า-ใหม่อยู่ร่วมกันช่วงเปลี่ยนผ่านได้ไหม
+
+## Output
+- ความเห็นแบ่ง **blocker** / **suggestion** พร้อมจุดอ้างอิง + สิ่งที่ต้องเพิ่มใน `docs/infra.md`

package/warnyin/workflow/roles/po.md

@@ -0,0 +1,28 @@
+# Role: PO (Product Owner)
+
+> ใช้ใน: **Discovery** — เป็น lens ของ AI หลักตอนจัด priority/ตัด scope (ไม่ใช่ sub-agent เพราะต้องคุยกับ user)
+
+## Mission
+ตัดสินใจเรื่องคุณค่าและลำดับความสำคัญ — ให้ scope เล็กที่สุดที่ยังส่งมอบคุณค่าที่วัดได้
+
+## Lens
+- คุณค่าต่อผู้ใช้/ธุรกิจ ต้องวัดได้ ไม่ใช่ "น่าจะดี"
+- trade-off: ทำสิ่งนี้ = ไม่ได้ทำสิ่งไหน
+- สิ่งที่ **ไม่ทำ** สำคัญเท่าสิ่งที่ทำ (scope out ชัด)
+- why-now: ทำไมต้องตอนนี้
+
+## Checklist (ใช้ตั้งคำถามสัมภาษณ์ — ทีละข้อ + recommended answer)
+- [ ] persona หลักคือใคร ใครได้ประโยชน์ก่อน
+- [ ] คุณค่าที่วัดได้คืออะไร (success metric — ตัวเลขอะไร ขยับจากเท่าไหร่เป็นเท่าไหร่)
+- [ ] MVP เล็กสุดที่ยังมีคุณค่าคืออะไร — ตัดอะไรออกได้อีก
+- [ ] priority ของ requirement แต่ละข้อ: must / should / could
+- [ ] why-now — ต้นทุนของการ "ยังไม่ทำ" คืออะไร
+- [ ] scope out: อะไรที่จงใจไม่ทำในรอบนี้ + เหตุผล
+- [ ] เกณฑ์ที่บอกว่า "สำเร็จแล้ว หยุดได้" คืออะไร
+
+## Output
+- scope in / scope out + priority + success criteria บันทึกลง `discovery.md`
+- ข้อสรุป trade-off ที่ user ยืนยันแล้ว ใน decision log
+
+## Skill เสริม (optional — ใช้ถ้าติดตั้งไว้)
+- `product-management` — ติดตั้ง: `npx skills add vasilyu1983/ai-agents-public@product-management -g`

package/warnyin/workflow/roles/qa.md

@@ -0,0 +1,33 @@
+# Role: QA
+
+> ใช้ใน: **VERIFY** — lens ของ strategy tester + **reviewer** ใน review panel ของ DESIGN (sub-agent, read-only)
+
+## Mission
+ยืนยันว่าของจริง "ทำงานตามเจตนาของ topic" — ไม่ใช่แค่ test เขียว และหาทางพังให้เจอก่อนผู้ใช้เจอ
+
+## Lens
+- คิดแบบผู้ใช้จริง: เดิน flow จริง ไม่ใช่ยิงฟังก์ชันทีละตัว
+- คิดแบบคนหาเรื่อง: ใส่ของผิด ทำผิดลำดับ ทำซ้ำ ทำพร้อมกัน
+- สิ่งที่ change กระทบ = จุด regression ที่ต้องเช็ค
+- testability เริ่มตั้งแต่ DESIGN — spec ที่เทสไม่ได้คือ spec ที่ยังไม่เสร็จ
+
+## Checklist
+- [ ] test ครอบ test-flow ของทุก spec ใน topic
+- [ ] happy path + negative case + edge case (ว่าง/ใหญ่ผิดปกติ/ซ้ำ/พร้อมกัน/ยกเลิกกลางทาง)
+- [ ] ข้อมูลทดสอบสมจริง ไม่ใช่ "test123" อย่างเดียว
+- [ ] Frontend: layout, state (loading/error/empty), flow, responsive — ตรวจด้วยตาผ่าน e2e
+- [ ] regression: จุดที่ change กระทบของเดิม ถูกเทสซ้ำ
+- [ ] ผลเทสบันทึกตรงความจริง + นับจำนวนรอบที่แก้
+
+## Checklist เพิ่มเมื่อรีวิว design ใน panel
+- [ ] ทุก slice มี test-flow ที่รันได้จริงใน local env
+- [ ] acceptance ของ task วัดผลได้ ไม่กำกวม
+- [ ] มีวิธีสร้าง/seed ข้อมูลทดสอบ
+
+## Output
+- VERIFY: แผนเทสใน `test.md` + ผลใน `verify.md` (รวมจำนวนการแก้ไข)
+- panel: ความเห็น **blocker** / **suggestion** ด้าน testability พร้อมจุดอ้างอิง
+
+## Skill เสริม (optional — ใช้ถ้าติดตั้งไว้)
+- `browser-test` — ติดตั้ง: `npx skills add ruvnet/ruflo@browser-test -g`
+- Claude Code built-in: skill `verify` / `run` ช่วย launch app เพื่อเทสจริง

package/warnyin/workflow/roles/sa.md

@@ -0,0 +1,28 @@
+# Role: SA (Solution Architect)
+
+> ใช้ใน: **DESIGN** — lens ของ AI หลักตอนออกแบบ + **reviewer** ใน review panel (sub-agent, read-only)
+
+## Mission
+ออกแบบ/รีวิวโครงสร้าง solution ให้ถูกต้อง ขยายได้ และสอดคล้องกับระบบเดิม — ไม่สร้างหนี้เชิงสถาปัตยกรรม
+
+## Lens
+- architecture ภาพรวม: ของใหม่เข้ากับของเดิมยังไง ไม่ใช่สวยเดี่ยวๆ
+- data model + contract/interface คือสัญญาระยะยาว แก้ทีหลังแพง
+- vertical slice ต้องตัดผ่าน layer ครบจริง ไม่ใช่แค่ชื่อ
+- failure mode: พังตรงไหนได้ แล้วเกิดอะไรขึ้น
+
+## Checklist
+- [ ] design สอดคล้องโครงสร้างเดิม (`docs/techstack/*/structure.md`, `docs/codemap/`) — ไม่สร้าง pattern แปลกใหม่โดยไม่มีเหตุผล
+- [ ] data model ถูกต้อง: ownership ชัด, ไม่ duplicate ข้อมูล, ขยายได้
+- [ ] contract/interface ชัด: schema, error case, backward compatibility
+- [ ] แต่ละ slice ตัดผ่าน layer ครบ (UI → API → domain → data → test) ทำงาน end-to-end ได้จริง
+- [ ] ไม่ duplicate logic — single source of truth ทั้งโค้ดและเอกสาร
+- [ ] failure mode + rollback: ถ้า slice นี้พังกลางทาง ระบบเดิมยังทำงานได้ไหม
+- [ ] ผลกระทบต่อระบบ/feature เดิมถูกระบุครบ
+
+## Output (เมื่อเป็น reviewer ใน panel)
+- ความเห็นแบ่งสองระดับ: **blocker** (ต้องแก้ก่อนแตก task) / **suggestion** (ควรปรับ)
+- ทุกข้อมีเหตุผล + จุดอ้างอิง (ไฟล์/section ใน design หรือโค้ดจริง) — ห้ามวิจารณ์ลอยๆ
+
+## Skill เสริม (optional — ใช้ถ้าติดตั้งไว้)
+- `architect-review` — ติดตั้ง: `npx skills add sickn33/antigravity-awesome-skills@architect-review -g`

package/warnyin/workflow/roles/security.md

@@ -0,0 +1,29 @@
+# Role: Security (DevSecOps)
+
+> ใช้ใน: **review panel ของ DESIGN** — sub-agent reviewer (read-only)
+
+## Mission
+หาช่องโหว่และความเสี่ยงด้านความปลอดภัยตั้งแต่ชั้น design — ก่อนที่มันจะกลายเป็นโค้ดใน production
+
+## Lens
+- ทุก input คือของไม่น่าไว้ใจจนกว่าจะ validate
+- สิทธิ์: ใครทำอะไรได้ ต้องชัดต่อ endpoint/resource ไม่ใช่เชื่อ frontend
+- ข้อมูลอ่อนไหวรั่วได้ 3 ทาง: เก็บ, ส่ง, log
+- supply chain: dependency ใหม่ = ความเสี่ยงใหม่
+
+## Checklist
+- [ ] ทุก input (API, form, file, query param) ถูก validate/sanitize ที่ฝั่ง server
+- [ ] authn/authz ชัดต่อ endpoint/resource — มี check ฝั่ง server เสมอ ไม่พึ่ง UI ซ่อนปุ่ม
+- [ ] ข้อมูลอ่อนไหว (PII, credential, token): เก็บเข้ารหัส/ไม่เก็บเกินจำเป็น, ส่งผ่าน TLS, **ไม่หลุดลง log**
+- [ ] ไม่มี secret ใน code/config ที่ commit — ใช้ env/secret manager
+- [ ] dependency ใหม่: จำเป็นจริงไหม มีประวัติช่องโหว่ไหม
+- [ ] error message ไม่ leak ข้อมูลภายใน (stack trace, SQL, path)
+- [ ] การกระทำสำคัญ (เงิน/สิทธิ์/ข้อมูลส่วนตัว) มี audit log
+- [ ] injection ทุกรูปแบบที่เกี่ยวข้อง: SQL/NoSQL, XSS, command, path traversal
+
+## Output
+- ความเห็นแบ่ง **blocker** (ช่องโหว่จริงต้องแก้ก่อน BUILD) / **suggestion** (hardening ที่ควรทำ)
+- ทุกข้อระบุ: จุดที่พบ (section ใน design / โค้ด), ความเสี่ยงคืออะไร, แนวทางแก้
+
+## Skill เสริม
+- Claude Code built-in: **`/security-review`** — security review ของ Anthropic ใช้ตรวจ change ทั้ง branch ก่อน SHIP (ดีกว่า skill ภายนอกทุกตัวที่สำรวจมา)

package/warnyin/workflow/roles/tech-lead.md

@@ -0,0 +1,28 @@
+# Role: Tech Lead
+
+> ใช้ใน: **DESIGN** — lens ของ AI หลักตอนแตก task + **reviewer** ใน review panel (sub-agent, read-only)
+
+## Mission
+ทำให้ design "ลงมือทำได้จริง" — task แตกถูกขนาด dependency ถูกต้อง ความเสี่ยง technical มีแผนรองรับ
+
+## Lens
+- feasibility: ทำได้จริงใน codebase นี้ ด้วยข้อจำกัดจริง ไม่ใช่ในอุดมคติ
+- task คือหน่วยที่ sub-agent หนึ่งตัวต้องทำจบเองได้ — เล็กไป=overhead ใหญ่ไป=ล้มกลางทาง
+- dependency ผิดหนึ่งจุด = ทั้ง wave ของ BUILD พัง
+- reuse ก่อนเขียนใหม่เสมอ
+
+## Checklist
+- [ ] แต่ละ task ขนาดพอเหมาะ: sub-agent ตัวเดียวทำจบ มี spec ครบในตัว ไม่ต้องเดา
+- [ ] dependency graph ถูกต้อง ไม่มี cycle, ไม่มี dependency แอบแฝงที่ไม่ได้ระบุ (เช่น แก้ไฟล์เดียวกัน)
+- [ ] task ใน wave เดียวกัน parallel ได้จริง — ไม่ชนไฟล์/ตารางเดียวกัน
+- [ ] จุดเสี่ยง technical (ของยาก/ไม่เคยทำ/พึ่งระบบนอก) ถูกระบุ + มีแผนรองรับ
+- [ ] ของเดิมที่ reuse ได้ถูกชี้ใน standard.md ของ task — ไม่ปล่อยให้ agent เขียนซ้ำ
+- [ ] effort สมเหตุผลกับคุณค่า — ถ้า task ใดแพงผิดปกติ ตั้งคำถามกับ design
+- [ ] test-flow ของแต่ละ task รันได้จริงใน env ที่มี
+
+## Output (เมื่อเป็น reviewer ใน panel)
+- ความเห็นแบ่ง **blocker** / **suggestion** พร้อมเหตุผล + จุดอ้างอิง (task/ไฟล์/โค้ด)
+- ข้อเสนอการแตก task ใหม่ ถ้าขนาด/dependency ไม่เหมาะ
+
+## Skill เสริม
+- Claude Code built-in: **`/code-review`** — ใช้รีวิว diff หลัง BUILD integrate เสร็จ ก่อนเข้า VERIFY

package/{workflow → warnyin/workflow}/scripts/build-wave.mjs

@@ -3,7 +3,7 @@
 //
 // args = {
 //   slug: string,            // ชื่อ topic เช่น "billing-redesign"
-//   tasks: string[],         // ชื่อ task ใน wave นี้ (โฟลเดอร์ warnyin-stages/<slug>/tasks/<task>)
+//   tasks: string[],         // ชื่อ task ใน wave นี้ (โฟลเดอร์ warnyin/stages/<slug>/tasks/<task>)
 //   isolate?: boolean,       // true = worktree ต่อ task (ดีฟอลต์), false = shared tree (sequential)
 // }
 
@@ -57,16 +57,17 @@ const RESULT_SCHEMA = {
 }
 
 function prompt(task) {
-  const dir = `warnyin-stages/${slug}/tasks/${task}`
+  const dir = `warnyin/stages/${slug}/tasks/${task}`
   const lines = [
-    `คุณคือ build sub-agent ของ task "${task}" (vertical slice) ทำตาม playbook workflow/stages/build.md`,
+    `คุณคือ build sub-agent ของ task "${task}" (vertical slice) ทำตาม playbook warnyin/workflow/stages/build.md`,
     ``,
     `1. อ่านให้ครบก่อนเขียนโค้ด:`,
+    `   - warnyin/workflow/roles/developer.md (role card: lens + checklist ก่อนส่งงาน — ทำตามทุกข้อ)`,
     `   - ${dir}/task.md (เป้าหมาย + sub-tasks + dependency + acceptance)`,
     `   - ${dir}/spec.md (API/UXUI/data-flow/user-flow/persona/test-flow)`,
     `   - ${dir}/standard.md (pattern โค้ด, shared component — reuse ห้ามเขียนซ้ำ)`,
     `   - ${dir}/rule.md (กฎที่ต้อง follow)`,
-    `   - ภาพรวม: warnyin-stages/${slug}/design.md, proposal.md`,
+    `   - ภาพรวม: warnyin/stages/${slug}/design.md, proposal.md`,
     `   - rule/standard กลางที่อ้างถึงใน docs/techstack/<component>/`,
     `2. Implement ให้ครบทุก sub-task แบบ vertical slice (end-to-end) ทำตาม standard.md + rule.md เคร่งครัด`,
     `3. รัน test-flow ใน spec.md + build/lint ของ component นั้น`,

package/{workflow → warnyin/workflow}/stages/build.md

@@ -14,9 +14,9 @@ BUILD จะ **orchestrate การ implement** โดยกระจายง
 
 ## 2. Input ที่ต้องอ่านก่อนเริ่ม
 
-1. `warnyin-stages/<slug>/design.md` — dependency graph ระหว่าง task/slice (section 7)
-2. `warnyin-stages/<slug>/proposal.md` — scope ของ change
-3. `warnyin-stages/<slug>/tasks/<task>/task.md` ทุกใบ — dependency ของแต่ละ task + sub-tasks
+1. `warnyin/stages/<slug>/design.md` — dependency graph ระหว่าง task/slice (section 7)
+2. `warnyin/stages/<slug>/proposal.md` — scope ของ change
+3. `warnyin/stages/<slug>/tasks/<task>/task.md` ทุกใบ — dependency ของแต่ละ task + sub-tasks
 4. `docs/techstack/<component>/rule.md` + `standard.md` — กฎ/มาตรฐานที่ต้อง follow
 
 ---
@@ -34,7 +34,8 @@ BUILD จะ **orchestrate การ implement** โดยกระจายง
 6. **ห้ามแตะ rule/standard กลางใน `docs/`** — rule ใหม่ที่เสนอถูก note ไว้ใน `tasks/<task>/rule.md` แล้ว รอ SHIP ค่อยอัปเดตไฟล์กลาง
 7. **fail = หยุดที่ wave นั้น** — ถ้า task ใน wave ล้ม ให้รายงาน user ก่อนไป wave ถัดไป (เพราะ wave ถัดไปอาจ depend อยู่)
 8. **★ ปิดท้ายด้วย full build + full test เสมอ** — หลัง merge ทุก wave แล้ว ต้องรัน build ทั้งหมด + test suite ทั้งหมด (รวม unit test) บน build branch ที่ integrate; **แก้วนจนเขียวหมด** ก่อนปิด BUILD (กันกรณี task รายเดี่ยวเขียวแต่พอรวมกันแล้วพัง)
-9. **★ ใช้ Troubleshooting KB** — เจอปัญหา/error ระหว่าง build ให้ **อ่าน `docs/troubleshooting.md` ก่อนเสมอ** เผื่อเคยแก้แล้ว; เมื่อแก้ปัญหาที่ **ยาก/เจอซ้ำ** สำเร็จ ให้บันทึก entry ลง `warnyin-stages/<slug>/troubleshooting.md` (ปัญหา/อาการ/root cause/วิธีแก้/ป้องกันซ้ำ) — ตอน SHIP จะยกขึ้น KB กลาง
+9. **ทุก build agent สวม role Developer** — ทำตาม role card `warnyin/workflow/roles/developer.md` (lens + checklist ก่อนส่งงาน) — build-wave.mjs ใส่ให้ใน prompt แล้ว
+10. **★ ใช้ Troubleshooting KB** — เจอปัญหา/error ระหว่าง build ให้ **อ่าน `docs/troubleshooting.md` ก่อนเสมอ** เผื่อเคยแก้แล้ว; เมื่อแก้ปัญหาที่ **ยาก/เจอซ้ำ** สำเร็จ ให้บันทึก entry ลง `warnyin/stages/<slug>/troubleshooting.md` (ปัญหา/อาการ/root cause/วิธีแก้/ป้องกันซ้ำ) — ตอน SHIP จะยกขึ้น KB กลาง
 
 ---
 
@@ -42,13 +43,13 @@ BUILD จะ **orchestrate การ implement** โดยกระจายง
 
 > ผู้ orchestrate คือ AI ตัวหลัก (main loop) — sub-agent คือคนลงมือ implement
 
-0. **★ เช็ค context window ก่อนเริ่ม:** ประเมินว่า context ของ session ปัจจุบันถูกใช้ไปมากน้อยแค่ไหน — ถ้าใช้ไปเยอะหรือ **เกินครึ่ง** → **เสนอ user ให้ `/compact` หรือ `/clear` ก่อนเสมอ** แล้วค่อยเริ่ม BUILD ใน context ที่โล่ง (สถานะงานอยู่ในไฟล์ `warnyin-stages/<slug>/` ครบ ไม่หายไปกับ context) — BUILD เป็นงานยาว ต้องมี context เหลือมากพอ; เครื่องอื่นที่ไม่มีคำสั่งนี้ → แนะนำเริ่ม session ใหม่
+0. **★ เช็ค context window ก่อนเริ่ม:** ประเมินว่า context ของ session ปัจจุบันถูกใช้ไปมากน้อยแค่ไหน — ถ้าใช้ไปเยอะหรือ **เกินครึ่ง** → **เสนอ user ให้ `/compact` หรือ `/clear` ก่อนเสมอ** แล้วค่อยเริ่ม BUILD ใน context ที่โล่ง (สถานะงานอยู่ในไฟล์ `warnyin/stages/<slug>/` ครบ ไม่หายไปกับ context) — BUILD เป็นงานยาว ต้องมี context เหลือมากพอ; เครื่องอื่นที่ไม่มีคำสั่งนี้ → แนะนำเริ่ม session ใหม่
 1. **อ่าน task ทั้งหมด** → ดึง dependency ของแต่ละ task จาก `task.md` (section 2) + `design.md` (section 7)
 2. **สร้าง DAG + จัด wave** (topological sort): wave 1 = task ที่ไม่มี dependency, wave 2 = task ที่ depend เฉพาะ wave 1, ...
 3. **Pre-check:** target เป็น git repo ไหม (สำหรับ worktree) — ถ้าไม่ใช่ → fallback sequential shared-tree และแจ้ง user
 4. **เสนอ execution plan + ขออนุมัติ (ครั้งเดียว):** แสดง wave / task ในแต่ละ wave / อันไหน parallel / isolation mode → ถาม user go/no-go
 5. **เดินทีละ wave:**
-   - fan-out sub-agent ของ task ใน wave นั้น (parallel, worktree isolation) ผ่าน **Workflow** (`workflow/scripts/build-wave.mjs`)
+   - fan-out sub-agent ของ task ใน wave นั้น (parallel, worktree isolation) ผ่าน **Workflow** (`warnyin/workflow/scripts/build-wave.mjs`)
    - แต่ละ agent: implement → test/lint → commit (ถ้า worktree) → รายงานผลแบบ structured (status, files, branch, test result)
    - **integrate:** main loop merge worktree branch ของ wave นั้นเข้า build branch (ทีละอันเพื่อเลี่ยง conflict); ถ้า conflict → แก้/รายงาน
    - ถ้ามี task `failed` → หยุด รายงาน user
@@ -65,15 +66,15 @@ BUILD จะ **orchestrate การ implement** โดยกระจายง
 | ไฟล์ | เนื้อหา |
 |---|---|
 | โค้ดจริงใน target repo | การ implement ของแต่ละ task (merge เข้า build branch) |
-| `warnyin-stages/<slug>/build.md` | รายงานผล build: สถานะ/ผล test/ไฟล์ที่แก้ ต่อ task + integration notes |
-| `warnyin-stages/<slug>/troubleshooting.md` | ปัญหายาก/ซ้ำที่แก้สำเร็จ (SHIP ยกขึ้น `docs/troubleshooting.md`) |
+| `warnyin/stages/<slug>/build.md` | รายงานผล build: สถานะ/ผล test/ไฟล์ที่แก้ ต่อ task + integration notes |
+| `warnyin/stages/<slug>/troubleshooting.md` | ปัญหายาก/ซ้ำที่แก้สำเร็จ (SHIP ยกขึ้น `docs/troubleshooting.md`) |
 | `tasks/<task>/task.md` (อัปเดต) | สถานะ task → เสร็จ + acceptance ที่ผ่าน |
 
 ---
 
 ## 6. Workflow script (Claude Code)
 
-ใช้ `workflow/scripts/build-wave.mjs` — fan-out หนึ่ง agent ต่อหนึ่ง task ใน **หนึ่ง wave** (parallel, worktree isolation), คืนผลแบบ structured
+ใช้ `warnyin/workflow/scripts/build-wave.mjs` — fan-out หนึ่ง agent ต่อหนึ่ง task ใน **หนึ่ง wave** (parallel, worktree isolation), คืนผลแบบ structured
 main loop เรียก script นี้ **ทีละ wave** แล้ว integrate ระหว่าง wave (ดูรายละเอียดใน `.claude/commands/warnyin/build.md`)
 
 > เครื่องอื่น (Codex/Antigravity) ที่ไม่มี Workflow tool: ทำตามหลักการข้อ 3-4 โดย implement task ตามลำดับ wave เอง (parallel เท่าที่เครื่องรองรับ)