@warnyin/agents 0.9.1 → 0.10.0

package/src/.warnyin/workflow/init.md

@@ -1,125 +1,125 @@
-# INIT — วิเคราะห์โปรเจกต์ + เติม docs/ ครั้งแรก
-
-> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
-> เป้าหมาย: ทำให้ `docs/` สะท้อนโปรเจกต์จริง — เพื่อให้ทุก stage (Discovery→SHIP) เริ่มจากความรู้ที่ถูกต้อง ไม่ใช่โครงว่างเปล่า
-
-> ⚠️ **Deliverable ของ INIT = ไฟล์จริงที่ถูกเขียนลงดิสก์ใน `docs/`**
-> การวิเคราะห์แล้วสรุปในแชทอย่างเดียว **ถือว่ายังไม่จบงาน** — INIT จะจบได้ก็ต่อเมื่อทุกไฟล์ในตาราง §4 ถูก write ลง `docs/` จริงและผ่าน gate §5
-
----
-
-## 1. INIT คืออะไร / ใช้เมื่อไหร่
-
-ใช้ **ครั้งแรกหลังติดตั้ง workflow** ลงโปรเจกต์ (`npx github:warnyin/warnyin-agents`)
-หรือเมื่อ `docs/` ยังว่าง/ล้าสมัยจนใช้อ้างอิงไม่ได้ — INIT ไม่ใช่ stage ของงาน แต่เป็นการ **ปูพื้นความรู้** ให้ workflow ทำงานได้เต็มประสิทธิภาพ
-
----
-
-## 2. หลักการทำงาน (operating principles)
-
-1. **โค้ดตอบได้ → อ่านโค้ดเอง ห้ามเดา** — structure, techstack, convention, วิธี build/test, infra วิเคราะห์จาก **โค้ดจริง + config จริง** เท่านั้น
-2. **ข้อมูลธุรกิจโค้ดตอบไม่ได้ → สัมภาษณ์ user ผ่าน role lens เฉพาะทาง** — เป้าหมายโปรเจกต์ ลูกค้า ขอบเขต ความสำคัญ: AI หลัก **สวม lens ของ BA** (`.warnyin/workflow/roles/ba.md`) และ **PO** (`.warnyin/workflow/roles/po.md`) ใช้ checklist ของทั้งสองเป็นชุดคำถาม — **ถามทีละข้อ + เสนอคำตอบแนะนำทุกครั้ง** (เดาจาก README/โค้ดเป็น recommended answer ให้ user แค่ยืนยัน/แก้)
-   - role ที่ต้องคุยกับ user เป็น **lens เสมอ ไม่ใช่ sub-agent** (sub-agent คุยกับ user ไม่ได้) — fan-out sub-agent ใช้ได้เฉพาะงานวิเคราะห์โค้ด read-only (ข้อ 5)
-   - ถ้าติดตั้ง skill `product-management` ไว้ (ดู `/warnyin:install-skill po`) → หยิบมาเสริมมุมตอนตั้งคำถาม scope/priority ได้
-3. **เสนอ summary ก่อนเขียน** — สรุปสิ่งที่วิเคราะห์ได้ + รายการไฟล์ docs/ ที่จะเขียน ให้ user ยืนยัน **ครั้งเดียว** แล้วจึงเขียนจริง
-4. **ไฟล์ docs/ ที่มีเนื้อหาอยู่แล้ว → เติม/อัปเดต ไม่เขียนทับทิ้ง** — ของเดิมของ user มีค่าเสมอ
-5. **วิเคราะห์หลาย component ขนานได้** — fan-out sub-agent (read-only) หนึ่งตัวต่อหนึ่ง component; เครื่องที่ไม่มี sub-agent → วิเคราะห์ทีละ component ด้วยหลักการเดียวกัน
-6. **ไม่แน่ใจ → ระบุว่า "ยังว่าง รอเติม" ชัดเจน** — ห้ามแต่งเนื้อหาขึ้นเองเพื่อให้ไฟล์ดูเต็ม
-7. **เขียนไฟล์จริงเสมอ ห้ามจบแค่สรุปในแชท** — หลัง user ยืนยัน summary ต้อง write ทุกไฟล์ในตาราง §4 ลง `docs/` ด้วย (copy template → เติมเนื้อหา); วิเคราะห์เสร็จแล้วไม่เขียนไฟล์ = งานล้มเหลว
-
----
-
-## 3. ลำดับขั้นการทำงาน (process)
-
-1. **สแกนภาพรวม:** โครงสร้าง repo, package manifest, ภาษา/framework, แบ่งเป็น **component** อะไรบ้าง (เช่น api-service, admin-console)
-2. **วิเคราะห์ลึกต่อ component (ขนานได้, read-only):** โครงสร้างโฟลเดอร์/โมดูล, pattern/convention ที่ใช้จริงในโค้ด, วิธี build/test ที่มีอยู่
-3. **วิเคราะห์ infra:** docker/compose, env, service ที่ต้องรันสำหรับ local dev
-4. **สัมภาษณ์ user เติมส่วนที่โค้ดตอบไม่ได้ (สวม BA + PO lens):**
-   - **ก่อนถาม → สแกนสิ่งที่มีอยู่ก่อนเสมอ:** README, `docs/project.md` เดิม, comment/config ในโค้ด — เอามาเป็น recommended answer; **ถามเฉพาะช่องที่ยัง "ขาดหาย" จริง** ไม่ถามซ้ำสิ่งที่หาคำตอบได้เอง
-   - **สวม BA lens** (`.warnyin/workflow/roles/ba.md`) ไล่ checklist: ปัญหาจริง/ใครเจ็บ, as-is→to-be, edge case ของ process, ข้อมูล/เจ้าของ, ข้อจำกัด (กฎหมาย/ระบบเดิม), acceptance วัดได้ไหม
-   - **สวม PO lens** (`.warnyin/workflow/roles/po.md`) ไล่ checklist: persona หลัก, success metric ที่วัดได้, MVP เล็กสุด, priority (must/should/could), why-now, scope-out
-   - ถาม **ทีละข้อ + เสนอคำตอบแนะนำทุกครั้ง** (AskUserQuestion) — เป็น lens ของ AI หลัก **ห้าม fan-out sub-agent มาสัมภาษณ์** (คุยกับ user ไม่ได้)
-   - ถ้าติดตั้ง `product-management` skill ไว้ → ใช้เสริมมุม scope/priority
-   - คำตอบที่ได้ → ใช้เติม `docs/project.md` (เป้าหมาย/ลูกค้า/ขอบเขต) และ `rule.md` ของแต่ละ component (กฎที่ user สั่ง)
-5. **เสนอ summary → user ยืนยันครั้งเดียว**
-6. **เขียนไฟล์จริงลง `docs/` ให้ครบตาราง §4 (ขั้นบังคับ ห้ามข้าม)** — ทำตามกลไก 6.1–6.4 นี้:
-
-   **6.1 ไฟล์ root** — copy template แล้วเติม:
-   ```
-   mkdir -p docs
-   cp .warnyin/template/docs/project.md         docs/project.md
-   cp .warnyin/template/docs/infra.md           docs/infra.md
-   cp .warnyin/template/docs/rule.md            docs/rule.md
-   cp .warnyin/template/docs/troubleshooting.md docs/troubleshooting.md
-   ```
-   - ไฟล์ไหนมีอยู่แล้วใน `docs/` → **ห้าม `cp` ทับ** ให้เปิดอ่านแล้ว Edit เติมแทน
-   - `project.md` → เติมจากผลสัมภาษณ์ user (ข้อ 4) · `infra.md` → เติมจาก config จริง (ข้อ 3) · `rule.md`/`troubleshooting.md` → วางโครงหัวข้อ ใส่ `<!-- ยังว่าง รอเติม -->` ในส่วนที่ยังไม่มีข้อมูล
-
-   **6.2 โฟลเดอร์ component** — วนทำ **ทุก component** ที่ได้จากข้อ 1 (สมมติชื่อจริง `<name>`):
-   ```
-   cp -R ".warnyin/template/docs/techstack/[component]" "docs/techstack/<name>"
-   ```
-   - ทำซ้ำคำสั่งนี้หนึ่งครั้งต่อหนึ่ง component (เช่น `api-service`, `admin-console`) — **rename เป็นชื่อจริงเสมอ**
-   - หลัง copy ครบ → ต้อง **ไม่มี** โฟลเดอร์ `docs/techstack/[component]` (ที่มีวงเล็บ) หลงเหลือ; ถ้ามีให้ลบทิ้ง
-
-   **6.3 เติมเนื้อหา 5 ไฟล์ในแต่ละ component** ด้วย Write/Edit (อิงผลวิเคราะห์ข้อ 2):
-   - `about.md` (component คืออะไร/ภาษา/framework) · `structure.md` (โครงโฟลเดอร์) · `standard.md` (convention ที่พบจริง + ยืนยัน user) · `rule.md` (กฎที่ user สั่ง — ถามก่อน ห้ามเดา) · `test.md` (framework/คำสั่งเทส)
-   - ส่วนที่ข้อมูลไม่พอ → ใส่ `<!-- ยังว่าง รอเติม -->` ห้ามแต่ง
-
-   **6.4 codemap** — สร้าง `docs/codemap/` ตาม playbook `.warnyin/workflow/codemap.md` (token-lean) อย่างน้อยต้องมี `index.md`
-
-7. **Verify ว่าเขียนจริง:** รัน `find docs -type f` เทียบกับตาราง §4 — ทุกแถวต้องมีไฟล์จริง, ทุก component มีครบ 5 ไฟล์, ไม่มีโฟลเดอร์/ไฟล์ที่ยังมี `[component]` (วงเล็บ) หลงเหลือ
-8. **รายงานปิดท้าย:** ส่วนไหนยังว่าง/ไม่แน่ใจ ให้ user เติมภายหลัง → พร้อมเริ่มงานแรกด้วย `/warnyin:discovery` หรือ `/warnyin:design`
-
----
-
-## 4. Output (เขียน/เติมที่ `docs/`)
-
-> โฟลเดอร์ component จริงให้ copy จาก template `.warnyin/template/docs/techstack/[component]/` เป็นชื่อจริง (เช่น `api-service/`) — ห้ามทิ้งโฟลเดอร์ `[component]` ว่างไว้เฉยๆ โดยไม่สร้างของจริง
-
-| ไฟล์ | เนื้อหา | แหล่งข้อมูล |
-|---|---|---|
-| `docs/project.md` | โปรเจกต์คืออะไร เป้าหมาย ลูกค้า ขอบเขต | สัมภาษณ์ user (+ README เดิมเป็น recommended) |
-| `docs/techstack/<component>/about.md` | component นี้คืออะไร ทำหน้าที่อะไร | โค้ดจริง |
-| `docs/techstack/<component>/structure.md` | โครงสร้างโฟลเดอร์/โมดูล | โค้ดจริง |
-| `docs/techstack/<component>/standard.md` | pattern/convention ที่พบจริงในโค้ด (ยืนยันกับ user) | โค้ดจริง + user |
-| `docs/techstack/<component>/rule.md` | กฎที่ user ต้องการบังคับ (ถามก่อน ห้ามเดา) | user |
-| `docs/techstack/<component>/test.md` | วิธีเทสที่ใช้อยู่ (framework, คำสั่ง, e2e) | โค้ด/config จริง |
-| `docs/codemap/` | แผนที่โค้ดทั้งชุด — สร้างตาม playbook `.warnyin/workflow/codemap.md` (token-lean) | โค้ดจริง |
-| `docs/infra.md` | local env: service ที่ต้องรัน, วิธีรัน, env vars | config จริง |
-| `docs/rule.md`, `docs/troubleshooting.md` | วางโครงหัวข้อ รอเติมระหว่างใช้งานจริง | — |
-
----
-
-## 4.1 Source map — `project` / `infra` / `rule` หาจากไหนใน codebase
-
-> หลัก: §2 ข้อ 1 **"โค้ดตอบได้ → อ่านเอง"** · §2 ข้อ 2 **"ตอบไม่ได้ → สัมภาษณ์"** — 3 ไฟล์นี้คาบเส้น จึงระบุแหล่งให้ชัด ก่อนจะไปถาม user
-
-### `infra.md` — ขุดจาก config จริงได้เกือบทั้งไฟล์ ✅
-| field | หาจากไฟล์ไหน |
-|---|---|
-| Service ที่ต้องรัน | `docker-compose.yml`/`compose.yaml`, `Dockerfile`, `.devcontainer/`, `Procfile`, k8s/helm manifests, `Makefile` |
-| วิธีรัน local | `package.json` scripts (`dev`/`start`), `Makefile` targets, `turbo.json`/`nx.json`, `.nvmrc`/`.node-version`, README ส่วน "Getting Started" |
-| Env vars | `.env.example`/`.env.sample`, env schema ในโค้ด (zod/envalid), `environment:` ใน compose, จุดที่อ้าง `process.env.*`/`os.environ` — **อ่านชื่อ+ความหมาย ห้ามดูดค่า secret จริง** |
-| staging/prod | `.github/workflows/`, `vercel.json`, `fly.toml`, terraform, deploy scripts |
-
-### `rule.md` (global) — โค้ดให้แค่ recommended, เจตนาต้องถาม ⚠️
-- **derive เป็น recommended ได้:** linter/formatter (`eslint.config.*`, `.prettierrc`, `.editorconfig`), `tsconfig` strict flags, pre-commit (`.husky/`, `lefthook`, `.pre-commit-config`), CI gates ใน workflows, `commitlint`, `CONTRIBUTING.md` / `CLAUDE.md` / `AGENTS.md` เดิม
-- **ต้องถาม user:** กฎที่ "อยากบังคับ" แต่ config ยังไม่ enforce — โค้ดบอกได้แค่ "ตอนนี้ enforce อะไร" ไม่ใช่ "อยากให้ enforce อะไร"
-- ตาม template `rule.md`: SHIP เป็นคน promote กฎเข้ามา — ตอน INIT แค่วางโครง + ใส่ recommended ที่ derive ได้ ไม่ต้องเค้นเยอะ
-
-### `project.md` — โค้ดตอบไม่ได้ เป็นงานสัมภาษณ์ (BA/PO lens) 🗣️
-- **derive เป็น recommended ได้:** ชื่อ/คำอธิบายสั้นจาก `package.json` `description` + repo name + README บรรทัดแรก · persona/ขอบเขตจาก README/landing/comment
-- **ต้องสัมภาษณ์เท่านั้น:** เป้าหมาย, success metric, scope-out, why-now — โค้ดไม่มีทางรู้
-
----
-
-## 5. Gate → จบ INIT เมื่อ
-
-- [ ] **ไฟล์ทุกแถวในตาราง §4 ถูกเขียนลง `docs/` จริง** (ยืนยันด้วย `find docs -type f`) — ไม่มีแถวไหนเหลือแค่ในแชท
-- [ ] ไม่มีโฟลเดอร์ชื่อ `[component]` (มีวงเล็บ) หลงเหลือ — ถูก copy เป็นชื่อ component จริงครบทุกตัว
-- [ ] `docs/project.md` มีเป้าหมาย/ลูกค้า/ขอบเขต ที่ user ยืนยันแล้ว
-- [ ] `docs/techstack/` ครบทุก component ที่พบ (about + structure + standard + test)
-- [ ] `docs/codemap/index.md` + `docs/infra.md` ตรงกับโค้ด/config จริง
-- [ ] ทุกเนื้อหามาจากโค้ดจริงหรือคำยืนยันของ user — **ไม่มีการเดา**; ส่วนที่ไม่แน่ใจระบุ "ยังว่าง รอเติม" ชัดเจน
-- [ ] user รับทราบรายการที่ยังว่าง
+# INIT — วิเคราะห์โปรเจกต์ + เติม docs/ ครั้งแรก
+
+> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
+> เป้าหมาย: ทำให้ `docs/` สะท้อนโปรเจกต์จริง — เพื่อให้ทุก stage (Discovery→SHIP) เริ่มจากความรู้ที่ถูกต้อง ไม่ใช่โครงว่างเปล่า
+
+> ⚠️ **Deliverable ของ INIT = ไฟล์จริงที่ถูกเขียนลงดิสก์ใน `docs/`**
+> การวิเคราะห์แล้วสรุปในแชทอย่างเดียว **ถือว่ายังไม่จบงาน** — INIT จะจบได้ก็ต่อเมื่อทุกไฟล์ในตาราง §4 ถูก write ลง `docs/` จริงและผ่าน gate §5
+
+---
+
+## 1. INIT คืออะไร / ใช้เมื่อไหร่
+
+ใช้ **ครั้งแรกหลังติดตั้ง workflow** ลงโปรเจกต์ (`npx github:warnyin/warnyin-agents`)
+หรือเมื่อ `docs/` ยังว่าง/ล้าสมัยจนใช้อ้างอิงไม่ได้ — INIT ไม่ใช่ stage ของงาน แต่เป็นการ **ปูพื้นความรู้** ให้ workflow ทำงานได้เต็มประสิทธิภาพ
+
+---
+
+## 2. หลักการทำงาน (operating principles)
+
+1. **โค้ดตอบได้ → อ่านโค้ดเอง ห้ามเดา** — structure, techstack, convention, วิธี build/test, infra วิเคราะห์จาก **โค้ดจริง + config จริง** เท่านั้น
+2. **ข้อมูลธุรกิจโค้ดตอบไม่ได้ → สัมภาษณ์ user ผ่าน role lens เฉพาะทาง** — เป้าหมายโปรเจกต์ ลูกค้า ขอบเขต ความสำคัญ: AI หลัก **สวม lens ของ BA** (`.warnyin/workflow/roles/ba.md`) และ **PO** (`.warnyin/workflow/roles/po.md`) ใช้ checklist ของทั้งสองเป็นชุดคำถาม — **ถามทีละข้อ + เสนอคำตอบแนะนำทุกครั้ง** (เดาจาก README/โค้ดเป็น recommended answer ให้ user แค่ยืนยัน/แก้)
+   - role ที่ต้องคุยกับ user เป็น **lens เสมอ ไม่ใช่ sub-agent** (sub-agent คุยกับ user ไม่ได้) — fan-out sub-agent ใช้ได้เฉพาะงานวิเคราะห์โค้ด read-only (ข้อ 5)
+   - ถ้าติดตั้ง skill `product-management` ไว้ (ดู `/warnyin:install-skill po`) → หยิบมาเสริมมุมตอนตั้งคำถาม scope/priority ได้
+3. **เสนอ summary ก่อนเขียน** — สรุปสิ่งที่วิเคราะห์ได้ + รายการไฟล์ docs/ ที่จะเขียน ให้ user ยืนยัน **ครั้งเดียว** แล้วจึงเขียนจริง
+4. **ไฟล์ docs/ ที่มีเนื้อหาอยู่แล้ว → เติม/อัปเดต ไม่เขียนทับทิ้ง** — ของเดิมของ user มีค่าเสมอ
+5. **วิเคราะห์หลาย component ขนานได้** — fan-out sub-agent (read-only) หนึ่งตัวต่อหนึ่ง component; เครื่องที่ไม่มี sub-agent → วิเคราะห์ทีละ component ด้วยหลักการเดียวกัน
+6. **ไม่แน่ใจ → ระบุว่า "ยังว่าง รอเติม" ชัดเจน** — ห้ามแต่งเนื้อหาขึ้นเองเพื่อให้ไฟล์ดูเต็ม
+7. **เขียนไฟล์จริงเสมอ ห้ามจบแค่สรุปในแชท** — หลัง user ยืนยัน summary ต้อง write ทุกไฟล์ในตาราง §4 ลง `docs/` ด้วย (copy template → เติมเนื้อหา); วิเคราะห์เสร็จแล้วไม่เขียนไฟล์ = งานล้มเหลว
+
+---
+
+## 3. ลำดับขั้นการทำงาน (process)
+
+1. **สแกนภาพรวม:** โครงสร้าง repo, package manifest, ภาษา/framework, แบ่งเป็น **component** อะไรบ้าง (เช่น api-service, admin-console)
+2. **วิเคราะห์ลึกต่อ component (ขนานได้, read-only):** โครงสร้างโฟลเดอร์/โมดูล, pattern/convention ที่ใช้จริงในโค้ด, วิธี build/test ที่มีอยู่
+3. **วิเคราะห์ infra:** docker/compose, env, service ที่ต้องรันสำหรับ local dev
+4. **สัมภาษณ์ user เติมส่วนที่โค้ดตอบไม่ได้ (สวม BA + PO lens):**
+   - **ก่อนถาม → สแกนสิ่งที่มีอยู่ก่อนเสมอ:** README, `docs/project.md` เดิม, comment/config ในโค้ด — เอามาเป็น recommended answer; **ถามเฉพาะช่องที่ยัง "ขาดหาย" จริง** ไม่ถามซ้ำสิ่งที่หาคำตอบได้เอง
+   - **สวม BA lens** (`.warnyin/workflow/roles/ba.md`) ไล่ checklist: ปัญหาจริง/ใครเจ็บ, as-is→to-be, edge case ของ process, ข้อมูล/เจ้าของ, ข้อจำกัด (กฎหมาย/ระบบเดิม), acceptance วัดได้ไหม
+   - **สวม PO lens** (`.warnyin/workflow/roles/po.md`) ไล่ checklist: persona หลัก, success metric ที่วัดได้, MVP เล็กสุด, priority (must/should/could), why-now, scope-out
+   - ถาม **ทีละข้อ + เสนอคำตอบแนะนำทุกครั้ง** (AskUserQuestion) — เป็น lens ของ AI หลัก **ห้าม fan-out sub-agent มาสัมภาษณ์** (คุยกับ user ไม่ได้)
+   - ถ้าติดตั้ง `product-management` skill ไว้ → ใช้เสริมมุม scope/priority
+   - คำตอบที่ได้ → ใช้เติม `docs/project.md` (เป้าหมาย/ลูกค้า/ขอบเขต) และ `rule.md` ของแต่ละ component (กฎที่ user สั่ง)
+5. **เสนอ summary → user ยืนยันครั้งเดียว**
+6. **เขียนไฟล์จริงลง `docs/` ให้ครบตาราง §4 (ขั้นบังคับ ห้ามข้าม)** — ทำตามกลไก 6.1–6.4 นี้:
+
+   **6.1 ไฟล์ root** — copy template แล้วเติม:
+   ```
+   mkdir -p docs
+   cp .warnyin/template/docs/project.md         docs/project.md
+   cp .warnyin/template/docs/infra.md           docs/infra.md
+   cp .warnyin/template/docs/rule.md            docs/rule.md
+   cp .warnyin/template/docs/troubleshooting.md docs/troubleshooting.md
+   ```
+   - ไฟล์ไหนมีอยู่แล้วใน `docs/` → **ห้าม `cp` ทับ** ให้เปิดอ่านแล้ว Edit เติมแทน
+   - `project.md` → เติมจากผลสัมภาษณ์ user (ข้อ 4) · `infra.md` → เติมจาก config จริง (ข้อ 3) · `rule.md`/`troubleshooting.md` → วางโครงหัวข้อ ใส่ `<!-- ยังว่าง รอเติม -->` ในส่วนที่ยังไม่มีข้อมูล
+
+   **6.2 โฟลเดอร์ component** — วนทำ **ทุก component** ที่ได้จากข้อ 1 (สมมติชื่อจริง `<name>`):
+   ```
+   cp -R ".warnyin/template/docs/techstack/[component]" "docs/techstack/<name>"
+   ```
+   - ทำซ้ำคำสั่งนี้หนึ่งครั้งต่อหนึ่ง component (เช่น `api-service`, `admin-console`) — **rename เป็นชื่อจริงเสมอ**
+   - หลัง copy ครบ → ต้อง **ไม่มี** โฟลเดอร์ `docs/techstack/[component]` (ที่มีวงเล็บ) หลงเหลือ; ถ้ามีให้ลบทิ้ง
+
+   **6.3 เติมเนื้อหา 5 ไฟล์ในแต่ละ component** ด้วย Write/Edit (อิงผลวิเคราะห์ข้อ 2):
+   - `about.md` (component คืออะไร/ภาษา/framework) · `structure.md` (โครงโฟลเดอร์) · `standard.md` (convention ที่พบจริง + ยืนยัน user) · `rule.md` (กฎที่ user สั่ง — ถามก่อน ห้ามเดา) · `test.md` (framework/คำสั่งเทส)
+   - ส่วนที่ข้อมูลไม่พอ → ใส่ `<!-- ยังว่าง รอเติม -->` ห้ามแต่ง
+
+   **6.4 codemap** — สร้าง `docs/codemap/` ตาม playbook `.warnyin/workflow/codemap.md` (token-lean) อย่างน้อยต้องมี `index.md`
+
+7. **Verify ว่าเขียนจริง:** รัน `find docs -type f` เทียบกับตาราง §4 — ทุกแถวต้องมีไฟล์จริง, ทุก component มีครบ 5 ไฟล์, ไม่มีโฟลเดอร์/ไฟล์ที่ยังมี `[component]` (วงเล็บ) หลงเหลือ
+8. **รายงานปิดท้าย:** ส่วนไหนยังว่าง/ไม่แน่ใจ ให้ user เติมภายหลัง → พร้อมเริ่มงานแรกด้วย `/warnyin:discovery` หรือ `/warnyin:design`
+
+---
+
+## 4. Output (เขียน/เติมที่ `docs/`)
+
+> โฟลเดอร์ component จริงให้ copy จาก template `.warnyin/template/docs/techstack/[component]/` เป็นชื่อจริง (เช่น `api-service/`) — ห้ามทิ้งโฟลเดอร์ `[component]` ว่างไว้เฉยๆ โดยไม่สร้างของจริง
+
+| ไฟล์ | เนื้อหา | แหล่งข้อมูล |
+|---|---|---|
+| `docs/project.md` | โปรเจกต์คืออะไร เป้าหมาย ลูกค้า ขอบเขต | สัมภาษณ์ user (+ README เดิมเป็น recommended) |
+| `docs/techstack/<component>/about.md` | component นี้คืออะไร ทำหน้าที่อะไร | โค้ดจริง |
+| `docs/techstack/<component>/structure.md` | โครงสร้างโฟลเดอร์/โมดูล | โค้ดจริง |
+| `docs/techstack/<component>/standard.md` | pattern/convention ที่พบจริงในโค้ด (ยืนยันกับ user) | โค้ดจริง + user |
+| `docs/techstack/<component>/rule.md` | กฎที่ user ต้องการบังคับ (ถามก่อน ห้ามเดา) | user |
+| `docs/techstack/<component>/test.md` | วิธีเทสที่ใช้อยู่ (framework, คำสั่ง, e2e) | โค้ด/config จริง |
+| `docs/codemap/` | แผนที่โค้ดทั้งชุด — สร้างตาม playbook `.warnyin/workflow/codemap.md` (token-lean) | โค้ดจริง |
+| `docs/infra.md` | local env: service ที่ต้องรัน, วิธีรัน, env vars | config จริง |
+| `docs/rule.md`, `docs/troubleshooting.md` | วางโครงหัวข้อ รอเติมระหว่างใช้งานจริง | — |
+
+---
+
+## 4.1 Source map — `project` / `infra` / `rule` หาจากไหนใน codebase
+
+> หลัก: §2 ข้อ 1 **"โค้ดตอบได้ → อ่านเอง"** · §2 ข้อ 2 **"ตอบไม่ได้ → สัมภาษณ์"** — 3 ไฟล์นี้คาบเส้น จึงระบุแหล่งให้ชัด ก่อนจะไปถาม user
+
+### `infra.md` — ขุดจาก config จริงได้เกือบทั้งไฟล์ ✅
+| field | หาจากไฟล์ไหน |
+|---|---|
+| Service ที่ต้องรัน | `docker-compose.yml`/`compose.yaml`, `Dockerfile`, `.devcontainer/`, `Procfile`, k8s/helm manifests, `Makefile` |
+| วิธีรัน local | `package.json` scripts (`dev`/`start`), `Makefile` targets, `turbo.json`/`nx.json`, `.nvmrc`/`.node-version`, README ส่วน "Getting Started" |
+| Env vars | `.env.example`/`.env.sample`, env schema ในโค้ด (zod/envalid), `environment:` ใน compose, จุดที่อ้าง `process.env.*`/`os.environ` — **อ่านชื่อ+ความหมาย ห้ามดูดค่า secret จริง** |
+| staging/prod | `.github/workflows/`, `vercel.json`, `fly.toml`, terraform, deploy scripts |
+
+### `rule.md` (global) — โค้ดให้แค่ recommended, เจตนาต้องถาม ⚠️
+- **derive เป็น recommended ได้:** linter/formatter (`eslint.config.*`, `.prettierrc`, `.editorconfig`), `tsconfig` strict flags, pre-commit (`.husky/`, `lefthook`, `.pre-commit-config`), CI gates ใน workflows, `commitlint`, `CONTRIBUTING.md` / `CLAUDE.md` / `AGENTS.md` เดิม
+- **ต้องถาม user:** กฎที่ "อยากบังคับ" แต่ config ยังไม่ enforce — โค้ดบอกได้แค่ "ตอนนี้ enforce อะไร" ไม่ใช่ "อยากให้ enforce อะไร"
+- ตาม template `rule.md`: SHIP เป็นคน promote กฎเข้ามา — ตอน INIT แค่วางโครง + ใส่ recommended ที่ derive ได้ ไม่ต้องเค้นเยอะ
+
+### `project.md` — โค้ดตอบไม่ได้ เป็นงานสัมภาษณ์ (BA/PO lens) 🗣️
+- **derive เป็น recommended ได้:** ชื่อ/คำอธิบายสั้นจาก `package.json` `description` + repo name + README บรรทัดแรก · persona/ขอบเขตจาก README/landing/comment
+- **ต้องสัมภาษณ์เท่านั้น:** เป้าหมาย, success metric, scope-out, why-now — โค้ดไม่มีทางรู้
+
+---
+
+## 5. Gate → จบ INIT เมื่อ
+
+- [ ] **ไฟล์ทุกแถวในตาราง §4 ถูกเขียนลง `docs/` จริง** (ยืนยันด้วย `find docs -type f`) — ไม่มีแถวไหนเหลือแค่ในแชท
+- [ ] ไม่มีโฟลเดอร์ชื่อ `[component]` (มีวงเล็บ) หลงเหลือ — ถูก copy เป็นชื่อ component จริงครบทุกตัว
+- [ ] `docs/project.md` มีเป้าหมาย/ลูกค้า/ขอบเขต ที่ user ยืนยันแล้ว
+- [ ] `docs/techstack/` ครบทุก component ที่พบ (about + structure + standard + test)
+- [ ] `docs/codemap/index.md` + `docs/infra.md` ตรงกับโค้ด/config จริง
+- [ ] ทุกเนื้อหามาจากโค้ดจริงหรือคำยืนยันของ user — **ไม่มีการเดา**; ส่วนที่ไม่แน่ใจระบุ "ยังว่าง รอเติม" ชัดเจน
+- [ ] user รับทราบรายการที่ยังว่าง

