สถานะ: 🟢 Complete — อัพเดท: 2026-07-11 (v2 — Fable5 Workflow ฉบับปรับปรุง)

AI-Assisted Software Development Workflow v2

v2 คืออะไร

พัฒนาต่อจาก v1 — โครง 5 phases เดิม + feedback loop เดิม สิ่งที่เพิ่มมา: Lane Triage, Evidence Rule, Circuit Breaker, Verify Gate, Incident Severity และอื่นๆ ดูสรุปการเปลี่ยนแปลงทั้งหมดได้ที่ Changelog ท้ายหน้า

Philosophy

จุดประสงค์ของ workflow นี้ไม่ใช่แค่การใช้ AI Skills แต่คือการลดต้นทุนการพัฒนาโดยเจอปัญหาให้เร็วที่สุด (Shift Left)

แต่ละ phase มีหน้าที่เดียวเท่านั้น — phase หนึ่งต้องไม่ทำงานของ phase อื่น

หลักการใหม่ใน v2 — Proportional Ceremony: ความหนักของ process ต้องสมดุลกับความเสี่ยงของงาน การรัน workflow เต็ม 5 phases กับงานแก้ typo ไม่ได้ลดความเสี่ยง — มันสอนให้คุณข้าม workflow ไปเลย Workflow จะอยู่รอดก็ต่อเมื่อเส้นทางที่ถูกที่สุดคือเส้นทางที่ถูกต้องด้วย

Scope

ครอบคลุม:

พัฒนา feature ใหม่
แก้ bug (ผ่าน Incident Workflow)
งานเล็กๆ (ผ่าน Lane Triage — ใหม่ใน v2)

ไม่ครอบคลุม:

Refactoring
งานเป็นทีม (สำหรับ solo developer + AI เท่านั้น)

Step 0 — Lane Triage (ใหม่)

ก่อนเข้า phase ไหนก็ตาม ให้จัดงานเข้า lane ก่อน ใช้เวลา 30 วินาที ห้ามข้าม — การข้าม triage คือสาเหตุที่ “งานเล็กๆ” กลายเป็น production incident

Risk Score

ตอบ 3 คำถาม:

คำถาม	0 คะแนน	1 คะแนน	2 คะแนน
Blast radius — ถ้าพังจะกระทบอะไร?	จุดเดียว, cosmetic	Feature เดียว	หลาย features / data / ระบบอื่น
Reversibility — ย้อนกลับยากแค่ไหน?	`git revert` จบ	Revert + เก็บกวาด	Migration, data เปลี่ยน, API เผยแพร่แล้ว, เงินโอนแล้ว
Sensitive surface — แตะเงิน, auth, security, user data ไหม?	ไม่	ทางอ้อม	โดยตรง

Lanes

คะแนน	Lane	เส้นทาง
0–1	🟢 Quick	เขียน → verify → self-review diff → commit ไม่ต้องมี PLAN.md ไม่ต้อง design review
2–3	🟡 Standard	Phase 3 → 4 → 5 (ข้าม Discovery/Design ได้เฉพาะเมื่อ requirements กับ design ชัดเจนอยู่แล้วจริงๆ)
4–6	🔴 Full	ครบทุก phase ไม่มีข้อยกเว้น

กติกา

ลังเลเมื่อไหร่ ขึ้น lane ที่สูงกว่า — triage ผิดควรจ่ายด้วย ceremony ไม่ใช่จ่ายด้วย incident
Escalation เป็นข้อบังคับ: ถ้างาน Quick เจอ schema change, คำถาม business rule, หรืออะไรที่ sensitive ระหว่างทำ — หยุด re-triage เข้า lane ที่ถูกต้อง ห้ามทำต่อเพราะ “ไหนๆ ก็เข้ามาแล้ว”
AI ต้องประกาศ lane และคะแนนตอนเริ่มงาน: Lane: Standard (blast 1, revert 1, sensitive 0) — ทำให้ triage ตรวจสอบได้และบังคับให้คำถามถูกถามจริงๆ

