@warnyin/agents 0.10.0 → 0.12.0

package/CHANGELOG.md

@@ -23,6 +23,16 @@
 
 ## [Unreleased]
 
+## [0.12.0] - 2026-06-11
+
+### Added
+- **Change sizing — ประเมินขนาด change ก่อนจ่าย ceremony แล้วจ่ายให้พอดี** (feature `change-sizing`) — capability ใหม่ `/warnyin:triage` (read-only router) + playbook `src/.warnyin/workflow/triage.md`: รับคำอธิบาย change → จัดเป็น **3 tier `{fast, standard, large}`** ด้วย rubric (signals + tie-break ก้ำกึ่ง→standard + **hard-floor 5 หมวด** [auth/authz · data-migration/schema · secret/credential · public-API/contract(breaking) · security-sensitive] บังคับ ≥ standard เสมอ + escalation/downgrade symmetric) → **แนะนำ route แล้วหยุด** (ให้ user สั่ง command เอง — pattern เดียวกับ `next`; triage = request by size, next = topic by stage). **fast-track wiring ครบ 4 stage แบบ unify-in-place:** reframe `stages/design.md §7` (2-level → 3-tier ชี้ skip-list canonical, tier `large` บังคับ `/warnyin:discovery`) + pointer hook ใน `stages/verify.md` (verify-lite) + `stages/ship.md` (ship-lite) — **rubric canonical อยู่ที่ `triage.md` เดียว** ทุกที่ชี้ด้วย markdown-link/backtick runtime-ref ไม่ duplicate. **fast-track ลดเฉพาะ ceremony ไม่ลด correctness** (skip-list ต่อ stage แต่คง test-floor/archive); ต่อยอด `build-orchestration` (fast → model `cheap` + DAG width 1). adapter `src/.claude/commands/warnyin/triage.md` + register ใน slash-command list; tool-agnostic (playbook กลางทุก harness อ่านได้). payload ติดมากับ `--update` รอบถัดไป
+
+## [0.11.0] - 2026-06-10
+
+### Added
+- **Build orchestration — BUILD เร็วขึ้นด้วย DAG กว้าง + model routing + lean verify** (feature `build-orchestration`) — แก้ root cause ที่ BUILD ช้า ("1 agent/wave, chain ยาว") โดยปรับ playbook 2 ชั้นแบบ **unify-in-place**: **(โครงสร้าง — DESIGN)** `src/.warnyin/workflow/stages/design.md` §3 เพิ่ม **DAG-width toolkit** (3 เทคนิคลด serialization: contract-first decouple / re-slice ต่างแกน / ยอม serialize เฉพาะ chain แท้ — toolkit optional คงนิยาม vertical slice เดิม) + **critical-path gate** (Gate §8 judgment: วัด critical-path depth + max wave width; chain เส้นตรงต้องมีเหตุผล explicit) + **task/context lean**; `roles/tech-lead.md` checklist + template `design.md` §7 (ช่อง depth/wave-width). **(กลไก — BUILD)** `src/.warnyin/workflow/scripts/build-wave.mjs` รับ `tasks: string[] | Array<{name, model?}>` — `model` per task แบบ **pass-through** เข้า `agent()` (ไม่ map/hardcode ชื่อรุ่น — payload generic); orchestrator `src/.claude/commands/warnyin/build.md` map tier→รุ่นจริง (Claude adapter); `stages/build.md` §3 ทำ **self-verify = scope component ตัวเอง** (integration เลื่อนไป full-gate ที่คง blocking). vocab tier generic `{cheap, balanced, deepest}` ใน `task.md` field `Model tier` (ไม่ระบุ = balanced; ไม่แตะ `balanced+` ของ review). **พิสูจน์เชิงประจักษ์:** งานอิสระ 4 task ขนาน 1 wave เทียบ chain 4 wave = **~3.95× เร็วขึ้น** (token เท่ากัน) + redesign DAG ของ scaffold-foundation chain depth 4 → wave width 2. **backward compatible** (`tasks: string[]` เดิม + ไม่ส่ง `model` → พฤติกรรมเดิม); payload ติดมากับ `--update` รอบถัดไป
+
 ## [0.10.0] - 2026-06-09
 
 ### Added

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@warnyin/agents",
-  "version": "0.10.0",
+  "version": "0.12.0",
   "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

@@ -8,11 +8,12 @@ argument-hint: "[slug ของ topic]"
 0. **★ เช็ค context window ก่อนเริ่ม:** ถ้า context ของ session ถูกใช้ไปเยอะหรือ**เกินครึ่ง** → เสนอ user ให้ `/compact` หรือ `/clear` ก่อนเสมอ แล้วค่อยรัน `/warnyin:build <slug>` ใหม่ใน context ที่โล่ง (สถานะงานอยู่ในไฟล์ `docs/stages/<slug>/` ครบ) — อย่าเริ่ม fan-out ทั้งที่ context ใกล้เต็ม
 1. อ่าน `.warnyin/workflow/stages/build.md` ให้ครบก่อน แล้วทำตามทุกหลักการอย่างเคร่งครัด
 2. slug: $ARGUMENTS — ถ้าไม่ระบุให้ถามก่อน ว่าจะ build topic ไหน (ดูโฟลเดอร์ใน `docs/stages/`)
