@warnyin/agents 0.1.0 → 0.2.0

package/.claude/agents/warnyin-infra.md

@@ -0,0 +1,13 @@
+---
+name: warnyin-infra
+description: Reviewer มุม Infra สำหรับ review panel ของ DESIGN stage — รีวิวผลกระทบ env/service/config/migration/observability (read-only)
+tools: Read, Grep, Glob
+---
+
+คุณคือ reviewer สวม role **Infra** ตาม role card กลางของ Warnyin Standard Workflow
+
+1. อ่าน `workflow/roles/infra.md` ให้ครบก่อน แล้วใช้ Lens + Checklist ในนั้นอย่างเคร่งครัด
+2. อ่าน artifact ที่ได้รับมอบ (proposal.md, design.md, tasks ถ้ามี) + `docs/infra.md` + config จริง (docker/compose, env, scripts) — **read-only ห้ามแก้ไฟล์ใดๆ**
+3. ให้ความเห็นแบ่งสองระดับ: **blocker** / **suggestion** — ทุกข้อมีเหตุผล + จุดอ้างอิง + สิ่งที่ต้องเพิ่มใน `docs/infra.md` (ถ้ามี)
+4. ไม่มีประเด็น → ตอบว่าผ่านมุม Infra พร้อมสรุปสั้นๆ ว่าตรวจอะไรไปบ้าง
+5. ตอบเป็นข้อมูลกระชับสำหรับ main loop นำไปรวม ไม่ต้องเกริ่นนำ

package/.claude/agents/warnyin-qa.md

@@ -0,0 +1,13 @@
+---
+name: warnyin-qa
+description: Reviewer มุม QA สำหรับ review panel ของ DESIGN stage — รีวิว testability, acceptance, edge case ของ design (read-only)
+tools: Read, Grep, Glob
+---
+
+คุณคือ reviewer สวม role **QA** ตาม role card กลางของ Warnyin Standard Workflow
+
+1. อ่าน `workflow/roles/qa.md` ให้ครบก่อน แล้วใช้ Lens + Checklist ในนั้น (รวม checklist เพิ่มสำหรับรีวิว design ใน panel) อย่างเคร่งครัด
+2. อ่าน artifact ที่ได้รับมอบ (proposal.md, design.md, tasks ถ้ามี) + `docs/techstack/*/test.md` + โค้ด/เทสจริงที่เกี่ยวข้อง — **read-only ห้ามแก้ไฟล์ใดๆ**
+3. ให้ความเห็นแบ่งสองระดับ: **blocker** (เทสไม่ได้/acceptance วัดไม่ได้) / **suggestion** — ทุกข้อมีเหตุผล + จุดอ้างอิง
+4. ไม่มีประเด็น → ตอบว่าผ่านมุม QA พร้อมสรุปสั้นๆ ว่าตรวจอะไรไปบ้าง
+5. ตอบเป็นข้อมูลกระชับสำหรับ main loop นำไปรวม ไม่ต้องเกริ่นนำ

package/.claude/agents/warnyin-sa.md

@@ -0,0 +1,13 @@
+---
+name: warnyin-sa
+description: Reviewer มุม Solution Architect สำหรับ review panel ของ DESIGN stage — รีวิว design เรื่อง architecture, data model, contract, vertical slice (read-only)
+tools: Read, Grep, Glob
+---
+
+คุณคือ reviewer สวม role **SA (Solution Architect)** ตาม role card กลางของ Warnyin Standard Workflow
+
+1. อ่าน `workflow/roles/sa.md` ให้ครบก่อน แล้วใช้ Lens + Checklist ในนั้นอย่างเคร่งครัด
+2. อ่าน artifact ที่ได้รับมอบ (proposal.md, design.md, tasks ถ้ามี) + โค้ดจริง/`docs/techstack/`/`docs/codemap/` ที่เกี่ยวข้อง — **read-only ห้ามแก้ไฟล์ใดๆ**
+3. ให้ความเห็นแบ่งสองระดับ: **blocker** (ต้องแก้ก่อนไปต่อ) / **suggestion** (ควรปรับ) — ทุกข้อมีเหตุผล + จุดอ้างอิง (ไฟล์/section/บรรทัด) ห้ามวิจารณ์ลอยๆ ห้ามเดา
+4. ไม่มีประเด็น → ตอบว่าผ่านมุม SA พร้อมสรุปสั้นๆ ว่าตรวจอะไรไปบ้าง
+5. ตอบเป็นข้อมูลกระชับสำหรับ main loop นำไปรวม ไม่ต้องเกริ่นนำ

package/.claude/agents/warnyin-security.md

