1 · Glossary
รวมคำศัพท์/acronym ที่ปรากฏซ้ำข้ามหลาย volume ของคู่มือนี้ เรียงตามตัวอักษร — สำหรับความหมายเชิงลึกของแต่ละจุดให้ตามลิงก์ไปยัง volume ต้นทาง
APP_TYPE — ค่าที่ระบุประเภทของ frontend ที่ยิง request มา (WEB, MOBILE, WEB_ADMIN ฯลฯ) ใช้ควบคุมสิทธิ์ผ่าน API_DEVICE_KEY ใน vtrc-api — ดู Vol 3 · vtrc-api
apiKey (device key) — key ระดับ device/frontend (ไม่ใช่ user) ที่ยืนยันว่า request มาจาก frontend ที่รู้จัก field จริงในโค้ดคือ key ไม่ใช่ apiKey (vtrc-api/api/src/config.js) — คนละแนวคิดกับ JWT ที่ยืนยันตัวตนของ user apiKey อย่างเดียวไม่ควรใช้แทน user authentication แต่หลาย repo ทำเช่นนั้น (ดู SEC-CU-05 ใน Vol 17)
checkLinkURL() — ฟังก์ชันที่ legacy frontend (vtrc-web, vtrc-rc-backoffice) ใช้เลือก GraphQL endpoint โดยอ่านจาก window.location.href แทน NODE_ENV — ดู canonical truth ที่ _audit-method/canonical-truths.md
dbHRMI_Center / dbHRMI_Center_NBC — ฐานข้อมูล MSSQL ของระบบ HR กลาง (HRMI) ที่ workflow-api เชื่อมต่อตรงข้าม service — NBC คือ instance แยกสำหรับหน่วยงานสาขา (National Blood Centre หรือเทียบเท่า)
empCode — รหัสพนักงาน ใช้เป็น key เชื่อมข้อมูลข้าม service หลายตัว (benefit-api, pms-api, workflow-api) แทน user id ภายในของแต่ละ service เอง
HRMI — ระบบ HR กลางของสภากาชาดไทย (Human Resource Management Information) ที่หลาย domain microservice (workflow-api, pms-api) เชื่อมต่อฐานข้อมูลตรงเพื่ออ่าน/เขียนข้อมูลพนักงาน
ignoreAuth — flag ใน cu-central-api ที่อนุญาตให้ resolver บางตัว bypass user-level authentication โดยพอมี apiKey ที่ถูกต้องเพียงอย่างเดียว — ดู SEC-CU-05
JWT vs apiKey — JWT ยืนยันตัวตนของ user (มี expiry, มี payload ที่ verify signature ได้) apiKey ยืนยันแค่ว่า request มาจาก device/frontend ที่รู้จัก ไม่ได้ผูกกับ user คนใดคนหนึ่ง — การใช้ apiKey แทน JWT ในจุดที่ควรตรวจ user คือช่องโหว่ pattern ที่พบซ้ำหลายครั้ง (ดู Vol 18 · auth failures / shared-secret blast radius)
@Public() — decorator ของ NestJS ที่บอกให้ global JwtAuthGuard ข้ามการตรวจสอบสำหรับ route นั้น ใช้ถูกต้องสำหรับ endpoint ที่ตั้งใจเปิดสาธารณะจริง (เช่น health check) แต่พบว่าถูกใช้ผิดจุดในหลาย repo — ดู Vol 18 · auth Class B
OTP store — ระบบ one-time password ของ VTRC เก็บอยู่ที่ตาราง otp ใน cu-central MariaDB (TTL 3 นาที) ไม่ใช่ Redis ของ vtrc-api ตามที่อาจเข้าใจผิดได้
SECRET_JWT_TWOWAY — ชื่อ environment variable ของ JWT secret ที่ share ร่วมกันระหว่าง 2way-api, 2way-batch, 2way-line-service — 2way-vtrc-api มี secret ตัวที่สองแยกต่างหาก hardcode ใน util/jwt.config.ts ไม่ใช่ตัวเดียวกัน
Distributed monolith — สถาปัตยกรรมที่ระบบถูกแยกเป็น microservice หลายตัวตาม deployment unit แต่ยังผูกกันแน่นระดับฐานข้อมูล (service หนึ่งอ่าน/เขียนตรงเข้า schema ของอีก service) ทำให้ได้ downside ของ monolith (change ที่กระทบกันข้าม service) โดยไม่ได้ upside ของ microservice (deploy/scale อิสระจากกันจริง) — พบใน workflow-api, benefit-api, pms-api (ดู Vol 19.3 · 12-month platform · cross-DB)
Debt ID scheme — รูปแบบการตั้งชื่อ debt item ในคู่มือนี้: SEC- (Security), PERF- (Performance), CORR- (Correctness/data integrity), LEG- (Legacy/EOL/dependency), QUAL- (Code quality), OBS- (Observability) — ดู _style/style-guide.md และ Vol 20 · debt-ID index
Canonical branch — สำหรับหลาย repo ในแพลตฟอร์ม default branch (main/master) ว่างหรือมีโค้ดน้อยกว่า branch production จริง (เช่น prod, uat) คู่มือนี้ document ตาม canonical branch เสมอ ไม่ใช่ default branch — ดูตารางเต็มที่ canonical-truths.md
Placeholder repo — repo ที่มีเพียง .git+.gitignore ไม่มีโค้ดจริงในทุก branch (8 ตัว: attendance-api, auth-api, career-api, hrservice-api, learning-api, notification-api, payroll-api, performing-api) — เป็นแผน microservice split ที่วางไว้แต่ยังไม่ implement ดู Vol 10
Wave / time horizon (ใน context modernization) — เดิมจัดเป็น Wave 1–4 ตาม debt category; หลัง Deep Redo จัดเป็นขอบฟ้าเวลา 90 วัน / 6 เดือน / 12 เดือน ตาม ROI ของ deep scorecards — ดู Vol 19 · Modernization
Scorecard — ไฟล์ *scorecard*.md ในแต่ละ per-service deep-dive volume (Vol 3-9) ที่บันทึก debt item ของ repo นั้นพร้อม severity — เป็นแหล่งข้อมูลต้นทางของ Vol 17 · master register ทั้งหมด
KBANK — ธนาคารกสิกรไทย (Kasikorn Bank) ปรากฏใน config ของ vtrc-api สำหรับ payment gateway — ไม่ใช่ธนาคารกรุงเทพตามที่อาจเข้าใจผิดจากชื่อย่อ
statusKcash — สถานะการชำระเงินผ่านช่องทาง K-Cash ของ vtrc-api — id '9' หมายถึงสถานะ SUCCESS (label แสดงผลคือ "PAID")