@warnyin/agents 0.5.2 → 0.7.0

package/{warnyin → src/.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 แล้ว

package/{warnyin → src/.warnyin}/workflow/stages/verify.md

@@ -14,7 +14,7 @@
 
 ## 2. ก่อนเทส — อ่านให้เข้าใจก่อนเสมอ
 
-1. **spec + tasks ทั้งหมด** — `warnyin/stages/<slug>/tasks/*/spec.md` + `task.md`, `design.md`, `proposal.md`
+1. **spec + tasks ทั้งหมด** — `docs/stages/<slug>/tasks/*/spec.md` + `task.md`, `design.md`, `proposal.md`
    → เข้าใจ **จุดประสงค์ของ topic** และสิ่งที่ต้องยืนยัน (อย่าเทสผ่านๆ โดยไม่เข้าใจ)
 2. **`docs/techstack/<component>/test.md`** — guideline ว่าเทสยังไง (เช่น frontend: e2e smoke ผ่าน **playwright-cli**)
    → ถ้า **ไม่มี** guideline → แนะนำว่าควรเทสแบบไหน/วิธีใดได้บ้าง แล้วเขียนแผนลง `test.md`
@@ -30,16 +30,16 @@
 3. **ใช้ guideline จาก `test.md`** ของ techstack; ถ้าไม่มีให้เสนอวิธีเทสที่เหมาะแล้วเขียนแผนเอง
 4. **Frontend → verify UX/UI ด้วย** (ไม่ใช่แค่ functional — ดู layout, state, flow, ความถูกต้องของหน้าจอ)
 5. **ข้อไหน verify ไม่ผ่าน → แก้จนผ่าน (loop)** และ **นับจำนวนการแก้ไข/จำนวนรอบ**
-6. **ปัญหายาก/ซ้ำในขั้นนี้ → บันทึก `warnyin/stages/<slug>/troubleshooting.md`** (เหมือน BUILD); เจอปัญหา → อ่าน `docs/troubleshooting.md` ก่อน
+6. **ปัญหายาก/ซ้ำในขั้นนี้ → บันทึก `docs/stages/<slug>/troubleshooting.md`** (เหมือน BUILD); เจอปัญหา → อ่าน `docs/troubleshooting.md` ก่อน
 7. **นาน/หลายรอบเกินไป → พิจารณาถาม user ทีละข้อ + เสนอคำตอบที่แนะนำ** (อย่าวนแก้เงียบๆ ไม่จบ)
 8. **ห้ามแตะไฟล์กลางใน `docs/`** — แผนเทสเขียนระดับ topic ที่ `test.md` ก่อน รอ SHIP merge เข้า `docs/techstack/<component>/test.md`
-9. **สวม role QA** — ทำตาม role card `warnyin/workflow/roles/qa.md` (lens: คิดแบบผู้ใช้จริง + คนหาเรื่อง, edge case, regression; checklist ครบทุกข้อ)
+9. **สวม role QA** — ทำตาม role card `.warnyin/workflow/roles/qa.md` (lens: คิดแบบผู้ใช้จริง + คนหาเรื่อง, edge case, regression; checklist ครบทุกข้อ)
 
 ---
 
 ## 4. ลำดับขั้นการทำงาน (process)
 
-0. **★ เช็ค context window ก่อนเริ่ม:** ประเมินว่า context ของ session ปัจจุบันถูกใช้ไปมากน้อยแค่ไหน — ถ้าใช้ไปเยอะหรือ **เกินครึ่ง** → **เสนอ user ให้ `/compact` หรือ `/clear` ก่อนเสมอ** แล้วค่อยเริ่ม VERIFY ใน context ที่โล่ง (สถานะงานอยู่ในไฟล์ `warnyin/stages/<slug>/` ครบ ไม่หายไปกับ context) — VERIFY เป็นลูปเทส-แก้ที่อาจยาว ต้องมี context เหลือมากพอ; เครื่องอื่นที่ไม่มีคำสั่งนี้ → แนะนำเริ่ม session ใหม่
+0. **★ เช็ค context window ก่อนเริ่ม:** ประเมินว่า context ของ session ปัจจุบันถูกใช้ไปมากน้อยแค่ไหน — ถ้าใช้ไปเยอะหรือ **เกินครึ่ง** → **เสนอ user ให้ `/compact` หรือ `/clear` ก่อนเสมอ** แล้วค่อยเริ่ม VERIFY ใน context ที่โล่ง (สถานะงานอยู่ในไฟล์ `docs/stages/<slug>/` ครบ ไม่หายไปกับ context) — VERIFY เป็นลูปเทส-แก้ที่อาจยาว ต้องมี context เหลือมากพอ; เครื่องอื่นที่ไม่มีคำสั่งนี้ → แนะนำเริ่ม session ใหม่
 1. **เข้าใจจุดประสงค์:** อ่าน spec/tasks/design → สรุปสิ่งที่ต้อง verify (functional + UX/UI)
 2. **วางแผนเทส → เขียน `test.md`:** ตาม guideline `docs/techstack/<component>/test.md`; ไม่มีก็เสนอวิธี (e2e smoke / integration / manual ฯลฯ) แล้วเขียนแผน
 3. **เตรียม local env:** รัน service ที่เกี่ยวข้องตาม `infra.md`
@@ -50,7 +50,7 @@
 
 ---
 
-## 5. Output (สร้างที่ `warnyin/stages/<slug>/`)
+## 5. Output (สร้างที่ `docs/stages/<slug>/`)
 
 | ไฟล์ | เนื้อหา | ปลายทางตอน SHIP |
 |---|---|---|

package/{AGENTS.md → src/AGENTS.md}

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

package/{bin → src/bin}/cli.mjs

@@ -24,41 +24,57 @@ if (args.has('--help') || args.has('-h')) {
 ใช้งาน:
   npx @warnyin/agents             ติดตั้ง (ข้ามไฟล์ที่มีอยู่แล้ว ไม่เขียนทับ)
   npx @warnyin/agents --update    อัปเดต playbook กลางเป็นเวอร์ชันล่าสุด
-                                  (เขียนทับเฉพาะ warnyin/workflow/, .claude/commands/warnyin/,
-                                   template warnyin/template/stages/[topic] — ไม่แตะ docs/ และงานจริง)
+                                  (เขียนทับเฉพาะ .warnyin/workflow/, .claude/commands/warnyin/,
+                                   template .warnyin/template/stages/[topic] — ไม่แตะ docs/ และงานจริง)
   npx @warnyin/agents --dry-run   แสดงรายการไฟล์ที่จะสร้าง/อัปเดต โดยไม่เขียนจริง
 
 หลังติดตั้ง: เปิด Claude Code ในโปรเจกต์ แล้วรัน /warnyin:init ให้ agent วิเคราะห์โปรเจกต์ + เติม docs/`)
   process.exit(0)
 }
 
+// guard กัน self-install — เก็บไว้แบบ defensive (zero-cost)
+// หลังย้าย source เข้า src/ → pkgRoot = src/ (sibling ของ bin/) จึงแทบไม่มีทาง === target (repo root / temp sandbox)
+// → guard นี้เป็น no-op โดยตั้งใจในเคสปกติ/sandbox; ยังคงดักได้เฉพาะ edge case ที่ install ลงโฟลเดอร์ที่เป็น src/ เอง
 if (path.resolve(pkgRoot) === path.resolve(target)) {
   console.error('✖ กำลังรันอยู่ใน repo ของ warnyin-agents เอง — ให้ cd ไปที่โปรเจกต์ปลายทางก่อน')
   process.exit(1)
 }
 
 // โครงเก่า (≤0.2.x): workflow/ + warnyin-stages/ ที่ root — เตือนให้ย้ายเอง ไม่แตะงานจริงของ user
-const legacy = ['workflow', 'warnyin-stages'].filter((d) => fs.existsSync(path.join(target, d)))
-if (legacy.length) {
-  console.warn(`⚠ พบโครงเลย์เอาต์เก่า (≤0.2.x): ${legacy.join(', ')}
-เวอร์ชันนี้ย้ายทุกอย่างไปใต้ warnyin/ — แนะนำย้ายด้วยตัวเองก่อน:
-  1. git mv warnyin-stages warnyin/stages          # งานจริงของคุณ (ปลอดภัย ไม่ถูกแตะโดย installer)
-  2. git rm -r workflow                            # playbook เก่า (เวอร์ชันใหม่จะอยู่ที่ warnyin/workflow)
-  3. ลบ template เก่าถ้ามี: "warnyin/stages/[topic]", "docs/techstack/[component]", "docs/features/[feature-name]"
-     (ย้ายไปรวมที่ warnyin/template/ แล้ว)
+const legacyV2 = ['workflow', 'warnyin-stages'].filter((d) => fs.existsSync(path.join(target, d)))
+if (legacyV2.length) {
+  console.warn(`⚠ พบโครงเลย์เอาต์เก่า (≤0.2.x): ${legacyV2.join(', ')}
+เวอร์ชันนี้ย้าย core ไปใต้ .warnyin/ และงานจริงไป docs/stages/ — แนะนำย้ายด้วยตัวเองก่อน:
+  1. git mv warnyin-stages docs/stages             # งานจริงของคุณ (ปลอดภัย ไม่ถูกแตะโดย installer)
+  2. git rm -r workflow                            # playbook เก่า (เวอร์ชันใหม่จะอยู่ที่ .warnyin/workflow)
 แล้วรันคำสั่งนี้อีกครั้ง\n`)
 }
 
+// โครงเก่า (0.3–0.5.x): ทุกอย่างอยู่ใต้ warnyin/ ที่ root — เวอร์ชันนี้แยกเป็น .warnyin/ (core) + docs/stages (งานจริง)
+const legacyV5 = ['workflow', 'template', 'installer', 'stages'].filter((d) =>
+  fs.existsSync(path.join(target, 'warnyin', d)),
+)
+if (legacyV5.length) {
+  console.warn(`⚠ พบโครงเลย์เอาต์เก่า (0.3–0.5.x): warnyin/{${legacyV5.join(', ')}}
+เวอร์ชันนี้ย้าย core ไป .warnyin/ และงานจริงไป docs/stages/ — แนะนำย้ายด้วยตัวเองก่อน:
+  1. git mv warnyin/stages docs/stages             # งานจริงของคุณ (active + achieved) — ปลอดภัย ไม่ถูกแตะ
+  2. git rm -r warnyin/workflow warnyin/template   # core เก่า (เวอร์ชันใหม่ installer จะวางที่ .warnyin/)
+แล้วรันคำสั่งนี้อีกครั้ง — installer จะวาง .warnyin/ ชุดใหม่ให้\n`)
+}
+
 // core = playbook กลาง + command + agent + template — เขียนทับได้เมื่อ --update
 const CORE = [
-  path.join('warnyin', 'workflow'),
-  path.join('warnyin', 'template'),
+  path.join('.warnyin', 'workflow'),
+  path.join('.warnyin', 'template'),
   path.join('.claude', 'commands', 'warnyin'),
   path.join('.claude', 'agents'),
 ]
-// scaffold = พื้นที่ทำงาน — เป็นข้อมูลของโปรเจกต์ ไม่เขียนทับเด็ดขาด
-// (เจาะจง warnyin/stages — warnyin/workflow + warnyin/template อยู่ใน CORE แล้ว ส่วน warnyin/installer เป็นของ installer ไม่ copy ไป target)
-const SCAFFOLD = [path.join('warnyin', 'stages')]
+// scaffold = พื้นที่ทำงานเปล่าของโปรเจกต์ — installer "สร้างเอง" ไม่ copy tree จาก package
+// (สำคัญ: ถ้า copy docs/stages จาก pkgRoot งานจริงของ repo ต้นทางจะรั่วไป target ทุกครั้ง — ดู verify installer-test-ci)
+const SCAFFOLD_FILES = [
+  path.join('docs', 'stages', 'context.md'), // บริบทงานที่จดไว้ (next/discovery/explore อ่าน "ถ้ามี")
+  path.join('docs', 'stages', 'achieved', '.gitkeep'), // ให้ git track โฟลเดอร์ archive เปล่า
+]
 
 const stats = { created: 0, updated: 0, skipped: 0 }
 
@@ -91,8 +107,25 @@ function copyTree(relDir, { overwrite }) {
   }
 }
 
-/** seed docs/ ของโปรเจกต์จาก warnyin/template/docs — ข้ามโฟลเดอร์ template `[...]` (ไว้ให้ /warnyin:init copy เป็นชื่อจริง) และไม่ทับไฟล์ที่มีอยู่ */
-const TEMPLATE_DOCS = path.join('warnyin', 'template', 'docs')
+/** สร้างโครง scaffold เปล่าของ docs/stages เอง (ไม่ copy จาก package — กันงานจริงของ repo ต้นทางรั่วไป target) — ไม่ทับไฟล์ที่มีอยู่ */
+function ensureScaffold() {
+  for (const rel of SCAFFOLD_FILES) {
+    const dest = path.join(target, rel)
+    if (fs.existsSync(dest)) {
+      stats.skipped++
+      continue
+    }
+    if (!DRY) {
+      fs.mkdirSync(path.dirname(dest), { recursive: true })
+      fs.writeFileSync(dest, '')
+    }
+    stats.created++
+    console.log(`  + ${rel}`)
+  }
+}
+
+/** seed docs/ ของโปรเจกต์จาก .warnyin/template/docs — ข้ามโฟลเดอร์ template `[...]` (ไว้ให้ /warnyin:init copy เป็นชื่อจริง) และไม่ทับไฟล์ที่มีอยู่ */
+const TEMPLATE_DOCS = path.join('.warnyin', 'template', 'docs')
 function seedDocs(relDir = TEMPLATE_DOCS) {
   const srcDir = path.join(pkgRoot, relDir)
   if (!fs.existsSync(srcDir)) return
@@ -142,9 +175,9 @@ function installRootDoc(name, srcPath) {
 console.log(`Warnyin Standard Workflow → ${target}${DRY ? '  (dry-run)' : ''}\n`)
 
 for (const dir of CORE) copyTree(dir, { overwrite: UPDATE })
-for (const dir of SCAFFOLD) copyTree(dir, { overwrite: false })
+ensureScaffold()
 seedDocs()
-installRootDoc('CLAUDE.md', path.join(pkgRoot, 'warnyin', 'installer', 'templates', 'CLAUDE.md'))
+installRootDoc('CLAUDE.md', path.join(pkgRoot, '.warnyin', 'installer', 'templates', 'CLAUDE.md'))
 installRootDoc('AGENTS.md', path.join(pkgRoot, 'AGENTS.md'))
 
 console.log(`\nสรุป: สร้างใหม่ ${stats.created} · อัปเดต ${stats.updated} · ข้าม (มีอยู่แล้ว) ${stats.skipped}`)

package/CLAUDE.md

@@ -1,40 +0,0 @@
-# CLAUDE.md
-
-repo มาตรฐานกลางของ **ways of work** สำหรับทุกโปรเจกต์ เดินงานผ่าน 5 stage:
-`Discovery (optional) ▶ DESIGN ▶ BUILD ▶ VERIFY ▶ SHIP`
-
-## กฎหลัก
-- แก่นของแต่ละ stage เป็น single source of truth ที่ `warnyin/workflow/stages/` — **ทำตาม playbook นั้นเสมอ** ก่อนเริ่มงานใน stage
-- อย่า duplicate logic ของ workflow ลงที่อื่น ถ้าต้องแก้พฤติกรรมให้แก้ที่ `warnyin/workflow/stages/`
-- output ของงานจริงเก็บใน `warnyin/stages/<slug>/` (copy จาก template `warnyin/template/stages/[topic]/`)
-- ความรู้ถาวรระดับโปรเจกต์อยู่ใน `docs/` — เริ่มอ่าน `docs/project.md` เสมอใน Discovery
-- role card กลางอยู่ที่ `warnyin/workflow/roles/` (BA/PO/SA/Tech Lead/Developer/QA/Security/Infra) — stage ไหนใช้ role ไหนดูใน playbook; reviewer subagent ของ Claude Code อยู่ที่ `.claude/agents/warnyin-*`
-
-## Slash commands (namespace `warnyin:`)
-- `/warnyin:init` → วิเคราะห์โปรเจกต์ + เติม `docs/` ครั้งแรกหลังติดตั้ง (`.claude/commands/warnyin/init.md` → `warnyin/workflow/init.md`)
-- `/warnyin:install-skill [role]` → ติดตั้ง skill เสริมประจำ role (รายการอยู่ที่ตารางใน `warnyin/workflow/roles/README.md`)
-- `/warnyin:update-codemaps` → สแกนโครงสร้าง + สร้าง/อัปเดต codemap แบบ token-lean ใน `docs/codemap/` (`warnyin/workflow/codemap.md`)
-- `/warnyin:explore [คำถาม]` → สำรวจ/ตอบคำถามแบบ read-only — ไม่สร้าง artifact ใดๆ จบที่คำตอบในแชท (`warnyin/workflow/explore.md`)
-- `/warnyin:next [slug]` → เช็คงานค้างทุก topic + แนะนำ command ถัดไป แบบ read-only (`warnyin/workflow/next.md`)
-- `/warnyin:discovery [topic]` → Discovery stage (`.claude/commands/warnyin/discovery.md` → `warnyin/workflow/stages/discovery.md`)
-- `/warnyin:design [slug] [change]` → DESIGN stage (`.claude/commands/warnyin/design.md` → `warnyin/workflow/stages/design.md`)
-- `/warnyin:build [slug]` → BUILD stage — fan-out sub-agent ตาม dependency (`warnyin/workflow/stages/build.md` + `warnyin/workflow/scripts/build-wave.mjs`)
-- `/warnyin:verify [slug]` → VERIFY stage — strategy tester เทส local env + UXUI แก้จนผ่าน (`warnyin/workflow/stages/verify.md`)
-- `/warnyin:ship [slug]` → SHIP stage — ส่งมอบ: promote ความรู้ขึ้น `docs/` + archive topic (`warnyin/workflow/stages/ship.md`)
-
-## การติดตั้งไปโปรเจกต์อื่น (npx installer)
-- `npx @warnyin/agents` (หรือสำรอง `npx github:warnyin/warnyin-agents`) → copy โครงทั้งหมดลงโปรเจกต์ปลายทาง (ข้ามไฟล์ที่มีอยู่, CLAUDE.md/AGENTS.md ที่มีอยู่จะต่อท้ายเป็น section)
-- `--update` → เขียนทับเฉพาะ core (`warnyin/workflow/`, `.claude/commands/warnyin/`, template ใน `warnyin/template/`) ไม่แตะ `docs/`/งานจริง
-- ตัว installer: `bin/cli.mjs` + template CLAUDE.md ของโปรเจกต์ปลายทางที่ `warnyin/installer/templates/CLAUDE.md` (แก้ commands list ที่ไหน ให้แก้ template นี้ด้วย; โฟลเดอร์นี้ไม่ถูก copy ไป target)
-- หลังติดตั้ง → รัน `/warnyin:init` เพื่อเติม `docs/`
-
-## รองรับหลาย AI
-repo นี้ tool-agnostic: Claude Code อ่าน `.claude/` + ไฟล์นี้, ส่วน Codex/Antigravity อ่าน `AGENTS.md`
-ทุกเครื่องชี้กลับมาที่ playbook กลางชุดเดียวกันใน `warnyin/workflow/stages/` — ดูภาพรวมที่ `warnyin/workflow/README.md`
-
-## สถานะการสร้าง workflow (อัปเดต 2026-06-04)
-ครบทั้ง 5 stage: Discovery ✅ · DESIGN ✅ · BUILD ✅ · VERIFY ✅ · SHIP ✅
-(playbook + command + template + build-wave.mjs ครบทุก stage)
-
-แพทเทิร์นการเติม/แก้ stage: playbook `warnyin/workflow/stages/<stage>.md` + command `.claude/commands/warnyin/<stage>.md` + อัปเดตตาราง stage ใน `AGENTS.md`/`CLAUDE.md`/`warnyin/workflow/README.md` + output template ใน `warnyin/template/stages/[topic]/`
-**สำคัญ: การเปลี่ยนพฤติกรรม stage ใดๆ ให้ user เป็นคนอธิบาย/ยืนยันก่อน อย่าเดาเอง**