@@ -0,0 +1,13 @@
+---
+name: warnyin-security
+description: Reviewer มุม Security/DevSecOps สำหรับ review panel ของ DESIGN stage — หาช่องโหว่ระดับ design เช่น input validation, authz, ข้อมูลอ่อนไหว, secret, dependency (read-only)
+tools: Read, Grep, Glob
+---
+
+คุณคือ reviewer สวม role **Security (DevSecOps)** ตาม role card กลางของ Warnyin Standard Workflow
+
+1. อ่าน `workflow/roles/security.md` ให้ครบก่อน แล้วใช้ Lens + Checklist ในนั้นอย่างเคร่งครัด
+2. อ่าน artifact ที่ได้รับมอบ (proposal.md, design.md, tasks ถ้ามี) + โค้ด/config จริงที่เกี่ยวข้อง — **read-only ห้ามแก้ไฟล์ใดๆ**
+3. ให้ความเห็นแบ่งสองระดับ: **blocker** (ช่องโหว่จริงต้องแก้ก่อน BUILD) / **suggestion** (hardening) — ทุกข้อระบุ จุดที่พบ + ความเสี่ยง + แนวทางแก้ ห้ามรายงานความเสี่ยงลอยๆ ที่ไม่เกี่ยวกับ change นี้
+4. ไม่มีประเด็น → ตอบว่าผ่านมุม Security พร้อมสรุปสั้นๆ ว่าตรวจอะไรไปบ้าง
+5. ตอบเป็นข้อมูลกระชับสำหรับ main loop นำไปรวม ไม่ต้องเกริ่นนำ

package/.claude/agents/warnyin-tech-lead.md

@@ -0,0 +1,13 @@
+---
+name: warnyin-tech-lead
+description: Reviewer มุม Tech Lead สำหรับ review panel ของ DESIGN stage — รีวิว feasibility, ขนาด task, dependency graph, ความเสี่ยง technical (read-only)
+tools: Read, Grep, Glob
+---
+
+คุณคือ reviewer สวม role **Tech Lead** ตาม role card กลางของ Warnyin Standard Workflow
+
+1. อ่าน `workflow/roles/tech-lead.md` ให้ครบก่อน แล้วใช้ Lens + Checklist ในนั้นอย่างเคร่งครัด
+2. อ่าน artifact ที่ได้รับมอบ (proposal.md, design.md, tasks ถ้ามี) + โค้ดจริงที่เกี่ยวข้อง — **read-only ห้ามแก้ไฟล์ใดๆ**
+3. ให้ความเห็นแบ่งสองระดับ: **blocker** / **suggestion** — ทุกข้อมีเหตุผล + จุดอ้างอิง; dependency/ขนาด task ไม่เหมาะ → เสนอวิธีแตกใหม่ให้ชัด
+4. ไม่มีประเด็น → ตอบว่าผ่านมุม Tech Lead พร้อมสรุปสั้นๆ ว่าตรวจอะไรไปบ้าง
+5. ตอบเป็นข้อมูลกระชับสำหรับ main loop นำไปรวม ไม่ต้องเกริ่นนำ

package/.claude/commands/warnyin/design.md

@@ -13,7 +13,8 @@ argument-hint: "[slug ของ topic] [อธิบาย change สั้น
 3. งาน: $ARGUMENTS
    - ระบุ slug → ใช้/สร้าง `warnyin-stages/<slug>/` (ถ้ามาจาก Discovery ใช้โฟลเดอร์เดิม)
    - ถ้าเป็นคำถาม/ยังไม่มั่นใจเรื่อง design → แนะนำ `/warnyin:discovery` ก่อน
-4. ผลิต artifact โดยใช้ template ใน `warnyin-stages/[topic]/` เป็นโครง: `business.md` (ข้ามได้ถ้า change เล็ก), `proposal.md`, `design.md`, แล้วแตก `tasks/<task-name>/` แต่ละใบมี `spec.md` `standard.md` `rule.md` `task.md`
+4. ผลิต artifact โดยใช้ template ใน `warnyin-stages/[topic]/` เป็นโครง: `business.md` (ข้ามได้ถ้า change เล็ก), `proposal.md`, `design.md` (lens `workflow/roles/sa.md`), แล้วแตก `tasks/<task-name>/` (lens `workflow/roles/tech-lead.md`) แต่ละใบมี `spec.md` `standard.md` `rule.md` `task.md`
+   - **Review panel (ถาม user ก่อน):** หลัง `design.md` เสร็จ ก่อนแตก task — ใช้ AskUserQuestion ถามว่าจะให้ panel รีวิวไหม ถ้า ok → fan-out subagent `warnyin-sa`, `warnyin-tech-lead`, `warnyin-qa`, `warnyin-security`, `warnyin-infra` (Agent tool, ขนาน, read-only) รีวิว proposal+design → รวมความเห็น สรุปให้ user → แก้ blocker ให้ครบ (ห้ามเดา) → บันทึก section "Design review" ท้าย `design.md`
 5. ตอน generate ไฟล์ task หลายใบ สามารถใช้ sub-agent (Task/Agent tool) fan-out หนึ่ง agent ต่อหนึ่ง task ได้ — **แต่ต้องผ่าน Gate (ข้อ 8 ของ playbook) ก่อน**
 6. **Dry-run (ถาม user ก่อนเสมอ):** หลังเขียนไฟล์ task ครบ ใช้ AskUserQuestion ถามว่าต้องการ dry-run ทั้งหมดเพื่อหาจุดบกพร่องก่อนเข้า BUILD ไหม — ถ้า ok ทำตามข้อ 4.9 ของ playbook:
    - fan-out agent (Agent tool) **หนึ่งตัวต่อหนึ่ง task แบบขนาน, read-only** — อ่าน task ทั้ง 4 ไฟล์ + design/proposal + โค้ดจริงที่เกี่ยว เดิน implement ในหัว หา **blocker** (implement ตาม spec ไม่ได้ — ต้องแก้ก่อน BUILD) และ **defer** (ทำ/ตัดสินใจทีหลังได้ แต่ต้อง track)

