@warnyin/agents 0.14.0 → 0.16.0

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)

package/src/AGENTS.md

@@ -1,54 +1,54 @@
-# AGENTS.md
-
-มาตรฐานเปิดสำหรับ AI agent ทุกเจ้าที่อ่านไฟล์นี้ (Codex, Antigravity, และเครื่องมืออื่นที่รองรับ `AGENTS.md`)
-
-## repo นี้คืออะไร
-
-repo มาตรฐานกลางของ **ways of work** สำหรับทุกโปรเจกต์ — เดินงานผ่าน 5 stage:
-
-```
-Discovery (optional) ──▶ DESIGN ──▶ BUILD ──▶ VERIFY ──▶ SHIP
-```
-
-## กฎสำคัญ: ทำตาม playbook กลางเสมอ
-
-แก่นของแต่ละ stage คือ **single source of truth** อยู่ที่ `.warnyin/workflow/stages/`
-ก่อนทำงานใน stage ใด ให้เปิดอ่านไฟล์ playbook ของ stage นั้นแล้วทำตามอย่างเคร่งครัด
-
-| Stage | playbook | สถานะ |
-|---|---|---|
-| Discovery | `.warnyin/workflow/stages/discovery.md` | ✅ พร้อมใช้ |
-| DESIGN | `.warnyin/workflow/stages/design.md` | ✅ พร้อมใช้ |
-| BUILD | `.warnyin/workflow/stages/build.md` | ✅ พร้อมใช้ |
-| VERIFY | `.warnyin/workflow/stages/verify.md` | ✅ พร้อมใช้ |
-| SHIP | `.warnyin/workflow/stages/ship.md` | ✅ พร้อมใช้ |
-
-## วิธีเริ่ม
-
-0. ครั้งแรกในโปรเจกต์ (docs/ ยังว่าง) → ทำตาม `.warnyin/workflow/init.md` เพื่อวิเคราะห์โปรเจกต์ + เติม `docs/` ก่อน
-1. อ่าน `.warnyin/workflow/README.md` เพื่อเข้าใจภาพรวมและโครงสร้าง
-2. งานใหม่ → copy `.warnyin/template/stages/[topic]/` เป็น `docs/stages/<slug>/`
-3. รัน stage ตามลำดับ โดยทำตาม playbook ของแต่ละ stage
-4. output ของงานเก็บใน `docs/stages/<slug>/`, ความรู้ถาวรระดับโปรเจกต์อยู่ใน `docs/`
-
-## สำรวจโดยไม่สร้าง artifact (EXPLORE)
-
-อยากถาม/สำรวจข้อมูลเฉยๆ โดยไม่เปิด topic → ทำตาม `.warnyin/workflow/explore.md`
-(read-only เด็ดขาด — ไม่สร้าง/แก้ไฟล์ใดๆ จบที่คำตอบในแชท)
-
-## เช็คงานค้าง / หาขั้นตอนถัดไป (NEXT)
-
-อยากรู้ว่ามีงานอะไรค้างและควรไปต่อยังไง → ทำตาม `.warnyin/workflow/next.md`
-(สแกน `docs/stages/*` ระบุ stage ปัจจุบันจาก artifact จริง + gate ที่ขาด — read-only ไม่แก้ไฟล์)
-
-## รัน Discovery
-
-ทำตาม `.warnyin/workflow/stages/discovery.md` — เริ่มอ่าน `docs/project.md`, ตี scope กว้าง→แคบ,
-ถามทีละข้อพร้อมเสนอคำตอบที่แนะนำ, คำถามที่ตอบได้ด้วยโค้ดให้ไปอ่านโค้ดเอง,
-เขียน output ลง `docs/stages/<slug>/discovery.md` และ `research.md`
-
-## การ resolve playbook (local-first → global)
-- path `.warnyin/workflow/...` / `.warnyin/template/...`: หาในโปรเจกต์ `./.warnyin/` ก่อน ไม่มี → `~/.warnyin/` (global install)
-- ถ้ายังไม่มี `docs/stages/` (global mode โปรเจกต์ใหม่) → รัน `/warnyin:init` ก่อน (สร้าง workspace)
-
-> หมายเหตุ: global root doc ของ Codex/Antigravity ไม่รองรับรอบนี้ — convention นี้มีผลเฉพาะ per-project path
+# AGENTS.md
+
+มาตรฐานเปิดสำหรับ AI agent ทุกเจ้าที่อ่านไฟล์นี้ (Codex, Antigravity, และเครื่องมืออื่นที่รองรับ `AGENTS.md`)
+
+## repo นี้คืออะไร
+
+repo มาตรฐานกลางของ **ways of work** สำหรับทุกโปรเจกต์ — เดินงานผ่าน 5 stage:
+
+```
+Discovery (optional) ──▶ DESIGN ──▶ BUILD ──▶ VERIFY ──▶ SHIP
+```
+
+## กฎสำคัญ: ทำตาม playbook กลางเสมอ
+
+แก่นของแต่ละ stage คือ **single source of truth** อยู่ที่ `.warnyin/workflow/stages/`
+ก่อนทำงานใน stage ใด ให้เปิดอ่านไฟล์ playbook ของ stage นั้นแล้วทำตามอย่างเคร่งครัด
+
+| Stage | playbook | สถานะ |
+|---|---|---|
+| Discovery | `.warnyin/workflow/stages/discovery.md` | ✅ พร้อมใช้ |
+| DESIGN | `.warnyin/workflow/stages/design.md` | ✅ พร้อมใช้ |
+| BUILD | `.warnyin/workflow/stages/build.md` | ✅ พร้อมใช้ |
+| VERIFY | `.warnyin/workflow/stages/verify.md` | ✅ พร้อมใช้ |
+| SHIP | `.warnyin/workflow/stages/ship.md` | ✅ พร้อมใช้ |
+
+## วิธีเริ่ม
+
+0. ครั้งแรกในโปรเจกต์ (docs/ ยังว่าง) → ทำตาม `.warnyin/workflow/init.md` เพื่อวิเคราะห์โปรเจกต์ + เติม `docs/` ก่อน
+1. อ่าน `.warnyin/workflow/README.md` เพื่อเข้าใจภาพรวมและโครงสร้าง
+2. งานใหม่ → copy `.warnyin/template/stages/[topic]/` เป็น `docs/stages/<slug>/`
+3. รัน stage ตามลำดับ โดยทำตาม playbook ของแต่ละ stage
+4. output ของงานเก็บใน `docs/stages/<slug>/`, ความรู้ถาวรระดับโปรเจกต์อยู่ใน `docs/`
+
+## สำรวจโดยไม่สร้าง artifact (EXPLORE)
+
+อยากถาม/สำรวจข้อมูลเฉยๆ โดยไม่เปิด topic → ทำตาม `.warnyin/workflow/explore.md`
+(read-only เด็ดขาด — ไม่สร้าง/แก้ไฟล์ใดๆ จบที่คำตอบในแชท)
+
+## เช็คงานค้าง / หาขั้นตอนถัดไป (NEXT)
+
+อยากรู้ว่ามีงานอะไรค้างและควรไปต่อยังไง → ทำตาม `.warnyin/workflow/next.md`
+(สแกน `docs/stages/*` ระบุ stage ปัจจุบันจาก artifact จริง + gate ที่ขาด — read-only ไม่แก้ไฟล์)
+
+## รัน Discovery
+
+ทำตาม `.warnyin/workflow/stages/discovery.md` — เริ่มอ่าน `docs/project.md`, ตี scope กว้าง→แคบ,
+ถามทีละข้อพร้อมเสนอคำตอบที่แนะนำ, คำถามที่ตอบได้ด้วยโค้ดให้ไปอ่านโค้ดเอง,
+เขียน output ลง `docs/stages/<slug>/discovery.md` และ `research.md`
+
+## การ resolve playbook (local-first → global)
+- path `.warnyin/workflow/...` / `.warnyin/template/...`: หาในโปรเจกต์ `./.warnyin/` ก่อน ไม่มี → `~/.warnyin/` (global install)
+- ถ้ายังไม่มี `docs/stages/` (global mode โปรเจกต์ใหม่) → รัน `/warnyin:init` ก่อน (สร้าง workspace)
+
+> หมายเหตุ: global root doc ของ Codex/Antigravity ไม่รองรับรอบนี้ — convention นี้มีผลเฉพาะ per-project path