@warnyin/agents 0.1.0

package/workflow/scripts/build-wave.mjs

@@ -0,0 +1,106 @@
+// build-wave — fan-out หนึ่ง sub-agent ต่อหนึ่ง task ใน "หนึ่ง wave" (task ที่ independent กัน)
+// main loop (BUILD command) เรียก script นี้ทีละ wave ตาม dependency แล้ว integrate ระหว่าง wave
+//
+// args = {
+//   slug: string,            // ชื่อ topic เช่น "billing-redesign"
+//   tasks: string[],         // ชื่อ task ใน wave นี้ (โฟลเดอร์ warnyin-stages/<slug>/tasks/<task>)
+//   isolate?: boolean,       // true = worktree ต่อ task (ดีฟอลต์), false = shared tree (sequential)
+// }
+
+export const meta = {
+  name: 'build-wave',
+  description: 'BUILD: fan-out sub-agent ต่อ task ใน wave เดียว — implement + test/lint + commit แล้วรายงานผล',
+  phases: [{ title: 'Build wave', detail: 'parallel agent, หนึ่งตัวต่อหนึ่ง task (worktree isolation)' }],
+}
+
+const slug = args && args.slug
+const tasks = (args && args.tasks) || []
+const isolate = !(args && args.isolate === false)
+
+if (!slug || tasks.length === 0) {
+  log('ไม่มี slug หรือ tasks — ไม่มีอะไรให้ build')
+  return { slug: slug || null, results: [], failed: [] }
+}
+
+phase('Build wave')
+log(`Build ${tasks.length} task ของ "${slug}"${isolate ? ' · worktree isolation' : ' · shared tree'}`)
+
+const RESULT_SCHEMA = {
+  type: 'object',
+  additionalProperties: false,
+  required: ['task', 'status', 'summary'],
+  properties: {
+    task: { type: 'string', description: 'ชื่อ task' },
+    status: { enum: ['passed', 'failed'], description: 'passed ก็ต่อเมื่อ test/lint เขียวจริง' },
+    summary: { type: 'string', description: 'สรุปสั้นๆ ว่าทำอะไร' },
+    branch: { type: 'string', description: 'ชื่อ git branch ของ worktree (ถ้า isolate) ให้ main loop merge' },
+    filesChanged: { type: 'array', items: { type: 'string' } },
+    testResult: { type: 'string', description: 'ผล test-flow + build/lint' },
+    notes: { type: 'string', description: 'conflict/ข้อควรระวัง/ rule ใหม่ที่ note ไว้' },
+    troubleshooting: {
+      type: 'array',
+      description: 'ปัญหายาก/เจอซ้ำที่แก้สำเร็จ — main loop จะเขียนรวมลง topic troubleshooting.md',
+      items: {
+        type: 'object',
+        additionalProperties: false,
+        required: ['title', 'rootCause', 'solution'],
+        properties: {
+          title: { type: 'string' },
+          symptom: { type: 'string', description: 'อาการ/error message' },
+          rootCause: { type: 'string' },
+          solution: { type: 'string' },
+          prevention: { type: 'string', description: 'วิธีป้องกันไม่ให้เกิดซ้ำ' },
+        },
+      },
+    },
+  },
+}
+
+function prompt(task) {
+  const dir = `warnyin-stages/${slug}/tasks/${task}`
+  const lines = [
+    `คุณคือ build sub-agent ของ task "${task}" (vertical slice) ทำตาม playbook workflow/stages/build.md`,
+    ``,
+    `1. อ่านให้ครบก่อนเขียนโค้ด:`,
+    `   - ${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`,
+    `   - 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 นั้น`,
+    `4. ถ้าเจอ error/ติดปัญหา → อ่าน docs/troubleshooting.md ก่อน เผื่อเคยแก้แล้ว`,
+    `5. รายงาน status=passed เฉพาะเมื่อ test/build เขียวจริง; ถ้าแก้ไม่ได้ → status=failed พร้อมเหตุผล`,
+    `   ห้ามรายงานผ่านทั้งที่ยังแดง`,
+    `6. ห้ามแก้ไฟล์ rule/standard กลางใน docs/ (rule ใหม่ note ไว้ใน ${dir}/rule.md อยู่แล้ว รอ SHIP)`,
+    `7. อัปเดตสถานะ + acceptance ที่ผ่านใน ${dir}/task.md`,
+    `8. ปัญหาที่ "ยาก/เจอซ้ำ" และแก้สำเร็จ → ใส่ในฟิลด์ troubleshooting (main loop จะรวมลง topic troubleshooting.md)`,
+  ]
+  if (isolate) {
+    lines.push(
+      `9. คุณอยู่ใน git worktree แยก: เมื่อเสร็จและเขียวแล้ว ให้ commit งาน (git add -A && git commit -m "build(${task}): ...")`,
+      `   แล้วรายงานชื่อ branch (git rev-parse --abbrev-ref HEAD) ในฟิลด์ branch เพื่อให้ main loop merge`,
+    )
+  } else {
+    lines.push(`9. (shared tree) อย่า commit เอง — main loop จะ commit ให้หลังตรวจ`)
+  }
+  lines.push(``, `คืนผลตาม schema.`)
+  return lines.join('\n')
+}
+
+const results = await parallel(
+  tasks.map((task) => () =>
+    agent(prompt(task), isolate
+      ? { label: `build:${task}`, schema: RESULT_SCHEMA, isolation: 'worktree' }
+      : { label: `build:${task}`, schema: RESULT_SCHEMA })
+  )
+)
+
+const clean = results.filter(Boolean)
+const failed = clean.filter((r) => r.status === 'failed').map((r) => r.task)
+const skipped = tasks.filter((t) => !clean.some((r) => r.task === t))
+
+log(`เสร็จ ${clean.length}/${tasks.length} · ผ่าน ${clean.length - failed.length} · ล้ม ${failed.length}${skipped.length ? ` · ข้าม ${skipped.length}` : ''}`)
+
+return { slug, results: clean, failed, skipped }

