@warnyin/agents 0.5.1 → 0.6.0

package/{warnyin → .warnyin}/workflow/README.md

@@ -13,17 +13,17 @@ Discovery (optional) ──▶ DESIGN ──▶ BUILD ──▶ VERIFY ──▶
 
 ## หลักการออกแบบ: Tool-agnostic, single source of truth
 
-แก่นของ workflow (กฎ / ขั้นตอน / เกณฑ์ผ่าน) เขียน **ครั้งเดียว** เป็น markdown ใน `warnyin/workflow/stages/`
+แก่นของ workflow (กฎ / ขั้นตอน / เกณฑ์ผ่าน) เขียน **ครั้งเดียว** เป็น markdown ใน `.warnyin/workflow/stages/`
 ส่วน AI แต่ละเครื่องมีแค่ **adapter บางๆ** ที่ "ชี้กลับ" มาที่ playbook กลางชุดเดียวกัน
 
 | AI tool | Adapter (จุดเชื่อม) | อ่าน playbook จาก |
 |---|---|---|
-| **Claude Code** | `.claude/commands/*.md` + `CLAUDE.md` | `warnyin/workflow/stages/*.md` |
-| **Codex** | `AGENTS.md` | `warnyin/workflow/stages/*.md` |
-| **Antigravity** | `AGENTS.md` | `warnyin/workflow/stages/*.md` |
-| เครื่องอื่นๆ | ชี้มาที่ `warnyin/workflow/stages/` ได้ทันที | `warnyin/workflow/stages/*.md` |
+| **Claude Code** | `.claude/commands/*.md` + `CLAUDE.md` | `.warnyin/workflow/stages/*.md` |
+| **Codex** | `AGENTS.md` | `.warnyin/workflow/stages/*.md` |
+| **Antigravity** | `AGENTS.md` | `.warnyin/workflow/stages/*.md` |
+| เครื่องอื่นๆ | ชี้มาที่ `.warnyin/workflow/stages/` ได้ทันที | `.warnyin/workflow/stages/*.md` |
 
-> แก้กฎที่ `warnyin/workflow/stages/` ที่เดียว → ทุกเครื่องได้เหมือนกันทันที
+> แก้กฎที่ `.warnyin/workflow/stages/` ที่เดียว → ทุกเครื่องได้เหมือนกันทันที
 > เพิ่ม AI เจ้าใหม่ = เพิ่ม adapter บางๆ อีกหนึ่งไฟล์ ไม่ต้องแตะ logic
 
 ---
@@ -46,7 +46,7 @@ warnyin/               # ★ ทุกอย่างของ workflow รว
     scripts/
       build-wave.mjs   #   Workflow script: fan-out sub-agent ต่อ task ใน wave (worktree)
   template/            # ★ template ทั้งหมดรวมที่เดียว
-    stages/[topic]/    #   หนึ่งหน่วยงาน — copy เป็น warnyin/stages/<slug>
+    stages/[topic]/    #   หนึ่งหน่วยงาน — copy เป็น docs/stages/<slug>
       discovery.md  research.md            # output ของ Discovery
       business.md  proposal.md  design.md  # output ของ DESIGN
       tasks/[task-name]/...  build.md      # output ของ DESIGN (tasks) + BUILD
@@ -60,7 +60,7 @@ warnyin/               # ★ ทุกอย่างของ workflow รว
     context.md
     achieved/          #   archive หลัง SHIP (<YYYY-MM-DD>-<slug>/)
 
-docs/                  # ความรู้ถาวรระดับโปรเจกต์ — ของจริงล้วน (seed จาก warnyin/template/docs)
+docs/                  # ความรู้ถาวรระดับโปรเจกต์ — ของจริงล้วน (seed จาก .warnyin/template/docs)
   project.md           # ★ จุดเริ่มของ Discovery — อ่านก่อนเสมอ
   rule.md  infra.md
   troubleshooting.md   # ★ KB ปัญหา-วิธีแก้ (อ่านก่อนเมื่อ build เจอ error; SHIP ป้อนเข้า)
