@warnyin/agents 0.15.0 → 0.17.0

package/src/.warnyin/workflow/contexts/README.md

@@ -1,51 +1,51 @@
-# Contexts — context profile กลางของ workflow
-
-> **แก่นกลาง tool-agnostic** — context card แต่ละใบคือ "posture ของทั้ง session" ในโหมดหนึ่ง
-> AI ทุกเจ้าใช้ไฟล์ชุดเดียวกัน: อ่านตอนเริ่ม stage เพื่อ set โหมดของ session แล้วทำงานตาม playbook เดิม
-
-## หลักการ
-
-- **context = session-level posture** — วิธีคิด/ท่าทีรวมของ "ทั้ง session": ตอนนี้กำลังสำรวจ, กำลังสร้าง, หรือกำลังตรวจ
-- **role = task-level lens** ([`roles/`](../roles/README.md)) — มุมมอง/checklist ของ "หนึ่งบทบาทต่อหนึ่งงาน" (BA, Developer, QA, ...)
-- คนละมิติ ใช้คู่กันได้: เช่น session อยู่โหมด `build` (posture) + sub-agent สวม role `Developer` (lens ของงานนั้น)
-- context **ไม่ duplicate** checklist ของ stage playbook/role card — ชี้กลับ playbook เสมอ (single source of truth)
-
-## ตาราง context ↔ stage
-
-| Stage playbook | Context ที่เข้าคู่ | เหตุผล |
-|---|---|---|
-| [`discovery.md`](../stages/discovery.md) | `research` | สำรวจ/เข้าใจก่อนตัดสิน |
-| [`design.md`](../stages/design.md) | `research` + `build` | ต้น = research (propose), ปลาย = build (แตก task) |
-| [`build.md`](../stages/build.md) | `build` | ลงมือสร้าง vertical slice |
-| [`verify.md`](../stages/verify.md) | `review` | ตรวจ/ยืนยันด้วยการรันจริง |
-| [`ship.md`](../stages/ship.md) | `review` | ตรวจความครบก่อนส่งมอบ/promote |
-
-## วิธี activate (manual)
-
-- **AI หลัก:** ตอนเริ่ม stage → เปิด playbook stage นั้น เจอ callout "Context profile" ชี้มา → อ่าน context card → สวม posture แล้วทำงานตาม playbook
-- **User สั่งตรง:** บอกโหมดได้ชัดๆ เช่น "อยู่โหมด research" / "สวม build context" → AI อ่าน card ที่ตรง
-- playbook ทุก stage มี callout ชี้กลับมาที่ context ที่เข้าคู่ (reference graph วนกลับ ไม่ duplicate)
-
-## โครงของ context card ทุกใบ
-
-1. **Mindset** — วิธีคิดรวมของ session โหมดนี้ (2–4 บรรทัด)
-2. **Do / Don't** — bullet สั้น 2 ฝั่ง: ทำ vs ห้าม
-3. **Tool preference** — เครื่องมือที่ควรใช้ / เลี่ยง (read-only vs edit vs run) + **Model tier** (generic: deepest/balanced/cheap)
-4. **ใช้คู่ stage ไหน** — ชี้ playbook stage ที่เข้าคู่ (→ ลิงก์)
-
-> เพิ่ม context ใหม่ = เพิ่มไฟล์ที่นี่ + ใส่ callout ใน playbook stage ที่เข้าคู่ + อัปเดตตารางด้านบน
-> (เก็บให้บาง opinionated — 3 context พอ; อย่าให้ไหลเป็น catalog)
-
-## Model tier (generic — harness ตีเป็นรุ่นจริงเอง)
-
-แต่ละ context แนะนำ **model tier** ใน section "Tool preference" เพื่อคุม token/cost ตาม posture:
-
-| Context | Tier | งาน |
-|---|---|---|
-| `research` | `deepest reasoning` | สำรวจ / architecture / ตัดสินใจ trade-off |
-| `build` | `balanced` (worker เชิงกลไก → `cheap`) | implement vertical slice ตาม spec |
-| `review` | `balanced+` | ตรวจ/จับ bug — ไม่ลด (พลาดแพงกว่า token) |
-
-> **tool-agnostic:** ใช้ vocab generic **ไม่ผูกชื่อรุ่น/ผลิตภัณฑ์ของ harness ใด ๆ** — แต่ละ harness map tier → รุ่นเอง (เทียบแนวทาง model selection ของ harness เช่นไฟล์ rules ฝั่ง performance); เป็น **guidance** ไม่ใช่ enforce
-
-> **per-task ใน BUILD (เพิ่มจาก per-context):** นอกจาก tier ระดับ context ด้านบน BUILD ยังกำหนด **model tier ต่อ task** ได้ผ่าน field `Model tier` ใน `task.md` — ใช้ subset `{cheap, balanced, deepest}` (ไม่ระบุ = `balanced` ตาม context build); mapping: mechanical/scaffold/config → `cheap` · implement ตาม spec ปกติ → `balanced` · logic หนัก/security/algorithm/ไม่เคยทำ → `deepest`. orchestrator ใน command (adapter) map tier→รุ่นจริง แล้วส่งเข้า `build-wave` per task — payload คง generic ตามเดิม
+# Contexts — context profile กลางของ workflow
+
+> **แก่นกลาง tool-agnostic** — context card แต่ละใบคือ "posture ของทั้ง session" ในโหมดหนึ่ง
+> AI ทุกเจ้าใช้ไฟล์ชุดเดียวกัน: อ่านตอนเริ่ม stage เพื่อ set โหมดของ session แล้วทำงานตาม playbook เดิม
+
+## หลักการ
+
+- **context = session-level posture** — วิธีคิด/ท่าทีรวมของ "ทั้ง session": ตอนนี้กำลังสำรวจ, กำลังสร้าง, หรือกำลังตรวจ
+- **role = task-level lens** ([`roles/`](../roles/README.md)) — มุมมอง/checklist ของ "หนึ่งบทบาทต่อหนึ่งงาน" (BA, Developer, QA, ...)
+- คนละมิติ ใช้คู่กันได้: เช่น session อยู่โหมด `build` (posture) + sub-agent สวม role `Developer` (lens ของงานนั้น)
+- context **ไม่ duplicate** checklist ของ stage playbook/role card — ชี้กลับ playbook เสมอ (single source of truth)
+
+## ตาราง context ↔ stage
+
+| Stage playbook | Context ที่เข้าคู่ | เหตุผล |
+|---|---|---|
+| [`discovery.md`](../stages/discovery.md) | `research` | สำรวจ/เข้าใจก่อนตัดสิน |
+| [`design.md`](../stages/design.md) | `research` + `build` | ต้น = research (propose), ปลาย = build (แตก task) |
+| [`build.md`](../stages/build.md) | `build` | ลงมือสร้าง vertical slice |
+| [`verify.md`](../stages/verify.md) | `review` | ตรวจ/ยืนยันด้วยการรันจริง |
+| [`ship.md`](../stages/ship.md) | `review` | ตรวจความครบก่อนส่งมอบ/promote |
+
+## วิธี activate (manual)
+
+- **AI หลัก:** ตอนเริ่ม stage → เปิด playbook stage นั้น เจอ callout "Context profile" ชี้มา → อ่าน context card → สวม posture แล้วทำงานตาม playbook
+- **User สั่งตรง:** บอกโหมดได้ชัดๆ เช่น "อยู่โหมด research" / "สวม build context" → AI อ่าน card ที่ตรง
+- playbook ทุก stage มี callout ชี้กลับมาที่ context ที่เข้าคู่ (reference graph วนกลับ ไม่ duplicate)
+
+## โครงของ context card ทุกใบ
+
+1. **Mindset** — วิธีคิดรวมของ session โหมดนี้ (2–4 บรรทัด)
+2. **Do / Don't** — bullet สั้น 2 ฝั่ง: ทำ vs ห้าม
+3. **Tool preference** — เครื่องมือที่ควรใช้ / เลี่ยง (read-only vs edit vs run) + **Model tier** (generic: deepest/balanced/cheap)
+4. **ใช้คู่ stage ไหน** — ชี้ playbook stage ที่เข้าคู่ (→ ลิงก์)
+
+> เพิ่ม context ใหม่ = เพิ่มไฟล์ที่นี่ + ใส่ callout ใน playbook stage ที่เข้าคู่ + อัปเดตตารางด้านบน
+> (เก็บให้บาง opinionated — 3 context พอ; อย่าให้ไหลเป็น catalog)
+
+## Model tier (generic — harness ตีเป็นรุ่นจริงเอง)
+
+แต่ละ context แนะนำ **model tier** ใน section "Tool preference" เพื่อคุม token/cost ตาม posture:
+
+| Context | Tier | งาน |
+|---|---|---|
+| `research` | `deepest reasoning` | สำรวจ / architecture / ตัดสินใจ trade-off |
+| `build` | `balanced` (worker เชิงกลไก → `cheap`) | implement vertical slice ตาม spec |
+| `review` | `balanced+` | ตรวจ/จับ bug — ไม่ลด (พลาดแพงกว่า token) |
+
+> **tool-agnostic:** ใช้ vocab generic **ไม่ผูกชื่อรุ่น/ผลิตภัณฑ์ของ harness ใด ๆ** — แต่ละ harness map tier → รุ่นเอง (เทียบแนวทาง model selection ของ harness เช่นไฟล์ rules ฝั่ง performance); เป็น **guidance** ไม่ใช่ enforce
+
+> **per-task ใน BUILD (เพิ่มจาก per-context):** นอกจาก tier ระดับ context ด้านบน BUILD ยังกำหนด **model tier ต่อ task** ได้ผ่าน field `Model tier` ใน `task.md` — ใช้ subset `{cheap, balanced, deepest}` (ไม่ระบุ = `balanced` ตาม context build); mapping: mechanical/scaffold/config → `cheap` · implement ตาม spec ปกติ → `balanced` · logic หนัก/security/algorithm/ไม่เคยทำ → `deepest`. orchestrator ใน command (adapter) map tier→รุ่นจริง แล้วส่งเข้า `build-wave` per task — payload คง generic ตามเดิม

