Canonical Truths — VTRC Knowledge Manual v2

ข้อเท็จจริงยืนยันจากโค้ด ใช้เป็น source of truth เมื่อเขียนหรือตรวจสอบ claim ใด ๆ ในคู่มัน

หากเนื้อหาใน volume ขัดแย้งกับตารางนี้ ให้แก้ volume ไม่ใช่ตารางนี้ (เว้นแต่ตารางนี้ผิดพลาด ซึ่งต้อง verify ใหม่และ update พร้อมบันทึกใน changelog)

สืบทอดมาจาก v1 DOC-CODE-DISCREPANCY-AUDIT.md (2026-07-11) — verified against legacy 5 services

Legacy Core (vtrc-api, cu-central-api, centralize-api)

ข้อเท็จจริง	ค่าที่ถูกต้อง	หลักฐาน
Live HR bridge จาก `vtrc-api`	`END_POINT_CENTRALIZE` → cu-central-api GraphQL	`vtrc-api/api/.env.example:36-37`, `vtrc-api/api/src/centralize/controllers/graphql.js`
NestJS `centralize-api`	service คนละตัว; REST `/api/`; caller จาก vtrc-api ไม่ยืนยัน* (debt E-08)	ไม่มี HTTP client ไป NestJS ใน `vtrc-api`
cu-central default `APP_PORT`	8080	`cu-central-api/main-api/src/config.js:20`
พอร์ตใน `.env.example` ของ vtrc-api	8082 (ค่าตัวอย่างที่ vtrc-api ชี้ — ไม่ใช่ default ของ cu-central)	`vtrc-api/api/.env.example:36`
Dockerfile `EXPOSE 9000` ของ cu-central	docs-only / ไม่ใช่ listen default	`cu-central-api/main-api/Dockerfile`
Compose cu-central prod map	มักเป็น 8000:8000	`cu-central-api/docker-compose.yml`
KBANK	ธนาคารกสิกรไทย (Kasikorn) ไม่ใช่กรุงเทพ	`vtrc-api/api/src/config.js:389`
`statusKcash` SUCCESS	id `'9'` → status `SUCCESS` (label PAID)	`vtrc-api/api/src/config.js:508-511`
K-Cash import	manual (`importUpdateStatus`) — ไม่มี cron ดึงผลธนาคาร	`vtrc-api/api/src/crons.js:14-27`
Cron `APP_NO===1`	เฉพาะ fund rate job; `updateDelegatesExpire` + `statLog` รันทุก replica	`vtrc-api/api/src/crons.js:14-27`
OTP store	cu-central MariaDB `otp`, default TTL 3 นาที — ไม่ใช่ Redis ของ vtrc	`SMS_OTP_EXPIRE_MINUTES`; `sendOtp` resolver
vtrc-api Redis	เชื่อมต่อได้ แต่ cache call sites ส่วนใหญ่ commented / vestigial	`vtrc-api/api/src/lib/redis.js` + callers
Dual MariaDB ใน vtrc-api	`db` + `db2` เท่านั้น — ไม่มี `dbHr` ใน `connector.js`	`vtrc-api/api/src/connector.js`
NBC MSSQL name	`dbHRMI_Center_NBC`	`centralize-api/src/employee/employee.service.ts`
NestJS `hrPaySlip`	`POST /api/hrPaySlip` ไม่ใช่ GET	`centralize-api/src/hrpayslip/hrpayslip.controller.ts:18`
NestJS employee GETs	14 routes; รวมทั้งระบบ ≈ 17	`centralize-api/src/employee/employee.controller.ts`
Device key field	`API_DEVICE_KEY[].key` ไม่ใช่ `apiKey`	`vtrc-api/api/src/config.js` + `index.js`
Session Redis key	`sess:{userUid}_{sessionId}` ไม่ใช่ `sess:<sid>`	`vtrc-api/api/src/session.js`
syncModels active	79 (ไม่ใช่ 88)	`vtrc-api/api/src/lib/model.js`
Frontend GraphQL URI	จาก `window.location.href` ผ่าน `checkLinkURL()` — ไม่ใช่ `NODE_ENV`	`vtrc-web/src/config/apollo.js`, `vtrc-rc-backoffice/src/config/apollo.js`

พอร์ตของ cu-central-api — เขียนให้ถูก