flowchart TD
    T0{{"Step 0 — Lane Triage<br/>blast radius + reversibility + sensitivity"}}
    T0 -->|"🟢 Quick (0–1)"| Q["Implement → Verify → Self-review diff → Commit"]
    T0 -->|"🟡 Standard (2–3)"| P3S["Phase 3 → 4 → 5"]
    T0 -->|"🔴 Full (4–6)"| P1S["Phase 1 → 2 → 3 → 4 → 5"]
    Q -->|"scope โตระหว่างทำ"| T0

Starting Point (Full lane)

สถานการณ์	Phase 1 Tool
โปรเจคใหม่ — ยังไม่มี CONTEXT.md	`grill-me` → สร้าง CONTEXT.md จากศูนย์
โปรเจคเดิม — มี CONTEXT.md แล้ว	`grill-with-docs` → cross-check กับ domain เดิม

Overall Workflow

flowchart TD
    T0{{"Step 0 — Lane Triage"}}
    T0 -->|Full| START{{"CONTEXT.md?"}}
    T0 -->|Standard| P3
    T0 -->|Quick| QL["Quick lane: implement → verify → commit"]

    START -->|"ไม่มี"| GRILL["grill-me"]
    START -->|"มี"| GRILLDOCS["grill-with-docs"]
    GRILL --> P1
    GRILLDOCS --> P1

    P1["🔍 Phase 1 — Discovery"]
    P2["📐 Phase 2 — Design Review<br/>plan mode → scrutinize (สูงสุด 2 รอบ)"]
    P3["📋 Phase 3 — Implementation Planning<br/>PLAN.md แบบ living checklist"]
    P4["⚙️ Phase 4 — Implementation<br/>+ verify gate + circuit breaker"]
    P5["✅ Phase 5 — Validation<br/>machine gate → code-review → scrutinize?"]

    P1 --> P2 --> P3 --> P4 --> P5

    P5 -->|PASS| MERGE["🚀 Merge / Release"]
    MERGE --> SMOKE["🔎 Post-release smoke check"]

    P5 -->|"FAIL: Coding"| P4
    P5 -->|"FAIL: Planning"| P3
    P5 -->|"FAIL: Design"| P2
    P5 -->|"FAIL: Requirement"| P1

กฎข้ามทุก Phase (ใหม่)

กฎเหล่านี้ใช้ทุก phase มีเพราะเพื่อนร่วมงานคือ AI — และ failure modes ของ AI เป็นระบบ ไม่ใช่สุ่ม

1. Evidence Rule

ทุก claim ที่ AI พูดเกี่ยวกับโค้ดที่มีอยู่แล้วต้องอ้าง file:line ทุก claim เกี่ยวกับ library API ต้องตรวจกับเวอร์ชันที่ติดตั้งจริง (อ่าน types ใน node_modules, อ่าน docs, หรือรันดู) — ไม่ใช่จำมาจากความจำ

“ผมเชื่อว่า” / “ปกติแล้ว” / “น่าจะเป็น” เกี่ยวกับ codebase ปัจจุบัน = ไม่ใช่หลักฐาน ไปอ่านโค้ดจริง

นี่คือปราการหลักป้องกัน hallucinated API และคำตอบผิดที่พูดอย่างมั่นใจ

2. Circuit Breaker

ถ้างานเดียวกันล้มเหลวสองครั้ง (test ไม่ผ่านซ้ำ, fix ไม่ fix, AI เสนอวิธีเดิมที่พังแล้วอีกรอบ):

หยุด ห้ามลองรอบสาม

ความล้มเหลวซ้ำแปลว่าปัญหาอยู่ต้นน้ำ — plan ผิด, design ผิด, หรือเข้าใจผิด ให้ classify ใหม่ (phase ไหนเป็นเจ้าของปัญหานี้?) แล้วกลับไปที่นั่น การวนแก้ใน Phase 4 คือวิธีเผาชั่วโมงที่พบบ่อยที่สุดในการทำงานกับ AI