package/src/.warnyin/workflow/contexts/build.md

@@ -1,25 +1,25 @@
-# Context — build (โหมดลงมือสร้าง vertical slice)
-
-> session-level posture · playbook: `.warnyin/workflow/stages/*`
-
-## Mindset
-ส่งมอบ vertical slice ที่ทำงานจริง end-to-end — ทำตาม spec/standard/rule ของ task
-slice เล็กจบในตัว, "เขียว" ต้องเขียวจริงจากการรัน ไม่ใช่คาดว่าเขียว
-
-## Do / Don't
-- ✅ ทำตาม task spec ครบทุกข้อ ไม่เกิน/ไม่ต่ำ
-- ✅ อ่าน `troubleshooting.md` ก่อนแก้ error
-- ✅ reuse shared component ใน standard ก่อนเขียนใหม่
-- ✅ commit เล็ก โฟกัสทีละ slice
-- ❌ หลุด scope ของ task
-- ❌ เดา spec — กลับไปอ่าน design / ถาม
-- ❌ แก้ rule กลาง (note ไว้ รอ SHIP)
-
-## Tool preference
-- **ควรใช้:** Edit / Write / Bash, sub-agent fan-out, `build-wave`
-- **เลี่ยง:** แก้นอก scope task, แตะ rule/standard กลางใน `docs/`
-- **Model tier:** `balanced` (orchestrator/main loop ที่ตัดสินใจ integrate); **fan-out worker per task** ตาม field `Model tier` ใน `task.md` (subset `{cheap, balanced, deepest}`; ไม่ระบุ = `balanced`): mechanical/scaffold/config → `cheap` · implement ตาม spec ปกติ → `balanced` · logic หนัก/security/algorithm/ไม่เคยทำ → `deepest` (คุม token/cost ต่อ agent — ดู `contexts/README.md` §"Model tier")
-
-## ใช้คู่ stage ไหน
-- ปลาย DESIGN (แตก task) → [`stages/design.md`](../stages/design.md)
-- BUILD → [`stages/build.md`](../stages/build.md)
+# Context — build (โหมดลงมือสร้าง vertical slice)
+
+> session-level posture · playbook: `.warnyin/workflow/stages/*`
+
+## Mindset
+ส่งมอบ vertical slice ที่ทำงานจริง end-to-end — ทำตาม spec/standard/rule ของ task
+slice เล็กจบในตัว, "เขียว" ต้องเขียวจริงจากการรัน ไม่ใช่คาดว่าเขียว
+
+## Do / Don't
+- ✅ ทำตาม task spec ครบทุกข้อ ไม่เกิน/ไม่ต่ำ
+- ✅ อ่าน `troubleshooting.md` ก่อนแก้ error
+- ✅ reuse shared component ใน standard ก่อนเขียนใหม่
+- ✅ commit เล็ก โฟกัสทีละ slice
+- ❌ หลุด scope ของ task
+- ❌ เดา spec — กลับไปอ่าน design / ถาม
+- ❌ แก้ rule กลาง (note ไว้ รอ SHIP)
+
+## Tool preference
+- **ควรใช้:** Edit / Write / Bash, sub-agent fan-out, `build-wave`
+- **เลี่ยง:** แก้นอก scope task, แตะ rule/standard กลางใน `docs/`
+- **Model tier:** `balanced` (orchestrator/main loop ที่ตัดสินใจ integrate); **fan-out worker per task** ตาม field `Model tier` ใน `task.md` (subset `{cheap, balanced, deepest}`; ไม่ระบุ = `balanced`): mechanical/scaffold/config → `cheap` · implement ตาม spec ปกติ → `balanced` · logic หนัก/security/algorithm/ไม่เคยทำ → `deepest` (คุม token/cost ต่อ agent — ดู `contexts/README.md` §"Model tier")
+
+## ใช้คู่ stage ไหน
+- ปลาย DESIGN (แตก task) → [`stages/design.md`](../stages/design.md)
+- BUILD → [`stages/build.md`](../stages/build.md)

