diff --git a/sdlc/ISO29110-audit-storytelling.md b/sdlc/ISO29110-audit-storytelling.md
new file mode 100644
index 0000000..ffe04b4
--- /dev/null
+++ b/sdlc/ISO29110-audit-storytelling.md
@@ -0,0 +1,178 @@
+# BRN WMS (200-WMS-26-001-00) — บทเล่าเรื่องสำหรับวันตรวจประเมิน ISO/IEC 29110
+
+เอกสารช่วยจำสำหรับทีม ใช้เล่าเรื่องโครงการต่อผู้ตรวจประเมินตั้งแต่เปิดจนปิดโครงการ ทุกประโยคต้องชี้ไปที่เอกสารจริงได้ทันที
+ถ้าผู้ตรวจถามสิ่งที่ไม่มีในเอกสาร ให้ตอบตามจริงว่า "ไม่ได้บันทึกไว้" ห้ามแต่งเพิ่ม
+
+## วิธีใช้
+
+- เล่าตามลำดับบทที่ 1–8 ใช้เวลารวมประมาณ 25–30 นาที แล้วเปิดให้ผู้ตรวจเลือกเส้นสอบกลับเอง
+- แต่ละบทมี **ผู้เล่า** **เอกสารที่เปิด** และ **ประโยคหลัก** ให้เปิดเอกสารบนจอก่อนพูดทุกครั้ง
+- ผู้เล่า: ApS = Project Manager, NoC = System Analyst, ThS = Developer, PaNg = QA/Tester, YaB = Document Control, SeV = Project Sponsor
+
+## โครงเรื่องในหนึ่งย่อหน้า
+
+โครงการพัฒนาระบบบริหารจัดการคลังสินค้า 11 ระบบงาน ระยะเวลา 232 วัน (5 ม.ค. – 24 ส.ค. 69) ทีม 6 คน
+เราตั้ง Baseline ความต้องการ 80 รายการก่อนเริ่มพัฒนา ควบคุมงานด้วยรายงานความก้าวหน้า 15 งวดและการประชุม 11 ครั้ง
+ตรวจสอบเอกสาร 4 รอบ ทดสอบ 45 Test Case แล้ว **พบข้อบกพร่องระดับสูง 4 รายการ** ซึ่งเราบันทึกตามจริง แจ้งผู้รับมอบ
+และผู้รับมอบตรวจรับแบบมีเงื่อนไขให้แก้ไขภายใต้การบำรุงรักษา — เรื่องนี้คือจุดแข็งของกระบวนการ ไม่ใช่จุดอ่อน
+
+## เส้นเวลา (ใช้เปิดเรื่อง)
+
+| ช่วงเวลา | เหตุการณ์สำคัญ | หลักฐาน |
+|---|---|---|
+| 5 ม.ค. 69 | ประชุมเปิดโครงการ | Statement of Work, Minutes of Meeting 5 ม.ค. |
+| 16–23 ม.ค. 69 | ระบุผู้มีส่วนได้ส่วนเสีย อนุมัติกฎบัตร | Stakeholder Register, Project Charter, MoM 23 ม.ค. |
+| 6–18 ก.พ. 69 | ความต้องการ 80 รายการ แผนโครงการ ตั้ง Baseline | Customer Requirements, Software Project Plan, Work Schedule, MoM 18 ก.พ. |
+| 19 ก.พ. – 29 พ.ค. 69 | ออกแบบและพัฒนา ตั้ง Baseline การพัฒนา 29 พ.ค. (`a0677d6`) | SRS, Software Design, Correction Register ISS-001–027 |
+| 17 มี.ค. / 29 พ.ค. / 31 ก.ค. / 17 ส.ค. 69 | ตรวจสอบเอกสาร 4 รอบ (3+3+3+6 ชม.) | Verification Results V0.1–V1.0 |
+| 31 ก.ค. 69 | Test Case 45 รายการ และ Traceability Record | Test Case and Test Procedures, Traceability Record |
+| 3–10 ส.ค. 69 | แก้ไขหลัง Baseline (ISS-028) และอนุมัติแผนทดสอบ | Correction Register, MoM 10 ส.ค. |
+| 10–14 ส.ค. 69 | ทดสอบระบบและ UAT บน Build `b2c4374` | Test Report, Validation Results |
+| 17 ส.ค. 69 | ชุดติดตั้ง Docker และ Baseline ส่งมอบ `6c39700`; ตรวจสอบรอบที่ 4 | Software Configuration, Verification Results V1.0 |
+| 19 ส.ค. 69 | ประชุมสรุปผลทดสอบและ UAT | MoM 19 ส.ค. |
+| 22–23 ส.ค. 69 | อบรมผู้ใช้ 6 คน ปิดงานควบคุมปฏิบัติการ OP-001/OP-002 | Training Report, Product Operation Guide |
+| 24 ส.ค. 69 | ตรวจรับแบบมีเงื่อนไขและปิดโครงการ | Acceptance Report, MoM 24 ส.ค., List of Evidence |
+
+---
+
+## บทที่ 1 — ทำไมต้องมีโครงการนี้ และใครเกี่ยวข้อง
+
+**ผู้เล่า:** ApS (เปิด) และ SeV (ยืนยันมุมลูกค้า)
+**เปิด:** Statement of Work → Project Charter Report → Stakeholder Register → Software Project Plan §5
+
+**ประโยคหลัก**
+- "บริษัทบันทึกคลังสินค้าแยกจากงานขายและบัญชี ยอดไม่ตรงกัน เราจึงตั้งโครงการรวม 11 ระบบงานไว้ในระบบเดียว ระยะเวลา 232 วัน"
+- "ผู้มีส่วนได้ส่วนเสียมี 10 กลุ่ม คือทีม 6 คน และผู้ใช้ 4 กลุ่ม — ฝ่ายคลัง ฝ่ายขาย/จัดซื้อ ฝ่ายบัญชี และผู้ดูแลระบบ
+  รายชื่อชุดเดียวกันอยู่ทั้งใน Stakeholder Register และ Software Project Plan §5.1–5.2"
+
+**ถ้าถูกถาม:** "ใครอนุมัติขอบเขต?" → SeV อนุมัติกฎบัตรในการประชุม 23 ม.ค. 69
+
+## บทที่ 2 — วางแผนและตั้ง Baseline ก่อนลงมือ
+
+**ผู้เล่า:** NoC (ความต้องการ) และ ApS (แผน)
+**เปิด:** Customer Requirements → Software Project Plan §6–§9 → Work Schedule → MoM 18 ก.พ.
+
+**ประโยคหลัก**
+- "เราเก็บความต้องการ 80 รายการใน 14 หมวด (CR01–CR14) ลูกค้าสรุปผลยอมรับทุกรายการ แล้วตั้ง Baseline ในการประชุม 18 ก.พ. 69 ก่อนเริ่มพัฒนา 19 ก.พ."
+- "แผนกำหนดความเสี่ยง 8 ข้อ (R1–R8) และแผนตรวจสอบ 4 รอบ รวม 15 ชั่วโมง ตามข้อแนะนำให้ตรวจราวทุก 2 เดือน"
+
+**ถ้าถูกถาม:** "ความเสี่ยงไหนเกิดจริง?" → R1 (ความต้องการเปลี่ยนระหว่างพัฒนา) เกิดจริงในเรื่อง Rack → Bin (บทที่ 4)
+และ R4/R5 (ข้อมูลรั่วข้ามบริษัท, ความลับรั่ว) ปรากฏเป็นข้อบกพร่อง ISS-031/ISS-032 ในรอบทดสอบ (บทที่ 6)
+
+## บทที่ 3 — พัฒนาและควบคุมงาน
+
+**ผู้เล่า:** ApS (ติดตามงาน) และ ThS (การพัฒนา)
+**เปิด:** Progress Status Record (เลือก 1 งวด) → Minutes of Meeting ที่แนบ → Correction Register → Software Configuration
+
+**ประโยคหลัก**
+- "เราออกรายงานความก้าวหน้า 15 งวด ทุกฉบับถูกนำเสนอในการประชุมที่มีรายงานการประชุมรองรับ ดูได้จากช่อง 'สิ่งแนบ' ของรายงานการประชุม"
+- "การประชุมแต่ละครั้งจัดในวันทำการ หลังงานที่ทบทวนเสร็จอย่างน้อย 5 วัน เพื่อให้มีเวลาตรวจผลงานก่อนรายงานว่าเสร็จ"
+- "ข้อบกพร่องที่พบระหว่างพัฒนา 28 รายการ (ISS-001–028) ทุกรายการเชื่อมกับ Commit ที่แก้และ Test Case ที่ใช้ตรวจ"
+- "Source Code อยู่บน Branch `main` เท่านั้น สำรองไปยัง Backup Remote ตั้ง Baseline การพัฒนา 29 พ.ค. และ Baseline ส่งมอบ `6c39700`"
+
+**ตัวอย่างที่ควรเปิดให้ดู:** PSR 17 มี.ค. 69 → นำเสนอในการประชุม 23 มี.ค. 69 ซึ่งทบทวนงาน Security & Database (Commit สุดท้าย 17 มี.ค.)
+
+## บทที่ 4 — การควบคุมการเปลี่ยนแปลง
+
+**ผู้เล่า:** ApS
+**เปิด:** Change Report ส่วนที่ 1–3 → MoM 18 พ.ค. → Correction Register ISS-023
+
+**ประโยคหลัก**
+- "เราใช้เกณฑ์ว่า 'ถ้าไม่ทำ ยังส่งมอบได้หรือไม่' ถ้ายังส่งมอบได้ ไม่ถือเป็นคำขอเปลี่ยนแปลง แต่บันทึกการพิจารณาไว้ทุกเรื่อง"
+- "มี 3 เรื่องที่ผ่านการพิจารณา ไม่มีเรื่องใดเข้าเกณฑ์ จึงไม่มีคำขอเปลี่ยนแปลงตลอดโครงการ"
+- "ตัวอย่าง: ที่ประชุม 18 พ.ค. มีมติเปลี่ยนคำว่า Rack เป็น Bin ทั้งระบบ เป็นการเปลี่ยนคำเรียก ไม่เพิ่มฟังก์ชัน ไม่กระทบ Man-day
+  ทีมแก้ใน Commit `8f57ab5` (27 พ.ค.) และพบว่าเปลี่ยนไม่ครบ จึงบันทึก ISS-023 และแก้ใน `5df6736` (28 พ.ค.)"
+
+**ถ้าถูกถาม:** "8 เดือนไม่มี CR เลยหรือ?" → เปิดเกณฑ์ใน Change Report ส่วนที่ 1 แล้วไล่ทั้ง 3 เรื่องด้วยคำถามเดียวกัน
+
+## บทที่ 5 — ตรวจสอบเอกสาร (Verification)
+
+**ผู้เล่า:** PaNg และ YaB
+**เปิด:** Software Project Plan §8.1 → Verification Results V0.1, V0.2, V0.3, V1.0
+
+**ประโยคหลัก**
+- "ตรวจสอบตามแผน 4 รอบ: 17 มี.ค. (แผนและความต้องการ), 29 พ.ค. (SRS และการออกแบบ), 31 ก.ค. (ชุดทดสอบและการสอบกลับ), 17 ส.ค. (ทุกสิ่งส่งมอบ)"
+- "รอบสุดท้ายเราบันทึก **ไม่ผ่าน 2 รายการ** คือผลการทดสอบที่ยังมีข้อบกพร่องคงค้าง และชุดติดตั้ง Docker ที่ยังไม่ได้ทดสอบ แล้วเสนอให้ตรวจรับพร้อมแผนแก้ไข"
+
+## บทที่ 6 — ทดสอบระบบและทดสอบการยอมรับ
+
+**ผู้เล่า:** PaNg (ทดสอบระบบ) และ SeV (UAT)
+**เปิด:** Test Case and Test Procedures → Traceability Record → Test Report → Validation Results → Correction Register ISS-029–032
+
+**ประโยคหลัก**
+- "Test Case 45 รายการ หนึ่งรายการต่อหนึ่ง Software Unit จัดทำพร้อม Traceability Record เมื่อ 31 ก.ค. 69"
+- "ทดสอบ 10–14 ส.ค. 69 บน Build `b2c4374` — ทดสอบได้ 43 รายการ ผ่าน 38 ไม่ผ่าน 5
+  อีก 2 รายการ (ชุดติดตั้ง Docker) ยังไม่ได้ทดสอบ เพราะส่งมอบหลังรอบทดสอบเมื่อ 17 ส.ค."
+- "ข้อบกพร่องที่พบบันทึกเป็น ISS-029–032 ระดับสูงทั้งหมด:
+  ไฟล์แนบเปิดได้จาก URL (ISS-029), การผ่าน GL ไม่อยู่ใน Transaction เดียวกับเอกสาร (ISS-030),
+  Socket.IO ไม่ตรวจ Session (ISS-031), ค่าความลับในแม่แบบค่าตั้งค่า (ISS-032)"
+- "UAT ทำคู่ขนานกับการทดสอบระบบตามมติที่ประชุม 10 ส.ค. ซึ่งต่างจากเกณฑ์เข้าสู่ UAT ในเอกสาร Test Case — เราบันทึกความต่างนี้ไว้ใน Validation Results
+  ผลคือความต้องการ 80 รายการ ผ่าน 60 ไม่ผ่าน 11 ยังไม่ได้ทดสอบ 5 และรอดำเนินการตามแผน 4"
+
+**ถ้าถูกถาม:** "ทำไมไม่แก้ก่อนส่งมอบ?" → ข้อบกพร่องพบในสัปดาห์สุดท้ายของโครงการ เราเลือกบันทึกและแจ้งผู้รับมอบตามจริง
+แทนการแก้เร่งรีบโดยไม่มีรอบทดสอบซ้ำ ผู้รับมอบจึงกำหนดเป็นเงื่อนไขการตรวจรับ (บทที่ 7)
+
+## บทที่ 7 — ส่งมอบ ตรวจรับ และปิดโครงการ
+
+**ผู้เล่า:** SeV (การตัดสินใจตรวจรับ) และ ApS
+**เปิด:** MoM 19 ส.ค. → Training Report → Product Operation Guide (OP-001/OP-002) → Acceptance Report → MoM 24 ส.ค. → List of Evidence
+
+**ประโยคหลัก**
+- "ประชุม 19 ส.ค. สรุปผลทดสอบ ผู้รับมอบรับทราบข้อบกพร่องและขอแผนแก้ไขก่อนตรวจรับ"
+- "อบรมผู้ใช้ 6 คนเมื่อ 22 ส.ค. ปิดงานสำรองข้อมูลอัตโนมัติและการเฝ้าระวังเมื่อ 23 ส.ค."
+- "24 ส.ค. ผู้รับมอบตรวจรับ **แบบมีเงื่อนไข**: (1) แก้ ISS-029–032 และทดสอบซ้ำภายใต้การบำรุงรักษาแบบแก้ไข
+  (2) ทดสอบ TC-UN13.002–003 ก่อนใช้ชุดติดตั้ง Docker ในสภาพแวดล้อมจริง — กำหนดติดตามใน Action Item ของการประชุม 24 ส.ค."
+
+**ต้องเตรียม:** สถานะปัจจุบันของการแก้ไข ISS-029–032 (ผู้ตรวจจะถามแน่นอน) — ตอบตามความคืบหน้าจริง ณ วันตรวจ
+
+## บทที่ 8 — สิ่งที่เราเรียนรู้
+
+**ผู้เล่า:** ApS
+**เปิด:** Correction Register ส่วน Lessons Learned
+
+**ประโยคหลัก**
+- "ข้อบกพร่องทั้ง 32 รายการจัดเป็น 5 กลุ่มสาเหตุ กลุ่มใหญ่ที่สุดคือความปลอดภัยและการควบคุมสิทธิ์ (15 รายการ รวม ISS-029, 031, 032)"
+- "โครงการถัดไปเราจะกำหนด Secure Coding Checklist และรูปแบบการตรวจสิทธิ์กลางตั้งแต่ช่วงออกแบบ
+  และตามข้อแนะนำของที่ปรึกษา จะให้ PM กับ SI เดินผ่านโปรแกรมทั้งระบบพร้อม Document Control ก่อนรอบทดสอบ"
+
+---
+
+## เส้นสอบกลับสำหรับสาธิต (ซ้อมให้คล่อง)
+
+**เส้นที่ผ่าน — สต๊อกต้องไม่ติดลบ**
+
+| ขั้น | รายการ | เอกสาร |
+|---|---|---|
+| ความต้องการ | CR01:008 บันทึกการจ่ายสินค้าออกโดยตรวจสิทธิ์และยอดคงเหลือ | Customer Requirements |
+| ความต้องการซอฟต์แวร์ | SR03:004, SR09:003 | SRS |
+| การออกแบบ | UN04.002 ICS – Stock-out (`StockManager.php`, `OrderManager.php`) | Software Design |
+| ข้อบกพร่องระหว่างพัฒนา | ISS-002 พบ 18 เม.ย. แก้ใน `92d116f` 24 เม.ย. | Correction Register |
+| การทดสอบ | TC-UN04.002 → Passed | Test Case, Test Report |
+| การยอมรับ | CR01:008 → Passed | Validation Results |
+
+**เส้นที่ไม่ผ่าน — ความถูกต้องของ Transaction**
+
+| ขั้น | รายการ | เอกสาร |
+|---|---|---|
+| ความต้องการ | CR13:001 เอกสาร + สต๊อก + GL ต้องเป็น Transaction เดียวกัน | Customer Requirements |
+| ความต้องการซอฟต์แวร์ | SR09:003 | SRS |
+| การออกแบบ | UN08.002 Journal & GL Posting | Software Design |
+| การทดสอบ | TC-UN08.002 → Failed (เอกสารไม่ถูก Rollback เมื่อการผ่าน GL ล้มเหลว) | Test Report |
+| ข้อบกพร่อง | ISS-030 คงค้าง | Correction Register |
+| การยอมรับ | CR13:001 → Failed → เงื่อนไขการตรวจรับข้อ (1) | Validation Results, Acceptance Report |
+
+## เรื่องที่ต้องพูดตรง ๆ
+
+| ประเด็น | คำตอบสั้น |
+|---|---|
+| ไม่มีคำขอเปลี่ยนแปลงตลอดโครงการ | มีการพิจารณา 3 เรื่องตามเกณฑ์ ไม่มีเรื่องใดเข้าเกณฑ์ หลักฐานอยู่ใน Change Report และรายงานการประชุม |
+| ข้อบกพร่องคงค้างตอนตรวจรับ | บันทึกตามจริง แจ้งผู้รับมอบ และตรวจรับแบบมีเงื่อนไข — ห้ามบอกว่าแก้เสร็จก่อน 24 ส.ค. |
+| UAT ไม่เป็นไปตามเกณฑ์เข้า | ผู้สนับสนุนโครงการอนุมัติให้ทำคู่ขนานในการประชุม 10 ส.ค. และบันทึกความต่างไว้ใน Validation Results |
+| ชุดติดตั้ง Docker ยังไม่ได้ทดสอบ | ส่งมอบหลังรอบทดสอบ เป็นเงื่อนไขการตรวจรับข้อ (2) |
+| Baseline ส่งมอบ `6c39700` ไม่ใช่ Build ที่ทดสอบ | Build ที่ทดสอบคือ `b2c4374` ส่วนที่เพิ่มหลังจากนั้นคือข้อมูลสาธิตและชุดติดตั้ง Docker ซึ่งระบุไว้ในเงื่อนไข |
+
+## สิ่งที่ห้ามทำในวันตรวจ
+
+- ห้ามแก้ไขหรือเติมเอกสารย้อนหลัง ถ้ามีบันทึกใหม่ให้ลงวันที่จริง
+- ห้ามตอบเกินกว่าที่เอกสารบันทึกไว้ ถ้าไม่แน่ใจให้บอกว่า "ขอตรวจสอบเอกสารก่อน" แล้วเปิดดู
+- ห้ามอ้าง Commit, Branch หรือเอกสารที่เกิดหลังวันที่ของเอกสารที่กำลังพูดถึง