@warnyin/agents 0.4.0 → 0.5.1

package/warnyin/workflow/init.md

@@ -3,6 +3,9 @@
 > **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
 > เป้าหมาย: ทำให้ `docs/` สะท้อนโปรเจกต์จริง — เพื่อให้ทุก stage (Discovery→SHIP) เริ่มจากความรู้ที่ถูกต้อง ไม่ใช่โครงว่างเปล่า
 
+> ⚠️ **Deliverable ของ INIT = ไฟล์จริงที่ถูกเขียนลงดิสก์ใน `docs/`**
+> การวิเคราะห์แล้วสรุปในแชทอย่างเดียว **ถือว่ายังไม่จบงาน** — INIT จะจบได้ก็ต่อเมื่อทุกไฟล์ในตาราง §4 ถูก write ลง `docs/` จริงและผ่าน gate §5
+
 ---
 
 ## 1. INIT คืออะไร / ใช้เมื่อไหร่
@@ -15,11 +18,14 @@
 ## 2. หลักการทำงาน (operating principles)
 
 1. **โค้ดตอบได้ → อ่านโค้ดเอง ห้ามเดา** — structure, techstack, convention, วิธี build/test, infra วิเคราะห์จาก **โค้ดจริง + config จริง** เท่านั้น
-2. **ข้อมูลธุรกิจโค้ดตอบไม่ได้ → สัมภาษณ์ user** — เป้าหมายโปรเจกต์ ลูกค้า ขอบเขต ความสำคัญ: **ถามทีละข้อ + เสนอคำตอบแนะนำทุกครั้ง** (เดาจาก README/โค้ดเป็น recommended answer ให้ user แค่ยืนยัน/แก้)
+2. **ข้อมูลธุรกิจโค้ดตอบไม่ได้ → สัมภาษณ์ user ผ่าน role lens เฉพาะทาง** — เป้าหมายโปรเจกต์ ลูกค้า ขอบเขต ความสำคัญ: AI หลัก **สวม lens ของ BA** (`warnyin/workflow/roles/ba.md`) และ **PO** (`warnyin/workflow/roles/po.md`) ใช้ checklist ของทั้งสองเป็นชุดคำถาม — **ถามทีละข้อ + เสนอคำตอบแนะนำทุกครั้ง** (เดาจาก README/โค้ดเป็น recommended answer ให้ user แค่ยืนยัน/แก้)
+   - role ที่ต้องคุยกับ user เป็น **lens เสมอ ไม่ใช่ sub-agent** (sub-agent คุยกับ user ไม่ได้) — fan-out sub-agent ใช้ได้เฉพาะงานวิเคราะห์โค้ด read-only (ข้อ 5)
+   - ถ้าติดตั้ง skill `product-management` ไว้ (ดู `/warnyin:install-skill po`) → หยิบมาเสริมมุมตอนตั้งคำถาม scope/priority ได้
 3. **เสนอ summary ก่อนเขียน** — สรุปสิ่งที่วิเคราะห์ได้ + รายการไฟล์ docs/ ที่จะเขียน ให้ user ยืนยัน **ครั้งเดียว** แล้วจึงเขียนจริง
 4. **ไฟล์ docs/ ที่มีเนื้อหาอยู่แล้ว → เติม/อัปเดต ไม่เขียนทับทิ้ง** — ของเดิมของ user มีค่าเสมอ
 5. **วิเคราะห์หลาย component ขนานได้** — fan-out sub-agent (read-only) หนึ่งตัวต่อหนึ่ง component; เครื่องที่ไม่มี sub-agent → วิเคราะห์ทีละ component ด้วยหลักการเดียวกัน
 6. **ไม่แน่ใจ → ระบุว่า "ยังว่าง รอเติม" ชัดเจน** — ห้ามแต่งเนื้อหาขึ้นเองเพื่อให้ไฟล์ดูเต็ม
+7. **เขียนไฟล์จริงเสมอ ห้ามจบแค่สรุปในแชท** — หลัง user ยืนยัน summary ต้อง write ทุกไฟล์ในตาราง §4 ลง `docs/` ด้วย (copy template → เติมเนื้อหา); วิเคราะห์เสร็จแล้วไม่เขียนไฟล์ = งานล้มเหลว
 
 ---
 