-3. **อ่าน task ทั้งหมด** ใน `docs/stages/<slug>/tasks/*/task.md` + `design.md` → ดึง dependency → สร้าง DAG → จัด **wave** ด้วย topological order
+3. **อ่าน task ทั้งหมด** ใน `docs/stages/<slug>/tasks/*/task.md` + `design.md` → ดึง dependency → สร้าง DAG → จัด **wave** ด้วย topological order · อ่าน field **`Model tier`** ของแต่ละ task ด้วย (generic `{cheap, balanced, deepest}`; ไม่มี = `balanced`) เพื่อใช้ map ตอนส่งเข้า build-wave (step 6)
 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, baseRef: "<ชื่อ build branch ที่สร้าง step 4>" } }` — `baseRef` = build branch จริง (worktree fork จาก main → agent merge build branch เองก่อนทำงาน เพื่อเห็น `docs/stages/<slug>/` + output ของ wave ก่อนหน้า)
+   - **map tier→รุ่นจริง (Claude adapter):** สำหรับแต่ละ task ใน wave นี้ → อ่าน `Model tier` generic จาก `task.md` แล้ว map เป็นชื่อรุ่นจริงของ harness นี้: `cheap → claude-haiku-4-5` · `balanced → claude-sonnet-4-6` · `deepest → claude-opus-4-8` (ไม่ระบุ tier = `balanced`) — orchestrator เป็นคน map (payload `build-wave` คง generic ไม่ผูกชื่อรุ่น)
+   - เรียก **Workflow** ด้วย `{ scriptPath: ".warnyin/workflow/scripts/build-wave.mjs", args: { slug, tasks: [{ name: "<task ใน wave นี้>", model: "<ชื่อรุ่นจริงที่ map ได้>" }, ...], isolate, baseRef: "<ชื่อ build branch ที่สร้าง step 4>" } }` — `tasks` ส่งเป็น `{name, model}[]` (build-wave รับทั้ง `string[]` เดิมและ `{name, model?}[]`; `model` เป็น pass-through เข้า `agent()` ตรงๆ) · `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)

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

@@ -14,6 +14,7 @@ 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`
+   - **Model tier ต่อ task:** ตอนแตก task ระบุ field `Model tier` ใน `task.md` (generic `{cheap, balanced, deepest}`; ไม่ระบุ = `balanced`) — mechanical/scaffold/config → `cheap` · implement ตาม spec ปกติ → `balanced` · logic หนัก/security/algorithm/ไม่เคยทำ → `deepest` (BUILD orchestrator map tier→รุ่นจริงตอน fan-out — ดู `contexts/README.md` §"Model tier")
    - **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`

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

@@ -0,0 +1,14 @@
+---
+description: ประเมินขนาด change → แนะนำ tier (fast/standard/large) + route ที่ควรไปต่อ แบบ read-only — แนะนำแล้วหยุด
+argument-hint: "[คำอธิบาย change ที่อยากประเมินขนาด]"
+---
+
+ทำหน้าที่เป็น change-sizing router ตาม **playbook กลาง** ของ workflow มาตรฐาน
+
+1. อ่าน `.warnyin/workflow/triage.md` ให้ครบก่อน แล้วทำตามทุกหลักการในนั้นอย่างเคร่งครัด
+   (**read-only เด็ดขาด — ห้ามสร้าง/แก้/ลบไฟล์ใดๆ**, แนะนำแล้วหยุด ให้ user สั่ง command เอง)
+2. ขอบเขต (คำอธิบาย change): $ARGUMENTS
+   - ไม่ระบุ → ถาม user ว่าอยากประเมิน change อะไร
+3. ประเมิน tier ตาม rubric ใน playbook (signals + hard-floor) จากคำอธิบาย change (+ inspect โค้ดที่อ้างถึงได้ แบบ read-only)
+4. รายงานในแชท: tier + เหตุผล (signals ที่เจอ) + route ที่แนะนำ + คำเตือน hard-floor (ถ้ามี)
+5. ไม่รัน stage ต่อให้เอง — เสนอ command ที่แนะนำ ให้ user ตัดสินใจ

package/src/.warnyin/installer/templates/CLAUDE.md

@@ -15,6 +15,7 @@
 - `/warnyin:update-codemaps` → สแกนโครงสร้าง + สร้าง/อัปเดต codemap แบบ token-lean (`.warnyin/workflow/codemap.md`)
 - `/warnyin:explore [คำถาม]` → สำรวจ/ตอบคำถามแบบ read-only — ไม่สร้าง artifact (`.warnyin/workflow/explore.md`)
 - `/warnyin:next [slug]` → เช็คงานค้าง + แนะนำ command ถัดไป แบบ read-only (`.warnyin/workflow/next.md`)
+- `/warnyin:triage [คำอธิบาย change]` → ประเมินขนาด + แนะนำ path (read-only) (`.warnyin/workflow/triage.md`)
 - `/warnyin:discovery [topic]` → Discovery stage (`.warnyin/workflow/stages/discovery.md`)
 - `/warnyin:design [slug] [change]` → DESIGN stage (`.warnyin/workflow/stages/design.md`)
 - `/warnyin:build [slug]` → BUILD stage — fan-out sub-agent ตาม dependency (`.warnyin/workflow/stages/build.md` + `.warnyin/workflow/scripts/build-wave.mjs`)

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

@@ -31,13 +31,19 @@
 - จุดที่ต้องระวัง / backward compatibility:
 
 ## 7. Dependency ระหว่าง slice/task
-> slice/task เชื่อมกันยังไง ลำดับการทำ
+> slice/task เชื่อมกันยังไง ลำดับการทำ — วาด DAG แล้ววัด width (กัน chain เผลอ)
 
 ```
 task-1 ──▶ task-2 ──▶ task-3
               └──▶ task-4
 ```
 
+- **critical-path depth (longest chain):** <จำนวน wave ของ chain ที่ยาวที่สุด>
+- **max wave width:** <จำนวน task สูงสุดใน wave เดียว — >1 = ขนานได้>
+- **เหตุผลถ้า task ใดถูก serialize:** <ถ้า DAG เป็น chain เส้นตรง (ทุก wave 1 task) → ทำไม decouple ด้วย DAG-width toolkit (design.md §3 ข้อ 2) ไม่ได้>
+
+
+
 ## 8. Test strategy ระดับ design
 - จะยืนยันว่า design ทำงานถูกอย่างไร (ภาพรวม — รายละเอียดอยู่ใน task spec):
 

