@warnyin/agents 0.8.5 → 0.9.1

package/CHANGELOG.md

@@ -23,6 +23,17 @@
 
 ## [Unreleased]
 
+## [0.9.1] - 2026-06-08
+
+### Fixed
+- **BUILD worktree เห็น dependency ครบทุก wave (build-wave sync build branch)** — harness fork worktree จาก **main** (คุมไม่ได้) ทำให้ build sub-agent ไม่เห็น `docs/stages/<slug>/` (topic docs) + output ของ wave ก่อนหน้า แล้ว improvise (KB#14). แก้ที่ payload แบบ **unify-in-place**: `src/.warnyin/workflow/scripts/build-wave.mjs` รับ arg `baseRef?` (ชื่อ build branch) + แทรก prompt **step `0.`** ให้ agent `git merge <baseRef> --no-edit` เป็นงานแรกก่อนอ่าน task **เฉพาะ `isolate && baseRef`** (`!baseRef` → ไม่แทรก = backward compat ไม่ renumber step 1-9) — มี **abort-on-conflict** (`|| git merge --abort` กันค้าง MERGE state) + retry transient lock + **hard-stop** (merge สำเร็จแต่ `task.md` ไม่ปรากฏ → STOP failed ห้าม improvise) + บันทึกผล merge ใน `notes`; command `src/.claude/commands/warnyin/build.md` step 6 ส่ง `baseRef` + integrate ด้วย `git checkout <branch> -- <scoped src files>` (เลี่ยง topic-docs copy + ปลอด KB#11 tracked-deletion); playbook `src/.warnyin/workflow/stages/build.md` §3 principle 3 + §4 step 5 อธิบายกลไก. **backward compatible** (caller ไม่ส่ง `baseRef`/`isolate:false` → พฤติกรรมเดิม); payload ติดมากับ `--update` รอบถัดไป
+
+## [0.9.0] - 2026-06-08
+
+### Added
+- **Structural validator + status script (`validate-topic.mjs`) wired เข้า workflow 3 จุด** — script เดียวใน payload (`src/.warnyin/workflow/scripts/validate-topic.mjs`, zero-dep ตาม pattern `lint-md.mjs`) 2 โหมด: **status** (ไม่ใส่ arg → ตารางทุก active topic, exit 0 เสมอ) · **validate** (`<slug>` → `✖`/`⚠` structural ละเอียด มี code C1–C5 กำกับ, exit 1 เมื่อมี ✖ · 0 เมื่อสะอาด/มีแค่ ⚠ · 2 slug ไม่ถูกต้อง/path traversal). wire เข้า playbook **3 จุดแบบ unify-in-place + node-guard ทุกจุด**: `next.md` (§2 step pre-scan โหมด status ก่อนอ่าน semantic — ตาราง heuristic เดิมคง fallback) · `stages/design.md` (§8 gate item "ทุก task มี 4 ไฟล์ครบ" → validate `<slug>` ควรไม่มี ✖, guidance ไม่ใช่ hard gate) · `stages/ship.md` (§4 step 1 → validate `<slug>` ก่อน promote, มี ✖ ควรแก้ก่อน) + command mirror `next/design/ship` (ชี้ playbook ไม่ duplicate รายการเช็ค). **structural เท่านั้น** — semantic ยังเป็นหน้าที่ model/ผู้ ship; **backward compatible** (เครื่องไม่มี node → playbook คง fallback เดิม); payload ติดมากับ `--update` รอบถัดไป
+- **วงจร Feature spec delta ครบ 3 stage (DESIGN/VERIFY/SHIP)** — wiring discipline ของ behavior spec แบบ unify-in-place ลง playbook กลาง + template + command adapter: `src/.warnyin/workflow/stages/design.md` (§2 input อ่าน `docs/features/<name>/spec.md` · §4 step 5 + §5 + §8 gate ครอบ "Spec delta") · `verify.md` (feature spec = regression baseline — scenario เดิม = regression case, delta = test case ใหม่; §2/§3/§4/§6) · `ship.md` (§4 step 5.1 merge `spec.md` ตาม delta — ADDED ต่อท้าย/MODIFIED แทนที่/REMOVED ลบ + **read-modify-verify key ไม่เจอ → STOP** + rename `[เดิมชื่อ:]` + stale delta re-check; §3/§5/§6 gate) · template `stages/[topic]/design.md` (+section "9. Spec delta") + `ship.md` (+แถว `spec.md`) · `src/.warnyin/workflow/README.md` note `spec.md` (living behavior spec) · command mirror `design/verify/ship` (ชี้ playbook ไม่ duplicate logic). **backward compatible** (feature ไม่มี spec → วิธีเดิม; topic ไม่มี §9 delta → SHIP ทำแบบเดิม); payload `.md` ล้วน ติดมากับ `--update` รอบถัดไป
+
 ## [0.8.5] - 2026-06-07
 
 ### Added
@@ -82,5 +93,13 @@
 ### Removed
 - รองรับ node 18 (drop ตาม EOL)
 
-[Unreleased]: https://github.com/warnyin/warnyin-agents/compare/v0.7.0...HEAD
+[Unreleased]: https://github.com/warnyin/warnyin-agents/compare/v0.9.1...HEAD
+[0.9.1]: https://github.com/warnyin/warnyin-agents/compare/v0.9.0...v0.9.1
+[0.9.0]: https://github.com/warnyin/warnyin-agents/compare/v0.8.5...v0.9.0
+[0.8.5]: https://github.com/warnyin/warnyin-agents/compare/v0.8.4...v0.8.5
+[0.8.4]: https://github.com/warnyin/warnyin-agents/compare/v0.8.3...v0.8.4
+[0.8.3]: https://github.com/warnyin/warnyin-agents/compare/v0.8.2...v0.8.3
+[0.8.2]: https://github.com/warnyin/warnyin-agents/compare/v0.8.1...v0.8.2
+[0.8.1]: https://github.com/warnyin/warnyin-agents/compare/v0.8.0...v0.8.1
+[0.8.0]: https://github.com/warnyin/warnyin-agents/compare/v0.7.0...v0.8.0
 [0.7.0]: https://github.com/warnyin/warnyin-agents/compare/v0.6.0...v0.7.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@warnyin/agents",
-  "version": "0.8.5",
+  "version": "0.9.1",
   "description": "Warnyin Standard Workflow installer — 5-stage ways of work (Discovery/DESIGN/BUILD/VERIFY/SHIP) สำหรับทุกโปรเจกต์",
   "type": "module",
   "license": "MIT",

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

@@ -12,8 +12,8 @@ argument-hint: "[slug ของ topic]"
 4. **Pre-check:** target เป็น git repo ไหม (จำเป็นสำหรับ worktree isolation) — ถ้าไม่ใช่ → fallback sequential shared-tree (`isolate:false`) และแจ้ง user. สร้าง build branch ใหม่ก่อนเริ่ม
 5. **ขออนุมัติครั้งเดียว** — ใช้ AskUserQuestion แสดง execution plan: แต่ละ wave มี task อะไร, อันไหน parallel, isolation mode, build branch → รอ go/no-go (อย่าเริ่มก่อนได้ไฟเขียว)
 6. **เดินทีละ wave** (หลังอนุมัติ):
-   - เรียก **Workflow** ด้วย `{ scriptPath: ".warnyin/workflow/scripts/build-wave.mjs", args: { slug, tasks: [<task ใน wave นี้>], isolate } }`
-   - เมื่อ workflow คืนผล: ถ้า `isolate` → **merge** branch ที่แต่ละ agent รายงาน (`result.branch`) เข้า build branch ทีละอัน, แก้ conflict ถ้ามี; ถ้า shared-tree → review + commit ให้
+   - เรียก **Workflow** ด้วย `{ scriptPath: ".warnyin/workflow/scripts/build-wave.mjs", args: { slug, tasks: [<task ใน wave นี้>], isolate, baseRef: "<ชื่อ build branch ที่สร้าง step 4>" } }` — `baseRef` = build branch จริง (worktree fork จาก main → agent merge build branch เองก่อนทำงาน เพื่อเห็น `docs/stages/<slug>/` + output ของ wave ก่อนหน้า)
+   - เมื่อ workflow คืนผล: ถ้า `isolate` → **integrate ด้วย `git checkout <result.branch> -- <ไฟล์ source ที่ task แก้>`** (checkout เฉพาะไฟล์ source ที่ scoped — เลี่ยง topic-docs copy ที่ agent merge เข้า worktree + ปลอด KB#11 tracked-deletion), แก้ conflict ถ้ามี; ถ้า shared-tree → review + commit ให้ · `task.md` status/checklist → main loop อัปเดตที่ main working dir ตอน integrate (E1 — agent แก้จาก worktree ไม่ได้ถ้า gitignored)
    - ถ้ามี task `failed` หรือ `skipped` → **หยุด** รายงาน user ก่อนไป wave ถัดไป
    - **รวม troubleshooting:** ดึงฟิลด์ `troubleshooting` จากผลของทุก agent ในรอบนี้ → เขียนรวมลง `docs/stages/<slug>/troubleshooting.md` (main loop เขียนเอง กันไฟล์ชนกันใน worktree)
 7. **★ Full build & test gate (หลัง merge ทุก wave):** บน build branch ที่ integrate แล้ว รัน build ทั้งหมด + test suite ทั้งหมด (รวม unit test) ของทุก component ที่กระทบ

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

@@ -14,6 +14,8 @@ argument-hint: "[slug ของ topic] [อธิบาย change สั้น
    - ระบุ slug → ใช้/สร้าง `docs/stages/<slug>/` (ถ้ามาจาก Discovery ใช้โฟลเดอร์เดิม)
    - ถ้าเป็นคำถาม/ยังไม่มั่นใจเรื่อง design → แนะนำ `/warnyin:discovery` ก่อน
 4. ผลิต artifact โดยใช้ template ใน `.warnyin/template/stages/[topic]/` เป็นโครง: `business.md` (ข้ามได้ถ้า change เล็ก), `proposal.md`, `design.md` (lens `.warnyin/workflow/roles/sa.md`), แล้วแตก `tasks/<task-name>/` (lens `.warnyin/workflow/roles/tech-lead.md`) แต่ละใบมี `spec.md` `standard.md` `rule.md` `task.md`
+   - **Spec delta:** `design.md` ต้องครอบ section "9. Spec delta" — เทียบ `docs/features/<name>/spec.md` ปัจจุบัน (input ข้อ 6) แล้วเขียน ADDED/MODIFIED/REMOVED หรือ "ไม่มี delta" (กติกาเต็ม + gate ดู playbook §2/§4/§8 — ไม่ทำซ้ำที่นี่)
+   - **Gate ดู playbook §8** — ถ้ารัน node ได้ validate `<slug>` ควรไม่มี ✖ (รายการเช็คอยู่ใน script + playbook ไม่ทำซ้ำที่นี่)
    - **Review panel (ถาม user ก่อน):** หลัง `design.md` เสร็จ ก่อนแตก task — ใช้ AskUserQuestion ถามว่าจะให้ panel รีวิวไหม ถ้า ok → fan-out subagent `warnyin-sa`, `warnyin-tech-lead`, `warnyin-qa`, `warnyin-security`, `warnyin-infra` (Agent tool, ขนาน, read-only) รีวิว proposal+design → รวมความเห็น สรุปให้ user → แก้ blocker ให้ครบ (ห้ามเดา) → บันทึก section "Design review" ท้าย `design.md`
 5. ตอน generate ไฟล์ task หลายใบ สามารถใช้ sub-agent (Task/Agent tool) fan-out หนึ่ง agent ต่อหนึ่ง task ได้ — **แต่ต้องผ่าน Gate (ข้อ 8 ของ playbook) ก่อน**
 6. **Dry-run (ถาม user ก่อนเสมอ):** หลังเขียนไฟล์ task ครบ ใช้ AskUserQuestion ถามว่าต้องการ dry-run ทั้งหมดเพื่อหาจุดบกพร่องก่อนเข้า BUILD ไหม — ถ้า ok ทำตามข้อ 4.9 ของ playbook:

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

@@ -12,5 +12,6 @@ argument-hint: "[slug (optional — ไม่ระบุ = สแกนทุ
    - ไม่ระบุ → สแกนทุก topic ใน `docs/stages/` (ยกเว้น `achieved/`)
 3. ต่อ topic: ระบุ stage ปัจจุบันจาก artifact ที่ถูกเติมจริง (ไฟล์ที่ยังเป็นโครง template = ยังไม่ทำ)
    + ไล่ gate ของ playbook stage นั้น + สถานะ task ใน `tasks/*/task.md`
+   - ทำตาม step pre-scan ใน playbook §2 — ถ้ารัน node ได้ รัน `validate-topic.mjs` โหมด status ก่อนอ่าน semantic (รายการเช็คอยู่ใน script + playbook)
 4. รายงานในแชท: ตารางภาพรวม (topic · stage · งานค้าง · command ถัดไป) + รายละเอียดงานค้าง + ลำดับงานที่แนะนำ
 5. ไม่รัน stage ต่อให้เอง — เสนอ command ให้ user ตัดสินใจ

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

@@ -7,12 +7,12 @@ argument-hint: "[slug ของ topic]"
 
 1. อ่าน `.warnyin/workflow/stages/ship.md` ให้ครบก่อน แล้วทำตามทุกหลักการอย่างเคร่งครัด
 2. slug: $ARGUMENTS — ถ้าไม่ระบุให้ถามก่อน ว่าจะ ship topic ไหน (ดูโฟลเดอร์ใน `docs/stages/`)
-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`
+3. **อ่านทำความเข้าใจ topic + รวบรวม learned-rule candidate:** อ่าน `docs/stages/<slug>/` ทุกไฟล์ — topic นี้ทำอะไร ทำอย่างไร เกิดความรู้ใหม่อะไรบ้าง; เช็คว่า VERIFY ผ่าน Gate แล้ว (`verify.md` สรุปผลผ่าน) — ถ้ายังไม่ผ่าน → หยุด แจ้ง user. ทำตาม playbook §4 step 1 — ถ้ารัน node ได้ validate `<slug>` ก่อน promote (มี ✖ ควรแก้ก่อน — รายการเช็คอยู่ใน script + playbook). รวบรวม 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 — **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/features/<feature-name>/` — ใหม่ → สร้าง (feature.md + business.md); เดิม → อัปเดต โดยใช้ business/proposal/design ของ topic — **และ merge `spec.md` ตาม Spec delta** ใน `design.md` §9 (ADDED ต่อท้าย · MODIFIED แทนที่ · REMOVED ลบ; **key ไม่เจอ → STOP ถาม user ห้าม merge เงียบ** — กติกาเต็มดู playbook §4 step 5)
    - `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 ใหม่/ที่เปลี่ยน (เฉพาะกฎระดับโปรเจกต์)

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

@@ -9,6 +9,7 @@ argument-hint: "[slug ของ topic]"
 1. อ่าน `.warnyin/workflow/stages/verify.md` ให้ครบก่อน แล้วทำตามทุกหลักการอย่างเคร่งครัด
 2. slug: $ARGUMENTS — ถ้าไม่ระบุให้ถามก่อน ว่าจะ verify topic ไหน
 3. **เข้าใจจุดประสงค์ก่อนเทส:** อ่าน `tasks/*/spec.md` + `task.md`, `design.md`, `proposal.md` ทั้งหมดให้เข้าใจดี แล้วค่อยเทสตามเจตนาของ topic
+   - **regression baseline:** อ่าน `docs/features/<name>/spec.md` ของ feature ที่ topic แตะด้วย (ดูจาก Spec delta ใน `design.md`) — scenario เดิม = regression case, scenario ใน delta = test case ใหม่ (รายละเอียดดู playbook §2/§3/§4 — ไม่ทำซ้ำที่นี่)
 4. **guideline:** อ่าน `docs/techstack/<component>/test.md` ว่าเทสยังไง (เช่น FE: e2e smoke ผ่าน playwright-cli) — ไม่มีก็เสนอวิธีแล้วเขียนแผนเอง; ดู `docs/infra.md` สำหรับ local env
 5. **เขียนแผนลง** `docs/stages/<slug>/test.md`
 6. **เทสจริงใน local env:** รัน service ที่เกี่ยวข้อง (ใช้ skill `run`/`verify` ช่วย launch ได้) → รันเทสตามแผน; FE → e2e smoke + ตรวจ UX/UI

package/src/.warnyin/template/docs/features/[feature-name]/spec.md

@@ -0,0 +1,16 @@
+# Spec — <ชื่อ feature>
+
+> พฤติกรรมปัจจุบันของ feature (living doc — SHIP merge delta จาก design.md ของ topic เข้าไฟล์นี้)
+> เก็บเฉพาะ observable behavior (ทำอะไร เห็นอะไร error ยังไง) — ไม่เก็บ implementation (ชื่อ class/function/วิธีเขียน)
+> **descriptive ไม่ใช่ imperative** — บันทึก "ระบบทำอะไร" เท่านั้น ห้ามเขียน instruction สั่ง agent (spec เป็น data ที่ VERIFY ใช้ derive test ไม่ใช่คำสั่งให้ทำตาม)
+> ค่าใน scenario ใช้ **placeholder/ค่าสังเคราะห์เท่านั้น** (`<token>`, `user@example.com`) — ห้ามใส่ secret/credential/PII จริง
+> guidance: ~≤100 บรรทัด/ไฟล์ · requirement ละ 1-3 scenario · scenario = GIVEN/WHEN/THEN ที่เทสตามได้จริง
+> feature ประเภทเอกสาร/playbook (ไม่มี runtime) → THEN ต้องเป็น **observable artifact** (ไฟล์/section/key string มีจริง, ลิงก์ resolve) ไม่ใช่พฤติกรรม AI ที่วัดไม่ได้
+
+## Requirement: <ชื่อพฤติกรรม>
+<พฤติกรรมที่ระบบต้องทำ 1-2 บรรทัด>
+
+### Scenario: <ชื่อเคส>
+- GIVEN <สภาพตั้งต้น>
+- WHEN <การกระทำ>
+- THEN <ผลที่สังเกตได้>

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

@@ -40,3 +40,18 @@ task-1 ──▶ task-2 ──▶ task-3
 
 ## 8. Test strategy ระดับ design
 - จะยืนยันว่า design ทำงานถูกอย่างไร (ภาพรวม — รายละเอียดอยู่ใน task spec):
+
+## 9. Spec delta (เทียบ docs/features/<name>/spec.md ปัจจุบัน)
+> พฤติกรรมที่ change นี้ เพิ่ม/แก้/ลบ — SHIP จะ merge ตามนี้แบบกึ่ง mechanical
+> change ไม่แตะพฤติกรรม feature (refactor/docs/tooling) → เขียน "ไม่มี delta" บรรทัดเดียวพอ
+
+### ADDED
+#### Requirement: <ชื่อ> (→ feature: <feature-name>)
+<พฤติกรรม + scenario ตาม format ของ spec.md>
+
+### MODIFIED
+#### Requirement: <ชื่อใหม่> (→ feature: <feature-name>) [เดิมชื่อ: <ชื่อเก่า> — ใส่เฉพาะกรณี rename]
+<เวอร์ชันใหม่เต็ม> _(เดิม: <สรุปสั้น>)_
+
+### REMOVED
+#### Requirement: <ชื่อเดิมใน spec> (→ feature: <feature-name>) — เหตุผลที่เลิก

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

@@ -11,6 +11,7 @@
 | ไฟล์ | สาระที่ promote |
 |---|---|
 | `docs/features/<feature-name>/` | |
+| `docs/features/<feature-name>/spec.md` | <!-- merge Spec delta จาก design.md §9 --> |
 | `docs/techstack/<component>/rule.md` | |
 | `docs/techstack/<component>/standard.md` | |
 | `docs/techstack/<component>/structure.md` | |

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

@@ -56,7 +56,7 @@ Discovery (optional) ──▶ DESIGN ──▶ BUILD ──▶ VERIFY ──▶
     docs/                                  #   โครง docs — installer seed เข้า docs/ ตอนติดตั้ง
       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)
+      features/[feature-name]/             #   copy เป็น docs/features/<feature-name> (โดย SHIP) — มี spec.md (living behavior spec)
   installer/templates/ #   template CLAUDE.md ของ target (installer ใช้เอง — ไม่ถูก copy ไป target)
 
 .claude/               # adapter Claude Code (ชี้กลับ playbook กลาง)

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

@@ -14,6 +14,7 @@ NEXT คือโหมด **อ่านอย่างเดียว (read-on
 
 ## 2. วิธีหาสถานะ (สแกนจากไฟล์จริง — ไม่ถาม user ก่อน)
 
+0. **structural pre-scan (ถ้ารัน node ได้):** ถ้ารัน node ได้ → รัน `node .warnyin/workflow/scripts/validate-topic.mjs` (โหมด status) เป็น structural pre-scan ก่อน แล้วค่อยอ่านเชิง semantic เฉพาะจุดที่ต้องตัดสิน — เครื่องที่รันไม่ได้ ใช้ตาราง heuristic ด้านล่างเหมือนเดิม
 1. **หา topic ที่ active:** โฟลเดอร์ใน `docs/stages/<slug>/` ทั้งหมด ยกเว้น `achieved/` และ `context.md`
    - ไม่มี topic เลย → รายงานว่า "ไม่มีงานค้าง" + แนะนำเริ่มงานใหม่ด้วย `/warnyin:discovery` หรือ `/warnyin:design`
 2. **อ่าน `docs/stages/context.md`** — บริบทงานที่จดไว้ (ถ้ามี)

package/src/.warnyin/workflow/scripts/build-wave.mjs

@@ -5,6 +5,7 @@
 //   slug: string,            // ชื่อ topic เช่น "billing-redesign"
 //   tasks: string[],         // ชื่อ task ใน wave นี้ (โฟลเดอร์ docs/stages/<slug>/tasks/<task>)
 //   isolate?: boolean,       // true = worktree ต่อ task (ดีฟอลต์), false = shared tree (sequential)
+//   baseRef?: string,        // ชื่อ build branch เช่น "build/my-topic"; ไม่ส่ง = ไม่ sync (backward compat)
 // }
 
 export const meta = {
@@ -18,6 +19,7 @@ const A = typeof args === 'string' ? JSON.parse(args) : (args || {})
 const slug = A.slug
 const tasks = A.tasks || []
 const isolate = !(A.isolate === false)
+const baseRef = A.baseRef || null   // ชื่อ build branch เช่น "build/my-topic"; ไม่ส่ง = ไม่ sync (backward compat)
 
 if (!slug || tasks.length === 0) {
   log('ไม่มี slug หรือ tasks — ไม่มีอะไรให้ build')
@@ -80,6 +82,20 @@ function prompt(task) {
     `7. อัปเดตสถานะ + acceptance ที่ผ่านใน ${dir}/task.md`,
     `8. ปัญหาที่ "ยาก/เจอซ้ำ" และแก้สำเร็จ → ใส่ในฟิลด์ troubleshooting (main loop จะรวมลง topic troubleshooting.md)`,
   ]
+  // worktree fork จาก main (คุมไม่ได้) → ให้ agent sync build branch เข้า worktree เองก่อนทำงาน
+  // แทรกเป็น step "0." ก่อน "1. อ่านให้ครบ" — เฉพาะ isolate && baseRef (ไม่ renumber step 1-9; !baseRef = พฤติกรรมเดิม)
+  if (isolate && baseRef) {
+    lines.splice(2, 0,
+      `0. **★ Sync build branch เข้า worktree ก่อน (ทำก่อน Read ไฟล์ใดๆ):** รัน`,
+      `   \`git merge ${baseRef} --no-edit || (git merge --abort; <รายงาน failed>)\``,
+      `   (worktree fork จาก main — ต้อง merge build branch เพื่อให้เห็น docs/stages/${slug}/ + output ของ wave ก่อนหน้า)`,
+      `   - ปกติเป็น fast-forward (main มักเป็น ancestor ของ build branch); ถ้าเป็น 3-way แล้ว conflict → **abort + รายงาน failed** (ห้ามทิ้ง worktree ค้าง MERGE state — step commit ท้ายจะพัง)`,
+      `   - ถ้าล้มด้วย lock error ชั่วคราว (transient \`index.lock\`/\`packed-refs\`) → **retry 1 ครั้ง** ก่อนรายงาน failed`,
+      `   - **★ hard-stop กัน improvise (panel B2):** หลัง merge ถ้าไฟล์ \`${dir}/task.md\` **ยังไม่ปรากฏ** → **STOP รายงาน failed ทันที ห้าม improvise/git reset เอง** (กันวนรอย KB#14)`,
+      `   - บันทึกผล merge ลงฟิลด์ \`notes\` (เช่น "merged ${baseRef}: fast-forward to <sha>") เพื่อ main loop verify ว่า sync เกิดจริง (Infra-S5)`,
+      ``,
+    )
+  }
   if (isolate) {
     lines.push(
       `9. คุณอยู่ใน git worktree แยก: เมื่อเสร็จและเขียวแล้ว ให้ commit งาน (git add -A && git commit -m "build(${task}): ...")`,

package/src/.warnyin/workflow/scripts/validate-topic.mjs

@@ -0,0 +1,378 @@
+import { readdirSync, readFileSync } from 'node:fs'
+import { join } from 'node:path'
+import { fileURLToPath } from 'node:url'
+
+// Structural validator ของ topic ใน docs/stages/ — zero-dep (mirror lint-md.mjs: pure fn + injectable IO + main-guard)
+// 2 โหมด: status (ไม่มี arg, ตารางทุก topic, exit 0) · validate (<slug>, รายการ ✖/⚠, exit 1 เมื่อมี ✖ / 2 เมื่อ slug ผิด)
+// เช็ค C1–C5 = structural เท่านั้น (semantic เป็นของ model ตาม gate เดิม) — canonical contract: design §4
+//
+// หลักการแยกระดับ (design §4.2): ✖ checks (C2/C3/C5) ไม่พึ่ง filled-detection (existence/structure ล้วน)
+//   · C1/C4 = ⚠ best-effort (heuristic เดา "เริ่มเติม" — ยอมรับ false ได้ ไม่ block)
+// security (design §4.4): เฉพาะ node:fs/node:path/node:url — ไม่มี child_process/network/write
+//   · report structural เท่านั้น (ชื่อไฟล์/section/code — ไม่ echo เนื้อ artifact) · ENOENT/EACCES guard ไม่พ่น absolute path
+
+// ── canonical: stage → artifact (design §4.3) ──────────────────────────────
+// required = ต้องมีถึงจะนับว่าผ่าน stage · optional = ข้ามได้ปกติ (ไม่ count เป็น "ข้าม stage")
+const STAGES = [
+  { order: 1, stage: 'Discovery', required: [], optional: ['discovery.md', 'research.md'] },
+  { order: 2, stage: 'DESIGN', required: ['proposal.md', 'design.md'], optional: ['business.md'] },
+  { order: 4, stage: 'BUILD', required: ['build.md'], optional: [] },
+  { order: 5, stage: 'VERIFY', required: ['verify.md', 'test.md'], optional: [] },
+  { order: 6, stage: 'SHIP', required: ['ship.md'], optional: [] },
+]
+// ไฟล์ artifact ทั้งหมดที่ใช้ infer stage (รวม required + optional ของทุก stage)
+const STAGE_FILES = STAGES.flatMap((s) => [...s.required, ...s.optional])
+const TASK_REQUIRED = ['spec.md', 'standard.md', 'rule.md', 'task.md']
+
+// ── filled heuristic (B1): "เริ่มเติม" = H1 (บรรทัดแรกที่ไม่ว่าง) ไม่มี placeholder <...> ─────
+// ทุก template artifact มี `— <ชื่อ...>` ที่ H1; ห้ามใช้ const FILLED_MARKERS list (เปราะ)
+function isFilled(content) {
+  if (content == null) return false
+  const lines = content.split('\n')
+  for (const line of lines) {
+    const t = line.trim()
+    if (t === '') continue
+    // H1 = บรรทัดแรกที่ไม่ว่าง — เริ่มเติมเมื่อไม่มี placeholder <...>
+    return !/<[^>]+>/.test(t)
+  }
+  return false
+}
+
+// helper: เอา content ของไฟล์ระดับ topic (relPath = ชื่อไฟล์ตรง ๆ เช่น 'design.md')
+function topLevel(files, name) {
+  return files.has(name) ? files.get(name) : null
+}
+
+// ── C2: ทุกโฟลเดอร์ใน tasks/ (ข้าม [...]) มีครบ 4 ไฟล์ ──────────────────────
+// files key รูปแบบ: 'tasks/<taskName>/<file>' — รวบ taskName + เซตไฟล์ที่มี
+function checkTasks(files) {
+  const issues = []
+  const tasks = new Map() // taskName -> Set<file>
+  for (const key of files.keys()) {
+    const parts = key.split('/')
+    if (parts[0] !== 'tasks' || parts.length < 3) continue
+    const taskName = parts[1]
+    if (taskName.startsWith('[')) continue // skip template placeholder [task-name]
+    if (!tasks.has(taskName)) tasks.set(taskName, new Set())
+    tasks.get(taskName).add(parts[2])
+  }
+  for (const [taskName, present] of tasks) {
+    const missing = TASK_REQUIRED.filter((f) => !present.has(f))
+    if (missing.length) {
+      issues.push({
+        code: 'C2',
+        level: 'error',
+        msg: `tasks/${taskName} ขาด ${missing.join(', ')}`,
+      })
+    }
+  }
+  return issues
+}
+
+// ── C3: ship.md เริ่มเติมแล้ว → ต้องมี '## 3. Learned rules' + ≥1 data row จริง ──────
+// (B4) ยัง template H1 → ข้าม (chicken-egg) · (B3) ≥1 row จริง (ไม่นับ header/separator/row ว่าง)
+function checkShipData(files) {
+  const issues = []
+  const ship = topLevel(files, 'ship.md')
+  if (ship == null) return issues // ไม่มีไฟล์ → ไม่เช็ค (ยังไม่ถึง SHIP)
+  if (!isFilled(ship)) return issues // ยัง template → ข้าม (B4)
+
+  const lines = ship.split('\n')
+  // หา section '## 3. Learned rules' (anchor H2 ที่ขึ้นต้นด้วยข้อความนี้)
+  let secStart = -1
+  for (let i = 0; i < lines.length; i++) {
+    if (/^##\s+3\.\s+Learned rules/.test(lines[i])) { secStart = i; break }
+  }
+  if (secStart === -1) {
+    issues.push({ code: 'C3', level: 'error', msg: 'ship.md ขาด section "## 3. Learned rules"' })
+    return issues
+  }
+  // ขอบเขต section = จนเจอ '## ' ถัดไป
+  let secEnd = lines.length
+  for (let i = secStart + 1; i < lines.length; i++) {
+    if (/^##\s/.test(lines[i])) { secEnd = i; break }
+  }
+  // หา data row จริงในตาราง: บรรทัดที่มี '|' ≥2, ไม่ใช่ separator (|---|), ไม่ใช่ header (มี cell ไม่ว่าง อย่างน้อย 1)
+  // header แยกจาก data ด้วย separator — นับ row หลัง separator ที่มี cell ไม่ว่าง
+  let sawSeparator = false
+  let hasDataRow = false
+  for (let i = secStart + 1; i < secEnd; i++) {
+    const t = lines[i].trim()
+    if (!t.startsWith('|')) continue
+    if (/^\|[\s|:-]*\|?$/.test(t) && t.includes('-')) { sawSeparator = true; continue } // separator |---|
+    if (!sawSeparator) continue // ยังไม่ถึง separator = ยังเป็น header
+    // data row: split cells, มี cell ที่ไม่ว่าง
+    const cells = t.split('|').slice(1, -1).map((c) => c.trim())
+    if (cells.some((c) => c !== '')) { hasDataRow = true; break }
+  }
+  if (!hasDataRow) {
+    issues.push({ code: 'C3', level: 'error', msg: 'ship.md section "Learned rules" ไม่มี data row (มีแค่ header/ตารางว่าง)' })
+  }
+  return issues
+}
+
+// ── C1: artifact ของ stage N เริ่มเติม แต่ required ของ stage < N ยัง template (ข้ามลำดับ) → ⚠ ──
+// + stage inference: stage ปัจจุบัน = stage สูงสุดที่มี artifact "เริ่มเติม"
+function inferStageAndC1(files) {
+  const issues = []
+  const filledOf = (name) => {
+    const c = topLevel(files, name)
+    return c != null && isFilled(c)
+  }
+  // stage ที่ "เริ่มเติม" = มี artifact required หรือ optional ตัวใดตัวหนึ่ง filled
+  let maxOrder = 0
+  let stageName = '(ยังไม่เริ่ม)'
+  for (const s of STAGES) {
+    const anyFilled = [...s.required, ...s.optional].some(filledOf)
+    if (anyFilled && s.order > maxOrder) { maxOrder = s.order; stageName = s.stage }
+  }
+  // C1: stage ที่เริ่มเติม (order N) แต่ required ของ stage order < N ยังไม่ครบ filled
+  for (const s of STAGES) {
+    if (s.required.length === 0) continue
+    const anyFilledHere = [...s.required, ...s.optional].some(filledOf)
+    if (!anyFilledHere) continue
+    // เช็ค required ของ stage ก่อนหน้า (order < s.order) ที่ยังไม่ filled
+    for (const prev of STAGES) {
+      if (prev.order >= s.order || prev.required.length === 0) continue
+      const prevDone = prev.required.every(filledOf)
+      if (!prevDone) {
+        issues.push({
+          code: 'C1',
+          level: 'warn',
+          msg: `${s.stage} เริ่มเติมแต่ ${prev.stage} (${prev.required.join('/')}) ยังเป็น template (ข้ามลำดับ)`,
+        })
+      }
+    }
+  }
+  return { issues, stage: stageName }
+}
+
+// ── C4: design.md เริ่มเติมแล้ว → ต้องมี section 'Spec delta' (หรือ 'ไม่มี delta') → ⚠ ─────
+function checkSpecDelta(files) {
+  const issues = []
+  const design = topLevel(files, 'design.md')
+  if (design == null || !isFilled(design)) return issues // ไม่มี/ยัง template → ข้าม
+  const hasDelta = /Spec delta/i.test(design) || /ไม่มี delta/.test(design)
+  if (!hasDelta) {
+    issues.push({ code: 'C4', level: 'warn', msg: 'design.md เริ่มเติมแล้วแต่ไม่มี section "Spec delta"' })
+  }
+  return issues
+}
+
+// ── pure fn หลัก: checkTopic(files) → {issues, stage} ────────────────────────
+export function checkTopic(files) {
+  const issues = []
+  issues.push(...checkTasks(files)) // C2 ✖
+  issues.push(...checkShipData(files)) // C3 ✖
+  const { issues: c1Issues, stage } = inferStageAndC1(files) // C1 ⚠ + stage
+  issues.push(...c1Issues)
+  issues.push(...checkSpecDelta(files)) // C4 ⚠
+  return { issues, stage }
+}
+
+// ── C5: feature spec format (checkFeatureSpec) ──────────────────────────────
+// มี '## Requirement:' ≥1 (anchor H2 เป๊ะ) · ทุก Requirement มี '### Scenario:' ≥1
+//   · ทุก Scenario มี GIVEN+WHEN+THEN (case-insensitive, ไม่ enforce order)
+// group ด้วย section boundary (เจอ '## Requirement:' ถัดไป = ปิด block ของ Requirement ก่อน) — defer #1
+export function checkFeatureSpec(name, content) {
+  const issues = []
+  const lines = content.split('\n')
+
+  // index ของ '## Requirement:' (H2 เป๊ะ — กัน false-match #### ใน design.md §9; defer #2)
+  const reqIdx = []
+  for (let i = 0; i < lines.length; i++) {
+    if (/^##\s+Requirement:/.test(lines[i])) reqIdx.push(i)
+  }
+  if (reqIdx.length === 0) {
+    issues.push({ code: 'C5', level: 'error', msg: `${name}: ไม่มี "## Requirement:" (≥1)` })
+    return issues
+  }
+
+  // แต่ละ Requirement block = [reqIdx[k] .. reqIdx[k+1]) (หรือจบไฟล์)
+  for (let k = 0; k < reqIdx.length; k++) {
+    const start = reqIdx[k]
+    const end = k + 1 < reqIdx.length ? reqIdx[k + 1] : lines.length
+    const reqTitle = lines[start].replace(/^##\s+Requirement:\s*/, '').trim() || '(ไม่มีชื่อ)'
+
+    // หา '### Scenario:' ใน block นี้
+    const scenIdx = []
+    for (let i = start + 1; i < end; i++) {
+      if (/^###\s+Scenario:/.test(lines[i])) scenIdx.push(i)
+    }
+    if (scenIdx.length === 0) {
+      issues.push({ code: 'C5', level: 'error', msg: `${name}: Requirement "${reqTitle}" ไม่มี "### Scenario:"` })
+      continue
+    }
+    // แต่ละ Scenario block = [scenIdx[j] .. scenIdx[j+1] หรือ end)
+    for (let j = 0; j < scenIdx.length; j++) {
+      const sStart = scenIdx[j]
+      const sEnd = j + 1 < scenIdx.length ? scenIdx[j + 1] : end
+      const scenTitle = lines[sStart].replace(/^###\s+Scenario:\s*/, '').trim() || '(ไม่มีชื่อ)'
+      const body = lines.slice(sStart + 1, sEnd).join('\n')
+      const missing = []
+      if (!/\bGIVEN\b/i.test(body)) missing.push('GIVEN')
+      if (!/\bWHEN\b/i.test(body)) missing.push('WHEN')
+      if (!/\bTHEN\b/i.test(body)) missing.push('THEN')
+      if (missing.length) {
+        issues.push({
+          code: 'C5',
+          level: 'error',
+          msg: `${name}: Scenario "${scenTitle}" ขาด ${missing.join('/')}`,
+        })
+      }
+    }
+  }
+  return issues
+}
+
+// ── render helper ───────────────────────────────────────────────────────────
+const SYM = { error: '✖', warn: '⚠' }
+function countLevels(issues) {
+  let err = 0
+  let warn = 0
+  for (const i of issues) {
+    if (i.level === 'error') err++
+    else if (i.level === 'warn') warn++
+  }
+  return { err, warn }
+}
+
+// ── fs walk (main เท่านั้น — pure fn ไม่รู้จัก fs) ──────────────────────────
+const SKIP_TOPIC = new Set(['achieved'])
+const SKIP_FILE = new Set(['context.md'])
+
+// อ่านไฟล์ทั้งหมดใต้ dir ของ topic เป็น Map<relPath,content> (relPath relative จาก topic dir, POSIX)
+function readTopicFiles(topicDir) {
+  const files = new Map()
+  const walk = (dir, prefix) => {
+    let entries
+    try {
+      entries = readdirSync(dir, { withFileTypes: true })
+    } catch {
+      return // ENOENT/EACCES guard — ข้ามเงียบ ไม่พ่น absolute path
+    }
+    for (const e of entries) {
+      const rel = prefix ? `${prefix}/${e.name}` : e.name
+      if (e.isDirectory()) {
+        walk(join(dir, e.name), rel)
+      } else if (e.isFile()) {
+        if (!e.name.endsWith('.md')) continue
+        try {
+          files.set(rel, readFileSync(join(dir, e.name), 'utf8'))
+        } catch {
+          // ENOENT/EACCES — ข้ามไฟล์ที่อ่านไม่ได้ ไม่ leak path
+        }
+      }
+    }
+  }
+  walk(topicDir, '')
+  return files
+}
+
+// list active topic slugs (dir ใต้ docs/stages/ ข้าม achieved) — ใช้ทั้ง status + slug whitelist (B7)
+function listTopics(stagesDir) {
+  let entries
+  try {
+    entries = readdirSync(stagesDir, { withFileTypes: true })
+  } catch {
+    return []
+  }
+  return entries
+    .filter((e) => e.isDirectory() && !SKIP_TOPIC.has(e.name))
+    .map((e) => e.name)
+}
+
+// walk docs/features/*/spec.md → [{name, content}]
+function readFeatureSpecs(featuresDir) {
+  const specs = []
+  let entries
+  try {
+    entries = readdirSync(featuresDir, { withFileTypes: true })
+  } catch {
+    return specs
+  }
+  for (const e of entries) {
+    if (!e.isDirectory()) continue
+    const specPath = join(featuresDir, e.name, 'spec.md')
+    try {
+      const content = readFileSync(specPath, 'utf8')
+      specs.push({ name: `docs/features/${e.name}/spec.md`, content })
+    } catch {
+      // ไม่มี spec.md → ข้าม (เช็คเฉพาะที่มีไฟล์)
+    }
+  }
+  return specs
+}
+
+// ── main: 2 โหมด ────────────────────────────────────────────────────────────
+function main() {
+  const cwd = process.cwd()
+  const stagesDir = join(cwd, 'docs', 'stages')
+  const featuresDir = join(cwd, 'docs', 'features')
+  const args = process.argv.slice(2)
+
+  if (args.length > 1) {
+    console.error('✖ ใช้: validate-topic.mjs [<slug>] — รับได้สูงสุด 1 arg')
+    process.exit(2)
+  }
+
+  // C5 spec ใช้ทั้งสองโหมด (รวมเข้า total count)
+  const featureSpecs = readFeatureSpecs(featuresDir)
+  const featureIssues = featureSpecs.flatMap((s) => checkFeatureSpec(s.name, s.content))
+
+  if (args.length === 0) {
+    // ── โหมด status ──
+    const topics = listTopics(stagesDir)
+    if (topics.length === 0 && featureIssues.length === 0) {
+      console.log('ไม่มีงานค้าง')
+      process.exit(0)
+    }
+    if (topics.length === 0) {
+      console.log('ไม่มี topic ใน docs/stages/')
+    } else {
+      console.log('topic'.padEnd(28), 'stage'.padEnd(14), '✖/⚠')
+      console.log('-'.repeat(28), '-'.repeat(14), '-----')
+      for (const slug of topics.sort()) {
+        const files = readTopicFiles(join(stagesDir, slug))
+        const { issues, stage } = checkTopic(files)
+        const { err, warn } = countLevels(issues)
+        console.log(slug.padEnd(28), stage.padEnd(14), `✖${err}/⚠${warn}`)
+      }
+    }
+    if (featureIssues.length) {
+      console.log('')
+      console.log(`feature spec (C5): ✖${featureIssues.length}`)
+    }
+    process.exit(0) // status เป็นรายงาน ไม่ใช่ gate
+  }
+
+  // ── โหมด validate <slug> ──
+  const slug = args[0]
+  // slug whitelist (B7): ต้องตรง basename ของ dir ที่มีอยู่จริง — กัน path traversal
+  const topics = listTopics(stagesDir)
+  if (!topics.includes(slug)) {
+    console.error(`✖ ไม่พบ topic "${slug}" ใน docs/stages/`)
+    process.exit(2)
+  }
+
+  const files = readTopicFiles(join(stagesDir, slug))
+  const { issues, stage } = checkTopic(files)
+  // รวม C5 ของ feature spec (เป็น cross-cutting — report ในโหมด validate ด้วย)
+  const allIssues = [...issues, ...featureIssues]
+
+  console.log(`topic: ${slug} · stage (ประมาณการ): ${stage}`)
+  if (allIssues.length === 0) {
+    console.log('✓ โครงครบ (structural)')
+    process.exit(0)
+  }
+  for (const i of allIssues) {
+    console.log(`${SYM[i.level] || '?'} [${i.code}] ${i.msg}`)
+  }
+  const { err } = countLevels(allIssues)
+  process.exit(err > 0 ? 1 : 0)
+}
+
+// main-guard: argv[1] comparison (ไม่ใช่ import.meta.main ที่ undefined บน node 20) — import จาก unit ไม่ trigger main
+if (process.argv[1] && fileURLToPath(import.meta.url) === process.argv[1]) {
+  main()
+}

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

@@ -29,6 +29,7 @@ BUILD จะ **orchestrate การ implement** โดยกระจายง
    - task ใน wave เดียวกัน = independent → รัน **parallel**
    - ข้าม wave = มี dependency → wave ถัดไปเริ่มหลัง wave ก่อนหน้ารวมผลเสร็จ
 3. **Worktree isolation ต่อ task** — แต่ละ parallel task ทำใน git worktree ของตัวเอง ไม่แก้ไฟล์ชนกัน แล้ว **integrate (merge) เข้า build branch หลังจบแต่ละ wave**
+   - **★ worktree fork จาก main (คุมไม่ได้) → agent ต้อง sync build branch ก่อน** — harness fork worktree จาก main จึงยังไม่เห็น `docs/stages/<slug>/` (topic docs) + output ของ wave ก่อนหน้า; build-wave สั่ง agent `git merge <baseRef>` (= build branch) เป็น step แรกก่อนอ่าน task เพื่อให้เห็น dependency ครบ (กลไกอยู่ใน `build-wave.mjs` — orchestrator ส่ง `baseRef` เข้ามา)
    - ถ้า target ไม่ใช่ git repo → fallback เป็น **sequential shared-tree** (ทีละ task ตาม dependency)
 4. **แต่ละ build agent ต้อง self-verify** — implement → รัน test-flow ใน `spec.md` + build/lint → **ต้องผ่านก่อนถึง mark passed**; ถ้าแก้ไม่ได้ให้รายงาน `failed` พร้อมเหตุผล **ห้ามรายงานผ่านทั้งที่ยังแดง**
 5. **เคารพ standard/rule ของ task** — ทำตาม `standard.md` (pattern โค้ด, reuse shared component) และ `rule.md` (กฎ) อย่างเคร่งครัด
@@ -52,9 +53,9 @@ BUILD จะ **orchestrate การ implement** โดยกระจายง
 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`)
-   - แต่ละ agent: implement → test/lint → commit (ถ้า worktree) → รายงานผลแบบ structured (status, files, branch, test result)
-   - **integrate:** main loop merge worktree branch ของ wave นั้นเข้า build branch (ทีละอันเพื่อเลี่ยง conflict); ถ้า conflict → แก้/รายงาน
+   - fan-out sub-agent ของ task ใน wave นั้น (parallel, worktree isolation) ผ่าน **Workflow** (`.warnyin/workflow/scripts/build-wave.mjs`) — orchestrator **ส่ง `baseRef` (= build branch)** เข้า build-wave เพื่อให้ agent sync build branch เข้า worktree ก่อน (เห็น topic docs + output wave ก่อนหน้า)
+   - แต่ละ agent: sync build branch (`git merge <baseRef>`) → implement → test/lint → commit (ถ้า worktree) → รายงานผลแบบ structured (status, files, branch, test result)
+   - **integrate:** main loop checkout **เฉพาะไฟล์ source ที่ scoped** ของ wave นั้นจาก worktree branch (`git checkout <branch> -- <files>` — เลี่ยง topic-docs copy ที่ agent merge เข้า worktree + ปลอด KB#11); ถ้า conflict → แก้/รายงาน
    - ถ้ามี task `failed` → หยุด รายงาน user
 6. **★ Full build & test gate (หลังทุก wave merge เสร็จ):** บน build branch ที่ integrate แล้ว รัน **build ทั้งหมด + test suite ทั้งหมด (รวม unit test)** ของทุก component ที่กระทบ
    - มี error / test แดง → **แก้จนเขียวหมด (loop)** อาจ delegate fix ให้ sub-agent ทีละจุด แล้ว rerun ใหม่

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

@@ -23,7 +23,8 @@
 3. `docs/techstack/<component>/standard.md` — ★ pattern/มาตรฐานการเขียนโค้ด
 4. `docs/techstack/<component>/{about,structure,test}.md`, `docs/codemap/index.md` — โครงสร้าง/วิธีเทสต์
 5. ถ้ามี Discovery → `docs/stages/<slug>/discovery.md`, `research.md`
-6. โค้ดจริงที่เกี่ยวข้อง (inspect เพื่อตอบคำถามแทนการเดา)
+6. `docs/features/<name>/spec.md` — ★ behavior spec ปัจจุบันของ feature ที่ change แตะ (baseline สำหรับเขียน Spec delta; feature ยังไม่มี spec → ข้ามได้)
+7. โค้ดจริงที่เกี่ยวข้อง (inspect เพื่อตอบคำถามแทนการเดา)
 
 ---
 
@@ -46,7 +47,7 @@
 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`) — **ครอบ "Spec delta" ด้วย**: เทียบพฤติกรรมที่ change นี้แตะกับ `docs/features/<name>/spec.md` ปัจจุบัน แล้วเขียน ADDED/MODIFIED/REMOVED (SHIP merge ตามนี้); change ไม่แตะพฤติกรรม feature → ระบุ "ไม่มี delta"
 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**
    2. รวมความเห็นทุก role → สรุปให้ user เห็นภาพ