cu-central-api:
  - default ในโค้ด: APP_PORT = 8080
  - vtrc-api .env.example ชี้: http://localhost:8082/api/graphql
    (ค่าที่ทีมตั้งตอน dev — ต้อง align กับ env จริง)
  - docker-compose (prod-style): มัก map 8000
  - อย่าเขียนว่า "cu-central = port 8082" โดยไม่มีเงื่อนไข
  - อย่าเขียน port 9000 เป็น listen port

Branch topology ของแพลตฟอร์ม (ใหม่ใน v2)

หลาย repo ในแพลตฟอร์มมี default branch (main/master) ที่ว่างหรือน้อยกว่า branch production จริง:

repo	default branch	branch canonical (ใช้ในการ document)	ไฟล์
`2way-api`	master	prod	178
`2way-meeting-backoffice`	master	prod	521
`2way-vtrc-api`	master	prod	158
`ai-recruitment-api`	main (ว่าง)	prod	390
`benefit-api`	master	prod	172
`job-scheduler-api`	master	prod	31
`meeting-backoffice`	master	UAT	72
`meeting-backoffice-new`	master (ว่าง)	UAT	56
`pms-api`	master (ว่าง)	uat	376
`recruitment-api`	master	prod	322
`recruitment-web`	master	prod	200
`vtrc-backoffice-new`	master	uat	773
`vtrc-common`	master	prod	58
`workflow-api`	main	uat	153
`sso-api`	main (ว่าง)	master	35
`meeting-vtrc-api`	master	prod-meeting-vtrc-api	180

กฎการ citation: เมื่ออ้าง file:line ของบริการเหล่านี้ ต้องระบุ branch ด้วย เช่น benefit-api/src/main.ts (branch: prod):42

Placeholder repos (ไม่มีโค้ด)

repositories เหล่านี้มีเพียง .git และ .gitignore (1 ไฟล์) — ไม่มีโค้ดในทุก branch:

attendance-api
auth-api
career-api
hrservice-api
learning-api
notification-api
payroll-api
performing-api

เขียนถึงใน Vol 10 ว่าเป็นแผน microservices split ที่วางไว้ แต่ยังไม่มีการ implement

2way Platform (2way-api, 2way-batch, 2way-line-service, 2way-meeting-backoffice, 2way-vtrc-api)

ข้อเท็จจริง	ค่าที่ถูกต้อง	หลักฐาน
Stack จริงของกลุ่มนี้	ไม่ใช่ NestJS 9 + Next.js เพียงอย่างเดียว — `2way-vtrc-api` คือ Express + Sequelize (MSSQL) + Mongoose และเป็น backend หลักที่ LIFF/employee-facing screens ใน `2way-meeting-backoffice` เรียกจริง	`2way-vtrc-api/util/db.config.ts`, `2way-meeting-backoffice` เรียก `getProfile`/`verifyUserLine`/`getListFAQs` ผ่าน `2way-vtrc-api`
`2way-api` (NestJS) รับผิดชอบ	เฉพาะ survey/announce admin CRUD + auth บางส่วน — เป็น subset ไม่ใช่ backend หลัก	`2way-api/src/announces/`, `2way-api/src/surveys/`
`2way-api` → centralize bridge	เรียกทั้ง `centralize-api` (REST, `EmployeesService`) และ `cu-central-api` (GraphQL, query `fetchListEmployeeForTwoWay`) — ยืนยัน/แก้ debt E-08 บางส่วนจากฝั่งนี้	`2way-api/src/employees/employees.service.ts`, `2way-api/src/auth/auth.service.ts`
`2way-vtrc-api` → cu-central-api	เรียก GraphQL ที่ host:port ต่างจาก `2way-api` (hardcode `centralizeapi.redcross.or.th:25563`)	`2way-vtrc-api` config
`2way-api` → `2way-line-service`	เชื่อมด้วย hardcoded IP `20.212.116.206:8200` ไม่ใช่ DNS	`2way-api` config
Ports ยืนยันแล้ว	`2way-line-service`=8200, `2way-vtrc-api`=8001, `2way-meeting-backoffice`=8002	Dockerfile/config ของแต่ละ repo
JWT secret	`SECRET_JWT_TWOWAY` ใช้ร่วมกันใน `2way-api`/`2way-batch`/`2way-line-service`; `2way-vtrc-api` มี secret ที่สองแยกต่างหาก hardcode ใน `util/jwt.config.ts`	ดูรายละเอียดใน `docs/volume-05-2way-platform/`
`2way-meeting-backoffice`	ชื่อ repo ทำให้เข้าใจผิด — ไม่มีความเกี่ยวข้องกับ Meeting Platform group เลย เป็น admin/LIFF frontend ของ 2way เท่านั้น	`docs/volume-05-2way-platform/2way-meeting-backoffice/`

