@warnyin/agents 0.17.0 → 0.18.0

package/src/.warnyin/workflow/stages/ship.md

@@ -1,94 +1,94 @@
-# Stage: SHIP
-
-> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
-> เป้าหมาย: **ส่งมอบ** — promote ความรู้ระดับ topic ขึ้นเอกสารกลางใน `docs/` + archive topic เข้า `docs/stages/achieved/`
-> **Context profile:** สวมโหมด `review` (`.warnyin/workflow/contexts/review.md`) — session-level posture ของ stage นี้
-
----
-
-## 1. SHIP คืออะไร / ใช้เมื่อไหร่
-
-ใช้หลัง VERIFY ผ่าน Gate แล้ว — SHIP ปิดวงจรของ topic โดยยกความรู้ที่เกิดขึ้นระหว่างงาน
-(feature, rule/standard ใหม่, วิธีเทส, troubleshooting, โครงสร้างโค้ดที่เปลี่ยน) ขึ้น **เอกสารกลางถาวร** ใน `docs/`
-แล้ว archive ทั้ง topic — เพื่อให้งานถัดไปเริ่มจากความรู้ล่าสุดเสมอ
-
-> SHIP เป็นเรื่อง **เอกสาร + archive เท่านั้น** — การ merge โค้ด (build branch → main / PR) จัดการเองนอก workflow
-
-> **★ fast-track hook:** ถ้า topic เป็น tier `fast` (จาก `/warnyin:triage`) → **ship-lite** ตาม [fast-track skip-list](../triage.md#fast-track-skip-list) — promote เฉพาะที่มี (อาจไม่มี learned-rule), archive ครบ; **correctness floor คงไว้ — archive ครบ + ไม่แตะ rule กลางมั่ว**. tier `standard`/`large` → flow เต็มด้านล่าง (hook นี้ N/A ไม่ลด bar)
-
----
-
-## 2. Input ที่ต้องอ่านก่อนเริ่ม
-
-1. `docs/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 ก่อนอัปเดตเอกสาร** — ย้ายทั้งโฟลเดอร์ `docs/stages/<slug>/` → `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` (วันที่ของวันที่ SHIP) **ก่อน** เริ่มแก้ `docs/` แล้วอ่านเนื้อหาจาก path ใหม่ระหว่าง promote
-4. **กลั่น ไม่ใช่ copy ดิบ** — merge สาระเข้าโครงสร้างของไฟล์กลางเดิม ระวัง duplicate/ขัดแย้งกับเนื้อหาที่มีอยู่; เขียนแบบ "ความรู้ถาวร" ไม่ใช่บันทึกรายงาน
-5. **เอกสารต้องตรงโค้ดจริง** — structure/codemap อัปเดตจากการดูโค้ดจริง ไม่ใช่จากความจำหรือ design เดิม; **ครอบ Spec delta ด้วย** — ถ้าพฤติกรรมจริง (หลัง BUILD/VERIFY) ต่างจาก delta ที่ approve ไว้ → **อัปเดต delta ใน design.md ก่อน แล้วค่อย merge**; และ re-check delta เทียบ `spec.md` ปัจจุบัน ณ เวลา ship (ไม่ใช่ ณ เวลา design)
-6. **อย่าเดา** — เนื้อหาที่ไม่แน่ใจว่าควร promote หรือควรวางไว้ไฟล์ไหน → ถามทีละข้อ + เสนอคำตอบที่แนะนำ
-7. **เก็บ learned-rule ให้หมด — planned + emergent** — รวบรวม rule ที่จะ promote ทุกตัว: ทั้ง **planned** (note "รอ SHIP" ใน `tasks/*/rule.md` §2) และ **emergent** (บทเรียนที่โผล่ตอนลงมือ — สแกน `build.md`/`verify.md`/`troubleshooting.md`/diff); ทุกตัวต้องมี **evidence (บังคับ)** + **scope** + **user ยืนยัน** ก่อน promote — ไม่มี evidence ไม่ promote (สอด "ห้ามเดา"); **learned-rule = กฎ generalize ไม่ใช่ incident** (troubleshooting = incident ที่ *อ้าง* เป็น evidence ได้). พิจารณาครบทุกข้อ (promote หรือตัดทิ้งพร้อมเหตุผล) ห้ามปล่อยค้าง
-
----
-
-## 4. ลำดับขั้นการทำงาน (process)
-
-1. **อ่านทำความเข้าใจ topic + รวบรวม learned-rule candidate:** อ่าน `docs/stages/<slug>/` ทุกไฟล์ — topic นี้ทำอะไร ทำอย่างไร เกิดความรู้ใหม่อะไรบ้าง (เช็คก่อนว่า VERIFY ผ่าน Gate แล้ว — มี `verify.md` สรุปผลผ่าน; ถ้ารัน node ได้ → รัน `node .warnyin/workflow/scripts/validate-topic.mjs <slug>` — มี ✖ ควรแก้ก่อน promote (script เช็คโครง; ความถูกของเนื้อหายังเป็นหน้าที่ผู้ ship)) — พร้อมกันนั้น **รวบรวม learned-rule candidate** เป็นตาราง (ทุกตัว = `rule + evidence + scope + promote?`):
-   - **planned:** จาก `tasks/*/rule.md` §2 "เสนอเพิ่ม rule ใหม่ (รอ SHIP)"
-   - **emergent:** สแกนบทเรียนที่โผล่ตอนลงมือ — `build.md` (pattern แก้ซ้ำ/integration), `verify.md` (รายการแก้+จำนวนรอบ), `troubleshooting.md` (ปัญหายาก→"กันซ้ำ" = candidate ชัดสุด), diff/commit
-   - **entry แต่ละตัว:** `rule` = ข้อความ **generalize** (ถ้าเป็น incident "X พังเพราะ Y" ยกเป็นกฎ "ก่อนแก้ Z เช็ค Y เสมอ") · `evidence` = **บังคับ** concrete pointer 1 บรรทัด + ลิงก์ artifact (`build.md`/`verify.md`/`troubleshooting.md`/diff/commit) — **ไม่มี evidence = ไม่ promote** · `scope` = `component:<c>`→`docs/techstack/<c>/rule.md` หรือ `project`→`docs/rule.md`
-2. **จำแนก feature:** สิ่งที่ทำเป็น **feature ใหม่** หรือ **ปรับปรุง feature เดิม** (เทียบกับ `docs/features/` ที่มีอยู่)
-3. **สรุป promotion plan + ขออนุมัติ (ครั้งเดียว):** feature ใหม่/ปรับปรุง, รายการไฟล์กลางที่จะอัปเดต + สาระ, ชื่อโฟลเดอร์ archive — **fold ตาราง learned-rule (rule + evidence + scope) เข้า approval เดียวกันนี้ ให้ user ยืนยัน per-rule** (✅ promote / ✂️ ตัด + เหตุผล) → รอ user ไฟเขียว
-4. **★ Archive:** ย้ายทั้งโฟลเดอร์ → `docs/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 — **และ merge `spec.md`** ตาม Spec delta ใน `design.md` §9: **ADDED** → ต่อท้าย `spec.md` · **MODIFIED** → แทนที่ requirement ชื่อตรงกัน (rename → หาด้วย `[เดิมชื่อ:]`) · **REMOVED** → ลบ requirement; **read-modify-verify — key ไม่เจอ → STOP:** MODIFIED/REMOVED ที่หา key ไม่เจอใน `spec.md` ของ feature ที่ `(→ feature:)` ระบุ → **หยุด ถาม user ห้าม merge เงียบ** (ห้ามตีความเป็น ADDED เอง); **feature ใหม่** → สร้าง `spec.md` จาก ADDED ทั้งก้อน (template `[feature-name]/spec.md`); **feature เดิมยังไม่มี `spec.md`** → สร้างใหม่จาก delta + พฤติกรรมจริง
-   2. **`docs/techstack/<component>/`** — `rule.md` / `standard.md` (learned-rule ที่ยืนยันแล้ว scope `component:<c>` + note "รอ SHIP" ใน tasks), `structure.md` (โครงสร้างที่เปลี่ยน), `test.md` (merge แผนเทสจาก `test.md` ของ topic); **`openapi.yaml` (ถ้า topic มี)** — promote `docs/stages/<slug>/openapi.yaml` → `docs/techstack/<component>/openapi.yaml` (living API contract): มีอยู่แล้ว → **merge ตาม delta** (path/schema ที่ topic แตะ) ไม่ทับทั้งไฟล์; ยังไม่มี → สร้างใหม่ — ทำตาม `.warnyin/workflow/api-doc.md` §4
-   3. **`docs/rule.md`** — global rule ใหม่/ที่เปลี่ยน (learned-rule ที่ยืนยันแล้ว scope `project` — กฎระดับโปรเจกต์ ไม่ผูกกับ component เดียว)
-   > promote learned-rule **เฉพาะตัวที่ user ยืนยัน (step 3)** ตาม scope: `component:<c>` → `docs/techstack/<c>/rule.md` · `project` → `docs/rule.md`
-   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 ให้ตรงกับโค้ดจริงปัจจุบัน ทำตาม playbook `.warnyin/workflow/codemap.md` (Claude Code: `/warnyin:update-codemaps`)
-6. **เขียนสรุปส่งมอบ:** `achieved/<YYYY-MM-DD>-<slug>/ship.md` — feature ใหม่/ปรับปรุง, เอกสารกลางที่อัปเดต (ไฟล์ → สาระ), note ที่ตัดทิ้งพร้อมเหตุผล
-7. **ปิดงาน:** รายงาน user ว่าส่งมอบครบ — topic ปิดสมบูรณ์
-
----
-
-## 5. Output
-
-| ที่ | เนื้อหา |
-|---|---|
-| `docs/features/<feature-name>/` | feature.md + business.md + spec.md (สร้างใหม่หรืออัปเดต — spec.md merge ตาม Spec delta) |
-| `docs/techstack/<component>/{rule,standard,structure,test}.md` | rule/standard ใหม่, โครงสร้าง, วิธีเทสที่ promote ขึ้น |
-| `docs/techstack/<component>/openapi.yaml` | living API contract — เฉพาะ topic ที่แตะ REST API (merge ตาม delta) |
-| `docs/rule.md` | global rule ที่เพิ่ม/เปลี่ยน |
-| `docs/troubleshooting.md` | KB ปัญหา-วิธีแก้ที่ merge เข้า |
-| `docs/infra.md`, `docs/project.md` | อัปเดตเฉพาะถ้ามีข้อมูลเกี่ยวข้อง |
-| `docs/codemap/` | code map ตรงกับโค้ดจริงปัจจุบัน |
-| `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` | ทั้ง topic ที่ archive แล้ว + `ship.md` (สรุปการส่งมอบ) |
-
----
-
-## 6. Gate → topic ปิดสมบูรณ์เมื่อ
-
-- [ ] topic ถูกย้ายไป `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` แล้ว (ไม่เหลือใน `docs/stages/`)
-- [ ] `docs/features/` สะท้อน feature ใหม่/ที่ปรับปรุงแล้ว
-- [ ] **Spec delta merge แล้ว** — `spec.md` ของ feature ที่แตะถูก merge ตาม delta; ทุก MODIFIED/REMOVED match requirement จริง (read-modify-verify — key ไม่เจอ → STOP ถาม user แล้ว ไม่ merge เงียบ)
-- [ ] learned-rules (planned + emergent) พิจารณาครบทุกตัว — note "รอ SHIP" ใน `tasks/*/rule.md` + `standard.md` + บทเรียน emergent จาก build/verify/troubleshooting; ทุก promote มี **evidence + user ยืนยัน**, ตัดทิ้งมีเหตุผล
-- [ ] `docs/troubleshooting.md` รวม entry จาก topic แล้ว
-- [ ] `docs/techstack/`, `docs/rule.md`, `docs/infra.md`, `docs/project.md` อัปเดตตามที่เกี่ยวข้อง
-- [ ] **API contract (ถ้า topic มี `openapi.yaml`)** — promote/merge เข้า `docs/techstack/<component>/openapi.yaml` ตาม delta แล้ว (`.warnyin/workflow/api-doc.md`)
-- [ ] `docs/codemap/` ตรงกับโค้ดจริงปัจจุบัน
-- [ ] `ship.md` สรุปการส่งมอบเขียนครบใน achieved
-- [ ] user รับทราบผลการส่งมอบ
-
-ยังไม่ครบ → อยู่ SHIP ต่อ topic ยังไม่ปิด
+# Stage: SHIP
+
+> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
+> เป้าหมาย: **ส่งมอบ** — promote ความรู้ระดับ topic ขึ้นเอกสารกลางใน `docs/` + archive topic เข้า `docs/stages/achieved/`
+> **Context profile:** สวมโหมด `review` (`.warnyin/workflow/contexts/review.md`) — session-level posture ของ stage นี้
+
+---
+
+## 1. SHIP คืออะไร / ใช้เมื่อไหร่
+
+ใช้หลัง VERIFY ผ่าน Gate แล้ว — SHIP ปิดวงจรของ topic โดยยกความรู้ที่เกิดขึ้นระหว่างงาน
+(feature, rule/standard ใหม่, วิธีเทส, troubleshooting, โครงสร้างโค้ดที่เปลี่ยน) ขึ้น **เอกสารกลางถาวร** ใน `docs/`
+แล้ว archive ทั้ง topic — เพื่อให้งานถัดไปเริ่มจากความรู้ล่าสุดเสมอ
+
+> SHIP เป็นเรื่อง **เอกสาร + archive เท่านั้น** — การ merge โค้ด (build branch → main / PR) จัดการเองนอก workflow
+
+> **★ fast-track hook:** ถ้า topic เป็น tier `fast` (จาก `/warnyin:triage`) → **ship-lite** ตาม [fast-track skip-list](../triage.md#fast-track-skip-list) — promote เฉพาะที่มี (อาจไม่มี learned-rule), archive ครบ; **correctness floor คงไว้ — archive ครบ + ไม่แตะ rule กลางมั่ว**. tier `standard`/`large` → flow เต็มด้านล่าง (hook นี้ N/A ไม่ลด bar)
+
+---
+
+## 2. Input ที่ต้องอ่านก่อนเริ่ม
+
+1. `docs/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 ก่อนอัปเดตเอกสาร** — ย้ายทั้งโฟลเดอร์ `docs/stages/<slug>/` → `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` (วันที่ของวันที่ SHIP) **ก่อน** เริ่มแก้ `docs/` แล้วอ่านเนื้อหาจาก path ใหม่ระหว่าง promote
+4. **กลั่น ไม่ใช่ copy ดิบ** — merge สาระเข้าโครงสร้างของไฟล์กลางเดิม ระวัง duplicate/ขัดแย้งกับเนื้อหาที่มีอยู่; เขียนแบบ "ความรู้ถาวร" ไม่ใช่บันทึกรายงาน
+5. **เอกสารต้องตรงโค้ดจริง** — structure/codemap อัปเดตจากการดูโค้ดจริง ไม่ใช่จากความจำหรือ design เดิม; **ครอบ Spec delta ด้วย** — ถ้าพฤติกรรมจริง (หลัง BUILD/VERIFY) ต่างจาก delta ที่ approve ไว้ → **อัปเดต delta ใน design.md ก่อน แล้วค่อย merge**; และ re-check delta เทียบ `spec.md` ปัจจุบัน ณ เวลา ship (ไม่ใช่ ณ เวลา design)
+6. **อย่าเดา** — เนื้อหาที่ไม่แน่ใจว่าควร promote หรือควรวางไว้ไฟล์ไหน → ถามทีละข้อ + เสนอคำตอบที่แนะนำ
+7. **เก็บ learned-rule ให้หมด — planned + emergent** — รวบรวม rule ที่จะ promote ทุกตัว: ทั้ง **planned** (note "รอ SHIP" ใน `tasks/*/rule.md` §2) และ **emergent** (บทเรียนที่โผล่ตอนลงมือ — สแกน `build.md`/`verify.md`/`troubleshooting.md`/diff); ทุกตัวต้องมี **evidence (บังคับ)** + **scope** + **user ยืนยัน** ก่อน promote — ไม่มี evidence ไม่ promote (สอด "ห้ามเดา"); **learned-rule = กฎ generalize ไม่ใช่ incident** (troubleshooting = incident ที่ *อ้าง* เป็น evidence ได้). พิจารณาครบทุกข้อ (promote หรือตัดทิ้งพร้อมเหตุผล) ห้ามปล่อยค้าง
+
+---
+
+## 4. ลำดับขั้นการทำงาน (process)
+
+1. **อ่านทำความเข้าใจ topic + รวบรวม learned-rule candidate:** อ่าน `docs/stages/<slug>/` ทุกไฟล์ — topic นี้ทำอะไร ทำอย่างไร เกิดความรู้ใหม่อะไรบ้าง (เช็คก่อนว่า VERIFY ผ่าน Gate แล้ว — มี `verify.md` สรุปผลผ่าน; ถ้ารัน node ได้ → รัน `node .warnyin/workflow/scripts/validate-topic.mjs <slug>` — มี ✖ ควรแก้ก่อน promote (script เช็คโครง; ความถูกของเนื้อหายังเป็นหน้าที่ผู้ ship)) — พร้อมกันนั้น **รวบรวม learned-rule candidate** เป็นตาราง (ทุกตัว = `rule + evidence + scope + promote?`):
+   - **planned:** จาก `tasks/*/rule.md` §2 "เสนอเพิ่ม rule ใหม่ (รอ SHIP)"
+   - **emergent:** สแกนบทเรียนที่โผล่ตอนลงมือ — `build.md` (pattern แก้ซ้ำ/integration), `verify.md` (รายการแก้+จำนวนรอบ), `troubleshooting.md` (ปัญหายาก→"กันซ้ำ" = candidate ชัดสุด), diff/commit
+   - **entry แต่ละตัว:** `rule` = ข้อความ **generalize** (ถ้าเป็น incident "X พังเพราะ Y" ยกเป็นกฎ "ก่อนแก้ Z เช็ค Y เสมอ") · `evidence` = **บังคับ** concrete pointer 1 บรรทัด + ลิงก์ artifact (`build.md`/`verify.md`/`troubleshooting.md`/diff/commit) — **ไม่มี evidence = ไม่ promote** · `scope` = `component:<c>`→`docs/techstack/<c>/rule.md` หรือ `project`→`docs/rule.md`
+2. **จำแนก feature:** สิ่งที่ทำเป็น **feature ใหม่** หรือ **ปรับปรุง feature เดิม** (เทียบกับ `docs/features/` ที่มีอยู่)
+3. **สรุป promotion plan + ขออนุมัติ (ครั้งเดียว):** feature ใหม่/ปรับปรุง, รายการไฟล์กลางที่จะอัปเดต + สาระ, ชื่อโฟลเดอร์ archive — **fold ตาราง learned-rule (rule + evidence + scope) เข้า approval เดียวกันนี้ ให้ user ยืนยัน per-rule** (✅ promote / ✂️ ตัด + เหตุผล) → รอ user ไฟเขียว
+4. **★ Archive:** ย้ายทั้งโฟลเดอร์ → `docs/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 — **และ merge `spec.md`** ตาม Spec delta ใน `design.md` §9: **ADDED** → ต่อท้าย `spec.md` · **MODIFIED** → แทนที่ requirement ชื่อตรงกัน (rename → หาด้วย `[เดิมชื่อ:]`) · **REMOVED** → ลบ requirement; **read-modify-verify — key ไม่เจอ → STOP:** MODIFIED/REMOVED ที่หา key ไม่เจอใน `spec.md` ของ feature ที่ `(→ feature:)` ระบุ → **หยุด ถาม user ห้าม merge เงียบ** (ห้ามตีความเป็น ADDED เอง); **feature ใหม่** → สร้าง `spec.md` จาก ADDED ทั้งก้อน (template `[feature-name]/spec.md`); **feature เดิมยังไม่มี `spec.md`** → สร้างใหม่จาก delta + พฤติกรรมจริง
+   2. **`docs/techstack/<component>/`** — `rule.md` / `standard.md` (learned-rule ที่ยืนยันแล้ว scope `component:<c>` + note "รอ SHIP" ใน tasks), `structure.md` (โครงสร้างที่เปลี่ยน), `test.md` (merge แผนเทสจาก `test.md` ของ topic); **`openapi.yaml` (ถ้า topic มี)** — promote `docs/stages/<slug>/openapi.yaml` → `docs/techstack/<component>/openapi.yaml` (living API contract): มีอยู่แล้ว → **merge ตาม delta** (path/schema ที่ topic แตะ) ไม่ทับทั้งไฟล์; ยังไม่มี → สร้างใหม่ — ทำตาม `.warnyin/workflow/api-doc.md` §4
+   3. **`docs/rule.md`** — global rule ใหม่/ที่เปลี่ยน (learned-rule ที่ยืนยันแล้ว scope `project` — กฎระดับโปรเจกต์ ไม่ผูกกับ component เดียว)
+   > promote learned-rule **เฉพาะตัวที่ user ยืนยัน (step 3)** ตาม scope: `component:<c>` → `docs/techstack/<c>/rule.md` · `project` → `docs/rule.md`
+   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 ให้ตรงกับโค้ดจริงปัจจุบัน ทำตาม playbook `.warnyin/workflow/codemap.md` (Claude Code: `/warnyin:update-codemaps`)
+6. **เขียนสรุปส่งมอบ:** `achieved/<YYYY-MM-DD>-<slug>/ship.md` — feature ใหม่/ปรับปรุง, เอกสารกลางที่อัปเดต (ไฟล์ → สาระ), note ที่ตัดทิ้งพร้อมเหตุผล
+7. **ปิดงาน:** รายงาน user ว่าส่งมอบครบ — topic ปิดสมบูรณ์
+
+---
+
+## 5. Output
+
+| ที่ | เนื้อหา |
+|---|---|
+| `docs/features/<feature-name>/` | feature.md + business.md + spec.md (สร้างใหม่หรืออัปเดต — spec.md merge ตาม Spec delta) |
+| `docs/techstack/<component>/{rule,standard,structure,test}.md` | rule/standard ใหม่, โครงสร้าง, วิธีเทสที่ promote ขึ้น |
+| `docs/techstack/<component>/openapi.yaml` | living API contract — เฉพาะ topic ที่แตะ REST API (merge ตาม delta) |
+| `docs/rule.md` | global rule ที่เพิ่ม/เปลี่ยน |
+| `docs/troubleshooting.md` | KB ปัญหา-วิธีแก้ที่ merge เข้า |
+| `docs/infra.md`, `docs/project.md` | อัปเดตเฉพาะถ้ามีข้อมูลเกี่ยวข้อง |
+| `docs/codemap/` | code map ตรงกับโค้ดจริงปัจจุบัน |
+| `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` | ทั้ง topic ที่ archive แล้ว + `ship.md` (สรุปการส่งมอบ) |
+
+---
+
+## 6. Gate → topic ปิดสมบูรณ์เมื่อ
+
+- [ ] topic ถูกย้ายไป `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` แล้ว (ไม่เหลือใน `docs/stages/`)
+- [ ] `docs/features/` สะท้อน feature ใหม่/ที่ปรับปรุงแล้ว
+- [ ] **Spec delta merge แล้ว** — `spec.md` ของ feature ที่แตะถูก merge ตาม delta; ทุก MODIFIED/REMOVED match requirement จริง (read-modify-verify — key ไม่เจอ → STOP ถาม user แล้ว ไม่ merge เงียบ)
+- [ ] learned-rules (planned + emergent) พิจารณาครบทุกตัว — note "รอ SHIP" ใน `tasks/*/rule.md` + `standard.md` + บทเรียน emergent จาก build/verify/troubleshooting; ทุก promote มี **evidence + user ยืนยัน**, ตัดทิ้งมีเหตุผล
+- [ ] `docs/troubleshooting.md` รวม entry จาก topic แล้ว
+- [ ] `docs/techstack/`, `docs/rule.md`, `docs/infra.md`, `docs/project.md` อัปเดตตามที่เกี่ยวข้อง
+- [ ] **API contract (ถ้า topic มี `openapi.yaml`)** — promote/merge เข้า `docs/techstack/<component>/openapi.yaml` ตาม delta แล้ว (`.warnyin/workflow/api-doc.md`)
+- [ ] `docs/codemap/` ตรงกับโค้ดจริงปัจจุบัน
+- [ ] `ship.md` สรุปการส่งมอบเขียนครบใน achieved
+- [ ] user รับทราบผลการส่งมอบ
+
+ยังไม่ครบ → อยู่ SHIP ต่อ topic ยังไม่ปิด

package/src/.warnyin/workflow/stages/verify.md

@@ -1,82 +1,82 @@
-# Stage: VERIFY
-
-> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
-> เป้าหมาย: เป็น **strategy tester** — ยืนยันว่า change ที่ build แล้ว "ทำงานถูกตามจุดประสงค์ของ topic" จริง (functional + UX/UI ถ้าเป็น FE) แก้จนผ่าน
-> **Context profile:** สวมโหมด `review` (`.warnyin/workflow/contexts/review.md`) — session-level posture ของ stage นี้
-
----
-
-## 1. VERIFY คืออะไร / ใช้เมื่อไหร่
-
-ใช้หลัง BUILD ผ่าน Gate (full build/test เขียว) — VERIFY ทดสอบ **เชิงพฤติกรรม/จุดประสงค์** ในสภาพแวดล้อมจริง (local env)
-ไม่ใช่แค่ unit test ผ่าน แต่ "ของจริงทำงานตามที่ topic ตั้งใจไหม"
-
-> **★ fast-track hook:** ถ้า topic เป็น tier `fast` (จาก `/warnyin:triage`) → **verify-lite** ตาม [fast-track skip-list](../triage.md#fast-track-skip-list) — functional ตาม spec + test เขียว, ข้าม empirical/panel ที่ไม่เกี่ยว; **correctness floor คงไว้ — test ต้องเขียวจริง**. tier `standard`/`large` → flow เต็มด้านล่าง (hook นี้ N/A ไม่ลด bar)
-
----
-
-## 2. ก่อนเทส — อ่านให้เข้าใจก่อนเสมอ
-
-1. **spec + tasks ทั้งหมด** — `docs/stages/<slug>/tasks/*/spec.md` + `task.md`, `design.md`, `proposal.md`
-   → เข้าใจ **จุดประสงค์ของ topic** และสิ่งที่ต้องยืนยัน (อย่าเทสผ่านๆ โดยไม่เข้าใจ)
-2. **`docs/features/<name>/spec.md` = regression baseline** — อ่าน behavior spec ของ feature ที่ topic แตะ (ดูจาก Spec delta ใน `design.md`); topic แตะหลาย feature → baseline = union ของ spec ทุก feature ที่ delta อ้างถึง; feature ยังไม่มี spec → ข้ามได้ (วิธีเดิม)
-   - **`docs/stages/<slug>/openapi.yaml` (ถ้ามี)** = API contract ที่ต้องยืนยัน — topic ที่แตะ REST API ต้อง verify ว่าโค้ดจริง **ตรง contract** (ดูข้อ 4)
-3. **`docs/techstack/<component>/test.md`** — guideline ว่าเทสยังไง (เช่น frontend: e2e smoke ผ่าน **playwright-cli**)
-   → ถ้า **ไม่มี** guideline → แนะนำว่าควรเทสแบบไหน/วิธีใดได้บ้าง แล้วเขียนแผนลง `test.md`
-4. **`docs/infra.md`** — local env / service ที่ต้องรันเพื่อเทส
-5. **`docs/troubleshooting.md`** — เผื่อปัญหาที่จะเจอเคยถูกแก้แล้ว
-6. **runtime security** (`.warnyin/workflow/roles/security.md` → "Runtime / operational security") — ตอนรันเทส local env ที่มี secret จริง ทบทวน secret isolation / no-egress / identity separation ก่อนปล่อย agent แตะของจริง
-
----
-
-## 3. หลักการทำงาน (operating principles)
-
-1. **เข้าใจจุดประสงค์ก่อนเทส** — เทสตามเจตนาของ topic ไม่ใช่แค่ให้เขียว **และพฤติกรรมเดิมจาก feature spec** — scenario เดิมใน `docs/features/<name>/spec.md` = regression case (ต้องไม่พัง ยกเว้นที่ MODIFIED/REMOVED ระบุ), scenario ใน Spec delta = test case ใหม่
-2. **เทสในสภาพแวดล้อมจริง (local env)** — รัน service ที่เกี่ยวข้องใน local แล้วเทสตามแผน
-3. **ใช้ guideline จาก `test.md`** ของ techstack; ถ้าไม่มีให้เสนอวิธีเทสที่เหมาะแล้วเขียนแผนเอง
-4. **Frontend → verify UX/UI ด้วย** (ไม่ใช่แค่ functional — ดู layout, state, flow, ความถูกต้องของหน้าจอ)
-5. **ข้อไหน verify ไม่ผ่าน → แก้จนผ่าน (loop)** และ **นับจำนวนการแก้ไข/จำนวนรอบ**
-6. **ปัญหายาก/ซ้ำในขั้นนี้ → บันทึก `docs/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 `.warnyin/workflow/roles/qa.md` (lens: คิดแบบผู้ใช้จริง + คนหาเรื่อง, edge case, regression; checklist ครบทุกข้อ)
-10. **★ investigate-before-edit** (enforce ของ "ห้ามเดา") — ก่อนแก้ไฟล์ที่มีอยู่ ต้องเข้าใจก่อน — **ใครใช้/อ่านไฟล์นี้, schema/contract/สัญญาของมัน, เจตนาเดิม**; แก้โดยไม่เข้าใจ = เดา (กรณีไม่ชัด → ถาม user / อ่านโค้ดที่อ้างถึง ก่อนแก้)
-11. **★ config-protection** (enforce ของ "ห้ามเดา") — ตอน fix loop (ข้อ 5 "แก้จนผ่าน") ห้ามแก้ config (linter/formatter/test threshold) หรือ disable rule **"เพื่อให้ build/test ผ่าน"** แทนการแก้ root cause จริง — "แก้จนผ่าน" ต้องเป็นการแก้ที่ต้นเหตุ ไม่ใช่ลด bar; ถ้า config ผิดจริง แก้ได้แต่ต้องมี **เหตุผลชัด + note** (ไม่ใช่เพื่อเลี่ยง finding)
-
----
-
-## 4. ลำดับขั้นการทำงาน (process)
-
-0. **★ เช็ค context window ก่อนเริ่ม:** ประเมินว่า context ของ session ปัจจุบันถูกใช้ไปมากน้อยแค่ไหน — ถ้าใช้ไปเยอะหรือ **เกินครึ่ง** → **เสนอ user ให้ `/compact` หรือ `/clear` ก่อนเสมอ** แล้วค่อยเริ่ม VERIFY ใน context ที่โล่ง (สถานะงานอยู่ในไฟล์ `docs/stages/<slug>/` ครบ ไม่หายไปกับ context) — VERIFY เป็นลูปเทส-แก้ที่อาจยาว ต้องมี context เหลือมากพอ; เครื่องอื่นที่ไม่มีคำสั่งนี้ → แนะนำเริ่ม session ใหม่
-1. **เข้าใจจุดประสงค์ + อ่าน baseline:** อ่าน spec/tasks/design + `docs/features/<name>/spec.md` ของ feature ที่ topic แตะ (union ถ้าหลาย feature) → สรุปสิ่งที่ต้อง verify (functional + UX/UI)
-2. **วางแผนเทส → เขียน `test.md`:** ตาม guideline `docs/techstack/<component>/test.md`; ไม่มีก็เสนอวิธี (e2e smoke / integration / manual ฯลฯ) แล้วเขียนแผน — **ครอบทั้ง regression (scenario เดิมใน baseline) + test case ใหม่ (scenario ใน Spec delta)**
-3. **เตรียม local env:** รัน service ที่เกี่ยวข้องตาม `infra.md`
-4. **รันเทสตามแผน:** functional ตาม test-flow ใน spec; FE → e2e smoke (playwright-cli) + ตรวจ UX/UI
-   - **★ contract validation (ถ้ามี `openapi.yaml`):** ยืนยัน implementation จริง = contract ตาม `.warnyin/workflow/api-doc.md` §4 (code-first regen → diff, หรือยิง request จริง → ตรวจ response/status/error ตรง schema); mismatch = ไม่ผ่าน → เข้า fix loop ข้อ 5
-5. **ไม่ผ่าน → แก้ → rerun:** วนจนผ่าน **นับจำนวนรอบ/จำนวนแก้**; ปัญหายาก→`troubleshooting.md`; ถ้านานเกิน→ถาม user (ทีละข้อ + recommended)
-6. **เขียนสรุป `verify.md`:** ผลเทส + รายการแก้ไข + **จำนวนการแก้ไข** + ผล UX/UI
-7. **ปิดงาน:** เสนอเข้า SHIP ด้วย `/warnyin:ship`
-
----
-
-## 5. Output (สร้างที่ `docs/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)
-- [ ] **regression ตาม baseline** — scenario เดิมใน `docs/features/<name>/spec.md` ของ feature ที่แตะ ยังผ่าน (ยกเว้นที่ MODIFIED/REMOVED) + scenario ใน Spec delta ผ่าน
-- [ ] Frontend: **UX/UI verify ผ่าน**
-- [ ] **API contract (ถ้ามี `openapi.yaml`)** — implementation จริงตรง contract (path/schema/status/error/auth); mismatch ถูกแก้จนตรง (ตาม `.warnyin/workflow/api-doc.md`)
-- [ ] ทุกข้อที่ไม่ผ่านถูกแก้จน **verify ผ่านหมด**
-- [ ] `test.md` (แผน) + `verify.md` (สรุป + จำนวนการแก้ไข) เขียนครบ
-- [ ] ปัญหายาก/ซ้ำถูกบันทึก `troubleshooting.md`
-
-ยังไม่ครบ → อยู่ VERIFY ต่อ ห้ามข้ามไป SHIP
+# Stage: VERIFY
+
+> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
+> เป้าหมาย: เป็น **strategy tester** — ยืนยันว่า change ที่ build แล้ว "ทำงานถูกตามจุดประสงค์ของ topic" จริง (functional + UX/UI ถ้าเป็น FE) แก้จนผ่าน
+> **Context profile:** สวมโหมด `review` (`.warnyin/workflow/contexts/review.md`) — session-level posture ของ stage นี้
+
+---
+
+## 1. VERIFY คืออะไร / ใช้เมื่อไหร่
+
+ใช้หลัง BUILD ผ่าน Gate (full build/test เขียว) — VERIFY ทดสอบ **เชิงพฤติกรรม/จุดประสงค์** ในสภาพแวดล้อมจริง (local env)
+ไม่ใช่แค่ unit test ผ่าน แต่ "ของจริงทำงานตามที่ topic ตั้งใจไหม"
+
+> **★ fast-track hook:** ถ้า topic เป็น tier `fast` (จาก `/warnyin:triage`) → **verify-lite** ตาม [fast-track skip-list](../triage.md#fast-track-skip-list) — functional ตาม spec + test เขียว, ข้าม empirical/panel ที่ไม่เกี่ยว; **correctness floor คงไว้ — test ต้องเขียวจริง**. tier `standard`/`large` → flow เต็มด้านล่าง (hook นี้ N/A ไม่ลด bar)
+
+---
+
+## 2. ก่อนเทส — อ่านให้เข้าใจก่อนเสมอ
+
+1. **spec + tasks ทั้งหมด** — `docs/stages/<slug>/tasks/*/spec.md` + `task.md`, `design.md`, `proposal.md`
+   → เข้าใจ **จุดประสงค์ของ topic** และสิ่งที่ต้องยืนยัน (อย่าเทสผ่านๆ โดยไม่เข้าใจ)
+2. **`docs/features/<name>/spec.md` = regression baseline** — อ่าน behavior spec ของ feature ที่ topic แตะ (ดูจาก Spec delta ใน `design.md`); topic แตะหลาย feature → baseline = union ของ spec ทุก feature ที่ delta อ้างถึง; feature ยังไม่มี spec → ข้ามได้ (วิธีเดิม)
+   - **`docs/stages/<slug>/openapi.yaml` (ถ้ามี)** = API contract ที่ต้องยืนยัน — topic ที่แตะ REST API ต้อง verify ว่าโค้ดจริง **ตรง contract** (ดูข้อ 4)
+3. **`docs/techstack/<component>/test.md`** — guideline ว่าเทสยังไง (เช่น frontend: e2e smoke ผ่าน **playwright-cli**)
+   → ถ้า **ไม่มี** guideline → แนะนำว่าควรเทสแบบไหน/วิธีใดได้บ้าง แล้วเขียนแผนลง `test.md`
+4. **`docs/infra.md`** — local env / service ที่ต้องรันเพื่อเทส
+5. **`docs/troubleshooting.md`** — เผื่อปัญหาที่จะเจอเคยถูกแก้แล้ว
+6. **runtime security** (`.warnyin/workflow/roles/security.md` → "Runtime / operational security") — ตอนรันเทส local env ที่มี secret จริง ทบทวน secret isolation / no-egress / identity separation ก่อนปล่อย agent แตะของจริง
+
+---
+
+## 3. หลักการทำงาน (operating principles)
+
+1. **เข้าใจจุดประสงค์ก่อนเทส** — เทสตามเจตนาของ topic ไม่ใช่แค่ให้เขียว **และพฤติกรรมเดิมจาก feature spec** — scenario เดิมใน `docs/features/<name>/spec.md` = regression case (ต้องไม่พัง ยกเว้นที่ MODIFIED/REMOVED ระบุ), scenario ใน Spec delta = test case ใหม่
+2. **เทสในสภาพแวดล้อมจริง (local env)** — รัน service ที่เกี่ยวข้องใน local แล้วเทสตามแผน
+3. **ใช้ guideline จาก `test.md`** ของ techstack; ถ้าไม่มีให้เสนอวิธีเทสที่เหมาะแล้วเขียนแผนเอง
+4. **Frontend → verify UX/UI ด้วย** (ไม่ใช่แค่ functional — ดู layout, state, flow, ความถูกต้องของหน้าจอ)
+5. **ข้อไหน verify ไม่ผ่าน → แก้จนผ่าน (loop)** และ **นับจำนวนการแก้ไข/จำนวนรอบ**
+6. **ปัญหายาก/ซ้ำในขั้นนี้ → บันทึก `docs/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 `.warnyin/workflow/roles/qa.md` (lens: คิดแบบผู้ใช้จริง + คนหาเรื่อง, edge case, regression; checklist ครบทุกข้อ)
+10. **★ investigate-before-edit** (enforce ของ "ห้ามเดา") — ก่อนแก้ไฟล์ที่มีอยู่ ต้องเข้าใจก่อน — **ใครใช้/อ่านไฟล์นี้, schema/contract/สัญญาของมัน, เจตนาเดิม**; แก้โดยไม่เข้าใจ = เดา (กรณีไม่ชัด → ถาม user / อ่านโค้ดที่อ้างถึง ก่อนแก้)
+11. **★ config-protection** (enforce ของ "ห้ามเดา") — ตอน fix loop (ข้อ 5 "แก้จนผ่าน") ห้ามแก้ config (linter/formatter/test threshold) หรือ disable rule **"เพื่อให้ build/test ผ่าน"** แทนการแก้ root cause จริง — "แก้จนผ่าน" ต้องเป็นการแก้ที่ต้นเหตุ ไม่ใช่ลด bar; ถ้า config ผิดจริง แก้ได้แต่ต้องมี **เหตุผลชัด + note** (ไม่ใช่เพื่อเลี่ยง finding)
+
+---
+
+## 4. ลำดับขั้นการทำงาน (process)
+
+0. **★ เช็ค context window ก่อนเริ่ม:** ประเมินว่า context ของ session ปัจจุบันถูกใช้ไปมากน้อยแค่ไหน — ถ้าใช้ไปเยอะหรือ **เกินครึ่ง** → **เสนอ user ให้ `/compact` หรือ `/clear` ก่อนเสมอ** แล้วค่อยเริ่ม VERIFY ใน context ที่โล่ง (สถานะงานอยู่ในไฟล์ `docs/stages/<slug>/` ครบ ไม่หายไปกับ context) — VERIFY เป็นลูปเทส-แก้ที่อาจยาว ต้องมี context เหลือมากพอ; เครื่องอื่นที่ไม่มีคำสั่งนี้ → แนะนำเริ่ม session ใหม่
+1. **เข้าใจจุดประสงค์ + อ่าน baseline:** อ่าน spec/tasks/design + `docs/features/<name>/spec.md` ของ feature ที่ topic แตะ (union ถ้าหลาย feature) → สรุปสิ่งที่ต้อง verify (functional + UX/UI)
+2. **วางแผนเทส → เขียน `test.md`:** ตาม guideline `docs/techstack/<component>/test.md`; ไม่มีก็เสนอวิธี (e2e smoke / integration / manual ฯลฯ) แล้วเขียนแผน — **ครอบทั้ง regression (scenario เดิมใน baseline) + test case ใหม่ (scenario ใน Spec delta)**
+3. **เตรียม local env:** รัน service ที่เกี่ยวข้องตาม `infra.md`
+4. **รันเทสตามแผน:** functional ตาม test-flow ใน spec; FE → e2e smoke (playwright-cli) + ตรวจ UX/UI
+   - **★ contract validation (ถ้ามี `openapi.yaml`):** ยืนยัน implementation จริง = contract ตาม `.warnyin/workflow/api-doc.md` §4 (code-first regen → diff, หรือยิง request จริง → ตรวจ response/status/error ตรง schema); mismatch = ไม่ผ่าน → เข้า fix loop ข้อ 5
+5. **ไม่ผ่าน → แก้ → rerun:** วนจนผ่าน **นับจำนวนรอบ/จำนวนแก้**; ปัญหายาก→`troubleshooting.md`; ถ้านานเกิน→ถาม user (ทีละข้อ + recommended)
+6. **เขียนสรุป `verify.md`:** ผลเทส + รายการแก้ไข + **จำนวนการแก้ไข** + ผล UX/UI
+7. **ปิดงาน:** เสนอเข้า SHIP ด้วย `/warnyin:ship`
+
+---
+
+## 5. Output (สร้างที่ `docs/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)
+- [ ] **regression ตาม baseline** — scenario เดิมใน `docs/features/<name>/spec.md` ของ feature ที่แตะ ยังผ่าน (ยกเว้นที่ MODIFIED/REMOVED) + scenario ใน Spec delta ผ่าน
+- [ ] Frontend: **UX/UI verify ผ่าน**
+- [ ] **API contract (ถ้ามี `openapi.yaml`)** — implementation จริงตรง contract (path/schema/status/error/auth); mismatch ถูกแก้จนตรง (ตาม `.warnyin/workflow/api-doc.md`)
+- [ ] ทุกข้อที่ไม่ผ่านถูกแก้จน **verify ผ่านหมด**
+- [ ] `test.md` (แผน) + `verify.md` (สรุป + จำนวนการแก้ไข) เขียนครบ
+- [ ] ปัญหายาก/ซ้ำถูกบันทึก `troubleshooting.md`
+
+ยังไม่ครบ → อยู่ VERIFY ต่อ ห้ามข้ามไป SHIP

package/src/.warnyin/workflow/triage.md

@@ -1,74 +1,74 @@
-# TRIAGE — ประเมินขนาด change → แนะนำ tier + route (read-only)
-
-> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
-> เป้าหมาย: รับคำอธิบาย change ของ user → ประเมินขนาดเป็น tier `{fast, standard, large}` ตาม rubric (signals + hard-floor) → **แนะนำ route** แล้วหยุด — **ไม่สร้างหรือแก้ไฟล์ใดๆ**
-> ★ ไฟล์นี้ **canonical** ของ rubric — `design.md §7` / `verify.md` / `ship.md` / command adapter ชี้มาที่นี่ (ไม่ inline rubric ซ้ำ)
-
----
-
-## 1. TRIAGE คืออะไร / ใช้เมื่อไหร่
-
-TRIAGE คือโหมด **อ่านอย่างเดียว (read-only)** — ไม่ใช่ stage ใน workflow, ไม่มี gate, ไม่มี output ไฟล์
-ใช้เมื่อ: มี change/request ใหม่แต่ **ยังไม่แน่ใจว่าควรจ่าย ceremony แค่ไหน** — อยากรู้ว่างานนี้ใหญ่แค่ไหน ควรเดิน path ไหน (fast-track / flow เต็ม / ต้อง Discovery ก่อน)
-
-- **ต่างจาก `next`:** triage = ประเมิน **request ใหม่ by size** ; next = route **topic เดิม by stage** — คนละแกน input
-- **ต่างจาก `explore`:** explore ตอบคำถาม/สำรวจ ; triage ตัดสิน tier + route ของ change ที่จะลงมือทำ
-
----
-
-## 2. วิธีประเมิน (rubric — สแกน → ตัดสิน tier เคารพ hard-floor)
-
-### 2A. Tier taxonomy (3 ระดับ 1 มิติ)
-
-| tier | ตัวอย่าง | route ที่แนะนำ |
-|---|---|---|
-| **fast** | bugfix, typo, config tweak, แก้/เพิ่ม wording-guidance สั้น, 1-2 ไฟล์, modify ของเดิม ไม่ cross-cutting | `/warnyin:design` แบบ **fast-track** (skip-list §2C) → build → verify-lite → ship-lite |
-| **standard** | feature ใหม่ขนาดปกติ, modify หลายไฟล์/หลาย component, มี logic ใหม่ | flow เต็มปัจจุบัน (`design` → build → verify → ship) |
-| **large** | greenfield/project ใหม่, cross-cutting หลาย component, mega | **บังคับ `/warnyin:discovery` ก่อน** → design → ... (decompose เต็ม = future) |
-
-### 2B. Signals + Hard-floor + Escalation (judgment heuristic ⚠ ไม่ใช่ ✖)
-
-- **signals ประเมิน tier:** #ไฟล์/#component ที่แตะ · new-vs-modify · greenfield · มี logic/algorithm ใหม่ · dep ใหม่ · UI/ผู้ใช้กระทบ
-- **★ tie-break ก้ำกึ่ง → ปัดขึ้น (fail-safe):** signals เป็น judgment ไม่มี threshold ตายตัว — เคสก้ำกึ่ง fast/standard → **เลือก standard** (ปรัชญาเดียวกับ hard-floor: ระวังไว้ก่อน) เพื่อให้พฤติกรรมก้ำกึ่ง consistent ไม่สุ่ม
-- **★ Hard-floor — บังคับ ≥ standard เสมอ (ไม่ว่าดูเล็กแค่ไหน):** แตะ **(1) auth/authz · (2) data migration/schema · (3) secret/credential · (4) public API/contract (breaking) · (5) security-sensitive (input handling/crypto/permission)** → triage ห้ามแนะนำ fast (**5 หมวด**)
-- **★ Escalation/Downgrade เป็น step (symmetric):**
-  1. **Upgrade (fast→standard/large):** พบว่าใหญ่กว่า/แตะ hard-floor กลางทาง → **เติม artifact ที่ fast-track ข้ามไป** (business.md/proposal-design เต็ม/panel/dry-run/แตก task เพิ่ม) แล้วเดิน flow tier ใหม่ต่อ — topic ไม่ต้องเริ่มใหม่
-  2. **Downgrade (standard→fast):** ถ้าประเมินเกิน (over-size) → ตัด ceremony ที่ยังไม่ทำได้ แต่ **ห้าม downgrade ข้าม hard-floor**
-  3. sizing เป็น **default ที่ปรับได้ทุกเมื่อ ไม่ lock**
-
-> **fast-track skip-list** = ดู section **Fast-track skip-list** ด้านล่าง (§2C canonical)
-
----
-
-## Fast-track skip-list
-
-> fast tier = **ข้าม ceremony ที่ไม่จำเป็น ไม่ใช่ข้าม correctness** (canonical §2C — `design.md §7` / `verify.md` / `ship.md` ชี้ anchor นี้)
-
-| stage | fast-track ทำ | คงไว้ (correctness floor) |
-|---|---|---|
-| DESIGN | ข้าม `business.md`, proposal/design สั้น, **ไม่ panel ไม่ dry-run**, 1 task, model tier `cheap` | spec/acceptance ขั้นต่ำของ task |
-| BUILD | 1 agent (DAG width 1, ไม่ต้อง fan-out) | **full-gate (test เขียว) ยัง blocking** |
-| VERIFY | lite — functional ตาม spec + test เขียว, ข้าม empirical/panel ที่ไม่เกี่ยว | test เขียวจริง |
-| SHIP | lite — promote เฉพาะที่มี (อาจไม่มี learned-rule), archive | archive ครบ + ไม่แตะ rule กลางมั่ว |
-
----
-
-## 3. รูปแบบรายงาน (ตอบในแชทเท่านั้น)
-
-triage **อ่าน input = คำอธิบาย change ของ user** (+ inspect โค้ดที่อ้างถึงได้) → ประเมิน tier ตาม §2A/§2B → **รายงาน: tier + เหตุผล (signals ที่เจอ) + route ที่แนะนำ + คำเตือน hard-floor (ถ้ามี)** → **หยุด ให้ user สั่ง command เอง** (ไม่รัน stage ต่อ — เหมือน `next`)
-
-รูปแบบที่แนะนำ:
-1. **tier ที่ประเมิน** (`fast` / `standard` / `large`)
-2. **เหตุผล** — signals ที่เจอ (#ไฟล์/component, new-vs-modify, logic ใหม่, ฯลฯ) + ถ้าก้ำกึ่งระบุว่าปัดขึ้น standard
-3. **คำเตือน hard-floor (ถ้ามี)** — ระบุหมวดที่ตรง → บังคับ ≥ standard
-4. **route ที่แนะนำ** — command ถัดไป (fast-track / flow เต็ม / Discovery ก่อน)
-5. **หยุด** — เสนอ command ให้ user เป็นคนสั่ง
-
----
-
-## 4. หลักการ (read-only เด็ดขาด)
-
-1. **Read-only เด็ดขาด** — ห้ามสร้าง/แก้/ลบไฟล์ใดๆ; triage แค่ประเมินแล้วรายงาน
-2. **สรุปจาก evidence:** ประเมินจากคำอธิบาย change + โค้ดที่อ้างถึงจริง ไม่เดา; ก้ำกึ่ง → ปัดขึ้น standard (fail-safe)
-3. **เคารพ hard-floor:** แตะหมวดใน §2B → ห้ามแนะนำ fast ไม่ว่าดูเล็กแค่ไหน
-4. **แนะนำแล้วหยุด:** ไม่รัน stage ถัดไปให้เอง — เสนอ command ให้ user เป็นคนสั่ง; sizing เป็น default ที่ escalate/downgrade ได้ทุกเมื่อ (ไม่ lock)
+# TRIAGE — ประเมินขนาด change → แนะนำ tier + route (read-only)
+
+> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
+> เป้าหมาย: รับคำอธิบาย change ของ user → ประเมินขนาดเป็น tier `{fast, standard, large}` ตาม rubric (signals + hard-floor) → **แนะนำ route** แล้วหยุด — **ไม่สร้างหรือแก้ไฟล์ใดๆ**
+> ★ ไฟล์นี้ **canonical** ของ rubric — `design.md §7` / `verify.md` / `ship.md` / command adapter ชี้มาที่นี่ (ไม่ inline rubric ซ้ำ)
+
+---
+
+## 1. TRIAGE คืออะไร / ใช้เมื่อไหร่
+
+TRIAGE คือโหมด **อ่านอย่างเดียว (read-only)** — ไม่ใช่ stage ใน workflow, ไม่มี gate, ไม่มี output ไฟล์
+ใช้เมื่อ: มี change/request ใหม่แต่ **ยังไม่แน่ใจว่าควรจ่าย ceremony แค่ไหน** — อยากรู้ว่างานนี้ใหญ่แค่ไหน ควรเดิน path ไหน (fast-track / flow เต็ม / ต้อง Discovery ก่อน)
+
+- **ต่างจาก `next`:** triage = ประเมิน **request ใหม่ by size** ; next = route **topic เดิม by stage** — คนละแกน input
+- **ต่างจาก `explore`:** explore ตอบคำถาม/สำรวจ ; triage ตัดสิน tier + route ของ change ที่จะลงมือทำ
+
+---
+
+## 2. วิธีประเมิน (rubric — สแกน → ตัดสิน tier เคารพ hard-floor)
+
+### 2A. Tier taxonomy (3 ระดับ 1 มิติ)
+
+| tier | ตัวอย่าง | route ที่แนะนำ |
+|---|---|---|
+| **fast** | bugfix, typo, config tweak, แก้/เพิ่ม wording-guidance สั้น, 1-2 ไฟล์, modify ของเดิม ไม่ cross-cutting | `/warnyin:design` แบบ **fast-track** (skip-list §2C) → build → verify-lite → ship-lite |
+| **standard** | feature ใหม่ขนาดปกติ, modify หลายไฟล์/หลาย component, มี logic ใหม่ | flow เต็มปัจจุบัน (`design` → build → verify → ship) |
+| **large** | greenfield/project ใหม่, cross-cutting หลาย component, mega | **บังคับ `/warnyin:discovery` ก่อน** → design → ... (decompose เต็ม = future) |
+
+### 2B. Signals + Hard-floor + Escalation (judgment heuristic ⚠ ไม่ใช่ ✖)
+
+- **signals ประเมิน tier:** #ไฟล์/#component ที่แตะ · new-vs-modify · greenfield · มี logic/algorithm ใหม่ · dep ใหม่ · UI/ผู้ใช้กระทบ
+- **★ tie-break ก้ำกึ่ง → ปัดขึ้น (fail-safe):** signals เป็น judgment ไม่มี threshold ตายตัว — เคสก้ำกึ่ง fast/standard → **เลือก standard** (ปรัชญาเดียวกับ hard-floor: ระวังไว้ก่อน) เพื่อให้พฤติกรรมก้ำกึ่ง consistent ไม่สุ่ม
+- **★ Hard-floor — บังคับ ≥ standard เสมอ (ไม่ว่าดูเล็กแค่ไหน):** แตะ **(1) auth/authz · (2) data migration/schema · (3) secret/credential · (4) public API/contract (breaking) · (5) security-sensitive (input handling/crypto/permission)** → triage ห้ามแนะนำ fast (**5 หมวด**)
+- **★ Escalation/Downgrade เป็น step (symmetric):**
+  1. **Upgrade (fast→standard/large):** พบว่าใหญ่กว่า/แตะ hard-floor กลางทาง → **เติม artifact ที่ fast-track ข้ามไป** (business.md/proposal-design เต็ม/panel/dry-run/แตก task เพิ่ม) แล้วเดิน flow tier ใหม่ต่อ — topic ไม่ต้องเริ่มใหม่
+  2. **Downgrade (standard→fast):** ถ้าประเมินเกิน (over-size) → ตัด ceremony ที่ยังไม่ทำได้ แต่ **ห้าม downgrade ข้าม hard-floor**
+  3. sizing เป็น **default ที่ปรับได้ทุกเมื่อ ไม่ lock**
+
+> **fast-track skip-list** = ดู section **Fast-track skip-list** ด้านล่าง (§2C canonical)
+
+---
+
+## Fast-track skip-list
+
+> fast tier = **ข้าม ceremony ที่ไม่จำเป็น ไม่ใช่ข้าม correctness** (canonical §2C — `design.md §7` / `verify.md` / `ship.md` ชี้ anchor นี้)
+
+| stage | fast-track ทำ | คงไว้ (correctness floor) |
+|---|---|---|
+| DESIGN | ข้าม `business.md`, proposal/design สั้น, **ไม่ panel ไม่ dry-run**, 1 task, model tier `cheap` | spec/acceptance ขั้นต่ำของ task |
+| BUILD | 1 agent (DAG width 1, ไม่ต้อง fan-out) | **full-gate (test เขียว) ยัง blocking** |
+| VERIFY | lite — functional ตาม spec + test เขียว, ข้าม empirical/panel ที่ไม่เกี่ยว | test เขียวจริง |
+| SHIP | lite — promote เฉพาะที่มี (อาจไม่มี learned-rule), archive | archive ครบ + ไม่แตะ rule กลางมั่ว |
+
+---
+
+## 3. รูปแบบรายงาน (ตอบในแชทเท่านั้น)
+
+triage **อ่าน input = คำอธิบาย change ของ user** (+ inspect โค้ดที่อ้างถึงได้) → ประเมิน tier ตาม §2A/§2B → **รายงาน: tier + เหตุผล (signals ที่เจอ) + route ที่แนะนำ + คำเตือน hard-floor (ถ้ามี)** → **หยุด ให้ user สั่ง command เอง** (ไม่รัน stage ต่อ — เหมือน `next`)
+
+รูปแบบที่แนะนำ:
+1. **tier ที่ประเมิน** (`fast` / `standard` / `large`)
+2. **เหตุผล** — signals ที่เจอ (#ไฟล์/component, new-vs-modify, logic ใหม่, ฯลฯ) + ถ้าก้ำกึ่งระบุว่าปัดขึ้น standard
+3. **คำเตือน hard-floor (ถ้ามี)** — ระบุหมวดที่ตรง → บังคับ ≥ standard
+4. **route ที่แนะนำ** — command ถัดไป (fast-track / flow เต็ม / Discovery ก่อน)
+5. **หยุด** — เสนอ command ให้ user เป็นคนสั่ง
+
+---
+
+## 4. หลักการ (read-only เด็ดขาด)
+
+1. **Read-only เด็ดขาด** — ห้ามสร้าง/แก้/ลบไฟล์ใดๆ; triage แค่ประเมินแล้วรายงาน
+2. **สรุปจาก evidence:** ประเมินจากคำอธิบาย change + โค้ดที่อ้างถึงจริง ไม่เดา; ก้ำกึ่ง → ปัดขึ้น standard (fail-safe)
+3. **เคารพ hard-floor:** แตะหมวดใน §2B → ห้ามแนะนำ fast ไม่ว่าดูเล็กแค่ไหน
+4. **แนะนำแล้วหยุด:** ไม่รัน stage ถัดไปให้เอง — เสนอ command ให้ user เป็นคนสั่ง; sizing เป็น default ที่ escalate/downgrade ได้ทุกเมื่อ (ไม่ lock)