package/workflow/stages/build.md

@@ -0,0 +1,93 @@
+# Stage: BUILD
+
+> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
+> เป้าหมาย: ลงมือทำ task ที่ DESIGN เตรียมไว้ โดย **fan-out sub-agent อัตโนมัติต่อ task ตาม dependency**
+
+---
+
+## 1. BUILD คืออะไร / ใช้เมื่อไหร่
+
+ใช้เมื่อ DESIGN ผ่าน Gate แล้ว มี `tasks/<task>/` ครบ (task.md + spec.md + standard.md + rule.md)
+BUILD จะ **orchestrate การ implement** โดยกระจายงานเป็น sub-agent หนึ่งตัวต่อหนึ่ง task/slice และเดินตาม dependency graph
+
+---
+
+## 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
+4. `docs/techstack/<component>/rule.md` + `standard.md` — กฎ/มาตรฐานที่ต้อง follow
+
+---
+
+## 3. หลักการทำงาน (operating principles)
+
+1. **ถาม user ยืนยัน "ครั้งเดียวก่อนเริ่ม"** — แสดง execution plan (DAG + wave ไหนรัน parallel + isolation) ให้ user อนุมัติ แล้วจึง fan-out อัตโนมัติ ไม่ถามซ้ำระหว่างทาง
+2. **Fan-out ตาม dependency (wave-based)** — จัด task เป็น "wave" ตาม topological order ของ dependency:
+   - task ใน wave เดียวกัน = independent → รัน **parallel**
+   - ข้าม wave = มี dependency → wave ถัดไปเริ่มหลัง wave ก่อนหน้ารวมผลเสร็จ
+3. **Worktree isolation ต่อ task** — แต่ละ parallel task ทำใน git worktree ของตัวเอง ไม่แก้ไฟล์ชนกัน แล้ว **integrate (merge) เข้า build branch หลังจบแต่ละ wave**
+   - ถ้า target ไม่ใช่ git repo → fallback เป็น **sequential shared-tree** (ทีละ task ตาม dependency)
+4. **แต่ละ build agent ต้อง self-verify** — implement → รัน test-flow ใน `spec.md` + build/lint → **ต้องผ่านก่อนถึง mark passed**; ถ้าแก้ไม่ได้ให้รายงาน `failed` พร้อมเหตุผล **ห้ามรายงานผ่านทั้งที่ยังแดง**
+5. **เคารพ standard/rule ของ task** — ทำตาม `standard.md` (pattern โค้ด, reuse shared component) และ `rule.md` (กฎ) อย่างเคร่งครัด
+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 กลาง
+
+---
+
+## 4. ลำดับขั้นการทำงาน (orchestration)
+
+> ผู้ orchestrate คือ AI ตัวหลัก (main loop) — sub-agent คือคนลงมือ implement
+
+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`)
+   - แต่ละ 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
+6. **★ Full build & test gate (หลังทุก wave merge เสร็จ):** บน build branch ที่ integrate แล้ว รัน **build ทั้งหมด + test suite ทั้งหมด (รวม unit test)** ของทุก component ที่กระทบ
+   - มี error / test แดง → **แก้จนเขียวหมด (loop)** อาจ delegate fix ให้ sub-agent ทีละจุด แล้ว rerun ใหม่
+   - **ห้ามปิด BUILD ถ้ายังมี build error หรือ test ตัวใดแดง**
+   - ถ้าวนแก้หลายรอบยังไม่ผ่าน → หยุด รายงาน user พร้อม log error
+7. **ปิดงาน:** อัปเดต `build.md` (รายงานผลต่อ task + ผล full build/test) + สถานะใน `task.md` แต่ละใบ → เสนอเข้า VERIFY ด้วย `/warnyin:verify`
+
+---
+
+## 5. Output
+
+| ไฟล์ | เนื้อหา |
+|---|---|
+| โค้ดจริงใน 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`) |
+| `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
+main loop เรียก script นี้ **ทีละ wave** แล้ว integrate ระหว่าง wave (ดูรายละเอียดใน `.claude/commands/warnyin/build.md`)
+
+> เครื่องอื่น (Codex/Antigravity) ที่ไม่มี Workflow tool: ทำตามหลักการข้อ 3-4 โดย implement task ตามลำดับ wave เอง (parallel เท่าที่เครื่องรองรับ)
+
+---
+
+## 7. Gate → เข้า VERIFY ได้เมื่อ
+
+- [ ] ทุก task ใน DAG ถูก implement และ merge เข้า build branch แล้ว
+- [ ] ทุก task รายงาน `passed` (test-flow + build/lint เขียว) — ไม่มี `failed` ค้าง
+- [ ] ไม่มี merge conflict ค้าง
+- [ ] **★ Full build ของทุก component ผ่าน — ไม่มี build error**
+- [ ] **★ test suite ทั้งหมด (รวม unit test) เขียวทั้งหมดบน build branch**
+- [ ] `build.md` สรุปผลครบทุก task + ผล full build/test
+- [ ] ไม่มีการแตะ rule/standard กลางใน `docs/` (rule ใหม่ยัง note รอ SHIP)
+
+ยังไม่ครบ → อยู่ BUILD ต่อ ห้ามข้ามไป VERIFY

package/workflow/stages/design.md

@@ -0,0 +1,107 @@
+# Stage: DESIGN
+
+> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
+> เป้าหมาย: เสนอ **change ใหม่** พร้อมผลิต artifact ครบในขั้นเดียว — proposal (what & why) → design (how) → tasks (พร้อม execute)
+
+---
+
+## 1. DESIGN คืออะไร / ใช้เมื่อไหร่
+
+ใช้เมื่อ user อยากอธิบายสิ่งที่จะสร้าง/แก้แบบเร็วๆ แล้วได้ **ข้อเสนอที่สมบูรณ์** — มีทั้งการออกแบบ, spec, และ task ที่พร้อมลงมือทำ
+ครอบคลุม: build change, fix bug, แก้อะไรก็ตามที่เกี่ยวกับ **code / docs**
+
+- **ถ้าเป็นคำถาม หรือยังไม่มั่นใจเรื่อง design → แนะนำให้ใช้ `/warnyin:discovery` ก่อน** แล้วค่อยกลับมา DESIGN
+- ปรับความละเอียด artifact ตามขนาด change (ดูข้อ 7)
+
+---
+
+## 2. Input ที่ต้องอ่านก่อนเริ่ม
+
+1. `docs/project.md` — เป้าหมาย/ขอบเขตโปรเจกต์
+2. `docs/rule.md` + `docs/techstack/<component>/rule.md` — ★ กฎที่ต้อง follow
+3. `docs/techstack/<component>/standard.md` — ★ pattern/มาตรฐานการเขียนโค้ด
+4. `docs/techstack/<component>/{about,structure,test}.md`, `docs/codemap/index.md` — โครงสร้าง/วิธีเทสต์
+5. ถ้ามี Discovery → `warnyin-stages/<slug>/discovery.md`, `research.md`
+6. โค้ดจริงที่เกี่ยวข้อง (inspect เพื่อตอบคำถามแทนการเดา)
+
+---
+
+## 3. หลักการทำงาน (operating principles)
+
+1. **ห้ามเดาเอง** — จุดที่ไม่มั่นใจ ให้ **ถามทีละข้อ + เสนอคำตอบที่แนะนำ (recommended answer) ทุกข้อ** (เหมือน Discovery) คำถามที่ตอบได้ด้วยโค้ด/เอกสาร → ไปอ่านเอง
+2. **Vertical slice architecture** — ออกแบบและแตก task เป็น "slice ที่ตัดผ่านทุก layer" (UI → API → domain → data → test) ทำงาน end-to-end ได้ในตัว **ไม่แบ่งตาม layer แนวนอน**
+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) — การแก้ **ห้ามเดา ห้ามคิดขึ้นเอง**
+
+---
+
+## 4. ลำดับขั้นการทำงาน (process)
+
+1. **เตรียมพื้นที่:** ใช้/สร้างโฟลเดอร์ `warnyin-stages/<slug>/` (ถ้ามาจาก Discovery ใช้อันเดิม)
+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:
+   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
+   2. task ไหนพบ issue → เขียน `tasks/<task>/issue.md` (template `[topic]/tasks/[task-name]/issue.md`); ไม่พบ → ไม่ต้องสร้างไฟล์
+   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`
+
+> generate ไฟล์ task หลายใบพร้อมกันได้โดยใช้ sub-agent (เช่น fan-out หนึ่ง agent ต่อหนึ่ง task) — แต่ต้องผ่าน Gate ก่อนเสมอ
+> เครื่องที่ fan-out ขนานไม่ได้ (ไม่มี sub-agent tool) → dry-run สแกนทีละ task ตามลำดับด้วยหลักการเดียวกัน
+
+---
+
+## 5. Output (สร้างที่ `warnyin-stages/<slug>/`)
+
+| ไฟล์ | เนื้อหา | optional? | template |
+|---|---|---|---|
+| `business.md` | what & why เชิงธุรกิจ (goal, persona, success metric) | ✅ ข้ามได้ถ้า change เล็ก | `[topic]/business.md` |
+| `proposal.md` | what & why ของ change + ทางเลือก + scope | จำเป็น | `[topic]/proposal.md` |
+| `design.md` | how — vertical slice, data model, contract, flow | จำเป็น | `[topic]/design.md` |
+| `tasks/<task-name>/spec.md` | spec เฉพาะ task (ดูข้อ 6) | จำเป็นต่อ task | `[topic]/tasks/[task-name]/spec.md` |
+| `tasks/<task-name>/standard.md` | pattern โค้ด/shared component อิง techstack standard | จำเป็นต่อ task | `[topic]/tasks/[task-name]/standard.md` |
+| `tasks/<task-name>/rule.md` | rule ที่ต้อง follow + rule ที่เสนอเพิ่ม (รอ SHIP) | จำเป็นต่อ task | `[topic]/tasks/[task-name]/rule.md` |
+| `tasks/<task-name>/task.md` | รายละเอียด task + sub-tasks + dependency + acceptance | จำเป็นต่อ task | `[topic]/tasks/[task-name]/task.md` |
+| `tasks/<task-name>/issue.md` | ผล dry-run: defer/blocker ที่พบ + แนวทางแก้ + สถานะ | ✅ เฉพาะเมื่อ dry-run แล้วพบ issue | `[topic]/tasks/[task-name]/issue.md` |
+
+---
+
+## 6. spec.md — กำหนด spec ตามชนิดของ task
+
+ใส่เฉพาะหัวข้อที่เกี่ยวกับ task นั้น:
+- **API task** → API SPEC ตามมาตรฐาน (endpoint, method, request/response schema, error, auth, status code)
+- **UX/UI task** → UXUI SPEC (wireframe หรือ figma ref ถ้ามี), states, responsive
+- **data-flow** — ข้อมูลไหลจากไหนไปไหน
+- **user-flow** — ผู้ใช้เดินผ่านขั้นตอนไหน
+- **persona** — ทำเพื่อใคร
+- **test-flow** — จะทดสอบ/ยืนยันความถูกต้องยังไง
+
+## 7. ปรับความละเอียดตามขนาด change
+
+- **เล็ก** (fix bug นิดหน่อย): ข้าม `business.md`, `proposal.md`/`design.md` แบบสั้น, 1 task ก็พอ
+- **กลาง/ใหญ่**: ครบทุก artifact, แตก vertical slice หลาย task + sub-task, dependency ชัด
+
+---
+
+## 8. Gate → เข้า BUILD (`/warnyin:build`) ได้เมื่อ
+
+- [ ] proposal.md (+ business.md ถ้าจำเป็น) + design.md ครบ และ user เห็นชอบ
+- [ ] **ไม่มีการเดา** — ทุกจุดที่ไม่ชัดถูกถาม (ทีละข้อ + recommended answer) และปิดแล้ว
+- [ ] design เป็น vertical slice ชัด — แต่ละ task/slice ส่งมอบคุณค่า end-to-end ได้
+- [ ] ทุก task มี `spec.md` + `standard.md` + `rule.md` + `task.md` ครบ
+- [ ] dependency / ลำดับระหว่าง task และ sub-task ชัดเจน เชื่อมต่อกัน
+- [ ] rule ที่ต้อง follow ถูกระบุครบ; rule/standard ใหม่ที่อยากเพิ่มถูก note ไว้ (รอ SHIP)
+- [ ] ถ้าทำ dry-run: **ไม่มี blocker ค้าง** — ทุก issue ถูกแก้/ปิดใน `issue.md`, defer ที่เหลือ user รับทราบแล้ว
+
+ยังไม่ครบ → ห้ามเขียนไฟล์ task / ห้ามโยน sub-agent / ห้ามข้ามไป BUILD