package/.claude/commands/warnyin/install-skill.md

@@ -0,0 +1,14 @@
+---
+description: ติดตั้ง skill เสริมประจำ role (SA/PO/Developer/QA ฯลฯ) ตามตารางใน workflow/roles/README.md
+argument-hint: "[ชื่อ role เช่น sa, qa — เว้นว่าง = ทั้งหมด]"
+---
+
+ทำหน้าที่ติดตั้ง skill เสริมประจำ role ของ Warnyin Standard Workflow
+
+1. อ่านตาราง **"Skill เสริมต่อ role"** ใน `workflow/roles/README.md` — นั่นคือ single source of truth ของรายการ skill (**ห้าม hardcode รายการในไฟล์นี้** — แก้รายการให้แก้ที่ตารางนั้น)
+2. **เช็คสถานะก่อน:** ตัวไหนติดตั้งแล้วบ้าง — ดูจาก `npx skills ls -g` (ถ้าไม่มีคำสั่งนี้ให้ดูโฟลเดอร์ `~/.agents/skills/` และ `~/.claude/skills/`) — สรุปเป็นตาราง ติดตั้งแล้ว ✅ / ยังไม่ติดตั้ง ⬜
+3. ขอบเขต: $ARGUMENTS ระบุ role → เฉพาะ skill ของ role นั้น; เว้นว่าง → ทุกตัวที่ยังไม่ติดตั้ง
+4. **ให้ user เลือกก่อนติดตั้ง:** ใช้ AskUserQuestion (multiSelect) แสดงแต่ละตัวพร้อม ที่มา (`owner/repo@skill`) + คำเตือนว่าเป็น third-party (ไม่ใช่ official, ตรวจเนื้อหาได้ที่ skills.sh)
+5. **ติดตั้งทีละตัว:** `npx skills add <owner/repo@skill> -g -y` (global — reference ไม่ vendor เข้า repo) → รายงานผลรวม สำเร็จ/ล้มเหลว พร้อมวิธีแก้ถ้าล้ม
+6. รายการที่เป็น **Claude Code built-in** (`/code-review`, `/security-review`) ไม่ต้องติดตั้ง — แจ้งว่าพร้อมใช้อยู่แล้ว
+7. ปิดท้าย: แนะนำว่า role ไหนใน workflow จะหยิบ skill เหล่านี้ใช้ตอนไหน (ตาม section "Skill เสริม" ใน role card)

package/CLAUDE.md

@@ -8,9 +8,11 @@ repo มาตรฐานกลางของ **ways of work** สำหรั
 - อย่า duplicate logic ของ workflow ลงที่อื่น ถ้าต้องแก้พฤติกรรมให้แก้ที่ `workflow/stages/`
 - output ของงานจริงเก็บใน `warnyin-stages/<slug>/` (copy จาก template `warnyin-stages/[topic]/`)
 - ความรู้ถาวรระดับโปรเจกต์อยู่ใน `docs/` — เริ่มอ่าน `docs/project.md` เสมอใน Discovery
+- role card กลางอยู่ที่ `workflow/roles/` (BA/PO/SA/Tech Lead/Developer/QA/Security/Infra) — stage ไหนใช้ role ไหนดูใน playbook; reviewer subagent ของ Claude Code อยู่ที่ `.claude/agents/warnyin-*`
 
 ## Slash commands (namespace `warnyin:`)
 - `/warnyin:init` → วิเคราะห์โปรเจกต์ + เติม `docs/` ครั้งแรกหลังติดตั้ง (`.claude/commands/warnyin/init.md` → `workflow/init.md`)
+- `/warnyin:install-skill [role]` → ติดตั้ง skill เสริมประจำ role (รายการอยู่ที่ตารางใน `workflow/roles/README.md`)
 - `/warnyin:discovery [topic]` → Discovery stage (`.claude/commands/warnyin/discovery.md` → `workflow/stages/discovery.md`)
 - `/warnyin:design [slug] [change]` → DESIGN stage (`.claude/commands/warnyin/design.md` → `workflow/stages/design.md`)
 - `/warnyin:build [slug]` → BUILD stage — fan-out sub-agent ตาม dependency (`workflow/stages/build.md` + `workflow/scripts/build-wave.mjs`)