@@ -80,15 +80,15 @@ npx @warnyin/agents --dry-run   # ดูก่อนว่าจะสร้า
 ```
 
 - โปรเจกต์ที่มี `CLAUDE.md`/`AGENTS.md` อยู่แล้ว → installer ต่อท้ายเป็น section ไม่เขียนทับ
-- `--update` เขียนทับเฉพาะ core (`warnyin/workflow/`, `.claude/commands/warnyin/`, template ใน `warnyin/template/`) — ไม่แตะ `docs/` และงานจริง
-- หลังติดตั้ง → เปิด Claude Code แล้วรัน `/warnyin:init` ให้ agent วิเคราะห์โปรเจกต์ + เติม `docs/` (playbook: `warnyin/workflow/init.md`)
+- `--update` เขียนทับเฉพาะ core (`.warnyin/workflow/`, `.claude/commands/warnyin/`, template ใน `.warnyin/template/`) — ไม่แตะ `docs/` และงานจริง
+- หลังติดตั้ง → เปิด Claude Code แล้วรัน `/warnyin:init` ให้ agent วิเคราะห์โปรเจกต์ + เติม `docs/` (playbook: `.warnyin/workflow/init.md`)
 
 ## วิธีใช้
 
-1. เริ่มงานใหม่ → copy `warnyin/template/stages/[topic]/` เป็น `warnyin/stages/<ชื่อ-งาน-kebab-case>/`
+1. เริ่มงานใหม่ → copy `.warnyin/template/stages/[topic]/` เป็น `docs/stages/<ชื่อ-งาน-kebab-case>/`
 2. รัน stage ตามลำดับ (Discovery ข้ามได้ถ้าเข้าใจ scope ชัดแล้ว)
    - Claude Code: `/warnyin:discovery <topic>`, `/warnyin:design <slug> <change>`
-   - Codex / Antigravity: บอกให้ทำตาม `warnyin/workflow/stages/<stage>.md`
+   - Codex / Antigravity: บอกให้ทำตาม `.warnyin/workflow/stages/<stage>.md`
 3. ผ่าน "gate" ของแต่ละ stage แล้วจึงไป stage ถัดไป
 4. เมื่อ SHIP (`/warnyin:ship <slug>`) → promote ความรู้ของ topic ขึ้นเอกสารกลางใน `docs/`
-   แล้วย้าย topic ไป `warnyin/stages/achieved/<YYYY-MM-DD>-<topic>/`
+   แล้วย้าย topic ไป `docs/stages/achieved/<YYYY-MM-DD>-<topic>/`

package/{warnyin → .warnyin}/workflow/explore.md

@@ -19,13 +19,13 @@ EXPLORE คือโหมด **อ่านอย่างเดียว (read
 1. `docs/project.md` — โปรเจกต์นี้คืออะไร เป้าหมาย ขอบเขต
 2. `docs/codemap/index.md` — แผนที่โค้ด (ไปอ่านโค้ดจริงต่อได้)
 3. `docs/rule.md`, `docs/infra.md`, `docs/features/*`, `docs/techstack/*` — ตามที่คำถามแตะ
-4. `warnyin/stages/context.md` + topic ใน `warnyin/stages/` และ `achieved/` ที่ใกล้เคียง — งานที่เคยทำ/กำลังทำ
+4. `docs/stages/context.md` + topic ใน `docs/stages/` และ `achieved/` ที่ใกล้เคียง — งานที่เคยทำ/กำลังทำ
 
 ---
 
 ## 3. หลักการทำงาน
 
-1. **Read-only เด็ดขาด:** ใช้เฉพาะการอ่าน/ค้น (read, grep, glob, sub-agent แบบ read-only) — **ห้ามสร้าง แก้ หรือลบไฟล์ใดๆ** รวมถึงไฟล์ใน `warnyin/stages/` และ `docs/`
+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 ไปต่อเองได้

package/{warnyin → .warnyin}/workflow/init.md

@@ -18,7 +18,7 @@
 ## 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 แค่ยืนยัน/แก้)
+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 ยืนยัน **ครั้งเดียว** แล้วจึงเขียนจริง
@@ -36,8 +36,8 @@
 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
+   - **สวม 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 สั่ง)
@@ -47,17 +47,17 @@
    **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
+   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>"
+   cp -R ".warnyin/template/docs/techstack/[component]" "docs/techstack/<name>"
    ```
    - ทำซ้ำคำสั่งนี้หนึ่งครั้งต่อหนึ่ง component (เช่น `api-service`, `admin-console`) — **rename เป็นชื่อจริงเสมอ**
    - หลัง copy ครบ → ต้อง **ไม่มี** โฟลเดอร์ `docs/techstack/[component]` (ที่มีวงเล็บ) หลงเหลือ; ถ้ามีให้ลบทิ้ง
@@ -66,7 +66,7 @@
    - `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`
+   **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`
@@ -75,7 +75,7 @@
 
 ## 4. Output (เขียน/เติมที่ `docs/`)
 
-> โฟลเดอร์ component จริงให้ copy จาก template `warnyin/template/docs/techstack/[component]/` เป็นชื่อจริง (เช่น `api-service/`) — ห้ามทิ้งโฟลเดอร์ `[component]` ว่างไว้เฉยๆ โดยไม่สร้างของจริง
+> โฟลเดอร์ component จริงให้ copy จาก template `.warnyin/template/docs/techstack/[component]/` เป็นชื่อจริง (เช่น `api-service/`) — ห้ามทิ้งโฟลเดอร์ `[component]` ว่างไว้เฉยๆ โดยไม่สร้างของจริง
 
 | ไฟล์ | เนื้อหา | แหล่งข้อมูล |
 |---|---|---|
@@ -85,12 +85,35 @@
 | `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/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`) — ไม่มีแถวไหนเหลือแค่ในแชท

package/{warnyin → .warnyin}/workflow/next.md

@@ -14,9 +14,9 @@ NEXT คือโหมด **อ่านอย่างเดียว (read-on
 
 ## 2. วิธีหาสถานะ (สแกนจากไฟล์จริง — ไม่ถาม user ก่อน)
 
-1. **หา topic ที่ active:** โฟลเดอร์ใน `warnyin/stages/<slug>/` ทั้งหมด ยกเว้น `achieved/` และ `context.md`
+1. **หา topic ที่ active:** โฟลเดอร์ใน `docs/stages/<slug>/` ทั้งหมด ยกเว้น `achieved/` และ `context.md`
    - ไม่มี topic เลย → รายงานว่า "ไม่มีงานค้าง" + แนะนำเริ่มงานใหม่ด้วย `/warnyin:discovery` หรือ `/warnyin:design`
-2. **อ่าน `warnyin/stages/context.md`** — บริบทงานที่จดไว้ (ถ้ามี)
+2. **อ่าน `docs/stages/context.md`** — บริบทงานที่จดไว้ (ถ้ามี)
 3. **ต่อ topic — ระบุ stage ปัจจุบันจาก artifact ที่ "ถูกเติมจริง":**
    ไฟล์ที่ยังเป็นโครง template (มี placeholder `<...>` / ตารางว่าง) = **ยังไม่ทำ** — ดูเนื้อหา ไม่ใช่แค่ว่าไฟล์มีอยู่
 
@@ -30,7 +30,7 @@ NEXT คือโหมด **อ่านอย่างเดียว (read-on
    | `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 ว่าข้อไหนยังไม่ครบ — ข้อที่ขาดคือ "งานค้าง" ที่แท้จริง
+5. **เช็ค gate ของ stage ปัจจุบัน:** เปิด playbook ของ stage นั้นใน `.warnyin/workflow/stages/` แล้วไล่ checklist gate ว่าข้อไหนยังไม่ครบ — ข้อที่ขาดคือ "งานค้าง" ที่แท้จริง
 
 ---
 

package/{warnyin → .warnyin}/workflow/roles/developer.md

@@ -1,6 +1,6 @@
 # Role: Developer
 
-> ใช้ใน: **BUILD** — system prompt เสริมของ build sub-agent ทุกตัว (ผ่าน `warnyin/workflow/scripts/build-wave.mjs`)
+> ใช้ใน: **BUILD** — system prompt เสริมของ build sub-agent ทุกตัว (ผ่าน `.warnyin/workflow/scripts/build-wave.mjs`)
 
 ## Mission
 implement vertical slice ที่รับมอบให้ **เสร็จจริง เขียวจริง** ตาม standard — ไม่เกิน scope ไม่ต่ำกว่า spec

package/{warnyin → .warnyin}/workflow/scripts/build-wave.mjs

@@ -3,7 +3,7 @@
 //
 // args = {
 //   slug: string,            // ชื่อ topic เช่น "billing-redesign"
-//   tasks: string[],         // ชื่อ task ใน wave นี้ (โฟลเดอร์ warnyin/stages/<slug>/tasks/<task>)
+//   tasks: string[],         // ชื่อ task ใน wave นี้ (โฟลเดอร์ docs/stages/<slug>/tasks/<task>)
 //   isolate?: boolean,       // true = worktree ต่อ task (ดีฟอลต์), false = shared tree (sequential)
 // }
 
@@ -13,9 +13,11 @@ export const meta = {
   phases: [{ title: 'Build wave', detail: 'parallel agent, หนึ่งตัวต่อหนึ่ง task (worktree isolation)' }],
 }
 
-const slug = args && args.slug
-const tasks = (args && args.tasks) || []
-const isolate = !(args && args.isolate === false)
+// บาง harness ส่ง args ของ Workflow เป็น string (JSON text) ไม่ใช่ object — รับทั้งสองแบบ
+const A = typeof args === 'string' ? JSON.parse(args) : (args || {})
+const slug = A.slug
+const tasks = A.tasks || []
+const isolate = !(A.isolate === false)
 
 if (!slug || tasks.length === 0) {
   log('ไม่มี slug หรือ tasks — ไม่มีอะไรให้ build')
@@ -57,17 +59,17 @@ const RESULT_SCHEMA = {
 }
 
 function prompt(task) {
-  const dir = `warnyin/stages/${slug}/tasks/${task}`
+  const dir = `docs/stages/${slug}/tasks/${task}`
   const lines = [
-    `คุณคือ build sub-agent ของ task "${task}" (vertical slice) ทำตาม playbook warnyin/workflow/stages/build.md`,
+    `คุณคือ build sub-agent ของ task "${task}" (vertical slice) ทำตาม playbook .warnyin/workflow/stages/build.md`,
     ``,
     `1. อ่านให้ครบก่อนเขียนโค้ด:`,
-    `   - warnyin/workflow/roles/developer.md (role card: lens + checklist ก่อนส่งงาน — ทำตามทุกข้อ)`,
+    `   - .warnyin/workflow/roles/developer.md (role card: lens + checklist ก่อนส่งงาน — ทำตามทุกข้อ)`,
     `   - ${dir}/task.md (เป้าหมาย + sub-tasks + dependency + acceptance)`,
     `   - ${dir}/spec.md (API/UXUI/data-flow/user-flow/persona/test-flow)`,
     `   - ${dir}/standard.md (pattern โค้ด, shared component — reuse ห้ามเขียนซ้ำ)`,
     `   - ${dir}/rule.md (กฎที่ต้อง follow)`,
-    `   - ภาพรวม: warnyin/stages/${slug}/design.md, proposal.md`,
+    `   - ภาพรวม: docs/stages/${slug}/design.md, proposal.md`,
     `   - rule/standard กลางที่อ้างถึงใน docs/techstack/<component>/`,
     `2. Implement ให้ครบทุก sub-task แบบ vertical slice (end-to-end) ทำตาม standard.md + rule.md เคร่งครัด`,
     `3. รัน test-flow ใน spec.md + build/lint ของ component นั้น`,

package/{warnyin → .warnyin}/workflow/stages/build.md

@@ -14,9 +14,9 @@ BUILD จะ **orchestrate การ implement** โดยกระจายง
 
 ## 2. Input ที่ต้องอ่านก่อนเริ่ม
 
-1. `warnyin/stages/<slug>/design.md` — dependency graph ระหว่าง task/slice (section 7)
-2. `warnyin/stages/<slug>/proposal.md` — scope ของ change
-3. `warnyin/stages/<slug>/tasks/<task>/task.md` ทุกใบ — dependency ของแต่ละ task + sub-tasks
+1. `docs/stages/<slug>/design.md` — dependency graph ระหว่าง task/slice (section 7)
+2. `docs/stages/<slug>/proposal.md` — scope ของ change
+3. `docs/stages/<slug>/tasks/<task>/task.md` ทุกใบ — dependency ของแต่ละ task + sub-tasks
 4. `docs/techstack/<component>/rule.md` + `standard.md` — กฎ/มาตรฐานที่ต้อง follow
 
 ---
@@ -34,8 +34,8 @@ BUILD จะ **orchestrate การ implement** โดยกระจายง
 6. **ห้ามแตะ rule/standard กลางใน `docs/`** — rule ใหม่ที่เสนอถูก note ไว้ใน `tasks/<task>/rule.md` แล้ว รอ SHIP ค่อยอัปเดตไฟล์กลาง
 7. **fail = หยุดที่ wave นั้น** — ถ้า task ใน wave ล้ม ให้รายงาน user ก่อนไป wave ถัดไป (เพราะ wave ถัดไปอาจ depend อยู่)
 8. **★ ปิดท้ายด้วย full build + full test เสมอ** — หลัง merge ทุก wave แล้ว ต้องรัน build ทั้งหมด + test suite ทั้งหมด (รวม unit test) บน build branch ที่ integrate; **แก้วนจนเขียวหมด** ก่อนปิด BUILD (กันกรณี task รายเดี่ยวเขียวแต่พอรวมกันแล้วพัง)
-9. **ทุก build agent สวม role Developer** — ทำตาม role card `warnyin/workflow/roles/developer.md` (lens + checklist ก่อนส่งงาน) — build-wave.mjs ใส่ให้ใน prompt แล้ว
-10. **★ ใช้ Troubleshooting KB** — เจอปัญหา/error ระหว่าง build ให้ **อ่าน `docs/troubleshooting.md` ก่อนเสมอ** เผื่อเคยแก้แล้ว; เมื่อแก้ปัญหาที่ **ยาก/เจอซ้ำ** สำเร็จ ให้บันทึก entry ลง `warnyin/stages/<slug>/troubleshooting.md` (ปัญหา/อาการ/root cause/วิธีแก้/ป้องกันซ้ำ) — ตอน SHIP จะยกขึ้น KB กลาง
+9. **ทุก build agent สวม role Developer** — ทำตาม role card `.warnyin/workflow/roles/developer.md` (lens + checklist ก่อนส่งงาน) — build-wave.mjs ใส่ให้ใน prompt แล้ว
+10. **★ ใช้ Troubleshooting KB** — เจอปัญหา/error ระหว่าง build ให้ **อ่าน `docs/troubleshooting.md` ก่อนเสมอ** เผื่อเคยแก้แล้ว; เมื่อแก้ปัญหาที่ **ยาก/เจอซ้ำ** สำเร็จ ให้บันทึก entry ลง `docs/stages/<slug>/troubleshooting.md` (ปัญหา/อาการ/root cause/วิธีแก้/ป้องกันซ้ำ) — ตอน SHIP จะยกขึ้น KB กลาง
 
 ---
 
@@ -43,13 +43,13 @@ BUILD จะ **orchestrate การ implement** โดยกระจายง
 
 > ผู้ orchestrate คือ AI ตัวหลัก (main loop) — sub-agent คือคนลงมือ implement
 
-0. **★ เช็ค context window ก่อนเริ่ม:** ประเมินว่า context ของ session ปัจจุบันถูกใช้ไปมากน้อยแค่ไหน — ถ้าใช้ไปเยอะหรือ **เกินครึ่ง** → **เสนอ user ให้ `/compact` หรือ `/clear` ก่อนเสมอ** แล้วค่อยเริ่ม BUILD ใน context ที่โล่ง (สถานะงานอยู่ในไฟล์ `warnyin/stages/<slug>/` ครบ ไม่หายไปกับ context) — BUILD เป็นงานยาว ต้องมี context เหลือมากพอ; เครื่องอื่นที่ไม่มีคำสั่งนี้ → แนะนำเริ่ม session ใหม่
+0. **★ เช็ค context window ก่อนเริ่ม:** ประเมินว่า context ของ session ปัจจุบันถูกใช้ไปมากน้อยแค่ไหน — ถ้าใช้ไปเยอะหรือ **เกินครึ่ง** → **เสนอ user ให้ `/compact` หรือ `/clear` ก่อนเสมอ** แล้วค่อยเริ่ม BUILD ใน context ที่โล่ง (สถานะงานอยู่ในไฟล์ `docs/stages/<slug>/` ครบ ไม่หายไปกับ context) — BUILD เป็นงานยาว ต้องมี context เหลือมากพอ; เครื่องอื่นที่ไม่มีคำสั่งนี้ → แนะนำเริ่ม session ใหม่
 1. **อ่าน task ทั้งหมด** → ดึง dependency ของแต่ละ task จาก `task.md` (section 2) + `design.md` (section 7)
 2. **สร้าง DAG + จัด wave** (topological sort): wave 1 = task ที่ไม่มี dependency, wave 2 = task ที่ depend เฉพาะ wave 1, ...
 3. **Pre-check:** target เป็น git repo ไหม (สำหรับ worktree) — ถ้าไม่ใช่ → fallback sequential shared-tree และแจ้ง user
 4. **เสนอ execution plan + ขออนุมัติ (ครั้งเดียว):** แสดง wave / task ในแต่ละ wave / อันไหน parallel / isolation mode → ถาม user go/no-go
 5. **เดินทีละ wave:**
-   - fan-out sub-agent ของ task ใน wave นั้น (parallel, worktree isolation) ผ่าน **Workflow** (`warnyin/workflow/scripts/build-wave.mjs`)
+   - fan-out sub-agent ของ task ใน wave นั้น (parallel, worktree isolation) ผ่าน **Workflow** (`.warnyin/workflow/scripts/build-wave.mjs`)
    - แต่ละ agent: implement → test/lint → commit (ถ้า worktree) → รายงานผลแบบ structured (status, files, branch, test result)
    - **integrate:** main loop merge worktree branch ของ wave นั้นเข้า build branch (ทีละอันเพื่อเลี่ยง conflict); ถ้า conflict → แก้/รายงาน
    - ถ้ามี task `failed` → หยุด รายงาน user
@@ -66,15 +66,15 @@ BUILD จะ **orchestrate การ implement** โดยกระจายง
 | ไฟล์ | เนื้อหา |
 |---|---|
 | โค้ดจริงใน target repo | การ implement ของแต่ละ task (merge เข้า build branch) |
-| `warnyin/stages/<slug>/build.md` | รายงานผล build: สถานะ/ผล test/ไฟล์ที่แก้ ต่อ task + integration notes |
-| `warnyin/stages/<slug>/troubleshooting.md` | ปัญหายาก/ซ้ำที่แก้สำเร็จ (SHIP ยกขึ้น `docs/troubleshooting.md`) |
+| `docs/stages/<slug>/build.md` | รายงานผล build: สถานะ/ผล test/ไฟล์ที่แก้ ต่อ task + integration notes |
+| `docs/stages/<slug>/troubleshooting.md` | ปัญหายาก/ซ้ำที่แก้สำเร็จ (SHIP ยกขึ้น `docs/troubleshooting.md`) |
 | `tasks/<task>/task.md` (อัปเดต) | สถานะ task → เสร็จ + acceptance ที่ผ่าน |
 
 ---
 
 ## 6. Workflow script (Claude Code)
 
-ใช้ `warnyin/workflow/scripts/build-wave.mjs` — fan-out หนึ่ง agent ต่อหนึ่ง task ใน **หนึ่ง wave** (parallel, worktree isolation), คืนผลแบบ structured
+ใช้ `.warnyin/workflow/scripts/build-wave.mjs` — fan-out หนึ่ง agent ต่อหนึ่ง task ใน **หนึ่ง wave** (parallel, worktree isolation), คืนผลแบบ structured
 main loop เรียก script นี้ **ทีละ wave** แล้ว integrate ระหว่าง wave (ดูรายละเอียดใน `.claude/commands/warnyin/build.md`)
 
 > เครื่องอื่น (Codex/Antigravity) ที่ไม่มี Workflow tool: ทำตามหลักการข้อ 3-4 โดย implement task ตามลำดับ wave เอง (parallel เท่าที่เครื่องรองรับ)

package/{warnyin → .warnyin}/workflow/stages/design.md

@@ -21,7 +21,7 @@
 2. `docs/rule.md` + `docs/techstack/<component>/rule.md` — ★ กฎที่ต้อง follow
 3. `docs/techstack/<component>/standard.md` — ★ pattern/มาตรฐานการเขียนโค้ด
 4. `docs/techstack/<component>/{about,structure,test}.md`, `docs/codemap/index.md` — โครงสร้าง/วิธีเทสต์
-5. ถ้ามี Discovery → `warnyin/stages/<slug>/discovery.md`, `research.md`
+5. ถ้ามี Discovery → `docs/stages/<slug>/discovery.md`, `research.md`
 6. โค้ดจริงที่เกี่ยวข้อง (inspect เพื่อตอบคำถามแทนการเดา)
 
 ---
@@ -33,33 +33,33 @@
 3. **task = หน่วยที่โยนให้ sub-agent ได้** — แต่ละ task self-contained (มี spec + standard + rule ของตัวเอง) แต่ **เชื่อมต่อกัน** ผ่าน dependency/ลำดับที่ระบุชัด
 4. **สอดคล้องมาตรฐานเสมอ** — อิง rule + standard ของ techstack; ถ้าจะเพิ่ม rule/standard ใหม่ ให้ **note ไว้ก่อน** (ยังไม่แก้ไฟล์กลาง — รอ SHIP)
 5. **Gate ก่อนเขียนไฟล์ task จริง** — ต้องผ่านเกณฑ์ข้อ 8 ก่อนจะ generate ไฟล์ task และก่อนโยนให้ sub-agent
-6. **ใช้ role lens** — ออกแบบ (design.md) ด้วยมุม **SA** (`warnyin/workflow/roles/sa.md`) และแตก/ตรวจ task ด้วยมุม **Tech Lead** (`warnyin/workflow/roles/tech-lead.md`)
-7. **Review panel ก่อนแตก task (optional — ถาม user ก่อนเสมอ)** — ให้หลาย role (SA / Tech Lead / QA / Security / Infra ตาม `warnyin/workflow/roles/`) รีวิว design ขนานแบบอิสระ (read-only) แล้วแก้ blocker ให้ครบก่อนแตก task (ดูขั้นตอนข้อ 4.6)
+6. **ใช้ role lens** — ออกแบบ (design.md) ด้วยมุม **SA** (`.warnyin/workflow/roles/sa.md`) และแตก/ตรวจ task ด้วยมุม **Tech Lead** (`.warnyin/workflow/roles/tech-lead.md`)
+7. **Review panel ก่อนแตก task (optional — ถาม user ก่อนเสมอ)** — ให้หลาย role (SA / Tech Lead / QA / Security / Infra ตาม `.warnyin/workflow/roles/`) รีวิว design ขนานแบบอิสระ (read-only) แล้วแก้ blocker ให้ครบก่อนแตก task (ดูขั้นตอนข้อ 4.6)
 8. **Dry-run ก่อนเข้า BUILD (optional — ถาม user ก่อนเสมอ)** — หลังเขียนไฟล์ task ครบ เสนอ user ว่าจะ dry-run ทั้งหมดเพื่อหาจุดบกพร่องไหม ถ้า ok → สแกนทุก task แบบขนาน (read-only) หา **defer/blocker** แล้วแก้ DESIGN จนไม่มี blocker ค้าง (ดูขั้นตอนข้อ 4.10) — การแก้ **ห้ามเดา ห้ามคิดขึ้นเอง**
 
 ---
 
 ## 4. ลำดับขั้นการทำงาน (process)
 
-1. **เตรียมพื้นที่:** ใช้/สร้างโฟลเดอร์ `warnyin/stages/<slug>/` (ถ้ามาจาก Discovery ใช้อันเดิม)
+1. **เตรียมพื้นที่:** ใช้/สร้างโฟลเดอร์ `docs/stages/<slug>/` (ถ้ามาจาก Discovery ใช้อันเดิม)
 2. **Ground + เคลียร์ความไม่ชัด:** อ่าน Input; ทุกจุดกำกวมเรื่อง design → ถามทีละข้อ + recommended answer จนชัด (ถ้าใหญ่/ไม่ชัดมาก → แนะนำ Discovery ก่อน)
 3. **business.md** *(optional — ข้ามได้ถ้า change เล็ก เช่น fix bug นิดหน่อย)*: what & why เชิงธุรกิจ — goal, คุณค่า, persona, success metric
 4. **proposal.md** (what & why): สรุป change ที่จะทำ, เหตุผล, ทางเลือกที่พิจารณา/ตัดทิ้ง, scope in/out
-5. **design.md** (how): ออกแบบเชิงเทคนิคแบบ vertical slice — slice มีอะไรบ้าง, แต่ละ slice ตัดผ่าน layer ไหน, data model, interface/contract, flow, ผลกระทบต่อระบบเดิม (ใช้ lens `warnyin/workflow/roles/sa.md`)
+5. **design.md** (how): ออกแบบเชิงเทคนิคแบบ vertical slice — slice มีอะไรบ้าง, แต่ละ slice ตัดผ่าน layer ไหน, data model, interface/contract, flow, ผลกระทบต่อระบบเดิม (ใช้ lens `.warnyin/workflow/roles/sa.md`)
 6. **Review panel (optional — ถาม user ก่อน):** เสนอ user ว่าจะให้ panel หลาย role รีวิว design ก่อนแตก task ไหม — ถ้า ok:
-   1. fan-out sub-agent reviewer **ขนาน (read-only)** ตาม role card: **SA** (architecture/data model/contract), **Tech Lead** (feasibility/ขนาด task/dependency), **QA** (testability/acceptance), **Security** (ช่องโหว่/ข้อมูลอ่อนไหว), **Infra** (env/config/migration) — แต่ละตัวอ่าน `proposal.md` + `design.md` + โค้ดจริงที่เกี่ยว แล้วให้ความเห็นตาม checklist ใน `warnyin/workflow/roles/<role>.md` แบ่งเป็น **blocker / suggestion**
+   1. fan-out sub-agent reviewer **ขนาน (read-only)** ตาม role card: **SA** (architecture/data model/contract), **Tech Lead** (feasibility/ขนาด task/dependency), **QA** (testability/acceptance), **Security** (ช่องโหว่/ข้อมูลอ่อนไหว), **Infra** (env/config/migration) — แต่ละตัวอ่าน `proposal.md` + `design.md` + โค้ดจริงที่เกี่ยว แล้วให้ความเห็นตาม checklist ใน `.warnyin/workflow/roles/<role>.md` แบ่งเป็น **blocker / suggestion**
    2. รวมความเห็นทุก role → สรุปให้ user เห็นภาพ
    3. **blocker → แก้ design ให้ครบ** โดยห้ามเดา — ติดจริงถาม user ทีละข้อ + เสนอคำตอบแนะนำ; suggestion → พิจารณา/บันทึกเหตุผลถ้าไม่ทำ
    4. บันทึกสรุปผล panel + สิ่งที่แก้ ลงท้าย `design.md` (section "Design review")
    5. เครื่องที่ fan-out ไม่ได้ → รีวิวทีละ role ด้วย checklist เดียวกัน
 7. **แตก tasks:** แปลง design เป็น task (= vertical slice / step ที่แก้); task ซับซ้อน → แตก **sub-task** ย่อย; เขียน **dependency graph / ลำดับ** ให้ sub-task เชื่อมกัน
 8. **rule check ต่อ task:** เปิด `docs/techstack/<component>/rule.md` หา rule ที่ task นี้ต้องโฟกัส → ใส่ใน `tasks/<task>/rule.md`; rule ใหม่ที่อยากเพิ่ม → note ใน section "เสนอเพิ่ม (รอ SHIP)"
-9. **เช็ค Gate (ข้อ 8)** → เมื่อผ่าน จึง **เขียนไฟล์ task ครบทุกใบ** (แตก task ด้วย lens `warnyin/workflow/roles/tech-lead.md`)
+9. **เช็ค Gate (ข้อ 8)** → เมื่อผ่าน จึง **เขียนไฟล์ task ครบทุกใบ** (แตก task ด้วย lens `.warnyin/workflow/roles/tech-lead.md`)
 10. **Dry-run (optional — ถาม user ก่อน):** ถาม user ว่าต้องการ dry-run ทั้งหมดเพื่อหาจุดบกพร่องก่อนเข้า BUILD ไหม — ถ้า ok:
    1. **fan-out agent หนึ่งตัวต่อหนึ่ง task แบบขนาน (read-only — ห้ามแก้โค้ด/ไฟล์ design)** — แต่ละตัวอ่าน task ทั้ง 4 ไฟล์ + `design.md`/`proposal.md` + โค้ดจริงที่เกี่ยว แล้ว "เดิน implement ในหัว" เพื่อหา:
       - **blocker** — สิ่งที่ทำให้ implement ตาม spec ไม่ได้ (ขัดแย้งกับโค้ดจริง/กับ task อื่น, ข้อมูล/spec ขาด, dependency ผิด) — BUILD จะล้มถ้าไม่แก้
       - **defer** — จุดที่ตัดสินใจ/ทำทีหลังได้ ไม่ block การเริ่ม BUILD แต่ต้องบันทึกและ track
-   2. task ไหนพบ issue → เขียน `tasks/<task>/issue.md` (template `warnyin/template/stages/[topic]/tasks/[task-name]/issue.md`); ไม่พบ → ไม่ต้องสร้างไฟล์
+   2. task ไหนพบ issue → เขียน `tasks/<task>/issue.md` (template `.warnyin/template/stages/[topic]/tasks/[task-name]/issue.md`); ไม่พบ → ไม่ต้องสร้างไฟล์
    3. รันครบทุก task แล้ว → **สรุปผลรวม** (จำนวน blocker/defer ต่อ task) ให้ user เห็นภาพ
    4. **หาวิธีแก้ DESIGN ตาม issue** (แก้ `design.md` / task ที่กระทบ) โดย **ห้ามเดา ห้ามคิดขึ้นเอง** — ติดจริงๆ ให้สัมภาษณ์ user **ถามทีละข้อ + เสนอคำตอบแนะนำทุกครั้ง**; คำถามที่โค้ดตอบได้ → ไปอ่านโค้ดเอง
    5. แก้แล้ว rerun dry-run เฉพาะ task ที่กระทบ วนจน **ไม่มี blocker ค้าง** (อัปเดตสถานะใน `issue.md` — defer ที่เหลือให้ user รับทราบ)
@@ -70,18 +70,18 @@
 
 ---
 
-## 5. Output (สร้างที่ `warnyin/stages/<slug>/`)
+## 5. Output (สร้างที่ `docs/stages/<slug>/`)
 
 | ไฟล์ | เนื้อหา | optional? | template |
 |---|---|---|---|
-| `business.md` | what & why เชิงธุรกิจ (goal, persona, success metric) | ✅ ข้ามได้ถ้า change เล็ก | `warnyin/template/stages/[topic]/business.md` |
-| `proposal.md` | what & why ของ change + ทางเลือก + scope | จำเป็น | `warnyin/template/stages/[topic]/proposal.md` |
-| `design.md` | how — vertical slice, data model, contract, flow | จำเป็น | `warnyin/template/stages/[topic]/design.md` |
-| `tasks/<task-name>/spec.md` | spec เฉพาะ task (ดูข้อ 6) | จำเป็นต่อ task | `warnyin/template/stages/[topic]/tasks/[task-name]/spec.md` |
-| `tasks/<task-name>/standard.md` | pattern โค้ด/shared component อิง techstack standard | จำเป็นต่อ task | `warnyin/template/stages/[topic]/tasks/[task-name]/standard.md` |
-| `tasks/<task-name>/rule.md` | rule ที่ต้อง follow + rule ที่เสนอเพิ่ม (รอ SHIP) | จำเป็นต่อ task | `warnyin/template/stages/[topic]/tasks/[task-name]/rule.md` |
-| `tasks/<task-name>/task.md` | รายละเอียด task + sub-tasks + dependency + acceptance | จำเป็นต่อ task | `warnyin/template/stages/[topic]/tasks/[task-name]/task.md` |
-| `tasks/<task-name>/issue.md` | ผล dry-run: defer/blocker ที่พบ + แนวทางแก้ + สถานะ | ✅ เฉพาะเมื่อ dry-run แล้วพบ issue | `warnyin/template/stages/[topic]/tasks/[task-name]/issue.md` |
+| `business.md` | what & why เชิงธุรกิจ (goal, persona, success metric) | ✅ ข้ามได้ถ้า change เล็ก | `.warnyin/template/stages/[topic]/business.md` |
+| `proposal.md` | what & why ของ change + ทางเลือก + scope | จำเป็น | `.warnyin/template/stages/[topic]/proposal.md` |
+| `design.md` | how — vertical slice, data model, contract, flow | จำเป็น | `.warnyin/template/stages/[topic]/design.md` |
+| `tasks/<task-name>/spec.md` | spec เฉพาะ task (ดูข้อ 6) | จำเป็นต่อ task | `.warnyin/template/stages/[topic]/tasks/[task-name]/spec.md` |
+| `tasks/<task-name>/standard.md` | pattern โค้ด/shared component อิง techstack standard | จำเป็นต่อ task | `.warnyin/template/stages/[topic]/tasks/[task-name]/standard.md` |
+| `tasks/<task-name>/rule.md` | rule ที่ต้อง follow + rule ที่เสนอเพิ่ม (รอ SHIP) | จำเป็นต่อ task | `.warnyin/template/stages/[topic]/tasks/[task-name]/rule.md` |
+| `tasks/<task-name>/task.md` | รายละเอียด task + sub-tasks + dependency + acceptance | จำเป็นต่อ task | `.warnyin/template/stages/[topic]/tasks/[task-name]/task.md` |
+| `tasks/<task-name>/issue.md` | ผล dry-run: defer/blocker ที่พบ + แนวทางแก้ + สถานะ | ✅ เฉพาะเมื่อ dry-run แล้วพบ issue | `.warnyin/template/stages/[topic]/tasks/[task-name]/issue.md` |
 
 ---
 

package/{warnyin → .warnyin}/workflow/stages/discovery.md

@@ -23,7 +23,7 @@ Discovery คือขั้นตอน **ค้นหาข้อมูล + d
 2. `docs/rule.md`, `docs/infra.md` — กฎและโครงสร้างพื้นฐาน
 3. `docs/codemap/index.md` — แผนที่โค้ด (ไปอ่านโค้ดจริงต่อได้)
 4. `docs/features/*`, `docs/techstack/*` — ฟีเจอร์เดิม + tech stack ของแต่ละ component
-5. `warnyin/stages/context.md` และ topic ที่ `achieved/` ที่ใกล้เคียง — เคยทำอะไรไปแล้ว
+5. `docs/stages/context.md` และ topic ที่ `achieved/` ที่ใกล้เคียง — เคยทำอะไรไปแล้ว
 
 ---
 
@@ -36,7 +36,7 @@ Discovery คือขั้นตอน **ค้นหาข้อมูล + d
 5. **เดินทีละกิ่งของ decision tree:** ไล่ทุกแขนงของการตัดสินใจ แก้ความสัมพันธ์ระหว่างการตัดสินใจทีละจุด ไม่ข้าม
 6. **บันทึกทันทีที่ตกลงได้:** พอได้ข้อสรุปที่ชัดเจนในประเด็นไหน ให้จดลง `discovery.md` (decision log) เลย ไม่รอจบ
 7. **ทุกข้อสรุปต้องสอดคล้องกับโปรเจกต์:** อ้างอิงกลับไปที่ `docs/project.md` และข้อจำกัดจริงเสมอ
-8. **ใช้ role lens ตอนตั้งคำถาม:** มอง scope ผ่าน checklist ของ **BA** (`warnyin/workflow/roles/ba.md` — business process, ข้อยกเว้น, ข้อมูล, ข้อจำกัด) และ **PO** (`warnyin/workflow/roles/po.md` — คุณค่า, priority, MVP, scope out, success metric) เพื่อให้คำถามครบมุมไม่หลุดประเด็น
+8. **ใช้ role lens ตอนตั้งคำถาม:** มอง scope ผ่าน checklist ของ **BA** (`.warnyin/workflow/roles/ba.md` — business process, ข้อยกเว้น, ข้อมูล, ข้อจำกัด) และ **PO** (`.warnyin/workflow/roles/po.md` — คุณค่า, priority, MVP, scope out, success metric) เพื่อให้คำถามครบมุมไม่หลุดประเด็น
 
 ### โหมด "ซักถามฉันหน่อย" (grill mode)
 เมื่อ user สั่ง grill → **ซักถามอย่างไม่หยุดหย่อนทุกแง่มุมของแผน** จนเข้าใจตรงกัน:
@@ -46,7 +46,7 @@ Discovery คือขั้นตอน **ค้นหาข้อมูล + d
 
 ## 4. ลำดับขั้นการทำงาน (process loop)
 
-1. **เตรียมพื้นที่:** ถ้ายังไม่มีโฟลเดอร์ topic → copy `warnyin/template/stages/[topic]/` เป็น `warnyin/stages/<slug>/` (slug = kebab-case ของหัวข้องาน)
+1. **เตรียมพื้นที่:** ถ้ายังไม่มีโฟลเดอร์ topic → copy `.warnyin/template/stages/[topic]/` เป็น `docs/stages/<slug>/` (slug = kebab-case ของหัวข้องาน)
 2. **Ground:** อ่าน Input ในข้อ 2 ให้ครบ สรุปความเข้าใจเริ่มต้น 3-5 บรรทัด ให้ user ยืนยัน
 3. **ตี scope กว้าง→แคบ ผ่านการสัมภาษณ์:** วนลูป — ถาม 1 ข้อ (พร้อม recommended answer) → user ตอบ → จดผลลง decision log → ถ้าตอบได้ด้วยโค้ดให้ไปอ่านเอง
 4. **research คู่ขนาน:** สิ่งที่ต้องค้นจริง (prior art, ทางเลือก technical, ข้อจำกัด) → จดลง `research.md` พร้อม evidence/links
@@ -54,14 +54,14 @@ Discovery คือขั้นตอน **ค้นหาข้อมูล + d
 
 ---
 
-## 5. Output (สร้างที่ `warnyin/stages/<slug>/`)
+## 5. Output (สร้างที่ `docs/stages/<slug>/`)
 
 | ไฟล์ | เนื้อหา | template |
 |---|---|---|
-| `discovery.md` | decision log + shared understanding + scope + PRD ย่อ + feature ideas | `warnyin/template/stages/[topic]/discovery.md` |
-| `research.md` | คำถามวิจัย + วิธี/แหล่ง + findings + code inspection + implication | `warnyin/template/stages/[topic]/research.md` |
+| `discovery.md` | decision log + shared understanding + scope + PRD ย่อ + feature ideas | `.warnyin/template/stages/[topic]/discovery.md` |
+| `research.md` | คำถามวิจัย + วิธี/แหล่ง + findings + code inspection + implication | `.warnyin/template/stages/[topic]/research.md` |
 
-> เริ่มจาก template (ไฟล์ใน `warnyin/template/stages/[topic]/`) เป็นโครง แล้วเติมเนื้อหาจริง อัปเดตทุกครั้งที่ได้ข้อสรุปใหม่
+> เริ่มจาก template (ไฟล์ใน `.warnyin/template/stages/[topic]/`) เป็นโครง แล้วเติมเนื้อหาจริง อัปเดตทุกครั้งที่ได้ข้อสรุปใหม่
 
 ---
 

package/{warnyin → .warnyin}/workflow/stages/ship.md

@@ -1,7 +1,7 @@
 # Stage: SHIP
 
 > **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
-> เป้าหมาย: **ส่งมอบ** — promote ความรู้ระดับ topic ขึ้นเอกสารกลางใน `docs/` + archive topic เข้า `warnyin/stages/achieved/`
+> เป้าหมาย: **ส่งมอบ** — promote ความรู้ระดับ topic ขึ้นเอกสารกลางใน `docs/` + archive topic เข้า `docs/stages/achieved/`
 
 ---
 
@@ -17,7 +17,7 @@
 
 ## 2. Input ที่ต้องอ่านก่อนเริ่ม
 
-1. `warnyin/stages/<slug>/` **ทุกไฟล์** — discovery, business, proposal, design, build, test, verify, troubleshooting, tasks/*
+1. `docs/stages/<slug>/` **ทุกไฟล์** — discovery, business, proposal, design, build, test, verify, troubleshooting, tasks/*
    → เข้าใจว่า topic นี้ **ทำอะไร ทำอย่างไร** และเกิดความรู้อะไรใหม่บ้าง
 2. `tasks/<task>/rule.md` section "เสนอเพิ่ม rule ใหม่ (รอ SHIP)" + `standard.md` — rule/standard ใหม่ที่ note ค้างไว้
 3. เอกสารกลางปลายทางที่จะอัปเดต — `docs/features/`, `docs/techstack/<component>/*`, `docs/rule.md`,
@@ -30,7 +30,7 @@
 
 1. **เข้าใจก่อน promote** — อ่าน topic ทั้งหมดให้เข้าใจว่าทำอะไร/ทำอย่างไร แล้วค่อยตัดสินใจว่าความรู้ชิ้นไหนควรขึ้นไฟล์กลางไหน
 2. **ขอ user ยืนยัน "ครั้งเดียวก่อนลงมือ"** — สรุป promotion plan (feature ใหม่หรือปรับปรุง, ไฟล์กลางที่จะอัปเดต + สาระที่จะใส่, ชื่อโฟลเดอร์ archive) ให้ user อนุมัติ แล้วจึง execute ไม่ถามซ้ำระหว่างทาง
-3. **★ Archive ก่อนอัปเดตเอกสาร** — ย้ายทั้งโฟลเดอร์ `warnyin/stages/<slug>/` → `warnyin/stages/achieved/<YYYY-MM-DD>-<slug>/` (วันที่ของวันที่ SHIP) **ก่อน** เริ่มแก้ `docs/` แล้วอ่านเนื้อหาจาก path ใหม่ระหว่าง promote
+3. **★ Archive ก่อนอัปเดตเอกสาร** — ย้ายทั้งโฟลเดอร์ `docs/stages/<slug>/` → `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` (วันที่ของวันที่ SHIP) **ก่อน** เริ่มแก้ `docs/` แล้วอ่านเนื้อหาจาก path ใหม่ระหว่าง promote
 4. **กลั่น ไม่ใช่ copy ดิบ** — merge สาระเข้าโครงสร้างของไฟล์กลางเดิม ระวัง duplicate/ขัดแย้งกับเนื้อหาที่มีอยู่; เขียนแบบ "ความรู้ถาวร" ไม่ใช่บันทึกรายงาน
 5. **เอกสารต้องตรงโค้ดจริง** — structure/codemap อัปเดตจากการดูโค้ดจริง ไม่ใช่จากความจำหรือ design เดิม
 6. **อย่าเดา** — เนื้อหาที่ไม่แน่ใจว่าควร promote หรือควรวางไว้ไฟล์ไหน → ถามทีละข้อ + เสนอคำตอบที่แนะนำ
@@ -40,17 +40,17 @@
 
 ## 4. ลำดับขั้นการทำงาน (process)
 
-1. **อ่านทำความเข้าใจ topic:** อ่าน `warnyin/stages/<slug>/` ทุกไฟล์ — topic นี้ทำอะไร ทำอย่างไร เกิดความรู้ใหม่อะไรบ้าง (เช็คก่อนว่า VERIFY ผ่าน Gate แล้ว — มี `verify.md` สรุปผลผ่าน)
+1. **อ่านทำความเข้าใจ topic:** อ่าน `docs/stages/<slug>/` ทุกไฟล์ — topic นี้ทำอะไร ทำอย่างไร เกิดความรู้ใหม่อะไรบ้าง (เช็คก่อนว่า VERIFY ผ่าน Gate แล้ว — มี `verify.md` สรุปผลผ่าน)
 2. **จำแนก feature:** สิ่งที่ทำเป็น **feature ใหม่** หรือ **ปรับปรุง feature เดิม** (เทียบกับ `docs/features/` ที่มีอยู่)
 3. **สรุป promotion plan + ขออนุมัติ (ครั้งเดียว):** feature ใหม่/ปรับปรุง, รายการไฟล์กลางที่จะอัปเดต + สาระ, ชื่อโฟลเดอร์ archive → รอ user ไฟเขียว
-4. **★ Archive:** ย้ายทั้งโฟลเดอร์ → `warnyin/stages/achieved/<YYYY-MM-DD>-<slug>/` (ใช้ `git mv` ถ้าเป็น git repo)
+4. **★ Archive:** ย้ายทั้งโฟลเดอร์ → `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` (ใช้ `git mv` ถ้าเป็น git repo)
 5. **อัปเดตเอกสารกลาง** (อ่านเนื้อหาจาก path ใน achieved):
    1. **`docs/features/<feature-name>/`** — feature ใหม่ → สร้างโฟลเดอร์ใหม่ (`feature.md` + `business.md`); ปรับปรุง feature เดิม → อัปเดตโฟลเดอร์เดิม โดยใช้เนื้อหาจาก `business.md` / `proposal.md` / `design.md` ของ topic
    2. **`docs/techstack/<component>/`** — `rule.md` / `standard.md` (จาก note "รอ SHIP" ใน tasks), `structure.md` (โครงสร้างที่เปลี่ยน), `test.md` (merge แผนเทสจาก `test.md` ของ topic)
    3. **`docs/rule.md`** — global rule ใหม่/ที่เปลี่ยน (เฉพาะข้อที่เป็นกฎระดับโปรเจกต์ ไม่ผูกกับ component เดียว)
    4. **`docs/troubleshooting.md`** — merge entry จาก `troubleshooting.md` ของ topic (ปัญหา/อาการ/root cause/วิธีแก้/ป้องกันซ้ำ)
    5. **`docs/infra.md` + `docs/project.md`** — เฉพาะถ้ามีข้อมูลที่เกี่ยวข้อง (env/service ใหม่, scope/เป้าหมายโปรเจกต์ที่ขยับ)
-   6. **`docs/codemap/` ทั้งหมด** — อัปเดต code map ให้ตรงกับโค้ดจริงปัจจุบัน ทำตาม playbook `warnyin/workflow/codemap.md` (Claude Code: `/warnyin:update-codemaps`)
+   6. **`docs/codemap/` ทั้งหมด** — อัปเดต code map ให้ตรงกับโค้ดจริงปัจจุบัน ทำตาม playbook `.warnyin/workflow/codemap.md` (Claude Code: `/warnyin:update-codemaps`)
 6. **เขียนสรุปส่งมอบ:** `achieved/<YYYY-MM-DD>-<slug>/ship.md` — feature ใหม่/ปรับปรุง, เอกสารกลางที่อัปเดต (ไฟล์ → สาระ), note ที่ตัดทิ้งพร้อมเหตุผล
 7. **ปิดงาน:** รายงาน user ว่าส่งมอบครบ — topic ปิดสมบูรณ์
 
@@ -66,13 +66,13 @@
 | `docs/troubleshooting.md` | KB ปัญหา-วิธีแก้ที่ merge เข้า |
 | `docs/infra.md`, `docs/project.md` | อัปเดตเฉพาะถ้ามีข้อมูลเกี่ยวข้อง |
 | `docs/codemap/` | code map ตรงกับโค้ดจริงปัจจุบัน |
-| `warnyin/stages/achieved/<YYYY-MM-DD>-<slug>/` | ทั้ง topic ที่ archive แล้ว + `ship.md` (สรุปการส่งมอบ) |
+| `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` | ทั้ง topic ที่ archive แล้ว + `ship.md` (สรุปการส่งมอบ) |
 
 ---
 
 ## 6. Gate → topic ปิดสมบูรณ์เมื่อ
 
-- [ ] topic ถูกย้ายไป `warnyin/stages/achieved/<YYYY-MM-DD>-<slug>/` แล้ว (ไม่เหลือใน `warnyin/stages/`)
+- [ ] topic ถูกย้ายไป `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` แล้ว (ไม่เหลือใน `docs/stages/`)
 - [ ] `docs/features/` สะท้อน feature ใหม่/ที่ปรับปรุงแล้ว
 - [ ] note "รอ SHIP" ทุกข้อใน `tasks/*/rule.md` + `standard.md` ถูกพิจารณาครบ — promote หรือตัดทิ้งพร้อมเหตุผล
 - [ ] `docs/troubleshooting.md` รวม entry จาก topic แล้ว