3. Context ที่ขอบเขต Phase

เคลียร์ context window ทุกครั้งที่ข้าม phase แต่ละ phase เริ่มใหม่ด้วย artifacts ที่เกี่ยวข้องเท่านั้น:

เข้า Phase	เอาเข้าไปด้วย
Phase 2	CONTEXT.md, ADRs
Phase 3	CONTEXT.md, design doc ที่อนุมัติแล้ว
Phase 4	CONTEXT.md, PLAN.md
Phase 5	CONTEXT.md, PLAN.md, diff / ไฟล์ที่แก้

ก่อนเคลียร์ context ต้องบันทึกก่อน: domain knowledge ใหม่ → CONTEXT.md; decision ที่ผ่าน ADR test → ADR; ความคืบหน้า → PLAN.md checkboxes ถ้าไม่ได้เขียนลง artifact = ไม่รอดข้ามขอบเขต — “AI จำได้” ไม่ใช่แผนที่ใช้ได้

Phase 1 — Discovery

Tool

grill-with-docs   (grill-me ถ้ายังไม่มี CONTEXT.md)

เป้าหมาย

เข้าใจปัญหาให้ครบก่อนคุยเรื่อง implementation — AI ควรค้นหา business problem ไม่ใช่รีบออกแบบ solution

หน้าที่

เคลียร์ requirements
ค้นหา business rules
สำรวจ edge cases
สร้างภาษากลาง (shared language)
อัพเดท CONTEXT.md — assumption ที่ยังไม่ยืนยันให้ flag เป็น unverified ชัดๆ
เขียน ADR เมื่อจำเป็น — ใช้ test นี้:

“Developer ในอนาคตมีเหตุผลที่จะเลือกต่างจากนี้ไหม และถ้าเลือกต่างแล้วย้อนกลับเจ็บจริงไหม?” ถ้า YES → เขียน ADR ถ้า NO → ข้าม

Exit Criteria

Requirements ชัดเจน
ไม่มีคำถาม business ค้าง หรือ คำถามที่ตอบไม่ได้ถูกบันทึกใน CONTEXT.md เป็น assumption ที่ flag ว่า unverified
มีภาษากลางแล้ว

ทำไม?

ความผิดพลาดระดับ requirement คือความผิดพลาดที่แพงที่สุดถ้าเจอช้า แก้ requirements ก่อนเขียนโค้ดถูกกว่า rewrite ทีหลังมหาศาล

Phase 2 — Design Review

Tool

Step 1: plan mode   → เสนอ architecture / design
Step 2: scrutinize  → โจมตี design ที่เสนอ (สูงสุด 2 รอบ)

เป้าหมาย

โจมตี design ที่เสนอมา — phase นี้ review architecture ไม่ใช่โค้ด

หน้าที่

Step 1 — plan mode ผลิต: architecture proposal, database schema, API design, key design decisions

Step 2 — scrutinize ท้าทาย: architecture, database design, API design, security, scalability, performance, concurrency, edge cases

Bounded Review (ใหม่)

Scrutinize รันสูงสุด 2 รอบ — AI reviewer แบบ adversarial สร้างข้อโต้แย้งได้ไม่รู้จบ scrutiny ที่ไม่มีขอบเขตคือการผัดวันประกันพรุ่งที่ใส่เสื้อ safety

หลังรอบ 2 แต่ละ concern ที่เหลือ developer ตัดสิน: ยอมรับความเสี่ยง (บันทึกหนึ่งบรรทัดใน design doc: concern + เหตุผลที่ยอมรับ) หรือ เปลี่ยน design ถ้า decision ผ่าน ADR test ให้เขียน ADR แล้วออกจาก phase

Exit Criteria

ไม่มี major architectural concern ที่ยังไม่ถูกจัดการ (fix แล้ว หรือยอมรับพร้อมเหตุผลเป็นลายลักษณ์อักษร)

Major = concern ที่แก้ด้วยการเปลี่ยนโค้ดอย่างเดียวไม่ได้:

Schema changes, API contract changes, security architecture changes, race conditions, missing constraints

ไม่ major (แก้ใน Phase 4):

Performance tuning, code style, naming, index optimization

ทำไม?

Requirements ถูกไม่ได้แปลว่า design ดี

Requirement: recurring payments Design แย่: รัน cron ทุกนาที Design ดีกว่า: dedicated scheduler Requirements เหมือนเดิม เปลี่ยนแค่ design

Phase 3 — Implementation Planning

Tool

karpathy-guidelines

เป้าหมาย

คิดก่อนเขียน — แปลง design ที่อนุมัติแล้วเป็น implementation plan

หน้าที่

ผลิต PLAN.md แบบ living checklist (ใหม่ — ดู format ด้านล่าง):

Task breakdown — แต่ละ task เป็น checkbox เรียงลำดับ หนึ่ง commit ต่อหนึ่ง task
รายการไฟล์ที่จะแก้
Migration strategy
Rollback strategy
Testing strategy
Verification plan (ใหม่): เราจะเห็น feature นี้ทำงานจริง end-to-end ใน Phase 4 ได้ยังไง? ตัดสินใจตอนนี้ ไม่ใช่หลังเขียนโค้ดเสร็จ

PLAN.md Format (ใหม่)

# PLAN — <feature>
Status: IN PROGRESS | lane: Full | design doc: <link>
 
## Tasks
- [x] 1. Add schema migration (files: db/migrations/...) — commit abc123
- [x] 2. Repository layer (files: src/repo/...) — commit def456
- [ ] 3. API endpoint (files: src/api/...)   ← NEXT
- [ ] 4. Wire UI
## Verification plan
รัน X, คลิก Y, คาดหวัง Z. Edge case: ...
## Rollback
Revert migration NNN; feature อยู่หลัง flag F

PLAN.md เก็บ state สด (checkboxes, commit hashes, marker NEXT) เพื่อให้ context ใหม่คนไหนก็ resume งานกลางทางได้ — session ตาย, context window เต็ม, หมดวัน ไฟล์ plan คือความจำ ไม่ใช่บทสนทนา

Exit Criteria

Developer อนุมัติ plan
ระบุ risks แล้ว
Tasks เรียงลำดับชัดเจน
Verification plan เป็นรูปธรรม (command ที่รันได้ / flow ที่คลิกได้ — ไม่ใช่แค่ “test it”)

Phase 4 — Implementation

Tool

karpathy-guidelines

เป้าหมาย

ทำตาม plan — ห้าม redesign ระหว่างทำ

ถ้าการ implement เผยว่า design ผิด — หยุด กลับ Phase 2 ห้ามตัดสินใจเรื่อง design ใน Phase 4 ห้าม “จดไว้แล้วทำต่อ” ทุก design change ที่ไม่อยู่ในแผนคือปัญหาของ Phase 2

(Circuit Breaker ใช้หนักที่สุดตรงนี้: ล้มเหลว 2 ครั้งกับ task เดิม = ปัญหาอยู่ต้นน้ำ หยุด patch)

หน้าที่

เขียนโค้ด — ติ๊ก checkbox ใน PLAN.md และบันทึก commit hash เมื่อ task เสร็จ
Unit tests:
- เฉพาะ logic ที่ไม่ trivial (branch, loop, parser, เส้นทางเงิน/security)
- Test เล็กๆ หนึ่งตัวที่ fail ถ้า logic พัง
- ไม่ต้อง framework, ไม่ต้อง fixtures, ไม่ต้อง suite ต่อ function
- One-liner ธรรมดาไม่ต้องมี test
Verify Gate (ใหม่): ก่อนออกจาก phase ต้องรัน verification plan จาก PLAN.md — รัน feature จริง end-to-end แล้วเห็นมันทำงาน Tests ผ่านคือเงื่อนไขจำเป็น ไม่ใช่เงื่อนไขพอ — tests พิสูจน์ว่าโค้ดตรงกับ tests การรัน feature พิสูจน์ว่าโค้ดตรงกับความเป็นจริง
Documentation:
- Inline comment เฉพาะจุดที่ WHY ไม่ชัด
- อัพเดท CONTEXT.md ถ้าเจอ domain knowledge ใหม่
- แค่นั้น