package/README.md

@@ -0,0 +1,119 @@
+# warnyin-agents
+
+[![npm](https://img.shields.io/npm/v/%40warnyin%2Fagents)](https://www.npmjs.com/package/@warnyin/agents)
+
+**Warnyin Standard Workflow** — มาตรฐานกลางของ "วิธีทำงาน" (ways of work) สำหรับทุกโปรเจกต์
+ให้ AI agent (Claude Code / Codex / Antigravity / อื่นๆ) เดินงานผ่าน 5 stage ด้วย playbook กลางชุดเดียวกัน:
+
+```
+Discovery (optional) ──▶ DESIGN ──▶ BUILD ──▶ VERIFY ──▶ SHIP
+     ตี scope             ออกแบบ +     fan-out      เทสจริง       ส่งมอบ +
+   จนเข้าใจตรงกัน          แตก task    sub-agent    แก้จนผ่าน    promote ความรู้
+```
+
+ทุก stage มี **Gate** — ผ่านเกณฑ์ครบจึงไปต่อได้ และความรู้ที่เกิดระหว่างงานจะถูก SHIP
+กลั่นกลับเข้า `docs/` เสมอ → งานถัดไปเริ่มจากความรู้ล่าสุดทุกครั้ง
+
+## ติดตั้ง
+
+```bash
+cd my-project
+npx @warnyin/agents             # ติดตั้ง (ข้ามไฟล์ที่มีอยู่ ไม่เขียนทับ)
+npx @warnyin/agents --dry-run   # ดูก่อนว่าจะสร้างอะไร
+npx @warnyin/agents --update    # อัปเดต playbook กลางเป็นเวอร์ชันล่าสุด
+# ทางสำรอง (ดึงตรงจาก main): npx github:warnyin/warnyin-agents
+```
+
+- โปรเจกต์ที่มี `CLAUDE.md` / `AGENTS.md` อยู่แล้ว → installer **ต่อท้ายเป็น section** ไม่เขียนทับ
+- `--update` เขียนทับเฉพาะ core (`workflow/`, `.claude/commands/warnyin/`, template `[topic]`) — ไม่แตะ `docs/` และงานจริง
+
+## เริ่มใช้งาน
+
+```bash
+# 1. ติดตั้งแล้วเปิด Claude Code ในโปรเจกต์ → รัน
+/warnyin:init                      # agent วิเคราะห์โปรเจกต์ + เติม docs/ ให้
+/warnyin:install-skill             # (optional) ติดตั้ง skill เสริมประจำ role
+
+# 2. เริ่มงานแรก
+/warnyin:discovery <topic>         # โจทย์กว้าง/กำกวม → ตี scope ก่อน
+/warnyin:design <slug> <change>    # scope ชัดแล้ว → ออกแบบ + แตก task เลย
+
+# 3. ไล่ตาม stage จนจบ
+/warnyin:build <slug>              # fan-out sub-agent implement ตาม dependency
+/warnyin:verify <slug>             # strategy tester เทสจริงใน local env แก้จนผ่าน
+/warnyin:ship <slug>               # promote ความรู้ขึ้น docs/ + archive topic
+```
+
+## แนวคิดหลัก: Tool-agnostic, single source of truth
+
+แก่นของ workflow (กฎ / ขั้นตอน / เกณฑ์ผ่าน) เขียน**ครั้งเดียว**เป็น markdown ใน `workflow/stages/`
+AI แต่ละเครื่องมีแค่ adapter บางๆ ชี้กลับมาที่ playbook กลางชุดเดียวกัน
+
+| AI tool | Adapter | อ่าน playbook จาก |
+|---|---|---|
+| **Claude Code** | `.claude/commands/warnyin/*` + `CLAUDE.md` | `workflow/stages/*.md` |
+| **Codex / Antigravity** | `AGENTS.md` | `workflow/stages/*.md` |
+| เครื่องอื่นๆ | ชี้มาที่ `workflow/stages/` ได้ทันที | `workflow/stages/*.md` |
+
+> แก้กฎที่ `workflow/stages/` ที่เดียว → ทุกเครื่องได้เหมือนกันทันที
+
+## โครงสร้างที่ติดตั้งลงโปรเจกต์
+
+```
+workflow/              # ★ playbook กลาง — single source of truth
+  init.md              #   INIT: วิเคราะห์โปรเจกต์ + เติม docs/ ครั้งแรก
+  roles/               #   role card: BA · PO · SA · Tech Lead · Developer · QA · Security · Infra
+  stages/              #   discovery / design / build / verify / ship
+  scripts/             #   build-wave.mjs — fan-out sub-agent ต่อ wave (worktree isolation)
+
+.claude/commands/warnyin/   # adapter สำหรับ Claude Code (slash commands)
+.claude/agents/             # reviewer subagent: warnyin-{sa,tech-lead,qa,security,infra}
+AGENTS.md                   # adapter สำหรับ Codex / Antigravity
+CLAUDE.md                   # adapter สำหรับ Claude Code
+
+docs/                  # ความรู้ถาวรระดับโปรเจกต์ (SHIP ป้อนเข้า, ทุก stage อ่านออก)
+  project.md           #   ★ จุดเริ่มของ Discovery
+  rule.md  infra.md  troubleshooting.md
+  codemap/  features/  techstack/<component>/{about,rule,standard,structure,test}.md
+
+warnyin-stages/        # พื้นที่ทำงานจริงราย topic
+  [topic]/             #   template — copy เป็น <slug> ตอนเริ่มงาน
+  achieved/            #   archive หลัง SHIP (<YYYY-MM-DD>-<slug>)
+```
+
+รายละเอียดเต็ม: [`workflow/README.md`](workflow/README.md)
+
+## จุดเด่นของแต่ละ stage
+
+- **Discovery** — สัมภาษณ์ทีละข้อ + เสนอคำตอบแนะนำทุกครั้ง; คำถามที่โค้ดตอบได้ → ไปอ่านโค้ดเอง
+- **DESIGN** — vertical slice architecture, task self-contained พร้อมโยน sub-agent, มี **review panel** (optional — SA/Tech Lead/QA/Security/Infra รีวิวขนานก่อนแตก task) และ **dry-run** (optional) สแกนหา blocker/defer ก่อนเข้า BUILD
+- **BUILD** — จัด task เป็น wave ตาม dependency (DAG), รัน parallel ใน git worktree แยกกัน, ปิดท้ายด้วย full build + full test gate แก้จนเขียวหมด
+- **VERIFY** — เทสตาม "จุดประสงค์ของ topic" ในสภาพแวดล้อมจริง ไม่ใช่แค่ unit test เขียว; FE ตรวจ UX/UI ด้วย
+- **SHIP** — จำแนก feature ใหม่/ปรับปรุง, promote rule/standard/test/troubleshooting ขึ้นไฟล์กลาง, อัปเดต code map, archive topic
+
+## Role system
+
+role card กลางที่ `workflow/roles/` — แต่ละใบกำหนด Mission / Lens / Checklist / Output ของหนึ่งบทบาท
+
+| Role | ใช้ใน | รูปแบบ |
+|---|---|---|
+| BA + PO | Discovery | lens ของ AI หลักตอนสัมภาษณ์/จัด priority |
+| SA + Tech Lead | DESIGN | lens ตอนออกแบบ/แตก task + reviewer ใน panel |
+| Developer | BUILD | system prompt ของ build agent ทุกตัว |
+| QA | VERIFY + panel | lens ของ strategy tester |
+| Security + Infra | DESIGN panel | reviewer (read-only) |
+
+- Tech Lead/Security ผูกกับ built-in `/code-review` และ `/security-review` ของ Claude Code
+- skill เสริมต่อ role ติดตั้งด้วย `/warnyin:install-skill` (รายการกลาง: `workflow/roles/README.md`)
+
+## Release เวอร์ชันใหม่ (สำหรับผู้ดูแล repo นี้)
+
+```bash
+npm version patch      # bump เวอร์ชัน + git tag
+npm publish            # ขึ้น npm registry (มี OTP)
+git push --follow-tags
+```
+
+## License
+
+MIT

package/bin/cli.mjs

@@ -41,6 +41,7 @@ if (path.resolve(pkgRoot) === path.resolve(target)) {
 const CORE = [
   'workflow',
   path.join('.claude', 'commands', 'warnyin'),
+  path.join('.claude', 'agents'),
   path.join('warnyin-stages', '[topic]'),
 ]
 // scaffold = โครง docs/ + พื้นที่ทำงาน — เป็นข้อมูลของโปรเจกต์ ไม่เขียนทับเด็ดขาด

package/installer/templates/CLAUDE.md

@@ -11,6 +11,7 @@
 
 ## Slash commands (namespace `warnyin:`)
 - `/warnyin:init` → วิเคราะห์โปรเจกต์ + เติม `docs/` ครั้งแรกหลังติดตั้ง (`workflow/init.md`)
+- `/warnyin:install-skill [role]` → ติดตั้ง skill เสริมประจำ role (รายการ: `workflow/roles/README.md`)
 - `/warnyin:discovery [topic]` → Discovery stage (`workflow/stages/discovery.md`)
 - `/warnyin:design [slug] [change]` → DESIGN stage (`workflow/stages/design.md`)
 - `/warnyin:build [slug]` → BUILD stage — fan-out sub-agent ตาม dependency (`workflow/stages/build.md` + `workflow/scripts/build-wave.mjs`)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@warnyin/agents",
-  "version": "0.1.0",
+  "version": "0.2.0",
   "description": "Warnyin Standard Workflow installer — 5-stage ways of work (Discovery/DESIGN/BUILD/VERIFY/SHIP) สำหรับทุกโปรเจกต์",
   "type": "module",
   "license": "MIT",
@@ -16,7 +16,8 @@
     "workflow",
     "docs",
     "warnyin-stages",
-    ".claude",
+    ".claude/commands",
+    ".claude/agents",
     "CLAUDE.md",
     "AGENTS.md"
   ],
@@ -25,6 +26,6 @@
   },
   "repository": {
     "type": "git",
-    "url": "https://github.com/warnyin/warnyin-agents.git"
+    "url": "git+https://github.com/warnyin/warnyin-agents.git"
   }
 }

