@warnyin/agents 0.7.0 → 0.8.5

package/CHANGELOG.md

@@ -5,8 +5,61 @@
 รูปแบบอ้างอิง [Keep a Changelog](https://keepachangelog.com/en/1.1.0/)
 และโปรเจกต์ยึด [Semantic Versioning](https://semver.org/spec/v2.0.0.html)
 
+## Migration guide
+
+อัปเกรดจากรุ่นเก่าที่ layout ต่างไป (installer จะ **เตือนให้ย้ายเอง ไม่แตะงานจริงของคุณ**):
+
+> **ลำดับที่แนะนำ: ย้ายงานจริงก่อน แล้วค่อยรัน `npx @warnyin/agents`**
+> คำสั่งย้ายด้านล่างใช้รูปแบบ `git mv <เก่า>/* docs/stages/` (ย้าย *เนื้อหา* ไม่ใช่ทั้งโฟลเดอร์) จึงปลอดภัยทั้งกรณีที่ยังไม่มี `docs/stages/` และกรณีที่เผลอรัน installer ไปก่อน (installer สร้าง `docs/stages/` เปล่าให้แล้ว) — กันงานจริงไปซ้อนเป็น `docs/stages/stages/`
+
+| จากรุ่น | layout เดิม | ต้องทำเอง (งานจริงปลอดภัย ไม่ถูกแตะ) |
+|---|---|---|
+| **≤0.2.x** | core `workflow/` + งานจริง `warnyin-stages/` ที่ root | `mkdir -p docs/stages && git mv warnyin-stages/* docs/stages/` แล้วลบ core เก่า `rm -rf workflow warnyin-stages` |
+| **0.3–0.5.x** | ทุกอย่างใต้ `warnyin/{workflow,template,installer,stages}` | `mkdir -p docs/stages && git mv warnyin/stages/* docs/stages/` แล้วลบ core เก่า `rm -rf warnyin` |
+
+จากนั้นรัน installer อีกครั้ง — installer จะวาง `.warnyin/` (core) ชุดใหม่ + แยกงานจริงไว้ที่ `docs/stages/` ให้
+
+> **0.6.0 → 0.7.0:** ผู้ใช้ปลายทาง (`npx @warnyin/agents`) **ไม่ต้องทำอะไร** — payload ที่ติดตั้งคงเดิม การเปลี่ยนแปลงทั้งหมด (bin path → `src/`, dogfood 2-layer) เป็นเรื่องภายใน repo เท่านั้น; ผู้พัฒนา repo เอง (contributor) ดู [`CONTRIBUTING.md`](CONTRIBUTING.md)
+
 ## [Unreleased]
 
+## [0.8.5] - 2026-06-07
+
+### Added
+- **Model-tier guidance ใน context profile** — `src/.warnyin/workflow/contexts/{research,build,review}.md` เพิ่มบรรทัด "Model tier" ใน section Tool preference (generic: `research`→`deepest reasoning` · `build`→`balanced`/fan-out worker เชิงกลไก→`cheap` · `review`→`balanced+`) + ตาราง legend ใน `contexts/README.md` — แนะนำ model tier ตาม posture เพื่อคุม token/cost; **tool-agnostic** ไม่ผูกชื่อรุ่น (harness map เอง) · global `docs/rule.md` §1 payload-guidance-generic — `.md` ล้วน, ติดมากับ `--update` รอบถัดไป
+- **Worked-example pointer ใน README** — section "ตัวอย่างจริง (worked example)" ชี้ `docs/example-walkthrough.md` (เดิน topic จริง `cli-legacy-warning-fix` ครบ 5 stage บน repo) ให้ผู้ใช้ใหม่เห็น artifact จริง
+
+## [0.8.4] - 2026-06-07
+
+### Added
+- **Utility skills (Claude adapter, auto-invocable)** — 3 safe utility skill ใหม่ `src/.claude/skills/{update-codemaps,explore,next}/SKILL.md` (`/update-codemaps`, `/explore`, `/next`): Claude project skill ที่ model **auto-invoke ได้เอง (description-driven)** body ชี้ playbook กลางเดิม (`.warnyin/workflow/{codemap,explore,next}.md`) ไม่ duplicate — auto-invoke เฉพาะ utility **read-only safe**; ผู้ใช้ปลายทางรับ skills อัตโนมัติตอน `npx @warnyin/agents` / `--update`. command `/warnyin:*` เดิม **ไม่เปลี่ยน** (non-breaking); build/ship คงเป็น command user-only (irreversible). global `docs/rule.md` §1 skill-adapter convention
+
+### Changed
+- **installer/packaging รองรับ skills** — `cli.mjs` CORE +`.claude/skills`; `package.json files` +`src/.claude/skills` (nested dotfolder ระบุชัด); `verify-pack` ALLOWED_PREFIX +`src/.claude/skills/` + R1 assert `hasSkills` (skills เป็น required payload กันหล่นเงียบ); test suite 18→19 (verify-pack 9→10)
+
+## [0.8.3] - 2026-06-07
+
+### Added
+- **Learned-rule capture ใน SHIP** — `ship.md` playbook (§3 principle 7 ขยาย + §4 step 1/3/5 + §6 gate) + command + template `[topic]/ship.md` (section "Learned rules"): จับ rule ที่ได้จากการทำจริง (planned + emergent จาก build/verify/troubleshooting) ด้วย `rule + evidence(บังคับ) + scope` แล้ว user ยืนยัน per-rule ก่อน promote — unify กับกลไก "รอ SHIP" เดิม; global `docs/rule.md` §1 + continuous-learning discipline + unify-in-place — `.md` ล้วน, ติดมากับ `--update` รอบถัดไป
+
+## [0.8.2] - 2026-06-07
+
+### Added
+- **Security checklist (agent-runtime + supply-chain)** — `roles/security.md` เพิ่ม section "Runtime / operational security" (secret isolation · no-egress · identity separation + Claude adapter note) + checklist item supply-chain/MCP (prompt-injection surface); `verify.md` §2 อ้าง runtime security ตอนรัน local env; `install-skill.md` step 4 เสริม warning prompt-injection; global `docs/rule.md` §3 ขยายเป็น Security baseline 2 มิติ (CI + agent-runtime) — `.md` ล้วน, ติดมากับ `--update` รอบถัดไป
+
+## [0.8.1] - 2026-06-07
+
+### Added
+- **Defensive rules** ใน BUILD/VERIFY playbook (§3) + developer.md/qa.md checklist + global `docs/rule.md` §1 — เวอร์ชัน enforce ของ "ห้ามเดา": (1) **investigate-before-edit** ก่อนแก้ไฟล์ที่มีอยู่ต้องเข้าใจ (ใครใช้/contract/เจตนา), (2) **config-protection** ห้ามแก้ config/test "เพื่อให้ผ่าน" แทนแก้โค้ดจริง — `.md` ล้วน, ติดมากับ `--update` รอบถัดไป
+
+## [0.8.0] - 2026-06-07
+
+### Added
+- **Context profiles** (`.warnyin/workflow/contexts/{research,build,review,README}.md`) — session-level posture 3 โหมด (สำรวจ/สร้าง/ตรวจ) คู่ขนานกับ role card (task-level lens); playbook แต่ละ stage มี callout ชี้ context ที่เข้าคู่ (Discovery→research · DESIGN→research+build · BUILD→build · VERIFY→review · SHIP→review) — `.md` ล้วน, ติดมากับ `--update` รอบถัดไป ไม่ต้องตั้งค่าเพิ่ม
+
+### Fixed
+- โครงสร้าง repo ใน `.warnyin/workflow/README.md` ให้ตรง layout จริงหลัง restructure 0.7.0 (`src/` layer + `.warnyin/`) — เดิมยังเป็น layout เก่า (`warnyin/`, `bin/cli.mjs`)
+
 ## [0.7.0] - 2026-06-07
 
 ### Added

package/README.md

@@ -27,6 +27,8 @@ npx @warnyin/agents --update    # อัปเดต playbook กลางเป
 - โปรเจกต์ที่มี `CLAUDE.md` / `AGENTS.md` อยู่แล้ว → installer **ต่อท้ายเป็น section** ไม่เขียนทับ
 - `--update` เขียนทับเฉพาะ core (`.warnyin/workflow/`, `.claude/commands/warnyin/`, template ใน `.warnyin/template/`) — ไม่แตะ `docs/` และงานจริง
 
+> **อัปเกรดจากรุ่นเก่า?** (`workflow/` หรือ `warnyin/` layout) ดู [Migration guide](CHANGELOG.md#migration-guide) ก่อนรัน installer รอบใหม่
+
 ## เริ่มใช้งาน
 
 ```bash
@@ -45,6 +47,13 @@ npx @warnyin/agents --update    # อัปเดต playbook กลางเป
 /warnyin:ship <slug>               # promote ความรู้ขึ้น docs/ + archive topic
 ```
 
+## ตัวอย่างจริง (worked example)
+
+อยากเห็นว่า "output ที่ทำดีแล้ว" หน้าตาเป็นยังไงก่อนเริ่ม topic ของตัวเอง?
+[`docs/example-walkthrough.md`](docs/example-walkthrough.md) ไล่ topic จริง (`cli-legacy-warning-fix`)
+ครบทั้ง 5 stage — เน้น **เหตุผลการตัดสินใจ** ของแต่ละ stage พร้อมลิงก์ไป artifact จริงใน `docs/stages/achieved/`
+(เปิดดูบน GitHub repo)
+
 ## แนวคิดหลัก: Tool-agnostic, single source of truth
 
 แก่นของ workflow (กฎ / ขั้นตอน / เกณฑ์ผ่าน) เขียน**ครั้งเดียว**เป็น markdown ใน `.warnyin/workflow/stages/`
@@ -61,7 +70,7 @@ AI แต่ละเครื่องมีแค่ adapter บางๆ ช
 ## โครงสร้างที่ติดตั้งลงโปรเจกต์
 
 ```
-warnyin/               # ★ ทุกอย่างของ workflow รวมใต้โฟลเดอร์เดียว
+.warnyin/              # ★ ทุกอย่างของ workflow รวมใต้โฟลเดอร์เดียว
   workflow/            #   playbook กลาง — single source of truth
     init.md            #     INIT: วิเคราะห์โปรเจกต์ + เติม docs/ ครั้งแรก
     roles/             #     role card: BA · PO · SA · Tech Lead · Developer · QA · Security · Infra
@@ -108,9 +117,27 @@ role card กลางที่ `.warnyin/workflow/roles/` — แต่ละ
 - Tech Lead/Security ผูกกับ built-in `/code-review` และ `/security-review` ของ Claude Code
 - skill เสริมต่อ role ติดตั้งด้วย `/warnyin:install-skill` (รายการกลาง: `.warnyin/workflow/roles/README.md`)
 
+## พัฒนา repo นี้ (contributor)
+
+repo นี้ใช้ **bootstrap / self-hosting**: source ของ workflow v-next อยู่ใน `src/` (committed/publish) ส่วน root ติดตั้ง release เสถียรไว้ dogfood (gitignored) — **clone แล้วต้อง bootstrap ก่อนใช้**:
+
+```bash
+git clone https://github.com/warnyin/warnyin-agents.git
+cd warnyin-agents
+npm run setup:dogfood    # ติดตั้ง release เสถียรลง root (.warnyin/.claude/CLAUDE.md/AGENTS.md — gitignored)
+npm test                 # black-box test installer (node --test, discover src/tests/)
+npm run setup:sandbox    # ทดสอบ v-next จาก src/ ลง temp dir (version skew — dogfood ที่ root ไม่โดนแตะ)
+```
+
+- พัฒนา workflow v-next ที่ `src/` · dogfood ที่ root = release เสถียร (แก้ `src/` ไม่กระทบ session ที่กำลังทำงาน)
+- รายละเอียดเต็ม: [`CONTRIBUTING.md`](CONTRIBUTING.md)
+
 ## Release เวอร์ชันใหม่ (สำหรับผู้ดูแล repo นี้)
 
+> publish payload มาจาก `src/` (allowlist `package.json files`) — `npm run verify:pack` เป็น gate ก่อน publish (CI ตรวจทุก PR): payload ต้องติด `src/.warnyin/`+`src/.claude/` ครบ ไม่มี tooling/docs รั่ว
+
 ```bash
+npm run verify:pack    # ตรวจ payload ก่อน (Windows: npm pack --dry-run --json → checkFiles)
 npm version patch      # bump เวอร์ชัน + git tag
 npm publish            # ขึ้น npm registry (มี OTP)
 git push --follow-tags

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@warnyin/agents",
-  "version": "0.7.0",
+  "version": "0.8.5",
   "description": "Warnyin Standard Workflow installer — 5-stage ways of work (Discovery/DESIGN/BUILD/VERIFY/SHIP) สำหรับทุกโปรเจกต์",
   "type": "module",
   "license": "MIT",
@@ -12,6 +12,7 @@
   },
   "scripts": {
     "test": "node --test",
+    "lint:md": "node src/scripts/lint-md.mjs",
     "verify:pack": "node src/scripts/verify-pack.mjs",
     "setup:dogfood": "node src/scripts/setup-dogfood.mjs",
     "setup:sandbox": "node src/scripts/setup-sandbox.mjs"
@@ -21,6 +22,7 @@
     "src/.warnyin",
     "src/.claude/commands",
     "src/.claude/agents",
+    "src/.claude/skills",
     "src/AGENTS.md",
     "README.md",
     "CHANGELOG.md",

package/src/.claude/commands/warnyin/build.md

@@ -27,3 +27,4 @@ argument-hint: "[slug ของ topic]"
 - ห้ามแก้ rule/standard กลางใน `docs/` (rule ใหม่ที่เสนอถูก note ไว้ใน `tasks/<task>/rule.md` รอ SHIP)
 - ปัญหายาก/ซ้ำที่แก้ได้ → `docs/stages/<slug>/troubleshooting.md` (SHIP จะยกขึ้น `docs/troubleshooting.md`)
 - เกณฑ์ปิด BUILD ดู Gate ข้อ 7 ของ playbook
+- คงเป็น command (user-only) โดยตั้งใจ — BUILD เป็น stateful/irreversible (สร้าง branch, fan-out, แก้ไฟล์) ต้องให้ user สั่งชัด ไม่ทำเป็น skill auto-invoke

package/src/.claude/commands/warnyin/install-skill.md

@@ -8,7 +8,7 @@ argument-hint: "[ชื่อ role เช่น sa, qa — เว้นว่า
 1. อ่านตาราง **"Skill เสริมต่อ role"** ใน `.warnyin/workflow/roles/README.md` — นั่นคือ single source of truth ของรายการ skill (**ห้าม hardcode รายการในไฟล์นี้** — แก้รายการให้แก้ที่ตารางนั้น)
 2. **เช็คสถานะก่อน:** ตัวไหนติดตั้งแล้วบ้าง — ดูจาก `npx skills ls -g` (ถ้าไม่มีคำสั่งนี้ให้ดูโฟลเดอร์ `~/.agents/skills/` และ `~/.claude/skills/`) — สรุปเป็นตาราง ติดตั้งแล้ว ✅ / ยังไม่ติดตั้ง ⬜
 3. ขอบเขต: $ARGUMENTS ระบุ role → เฉพาะ skill ของ role นั้น; เว้นว่าง → ทุกตัวที่ยังไม่ติดตั้ง
-4. **ให้ user เลือกก่อนติดตั้ง:** ใช้ AskUserQuestion (multiSelect) แสดงแต่ละตัวพร้อม ที่มา (`owner/repo@skill`) + คำเตือนว่าเป็น third-party (ไม่ใช่ official, ตรวจเนื้อหาได้ที่ skills.sh)
+4. **ให้ user เลือกก่อนติดตั้ง:** ใช้ AskUserQuestion (multiSelect) แสดงแต่ละตัวพร้อม ที่มา (`owner/repo@skill`) + คำเตือนว่าเป็น third-party (ไม่ใช่ official, ตรวจเนื้อหาได้ที่ skills.sh) — **third-party skill = instruction ที่ AI execute ต่อ (prompt-injection surface) ตรวจเนื้อหาก่อนติดตั้ง**
 5. **ติดตั้งทีละตัว:** `npx skills add <owner/repo@skill> -g -y` (global — reference ไม่ vendor เข้า repo) → รายงานผลรวม สำเร็จ/ล้มเหลว พร้อมวิธีแก้ถ้าล้ม
 6. รายการที่เป็น **Claude Code built-in** (`/code-review`, `/security-review`) ไม่ต้องติดตั้ง — แจ้งว่าพร้อมใช้อยู่แล้ว
 7. ปิดท้าย: แนะนำว่า role ไหนใน workflow จะหยิบ skill เหล่านี้ใช้ตอนไหน (ตาม section "Skill เสริม" ใน role card)

package/src/.claude/commands/warnyin/ship.md

@@ -7,13 +7,13 @@ argument-hint: "[slug ของ topic]"
 
 1. อ่าน `.warnyin/workflow/stages/ship.md` ให้ครบก่อน แล้วทำตามทุกหลักการอย่างเคร่งครัด
 2. slug: $ARGUMENTS — ถ้าไม่ระบุให้ถามก่อน ว่าจะ ship topic ไหน (ดูโฟลเดอร์ใน `docs/stages/`)
-3. **อ่านทำความเข้าใจ topic:** อ่าน `docs/stages/<slug>/` ทุกไฟล์ (รวม `tasks/*/rule.md` section "รอ SHIP" + `standard.md`) — topic นี้ทำอะไร ทำอย่างไร เกิดความรู้ใหม่อะไรบ้าง; เช็คว่า VERIFY ผ่าน Gate แล้ว (`verify.md` สรุปผลผ่าน) — ถ้ายังไม่ผ่าน → หยุด แจ้ง user
+3. **อ่านทำความเข้าใจ topic + รวบรวม learned-rule candidate:** อ่าน `docs/stages/<slug>/` ทุกไฟล์ — topic นี้ทำอะไร ทำอย่างไร เกิดความรู้ใหม่อะไรบ้าง; เช็คว่า VERIFY ผ่าน Gate แล้ว (`verify.md` สรุปผลผ่าน) — ถ้ายังไม่ผ่าน → หยุด แจ้ง user. รวบรวม learned-rule candidate เป็นตาราง (`rule + evidence + scope + promote?`): **planned** จาก `tasks/*/rule.md` §2 "รอ SHIP" + `standard.md` · **emergent** สแกนบทเรียนใน `build.md`/`verify.md`/`troubleshooting.md`/diff — `rule` ต้อง generalize (ไม่ใช่ incident), `evidence` บังคับ (pointer + ลิงก์ artifact; ไม่มี = ไม่ promote), `scope` = `component:<c>` หรือ `project`
 4. **จำแนก feature:** feature ใหม่ หรือปรับปรุง feature เดิม (เทียบกับ `docs/features/` ที่มีอยู่)
-5. **ขออนุมัติครั้งเดียว** — ใช้ AskUserQuestion สรุป promotion plan: feature ใหม่/ปรับปรุง, ไฟล์กลางที่จะอัปเดต + สาระที่จะใส่, ชื่อโฟลเดอร์ archive → รอ go/no-go (อย่าแก้ไฟล์ใดก่อนได้ไฟเขียว)
+5. **ขออนุมัติครั้งเดียว** — ใช้ AskUserQuestion สรุป promotion plan: feature ใหม่/ปรับปรุง, ไฟล์กลางที่จะอัปเดต + สาระที่จะใส่, ชื่อโฟลเดอร์ archive — **fold ตาราง learned-rule (rule + evidence + scope) เข้า approval เดียวกัน ให้ user ยืนยัน per-rule** (✅ promote / ✂️ ตัด + เหตุผล) → รอ go/no-go (อย่าแก้ไฟล์ใดก่อนได้ไฟเขียว)
 6. **★ Archive ก่อน:** ย้ายทั้งโฟลเดอร์ `docs/stages/<slug>/` → `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` (ใช้ `git mv`; วันที่ = วันที่ ship) แล้วอ่านเนื้อหาจาก path ใหม่ระหว่าง promote
 7. **อัปเดตเอกสารกลาง** (กลั่นเข้าโครงสร้างไฟล์เดิม ไม่ copy ดิบ, ระวัง duplicate):
    - `docs/features/<feature-name>/` — ใหม่ → สร้าง (feature.md + business.md); เดิม → อัปเดต โดยใช้ business/proposal/design ของ topic
-   - `docs/techstack/<component>/{rule,standard}.md` — จาก note "รอ SHIP" (พิจารณาครบทุกข้อ: promote หรือตัดทิ้งพร้อมเหตุผล)
+   - `docs/techstack/<component>/{rule,standard}.md` — learned-rule ที่ยืนยันแล้ว scope `component:<c>` + note "รอ SHIP" (พิจารณาครบทุกข้อ: promote หรือตัดทิ้งพร้อมเหตุผล); learned-rule scope `project` → `docs/rule.md`
    - `docs/techstack/<component>/structure.md` + `test.md` — โครงสร้างที่เปลี่ยน (ดูโค้ดจริง) + merge แผนเทสจาก `test.md` ของ topic
    - `docs/rule.md` — global rule ใหม่/ที่เปลี่ยน (เฉพาะกฎระดับโปรเจกต์)
    - `docs/troubleshooting.md` — merge entry จาก `troubleshooting.md` ของ topic
@@ -25,3 +25,4 @@ argument-hint: "[slug ของ topic]"
 - SHIP เป็นเรื่อง **เอกสาร + archive เท่านั้น** — ไม่ merge โค้ด (build branch → main จัดการเองนอก workflow)
 - เนื้อหาที่ไม่แน่ใจว่าควร promote/วางไฟล์ไหน → ถามทีละข้อ + เสนอคำตอบที่แนะนำ อย่าเดา
 - เกณฑ์ปิดดู Gate ข้อ 6 ของ playbook
+- คงเป็น command (user-only) โดยตั้งใจ — SHIP เป็น stateful/irreversible (archive ด้วย git mv, promote เอกสารกลาง) ต้องให้ user สั่งชัด ไม่ทำเป็น skill auto-invoke

package/src/.claude/skills/explore/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: explore
+description: สำรวจ/ตอบคำถามเกี่ยวกับโปรเจกต์แบบ read-only — ไม่สร้าง artifact ใดๆ จบที่คำตอบในแชท
+when_to_use: เมื่อต้องการเข้าใจ/ตอบคำถามเกี่ยวกับโครงสร้าง โค้ด หรือ logic ของโปรเจกต์ โดยไม่ต้องสร้างหรือแก้ไฟล์
+allowed-tools: Read, Grep, Glob, Bash(find:*), Bash(ls:*), Bash(grep:*)
+---
+
+ทำหน้าที่เป็น explorer ตาม **playbook กลาง** ของ workflow มาตรฐาน — อ่าน `.warnyin/workflow/explore.md` ให้ครบก่อน แล้วทำตามทุกหลักการอย่างเคร่งครัด (**read-only เด็ดขาด — ห้ามสร้าง/แก้/ลบไฟล์ใดๆ**, อ้าง `path:line`; ชี้ playbook ไม่ duplicate) — รับหัวข้อ/คำถามจาก request; ถ้าไม่ระบุ → ถาม user ว่าอยากสำรวจเรื่องอะไร

package/src/.claude/skills/next/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: next
+description: เช็คงานค้างทุก topic + แนะนำขั้นตอน/command ถัดไป แบบ read-only — ไม่สร้าง/แก้ไฟล์ใดๆ
+when_to_use: เมื่อต้องการรู้ว่าแต่ละ topic ค้างอยู่ stage ไหน + ควรรัน command อะไรถัดไป
+allowed-tools: Read, Grep, Glob, Bash(find:*), Bash(ls:*), Bash(grep:*)
+---
+
+ทำหน้าที่เป็น status reporter ตาม **playbook กลาง** ของ workflow มาตรฐาน — อ่าน `.warnyin/workflow/next.md` ให้ครบก่อน แล้วทำตามทุกหลักการอย่างเคร่งครัด (**read-only เด็ดขาด — ห้ามสร้าง/แก้/ลบไฟล์ใดๆ**, สรุปจาก evidence ในไฟล์จริง, แนะนำแล้วหยุด; ชี้ playbook ไม่ duplicate) — รับ slug จาก request (ไม่ระบุ = สแกนทุก topic ใน `docs/stages/` ยกเว้น `achieved/`)

package/src/.claude/skills/update-codemaps/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: update-codemaps
+description: Scan project structure and generate token-lean architecture codemaps (docs/codemap/)
+when_to_use: หลังเพิ่ม/ย้าย/ลบไฟล์ หรือเปลี่ยนโครงสร้างโปรเจกต์ → refresh docs/codemap/ ให้ตรงโครงจริง
+allowed-tools: Read, Grep, Glob, Bash(find:*), Bash(ls:*), Bash(grep:*)
+---
+
+ทำหน้าที่เป็น codemap generator ตาม **playbook กลาง** ของ workflow มาตรฐาน — อ่าน `.warnyin/workflow/codemap.md` ให้ครบก่อน แล้วทำตามทุกขั้นอย่างเคร่งครัด (ชี้ playbook ไม่ duplicate ขั้นตอน)

package/src/.warnyin/template/stages/[topic]/ship.md

@@ -20,10 +20,12 @@
 | `docs/infra.md` / `docs/project.md` | <!-- ถ้าเกี่ยวข้อง --> |
 | `docs/codemap/` | |
 
-## 3. note "รอ SHIP" ที่ตัดทิ้ง (ไม่ promote)
-| note | เหตุผลที่ตัด |
-|---|---|
-| | |
+## 3. Learned rules (planned + emergent)
+> กฎ generalize ที่จับจาก topic นี้ — planned (`tasks/*/rule.md` §2) + emergent (บทเรียนตอน build/verify/troubleshooting). evidence บังคับ; ไม่มี evidence = ไม่ promote. ครอบทั้งที่ promote และที่ตัด.
+
+| rule (generalize) | evidence (pointer + artifact) | scope (`component:<c>` / `project`) | promote? (✅ / ✂️ + เหตุผล) |
+|---|---|---|---|
+| | | | |
 
 ## 4. Archive
 - ย้ายจาก `docs/stages/<slug>/` → `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` เมื่อ <YYYY-MM-DD>

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

@@ -30,19 +30,20 @@ Discovery (optional) ──▶ DESIGN ──▶ BUILD ──▶ VERIFY ──▶
 
 ## โครงสร้าง repo
 
-```
-bin/cli.mjs            # npx installer — ติดตั้ง workflow ลงโปรเจกต์อื่น
+> โครงนี้คือสิ่งที่อยู่ใน **โปรเจกต์ที่ติดตั้งแล้ว** (installer วาง `.warnyin/`+`.claude/` ให้)
+> ตัว repo `warnyin-agents` เองเก็บ source ที่จะ publish ไว้ใต้ `src/` (เช่น `src/bin/cli.mjs`, `src/.warnyin/`) — ดู `CONTRIBUTING.md`
 
-warnyin/               # ★ ทุกอย่างของ workflow รวมใต้โฟลเดอร์เดียว
-  installer/templates/ #   template CLAUDE.md สำหรับโปรเจกต์ปลายทาง (installer ใช้เอง — ไม่ถูก copy ไป target)
+```
+.warnyin/              # ★ แก่นกลาง workflow (installer วางให้ — อัปเดตได้ด้วย --update)
   workflow/            # playbook กลาง — single source of truth
     README.md          #   ไฟล์นี้ — ภาพรวม + วิธีรองรับหลาย AI
     init.md            #   playbook: INIT — วิเคราะห์โปรเจกต์ + เติม docs/ ครั้งแรก
     codemap.md         #   playbook: CODEMAP — สแกน + สร้าง codemap แบบ token-lean
     explore.md         #   playbook: EXPLORE — สำรวจ/ตอบคำถามแบบ read-only ไม่สร้าง artifact
     next.md            #   playbook: NEXT — เช็คงานค้าง + แนะนำขั้นตอนถัดไป (read-only)
-    roles/             #   role card กลาง: ba, po, sa, tech-lead, developer, qa, security, infra
     stages/            #   discovery ✅ · design ✅ · build ✅ · verify ✅ · ship ✅
+    roles/             #   role card กลาง (task-level lens): ba, po, sa, tech-lead, developer, qa, security, infra
+    contexts/          #   context profile กลาง (session-level posture): research, build, review + README
     scripts/
       build-wave.mjs   #   Workflow script: fan-out sub-agent ต่อ task ใน wave (worktree)
   template/            # ★ template ทั้งหมดรวมที่เดียว
@@ -56,15 +57,20 @@ warnyin/               # ★ ทุกอย่างของ workflow รว
       project.md  rule.md  infra.md  troubleshooting.md  codemap/index.md
       techstack/[component]/               #   copy เป็น docs/techstack/<component> (โดย /warnyin:init)
       features/[feature-name]/             #   copy เป็น docs/features/<feature-name> (โดย SHIP)
-  stages/              # พื้นที่ทำงานจริง ตาม topic
-    context.md
-    achieved/          #   archive หลัง SHIP (<YYYY-MM-DD>-<slug>/)
+  installer/templates/ #   template CLAUDE.md ของ target (installer ใช้เอง — ไม่ถูก copy ไป target)
 
-docs/                  # ความรู้ถาวรระดับโปรเจกต์ — ของจริงล้วน (seed จาก .warnyin/template/docs)
+.claude/               # adapter Claude Code (ชี้กลับ playbook กลาง)
+  commands/warnyin/    #   slash command /warnyin:*
+  agents/              #   reviewer subagent warnyin-{sa,tech-lead,qa,security,infra}
+CLAUDE.md  AGENTS.md   # adapter + pointer ของ Claude / Codex·Antigravity
+
+docs/                  # ความรู้ถาวรระดับโปรเจกต์ + งานจริง — ของจริงล้วน (seed จาก template/docs)
   project.md           # ★ จุดเริ่มของ Discovery — อ่านก่อนเสมอ
   rule.md  infra.md
   troubleshooting.md   # ★ KB ปัญหา-วิธีแก้ (อ่านก่อนเมื่อ build เจอ error; SHIP ป้อนเข้า)
   codemap/  features/  techstack/
+  stages/              #   พื้นที่ทำงานจริง ตาม topic (<slug>/) + achieved/<YYYY-MM-DD>-<slug>/ หลัง SHIP
+```
 ```
 
 ---

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

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

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

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

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

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

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

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

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

@@ -16,6 +16,8 @@ implement vertical slice ที่รับมอบให้ **เสร็จ
 - [ ] ทำครบทุก sub-task — acceptance ทุกข้อของ task ผ่าน
 - [ ] ตาม standard.md (pattern, shared component) + rule.md เคร่งครัด
 - [ ] ไม่แตะไฟล์นอก scope ของ task — เจอสิ่งควรแก้นอก scope → note ไว้ ไม่ลงมือเอง
+- [ ] เข้าใจไฟล์ก่อนแก้ (ใครใช้/contract/เจตนา) — ไม่แก้แบบไม่เข้าใจ (investigate-before-edit)
+- [ ] ไม่แก้ config/test ให้เขียวแทนแก้โค้ดจริง — config ผิดจริงแก้ได้ + เหตุผล + note (config-protection)
 - [ ] รัน test-flow ใน spec.md + build/lint **ผ่านจริง** — ห้ามรายงาน passed ทั้งที่ยังแดง
 - [ ] ไม่ทิ้งขยะ: debug code, commented-out code, TODO ลอยๆ
 - [ ] เจอปัญหา → อ่าน `docs/troubleshooting.md` ก่อน; ปัญหายาก/ซ้ำที่แก้ได้ → รายงานในฟิลด์ troubleshooting

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

@@ -18,6 +18,8 @@
 - [ ] Frontend: layout, state (loading/error/empty), flow, responsive — ตรวจด้วยตาผ่าน e2e
 - [ ] regression: จุดที่ change กระทบของเดิม ถูกเทสซ้ำ
 - [ ] ผลเทสบันทึกตรงความจริง + นับจำนวนรอบที่แก้
+- [ ] เข้าใจไฟล์/contract ก่อนแก้ตอน fix loop — ไม่แก้แบบไม่เข้าใจ (investigate-before-edit)
+- [ ] ตอน fix loop — ไม่ลด bar (config/test threshold/disable rule) เพื่อให้ผ่าน; แก้ root cause จริง (config-protection)
 
 ## Checklist เพิ่มเมื่อรีวิว design ใน panel
 - [ ] ทุก slice มี test-flow ที่รันได้จริงใน local env

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

@@ -9,7 +9,7 @@
 - ทุก input คือของไม่น่าไว้ใจจนกว่าจะ validate
 - สิทธิ์: ใครทำอะไรได้ ต้องชัดต่อ endpoint/resource ไม่ใช่เชื่อ frontend
 - ข้อมูลอ่อนไหวรั่วได้ 3 ทาง: เก็บ, ส่ง, log
-- supply chain: dependency ใหม่ = ความเสี่ยงใหม่
+- supply chain: dependency ใหม่ = ความเสี่ยงใหม่ — ครอบ third-party skill / MCP / payload `.md` ที่ AI execute ต่อด้วย
 
 ## Checklist
 - [ ] ทุก input (API, form, file, query param) ถูก validate/sanitize ที่ฝั่ง server
@@ -20,6 +20,16 @@
 - [ ] error message ไม่ leak ข้อมูลภายใน (stack trace, SQL, path)
 - [ ] การกระทำสำคัญ (เงิน/สิทธิ์/ข้อมูลส่วนตัว) มี audit log
 - [ ] injection ทุกรูปแบบที่เกี่ยวข้อง: SQL/NoSQL, XSS, command, path traversal
+- [ ] **supply-chain / MCP:** third-party skill / MCP / payload `.md` = prompt-injection surface → ตรวจเนื้อหาก่อนติดตั้ง (อ่าน source / skills.sh), ติด global ไม่ vendor เข้า repo, จำกัดสิทธิ์ที่มันเข้าถึง
+
+## Runtime / operational security
+
+> ความปลอดภัยตอน **รัน AI agent ในเครื่อง** (คู่กับ app-security ข้างบน — คนละมิติ ไม่ทับกัน); principle portable ทุก harness
+
+- **P1 · secret isolation:** กัน agent อ่าน/เข้าถึง secret ที่ไม่เกี่ยวกับงาน — `.env`, `~/.ssh`, credential/token, keychain; ให้สิทธิ์อ่านเฉพาะ scope ของงาน (least-privilege ระดับ filesystem)
+- **P2 · no unnecessary egress:** payload/skill ที่ agent execute ต่อ ไม่ควรส่งข้อมูลออกได้อิสระ — รันใน sandbox/network ที่จำกัด egress เท่าที่งานต้องใช้
+- **P3 · identity separation:** แยก identity ของ session agent ออกจาก credential ส่วนตัว/prod — ไม่ใช้ token ส่วนตัว/สิทธิ์ prod ใน session ที่รัน automation/agent (ใช้ scoped credential แยก)
+  - **Claude adapter note** (ตัวอย่างเฉพาะ Claude Code — harness อื่นปรับเทียบ): `settings.json` → `permissions.deny`: `Read(**/.env*)`, `Read(~/.ssh/**)`; รัน sandbox no-egress เมื่อไม่ต้องการเครือข่าย
 
 ## Output
 - ความเห็นแบ่ง **blocker** (ช่องโหว่จริงต้องแก้ก่อน BUILD) / **suggestion** (hardening ที่ควรทำ)

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

@@ -2,6 +2,7 @@
 
 > **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
 > เป้าหมาย: ลงมือทำ task ที่ DESIGN เตรียมไว้ โดย **fan-out sub-agent อัตโนมัติต่อ task ตาม dependency**
+> **Context profile:** สวมโหมด `build` (`.warnyin/workflow/contexts/build.md`) — session-level posture ของ stage นี้
 
 ---
 
@@ -36,6 +37,8 @@ BUILD จะ **orchestrate การ implement** โดยกระจายง
 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 ลง `docs/stages/<slug>/troubleshooting.md` (ปัญหา/อาการ/root cause/วิธีแก้/ป้องกันซ้ำ) — ตอน SHIP จะยกขึ้น KB กลาง
+11. **★ investigate-before-edit** (enforce ของ "ห้ามเดา") — ก่อนแก้ไฟล์ที่มีอยู่ ต้องเข้าใจก่อน — **ใครใช้/อ่านไฟล์นี้, schema/contract/สัญญาของมัน, เจตนาเดิม**; แก้โดยไม่เข้าใจ = เดา (กรณีไม่ชัด → ถาม user / อ่านโค้ดที่อ้างถึง ก่อนแก้)
+12. **★ config-protection** (enforce ของ "ห้ามเดา") — ห้ามแก้ config (linter/formatter/test threshold) หรือ disable rule **"เพื่อให้ build/test ผ่าน"** แทนการแก้โค้ดจริง — ถ้า config ผิดจริง แก้ได้แต่ต้องมี **เหตุผลชัด + note** (ไม่ใช่เพื่อเลี่ยง finding)
 
 ---
 

package/src/.warnyin/workflow/stages/design.md

@@ -2,6 +2,7 @@
 
 > **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
 > เป้าหมาย: เสนอ **change ใหม่** พร้อมผลิต artifact ครบในขั้นเดียว — proposal (what & why) → design (how) → tasks (พร้อม execute)
+> **Context profile:** สวมโหมด `research` (`.warnyin/workflow/contexts/research.md`) ช่วงต้น (proposal/design) · `build` (`.warnyin/workflow/contexts/build.md`) ช่วงแตก task — session-level posture ของ stage นี้
 
 ---
 

package/src/.warnyin/workflow/stages/discovery.md

@@ -2,6 +2,7 @@
 
 > **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
 > เป้าหมาย: เปลี่ยนความต้องการที่ยังคลุมเครือ ให้เป็น **ความเข้าใจร่วมกัน (shared understanding)** ที่ชัดพอจะเข้า DESIGN ได้
+> **Context profile:** สวมโหมด `research` (`.warnyin/workflow/contexts/research.md`) — session-level posture ของ stage นี้
 
 ---
 

package/src/.warnyin/workflow/stages/ship.md

@@ -2,6 +2,7 @@
 
 > **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
 > เป้าหมาย: **ส่งมอบ** — promote ความรู้ระดับ topic ขึ้นเอกสารกลางใน `docs/` + archive topic เข้า `docs/stages/achieved/`
+> **Context profile:** สวมโหมด `review` (`.warnyin/workflow/contexts/review.md`) — session-level posture ของ stage นี้
 
 ---
 
@@ -34,20 +35,24 @@
 4. **กลั่น ไม่ใช่ copy ดิบ** — merge สาระเข้าโครงสร้างของไฟล์กลางเดิม ระวัง duplicate/ขัดแย้งกับเนื้อหาที่มีอยู่; เขียนแบบ "ความรู้ถาวร" ไม่ใช่บันทึกรายงาน
 5. **เอกสารต้องตรงโค้ดจริง** — structure/codemap อัปเดตจากการดูโค้ดจริง ไม่ใช่จากความจำหรือ design เดิม
 6. **อย่าเดา** — เนื้อหาที่ไม่แน่ใจว่าควร promote หรือควรวางไว้ไฟล์ไหน → ถามทีละข้อ + เสนอคำตอบที่แนะนำ
-7. **เก็บ "รอ SHIP" ให้หมด** — rule/standard ที่ note ค้างไว้ใน tasks ต้องถูกพิจารณาครบทุกข้อ (promote หรือตัดทิ้งพร้อมเหตุผล) ห้ามปล่อยค้าง
+7. **เก็บ learned-rule ให้หมด — planned + emergent** — รวบรวม rule ที่จะ promote ทุกตัว: ทั้ง **planned** (note "รอ SHIP" ใน `tasks/*/rule.md` §2) และ **emergent** (บทเรียนที่โผล่ตอนลงมือ — สแกน `build.md`/`verify.md`/`troubleshooting.md`/diff); ทุกตัวต้องมี **evidence (บังคับ)** + **scope** + **user ยืนยัน** ก่อน promote — ไม่มี evidence ไม่ promote (สอด "ห้ามเดา"); **learned-rule = กฎ generalize ไม่ใช่ incident** (troubleshooting = incident ที่ *อ้าง* เป็น evidence ได้). พิจารณาครบทุกข้อ (promote หรือตัดทิ้งพร้อมเหตุผล) ห้ามปล่อยค้าง
 
 ---
 
 ## 4. ลำดับขั้นการทำงาน (process)
 
-1. **อ่านทำความเข้าใจ topic:** อ่าน `docs/stages/<slug>/` ทุกไฟล์ — topic นี้ทำอะไร ทำอย่างไร เกิดความรู้ใหม่อะไรบ้าง (เช็คก่อนว่า VERIFY ผ่าน Gate แล้ว — มี `verify.md` สรุปผลผ่าน)
+1. **อ่านทำความเข้าใจ topic + รวบรวม learned-rule candidate:** อ่าน `docs/stages/<slug>/` ทุกไฟล์ — topic นี้ทำอะไร ทำอย่างไร เกิดความรู้ใหม่อะไรบ้าง (เช็คก่อนว่า VERIFY ผ่าน Gate แล้ว — มี `verify.md` สรุปผลผ่าน) — พร้อมกันนั้น **รวบรวม learned-rule candidate** เป็นตาราง (ทุกตัว = `rule + evidence + scope + promote?`):
+   - **planned:** จาก `tasks/*/rule.md` §2 "เสนอเพิ่ม rule ใหม่ (รอ SHIP)"
+   - **emergent:** สแกนบทเรียนที่โผล่ตอนลงมือ — `build.md` (pattern แก้ซ้ำ/integration), `verify.md` (รายการแก้+จำนวนรอบ), `troubleshooting.md` (ปัญหายาก→"กันซ้ำ" = candidate ชัดสุด), diff/commit
+   - **entry แต่ละตัว:** `rule` = ข้อความ **generalize** (ถ้าเป็น incident "X พังเพราะ Y" ยกเป็นกฎ "ก่อนแก้ Z เช็ค Y เสมอ") · `evidence` = **บังคับ** concrete pointer 1 บรรทัด + ลิงก์ artifact (`build.md`/`verify.md`/`troubleshooting.md`/diff/commit) — **ไม่มี evidence = ไม่ promote** · `scope` = `component:<c>`→`docs/techstack/<c>/rule.md` หรือ `project`→`docs/rule.md`
 2. **จำแนก feature:** สิ่งที่ทำเป็น **feature ใหม่** หรือ **ปรับปรุง feature เดิม** (เทียบกับ `docs/features/` ที่มีอยู่)
-3. **สรุป promotion plan + ขออนุมัติ (ครั้งเดียว):** feature ใหม่/ปรับปรุง, รายการไฟล์กลางที่จะอัปเดต + สาระ, ชื่อโฟลเดอร์ archive → รอ user ไฟเขียว
+3. **สรุป promotion plan + ขออนุมัติ (ครั้งเดียว):** feature ใหม่/ปรับปรุง, รายการไฟล์กลางที่จะอัปเดต + สาระ, ชื่อโฟลเดอร์ archive — **fold ตาราง learned-rule (rule + evidence + scope) เข้า approval เดียวกันนี้ ให้ user ยืนยัน per-rule** (✅ promote / ✂️ ตัด + เหตุผล) → รอ user ไฟเขียว
 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 เดียว)
+   2. **`docs/techstack/<component>/`** — `rule.md` / `standard.md` (learned-rule ที่ยืนยันแล้ว scope `component:<c>` + note "รอ SHIP" ใน tasks), `structure.md` (โครงสร้างที่เปลี่ยน), `test.md` (merge แผนเทสจาก `test.md` ของ topic)
+   3. **`docs/rule.md`** — global rule ใหม่/ที่เปลี่ยน (learned-rule ที่ยืนยันแล้ว scope `project` — กฎระดับโปรเจกต์ ไม่ผูกกับ component เดียว)
+   > promote learned-rule **เฉพาะตัวที่ user ยืนยัน (step 3)** ตาม scope: `component:<c>` → `docs/techstack/<c>/rule.md` · `project` → `docs/rule.md`
    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`)
@@ -74,7 +79,7 @@
 
 - [ ] topic ถูกย้ายไป `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` แล้ว (ไม่เหลือใน `docs/stages/`)
 - [ ] `docs/features/` สะท้อน feature ใหม่/ที่ปรับปรุงแล้ว
-- [ ] note "รอ SHIP" ทุกข้อใน `tasks/*/rule.md` + `standard.md` ถูกพิจารณาครบ — promote หรือตัดทิ้งพร้อมเหตุผล
+- [ ] learned-rules (planned + emergent) พิจารณาครบทุกตัว — note "รอ SHIP" ใน `tasks/*/rule.md` + `standard.md` + บทเรียน emergent จาก build/verify/troubleshooting; ทุก promote มี **evidence + user ยืนยัน**, ตัดทิ้งมีเหตุผล
 - [ ] `docs/troubleshooting.md` รวม entry จาก topic แล้ว
 - [ ] `docs/techstack/`, `docs/rule.md`, `docs/infra.md`, `docs/project.md` อัปเดตตามที่เกี่ยวข้อง
 - [ ] `docs/codemap/` ตรงกับโค้ดจริงปัจจุบัน

package/src/.warnyin/workflow/stages/verify.md

@@ -2,6 +2,7 @@
 
 > **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
 > เป้าหมาย: เป็น **strategy tester** — ยืนยันว่า change ที่ build แล้ว "ทำงานถูกตามจุดประสงค์ของ topic" จริง (functional + UX/UI ถ้าเป็น FE) แก้จนผ่าน
+> **Context profile:** สวมโหมด `review` (`.warnyin/workflow/contexts/review.md`) — session-level posture ของ stage นี้
 
 ---
 
@@ -20,6 +21,7 @@
    → ถ้า **ไม่มี** guideline → แนะนำว่าควรเทสแบบไหน/วิธีใดได้บ้าง แล้วเขียนแผนลง `test.md`
 3. **`docs/infra.md`** — local env / service ที่ต้องรันเพื่อเทส
 4. **`docs/troubleshooting.md`** — เผื่อปัญหาที่จะเจอเคยถูกแก้แล้ว
+5. **runtime security** (`.warnyin/workflow/roles/security.md` → "Runtime / operational security") — ตอนรันเทส local env ที่มี secret จริง ทบทวน secret isolation / no-egress / identity separation ก่อนปล่อย agent แตะของจริง
 
 ---
 
@@ -34,6 +36,8 @@
 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 ครบทุกข้อ)
+10. **★ investigate-before-edit** (enforce ของ "ห้ามเดา") — ก่อนแก้ไฟล์ที่มีอยู่ ต้องเข้าใจก่อน — **ใครใช้/อ่านไฟล์นี้, schema/contract/สัญญาของมัน, เจตนาเดิม**; แก้โดยไม่เข้าใจ = เดา (กรณีไม่ชัด → ถาม user / อ่านโค้ดที่อ้างถึง ก่อนแก้)
+11. **★ config-protection** (enforce ของ "ห้ามเดา") — ตอน fix loop (ข้อ 5 "แก้จนผ่าน") ห้ามแก้ config (linter/formatter/test threshold) หรือ disable rule **"เพื่อให้ build/test ผ่าน"** แทนการแก้ root cause จริง — "แก้จนผ่าน" ต้องเป็นการแก้ที่ต้นเหตุ ไม่ใช่ลด bar; ถ้า config ผิดจริง แก้ได้แต่ต้องมี **เหตุผลชัด + note** (ไม่ใช่เพื่อเลี่ยง finding)
 
 ---
 

package/src/bin/cli.mjs

@@ -45,8 +45,8 @@ const legacyV2 = ['workflow', 'warnyin-stages'].filter((d) => fs.existsSync(path
 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)
+  1. mkdir -p docs/stages && git mv warnyin-stages/* docs/stages/   # งานจริงของคุณ (ปลอดภัย ไม่ถูกแตะโดย installer)
+  2. rm -rf workflow warnyin-stages                # core เก่า + โฟลเดอร์ที่ย้ายของออกแล้ว
 แล้วรันคำสั่งนี้อีกครั้ง\n`)
 }
 
@@ -57,8 +57,8 @@ const legacyV5 = ['workflow', 'template', 'installer', 'stages'].filter((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/)
+  1. mkdir -p docs/stages && git mv warnyin/stages/* docs/stages/   # งานจริงของคุณ (active + achieved) — ปลอดภัย ไม่ถูกแตะ
+  2. rm -rf warnyin                                # core เก่าทั้งหมด (เวอร์ชันใหม่ installer จะวางที่ .warnyin/)
 แล้วรันคำสั่งนี้อีกครั้ง — installer จะวาง .warnyin/ ชุดใหม่ให้\n`)
 }
 
@@ -68,6 +68,7 @@ const CORE = [
   path.join('.warnyin', 'template'),
   path.join('.claude', 'commands', 'warnyin'),
   path.join('.claude', 'agents'),
+  path.join('.claude', 'skills'),
 ]
 // scaffold = พื้นที่ทำงานเปล่าของโปรเจกต์ — installer "สร้างเอง" ไม่ copy tree จาก package
 // (สำคัญ: ถ้า copy docs/stages จาก pkgRoot งานจริงของ repo ต้นทางจะรั่วไป target ทุกครั้ง — ดู verify installer-test-ci)