Volume 15 · Technical Debt & Risk Register

วัตถุประสงค์ของ Volume

Volume นี้รวบรวมหนี้ทางเทคนิค (technical debt) ของระบบ VTRC ทั้งหมดไว้ในที่เดียว ทุกรายการมีหลักฐานอ้างอิง (file:line) และระบุผลกระทบ แนวทางแก้ไขระยะสั้น และทิศทางระยะยาว

จุดประสงค์คือให้ทีมตัดสินใจได้ว่าจะจัดลำดับเรื่องใดก่อน โดยดูจาก severity และ effort ที่ต้องใช้ ไม่ใช่ตัดสินใจจากความรู้สึก

ที่มาของข้อมูล

• เอกสาร audit เดิม (Volume docs/audit/05-tech-debt-register.md) — 58 รายการที่สำรวจใน Phase 5
• Scorecard ของ Volume 3-13 ที่เขียนในเล่มนี้
• การตรวจสอบ codebase จริงใน /Users/tnd/Documents/I3/vtrc/

ผู้อ่านที่คาดไว้

• หัวหน้าทีมวิศวกรรม — ใช้วางแผน roadmap
• ทีมปฏิบัติการ — ใช้ทำความเข้าใจความเสี่ยงที่ยังไม่ได้แก้
• ผู้บริหาร — ใช้ประเมินสถานะทางเทคนิคของระบบ
• นักพัฒนาใหม่ — ใช้ทำความเข้าใจว่าทำไมโค้ดบางส่วนจึงเป็นเช่นนั้น

นิยาม Severity

ระดับ	นิยาม	ตัวอย่าง
Critical	ความเสี่ยงด้านความปลอดภัย การสูญเสียข้อมูล หรือความพร้อมใช้งานที่ กำลังเกิดอยู่ ต้องแก้ทันที	command injection, JWT secret เป็นค่า default, GCP key อยู่ใน repo
High	อันตรายต่อความถูกต้องหรือความสามารถในการดูแลรักษาเมื่อโหลดสูง ควรแก้ภายใน 1-3 เดือน	RBAC ไม่สม่ำเสมอ, transaction ถูก swallow, N+1 query ทุก request
Med	สิ่งที่ทำให้การทำงานช้าลง โค้ดอ่านยาก หรือเพิ่มความเสี่ยงในระยะยาว ควรแก่ในโอกาสที่มี	_bk files 131 ไฟล์, ใช้ UI library ซ้อนกัน 4 ตัว, typo ใน ENUM

วิธีอ่าน Volume นี้

1. ภาพรวมรวดเร็ว — ดูบท 14.9 (heat-map) และ 14.12 (scorecard)
2. จะแก้ debt รายการใด — ไปบทที่รวบรวมหมวดนั้น (เช่น security ไป 14.1, 14.2)
3. วางแผน roadmap — ดูบท 14.10 (sequencing) และ 14.11 (guardrails)

ID scheme

แต่ละรายการมี ID ตามหมวดดั้งเดิมของ audit:

Prefix	หมวด
SEC-	Security
PERF-	Performance
CORR-	Correctness / data integrity
LEG-	Legacy / EOL / dependency

ID เดียวกันใช้ต่อเนื่องจาก audit doc 05 เพื่อให้ cross-reference ได้

รูปแบบตารางที่ใช้ในแต่ละบท

| # | ปัญหา | Severity | Evidence (file:line) | Impact | Mitigation ระยะสั้น | แนวทางระยะยาว |

• ปัญหา — อธิบายสั้น ๆ ว่าอะไรผิด
• Evidence — file:line ที่พบ ไม่ใช่คำอธิบาย
• Impact — ผลกระทบจริงต่อระบบ/ผู้ใช้
• Mitigation ระยะสั้น — สิ่งที่ทำได้ในเวลาไม่กี่วัน โดยไม่เปลี่ยน architecture
• แนวทางระยะยาว — สิ่งที่ควรทำเมื่อปรับปรุงระบบ (รายละเอียดใน Volume 15)

สถิติรวม

หมวด	Critical	High	Med	รวม
Security (SEC)	6	5	0	11
Performance (PERF)	2	5	0	8 (note: PERF-7 ถูกนับซ้อนกับ security ที่ 8093)
Correctness (CORR)	3	5	1	9
Legacy (LEG)	2	16	12	30
รวม	13	31	13	58

หมายเหตุ: ตัวเลขอาจทับซ้อนบางหมวด (เช่น PERF-7 ที่เป็นทั้ง security และ performance) — ใช้การนับตาม ID หลัก

ข้อจำกัดของ Volume นี้

1. ไม่ใช่ checklist สำหรับ audit ใหม่ — เป็น register ของ debt ที่พบในช่วงสำรวจเท่านั้น อาจมี debt ที่ยังไม่ถูกค้นพบ
2. ระดับ severity อาจเปลี่ยน — บางรายการอาจรุนแรงกว่าที่ประเมินเมื่อเกิด incident จริง
3. Effort เป็นการประมาณ — ระดับความยากของการแก้ไขขึ้นกับทักษะของทีมและบริบทในขณะนั้น
4. แนวทางระยะยาวอ้างอิง modernization target — ทิศทางที่แนะนำคือ Go (Hexagonal/DDD) สำหรับ backend และ Nuxt 3 (Feature-Sliced Design) สำหรับ frontend ตาม audit doc เดิม แต่ทีมสามารถเลือกทิศทางอื่นได้หากเหมาะสม

โครงสร้าง Volume

• บท 14.1-14.2 — debt ด้าน security (จัดลำดับตาม severity)
• บท 14.3 — debt ด้าน performance
• บท 14.4 — debt ด้าน correctness และ data integrity
• บท 14.5-14.8 — debt ด้าน legacy แยกตามประเภท (runtime, dependency, code quality, build)
• บท 14.9 — heat-map สำหรับตัดสินใจ
• บท 14.10 — ลำดับการปรับปรุง (Wave 0/1/2/3)
• บท 14.11 — กฎป้องกัน debt ใหม่
• บท 14.12 — scorecard สรุป