Exit Criteria

Feature เสร็จ ทุก task ใน PLAN.md ติ๊กครบ
Tests ผ่าน
Verification plan รันแล้วได้ผลตามคาด — เห็นมันทำงาน ไม่ใช่เดาว่าทำงาน
Documentation อัพเดทแล้ว

ทำไม?

หลักการ Karpathy ใช้ตลอดการ implement: เข้าใจก่อน, คิดก่อน, แก้น้อยที่สุด, verify ทุกอย่าง, ห้ามเดา

Phase 5 — Validation

Tool

Step 0: machine gate               → อัตโนมัติ ต้องเขียวก่อน (ใหม่)
Step 1: code-review                → บังคับ
Step 2: security-review            → ตามเงื่อนไข (ใหม่)
Step 3: scrutinize                 → ตามเงื่อนไข

Step 0 — Machine Gate (ใหม่)

Test suite เต็ม, linter, type-check, build — เขียวหมดก่อน review ใดๆ จะเริ่ม Review โค้ดที่ build ไม่ผ่านคือ review ที่เสียเปล่า ให้เครื่องจับปัญหาที่เครื่องจับได้ฟรีๆ

เมื่อไหร่รัน security-review (ใหม่)

Diff แตะ auth, payments, user data, file uploads, หรืออะไรที่ user input วิ่งเข้า database
งานถูก flag Sensitive ตอน triage Step 0

เมื่อไหร่รัน scrutinize

code-review ผ่านแต่ยังรู้สึกไม่ชอบมาพากล
Implementation ซับซ้อนและ design drift เป็นความเสี่ยงจริง
ยังมีคำถามเชิง approach พื้นฐานค้างอยู่

หน้าที่

Review: code quality, test coverage, regression risk, security, maintainability, missing edge cases, ความสอดคล้องกับ design — diff เทียบ PLAN.md: ทุก deviation ต้องมีเหตุผลเป็นลายลักษณ์อักษร ไม่งั้นนับเป็น FAIL

Exit Criteria

Implementation พร้อม production
สกัดความรู้ก่อนลบ (ใหม่): ก่อนลบ PLAN.md ย้ายของที่มีค่าออกก่อน — domain knowledge → CONTEXT.md, เรื่องเซอร์ไพรส์ → Improvement Log แล้วค่อยลบ PLAN.md การลบ plan คือหลักฐานว่าสกัดเสร็จแล้ว

ถ้า Validation Fail

ห้าม restart ทั้ง workflow — classify ปัญหาแล้วกลับไปที่ phase ที่รับผิดชอบ

ประเภทปัญหา	ตัวอย่าง	กลับไป
Coding Issue	ขาด null check, error handling, code smell, ขาด tests	Phase 4
Planning Issue	ขาด migration, ขาด rollback plan, testing strategy แย่	Phase 3
Design Issue	Schema ผิด, API แย่, race condition, security flaw	Phase 2
Requirement Issue	Business rules ผิด, requirement หาย, assumption ผิด	Phase 1

Post-Release Smoke Check (ใหม่)

Merge ไม่ใช่เส้นชัย — feature ทำงานใน environment จริงต่างหากคือเส้นชัย

ภายในไม่กี่นาทีหลัง release: ลองใช้ feature หนึ่งรอบในที่ที่มันรันจริง แล้วชำเลืองดู logs/errors ใช้เวลา 2 นาที — จับ bug ประเภท “worked locally” (env vars, build config, ลำดับ migration) ตอนที่ยัง revert ง่าย แทนที่จะเจออีก 3 features ถัดไป

Incident Workflow (เจอ Bug)