@@ -28,9 +34,42 @@
 1. **สแกนภาพรวม:** โครงสร้าง repo, package manifest, ภาษา/framework, แบ่งเป็น **component** อะไรบ้าง (เช่น api-service, admin-console)
 2. **วิเคราะห์ลึกต่อ component (ขนานได้, read-only):** โครงสร้างโฟลเดอร์/โมดูล, pattern/convention ที่ใช้จริงในโค้ด, วิธี build/test ที่มีอยู่
 3. **วิเคราะห์ infra:** docker/compose, env, service ที่ต้องรันสำหรับ local dev
-4. **สัมภาษณ์ user เติมส่วนธุรกิจ:** เป้าหมายโปรเจกต์ ลูกค้า ขอบเขต — ทีละข้อ + recommended answer
-5. **เสนอ summary → user ยืนยันครั้งเดียว → เขียน docs/** (ตามตาราง Output ข้อ 4)
-6. **รายงานปิดท้าย:** ส่วนไหนยังว่าง/ไม่แน่ใจ ให้ user เติมภายหลัง → พร้อมเริ่มงานแรกด้วย `/warnyin:discovery` หรือ `/warnyin:design`
+4. **สัมภาษณ์ user เติมส่วนที่โค้ดตอบไม่ได้ (สวม BA + PO lens):**
+   - **ก่อนถาม → สแกนสิ่งที่มีอยู่ก่อนเสมอ:** README, `docs/project.md` เดิม, comment/config ในโค้ด — เอามาเป็น recommended answer; **ถามเฉพาะช่องที่ยัง "ขาดหาย" จริง** ไม่ถามซ้ำสิ่งที่หาคำตอบได้เอง
+   - **สวม BA lens** (`warnyin/workflow/roles/ba.md`) ไล่ checklist: ปัญหาจริง/ใครเจ็บ, as-is→to-be, edge case ของ process, ข้อมูล/เจ้าของ, ข้อจำกัด (กฎหมาย/ระบบเดิม), acceptance วัดได้ไหม
+   - **สวม PO lens** (`warnyin/workflow/roles/po.md`) ไล่ checklist: persona หลัก, success metric ที่วัดได้, MVP เล็กสุด, priority (must/should/could), why-now, scope-out
+   - ถาม **ทีละข้อ + เสนอคำตอบแนะนำทุกครั้ง** (AskUserQuestion) — เป็น lens ของ AI หลัก **ห้าม fan-out sub-agent มาสัมภาษณ์** (คุยกับ user ไม่ได้)
+   - ถ้าติดตั้ง `product-management` skill ไว้ → ใช้เสริมมุม scope/priority
+   - คำตอบที่ได้ → ใช้เติม `docs/project.md` (เป้าหมาย/ลูกค้า/ขอบเขต) และ `rule.md` ของแต่ละ component (กฎที่ user สั่ง)
+5. **เสนอ summary → user ยืนยันครั้งเดียว**
+6. **เขียนไฟล์จริงลง `docs/` ให้ครบตาราง §4 (ขั้นบังคับ ห้ามข้าม)** — ทำตามกลไก 6.1–6.4 นี้:
+
+   **6.1 ไฟล์ root** — copy template แล้วเติม:
+   ```
+   mkdir -p docs
+   cp warnyin/template/docs/project.md         docs/project.md
+   cp warnyin/template/docs/infra.md           docs/infra.md
+   cp warnyin/template/docs/rule.md            docs/rule.md
+   cp warnyin/template/docs/troubleshooting.md docs/troubleshooting.md
+   ```
+   - ไฟล์ไหนมีอยู่แล้วใน `docs/` → **ห้าม `cp` ทับ** ให้เปิดอ่านแล้ว Edit เติมแทน
+   - `project.md` → เติมจากผลสัมภาษณ์ user (ข้อ 4) · `infra.md` → เติมจาก config จริง (ข้อ 3) · `rule.md`/`troubleshooting.md` → วางโครงหัวข้อ ใส่ `<!-- ยังว่าง รอเติม -->` ในส่วนที่ยังไม่มีข้อมูล
+
+   **6.2 โฟลเดอร์ component** — วนทำ **ทุก component** ที่ได้จากข้อ 1 (สมมติชื่อจริง `<name>`):
+   ```
+   cp -R "warnyin/template/docs/techstack/[component]" "docs/techstack/<name>"
+   ```
+   - ทำซ้ำคำสั่งนี้หนึ่งครั้งต่อหนึ่ง component (เช่น `api-service`, `admin-console`) — **rename เป็นชื่อจริงเสมอ**
+   - หลัง copy ครบ → ต้อง **ไม่มี** โฟลเดอร์ `docs/techstack/[component]` (ที่มีวงเล็บ) หลงเหลือ; ถ้ามีให้ลบทิ้ง
+
+   **6.3 เติมเนื้อหา 5 ไฟล์ในแต่ละ component** ด้วย Write/Edit (อิงผลวิเคราะห์ข้อ 2):
+   - `about.md` (component คืออะไร/ภาษา/framework) · `structure.md` (โครงโฟลเดอร์) · `standard.md` (convention ที่พบจริง + ยืนยัน user) · `rule.md` (กฎที่ user สั่ง — ถามก่อน ห้ามเดา) · `test.md` (framework/คำสั่งเทส)
+   - ส่วนที่ข้อมูลไม่พอ → ใส่ `<!-- ยังว่าง รอเติม -->` ห้ามแต่ง
+
+   **6.4 codemap** — สร้าง `docs/codemap/` ตาม playbook `warnyin/workflow/codemap.md` (token-lean) อย่างน้อยต้องมี `index.md`
+
+7. **Verify ว่าเขียนจริง:** รัน `find docs -type f` เทียบกับตาราง §4 — ทุกแถวต้องมีไฟล์จริง, ทุก component มีครบ 5 ไฟล์, ไม่มีโฟลเดอร์/ไฟล์ที่ยังมี `[component]` (วงเล็บ) หลงเหลือ
+8. **รายงานปิดท้าย:** ส่วนไหนยังว่าง/ไม่แน่ใจ ให้ user เติมภายหลัง → พร้อมเริ่มงานแรกด้วย `/warnyin:discovery` หรือ `/warnyin:design`
 
 ---
 
@@ -54,6 +93,8 @@
 
 ## 5. Gate → จบ INIT เมื่อ
 
+- [ ] **ไฟล์ทุกแถวในตาราง §4 ถูกเขียนลง `docs/` จริง** (ยืนยันด้วย `find docs -type f`) — ไม่มีแถวไหนเหลือแค่ในแชท
+- [ ] ไม่มีโฟลเดอร์ชื่อ `[component]` (มีวงเล็บ) หลงเหลือ — ถูก copy เป็นชื่อ component จริงครบทุกตัว
 - [ ] `docs/project.md` มีเป้าหมาย/ลูกค้า/ขอบเขต ที่ user ยืนยันแล้ว
 - [ ] `docs/techstack/` ครบทุก component ที่พบ (about + structure + standard + test)
 - [ ] `docs/codemap/index.md` + `docs/infra.md` ตรงกับโค้ด/config จริง

package/warnyin/workflow/next.md

@@ -0,0 +1,47 @@
+# NEXT — เช็คงานค้าง + แนะนำขั้นตอนถัดไป (read-only)
+
+> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
+> เป้าหมาย: ตอบคำถาม "ตอนนี้มีงานอะไรค้าง และควรไปต่อยังไง" จากสถานะจริงในไฟล์ — **ไม่สร้างหรือแก้ไฟล์ใดๆ**
+
+---
+
+## 1. NEXT คืออะไร / ใช้เมื่อไหร่
+
+NEXT คือโหมด **อ่านอย่างเดียว (read-only)** — ไม่ใช่ stage, ไม่มี gate, ไม่มี output ไฟล์
+ใช้เมื่อ: กลับมาทำงานต่อแล้วจำไม่ได้ว่าค้างตรงไหน, อยากเห็นภาพรวมทุก topic, หรืออยากรู้ว่า command ถัดไปคืออะไร
+
+---
+
+## 2. วิธีหาสถานะ (สแกนจากไฟล์จริง — ไม่ถาม user ก่อน)
+
+1. **หา topic ที่ active:** โฟลเดอร์ใน `warnyin/stages/<slug>/` ทั้งหมด ยกเว้น `achieved/` และ `context.md`
+   - ไม่มี topic เลย → รายงานว่า "ไม่มีงานค้าง" + แนะนำเริ่มงานใหม่ด้วย `/warnyin:discovery` หรือ `/warnyin:design`
+2. **อ่าน `warnyin/stages/context.md`** — บริบทงานที่จดไว้ (ถ้ามี)
+3. **ต่อ topic — ระบุ stage ปัจจุบันจาก artifact ที่ "ถูกเติมจริง":**
+   ไฟล์ที่ยังเป็นโครง template (มี placeholder `<...>` / ตารางว่าง) = **ยังไม่ทำ** — ดูเนื้อหา ไม่ใช่แค่ว่าไฟล์มีอยู่
+
+   | artifact ที่เติมแล้วล่าสุด | stage ปัจจุบัน | ขั้นถัดไป |
+   |---|---|---|
+   | ยังไม่มีอะไรเติม | ยังไม่เริ่ม | `/warnyin:discovery <slug>` หรือ `/warnyin:design <slug> <change>` ถ้า scope ชัด |
+   | `discovery.md` / `research.md` | Discovery | เช็ค gate ของ `stages/discovery.md` → ผ่านแล้วไป `/warnyin:design` |
+   | `proposal.md` / `design.md` / `tasks/` | DESIGN | เช็ค gate ของ `stages/design.md` → ผ่านแล้วไป `/warnyin:build` |
+   | `build.md` / task มีสถานะ `กำลังทำ`-`เสร็จ` | BUILD | task ค้าง → `/warnyin:build` ต่อ; ครบแล้ว → `/warnyin:verify` |
+   | `test.md` / `verify.md` | VERIFY | เช็ค gate ของ `stages/verify.md` → ผ่านแล้วไป `/warnyin:ship` |
+   | `ship.md` เติมแล้วแต่ topic ยังไม่ถูก archive | SHIP ยังไม่จบ | รัน `/warnyin:ship` ให้จบ (promote ขึ้น `docs/` + ย้ายไป `achieved/`) |
+
+4. **งานค้างระดับ task (เฉพาะ topic ที่อยู่ BUILD):** ไล่ `tasks/*/task.md` — ช่อง **สถานะ** (`รอ build` / `กำลังทำ` / `เสร็จ`) + checkbox ของ sub-tasks/acceptance ที่ยังไม่ติ๊ก
+5. **เช็ค gate ของ stage ปัจจุบัน:** เปิด playbook ของ stage นั้นใน `warnyin/workflow/stages/` แล้วไล่ checklist gate ว่าข้อไหนยังไม่ครบ — ข้อที่ขาดคือ "งานค้าง" ที่แท้จริง
+
+---
+
+## 3. รูปแบบรายงาน (ตอบในแชทเท่านั้น)
+
+1. **ตารางภาพรวม:** topic · stage ปัจจุบัน · งานค้าง/gate ที่ขาด · command ถัดไปที่แนะนำ
+2. **รายละเอียดต่อ topic** (เฉพาะที่มีงานค้าง): ข้อ gate ที่ยังไม่ผ่าน, task ที่ยัง `รอ build`/`กำลังทำ`, open question
+3. **คำแนะนำลำดับงาน:** ถ้ามีหลาย topic ให้เสนอว่าควรทำอันไหนก่อนพร้อมเหตุผลสั้นๆ — ตัดสินใจสุดท้ายเป็นของ user
+
+## 4. หลักการ
+
+1. **Read-only เด็ดขาด** — ห้ามสร้าง/แก้/ลบไฟล์ รวมถึง `context.md`; ถ้าพบว่าสถานะในไฟล์ล้าสมัย ให้รายงานเป็นข้อเสนอ ไม่แก้เอง
+2. **สรุปจาก evidence:** ทุกข้อสรุปอ้างไฟล์/บรรทัดจริง ไม่เดา
+3. **แนะนำแล้วหยุด:** ไม่รัน stage ถัดไปให้เอง — เสนอ command ให้ user เป็นคนสั่ง

package/warnyin/workflow/scripts/build-wave.mjs

@@ -1,107 +1,107 @@
-// 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 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`,
-    `   - 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 }
+// 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 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`,
+    `   - 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/warnyin/workflow/stages/build.md

@@ -1,94 +1,94 @@
-# 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. **ทุก 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 กลาง
-
----
-
-## 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** (`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
-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)
-
-ใช้ `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 เท่าที่เครื่องรองรับ)
-
----
-
-## 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
+# 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. **ทุก 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 กลาง
+
+---
+
+## 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** (`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
+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)
+
+ใช้ `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 เท่าที่เครื่องรองรับ)
+
+---
+
+## 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