@warnyin/agents 0.16.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 เป็นคนตัดสินใจ