@@ -77,7 +78,7 @@
 |---|---|---|---|
 | `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` |
+| `design.md` | how — vertical slice, data model, contract, flow, **Spec delta** | จำเป็น | `.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` |
@@ -108,7 +109,8 @@
 - [ ] proposal.md (+ business.md ถ้าจำเป็น) + design.md ครบ และ user เห็นชอบ
 - [ ] **ไม่มีการเดา** — ทุกจุดที่ไม่ชัดถูกถาม (ทีละข้อ + recommended answer) และปิดแล้ว
 - [ ] design เป็น vertical slice ชัด — แต่ละ task/slice ส่งมอบคุณค่า end-to-end ได้
-- [ ] ทุก task มี `spec.md` + `standard.md` + `rule.md` + `task.md` ครบ
+- [ ] **Spec delta ครบ** — เทียบ `docs/features/<name>/spec.md` ของ feature ที่แตะ (ADDED/MODIFIED/REMOVED) หรือระบุ "ไม่มี delta"
+- [ ] ทุก task มี `spec.md` + `standard.md` + `rule.md` + `task.md` ครบ (ถ้ารัน node ได้: `node .warnyin/workflow/scripts/validate-topic.mjs <slug>` ควรไม่มี ✖ — เช็คโครง ไม่แทนการอ่าน semantic)
 - [ ] dependency / ลำดับระหว่าง task และ sub-task ชัดเจน เชื่อมต่อกัน
 - [ ] rule ที่ต้อง follow ถูกระบุครบ; rule/standard ใหม่ที่อยากเพิ่มถูก note ไว้ (รอ SHIP)
 - [ ] ถ้าทำ review panel: **blocker จากทุก role ถูกแก้/ปิดครบ** — สรุปผลบันทึกใน `design.md` section "Design review"

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