package/workflow/stages/discovery.md

@@ -0,0 +1,76 @@
+# Stage: DISCOVERY (optional)
+
+> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
+> เป้าหมาย: เปลี่ยนความต้องการที่ยังคลุมเครือ ให้เป็น **ความเข้าใจร่วมกัน (shared understanding)** ที่ชัดพอจะเข้า DESIGN ได้
+
+---
+
+## 1. Discovery คืออะไร / ใช้เมื่อไหร่
+
+Discovery คือขั้นตอน **ค้นหาข้อมูล + deep research + สัมภาษณ์** เพื่อตี scope สิ่งที่ user ต้องการ
+จากภาพกว้าง → แคบลงเรื่อยๆ จนทุกฝ่ายเข้าใจตรงกันก่อนลงมือออกแบบ
+
+- **optional** — ข้ามได้ถ้า scope ชัดอยู่แล้ว (งานเล็ก/ชัดเจน) แล้วไป DESIGN ตรงๆ
+- ใช้เมื่อ: โจทย์กว้าง/กำกวม, มีหลายทางเลือก, มี trade-off ที่ต้องตัดสินใจ, หรือ user พิมพ์ **"ซักถามฉันหน่อย" / "grill me"**
+
+---
+
+## 2. Input ที่ต้องอ่านก่อนเริ่ม (เรียงลำดับ)
+
+อ่านเพื่อ "ground" ตัวเองในบริบทโปรเจกต์ — **อย่าเพิ่งถาม user สิ่งที่หาเองได้**
+
+1. `docs/project.md` — ★ จุดเริ่มเสมอ: โปรเจกต์นี้คืออะไร เป้าหมาย ลูกค้า ขอบเขต
+2. `docs/rule.md`, `docs/infra.md` — กฎและโครงสร้างพื้นฐาน
+3. `docs/codemap/index.md` — แผนที่โค้ด (ไปอ่านโค้ดจริงต่อได้)
+4. `docs/features/*`, `docs/techstack/*` — ฟีเจอร์เดิม + tech stack ของแต่ละ component
+5. `warnyin-stages/context.md` และ topic ที่ `achieved/` ที่ใกล้เคียง — เคยทำอะไรไปแล้ว
+
+---
+
+## 3. หลักการทำงาน (operating principles)
+
+1. **กว้าง → แคบ:** เริ่มจากภาพรวม แล้วค่อยๆ ตี scope ให้แคบลงทีละชั้น (problem → goal → ขอบเขต → ทางเลือก → รายละเอียด)
+2. **ถามทีละข้อ (one question at a time):** ห้ามถามรัวหลายข้อพร้อมกัน รอคำตอบก่อนค่อยถามข้อถัดไป
+3. **เสนอคำตอบที่แนะนำทุกครั้ง:** ทุกคำถามต้องแนบ *recommended answer* + เหตุผลสั้นๆ ให้ user แค่ยืนยัน/แก้ ไม่ใช่คิดเองทั้งหมด
+4. **โค้ดตอบได้ → ไปอ่านโค้ด ไม่ต้องถาม:** ถ้าคำถามไหนตอบได้ด้วยการ inspect โค้ด/เอกสาร ให้ไปหาคำตอบเองแล้วรายงานสิ่งที่พบ แทนการถาม user
+5. **เดินทีละกิ่งของ decision tree:** ไล่ทุกแขนงของการตัดสินใจ แก้ความสัมพันธ์ระหว่างการตัดสินใจทีละจุด ไม่ข้าม
+6. **บันทึกทันทีที่ตกลงได้:** พอได้ข้อสรุปที่ชัดเจนในประเด็นไหน ให้จดลง `discovery.md` (decision log) เลย ไม่รอจบ
+7. **ทุกข้อสรุปต้องสอดคล้องกับโปรเจกต์:** อ้างอิงกลับไปที่ `docs/project.md` และข้อจำกัดจริงเสมอ
+
+### โหมด "ซักถามฉันหน่อย" (grill mode)
+เมื่อ user สั่ง grill → **ซักถามอย่างไม่หยุดหย่อนทุกแง่มุมของแผน** จนเข้าใจตรงกัน:
+ความถูกต้องของสมมติฐาน, edge case, ทางเลือกที่ตัดทิ้งและทำไม, ผลกระทบต่อระบบเดิม, ต้นทุน/เวลา, ความเสี่ยง, เกณฑ์ความสำเร็จ — ยังคงถามทีละข้อ + เสนอคำตอบที่แนะนำ
+
+---
+
+## 4. ลำดับขั้นการทำงาน (process loop)
+
+1. **เตรียมพื้นที่:** ถ้ายังไม่มีโฟลเดอร์ topic → copy `warnyin-stages/[topic]/` เป็น `warnyin-stages/<slug>/` (slug = kebab-case ของหัวข้องาน)
+2. **Ground:** อ่าน Input ในข้อ 2 ให้ครบ สรุปความเข้าใจเริ่มต้น 3-5 บรรทัด ให้ user ยืนยัน
+3. **ตี scope กว้าง→แคบ ผ่านการสัมภาษณ์:** วนลูป — ถาม 1 ข้อ (พร้อม recommended answer) → user ตอบ → จดผลลง decision log → ถ้าตอบได้ด้วยโค้ดให้ไปอ่านเอง
+4. **research คู่ขนาน:** สิ่งที่ต้องค้นจริง (prior art, ทางเลือก technical, ข้อจำกัด) → จดลง `research.md` พร้อม evidence/links
+5. **เช็ค gate (ข้อ 6):** เมื่อครบเกณฑ์ → สรุปและเสนอ "พร้อมเข้า DESIGN"
+
+---
+
+## 5. Output (สร้างที่ `warnyin-stages/<slug>/`)
+
+| ไฟล์ | เนื้อหา | template |
+|---|---|---|
+| `discovery.md` | decision log + shared understanding + scope + PRD ย่อ + feature ideas | `warnyin-stages/[topic]/discovery.md` |
+| `research.md` | คำถามวิจัย + วิธี/แหล่ง + findings + code inspection + implication | `warnyin-stages/[topic]/research.md` |
+
+> เริ่มจาก template (ไฟล์ใน `[topic]/`) เป็นโครง แล้วเติมเนื้อหาจริง อัปเดตทุกครั้งที่ได้ข้อสรุปใหม่
+
+---
+
+## 6. Gate → เข้า DESIGN ได้เมื่อ
+
+- [ ] Problem / why-now ชัด และผูกกับ `docs/project.md`
+- [ ] Scope in / out ระบุชัด (สิ่งที่จะทำ และจะไม่ทำ)
+- [ ] Decision log ปิดทุกประเด็นสำคัญ — ไม่มี open question ที่ block การออกแบบ
+- [ ] เกณฑ์ความสำเร็จ (success criteria) วัดผลได้
+- [ ] สมมติฐาน/ข้อจำกัด/ความเสี่ยงหลัก ถูกบันทึก
+- [ ] user ยืนยันว่า "เข้าใจตรงกันแล้ว"
+
+ยังไม่ครบ → อยู่ Discovery ต่อ ห้ามข้ามไป DESIGN