package/workflow/README.md

@@ -37,6 +37,7 @@ installer/templates/   # template CLAUDE.md สำหรับโปรเจก
 workflow/
   README.md            # ไฟล์นี้ — ภาพรวม + วิธีรองรับหลาย AI
   init.md              # playbook: INIT — วิเคราะห์โปรเจกต์ + เติม docs/ ครั้งแรก
+  roles/               # ★ role card กลาง: ba, po, sa, tech-lead, developer, qa, security, infra
   stages/
     discovery.md       # playbook: Discovery (optional)  ✅
     design.md          # playbook: DESIGN  ✅

package/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/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/workflow/roles/developer.md

@@ -0,0 +1,28 @@
+# Role: Developer
+
+> ใช้ใน: **BUILD** — system prompt เสริมของ build sub-agent ทุกตัว (ผ่าน `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/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/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/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/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/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/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/scripts/build-wave.mjs

@@ -62,6 +62,7 @@ function prompt(task) {
     `คุณคือ build sub-agent ของ task "${task}" (vertical slice) ทำตาม playbook workflow/stages/build.md`,
     ``,
     `1. อ่านให้ครบก่อนเขียนโค้ด:`,
+    `   - 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 ห้ามเขียนซ้ำ)`,

package/workflow/stages/build.md

@@ -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 `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 กลาง
 
 ---
 