package/src/.warnyin/template/stages/[topic]/tasks/[task-name]/task.md

@@ -8,6 +8,7 @@
 | **Task** | `<kebab-case>` |
 | **Slice อ้างอิง** | `design.md` slice #__ |
 | **Component** | `admin-console` / `api-service` / ... |
+| **Model tier** | `cheap` / `balanced` / `deepest` _(optional; ไม่ระบุ = `balanced` — ดู `contexts/README.md` §"Model tier")_ |
 | **สถานะ** | `รอ build` / `กำลังทำ` / `เสร็จ` |
 
 ## 1. เป้าหมายของ task (vertical slice)

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

@@ -41,6 +41,7 @@ Discovery (optional) ──▶ DESIGN ──▶ BUILD ──▶ VERIFY ──▶
     codemap.md         #   playbook: CODEMAP — สแกน + สร้าง codemap แบบ token-lean
     explore.md         #   playbook: EXPLORE — สำรวจ/ตอบคำถามแบบ read-only ไม่สร้าง artifact
     next.md            #   playbook: NEXT — เช็คงานค้าง + แนะนำขั้นตอนถัดไป (read-only)
+    triage.md          #   capability: TRIAGE — ประเมินขนาด change → tier + route (read-only)
     api-doc.md         #   capability: API-DOC — adaptive OpenAPI 3.1 contract (DESIGN/VERIFY/SHIP เรียกเอง)
     stages/            #   discovery ✅ · design ✅ · build ✅ · verify ✅ · ship ✅
     roles/             #   role card กลาง (task-level lens): ba, po, sa, tech-lead, developer, qa, security, infra

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

@@ -47,3 +47,5 @@
 | `review` | `balanced+` | ตรวจ/จับ bug — ไม่ลด (พลาดแพงกว่า token) |
 
 > **tool-agnostic:** ใช้ vocab generic **ไม่ผูกชื่อรุ่น/ผลิตภัณฑ์ของ harness ใด ๆ** — แต่ละ harness map tier → รุ่นเอง (เทียบแนวทาง model selection ของ harness เช่นไฟล์ rules ฝั่ง performance); เป็น **guidance** ไม่ใช่ enforce
+
+> **per-task ใน BUILD (เพิ่มจาก per-context):** นอกจาก tier ระดับ context ด้านบน BUILD ยังกำหนด **model tier ต่อ task** ได้ผ่าน field `Model tier` ใน `task.md` — ใช้ subset `{cheap, balanced, deepest}` (ไม่ระบุ = `balanced` ตาม context build); mapping: mechanical/scaffold/config → `cheap` · implement ตาม spec ปกติ → `balanced` · logic หนัก/security/algorithm/ไม่เคยทำ → `deepest`. orchestrator ใน command (adapter) map tier→รุ่นจริง แล้วส่งเข้า `build-wave` per task — payload คง generic ตามเดิม

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

@@ -18,7 +18,7 @@ slice เล็กจบในตัว, "เขียว" ต้องเขี
 ## 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 — งานกำหนดไว้แล้ว)
+- **Model tier:** `balanced` (orchestrator/main loop ที่ตัดสินใจ integrate); **fan-out worker per task** ตาม field `Model tier` ใน `task.md` (subset `{cheap, balanced, deepest}`; ไม่ระบุ = `balanced`): mechanical/scaffold/config → `cheap` · implement ตาม spec ปกติ → `balanced` · logic หนัก/security/algorithm/ไม่เคยทำ → `deepest` (คุม token/cost ต่อ agent — ดู `contexts/README.md` §"Model tier")
 
 ## ใช้คู่ stage ไหน
 - ปลาย DESIGN (แตก task) → [`stages/design.md`](../stages/design.md)

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

@@ -19,6 +19,7 @@ implement vertical slice ที่รับมอบให้ **เสร็จ
 - [ ] เข้าใจไฟล์ก่อนแก้ (ใครใช้/contract/เจตนา) — ไม่แก้แบบไม่เข้าใจ (investigate-before-edit)
 - [ ] ไม่แก้ config/test ให้เขียวแทนแก้โค้ดจริง — config ผิดจริงแก้ได้ + เหตุผล + note (config-protection)
 - [ ] รัน test-flow ใน spec.md + build/lint **ผ่านจริง** — ห้ามรายงาน passed ทั้งที่ยังแดง
+- [ ] self-verify = **scope ตัวเองเท่านั้น** — test-flow ใน spec.md = unit + lint ของ **component ที่ task แตะ** ไม่ใช่ทั้ง repo; **ไม่รัน full cross-component build/integration/e2e ต่อ task** (integration cover ที่ full-gate หลัง merge ทุก wave — build.md §3 ข้อ 8 / §4 ข้อ 6)
 - [ ] ไม่ทิ้งขยะ: debug code, commented-out code, TODO ลอยๆ
 - [ ] เจอปัญหา → อ่าน `docs/troubleshooting.md` ก่อน; ปัญหายาก/ซ้ำที่แก้ได้ → รายงานในฟิลด์ troubleshooting
 - [ ] รายงานตรงความจริงทุกฟิลด์ — แก้ไม่ได้ให้ `failed` พร้อมเหตุผล ดีกว่า passed ปลอม

package/src/.warnyin/workflow/roles/tech-lead.md

@@ -12,9 +12,9 @@
 - reuse ก่อนเขียนใหม่เสมอ
 
 ## Checklist
-- [ ] แต่ละ task ขนาดพอเหมาะ: sub-agent ตัวเดียวทำจบ มี spec ครบในตัว ไม่ต้องเดา
+- [ ] แต่ละ task ขนาดพอเหมาะ: sub-agent ตัวเดียวทำจบ มี spec ครบในตัว **+ กระชับ; brief ยาวผิดปกติ → recheck dependency/re-slice** ไม่ต้องเดา
 - [ ] dependency graph ถูกต้อง ไม่มี cycle, ไม่มี dependency แอบแฝงที่ไม่ได้ระบุ (เช่น แก้ไฟล์เดียวกัน)