package/workflow/stages/ship.md

@@ -0,0 +1,84 @@
+# Stage: SHIP
+
+> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
+> เป้าหมาย: **ส่งมอบ** — promote ความรู้ระดับ topic ขึ้นเอกสารกลางใน `docs/` + archive topic เข้า `warnyin-stages/achieved/`
+
+---
+
+## 1. SHIP คืออะไร / ใช้เมื่อไหร่
+
+ใช้หลัง VERIFY ผ่าน Gate แล้ว — SHIP ปิดวงจรของ topic โดยยกความรู้ที่เกิดขึ้นระหว่างงาน
+(feature, rule/standard ใหม่, วิธีเทส, troubleshooting, โครงสร้างโค้ดที่เปลี่ยน) ขึ้น **เอกสารกลางถาวร** ใน `docs/`
+แล้ว archive ทั้ง topic — เพื่อให้งานถัดไปเริ่มจากความรู้ล่าสุดเสมอ
+
+> SHIP เป็นเรื่อง **เอกสาร + archive เท่านั้น** — การ merge โค้ด (build branch → main / PR) จัดการเองนอก workflow
+
+---
+
+## 2. Input ที่ต้องอ่านก่อนเริ่ม
+
+1. `warnyin-stages/<slug>/` **ทุกไฟล์** — discovery, business, proposal, design, build, test, verify, troubleshooting, tasks/*
+   → เข้าใจว่า topic นี้ **ทำอะไร ทำอย่างไร** และเกิดความรู้อะไรใหม่บ้าง
+2. `tasks/<task>/rule.md` section "เสนอเพิ่ม rule ใหม่ (รอ SHIP)" + `standard.md` — rule/standard ใหม่ที่ note ค้างไว้
+3. เอกสารกลางปลายทางที่จะอัปเดต — `docs/features/`, `docs/techstack/<component>/*`, `docs/rule.md`,
+   `docs/troubleshooting.md`, `docs/infra.md`, `docs/project.md`, `docs/codemap/`
+4. โค้ดจริงที่ change กระทบ — สำหรับอัปเดต structure + code map ให้ตรงความเป็นจริง
+
+---
+
+## 3. หลักการทำงาน (operating principles)
+
+1. **เข้าใจก่อน promote** — อ่าน topic ทั้งหมดให้เข้าใจว่าทำอะไร/ทำอย่างไร แล้วค่อยตัดสินใจว่าความรู้ชิ้นไหนควรขึ้นไฟล์กลางไหน
+2. **ขอ user ยืนยัน "ครั้งเดียวก่อนลงมือ"** — สรุป promotion plan (feature ใหม่หรือปรับปรุง, ไฟล์กลางที่จะอัปเดต + สาระที่จะใส่, ชื่อโฟลเดอร์ archive) ให้ user อนุมัติ แล้วจึง execute ไม่ถามซ้ำระหว่างทาง
+3. **★ Archive ก่อนอัปเดตเอกสาร** — ย้ายทั้งโฟลเดอร์ `warnyin-stages/<slug>/` → `warnyin-stages/achieved/<YYYY-MM-DD>-<slug>/` (วันที่ของวันที่ SHIP) **ก่อน** เริ่มแก้ `docs/` แล้วอ่านเนื้อหาจาก path ใหม่ระหว่าง promote
+4. **กลั่น ไม่ใช่ copy ดิบ** — merge สาระเข้าโครงสร้างของไฟล์กลางเดิม ระวัง duplicate/ขัดแย้งกับเนื้อหาที่มีอยู่; เขียนแบบ "ความรู้ถาวร" ไม่ใช่บันทึกรายงาน
+5. **เอกสารต้องตรงโค้ดจริง** — structure/codemap อัปเดตจากการดูโค้ดจริง ไม่ใช่จากความจำหรือ design เดิม
+6. **อย่าเดา** — เนื้อหาที่ไม่แน่ใจว่าควร promote หรือควรวางไว้ไฟล์ไหน → ถามทีละข้อ + เสนอคำตอบที่แนะนำ
+7. **เก็บ "รอ SHIP" ให้หมด** — rule/standard ที่ note ค้างไว้ใน tasks ต้องถูกพิจารณาครบทุกข้อ (promote หรือตัดทิ้งพร้อมเหตุผล) ห้ามปล่อยค้าง
+
+---
+
+## 4. ลำดับขั้นการทำงาน (process)
+
+1. **อ่านทำความเข้าใจ topic:** อ่าน `warnyin-stages/<slug>/` ทุกไฟล์ — topic นี้ทำอะไร ทำอย่างไร เกิดความรู้ใหม่อะไรบ้าง (เช็คก่อนว่า VERIFY ผ่าน Gate แล้ว — มี `verify.md` สรุปผลผ่าน)
+2. **จำแนก feature:** สิ่งที่ทำเป็น **feature ใหม่** หรือ **ปรับปรุง feature เดิม** (เทียบกับ `docs/features/` ที่มีอยู่)
+3. **สรุป promotion plan + ขออนุมัติ (ครั้งเดียว):** feature ใหม่/ปรับปรุง, รายการไฟล์กลางที่จะอัปเดต + สาระ, ชื่อโฟลเดอร์ archive → รอ user ไฟเขียว
+4. **★ Archive:** ย้ายทั้งโฟลเดอร์ → `warnyin-stages/achieved/<YYYY-MM-DD>-<slug>/` (ใช้ `git mv` ถ้าเป็น git repo)
+5. **อัปเดตเอกสารกลาง** (อ่านเนื้อหาจาก path ใน achieved):
+   1. **`docs/features/<feature-name>/`** — feature ใหม่ → สร้างโฟลเดอร์ใหม่ (`feature.md` + `business.md`); ปรับปรุง feature เดิม → อัปเดตโฟลเดอร์เดิม โดยใช้เนื้อหาจาก `business.md` / `proposal.md` / `design.md` ของ topic
+   2. **`docs/techstack/<component>/`** — `rule.md` / `standard.md` (จาก note "รอ SHIP" ใน tasks), `structure.md` (โครงสร้างที่เปลี่ยน), `test.md` (merge แผนเทสจาก `test.md` ของ topic)
+   3. **`docs/rule.md`** — global rule ใหม่/ที่เปลี่ยน (เฉพาะข้อที่เป็นกฎระดับโปรเจกต์ ไม่ผูกกับ component เดียว)
+   4. **`docs/troubleshooting.md`** — merge entry จาก `troubleshooting.md` ของ topic (ปัญหา/อาการ/root cause/วิธีแก้/ป้องกันซ้ำ)
+   5. **`docs/infra.md` + `docs/project.md`** — เฉพาะถ้ามีข้อมูลที่เกี่ยวข้อง (env/service ใหม่, scope/เป้าหมายโปรเจกต์ที่ขยับ)
+   6. **`docs/codemap/` ทั้งหมด** — อัปเดต code map ให้ตรงกับโค้ดจริงปัจจุบัน (ตรวจจากโค้ดจริง อย่างน้อยทุกส่วนที่ change กระทบ)
+6. **เขียนสรุปส่งมอบ:** `achieved/<YYYY-MM-DD>-<slug>/ship.md` — feature ใหม่/ปรับปรุง, เอกสารกลางที่อัปเดต (ไฟล์ → สาระ), note ที่ตัดทิ้งพร้อมเหตุผล
+7. **ปิดงาน:** รายงาน user ว่าส่งมอบครบ — topic ปิดสมบูรณ์
+
+---
+
+## 5. Output
+
+| ที่ | เนื้อหา |
+|---|---|
+| `docs/features/<feature-name>/` | feature.md + business.md (สร้างใหม่หรืออัปเดต) |
+| `docs/techstack/<component>/{rule,standard,structure,test}.md` | rule/standard ใหม่, โครงสร้าง, วิธีเทสที่ promote ขึ้น |
+| `docs/rule.md` | global rule ที่เพิ่ม/เปลี่ยน |
+| `docs/troubleshooting.md` | KB ปัญหา-วิธีแก้ที่ merge เข้า |
+| `docs/infra.md`, `docs/project.md` | อัปเดตเฉพาะถ้ามีข้อมูลเกี่ยวข้อง |
+| `docs/codemap/` | code map ตรงกับโค้ดจริงปัจจุบัน |
+| `warnyin-stages/achieved/<YYYY-MM-DD>-<slug>/` | ทั้ง topic ที่ archive แล้ว + `ship.md` (สรุปการส่งมอบ) |
+
+---
+
+## 6. Gate → topic ปิดสมบูรณ์เมื่อ
+
+- [ ] topic ถูกย้ายไป `warnyin-stages/achieved/<YYYY-MM-DD>-<slug>/` แล้ว (ไม่เหลือใน `warnyin-stages/`)
+- [ ] `docs/features/` สะท้อน feature ใหม่/ที่ปรับปรุงแล้ว
+- [ ] note "รอ SHIP" ทุกข้อใน `tasks/*/rule.md` + `standard.md` ถูกพิจารณาครบ — promote หรือตัดทิ้งพร้อมเหตุผล
+- [ ] `docs/troubleshooting.md` รวม entry จาก topic แล้ว
+- [ ] `docs/techstack/`, `docs/rule.md`, `docs/infra.md`, `docs/project.md` อัปเดตตามที่เกี่ยวข้อง
+- [ ] `docs/codemap/` ตรงกับโค้ดจริงปัจจุบัน
+- [ ] `ship.md` สรุปการส่งมอบเขียนครบใน achieved
+- [ ] user รับทราบผลการส่งมอบ
+
+ยังไม่ครบ → อยู่ SHIP ต่อ topic ยังไม่ปิด

package/workflow/stages/verify.md

@@ -0,0 +1,70 @@
+# Stage: VERIFY
+
+> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
+> เป้าหมาย: เป็น **strategy tester** — ยืนยันว่า change ที่ build แล้ว "ทำงานถูกตามจุดประสงค์ของ topic" จริง (functional + UX/UI ถ้าเป็น FE) แก้จนผ่าน
+
+---
+
+## 1. VERIFY คืออะไร / ใช้เมื่อไหร่
+
+ใช้หลัง BUILD ผ่าน Gate (full build/test เขียว) — VERIFY ทดสอบ **เชิงพฤติกรรม/จุดประสงค์** ในสภาพแวดล้อมจริง (local env)
+ไม่ใช่แค่ unit test ผ่าน แต่ "ของจริงทำงานตามที่ topic ตั้งใจไหม"
+
+---
+
+## 2. ก่อนเทส — อ่านให้เข้าใจก่อนเสมอ
+
+1. **spec + tasks ทั้งหมด** — `warnyin-stages/<slug>/tasks/*/spec.md` + `task.md`, `design.md`, `proposal.md`
+   → เข้าใจ **จุดประสงค์ของ topic** และสิ่งที่ต้องยืนยัน (อย่าเทสผ่านๆ โดยไม่เข้าใจ)
+2. **`docs/techstack/<component>/test.md`** — guideline ว่าเทสยังไง (เช่น frontend: e2e smoke ผ่าน **playwright-cli**)
+   → ถ้า **ไม่มี** guideline → แนะนำว่าควรเทสแบบไหน/วิธีใดได้บ้าง แล้วเขียนแผนลง `test.md`
+3. **`docs/infra.md`** — local env / service ที่ต้องรันเพื่อเทส
+4. **`docs/troubleshooting.md`** — เผื่อปัญหาที่จะเจอเคยถูกแก้แล้ว
+
+---
+
+## 3. หลักการทำงาน (operating principles)
+
+1. **เข้าใจจุดประสงค์ก่อนเทส** — เทสตามเจตนาของ topic ไม่ใช่แค่ให้เขียว
+2. **เทสในสภาพแวดล้อมจริง (local env)** — รัน service ที่เกี่ยวข้องใน local แล้วเทสตามแผน
+3. **ใช้ guideline จาก `test.md`** ของ techstack; ถ้าไม่มีให้เสนอวิธีเทสที่เหมาะแล้วเขียนแผนเอง
+4. **Frontend → verify UX/UI ด้วย** (ไม่ใช่แค่ functional — ดู layout, state, flow, ความถูกต้องของหน้าจอ)
+5. **ข้อไหน verify ไม่ผ่าน → แก้จนผ่าน (loop)** และ **นับจำนวนการแก้ไข/จำนวนรอบ**
+6. **ปัญหายาก/ซ้ำในขั้นนี้ → บันทึก `warnyin-stages/<slug>/troubleshooting.md`** (เหมือน BUILD); เจอปัญหา → อ่าน `docs/troubleshooting.md` ก่อน
+7. **นาน/หลายรอบเกินไป → พิจารณาถาม user ทีละข้อ + เสนอคำตอบที่แนะนำ** (อย่าวนแก้เงียบๆ ไม่จบ)
+8. **ห้ามแตะไฟล์กลางใน `docs/`** — แผนเทสเขียนระดับ topic ที่ `test.md` ก่อน รอ SHIP merge เข้า `docs/techstack/<component>/test.md`
+
+---
+
+## 4. ลำดับขั้นการทำงาน (process)
+
+0. **★ เช็ค context window ก่อนเริ่ม:** ประเมินว่า context ของ session ปัจจุบันถูกใช้ไปมากน้อยแค่ไหน — ถ้าใช้ไปเยอะหรือ **เกินครึ่ง** → **เสนอ user ให้ `/compact` หรือ `/clear` ก่อนเสมอ** แล้วค่อยเริ่ม VERIFY ใน context ที่โล่ง (สถานะงานอยู่ในไฟล์ `warnyin-stages/<slug>/` ครบ ไม่หายไปกับ context) — VERIFY เป็นลูปเทส-แก้ที่อาจยาว ต้องมี context เหลือมากพอ; เครื่องอื่นที่ไม่มีคำสั่งนี้ → แนะนำเริ่ม session ใหม่
+1. **เข้าใจจุดประสงค์:** อ่าน spec/tasks/design → สรุปสิ่งที่ต้อง verify (functional + UX/UI)
+2. **วางแผนเทส → เขียน `test.md`:** ตาม guideline `docs/techstack/<component>/test.md`; ไม่มีก็เสนอวิธี (e2e smoke / integration / manual ฯลฯ) แล้วเขียนแผน
+3. **เตรียม local env:** รัน service ที่เกี่ยวข้องตาม `infra.md`
+4. **รันเทสตามแผน:** functional ตาม test-flow ใน spec; FE → e2e smoke (playwright-cli) + ตรวจ UX/UI
+5. **ไม่ผ่าน → แก้ → rerun:** วนจนผ่าน **นับจำนวนรอบ/จำนวนแก้**; ปัญหายาก→`troubleshooting.md`; ถ้านานเกิน→ถาม user (ทีละข้อ + recommended)
+6. **เขียนสรุป `verify.md`:** ผลเทส + รายการแก้ไข + **จำนวนการแก้ไข** + ผล UX/UI
+7. **ปิดงาน:** เสนอเข้า SHIP ด้วย `/warnyin:ship`
+
+---
+
+## 5. Output (สร้างที่ `warnyin-stages/<slug>/`)
+
+| ไฟล์ | เนื้อหา | ปลายทางตอน SHIP |
+|---|---|---|
+| `test.md` | แผน/วิธีเทสของ topic (cases, env, e2e smoke, UXUI checklist) | merge เข้า `docs/techstack/<component>/test.md` |
+| `verify.md` | สรุปผล verify + รายการแก้ไข + จำนวนรอบที่แก้ | (เก็บใน archive) |
+| `troubleshooting.md` (อัปเดต) | ปัญหายาก/ซ้ำที่เจอตอนเทส | merge เข้า `docs/troubleshooting.md` |
+
+---
+
+## 6. Gate → เข้า SHIP ได้เมื่อ
+
+- [ ] เทสตาม **จุดประสงค์ของ topic** ครบ (functional ตาม test-flow ใน spec)
+- [ ] Frontend: **UX/UI verify ผ่าน**
+- [ ] ทุกข้อที่ไม่ผ่านถูกแก้จน **verify ผ่านหมด**
+- [ ] `test.md` (แผน) + `verify.md` (สรุป + จำนวนการแก้ไข) เขียนครบ
+- [ ] ปัญหายาก/ซ้ำถูกบันทึก `troubleshooting.md`
+
+ยังไม่ครบ → อยู่ VERIFY ต่อ ห้ามข้ามไป SHIP