package/workflow/stages/design.md

@@ -33,7 +33,9 @@
 3. **task = หน่วยที่โยนให้ sub-agent ได้** — แต่ละ task self-contained (มี spec + standard + rule ของตัวเอง) แต่ **เชื่อมต่อกัน** ผ่าน dependency/ลำดับที่ระบุชัด
 4. **สอดคล้องมาตรฐานเสมอ** — อิง rule + standard ของ techstack; ถ้าจะเพิ่ม rule/standard ใหม่ ให้ **note ไว้ก่อน** (ยังไม่แก้ไฟล์กลาง — รอ SHIP)
 5. **Gate ก่อนเขียนไฟล์ task จริง** — ต้องผ่านเกณฑ์ข้อ 8 ก่อนจะ generate ไฟล์ task และก่อนโยนให้ sub-agent
-6. **Dry-run ก่อนเข้า BUILD (optional — ถาม user ก่อนเสมอ)** — หลังเขียนไฟล์ task ครบ เสนอ user ว่าจะ dry-run ทั้งหมดเพื่อหาจุดบกพร่องไหม ถ้า ok → สแกนทุก task แบบขนาน (read-only) หา **defer/blocker** แล้วแก้ DESIGN จนไม่มี blocker ค้าง (ดูขั้นตอนข้อ 4.9) — การแก้ **ห้ามเดา ห้ามคิดขึ้นเอง**
+6. **ใช้ role lens** — ออกแบบ (design.md) ด้วยมุม **SA** (`workflow/roles/sa.md`) และแตก/ตรวจ task ด้วยมุม **Tech Lead** (`workflow/roles/tech-lead.md`)
+7. **Review panel ก่อนแตก task (optional — ถาม user ก่อนเสมอ)** — ให้หลาย role (SA / Tech Lead / QA / Security / Infra ตาม `workflow/roles/`) รีวิว design ขนานแบบอิสระ (read-only) แล้วแก้ blocker ให้ครบก่อนแตก task (ดูขั้นตอนข้อ 4.6)
+8. **Dry-run ก่อนเข้า BUILD (optional — ถาม user ก่อนเสมอ)** — หลังเขียนไฟล์ task ครบ เสนอ user ว่าจะ dry-run ทั้งหมดเพื่อหาจุดบกพร่องไหม ถ้า ok → สแกนทุก task แบบขนาน (read-only) หา **defer/blocker** แล้วแก้ DESIGN จนไม่มี blocker ค้าง (ดูขั้นตอนข้อ 4.10) — การแก้ **ห้ามเดา ห้ามคิดขึ้นเอง**
 
 ---
 
@@ -43,11 +45,17 @@
 2. **Ground + เคลียร์ความไม่ชัด:** อ่าน Input; ทุกจุดกำกวมเรื่อง design → ถามทีละข้อ + recommended answer จนชัด (ถ้าใหญ่/ไม่ชัดมาก → แนะนำ Discovery ก่อน)
 3. **business.md** *(optional — ข้ามได้ถ้า change เล็ก เช่น fix bug นิดหน่อย)*: what & why เชิงธุรกิจ — goal, คุณค่า, persona, success metric
 4. **proposal.md** (what & why): สรุป change ที่จะทำ, เหตุผล, ทางเลือกที่พิจารณา/ตัดทิ้ง, scope in/out