Bug ไม่ใช่ส่วนหนึ่งของ development workflow — มันเดินเส้น Incident Workflow แยกต่างหาก

Severity Triage ก่อน (ใหม่)

Severity	นิยาม	เส้นทาง
Sev1	Production ล่ม, data กำลังพัง, เงินรั่ว, ช่อง security เปิดอยู่	Mitigate ก่อน — rollback / ปิด flag / hotfix เพื่อหยุดเลือดไหล Root cause มาทีหลังเมื่อระบบปลอดภัยแล้ว
Sev2	พังแต่ควบคุมได้	เส้นทางปกติด้านล่าง

กฎ Sev1: mitigation ≠ resolution เมื่อระบบนิ่งแล้ว incident เข้าเส้นทางปกติ — Debug Mantra, root cause, classification, และ fix ที่ engineer จริงๆ Hotfix ซื้อเวลา มันไม่ใช่ fix การข้าม root-cause pass หลัง hotfix คือวิธีที่ Sev1 ตัวเดิมระเบิดซ้ำรอบสอง

flowchart TD
    BUG["🐛 เจอ Bug"]
    SEV{"Severity?"}
    BUG --> SEV
    SEV -->|"Sev1"| MIT["🚨 Mitigate ทันที<br/>rollback / ปิด flag / hotfix"]
    MIT --> DEBUG
    SEV -->|"Sev2"| DEBUG

    DEBUG["Debug Mantra<br/>Reproduce → Trace path → Falsify → Record"]
    ROOT["หา Root Cause"]
    CLASSIFY{"Classify Root Cause"}

    DEBUG --> ROOT --> CLASSIFY

    CLASSIFY -->|"Requirement"| RP1["กลับ Phase 1"]
    CLASSIFY -->|"Design"| RP2["กลับ Phase 2"]
    CLASSIFY -->|"Planning"| RP3["กลับ Phase 3"]
    CLASSIFY -->|"Coding"| RP4["กลับ Phase 4"]

    RP1 & RP2 & RP3 & RP4 --> P5["Phase 5 — scope เฉพาะ fix"]
    P5 --> MERGE["🚀 Merge / Release"]
    MERGE --> IMPROVE["📈 บันทึก Improvement Log<br/>(บังคับ — ปิด incident)"]

Debug Mantra

Tool

debug-mantra

เป้าหมาย: หา Root Cause ไม่ใช่หา Fix

Reproduce ให้ได้เสถียร
รู้จัก fail path
Falsify สมมติฐาน
บันทึกทุกการทดลอง

หา root cause เจอแล้วเท่านั้นถึงค่อยลงมือ fix

Continuous Improvement

ทุก bug ควรทำให้ workflow ดีขึ้น อย่าหยุดที่:

“จะ fix bug นี้ยังไง?”

ต้องถามต่อ:

“ทำไม workflow ของเราไม่จับมัน?”

ตัวอย่าง:

เจอ race condition → Validation ขาด concurrency testing → เพิ่ม concurrency checklist
เข้าใจ requirement ผิด → Discovery ถามไม่ครบ → ปรับ prompts ของ grill-with-docs
Migration พัง → Planning ขาด rollback strategy → อัพเดท planning template

Improvement Log

กติกาสั้นๆ: developer เขียน log entry ก่อนปิด incident (เป็นส่วนหนึ่งของ definition of done) เมื่อ improvement ถูกยอมรับ ให้แก้ workflow file / skill prompt / template โดยตรง แล้ว mark row เป็น Applied — workflow file คือ source of truth เดียว

Date	Trigger	Gap ที่พบ	Fix	Status
2026-07-07	v1 review	ไม่มีเส้นทางสำหรับงานเล็ก → ceremony ถูกข้ามแบบมั่วๆ	Step 0 Lane Triage	Applied
2026-07-07	v1 review	Incident workflow ไม่มีกลไก capture	Log นี้	Applied

Guiding Principles

1. Shift Left

เจอปัญหาให้เร็วที่สุด — เจอเร็ว = ถูก