@@ -33,7 +33,7 @@
 2. **ขอ user ยืนยัน "ครั้งเดียวก่อนลงมือ"** — สรุป promotion plan (feature ใหม่หรือปรับปรุง, ไฟล์กลางที่จะอัปเดต + สาระที่จะใส่, ชื่อโฟลเดอร์ archive) ให้ user อนุมัติ แล้วจึง execute ไม่ถามซ้ำระหว่างทาง
 3. **★ Archive ก่อนอัปเดตเอกสาร** — ย้ายทั้งโฟลเดอร์ `docs/stages/<slug>/` → `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` (วันที่ของวันที่ SHIP) **ก่อน** เริ่มแก้ `docs/` แล้วอ่านเนื้อหาจาก path ใหม่ระหว่าง promote
 4. **กลั่น ไม่ใช่ copy ดิบ** — merge สาระเข้าโครงสร้างของไฟล์กลางเดิม ระวัง duplicate/ขัดแย้งกับเนื้อหาที่มีอยู่; เขียนแบบ "ความรู้ถาวร" ไม่ใช่บันทึกรายงาน
-5. **เอกสารต้องตรงโค้ดจริง** — structure/codemap อัปเดตจากการดูโค้ดจริง ไม่ใช่จากความจำหรือ design เดิม
+5. **เอกสารต้องตรงโค้ดจริง** — structure/codemap อัปเดตจากการดูโค้ดจริง ไม่ใช่จากความจำหรือ design เดิม; **ครอบ Spec delta ด้วย** — ถ้าพฤติกรรมจริง (หลัง BUILD/VERIFY) ต่างจาก delta ที่ approve ไว้ → **อัปเดต delta ใน design.md ก่อน แล้วค่อย merge**; และ re-check delta เทียบ `spec.md` ปัจจุบัน ณ เวลา ship (ไม่ใช่ ณ เวลา design)
 6. **อย่าเดา** — เนื้อหาที่ไม่แน่ใจว่าควร 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 หรือตัดทิ้งพร้อมเหตุผล) ห้ามปล่อยค้าง
 