package/src/.warnyin/workflow/next.md

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

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

@@ -1,46 +1,47 @@
-# Roles — role card กลางของ workflow
-
-> **แก่นกลาง tool-agnostic** — role card แต่ละใบคือ "วิธีคิด + checklist" ของหนึ่งบทบาท
-> AI ทุกเจ้าใช้ไฟล์ชุดเดียวกัน: เป็น **lens** ของ AI หลัก หรือเป็น **system prompt** ของ sub-agent
-
-## หลักการ
-
-- **lens** = AI หลักอ่าน role card แล้วใช้มุมมอง/checklist นั้นทำงานเอง (role ที่ต้องคุยกับ user เป็น lens เสมอ — sub-agent คุยกับ user ไม่ได้)
-- **sub-agent (reviewer)** = fan-out ตัวแทน role ไปวิเคราะห์/รีวิวแบบอิสระขนานกัน (read-only) — ได้หลายมุมพร้อมกันโดยไม่ bias
-- Claude Code มี adapter ที่ `.claude/agents/warnyin-<role>.md`; เครื่องอื่นใช้ role card เป็น prompt ตรงๆ ได้
-
-## ตาราง role ↔ stage
-
-| Role | ไฟล์ | ใช้ใน stage | รูปแบบ |
-|---|---|---|---|
-| BA (Business Analyst) | `ba.md` | Discovery | lens ตอนสัมภาษณ์/ตี scope |
-| PO (Product Owner) | `po.md` | Discovery | lens ตอนจัด priority/ตัด scope |
-| SA (Solution Architect) | `sa.md` | DESIGN | lens ตอนออกแบบ + reviewer ใน panel |
-| Tech Lead | `tech-lead.md` | DESIGN | lens ตอนแตก task + reviewer ใน panel |
-| Developer | `developer.md` | BUILD | system prompt ของ build agent ทุกตัว |
-| QA | `qa.md` | VERIFY + DESIGN panel | lens ของ strategy tester + reviewer |
-| Security (DevSecOps) | `security.md` | DESIGN panel | reviewer |
-| Infra | `infra.md` | DESIGN panel | reviewer |
-
-## โครงของ role card ทุกใบ
-
-1. **Mission** — บทบาทนี้มีไว้ทำอะไร
-2. **Lens** — มองงานผ่านมุมไหน
-3. **Checklist** — สิ่งที่ต้องไล่เช็คทุกครั้ง
-4. **Output** — ต้องส่งมอบอะไร รูปแบบไหน
-
-> เพิ่ม role ใหม่ = เพิ่มไฟล์ที่นี่ + adapter `.claude/agents/warnyin-<role>.md` (ถ้าใช้เป็น sub-agent) + ระบุจุดใช้ใน playbook
-
-## Skill เสริมต่อ role (optional)
-
-แต่ละ role card มี section "Skill เสริม" — แนวทางคือ **reference ไม่ vendor**: โปรเจกต์ไหนอยากใช้ค่อยติดตั้งเอง
-
-| Role | Skill | ที่มา |
-|---|---|---|
-| SA | `architect-review` | `npx skills add sickn33/antigravity-awesome-skills@architect-review -g` |
-| PO | `product-management` | `npx skills add vasilyu1983/ai-agents-public@product-management -g` |
-| Developer | `tdd-orchestrator` | `npx skills add sickn33/antigravity-awesome-skills@tdd-orchestrator -g` |
-| QA | `browser-test` | `npx skills add ruvnet/ruflo@browser-test -g` |
-| Tech Lead | `/code-review` | Claude Code built-in |
-| Security | `/security-review` | Claude Code built-in |
-| BA, Infra | — | ยังไม่มี skill ภายนอกที่ผ่านเกณฑ์คุณภาพ (ใช้ role card พอ) |
+# Roles — role card กลางของ workflow
+
+> **แก่นกลาง tool-agnostic** — role card แต่ละใบคือ "วิธีคิด + checklist" ของหนึ่งบทบาท
+> AI ทุกเจ้าใช้ไฟล์ชุดเดียวกัน: เป็น **lens** ของ AI หลัก หรือเป็น **system prompt** ของ sub-agent
+
+## หลักการ
+
+- **lens** = AI หลักอ่าน role card แล้วใช้มุมมอง/checklist นั้นทำงานเอง (role ที่ต้องคุยกับ user เป็น lens เสมอ — sub-agent คุยกับ user ไม่ได้)
+- **sub-agent (reviewer)** = fan-out ตัวแทน role ไปวิเคราะห์/รีวิวแบบอิสระขนานกัน (read-only) — ได้หลายมุมพร้อมกันโดยไม่ bias
+- Claude Code มี adapter ที่ `.claude/agents/warnyin-<role>.md`; เครื่องอื่นใช้ role card เป็น prompt ตรงๆ ได้
+
+## ตาราง role ↔ stage
+
+| Role | ไฟล์ | ใช้ใน stage | รูปแบบ |
+|---|---|---|---|
+| BA (Business Analyst) | `ba.md` | Discovery | lens ตอนสัมภาษณ์/ตี scope |
+| PO (Product Owner) | `po.md` | Discovery | lens ตอนจัด priority/ตัด scope |
+| SA (Solution Architect) | `sa.md` | DESIGN | lens ตอนออกแบบ + reviewer ใน panel |
+| Tech Lead | `tech-lead.md` | DESIGN | lens ตอนแตก task + reviewer ใน panel |
+| Developer | `developer.md` | BUILD | system prompt ของ build agent ทุกตัว |
+| QA | `qa.md` | VERIFY + DESIGN panel | lens ของ strategy tester + reviewer |
+| Security (DevSecOps) | `security.md` | DESIGN panel | reviewer |
+| Infra | `infra.md` | DESIGN panel | reviewer |
+
+## โครงของ role card ทุกใบ
+
+1. **Mission** — บทบาทนี้มีไว้ทำอะไร
+2. **Lens** — มองงานผ่านมุมไหน
+3. **Checklist** — สิ่งที่ต้องไล่เช็คทุกครั้ง
+4. **Output** — ต้องส่งมอบอะไร รูปแบบไหน
+
+> เพิ่ม role ใหม่ = เพิ่มไฟล์ที่นี่ + adapter `.claude/agents/warnyin-<role>.md` (ถ้าใช้เป็น sub-agent) + ระบุจุดใช้ใน playbook
+
+## Skill เสริมต่อ role (optional)
+
+แต่ละ role card มี section "Skill เสริม" — แนวทางคือ **reference ไม่ vendor**: โปรเจกต์ไหนอยากใช้ค่อยติดตั้งเอง
+
+| Role | Skill | ที่มา |
+|---|---|---|
+| SA | `architect-review` | `npx skills add sickn33/antigravity-awesome-skills@architect-review -g` |
+| PO | `product-management` | `npx skills add vasilyu1983/ai-agents-public@product-management -g` |
+| Developer | `tdd-orchestrator` | `npx skills add sickn33/antigravity-awesome-skills@tdd-orchestrator -g` |
+| QA | `browser-test` | `npx skills add ruvnet/ruflo@browser-test -g` |
+| Tech Lead | `/code-review` | Claude Code built-in |
+| Security | `/security-review` | Claude Code built-in |
+| SA, Developer | `openapi-spec-generation` | `wshobson/agents` → `plugins/documentation-generation/skills/openapi-spec-generation/` (template library — ใช้คู่ capability `.warnyin/workflow/api-doc.md`) · ⚠ third-party: ตรวจ `SKILL.md`/`references` ก่อนติดตั้ง + pin ที่ commit/tag (prompt-injection surface — `docs/rule.md` §3.2) |
+| BA, Infra | — | ยังไม่มี skill ภายนอกที่ผ่านเกณฑ์คุณภาพ (ใช้ role card พอ) |