2. Proportional Ceremony (ใหม่)

ความลึกของ process สมดุลกับความเสี่ยงของงาน Quick lane ไม่ใช่การโกง — มันคือ workflow สิ่งที่เป็นการโกงคือการอยู่ Quick lane ต่อทั้งที่งานเผยแล้วว่ามันไม่ควรอยู่

3. Single Responsibility

แต่ละ phase มีหน้าที่เดียว:

Discovery ค้นหา / Design Review วิจารณ์ architecture / Planning วางแผน / Implementation สร้าง / Validation ตรวจ implementation / Debugging หา root cause

CONTEXT.md เป็น living document — phase ไหนก็ตามที่เจอ domain knowledge ใหม่, เปลี่ยน business rule, หรือตอบคำถามค้าง ต้องอัพเดท CONTEXT.md ก่อนออกจาก phase ไม่ใช่แค่ Phase 1

4. Stage Gates

ทุก phase ต้องผ่าน exit criteria ก่อนไปต่อ

เจ้าของ: Developer เป็นคนตัดสินใจออกจาก phase AI ต้องแจ้งทุกประเด็นค้างก่อน developer จะออก AI ห้ามปล่อยให้ phase ปิดเงียบๆ ทั้งที่มีคำถามค้าง

Context: เคลียร์ทุกขอบเขต phase — state รอดได้ผ่าน artifacts เท่านั้น

5. Trust but Verify the AI (ใหม่)

AI คือเพื่อนร่วมงานที่มี failure modes ชัดเจน: hallucinate APIs, เห็นด้วยง่ายเกิน, patch อาการแทนสาเหตุ, และเสียงมั่นใจเท่ากันทั้งตอนถูกและตอนผิด Evidence Rule, Circuit Breaker, Verify Gate, bounded scrutiny ทั้งหมดมีอยู่ด้วยเหตุผลเดียว:

Output ของ AI คือ claim ไม่ใช่ fact — จนกว่าจะ verify กับความเป็นจริง

6. Feedback Loop

Validation กับ Debugging ไม่มีวัน restart ทั้ง process — หาต้นตอจริงแล้วกลับเฉพาะ phase ที่รับผิดชอบ

7. Continuous Improvement

ทุก defect ควรปรับปรุง workflow, checklists, CONTEXT.md, templates, prompts, หรือ AI instructions เป้าหมายไม่ใช่แค่ fix bug วันนี้ แต่คือป้องกัน bug ชนิดเดียวกันไม่ให้เกิดซ้ำ

Changelog จาก v1

#	เปลี่ยนอะไร	ทำไม
1	Step 0 Lane Triage (Quick/Standard/Full ตาม risk score)	ความเสี่ยงจริงที่สุดของ v1: ceremony เต็มทุกงาน → คนข้าม workflow แบบไม่เป็นทางการ → ไม่มี process เลยในวันที่ต้องการมันที่สุด
2	Evidence Rule (อ้าง file:line; verify library API กับเวอร์ชันจริง)	จัดการ AI failure mode อันดับ 1: confident hallucination — v1 พูดว่า “never guess” เป็นค่านิยม อันนี้ทำให้ตรวจสอบได้
3	Circuit Breaker (fail 2 ครั้ง → หยุด, classify ต้นน้ำ)	กัน thrash loop ใน Phase 4 — วิธีเผาชั่วโมงที่พบบ่อยที่สุด
4	Bounded scrutinize (สูงสุด 2 รอบ; risk ที่เหลือยอมรับเป็นลายลักษณ์อักษร)	Adversarial reviewer โต้แย้งได้ไม่รู้จบ — บังคับ accept-or-change แปลงความกังวลเป็นการตัดสินใจ
5	PLAN.md แบบ living checklist	กฎเคลียร์ context ของ v1 สมมติว่า phase จบใน session เดียว — ความจริงไม่ใช่ ไฟล์ plan คือ state ที่ resume ได้
6	Verify Gate ใน Phase 4 + verification plan เขียนตั้งแต่ Phase 3	Tests พิสูจน์ว่าโค้ดตรง tests — การรัน feature เท่านั้นที่พิสูจน์ว่าตรงความเป็นจริง
7	Machine gate + conditional security-review ใน Phase 5	อย่าเสียแรง review กับสิ่งที่ linter จับได้ฟรี; เพิ่ม security pass เมื่อ triage flag บอกว่าจำเป็น
8	สกัดความรู้ก่อนลบ PLAN.md	v1 ลบ plan — ถูกแล้ว — แต่เสี่ยงลบความรู้ไปด้วย extract-then-delete ทำให้การลบคือหลักฐานของการสกัด
9	Incident severity (Sev1 mitigate ก่อน)	Root-cause ตอน production ล่ม = ขยายความเสียหาย mitigate ก่อน แล้วค่อยเดินเส้น root cause เต็ม
10	Post-release smoke check	v1 จบที่ Merge — bug ประเภท “worked locally” จับได้ใน 2 นาทีหลัง deploy หรือไม่ก็อีกหลายชั่วโมงในอีก 3 features ถัดไป