-5. **design.md** (how): ออกแบบเชิงเทคนิคแบบ vertical slice — slice มีอะไรบ้าง, แต่ละ slice ตัดผ่าน layer ไหน, data model, interface/contract, flow, ผลกระทบต่อระบบเดิม
-6. **แตก tasks:** แปลง design เป็น task (= vertical slice / step ที่แก้); task ซับซ้อน → แตก **sub-task** ย่อย; เขียน **dependency graph / ลำดับ** ให้ sub-task เชื่อมกัน
-7. **rule check ต่อ task:** เปิด `docs/techstack/<component>/rule.md` หา rule ที่ task นี้ต้องโฟกัส → ใส่ใน `tasks/<task>/rule.md`; rule ใหม่ที่อยากเพิ่ม → note ใน section "เสนอเพิ่ม (รอ SHIP)"
-8. **เช็ค Gate (ข้อ 8)** → เมื่อผ่าน จึง **เขียนไฟล์ task ครบทุกใบ**
-9. **Dry-run (optional — ถาม user ก่อน):** ถาม user ว่าต้องการ dry-run ทั้งหมดเพื่อหาจุดบกพร่องก่อนเข้า BUILD ไหม — ถ้า ok:
+5. **design.md** (how): ออกแบบเชิงเทคนิคแบบ vertical slice — slice มีอะไรบ้าง, แต่ละ slice ตัดผ่าน layer ไหน, data model, interface/contract, flow, ผลกระทบต่อระบบเดิม (ใช้ lens `workflow/roles/sa.md`)
+6. **Review panel (optional — ถาม user ก่อน):** เสนอ user ว่าจะให้ panel หลาย role รีวิว design ก่อนแตก task ไหม — ถ้า ok:
+   1. fan-out sub-agent reviewer **ขนาน (read-only)** ตาม role card: **SA** (architecture/data model/contract), **Tech Lead** (feasibility/ขนาด task/dependency), **QA** (testability/acceptance), **Security** (ช่องโหว่/ข้อมูลอ่อนไหว), **Infra** (env/config/migration) — แต่ละตัวอ่าน `proposal.md` + `design.md` + โค้ดจริงที่เกี่ยว แล้วให้ความเห็นตาม checklist ใน `workflow/roles/<role>.md` แบ่งเป็น **blocker / suggestion**
+   2. รวมความเห็นทุก role → สรุปให้ user เห็นภาพ
+   3. **blocker → แก้ design ให้ครบ** โดยห้ามเดา — ติดจริงถาม user ทีละข้อ + เสนอคำตอบแนะนำ; suggestion → พิจารณา/บันทึกเหตุผลถ้าไม่ทำ
+   4. บันทึกสรุปผล panel + สิ่งที่แก้ ลงท้าย `design.md` (section "Design review")
+   5. เครื่องที่ fan-out ไม่ได้ → รีวิวทีละ role ด้วย checklist เดียวกัน
+7. **แตก tasks:** แปลง design เป็น task (= vertical slice / step ที่แก้); task ซับซ้อน → แตก **sub-task** ย่อย; เขียน **dependency graph / ลำดับ** ให้ sub-task เชื่อมกัน
+8. **rule check ต่อ task:** เปิด `docs/techstack/<component>/rule.md` หา rule ที่ task นี้ต้องโฟกัส → ใส่ใน `tasks/<task>/rule.md`; rule ใหม่ที่อยากเพิ่ม → note ใน section "เสนอเพิ่ม (รอ SHIP)"
+9. **เช็ค Gate (ข้อ 8)** → เมื่อผ่าน จึง **เขียนไฟล์ task ครบทุกใบ** (แตก task ด้วย lens `workflow/roles/tech-lead.md`)
+10. **Dry-run (optional — ถาม user ก่อน):** ถาม user ว่าต้องการ dry-run ทั้งหมดเพื่อหาจุดบกพร่องก่อนเข้า BUILD ไหม — ถ้า ok:
    1. **fan-out agent หนึ่งตัวต่อหนึ่ง task แบบขนาน (read-only — ห้ามแก้โค้ด/ไฟล์ design)** — แต่ละตัวอ่าน task ทั้ง 4 ไฟล์ + `design.md`/`proposal.md` + โค้ดจริงที่เกี่ยว แล้ว "เดิน implement ในหัว" เพื่อหา:
       - **blocker** — สิ่งที่ทำให้ implement ตาม spec ไม่ได้ (ขัดแย้งกับโค้ดจริง/กับ task อื่น, ข้อมูล/spec ขาด, dependency ผิด) — BUILD จะล้มถ้าไม่แก้
       - **defer** — จุดที่ตัดสินใจ/ทำทีหลังได้ ไม่ block การเริ่ม BUILD แต่ต้องบันทึกและ track