-- [ ] task ใน wave เดียวกัน parallel ได้จริง — ไม่ชนไฟล์/ตารางเดียวกัน
+- [ ] task ใน wave เดียวกัน parallel ได้จริง — ไม่ชนไฟล์/ตารางเดียวกัน **และ DAG ไม่ลึกเกินจำเป็น (ลอง DAG-width toolkit ก่อนยอม serialize — contract-first / re-slice ต่างแกน / serialize เฉพาะ chain แท้)**
 - [ ] จุดเสี่ยง technical (ของยาก/ไม่เคยทำ/พึ่งระบบนอก) ถูกระบุ + มีแผนรองรับ
 - [ ] ของเดิมที่ reuse ได้ถูกชี้ใน standard.md ของ task — ไม่ปล่อยให้ agent เขียนซ้ำ
 - [ ] effort สมเหตุผลกับคุณค่า — ถ้า task ใดแพงผิดปกติ ตั้งคำถามกับ design

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

@@ -3,7 +3,10 @@
 //
 // args = {
 //   slug: string,            // ชื่อ topic เช่น "billing-redesign"
-//   tasks: string[],         // ชื่อ task ใน wave นี้ (โฟลเดอร์ docs/stages/<slug>/tasks/<task>)
+//   tasks: string[] | Array<{ name: string, model?: string }>,
+//                            // ชื่อ task ใน wave นี้ (โฟลเดอร์ docs/stages/<slug>/tasks/<task>)
+//                            // รับทั้ง string[] (เดิม, backward compat) และ {name, model?}[] — normalize ภายในเป็น {name, model}
+//                            // model = pass-through string (orchestrator map tier→รุ่นจริงก่อนส่งเข้ามา); script ไม่ map/ไม่ hardcode ชื่อรุ่น
 //   isolate?: boolean,       // true = worktree ต่อ task (ดีฟอลต์), false = shared tree (sequential)
 //   baseRef?: string,        // ชื่อ build branch เช่น "build/my-topic"; ไม่ส่ง = ไม่ sync (backward compat)
 // }