@@ -41,7 +41,7 @@
 
 ## 4. ลำดับขั้นการทำงาน (process)
 
-1. **อ่านทำความเข้าใจ topic + รวบรวม learned-rule candidate:** อ่าน `docs/stages/<slug>/` ทุกไฟล์ — topic นี้ทำอะไร ทำอย่างไร เกิดความรู้ใหม่อะไรบ้าง (เช็คก่อนว่า VERIFY ผ่าน Gate แล้ว — มี `verify.md` สรุปผลผ่าน) — พร้อมกันนั้น **รวบรวม learned-rule candidate** เป็นตาราง (ทุกตัว = `rule + evidence + scope + promote?`):
+1. **อ่านทำความเข้าใจ topic + รวบรวม learned-rule candidate:** อ่าน `docs/stages/<slug>/` ทุกไฟล์ — topic นี้ทำอะไร ทำอย่างไร เกิดความรู้ใหม่อะไรบ้าง (เช็คก่อนว่า VERIFY ผ่าน Gate แล้ว — มี `verify.md` สรุปผลผ่าน; ถ้ารัน node ได้ → รัน `node .warnyin/workflow/scripts/validate-topic.mjs <slug>` — มี ✖ ควรแก้ก่อน promote (script เช็คโครง; ความถูกของเนื้อหายังเป็นหน้าที่ผู้ ship)) — พร้อมกันนั้น **รวบรวม 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`
@@ -49,7 +49,7 @@
 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
+   1. **`docs/features/<feature-name>/`** — feature ใหม่ → สร้างโฟลเดอร์ใหม่ (`feature.md` + `business.md`); ปรับปรุง feature เดิม → อัปเดตโฟลเดอร์เดิม โดยใช้เนื้อหาจาก `business.md` / `proposal.md` / `design.md` ของ topic — **และ merge `spec.md`** ตาม Spec delta ใน `design.md` §9: **ADDED** → ต่อท้าย `spec.md` · **MODIFIED** → แทนที่ requirement ชื่อตรงกัน (rename → หาด้วย `[เดิมชื่อ:]`) · **REMOVED** → ลบ requirement; **read-modify-verify — key ไม่เจอ → STOP:** MODIFIED/REMOVED ที่หา key ไม่เจอใน `spec.md` ของ feature ที่ `(→ feature:)` ระบุ → **หยุด ถาม user ห้าม merge เงียบ** (ห้ามตีความเป็น ADDED เอง); **feature ใหม่** → สร้าง `spec.md` จาก ADDED ทั้งก้อน (template `[feature-name]/spec.md`); **feature เดิมยังไม่มี `spec.md`** → สร้างใหม่จาก delta + พฤติกรรมจริง
    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`