Domain Microservices (benefit-api, recruitment-api, ai-recruitment-api, pms-api, chat-center-api, job-scheduler-api, workflow-api, sso-api, vtrc-common)

ข้อเท็จจริง	ค่าที่ถูกต้อง	หลักฐาน
`vtrc-common` คือ	ไม่ใช่ shared npm library — เป็น standalone HTTP microservice (Dockerfile+`.env`+MSSQL DB `vtrc_common` ของตัวเอง), port 9310 — ไม่มี repo ใดใน workspace ประกาศเป็น npm dependency	`vtrc-common/Dockerfile`, `vtrc-common/.env`
`vtrc-common` consumer จริง	`benefit-api` (เฉพาะ `/file/*`), `vtrc-mobile`, `vtrc-web`, `vtrc-rc-backoffice` — เรียกผ่าน HTTP URL ตรง	grep คำว่า `vtrc-common`/`vtrc_common` ข้าม repo
`workflow-api` package name จริง	`ai-pms-nest` — ครอบ 3 domain: AI course embedding, health-checkup benefit config, IPD hospital billing	`workflow-api/package.json:2` (branch: uat)
`workflow-api` auth	ไม่มี global auth guard บังคับ — role อ่านจาก JWT payload ที่ไม่ verify signature (เป็นข้อยกเว้นเดียวในกลุ่ม NestJS ทั้งหมด)	`workflow-api/src` (branch: uat) — ดู `docs/volume-06-domain-microservices/workflow-api/`
`sso-api`	ไม่เคย issue JWT ของตัวเอง (call `sign()` ถูก comment ไว้) — endpoint ที่การ์ดด้วย `JwtAuthGuard` จึงเข้าไม่ถึงผ่าน flow ปกติของตัวเอง	`sso-api/src/app.service.ts:27,143-191`
Ports ยืนยันแล้ว	`benefit-api`=9320, `recruitment-api`=9330, `pms-api`=9331, `ai-recruitment-api`=9430, `vtrc-common`=9310	Dockerfile/config ของแต่ละ repo
Secret sharing ข้ามกลุ่ม	JWT secret เดียวกันใน `benefit-api`/`recruitment-api`/`ai-recruitment-api`/`pms-api`; MSSQL `sa` password เดียวกันใน `chat-center-api`/`job-scheduler-api`/`vtrc-common`/`workflow-api` — ไม่มี central auth/secret-management service	`.env` ของแต่ละ repo (ดู debt IDs ใน Volume 17/18)
Database coupling ข้าม service	`benefit-api` เขียนตรงเข้า schema `vtrc` ของ legacy core (TypeORM connection ที่สอง); `recruitment-api`/`ai-recruitment-api` share database `recruitment_ai`; `pms-api` เชื่อม `dbWorkforce` จาก 10 module; `workflow-api` เชื่อม 6 database connection รวม `vtrc`, `dbHRMI_Center`, `dbHRMI_Center_NBC`, `benefit`	ดู `docs/volume-06-domain-microservices//03-persistence.md`

Meeting Platform (meeting-vtrc-api, meeting-backoffice, meeting-backoffice-new)

ข้อเท็จจริง	ค่าที่ถูกต้อง	หลักฐาน
`meeting-vtrc-api` stack	ไม่ใช่ "Express + Mongoose" ตามที่ `docs/index.md` ระบุไว้เดิม — เป็น Express + Sequelize + MSSQL; `mongoose` เป็น dead dependency (`util/mongo.config.ts` comment ทิ้งทั้งไฟล์)	`meeting-vtrc-api/util/db.config.ts:1-6`, `.envprod:16` (branch: prod-meeting-vtrc-api)
`meeting-backoffice-new`	build output ถูก embed เป็น static sub-app ใน `vtrc-backoffice` และ `vtrc-backoffice-new` ที่ path `/meeting-backoffice/` (ยืนยันด้วย shasum ตรงกัน)	ดู `docs/volume-07-meeting-platform/`
`meeting-backoffice` (Next.js)	deploy เป็น standalone service จริงผ่าน GCR image แยก mount ที่ `/meetingbo`	Dockerfile + deploy config
`meeting-vtrc-api` → `vtrc-api`	bridge auth ผ่าน GraphQL query `fetchEmployeeProfileForOtherService`; ส่ง push notification ผ่าน `vtrc-api`'s mutation `sendNotificationFrom3Party` ไม่ได้ยิง FCM ตรง	`meeting-vtrc-api/middleware/checkbypass.ts:38-56`