@@ -17,10 +20,29 @@ export const meta = {
 // บาง harness ส่ง args ของ Workflow เป็น string (JSON text) ไม่ใช่ object — รับทั้งสองแบบ
 const A = typeof args === 'string' ? JSON.parse(args) : (args || {})
 const slug = A.slug
-const tasks = A.tasks || []
 const isolate = !(A.isolate === false)
 const baseRef = A.baseRef || null   // ชื่อ build branch เช่น "build/my-topic"; ไม่ส่ง = ไม่ sync (backward compat)
 
+// normalize tasks: รับทั้ง string[] (เดิม) และ {name, model?}[] (ใหม่) → ภายในเป็น {name, model} เสมอ
+// string element → {name, model: undefined} (backward compat); model = pass-through string ไม่ map/ไม่ hardcode
+export function normalizeTasks(rawTasks) {
+  return (rawTasks || []).map((t) =>
+    typeof t === 'string' ? { name: t, model: undefined } : { name: t.name, model: t.model })
+}
+
+// สร้าง opts ของ agent() แบบ immutable — conditional spread: key หายเมื่อไม่มีค่า (ไม่ใช่ undefined)
+// แนวเดียวกับ baseRef เดิม (optional arg, conditional เฉพาะเมื่อมีค่า)
+export function buildOpts(task, isolate) {
+  return {
+    label: `build:${task.name}`,
+    schema: RESULT_SCHEMA,
+    ...(isolate && { isolation: 'worktree' }),
+    ...(task.model && { model: task.model }),
+  }
+}
+
+const tasks = normalizeTasks(A.tasks)
+
 if (!slug || tasks.length === 0) {
   log('ไม่มี slug หรือ tasks — ไม่มีอะไรให้ build')
   return { slug: slug || null, results: [], failed: [] }
@@ -109,16 +131,12 @@ function prompt(task) {
 }
 
 const results = await parallel(
-  tasks.map((task) => () =>
-    agent(prompt(task), isolate
-      ? { label: `build:${task}`, schema: RESULT_SCHEMA, isolation: 'worktree' }
-      : { label: `build:${task}`, schema: RESULT_SCHEMA })
-  )
+  tasks.map((task) => () => agent(prompt(task.name), buildOpts(task, isolate)))
 )
 
 const clean = results.filter(Boolean)
 const failed = clean.filter((r) => r.status === 'failed').map((r) => r.task)
-const skipped = tasks.filter((t) => !clean.some((r) => r.task === t))
+const skipped = tasks.filter((t) => !clean.some((r) => r.task === t.name)).map((t) => t.name)
 
 log(`เสร็จ ${clean.length}/${tasks.length} · ผ่าน ${clean.length - failed.length} · ล้ม ${failed.length}${skipped.length ? ` · ข้าม ${skipped.length}` : ''}`)
 

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

@@ -31,11 +31,11 @@ BUILD จะ **orchestrate การ implement** โดยกระจายง
 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` พร้อมเหตุผล **ห้ามรายงานผ่านทั้งที่ยังแดง**
+4. **แต่ละ build agent ต้อง self-verify (scope = component ตัวเองเท่านั้น)** — implement → รัน test-flow ใน `spec.md` + build/lint **ของ component ที่ task นั้นแตะ (unit + lint ของ component นั้น) ไม่ใช่ทั้ง repo** → **ต้องผ่านก่อนถึง mark passed**; ถ้าแก้ไม่ได้ให้รายงาน `failed` พร้อมเหตุผล **ห้ามรายงานผ่านทั้งที่ยังแดง** — **cross-component / integration / e2e ไม่ต้องรันต่อ task** (เลื่อนไป full-gate ข้อ 8 / §4 ข้อ 6) กันรันซ้ำเสียเวลา
 5. **เคารพ standard/rule ของ task** — ทำตาม `standard.md` (pattern โค้ด, reuse shared component) และ `rule.md` (กฎ) อย่างเคร่งครัด
 6. **ห้ามแตะ rule/standard กลางใน `docs/`** — rule ใหม่ที่เสนอถูก note ไว้ใน `tasks/<task>/rule.md` แล้ว รอ SHIP ค่อยอัปเดตไฟล์กลาง
 7. **fail = หยุดที่ wave นั้น** — ถ้า task ใน wave ล้ม ให้รายงาน user ก่อนไป wave ถัดไป (เพราะ wave ถัดไปอาจ depend อยู่)
-8. **★ ปิดท้ายด้วย full build + full test เสมอ** — หลัง merge ทุก wave แล้ว ต้องรัน build ทั้งหมด + test suite ทั้งหมด (รวม unit test) บน build branch ที่ integrate; **แก้วนจนเขียวหมด** ก่อนปิด BUILD (กันกรณี task รายเดี่ยวเขียวแต่พอรวมกันแล้วพัง)
+8. **★ ปิดท้ายด้วย full build + full test เสมอ (blocking gate — ห้ามลด bar)** — หลัง merge ทุก wave แล้ว ต้องรัน build ทั้งหมด + test suite ทั้งหมด (รวม unit test) + cross-component/integration บน build branch ที่ integrate; **แก้วนจนเขียวหมด** ก่อนปิด BUILD (กันกรณี task รายเดี่ยวเขียวแต่พอรวมกันแล้วพัง) — **gate นี้คงเป็น blocking เสมอ** การที่ข้อ 4 ลด self-verify ของ agent เหลือ scope component เดียว **ไม่ได้ลดความเข้มของ full-gate** (integration coverage ย้ายมารวมที่นี่ ไม่ใช่ตัดทิ้ง); ห้ามแปลง gate นี้เป็น optional/informational เพื่อให้ "ดูเร็วขึ้น"
 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 / อ่านโค้ดที่อ้างถึง ก่อนแก้)
@@ -57,7 +57,7 @@ BUILD จะ **orchestrate การ implement** โดยกระจายง
    - แต่ละ 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 ที่กระทบ
+6. **★ Full build & test gate (หลังทุก wave merge เสร็จ — blocking, ห้ามลด bar):** บน build branch ที่ integrate แล้ว รัน **build ทั้งหมด + test suite ทั้งหมด (รวม unit test) + cross-component/integration** ของทุก component ที่กระทบ — นี่คือจุดที่ครอบ integration ที่ self-verify ต่อ task (§3 ข้อ 4) ไม่ได้รัน จึง **ต้องคงเป็น blocking gate เต็มเสมอ**
    - มี error / test แดง → **แก้จนเขียวหมด (loop)** อาจ delegate fix ให้ sub-agent ทีละจุด แล้ว rerun ใหม่
    - **ห้ามปิด BUILD ถ้ายังมี build error หรือ test ตัวใดแดง**
    - ถ้าวนแก้หลายรอบยังไม่ผ่าน → หยุด รายงาน user พร้อม log error

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

@@ -32,7 +32,11 @@
 
 1. **ห้ามเดาเอง** — จุดที่ไม่มั่นใจ ให้ **ถามทีละข้อ + เสนอคำตอบที่แนะนำ (recommended answer) ทุกข้อ** (เหมือน Discovery) คำถามที่ตอบได้ด้วยโค้ด/เอกสาร → ไปอ่านเอง
 2. **Vertical slice architecture** — ออกแบบและแตก task เป็น "slice ที่ตัดผ่านทุก layer" (UI → API → domain → data → test) ทำงาน end-to-end ได้ในตัว **ไม่แบ่งตาม layer แนวนอน**
-3. **task = หน่วยที่โยนให้ sub-agent ได้** — แต่ละ task self-contained (มี spec + standard + rule ของตัวเอง) แต่ **เชื่อมต่อกัน** ผ่าน dependency/ลำดับที่ระบุชัด
+   - **DAG-width toolkit (เทคนิคเสริม optional ลด serialization)** — คงนิยาม vertical slice เดิม (slice ตัดทุก layer end-to-end); toolkit เป็นเทคนิคเสริม เลือกตามเคส ไม่ใช่ข้อบังคับ — ใช้เมื่อแตก slice แล้วได้ dependency chain ลึก:
+     1. **Contract-first decouple** — เมื่อ task B ต้องการแค่ **interface/contract** ของ A (ไม่ใช่ runtime จริง) → ให้ B พึ่ง **contract artifact** (type/schema/openapi/ไฟล์กลางที่ตกลงใน design) แทน → A‖B ขนาน; integration พิสูจน์ที่ **full-gate** (`build.md` §3 ข้อ 8) — slice ยัง end-to-end แค่ stub ฝั่ง dependency ชั่วคราว
+     2. **Re-slice ต่างแกน** — ถ้าแตกตาม component-layer แล้วได้ chain → ลองแตกตาม **feature/capability ที่ independent** แทน
+     3. **ยอม serialize เฉพาะ chain แท้** — dependency ที่เลี่ยงไม่ได้ (foundation ต้องก่อน / doc ต้องอ้าง code) → ยอมรับ แล้วโฟกัส **ลดเวลา node บน critical path** (model tier + task-lean)
+3. **task = หน่วยที่โยนให้ sub-agent ได้** — แต่ละ task self-contained (มี spec + standard + rule ของตัวเอง) **กระชับพอ agent ทำจบ ไม่ฟุ่มเฟือย** (brief ยาวผิดปกติ → recheck dependency/re-slice) แต่ **เชื่อมต่อกัน** ผ่าน dependency/ลำดับที่ระบุชัด — เมื่อแตก task ต้อง **วาด DAG แล้ววัด critical-path depth (longest chain) + max wave width**: ถ้า DAG เป็น chain เส้นตรง (ทุก wave มี 1 task) ต้องมี **เหตุผล explicit** ว่าทำไม decouple ด้วย toolkit ข้อ 2 (3 เทคนิค) ไม่ได้ (กัน chain เผลอ)
 4. **สอดคล้องมาตรฐานเสมอ** — อิง rule + standard ของ techstack; ถ้าจะเพิ่ม rule/standard ใหม่ ให้ **note ไว้ก่อน** (ยังไม่แก้ไฟล์กลาง — รอ SHIP)
 5. **Gate ก่อนเขียนไฟล์ task จริง** — ต้องผ่านเกณฑ์ข้อ 8 ก่อนจะ generate ไฟล์ task และก่อนโยนให้ sub-agent
 6. **ใช้ role lens** — ออกแบบ (design.md) ด้วยมุม **SA** (`.warnyin/workflow/roles/sa.md`) และแตก/ตรวจ task ด้วยมุม **Tech Lead** (`.warnyin/workflow/roles/tech-lead.md`)
@@ -54,7 +58,7 @@
    3. **blocker → แก้ design ให้ครบ** โดยห้ามเดา — ติดจริงถาม user ทีละข้อ + เสนอคำตอบแนะนำ; suggestion → พิจารณา/บันทึกเหตุผลถ้าไม่ทำ
    4. บันทึกสรุปผล panel + สิ่งที่แก้ ลงท้าย `design.md` (section "Design review")
    5. เครื่องที่ fan-out ไม่ได้ → รีวิวทีละ role ด้วย checklist เดียวกัน
-7. **แตก tasks:** แปลง design เป็น task (= vertical slice / step ที่แก้); task ซับซ้อน → แตก **sub-task** ย่อย; เขียน **dependency graph / ลำดับ** ให้ sub-task เชื่อมกัน
+7. **แตก tasks:** แปลง design เป็น task (= vertical slice / step ที่แก้); task ซับซ้อน → แตก **sub-task** ย่อย; **วาด DAG** + ระบุ **critical-path depth (longest chain) + max wave width + เหตุผลถ้า task ใดถูก serialize** — ถ้าได้ chain ลึก ลอง DAG-width toolkit (§3 ข้อ 2) ก่อนยอม serialize; เขียน **dependency graph / ลำดับ** ให้ sub-task เชื่อมกัน
 8. **rule check ต่อ task:** เปิด `docs/techstack/<component>/rule.md` หา rule ที่ task นี้ต้องโฟกัส → ใส่ใน `tasks/<task>/rule.md`; rule ใหม่ที่อยากเพิ่ม → note ใน section "เสนอเพิ่ม (รอ SHIP)"
 9. **เช็ค Gate (ข้อ 8)** → เมื่อผ่าน จึง **เขียนไฟล์ task ครบทุกใบ** (แตก task ด้วย lens `.warnyin/workflow/roles/tech-lead.md`)
 10. **Dry-run (optional — ถาม user ก่อน):** ถาม user ว่าต้องการ dry-run ทั้งหมดเพื่อหาจุดบกพร่องก่อนเข้า BUILD ไหม — ถ้า ok:
@@ -99,10 +103,15 @@
 - **persona** — ทำเพื่อใคร
 - **test-flow** — จะทดสอบ/ยืนยันความถูกต้องยังไง
 
-## 7. ปรับความละเอียดตามขนาด change
+## 7. ปรับความละเอียดตามขนาด change (3-tier)
 
-- **เล็ก** (fix bug นิดหน่อย): ข้าม `business.md`, `proposal.md`/`design.md` แบบสั้น, 1 task ก็พอ
-- **กลาง/ใหญ่**: ครบทุก artifact, แตก vertical slice หลาย task + sub-task, dependency ชัด
+ปรับ ceremony ตาม **tier** ที่ `/warnyin:triage` ประเมิน (`.warnyin/workflow/triage.md`) — fast/standard/large:
+
+- **fast** (bugfix, typo, config tweak, wording-guidance สั้น, 1-2 ไฟล์ modify ของเดิม ไม่ cross-cutting): **fast-track** — ข้าม `business.md`, proposal/design สั้น, **ไม่ panel ไม่ dry-run**, 1 task; ทำตาม [fast-track skip-list](../triage.md#fast-track-skip-list) (canonical ใน `triage.md` — ไม่ลอก rubric มาที่นี่). **คง correctness floor:** spec/acceptance ขั้นต่ำของ task ยังต้องครบ
+- **standard** (feature ปกติ, modify หลายไฟล์/หลาย component, มี logic ใหม่): flow เต็ม — ครบทุก artifact, แตก vertical slice หลาย task + sub-task, dependency ชัด, panel/dry-run ตามเหมาะ
+- **large** (greenfield/project ใหม่, cross-cutting หลาย component, mega): **บังคับ `/warnyin:discovery` ก่อน** แล้วค่อยกลับมา DESIGN → decompose เต็ม
+
+> hard-floor (auth/migration/secret/public-API/security-sensitive) บังคับ ≥ standard เสมอ — ดู [triage rubric](../triage.md#fast-track-skip-list) (`triage.md` §3B); fast-track ลดเฉพาะ ceremony ไม่ลด correctness — Gate §8 ของ standard/large คงเดิม
 
 ---
 
@@ -114,7 +123,7 @@
 - [ ] **Spec delta ครบ** — เทียบ `docs/features/<name>/spec.md` ของ feature ที่แตะ (ADDED/MODIFIED/REMOVED) หรือระบุ "ไม่มี delta"
 - [ ] **API contract (ถ้าแตะ REST API)** — topic ที่ auto-detect ว่าแตะ backend/REST API มี `openapi.yaml` (OpenAPI 3.1) ครบ + `spec.md` ของ API task ชี้มาที่ contract (ตาม `.warnyin/workflow/api-doc.md`); ไม่ใช่ REST API → ข้อนี้ N/A
 - [ ] ทุก task มี `spec.md` + `standard.md` + `rule.md` + `task.md` ครบ (ถ้ารัน node ได้: `node .warnyin/workflow/scripts/validate-topic.mjs <slug>` ควรไม่มี ✖ — เช็คโครง ไม่แทนการอ่าน semantic)
-- [ ] dependency / ลำดับระหว่าง task และ sub-task ชัดเจน เชื่อมต่อกัน
+- [ ] dependency / ลำดับระหว่าง task และ sub-task ชัดเจน เชื่อมต่อกัน — **critical-path gate (judgment, ไม่ใช่ mechanical check):** ระบุ critical-path depth + max wave width; ถ้า DAG เป็น chain เส้นตรง (ทุก wave มี 1 task) → ต้องมี **เหตุผล explicit** ว่าทำไม decouple ด้วย DAG-width toolkit (§3 ข้อ 2) ไม่ได้ (กัน chain เผลอ)
 - [ ] rule ที่ต้อง follow ถูกระบุครบ; rule/standard ใหม่ที่อยากเพิ่มถูก note ไว้ (รอ SHIP)
 - [ ] ถ้าทำ review panel: **blocker จากทุก role ถูกแก้/ปิดครบ** — สรุปผลบันทึกใน `design.md` section "Design review"
 - [ ] ถ้าทำ dry-run: **ไม่มี blocker ค้าง** — ทุก issue ถูกแก้/ปิดใน `issue.md`, defer ที่เหลือ user รับทราบแล้ว

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

@@ -14,6 +14,8 @@
 
 > SHIP เป็นเรื่อง **เอกสาร + archive เท่านั้น** — การ merge โค้ด (build branch → main / PR) จัดการเองนอก workflow
 
+> **★ fast-track hook:** ถ้า topic เป็น tier `fast` (จาก `/warnyin:triage`) → **ship-lite** ตาม [fast-track skip-list](../triage.md#fast-track-skip-list) — promote เฉพาะที่มี (อาจไม่มี learned-rule), archive ครบ; **correctness floor คงไว้ — archive ครบ + ไม่แตะ rule กลางมั่ว**. tier `standard`/`large` → flow เต็มด้านล่าง (hook นี้ N/A ไม่ลด bar)
+
 ---
 
 ## 2. Input ที่ต้องอ่านก่อนเริ่ม

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

@@ -11,6 +11,8 @@
 ใช้หลัง BUILD ผ่าน Gate (full build/test เขียว) — VERIFY ทดสอบ **เชิงพฤติกรรม/จุดประสงค์** ในสภาพแวดล้อมจริง (local env)
 ไม่ใช่แค่ unit test ผ่าน แต่ "ของจริงทำงานตามที่ topic ตั้งใจไหม"
 
+> **★ fast-track hook:** ถ้า topic เป็น tier `fast` (จาก `/warnyin:triage`) → **verify-lite** ตาม [fast-track skip-list](../triage.md#fast-track-skip-list) — functional ตาม spec + test เขียว, ข้าม empirical/panel ที่ไม่เกี่ยว; **correctness floor คงไว้ — test ต้องเขียวจริง**. tier `standard`/`large` → flow เต็มด้านล่าง (hook นี้ N/A ไม่ลด bar)
+
 ---
 
 ## 2. ก่อนเทส — อ่านให้เข้าใจก่อนเสมอ

package/src/.warnyin/workflow/triage.md

@@ -0,0 +1,74 @@
+# TRIAGE — ประเมินขนาด change → แนะนำ tier + route (read-only)
+
+> **Playbook กลาง — AI ทุกเจ้าทำตามไฟล์นี้ชุดเดียวกัน** (Claude Code / Codex / Antigravity / อื่นๆ)
+> เป้าหมาย: รับคำอธิบาย change ของ user → ประเมินขนาดเป็น tier `{fast, standard, large}` ตาม rubric (signals + hard-floor) → **แนะนำ route** แล้วหยุด — **ไม่สร้างหรือแก้ไฟล์ใดๆ**
+> ★ ไฟล์นี้ **canonical** ของ rubric — `design.md §7` / `verify.md` / `ship.md` / command adapter ชี้มาที่นี่ (ไม่ inline rubric ซ้ำ)
+
+---
+
+## 1. TRIAGE คืออะไร / ใช้เมื่อไหร่
+
+TRIAGE คือโหมด **อ่านอย่างเดียว (read-only)** — ไม่ใช่ stage ใน workflow, ไม่มี gate, ไม่มี output ไฟล์
+ใช้เมื่อ: มี change/request ใหม่แต่ **ยังไม่แน่ใจว่าควรจ่าย ceremony แค่ไหน** — อยากรู้ว่างานนี้ใหญ่แค่ไหน ควรเดิน path ไหน (fast-track / flow เต็ม / ต้อง Discovery ก่อน)
+
+- **ต่างจาก `next`:** triage = ประเมิน **request ใหม่ by size** ; next = route **topic เดิม by stage** — คนละแกน input
+- **ต่างจาก `explore`:** explore ตอบคำถาม/สำรวจ ; triage ตัดสิน tier + route ของ change ที่จะลงมือทำ
+
+---
+
+## 2. วิธีประเมิน (rubric — สแกน → ตัดสิน tier เคารพ hard-floor)
+
+### 2A. Tier taxonomy (3 ระดับ 1 มิติ)
+
+| tier | ตัวอย่าง | route ที่แนะนำ |
+|---|---|---|
+| **fast** | bugfix, typo, config tweak, แก้/เพิ่ม wording-guidance สั้น, 1-2 ไฟล์, modify ของเดิม ไม่ cross-cutting | `/warnyin:design` แบบ **fast-track** (skip-list §2C) → build → verify-lite → ship-lite |
+| **standard** | feature ใหม่ขนาดปกติ, modify หลายไฟล์/หลาย component, มี logic ใหม่ | flow เต็มปัจจุบัน (`design` → build → verify → ship) |
+| **large** | greenfield/project ใหม่, cross-cutting หลาย component, mega | **บังคับ `/warnyin:discovery` ก่อน** → design → ... (decompose เต็ม = future) |
+
+### 2B. Signals + Hard-floor + Escalation (judgment heuristic ⚠ ไม่ใช่ ✖)
+
+- **signals ประเมิน tier:** #ไฟล์/#component ที่แตะ · new-vs-modify · greenfield · มี logic/algorithm ใหม่ · dep ใหม่ · UI/ผู้ใช้กระทบ
+- **★ tie-break ก้ำกึ่ง → ปัดขึ้น (fail-safe):** signals เป็น judgment ไม่มี threshold ตายตัว — เคสก้ำกึ่ง fast/standard → **เลือก standard** (ปรัชญาเดียวกับ hard-floor: ระวังไว้ก่อน) เพื่อให้พฤติกรรมก้ำกึ่ง consistent ไม่สุ่ม
+- **★ Hard-floor — บังคับ ≥ standard เสมอ (ไม่ว่าดูเล็กแค่ไหน):** แตะ **(1) auth/authz · (2) data migration/schema · (3) secret/credential · (4) public API/contract (breaking) · (5) security-sensitive (input handling/crypto/permission)** → triage ห้ามแนะนำ fast (**5 หมวด**)
+- **★ Escalation/Downgrade เป็น step (symmetric):**
+  1. **Upgrade (fast→standard/large):** พบว่าใหญ่กว่า/แตะ hard-floor กลางทาง → **เติม artifact ที่ fast-track ข้ามไป** (business.md/proposal-design เต็ม/panel/dry-run/แตก task เพิ่ม) แล้วเดิน flow tier ใหม่ต่อ — topic ไม่ต้องเริ่มใหม่
+  2. **Downgrade (standard→fast):** ถ้าประเมินเกิน (over-size) → ตัด ceremony ที่ยังไม่ทำได้ แต่ **ห้าม downgrade ข้าม hard-floor**
+  3. sizing เป็น **default ที่ปรับได้ทุกเมื่อ ไม่ lock**
+
+> **fast-track skip-list** = ดู section **Fast-track skip-list** ด้านล่าง (§2C canonical)
+
+---
+
+## Fast-track skip-list
+
+> fast tier = **ข้าม ceremony ที่ไม่จำเป็น ไม่ใช่ข้าม correctness** (canonical §2C — `design.md §7` / `verify.md` / `ship.md` ชี้ anchor นี้)
+
+| stage | fast-track ทำ | คงไว้ (correctness floor) |
+|---|---|---|
+| DESIGN | ข้าม `business.md`, proposal/design สั้น, **ไม่ panel ไม่ dry-run**, 1 task, model tier `cheap` | spec/acceptance ขั้นต่ำของ task |
+| BUILD | 1 agent (DAG width 1, ไม่ต้อง fan-out) | **full-gate (test เขียว) ยัง blocking** |
+| VERIFY | lite — functional ตาม spec + test เขียว, ข้าม empirical/panel ที่ไม่เกี่ยว | test เขียวจริง |
+| SHIP | lite — promote เฉพาะที่มี (อาจไม่มี learned-rule), archive | archive ครบ + ไม่แตะ rule กลางมั่ว |
+
+---
+
+## 3. รูปแบบรายงาน (ตอบในแชทเท่านั้น)
+
+triage **อ่าน input = คำอธิบาย change ของ user** (+ inspect โค้ดที่อ้างถึงได้) → ประเมิน tier ตาม §2A/§2B → **รายงาน: tier + เหตุผล (signals ที่เจอ) + route ที่แนะนำ + คำเตือน hard-floor (ถ้ามี)** → **หยุด ให้ user สั่ง command เอง** (ไม่รัน stage ต่อ — เหมือน `next`)
+
+รูปแบบที่แนะนำ:
+1. **tier ที่ประเมิน** (`fast` / `standard` / `large`)
+2. **เหตุผล** — signals ที่เจอ (#ไฟล์/component, new-vs-modify, logic ใหม่, ฯลฯ) + ถ้าก้ำกึ่งระบุว่าปัดขึ้น standard
+3. **คำเตือน hard-floor (ถ้ามี)** — ระบุหมวดที่ตรง → บังคับ ≥ standard
+4. **route ที่แนะนำ** — command ถัดไป (fast-track / flow เต็ม / Discovery ก่อน)
+5. **หยุด** — เสนอ command ให้ user เป็นคนสั่ง
+
+---
+
+## 4. หลักการ (read-only เด็ดขาด)
+
+1. **Read-only เด็ดขาด** — ห้ามสร้าง/แก้/ลบไฟล์ใดๆ; triage แค่ประเมินแล้วรายงาน
+2. **สรุปจาก evidence:** ประเมินจากคำอธิบาย change + โค้ดที่อ้างถึงจริง ไม่เดา; ก้ำกึ่ง → ปัดขึ้น standard (fail-safe)
+3. **เคารพ hard-floor:** แตะหมวดใน §2B → ห้ามแนะนำ fast ไม่ว่าดูเล็กแค่ไหน
+4. **แนะนำแล้วหยุด:** ไม่รัน stage ถัดไปให้เอง — เสนอ command ให้ user เป็นคนสั่ง; sizing เป็น default ที่ escalate/downgrade ได้ทุกเมื่อ (ไม่ lock)