package/src/.warnyin/workflow/contexts/research.md

@@ -1,25 +1,25 @@
-# Context — research (โหมดสำรวจ/เข้าใจก่อนตัดสิน)
-
-> session-level posture · playbook: `.warnyin/workflow/stages/*`
-
-## Mindset
-เข้าใจก่อนตัดสิน — กว้างก่อนลึก ตั้งคำถาม > รีบสรุป
-สำรวจของจริง (โค้ด/เอกสาร) ไม่เดาจากความเคยชิน; สะสม evidence ให้พอก่อนเสนอทางเลือก
-
-## Do / Don't
-- ✅ อ่านโค้ด/เอกสารจริง ก่อนสรุปทุกครั้ง
-- ✅ ถามทีละข้อ + เสนอคำตอบให้ user ยืนยัน
-- ✅ บันทึก evidence (path/บรรทัด) ที่อ้างอิง
-- ❌ เดา/สรุปจากความเคยชินโดยไม่ยืนยัน
-- ❌ แก้ไฟล์ production ระหว่างสำรวจ
-- ❌ รีบสรุปก่อน scope ชัด
-
-## Tool preference
-- **ควรใช้:** read-only — Read / Grep / Glob / fast-context, `/warnyin:explore`
-- **เลี่ยง:** Edit / Write โค้ดจริง, คำสั่งที่เปลี่ยน state
-- **Model tier:** `deepest reasoning` — สำรวจ/architecture/ตัดสินใจ trade-off = งานคิดหนัก คุ้มใช้ตัวลึกสุด
-
-## ใช้คู่ stage ไหน
-- Discovery → [`stages/discovery.md`](../stages/discovery.md)
-- ช่วงต้น DESIGN (เก็บ context ก่อน propose) → [`stages/design.md`](../stages/design.md)
-- เช็คงานค้าง → [`next.md`](../next.md)
+# Context — research (โหมดสำรวจ/เข้าใจก่อนตัดสิน)
+
+> session-level posture · playbook: `.warnyin/workflow/stages/*`
+
+## Mindset
+เข้าใจก่อนตัดสิน — กว้างก่อนลึก ตั้งคำถาม > รีบสรุป
+สำรวจของจริง (โค้ด/เอกสาร) ไม่เดาจากความเคยชิน; สะสม evidence ให้พอก่อนเสนอทางเลือก
+
+## Do / Don't
+- ✅ อ่านโค้ด/เอกสารจริง ก่อนสรุปทุกครั้ง
+- ✅ ถามทีละข้อ + เสนอคำตอบให้ user ยืนยัน
+- ✅ บันทึก evidence (path/บรรทัด) ที่อ้างอิง
+- ❌ เดา/สรุปจากความเคยชินโดยไม่ยืนยัน
+- ❌ แก้ไฟล์ production ระหว่างสำรวจ
+- ❌ รีบสรุปก่อน scope ชัด
+
+## Tool preference
+- **ควรใช้:** read-only — Read / Grep / Glob / fast-context, `/warnyin:explore`
+- **เลี่ยง:** Edit / Write โค้ดจริง, คำสั่งที่เปลี่ยน state
+- **Model tier:** `deepest reasoning` — สำรวจ/architecture/ตัดสินใจ trade-off = งานคิดหนัก คุ้มใช้ตัวลึกสุด
+
+## ใช้คู่ stage ไหน
+- Discovery → [`stages/discovery.md`](../stages/discovery.md)
+- ช่วงต้น DESIGN (เก็บ context ก่อน propose) → [`stages/design.md`](../stages/design.md)
+- เช็คงานค้าง → [`next.md`](../next.md)

