A.8 Changelog + Errata
บทนี้แบ่งเป็น 2 ส่วน — Changelog (สิ่งที่แก้) และ Errata (สิ่งที่ทราบว่ายังไม่สมบูรณ์)
Part 1 — Changelog
รูปแบบ entry
แต่ละ entry มีรูปแบบ:
## YYYY-MM-DD — หัวข้อการแก้ไข
**สถานะก่อน**: ...
**สถานะหลัง**: ...
**เหตุผล**: ...
**ไฟล์ที่แก้**: ...
**กฎสำหรับงานต่อ**: ...2026-07-10 — END_POINT_CENTRALIZE → cu-central-api
สถานะก่อน: Volume 2 (Architecture) และ Volume 3 (vtrc-api) เขียนว่า END_POINT_CENTRALIZE ใน vtrc-api ชี้ไป NestJS centralize-api
สถานะหลัง: END_POINT_CENTRALIZE ชี้ไป cu-central-api (Node.js Apollo บน port 8082) — NestJS centralize-api เป็น service คนละตัวกัน
เหตุผล: หลักฐานชัดเจนจาก vtrc-api/api/.env.example:36-37:
END_POINT_CENTRALIZE=http://localhost:8082/api/graphql
END_POINT_CENTRALIZE_AUTH=http://localhost:8082/auth- port 8082 = cu-central-api
- NestJS centralize-api รันบน port 3000 (REST) ไม่ใช่ 8082 (GraphQL)
- transport เป็น GraphQL + apiKey header — ตรงกับ pattern ของ cu-central-api
ไฟล์ที่แก้:
- Volume 0: บท 03, 06
- Volume 1: บท 10
- Volume 2: บท 01, 02, 03, 04, 05, 06
- Volume 3: index, บท 01, 03, 04 (rewrite), 06, 08, 09, 10
- Volume 5: index, 09
- Volume 8: บท 01, 09
- Volume 9: บท 01, 02
.cursor/rules/workspace-structure.mdc— แหล่งความเข้าใจผิดของ agent ตั้งแต่แรก
กฎสำหรับงานต่อ: ถ้าเขียนไปแล้วมารู้ทีหลังว่าผิด ต้องกลับไปแก้ต้นเหตุทุก volume ที่อ้างถึง ไม่ใช่แค่ flag ใน volume ใหม่
เรียนรู้: ความผิดพลาดตั้งต้นมาจากชื่อ "centralize-api" ของ NestJS service ที่ดูเหมือนจะเป็น target ของ END_POINT_CENTRALIZE — แต่ความจริงเป็น service ที่แยกต่างหาก ชื่อ "centralize" ใน vtrc-api เป็นชื่อทางประวัติศาสตร์ ไม่ได้หมายถึง service ตัวใดตัวหนึ่งโดยตรง
2026-07-10 — ปรับปรุงภาษาไทยให้เป็นทางการ
สถานะก่อน: Volume 4 มีคำและวลีที่ไม่เป็นธรรมชาติ เช่น "ดูเหมือน vtrc-api น้อง", "specialty ของ", "เป็นเจ้าของฝั่งเดียว"
สถานะหลัง: ปรับปรุงภาษาทั้งหมดให้เป็นทางการและอ่านเข้าใจง่าย — เพิ่ม "คำต้องห้าม/ต้องปรับ" table ใน progress.txt และ A.9
ไฟล์ที่แก้: Volume 4 ทั้งเล่ม (10 ไฟล์) + Volume 5 ทั้งเล่ม (10 ไฟล์) + progress.txt
กฎสำหรับงานต่อ: ก่อนเขียน volume ใหม่หรือแก้ volume เดิม ตรวจสอบกับ "คำต้องห้าม/ต้องปรับ" table ใน A.9
2026-07-11 — Volume 15-16 เสร็จสมบูรณ์
สถานะ: Volume 15 (Modernization Plan) 13 ไฟล์ และ Volume 17 (Appendices) 10 ไฟล์ เสร็จสมบูรณ์ — manual ครบทั้ง 17 volume
2026-07-11 — Documentation integrity remediation (P0 themes A–F + H1)
สถานะก่อน: คู่มือหลาย volume ยังมีข้อผิดระดับ P0 ตามรายงาน /docs-verify CORPUS — ชี้อ่านไป NestJS เป็นสะพาน HR/auth แบบ live, สับสนพอร์ต cu-central, ระบุ KBANK เป็นธนาคารกรุงเทพ, ระบุ OTP ใน Redis ของ vtrc, ตาราง statusKcash ไม่ตรงโค้ด, Volume 7 Apollo/Docker ไม่ตรงแหล่ง, และดัชนี debt ID ใน A.4 ขัดกับ Volume 14
สถานะหลัง: แก้ข้อผิด P0 ตามธีม A–F และ H1 ใน volume ที่อยู่ในคลื่น remediation นี้ ให้สอดคล้องหลักฐานจากโค้ด (cu-central-api เป็น live bridge, พอร์ตแยกตามชั้น CODE_DEFAULT / CLIENT_TARGET / COMPOSE / EXPOSE, กสิกรไทย, OTP ใน MariaDB, statusKcash ตาม config.js, Volume 7 ตามแหล่งปัจจุบัน, A.4 ตาม Volume 14)
เหตุผล: รายงาน integrity CORPUS วันที่ 2026-07-11 ตัดสินว่าคู่มือทั้งชุดไม่ผ่านเกณฑ์จนกว่าจะแก้ P0 — รายละเอียดหลักฐานและ checklist อยู่ใน docs/audits/docs-verify-2026-07-11-corpus.md
ไฟล์ที่แก้ (volumes ในคลื่นนี้):
- Volume 0, 1, 3, 4, 5, 7, 8, 9, 10, 11, 12, 13, 15, 16
- รายงานอ้างอิง:
docs/audits/docs-verify-2026-07-11-corpus.md
กฎสำหรับงานต่อ: หลังแก้ P0 แล้ว ยังต้องทำ VOLUME sweep เพิ่ม (U-005) และยืนยัน caller ของ NestJS (E-08 / U-001) ก่อนถือว่าคู่มือผ่านเกณฑ์ national-grade
2026-07-11 — Documentation integrity Wave 3 complete
สถานะก่อน: CONDITIONAL PASS หลังแก้ธีม P0; รายการ Volume 6 ล้าสมัย; เนื้อหาใน docs/audit/* ทำให้เข้าใจผิด
สถานะหลัง: นับจำนวน Volume 6 ตามหลักฐานแล้ว (exports 138/41, โฟลเดอร์ user 36); ใส่แบนเนอร์ SUPERSEDED และแก้แถววิกฤตใน docs/audit/*; grep ที่เหลือระดับ P0 บน volumes เคลียร์แล้ว
เหตุผล: ปิดงานค้างของ Commander Wave 3
ไฟล์ที่แก้: volume-06-*, docs/audit/*
กฎสำหรับงานต่อ: ให้อ้าง VitePress volumes เป็นหลัก; ถือว่า docs/audit เป็นเอกสารประวัติศาสตร์เท่านั้น
2026-07-11 — Volume 2 port classification (CONDITIONAL PASS → PASS)
สถานะก่อน: /docs-verify CORPUS re-audit ตัดสิน CONDITIONAL PASS เพราะ Volume 2 ยังเขียน cu-central เป็น “port 8082” โดยไม่แยก CODE_DEFAULT APP_PORT=8080 กับ CLIENT_TARGET และ citation config.js:28 / graphql.js:90 คลาดเคลื่อน
สถานะหลัง: Volume 2 บท 01–04 ใช้ภาษาแยกชั้นพอร์ตเดียวกับ Volume 3; citation ชี้ graphql.js:17-23, auth.js:28, และ .env.example:36 พร้อมระบุว่า config.js:28 เป็น default ว่าง
เหตุผล: ปิด finding F-001 / F-002 / F-003 จาก docs/audits/docs-verify-2026-07-11-corpus-reaudit.md
ไฟล์ที่แก้: volume-02-architecture/01-system-context.md, 02-topology.md, 03-request-lifecycle.md, 04-external-integrations.md
กฎสำหรับงานต่อ: ห้ามเขียน “cu-central = port 8082” โดยไม่มีชั้น CODE_DEFAULT / CLIENT_TARGET / COMPOSE / EXPOSE
2026-07-11 — Residual P1 cleanup (Vol 8 sourceDb, Vol 14 LEG packages, audit diagram)
สถานะก่อน: หลัง PASS ยังเหลือ P1 — sourceDb ถูกเขียนเป็น enum 'vtrc'|'nbc'; LEG-10/12/29 อ้าง package บน cu-central ผิด; แผนภาพใน docs/audit/04 ยังชี้อ่าน NestJS บน time-attendance path
สถานะหลัง: Vol 8 อธิบาย sourceDb เป็นสตริง HRMI SourceDB จริง; LEG-10/29 จำกัดที่ vtrc-api; LEG-12 แยกเวอร์ชัน redis; แผนภาพ audit 04 แก้เป็น cu-central
เหตุผล: ปิดรายการค้างจากคำถาม “มีอะไรผิดอีก”
ไฟล์ที่แก้: volume-09-data-model/05, 09, 11; volume-15-tech-debt/06-dependency-hygiene.md; docs/audit/04-business-logic.md; docs/audit/05-tech-debt-register.md (banner)
กฎสำหรับงานต่อ: ก่อนอ้าง package ใน debt register ต้องเปิด package.json ของ repo นั้น ๆ
Part 2 — Errata
สิ่งที่ทราบว่า manual ยังไม่ครอบคลุม หรือข้อจำกัดที่ผู้อ่านควรรู้
E-01 — ไม่ได้รัน npm audit / yarn audit
ที่มา: Vol 9.11 (11-scorecard-remediation.md) รายละเอียด: Vol 14 ระบุ CVEs จากข้อมูลที่ public แต่ไม่ได้รัน npm audit --production จริงในทุก repo เพราะต้องการ network install ผลกระทบ: อาจมี CVEs ที่ไม่ถูกรายงาน แนวทางแก้: รัน npm audit ใน Wave 0 (Vol 15.2)
E-02 — ไม่ได้ audit TLS cipher suite ของ nginx
ที่มา: Vol 9.11 รายลัพธ์: nginx config mount จาก host ไม่ได้อยู่ใน repo จึงไม่สามารถวิเคราะห์ cipher ได้ ผลกระทบ: อาจมี cipher ที่อ่อนแอหรือ protocol version เก่า (เช่น TLS 1.0) แนวทางแก้: ขอ nginx config จากทีมปฏิบัติการและทำ sslscan ใน Wave 0
E-03 — ไม่ได้ครอบคลุม OWASP Top 10 ครบ
ที่มา: Vol 9.11 รายลัพธ์: Vol 9 ครอบเฉพาะช่องโหว่ที่พบจริง ไม่ใช่ assessment ครบทั้ง 10 หมวดของ OWASP ผลกระทบ: อาจมีช่องโหว่ในหมวดที่ไม่ได้วิเคราะห์ที่ยังไม่ถูกรายงาน แนวทางแก้: จ้างทำ penetration test เต็มรูปแบบใน Wave 0
E-04 — ไม่ได้ trace createslip/createtax end-to-end
ที่มา: Vol 9.11 รายลัพธ์: ไม่ได้ยืนยันว่า qpdf RCE (SEC-1) สามารถเข้าถึงได้โดยไม่ต้อง authenticate หรือไม่ ผลกระทบ: severity ของ SEC-1 อาจผิด แนวทางแก้: trace code path ใน Wave 0 (ก่อนแก้ SEC-1)
E-05 — Debt register อาจไม่ครบ
ที่มา: Vol 14 index รายลัพธ์: Vol 14 ไม่ใช่ checklist สำหรับ audit ใหม่ — เป็นการรวบรวม debt ที่พบในระหว่างเขียน manual ผลกระทบ: อาจมี debt ที่ไม่ได้ถูกรายงาน แนวทางแก้: ทำ debt discovery workshop กับทีมวิศวกรรมใน Wave 0
E-06 — file:line reference อาจคลาดเคลื่อน
ที่มา: limitation ของ manual รายลัพธ์: line number ใน file:line reference อ้างถึงสถานะ codebase ณ กรกฎาคม 2026 — ถ้า code มีการแก้ไข line number จะเปลี่ยน ผลกระทบ: reader อาจไม่เจอจุดที่อ้างถึงตรง ๆ แต่ยังเจอ "ใกล้ ๆ" ได้ แนวทางแก้: ใช้เป็นจุดอ้างอิงเบื้องต้น แล้วค้นหาในไฟล์ด้วยชื่อ function หรือ variable
E-07 — Effort estimate เป็นการประมาณ
ที่มา: Vol 14.9 (heatmap), Vol 15.11 (budget) รายลัพธ์: ตัวเลข effort (วัน, สัปดาห์, เดือน) เป็น rough order of magnitude ผลกระทบ: งบประมาณจริงอาจห่างจากประมาณการอย่างมาก แนวทางแก้: quote จาก vendor หรือประเมินจากความเร็วจริงของทีมใน Wave 0
E-08 — centralize-api caller ยังไม่ยืนยัน
ที่มา: Vol 5 + Vol 12 รายลัพธ์: ไม่พบหลักฐานใน codebase ว่า NestJS centralize-api ถูกเรียกจาก service ใดใน production — แต่ทีมงานแจ้งว่ามี caller (NEW_CENTRAIL_API ใน vtrc-api, CENTRALIZE_SERVER ใน benefit-api) ซึ่งไม่มีอยู่ใน workspace ปัจจุบัน ผลกระทบ: architecture diagram อาจไม่สมบูรณ์ แนวทางแก้: สอบถามทีมอีกครั้ง ขอ repo ของ benefit-api หรือ config ของ NEW_CENTRAIL_APIสถานะ: ยังเปิดอยู่ (U-001) — ไม่ใช่เป้าหมายของคลื่น remediation 2026-07-11
E-09 — NestJS ยังถูกอธิบายว่าเป็น live bridge ในหลาย volume
ที่มา: docs/audits/docs-verify-2026-07-11-corpus.md (Theme A; F-001, F-008, F-015–F-016, F-019–F-020, F-027–F-028, F-034, F-042) รายลัพธ์: Volume 0, 1, 4, 8, 9, 12, 15 (และไดอะแกรมที่เกี่ยวข้อง) ชี้อ่านไป NestJS centralize-api เป็นเส้นทาง HR/auth แบบ live ทั้งที่โค้ดใช้ END_POINT_CENTRALIZE(_AUTH) → cu-central-api ผลกระทบ: ผู้อ่านติดตาม auth / payslip / attendance ผิด service แนวทางแก้: ปรับทุกจุดให้ตรง Volume 2/3 — live bridge คือ cu-central-api; NestJS ระบุว่า caller ยังไม่ยืนยัน (E-08) สถานะ: remediated (Wave 1–3, 2026-07-11)
E-10 — ความสับสนเรื่องพอร์ต cu-central (8080 / 8082 / 9000)
ที่มา: CORPUS Theme B (F-002, F-021, F-030, F-041) รายลัพธ์: คู่มือระบุพอร์ตแบบสัมบูรณ์ผิดชั้น — APP_PORT เริ่มต้น 8080, ตัวอย่าง client ใน .env.example ใช้ 8082, EXPOSE 9000 เป็น metadata ใน Dockerfile เท่านั้น, compose ใช้ host ports อื่น ผลกระทบ: ตั้งค่า local / อ่าน topology ผิดพอร์ต แนวทางแก้: เขียนใหม่โดยแยกชั้น CODE_DEFAULT / CLIENT_TARGET / COMPOSE_HOST / DOCKER_EXPOSE — ห้ามสรุปว่า “cu-central = 8082” หรือ “= 9000” โดยไม่มีเงื่อนไข สถานะ: remediated (Wave 1–3, 2026-07-11)
E-11 — KBANK ถูกระบุว่าเป็นธนาคารกรุงเทพ
ที่มา: CORPUS Theme C (F-009, F-014, F-017, F-018) รายลัพธ์: Volume 0/1 (และ glossary) ใช้ชื่อ “ธนาคารกรุงเทพ” กับ KBANK / K-Cash ทั้งที่ vtrc-api/api/src/config.js ระบุกสิกรไทย ผลกระทบ: เอกสารการเงินและคำอธิบายธนาคารผิดสถาบัน แนวทางแก้: แทนที่ด้วยกสิกรไทยทุกจุดที่อ้าง KBANK ใน Volume 0/1 สถานะ: remediated (Wave 1–3, 2026-07-11)
E-12 — OTP / Redis ถูกระบุผิดว่าอยู่ที่ vtrc-api
ที่มา: CORPUS Theme D (F-035–F-038; X-004) รายลัพธ์: Volume 12.7 และ Volume 13.6/7/8 อธิบาย OTP ใน Redis ของ vtrc (otp:*, TTL 5 นาที) ทั้งที่ OTP ถูกเก็บใน MariaDB ของ cu-central (Models.Otp, TTL เริ่มต้น 3 นาที) ผลกระทบ: runbook debug / ปฏิบัติการ Redis ผิดที่ — ค้นหา key ที่ไม่มี แนวทางแก้: เขียนส่วน Redis ของ vtrc ใหม่; ชี้ OTP ไปที่ฐานข้อมูล cu-central; ลบ runbook otp:* บน vtrc-redis สำหรับ registration OTP สถานะ: remediated (Wave 1–3, 2026-07-11)
E-13 — ตาราง statusKcash ใน Volume 11 ไม่ตรง config.js
ที่มา: CORPUS Theme E (F-031; และ cron gating ที่เกี่ยวข้อง F-010, F-032) รายลัพธ์: Volume 11.3 มี id '0' เป็น SUCCESS และป้ายสถานะไม่ตรงโค้ด — ค่าจริง SUCCESS = '9' (PAID / โอนสำเร็จ); FAILED = '6','7','8','10'ผลกระทบ: อ่านสถานะโอน K-Cash / welfare hospital ผิดรหัส แนวทางแก้: แทนที่ตารางด้วยค่าจาก vtrc-api/api/src/config.js:488-518; แก้ narrative cron APP_NO และลบการอ้าง K-Cash cron ที่ไม่มีใน crons.jsสถานะ: remediated (Wave 1–3, 2026-07-11)
E-14 — Volume 7 Apollo / Docker / auth ไม่ตรงแหล่งปัจจุบัน
ที่มา: CORPUS Theme F (F-023–F-025) รายลัพธ์: บท 7.2–7.4 อ้าง createHttpLink, getApikey, JWT จาก isLoggedIn, และ Docker แบบ serve/alpine ทั้งที่ backoffice ใช้ createUploadLink, apiKeyNews(), isLoggedIn เป็น boolean, และ stage-2 เป็น nginx:1.24.0ผลกระทบ: onboarding backoffice และ troubleshooting Apollo ผิด API แนวทางแก้: เขียน 7.2–7.4 ใหม่จาก vtrc-rc-backoffice/src/config/apollo.js, auth utils, และ Dockerfile ปัจจุบัน สถานะ: remediated (Wave 1–3, 2026-07-11)
E-15 — ดัชนี debt ID ใน A.4 ขัดกับ Volume 14
ที่มา: CORPUS Theme H1 (F-039; X-003) รายลัพธ์: volume-16/.../04-debt-id-index.md สลับความหมาย SEC-6/7/8 เทียบกับ Volume 14 (SEC-6 trustCert, SEC-7 axois, SEC-8 PII เป็นต้น) ผลกระทบ: อ้างอิง debt / remediation plan ข้าม volume ผิด ID แนวทางแก้: ให้ A.4 ตรงกับ Volume 14 ทุกตัว — Volume 14 เป็นแหล่งอำนาจของหมายเลข SEC/LEG สถานะ: remediated (Wave 1–3, 2026-07-11)
วิธีรายงาน errata ใหม่
ถ้าพบข้อผิดพลาดใน manual รายงานโดย:
- บันทึกใน section "Errata" ของไฟล์นี้
- ใช้รูปแบบเดียวกับ E-01 ถึง E-15 (ที่มา, รายลัพธ์, ผลกระทบ, แนวทางแก้, สถานะถ้ามี)
- ถ้าเป็นข้อผิดพลาดที่ต้องแก้ใน volume อื่น ให้แก้ทันทีและบันทึกใน Changelog ของไฟล์นี้ด้วย
นโยบายการแก้ไข
- ข้อผิดพลาดทางข้อเท็จจริง (เช่น END_POINT_CENTRALIZE) — แก้ทันที และบันทึกใน Changelog
- ข้อจำกัดที่ทราบ (เช่น ไม่ได้รัน npm audit) — เก็บใน Errata จนกว่าจะแก้
- ความเห็นที่เปลี่ยน — ไม่ใช่ errata เก็บเป็น entry ใหม่ใน Changelog พร้อมเหตุผล