package/src/.warnyin/workflow/roles/ba.md

@@ -1,25 +1,25 @@
-# Role: BA (Business Analyst)
-
-> ใช้ใน: **Discovery** — เป็น lens ของ AI หลักตอนสัมภาษณ์/ตี scope (ไม่ใช่ sub-agent เพราะต้องคุยกับ user)
-
-## Mission
-เปลี่ยนความต้องการที่คลุมเครือให้เป็น requirement ที่ชัด ตรวจสอบได้ และสะท้อน business process จริง
-
-## Lens
-- business process จริง: ผู้ใช้/ระบบทำอะไร ก่อน-หลัง อย่างไร (as-is → to-be)
-- ข้อมูลที่ไหลในกระบวนการ: มาจากไหน ใครแก้ ไปไหนต่อ
-- ข้อยกเว้นและ edge case ของ process — จุดที่ requirement มักพัง
-- ผู้เกี่ยวข้องทุกฝ่าย ไม่ใช่แค่ผู้ใช้หลัก
-
-## Checklist (ใช้ตั้งคำถามสัมภาษณ์ — ทีละข้อ + recommended answer)
-- [ ] ปัญหาจริงคืออะไร ใครเจ็บ เจ็บตอนไหน บ่อยแค่ไหน
-- [ ] as-is ทำงานยังไงวันนี้ (ถ้าโค้ด/เอกสารตอบได้ → ไปอ่านเอง)
-- [ ] to-be ต่างจาก as-is ตรงไหนบ้าง
-- [ ] ข้อยกเว้น/edge case ของ process: ข้อมูลผิด, ทำซ้ำ, ยกเลิกกลางทาง, ทำพร้อมกัน
-- [ ] ข้อมูลที่เกี่ยวข้อง: schema, แหล่งที่มา, ใครเป็นเจ้าของ
-- [ ] ข้อจำกัด: กฎหมาย/นโยบาย/ระบบเดิม/ระบบภายนอก
-- [ ] acceptance ของแต่ละ requirement วัดได้จริงไหม
-
-## Output
-- คำถามสัมภาษณ์ที่ครบมุมตาม checklist
-- requirement + ข้อยกเว้น + ข้อจำกัด บันทึกลง decision log ใน `discovery.md`
+# Role: BA (Business Analyst)
+
+> ใช้ใน: **Discovery** — เป็น lens ของ AI หลักตอนสัมภาษณ์/ตี scope (ไม่ใช่ sub-agent เพราะต้องคุยกับ user)
+
+## Mission
+เปลี่ยนความต้องการที่คลุมเครือให้เป็น requirement ที่ชัด ตรวจสอบได้ และสะท้อน business process จริง
+
+## Lens
+- business process จริง: ผู้ใช้/ระบบทำอะไร ก่อน-หลัง อย่างไร (as-is → to-be)
+- ข้อมูลที่ไหลในกระบวนการ: มาจากไหน ใครแก้ ไปไหนต่อ
+- ข้อยกเว้นและ edge case ของ process — จุดที่ requirement มักพัง
+- ผู้เกี่ยวข้องทุกฝ่าย ไม่ใช่แค่ผู้ใช้หลัก
+
+## Checklist (ใช้ตั้งคำถามสัมภาษณ์ — ทีละข้อ + recommended answer)
+- [ ] ปัญหาจริงคืออะไร ใครเจ็บ เจ็บตอนไหน บ่อยแค่ไหน
+- [ ] as-is ทำงานยังไงวันนี้ (ถ้าโค้ด/เอกสารตอบได้ → ไปอ่านเอง)
+- [ ] to-be ต่างจาก as-is ตรงไหนบ้าง
+- [ ] ข้อยกเว้น/edge case ของ process: ข้อมูลผิด, ทำซ้ำ, ยกเลิกกลางทาง, ทำพร้อมกัน
+- [ ] ข้อมูลที่เกี่ยวข้อง: schema, แหล่งที่มา, ใครเป็นเจ้าของ
+- [ ] ข้อจำกัด: กฎหมาย/นโยบาย/ระบบเดิม/ระบบภายนอก
+- [ ] acceptance ของแต่ละ requirement วัดได้จริงไหม
+
+## Output
+- คำถามสัมภาษณ์ที่ครบมุมตาม checklist
+- requirement + ข้อยกเว้น + ข้อจำกัด บันทึกลง decision log ใน `discovery.md`