@@ -65,7 +65,7 @@
 
 | ที่ | เนื้อหา |
 |---|---|
-| `docs/features/<feature-name>/` | feature.md + business.md (สร้างใหม่หรืออัปเดต) |
+| `docs/features/<feature-name>/` | feature.md + business.md + spec.md (สร้างใหม่หรืออัปเดต — spec.md merge ตาม Spec delta) |
 | `docs/techstack/<component>/{rule,standard,structure,test}.md` | rule/standard ใหม่, โครงสร้าง, วิธีเทสที่ promote ขึ้น |
 | `docs/rule.md` | global rule ที่เพิ่ม/เปลี่ยน |
 | `docs/troubleshooting.md` | KB ปัญหา-วิธีแก้ที่ merge เข้า |
@@ -79,6 +79,7 @@
 
 - [ ] topic ถูกย้ายไป `docs/stages/achieved/<YYYY-MM-DD>-<slug>/` แล้ว (ไม่เหลือใน `docs/stages/`)
 - [ ] `docs/features/` สะท้อน feature ใหม่/ที่ปรับปรุงแล้ว
+- [ ] **Spec delta merge แล้ว** — `spec.md` ของ feature ที่แตะถูก merge ตาม delta; ทุก MODIFIED/REMOVED match requirement จริง (read-modify-verify — key ไม่เจอ → STOP ถาม user แล้ว ไม่ merge เงียบ)
 - [ ] 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` อัปเดตตามที่เกี่ยวข้อง

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

@@ -17,17 +17,18 @@
 
 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**)
+2. **`docs/features/<name>/spec.md` = regression baseline** — อ่าน behavior spec ของ feature ที่ topic แตะ (ดูจาก Spec delta ใน `design.md`); topic แตะหลาย feature → baseline = union ของ spec ทุก feature ที่ delta อ้างถึง; feature ยังไม่มี spec → ข้ามได้ (วิธีเดิม)
+3. **`docs/techstack/<component>/test.md`** — guideline ว่าเทสยังไง (เช่น frontend: e2e smoke ผ่าน **playwright-cli**)
    → ถ้า **ไม่มี** 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 แตะของจริง
+4. **`docs/infra.md`** — local env / service ที่ต้องรันเพื่อเทส
+5. **`docs/troubleshooting.md`** — เผื่อปัญหาที่จะเจอเคยถูกแก้แล้ว
+6. **runtime security** (`.warnyin/workflow/roles/security.md` → "Runtime / operational security") — ตอนรันเทส local env ที่มี secret จริง ทบทวน secret isolation / no-egress / identity separation ก่อนปล่อย agent แตะของจริง
 
 ---
 
 ## 3. หลักการทำงาน (operating principles)
 
-1. **เข้าใจจุดประสงค์ก่อนเทส** — เทสตามเจตนาของ topic ไม่ใช่แค่ให้เขียว
+1. **เข้าใจจุดประสงค์ก่อนเทส** — เทสตามเจตนาของ topic ไม่ใช่แค่ให้เขียว **และพฤติกรรมเดิมจาก feature spec** — scenario เดิมใน `docs/features/<name>/spec.md` = regression case (ต้องไม่พัง ยกเว้นที่ MODIFIED/REMOVED ระบุ), scenario ใน Spec delta = test case ใหม่
 2. **เทสในสภาพแวดล้อมจริง (local env)** — รัน service ที่เกี่ยวข้องใน local แล้วเทสตามแผน
 3. **ใช้ guideline จาก `test.md`** ของ techstack; ถ้าไม่มีให้เสนอวิธีเทสที่เหมาะแล้วเขียนแผนเอง
 4. **Frontend → verify UX/UI ด้วย** (ไม่ใช่แค่ functional — ดู layout, state, flow, ความถูกต้องของหน้าจอ)
@@ -44,8 +45,8 @@
 ## 4. ลำดับขั้นการทำงาน (process)
 
 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 ฯลฯ) แล้วเขียนแผน
+1. **เข้าใจจุดประสงค์ + อ่าน baseline:** อ่าน spec/tasks/design + `docs/features/<name>/spec.md` ของ feature ที่ topic แตะ (union ถ้าหลาย feature) → สรุปสิ่งที่ต้อง verify (functional + UX/UI)
+2. **วางแผนเทส → เขียน `test.md`:** ตาม guideline `docs/techstack/<component>/test.md`; ไม่มีก็เสนอวิธี (e2e smoke / integration / manual ฯลฯ) แล้วเขียนแผน — **ครอบทั้ง regression (scenario เดิมใน baseline) + test case ใหม่ (scenario ใน Spec delta)**
 3. **เตรียม local env:** รัน service ที่เกี่ยวข้องตาม `infra.md`
 4. **รันเทสตามแผน:** functional ตาม test-flow ใน spec; FE → e2e smoke (playwright-cli) + ตรวจ UX/UI
 5. **ไม่ผ่าน → แก้ → rerun:** วนจนผ่าน **นับจำนวนรอบ/จำนวนแก้**; ปัญหายาก→`troubleshooting.md`; ถ้านานเกิน→ถาม user (ทีละข้อ + recommended)
@@ -67,6 +68,7 @@
 ## 6. Gate → เข้า SHIP ได้เมื่อ
 
 - [ ] เทสตาม **จุดประสงค์ของ topic** ครบ (functional ตาม test-flow ใน spec)
+- [ ] **regression ตาม baseline** — scenario เดิมใน `docs/features/<name>/spec.md` ของ feature ที่แตะ ยังผ่าน (ยกเว้นที่ MODIFIED/REMOVED) + scenario ใน Spec delta ผ่าน
 - [ ] Frontend: **UX/UI verify ผ่าน**
 - [ ] ทุกข้อที่ไม่ผ่านถูกแก้จน **verify ผ่านหมด**
 - [ ] `test.md` (แผน) + `verify.md` (สรุป + จำนวนการแก้ไข) เขียนครบ