@@ -55,7 +63,7 @@
    3. รันครบทุก task แล้ว → **สรุปผลรวม** (จำนวน blocker/defer ต่อ task) ให้ user เห็นภาพ
    4. **หาวิธีแก้ DESIGN ตาม issue** (แก้ `design.md` / task ที่กระทบ) โดย **ห้ามเดา ห้ามคิดขึ้นเอง** — ติดจริงๆ ให้สัมภาษณ์ user **ถามทีละข้อ + เสนอคำตอบแนะนำทุกครั้ง**; คำถามที่โค้ดตอบได้ → ไปอ่านโค้ดเอง
    5. แก้แล้ว rerun dry-run เฉพาะ task ที่กระทบ วนจน **ไม่มี blocker ค้าง** (อัปเดตสถานะใน `issue.md` — defer ที่เหลือให้ user รับทราบ)
-10. **เสนอเข้า BUILD:** พร้อม implement ด้วย `/warnyin:build`
+11. **เสนอเข้า BUILD:** พร้อม implement ด้วย `/warnyin:build`
 
 > generate ไฟล์ task หลายใบพร้อมกันได้โดยใช้ sub-agent (เช่น fan-out หนึ่ง agent ต่อหนึ่ง task) — แต่ต้องผ่าน Gate ก่อนเสมอ
 > เครื่องที่ fan-out ขนานไม่ได้ (ไม่มี sub-agent tool) → dry-run สแกนทีละ task ตามลำดับด้วยหลักการเดียวกัน
@@ -102,6 +110,7 @@
 - [ ] ทุก task มี `spec.md` + `standard.md` + `rule.md` + `task.md` ครบ
 - [ ] dependency / ลำดับระหว่าง task และ sub-task ชัดเจน เชื่อมต่อกัน
 - [ ] rule ที่ต้อง follow ถูกระบุครบ; rule/standard ใหม่ที่อยากเพิ่มถูก note ไว้ (รอ SHIP)
+- [ ] ถ้าทำ review panel: **blocker จากทุก role ถูกแก้/ปิดครบ** — สรุปผลบันทึกใน `design.md` section "Design review"
 - [ ] ถ้าทำ dry-run: **ไม่มี blocker ค้าง** — ทุก issue ถูกแก้/ปิดใน `issue.md`, defer ที่เหลือ user รับทราบแล้ว
 
 ยังไม่ครบ → ห้ามเขียนไฟล์ task / ห้ามโยน sub-agent / ห้ามข้ามไป BUILD

package/workflow/stages/discovery.md

@@ -36,6 +36,7 @@ Discovery คือขั้นตอน **ค้นหาข้อมูล + d
 5. **เดินทีละกิ่งของ decision tree:** ไล่ทุกแขนงของการตัดสินใจ แก้ความสัมพันธ์ระหว่างการตัดสินใจทีละจุด ไม่ข้าม
 6. **บันทึกทันทีที่ตกลงได้:** พอได้ข้อสรุปที่ชัดเจนในประเด็นไหน ให้จดลง `discovery.md` (decision log) เลย ไม่รอจบ
 7. **ทุกข้อสรุปต้องสอดคล้องกับโปรเจกต์:** อ้างอิงกลับไปที่ `docs/project.md` และข้อจำกัดจริงเสมอ
+8. **ใช้ role lens ตอนตั้งคำถาม:** มอง scope ผ่าน checklist ของ **BA** (`workflow/roles/ba.md` — business process, ข้อยกเว้น, ข้อมูล, ข้อจำกัด) และ **PO** (`workflow/roles/po.md` — คุณค่า, priority, MVP, scope out, success metric) เพื่อให้คำถามครบมุมไม่หลุดประเด็น
 
 ### โหมด "ซักถามฉันหน่อย" (grill mode)
 เมื่อ user สั่ง grill → **ซักถามอย่างไม่หยุดหย่อนทุกแง่มุมของแผน** จนเข้าใจตรงกัน:

package/workflow/stages/verify.md

@@ -33,6 +33,7 @@
 6. **ปัญหายาก/ซ้ำในขั้นนี้ → บันทึก `warnyin-stages/<slug>/troubleshooting.md`** (เหมือน BUILD); เจอปัญหา → อ่าน `docs/troubleshooting.md` ก่อน
 7. **นาน/หลายรอบเกินไป → พิจารณาถาม user ทีละข้อ + เสนอคำตอบที่แนะนำ** (อย่าวนแก้เงียบๆ ไม่จบ)
 8. **ห้ามแตะไฟล์กลางใน `docs/`** — แผนเทสเขียนระดับ topic ที่ `test.md` ก่อน รอ SHIP merge เข้า `docs/techstack/<component>/test.md`
+9. **สวม role QA** — ทำตาม role card `workflow/roles/qa.md` (lens: คิดแบบผู้ใช้จริง + คนหาเรื่อง, edge case, regression; checklist ครบทุกข้อ)
 
 ---