package/src/.warnyin/workflow/contexts/review.md

@@ -1,25 +1,25 @@
-# Context — review (โหมดตรวจ/ยืนยันก่อนปล่อย)
-
-> session-level posture · playbook: `.warnyin/workflow/stages/*`
-
-## Mindset
-หาจุดพลาดก่อนปล่อย — skeptical, ไม่เชื่อว่าผ่านจนกว่าจะรันจริง
-ยืนยันด้วยหลักฐาน (test/verify เขียวจริง) ไม่ใช่คำสัญญาในโค้ด
-
-## Do / Don't
-- ✅ รัน test / verify จริง ดูผลด้วยตา
-- ✅ ไล่ acceptance ทีละข้อ เทียบกับ spec
-- ✅ ตรวจ edge case + security
-- ❌ เชื่อว่าผ่านโดยไม่รัน
-- ❌ ปล่อย issue ระดับ CRITICAL / HIGH
-- ❌ แก้เยอะระหว่าง review (note ไว้ ให้กลับไป BUILD)
-
-## Tool preference
-- **ควรใช้:** Read + Bash (รัน test/verify), reviewer sub-agents, `/code-review` `/security-review`
-- **เลี่ยง:** เขียน feature ใหม่ระหว่าง review, แก้ scope กว้างๆ
-- **Model tier:** `balanced+` — skeptical จับ bug/regression/edge case = **ไม่ควรลด tier** (พลาดของจริงแพงกว่าค่า token)
-
-## ใช้คู่ stage ไหน
-- VERIFY → [`stages/verify.md`](../stages/verify.md)
-- SHIP (ตรวจความครบก่อนส่งมอบ) → [`stages/ship.md`](../stages/ship.md)
-- DESIGN review panel → [`stages/design.md`](../stages/design.md)
+# Context — review (โหมดตรวจ/ยืนยันก่อนปล่อย)
+
+> session-level posture · playbook: `.warnyin/workflow/stages/*`
+
+## Mindset
+หาจุดพลาดก่อนปล่อย — skeptical, ไม่เชื่อว่าผ่านจนกว่าจะรันจริง
+ยืนยันด้วยหลักฐาน (test/verify เขียวจริง) ไม่ใช่คำสัญญาในโค้ด
+
+## Do / Don't
+- ✅ รัน test / verify จริง ดูผลด้วยตา
+- ✅ ไล่ acceptance ทีละข้อ เทียบกับ spec
+- ✅ ตรวจ edge case + security
+- ❌ เชื่อว่าผ่านโดยไม่รัน
+- ❌ ปล่อย issue ระดับ CRITICAL / HIGH
+- ❌ แก้เยอะระหว่าง review (note ไว้ ให้กลับไป BUILD)
+
+## Tool preference
+- **ควรใช้:** Read + Bash (รัน test/verify), reviewer sub-agents, `/code-review` `/security-review`
+- **เลี่ยง:** เขียน feature ใหม่ระหว่าง review, แก้ scope กว้างๆ
+- **Model tier:** `balanced+` — skeptical จับ bug/regression/edge case = **ไม่ควรลด tier** (พลาดของจริงแพงกว่าค่า token)
+
+## ใช้คู่ stage ไหน
+- VERIFY → [`stages/verify.md`](../stages/verify.md)
+- SHIP (ตรวจความครบก่อนส่งมอบ) → [`stages/ship.md`](../stages/ship.md)
+- DESIGN review panel → [`stages/design.md`](../stages/design.md)