Mobile (vtrc-mobile, new-vtrc-mobile, vtrc-application-front)

ข้อเท็จจริง	ค่าที่ถูกต้อง	หลักฐาน
Endpoint resolution บน mobile	ไม่ใช่ `checkLinkURL()` แบบเว็บ — เป็น source-level constant ที่ต้อง comment/uncomment แล้ว rebuild เพื่อสลับ PROD/UAT/local	`vtrc-mobile/src/config/index.js:4`, `src/constants/HostApi.js:23` (มี drift กันเอง 3 ไฟล์)
`Config.MEETING_API`	hardcode ชี้ไป UAT host เสมอไม่ว่า build config จะเป็นอะไร	`vtrc-mobile/src/config/index.js:12`
`vtrc-application-front`	ไม่ใช่ Cordova ตามที่ `docs/index.md` ระบุไว้เดิม — เป็นหน้า static HTML "download center" ที่มี `.ipa` binary commit ไว้	เนื้อหาจริงใน repo, ดู `docs/volume-08-mobile/vtrc-application-front/`

Web Frontends เพิ่มเติม (vtrc-backoffice, vtrc-backoffice-new)

ข้อเท็จจริง	ค่าที่ถูกต้อง	หลักฐาน
AntD version ของกลุ่ม	ไม่ใช่ "v3/v4" แบบรวม — มีเพียง `vtrc-web` ที่ใช้ v3; `vtrc-rc-backoffice`/`vtrc-backoffice`/`vtrc-backoffice-new` resolve ไปที่ v4.15.4 ตรงกันหมด	`package-lock.json` ของแต่ละ repo
`vtrc-backoffice` vs `vtrc-backoffice-new`	`-new` คือ fork/copy ของ `vtrc-backoffice` พัฒนาต่อแยก repo — src ตรงกัน 99%+	ดู `docs/volume-04-frontends/index.md`
SSO handoff cross-repo	`vtrc-backoffice-new` (ผู้ส่ง, `checkEmployeeCU`) → `/pathLogin/:token/:refreshToken` → `vtrc-rc-backoffice` (ผู้รับ, component `PathLogin`) — ส่ง access/refresh token ผ่าน URL จริง ยืนยันทั้ง 2 ฝั่ง	`vtrc-backoffice-new/src/pages/Login/index.js:83-103` (branch: uat), `vtrc-rc-backoffice/src/containers/App/index.js:24`

การ verify canonical truths ใหม่

เมื่อมีการเปลี่ยนแปลงโค้ดที่กระทบตารางนี้:

อัปเดตตารางพร้อมบันทึกวันที่ verify
แจ้งใน Vol 20 · Changelog ว่า canonical truth ไหนเปลี่ยน
ตรวจทุก volume ที่อ้างถึง truth นั้น — แก้ให้ตรงกัน

หากไม่แน่ใจว่าข้อมูลถูก ให้รัน docs-verify skill เพื่อ re-verify

Canonical Truths — VTRC Knowledge Manual v2 ​

Legacy Core (vtrc-api, cu-central-api, centralize-api) ​

พอร์ตของ cu-central-api — เขียนให้ถูก ​

Branch topology ของแพลตฟอร์ม (ใหม่ใน v2) ​

Placeholder repos (ไม่มีโค้ด) ​

2way Platform (2way-api, 2way-batch, 2way-line-service, 2way-meeting-backoffice, 2way-vtrc-api) ​

Domain Microservices (benefit-api, recruitment-api, ai-recruitment-api, pms-api, chat-center-api, job-scheduler-api, workflow-api, sso-api, vtrc-common) ​

Meeting Platform (meeting-vtrc-api, meeting-backoffice, meeting-backoffice-new) ​

Mobile (vtrc-mobile, new-vtrc-mobile, vtrc-application-front) ​

Web Frontends เพิ่มเติม (vtrc-backoffice, vtrc-backoffice-new) ​

การ verify canonical truths ใหม่ ​