หมายเหตุการปรับจาก Fable5 Workflow ฉบับเต็ม

เวอร์ชันนี้ตัด 3 อย่างจากร่าง v2 ฉบับเต็มออก เพราะเป็น process แบบทีมที่ไม่คุ้มสำหรับ solo dev: Assumption Ledger แบบตาราง ID/status (ใช้การ flag unverified ใน CONTEXT.md แบบ v1 พอ), กติกา Improvement Log แบบ 4 ข้อ (เหลือกติกาบรรทัดเดียว: เขียนก่อนปิด incident), และ Phase Entry Protocol แบบ template (เหลือตาราง artifacts ก็พอ) — ถ้า bug เริ่มซ้ำ class เดิมค่อยพิจารณาเพิ่มกลับ

เกี่ยวข้อง

v1 — เวอร์ชันแรก — เก็บไว้อ้างอิง
Skills — grill, scrutinize, code-review, debug-mantra ที่ใช้ใน workflow นี้
Memory — CONTEXT.md และการจัดการ context ข้าม session

Claude KnowHow

รายการหน้า

AI-Assisted Development Workflow v2 (Fable5)

AI-Assisted Software Development Workflow v2

Philosophy

Scope

Step 0 — Lane Triage (ใหม่)

Risk Score

Lanes

กติกา

Starting Point (Full lane)

Overall Workflow

กฎข้ามทุก Phase (ใหม่)

1. Evidence Rule

2. Circuit Breaker

3. Context ที่ขอบเขต Phase

Phase 1 — Discovery

Tool

เป้าหมาย

หน้าที่

Exit Criteria

ทำไม?

Phase 2 — Design Review

Tool

เป้าหมาย

หน้าที่

Bounded Review (ใหม่)

Exit Criteria

ทำไม?

Phase 3 — Implementation Planning

Tool

เป้าหมาย

หน้าที่

PLAN.md Format (ใหม่)

Exit Criteria

Phase 4 — Implementation

Tool

เป้าหมาย

หน้าที่

Exit Criteria

ทำไม?

Phase 5 — Validation

Tool

Step 0 — Machine Gate (ใหม่)

เมื่อไหร่รัน security-review (ใหม่)

เมื่อไหร่รัน scrutinize

หน้าที่

Exit Criteria

ถ้า Validation Fail

Post-Release Smoke Check (ใหม่)

Incident Workflow (เจอ Bug)

Severity Triage ก่อน (ใหม่)

Debug Mantra

Tool

Continuous Improvement

Improvement Log

Guiding Principles

1. Shift Left

2. Proportional Ceremony (ใหม่)

3. Single Responsibility

4. Stage Gates

5. Trust but Verify the AI (ใหม่)

6. Feedback Loop

7. Continuous Improvement

Changelog จาก v1

เกี่ยวข้อง

มุมมองกราฟ

สารบัญ

หน้าที่กล่าวถึง