package/src/.warnyin/workflow/explore.md

@@ -1,32 +1,32 @@
-# EXPLORE — สำรวจ/ตอบคำถามแบบ read-only (ไม่สร้าง artifact)
-
-> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
-> เป้าหมาย: ตอบคำถาม/สำรวจข้อมูล โค้ด และเอกสารของโปรเจกต์แบบ **grounded** โดย **ไม่สร้างหรือแก้ไฟล์ใดๆ** — จบที่คำตอบในแชท
-
----
-
-## 1. EXPLORE คืออะไร / ใช้เมื่อไหร่
-
-EXPLORE คือโหมด **อ่านอย่างเดียว (read-only)** — ไม่ใช่ stage ใน workflow, ไม่มี gate, ไม่มี output ไฟล์
-
-- ใช้เมื่อ: อยากเข้าใจข้อมูล/โค้ด/พฤติกรรมระบบ, ถามเช็คความเข้าใจ, หาว่าอะไรอยู่ตรงไหน, เปรียบเทียบทางเลือกแบบเร็วๆ — **ยังไม่แน่ใจว่าจะกลายเป็นงานจริงหรือไม่**
-- ต่างจาก Discovery: Discovery เป็น stage ที่ผลิต `discovery.md` + `research.md` เพื่อเข้า DESIGN — EXPLORE แค่ตอบ ไม่จดอะไรลงไฟล์
-
----
-
-## 2. Input ที่อ่านเพื่อ ground ตัวเอง (เท่าที่เกี่ยวกับคำถาม — ไม่ต้องครบทุกไฟล์)
-
-1. `docs/project.md` — โปรเจกต์นี้คืออะไร เป้าหมาย ขอบเขต
-2. `docs/codemap/index.md` — แผนที่โค้ด (ไปอ่านโค้ดจริงต่อได้)
-3. `docs/rule.md`, `docs/infra.md`, `docs/features/*`, `docs/techstack/*` — ตามที่คำถามแตะ
-4. `docs/stages/context.md` + topic ใน `docs/stages/` และ `achieved/` ที่ใกล้เคียง — งานที่เคยทำ/กำลังทำ
-
----
-
-## 3. หลักการทำงาน
-
-1. **Read-only เด็ดขาด:** ใช้เฉพาะการอ่าน/ค้น (read, grep, glob, sub-agent แบบ read-only) — **ห้ามสร้าง แก้ หรือลบไฟล์ใดๆ** รวมถึงไฟล์ใน `docs/stages/` และ `docs/`
-2. **โค้ดตอบได้ → ไปอ่านโค้ด:** อ้างอิงคำตอบด้วย `path:line` หรือชื่อไฟล์จริงเสมอ ไม่ตอบจากการเดา
-3. **คำถามกว้าง → fan-out:** ถ้าต้องกวาดหลายพื้นที่ ให้กระจาย sub-agent แบบ read-only (เช่น Explore) ขนานกัน แล้วสังเคราะห์คำตอบเดียว
-4. **ตอบในแชทเท่านั้น:** สรุปกระชับ ชี้ไฟล์/บรรทัดให้ user ไปต่อเองได้
-5. **เจอประเด็นที่ควรเก็บเป็นงาน → เสนอ ไม่ทำเอง:** ถ้าการสำรวจชี้ว่าควรเปิด topic จริง ให้เสนอ `/warnyin:discovery <topic>` (scope ยังกว้าง) หรือ `/warnyin:design <slug> <change>` (scope ชัดแล้ว) — ให้ user เป็นคนตัดสินใจ
+# EXPLORE — สำรวจ/ตอบคำถามแบบ read-only (ไม่สร้าง artifact)
+
+> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
+> เป้าหมาย: ตอบคำถาม/สำรวจข้อมูล โค้ด และเอกสารของโปรเจกต์แบบ **grounded** โดย **ไม่สร้างหรือแก้ไฟล์ใดๆ** — จบที่คำตอบในแชท
+
+---
+
+## 1. EXPLORE คืออะไร / ใช้เมื่อไหร่
+
+EXPLORE คือโหมด **อ่านอย่างเดียว (read-only)** — ไม่ใช่ stage ใน workflow, ไม่มี gate, ไม่มี output ไฟล์
+
+- ใช้เมื่อ: อยากเข้าใจข้อมูล/โค้ด/พฤติกรรมระบบ, ถามเช็คความเข้าใจ, หาว่าอะไรอยู่ตรงไหน, เปรียบเทียบทางเลือกแบบเร็วๆ — **ยังไม่แน่ใจว่าจะกลายเป็นงานจริงหรือไม่**
+- ต่างจาก Discovery: Discovery เป็น stage ที่ผลิต `discovery.md` + `research.md` เพื่อเข้า DESIGN — EXPLORE แค่ตอบ ไม่จดอะไรลงไฟล์
+
+---
+
+## 2. Input ที่อ่านเพื่อ ground ตัวเอง (เท่าที่เกี่ยวกับคำถาม — ไม่ต้องครบทุกไฟล์)
+
+1. `docs/project.md` — โปรเจกต์นี้คืออะไร เป้าหมาย ขอบเขต
+2. `docs/codemap/index.md` — แผนที่โค้ด (ไปอ่านโค้ดจริงต่อได้)
+3. `docs/rule.md`, `docs/infra.md`, `docs/features/*`, `docs/techstack/*` — ตามที่คำถามแตะ
+4. `docs/stages/context.md` + topic ใน `docs/stages/` และ `achieved/` ที่ใกล้เคียง — งานที่เคยทำ/กำลังทำ
+
+---
+
+## 3. หลักการทำงาน
+
+1. **Read-only เด็ดขาด:** ใช้เฉพาะการอ่าน/ค้น (read, grep, glob, sub-agent แบบ read-only) — **ห้ามสร้าง แก้ หรือลบไฟล์ใดๆ** รวมถึงไฟล์ใน `docs/stages/` และ `docs/`
+2. **โค้ดตอบได้ → ไปอ่านโค้ด:** อ้างอิงคำตอบด้วย `path:line` หรือชื่อไฟล์จริงเสมอ ไม่ตอบจากการเดา
+3. **คำถามกว้าง → fan-out:** ถ้าต้องกวาดหลายพื้นที่ ให้กระจาย sub-agent แบบ read-only (เช่น Explore) ขนานกัน แล้วสังเคราะห์คำตอบเดียว
+4. **ตอบในแชทเท่านั้น:** สรุปกระชับ ชี้ไฟล์/บรรทัดให้ user ไปต่อเองได้
+5. **เจอประเด็นที่ควรเก็บเป็นงาน → เสนอ ไม่ทำเอง:** ถ้าการสำรวจชี้ว่าควรเปิด topic จริง ให้เสนอ `/warnyin:discovery <topic>` (scope ยังกว้าง) หรือ `/warnyin:design <slug> <change>` (scope ชัดแล้ว) — ให้ user เป็นคนตัดสินใจ

package/src/.warnyin/workflow/feedback.md

@@ -0,0 +1,212 @@
+# FEEDBACK — เปิด GitHub Issue แจ้ง feedback ที่ warnyin/warnyin-agents
+
+> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
+> เป้าหมาย: รับข้อมูลจาก user → สัมภาษณ์สั้น → เรียบเรียง title + body → **preview + confirm** → ยิงด้วย `gh` หรือ fallback URL → คืน link ให้ user
+
+---
+
+## 1. FEEDBACK คืออะไร / ใช้เมื่อไหร่
+
+FEEDBACK ช่วยให้ผู้ใช้ปลายทางของ Warnyin Standard Workflow **เปิด GitHub issue** กลับมาที่ทีมได้โดยไม่ต้องออกจาก flow
+
+- ใช้เมื่อ: อยากแจ้ง **ปัญหา (Bug) / ฟีเจอร์ใหม่ที่อยากได้ (Feature) / จุดที่อยากปรับปรุง (Improvement)**
+- ปลายทาง: repo `warnyin/warnyin-agents` เสมอ (hardcode)
+- ต่างจากการเขียน issue เอง: AI ช่วยสัมภาษณ์สั้น เรียบเรียงรูปแบบมาตรฐาน และจัดการ title prefix + label ให้อัตโนมัติ
+
+---
+
+## 2. Input ที่รับ
+
+- **seed argument** (`$ARGUMENTS`) — ถ้า user ส่งมา ใช้เป็นจุดเริ่มต้น (อาจเป็นประเภท เช่น "Bug" หรือข้อความ feedback สั้นๆ)
+- **คำตอบจาก user** — ข้อมูลที่ถามสัมภาษณ์เท่านั้น (**ห้ามดึง session context อัตโนมัติ** — กัน path/secret leak ขึ้น public issue)
+- ถ้า user ไม่ส่ง seed → ถามประเภทก่อน
+
+---
+
+## 3. Flow หลัก (ทำตามลำดับ)
+
+### ขั้นที่ 1 — เลือกประเภท
+
+ถามหรืออ่านจาก seed ว่าเป็น:
+
+| ประเภท | Title prefix | Label (best-effort) |
+|---|---|---|
+| Bug | `[Bug]` | `bug` |
+| Feature | `[Feature]` | `enhancement` |
+| Improvement | `[Improvement]` | `enhancement` |
+
+ถ้า seed ชัดเจนพอ (เช่น "Bug" หรือข้อความที่บ่งชี้ประเภท) → ยืนยันกับ user แล้วข้ามไปขั้นที่ 2 ได้เลย
+
+### ขั้นที่ 2 — สัมภาษณ์สั้น (ตามประเภท)
+
+**Bug:**
+1. สรุปปัญหา (อะไรผิดปกติ?)
+2. ขั้นตอน reproduce (ทำอะไรแล้วเกิดปัญหา?)
+3. ผลที่คาด vs ผลที่เกิดจริง
+4. เวอร์ชัน/สภาพแวดล้อม (workflow version, OS, node — **ถามเฉพาะถ้า user อยากระบุ** ไม่บังคับ)
+5. หมายเหตุเพิ่มเติม (optional)
+
+**Feature:**
+1. ปัญหา/ความต้องการ (อยากได้อะไรเพิ่ม?)
+2. ข้อเสนอ (อยากได้อะไร ทำงานยังไง?)
+3. คุณค่า/ใครได้ประโยชน์
+4. ทางเลือกที่เคยลอง (optional)
+
+**Improvement:**
+1. จุดที่อยากปรับ (อะไรที่รู้สึกว่าควรดีกว่านี้?)
+2. เหตุผล/ปัญหาปัจจุบัน
+3. ผลที่คาดหลังปรับ
+
+> **กฎ privacy (D4):** ใช้เฉพาะข้อมูลที่ user ให้ในการสัมภาษณ์ — **ห้ามแปะ error/โค้ด/path จาก session ลง body โดยไม่ได้รับอนุญาต** เว้นแต่ user พิมพ์ให้เองหรือสั่งชัดว่า "ใส่ error นี้ด้วย"
+
+### ขั้นที่ 3 — เรียบเรียง title + body
+
+**Title:** `<prefix> <สรุปสั้นๆ 1 บรรทัด>`
+ตัวอย่าง: `[Bug] workflow verify ล้มเหลวเมื่อไม่มี git remote`
+
+**Body:** markdown template ตามประเภท
+
+สำหรับ **Bug:**
+```
+## สรุปปัญหา
+<สรุป>
+
+## ขั้นตอน Reproduce
+1. <ขั้นตอน>
+2. ...
+
+## ผลที่คาด
+<คาดหวัง>
+
+## ผลที่เกิดจริง
+<ที่เกิดขึ้นจริง>
+
+## สภาพแวดล้อม
+- Workflow version: <ถ้ามี>
+- OS: <ถ้ามี>
+- Node: <ถ้ามี>
+
+## หมายเหตุ
+<เพิ่มเติม ถ้ามี>
+
+---
+*สร้างผ่าน `/warnyin:feedback:issue`*
+```
+
+สำหรับ **Feature:**
+```
+## ปัญหา / ความต้องการ
+<ปัญหา>
+
+## ข้อเสนอ
+<อยากได้อะไร ทำงานยังไง>
+
+## คุณค่า / ใครได้ประโยชน์
+<คุณค่า>
+
+## ทางเลือกที่เคยลอง
+<ถ้ามี>
+
+---
+*สร้างผ่าน `/warnyin:feedback:issue`*
+```
+
+สำหรับ **Improvement:**
+```
+## จุดที่อยากปรับ
+<จุดที่อยากปรับ>
+
+## เหตุผล / ปัญหาปัจจุบัน
+<ปัญหา>
+
+## ผลที่คาดหลังปรับ
+<ผลที่คาด>
+
+---
+*สร้างผ่าน `/warnyin:feedback:issue`*
+```
+
+---
+
+## 4. Detect Ladder — เลือก path ยิง issue
+
+เดินตามลำดับนี้เสมอ:
+
+```
+1. มี gh ใน PATH ไหม?
+   └─ ไม่มี → fallback URL (แจ้งเหตุผล: "ไม่พบ gh CLI")
+
+2. gh auth status ผ่านไหม?
+   └─ ไม่ผ่าน → fallback URL (แจ้งเหตุผล: "ยังไม่ได้ login gh")
+
+3. พร้อม → ยิง gh issue create (ขั้นที่ 5)
+```
+
+**ไม่สอน/ติดตั้ง gh ให้** — แค่ detect แล้ว fallback
+
+---
+
+## 5. Confirm Gate (บังคับ — D5)
+
+**ก่อนยิงทุกกรณี** แสดง preview ให้ user ดูก่อน:
+
+```
+📋 Preview issue ที่จะส่ง:
+
+**Title:** [Bug] workflow verify ล้มเหลวเมื่อไม่มี git remote
+
+**Body:**
+---
+## สรุปปัญหา
+...
+---
+
+ยืนยันส่ง issue นี้? (ใช่ / แก้ไข / ยกเลิก)
+```
+
+- **ใช่ / ยืนยัน** → ยิง
+- **แก้ไข** → รับข้อมูลเพิ่ม แล้วแสดง preview ใหม่
+- **ยกเลิก** → หยุด ไม่ยิง
+
+**ห้ามยิงก่อน user ยืนยัน** — ไม่มีข้อยกเว้น
+
+---
+
+## 6. ยิง issue
+
+### Path สำเร็จ (มี gh + login แล้ว)
+
+```bash
+gh issue create \
+  --repo warnyin/warnyin-agents \
+  --title "<prefix> <สรุป>" \
+  --body "<body>" \
+  --label <label>
+```
+
+ถ้า `--label` fail เพราะ permission (non-collaborator) → **retry ยิงใหม่โดยไม่มี `--label`** แล้วแจ้ง user ว่า maintainer จะ label ทีหลัง
+
+คืน URL ของ issue ที่สร้าง
+
+### Path Fallback (ไม่มี gh หรือไม่ได้ login)
+
+สร้าง URL พร้อมข้อมูล (urlencode title + body + labels):
+
+```
+https://github.com/warnyin/warnyin-agents/issues/new?title=<urlenc>&body=<urlenc>&labels=<urlenc>
+```
+
+แจ้ง user ว่า:
+- เหตุผลที่ degrade (ไม่มี gh หรือ ยังไม่ได้ login)
+- ให้เปิด URL นี้ใน browser เพื่อส่ง issue
+
+---
+
+## 7. กฎที่ต้องเคร่งครัด
+
+1. **ไม่ดึง session context เองโดยไม่ได้รับอนุญาต** — body ประกอบจากข้อมูลที่ user ให้เท่านั้น
+2. **Confirm gate บังคับ** — preview ก่อนยิงทุกกรณี ไม่มีข้อยกเว้น
+3. **Footer ไม่ใส่ path/secret/ข้อมูลเครื่อง** — มีแค่ `*สร้างผ่าน /warnyin:feedback:issue*`
+4. **repo hardcode** `warnyin/warnyin-agents` — ไม่ยิงไป repo อื่น
+5. **title prefix บังคับ** — `[Bug]` / `[Feature]` / `[Improvement]` ขึ้นต้น title เสมอ
+6. **label best-effort** — fail เงียบได้ retry ไม่มี label แล้วแจ้ง user