Queue Manager — สเปกผลิตภัณฑ์ (Contract)

ระบบหน้ารอคิวเสมือน (virtual waiting room) และจัดการ traffic ระดับเดียวกับ CrowdHandler และ Queue-it

Stack (กำหนดตายตัว — ห้ามเปลี่ยน)

Node.js >= 18 ตัวที่รันจริง (runtime) ต้องไม่มี dependency เลย: โค้ดใน server.js, lib/, snippet/ และ public/ ห้าม import package จาก node_modules ใช้ได้แค่ของที่มากับ node (node:http, node:crypto, node:fs, …) และ dependencies ใน package.json ต้องว่างเสมอ
Vitest ใช้รัน test ตอนพัฒนาเท่านั้น (อยู่ใน devDependencies และเป็น npm package ตัวเดียวที่อนุญาต) npm test → vitest run, npm run test:watch → vitest ตั้งค่าอยู่ใน vitest.config.js ไฟล์ test ใน test/*.test.js ใช้ globals ของ Vitest (describe/it/expect/beforeAll/afterAll) จึงไม่มีไฟล์ test ไหน import มันเลย การ ship หรือ deploy ผลิตภัณฑ์ไม่ติดตั้งมัน
รันเป็น process เดียว: node server.js ที่ port 8080 (env PORT)
ส่งข้อมูลแบบสด (realtime): ใช้ Server-Sent Events (SSE) ไม่ใช้ websocket
เก็บข้อมูล: production ใช้ STORE=valkey + SIDESTORE=pg (NODE_ENV=production ไม่ยอมใช้แบบอื่น): คิวที่กำลังทำงานอยู่ใน Valkey ทุกการเปลี่ยนแปลงบันทึกลง journal ใน Postgres แยกตาม room และข้อมูลอื่นทั้งหมดอยู่ใน Postgres ข้อมูลไม่หายเมื่อ restart ส่วน STORE=memory (development และ test) อยู่ใน process และไม่ใช้ดิสก์: ไม่เขียนอะไรลงดิสก์ และเริ่มจากว่างทุกครั้ง journal แบบไฟล์ (data/) ถูกเอาออกใน step 5
ลำดับของ event (QM-449 ข้อบังคับสำหรับระบบจริง): event ของแต่ละ room ต้องมีเลขลำดับต่อ room ที่เพิ่มขึ้นเสมอ เพื่อให้ตอน replay ตรวจเจอได้ว่ามี event หายหรือสลับลำดับ Valkey store ทำส่วนนี้แล้ว: ทุกแถวของ journal ใน Postgres มี seq ของ room และ rebuild ตรวจเจอช่องว่างได้ memory store ไม่มี journal
ยืนยันตัวตน admin: env ADMIN_KEY (ค่า default admin-dev) ส่งเป็น Authorization: Bearer <key>

ถ้าใช้ key ค่า default: เมื่อไม่ได้ตั้ง HOST server จะ bind 127.0.0.1 และถ้า HOST ไม่ใช่ loopback server จะไม่ยอม start
credential ของ admin แบบอื่น: operator key ที่มีชื่อ (qmo_…, role owner | operator | viewer ถ้า role ไม่พอได้ 403 insufficient_role), monitor token แบบอ่านอย่างเดียว และ session cookie ของ console qm_console (ดูด้านล่าง)
credential ที่ผิดถูกนับกับ ADMIN_AUTH_FAIL_PER_MIN ที่อยู่ที่ถูกล็อกจะได้ 429 too_many_auth_failures ก่อนที่ server จะอ่าน credential ใด ๆ ดู OPERATIONS.md หัวข้อ Two keys, two blast radii และ Operators, roles and the audit trail
credential ใน query string จะไปอยู่ใน access log, ใน header Referer และบน inline host (ที่ /__qm/* ถูกเขียนใหม่ก่อนตรวจสิทธิ์) ไปอยู่ใน access log และ log ของ CDN ของ ลูกค้า ดังนั้นไม่มี key ไหนถูกรับจาก URL เลย
route ของ SSE เป็นที่เดียวที่ EventSource ส่ง header ไม่ได้: POST /api/admin/sse-ticket (Bearer) คืน ticket ที่ใช้ได้ครั้งเดียว อายุ 30 วินาที หมดทันทีที่ใช้ ใช้ได้เฉพาะกับ credential ที่ขอมัน และนำไปใช้เป็น GET /api/admin/events?ticket=<t>
ลิงก์ monitor ที่แชร์ได้เก็บ viewer token ไว้ใน fragment ของ URL (ส่วนหลัง #) ซึ่งไม่มี browser ไหนส่งไปให้ server

Token: base64url(JSON) "." base64url(HMAC-SHA256) ความลับหลักมาจาก env SECRET (ค่า default สุ่มใหม่ทุกครั้งที่เริ่ม จำเป็นเมื่อใช้ SIDESTORE=pg) QM-352 มีสองแบบ ตรวจลายเซ็นทั้งสองแบบเสมอ:

แบบ	ลงลายเซ็นเมื่อ	key และกฎ
Legacy	เป็นค่า default	HMAC key คือ SECRET ไม่มี `kid` รับได้ทุกจุดประสงค์ที่เนื้อหา (payload) ผ่านการตรวจ
v2	`TOKEN_SIGN_V2=1`	key แยกตามจุดประสงค์ = HKDF-SHA256(SECRET, salt ว่าง, info เป็น `qm:visitor`, `qm:monitor`, `qm:session` หรือ `qm:operator`, 32 byte) payload มี `kid` = hex(HKDF-SHA256(SECRET, salt ว่าง, `qm:kid`, 4 byte)) `kid` ที่ไม่รู้จักถูกปฏิเสธ ใช้ข้ามจุดประสงค์ไม่ได้เด็ดขาด

SECRET_PREVIOUS ทำให้ SECRET ตัวก่อนยังตรวจผ่าน (ทั้งสองแบบ) ระหว่างเปลี่ยน key token ใหม่ใช้ SECRET ตัวตรวจของ operator ใช้กฎเดียวกัน และไม่เคยถูกลดจาก v2 ลงมา ดู OPERATIONS.md หัวข้อ Signing keys and rotating SECRET

เนื้อหา (payload) ของ visitor token (จุดประสงค์ visitor): {r, n, g, iat} สำหรับที่ในคิว หรือ {r, q, g, iat} สำหรับที่ใน pre-queue มี n หรือ q อย่างใดอย่างหนึ่งเท่านั้น ไม่มีทั้งคู่ v2 เพิ่ม kid

r room id
n หมายเลข ticket (จำนวนเต็ม >= 0 โดย 0 = pass แบบ bypass ที่ไม่ได้จองที่)
q หมายเลขอ้างอิงใน pre-queue (จำนวนเต็ม >= 1 ไม่ใช่ลำดับ)
g รุ่นของ room (generation, จำนวนเต็ม >= 1 room ที่ถูกลบแล้วสร้างใหม่ได้รุ่นใหม่ ticket เก่าจึงเอาที่ในคิวใหม่ไม่ได้)
iat เวลาที่ออก เป็น epoch ms

ถูกปฏิเสธเมื่อเกิน TOKEN_MAX_AGE_SEC (default 86400 ต่ำสุด 60) นับจาก iat หรือเมื่อ iat อยู่ในอนาคตเกิน 60 วินาที token ไม่ได้ เก็บสถานะว่ากำลังรอหรือผ่านแล้ว สถานะนั้นอยู่ใน engine โดยใช้ r+n เป็นตัวค้น จุดประสงค์อื่น (monitor, session, operator) มี payload ของตัวเอง และใน v2 ไม่มีทางถูกรับเป็น visitor token

ความเป็นเจ้าของไฟล์ (builder แต่ละคนอยู่ในเลนของตัวเอง)

Path	เจ้าของ
`server.js`, `lib/engine.js`, `lib/roomstore/`, `lib/token.js`	ผู้สร้าง engine
`public/waiting.html` (+ CSS/JS ในไฟล์)	ผู้สร้างหน้าของผู้เข้าชม
`public/admin.html` (+ CSS/JS ในไฟล์)	ผู้สร้าง dashboard
`snippet/qm.js`, `INTEGRATION.md`	ผู้สร้างส่วนเชื่อมต่อ
`test/*.test.js`	ผู้สร้างแต่ละคนเพิ่มของตัวเอง
`PROGRESS.html`, `SPEC.md`	ผู้ประสานงาน (orchestrator) เท่านั้น

แนวคิดหลัก

Room (หน้ารอหนึ่งห้อง): มี id, ชื่อ, URL ปลายทาง, ratePerMinute (อัตราปล่อยคนออก), maxConcurrent (ไม่บังคับ) และสถานะที่ตั้งไว้: active | paused | bypass (bypass = ปิดคิว ทุกคนผ่าน) room ที่ opensAt ยังอยู่ในอนาคต จะแจ้งผู้เข้าชมด้วยสถานะ ที่มีผลจริง scheduled ขณะที่สถานะที่ตั้งไว้ยังเป็นหนึ่งในสามค่านั้น รายการ room ฝั่ง admin แสดงทั้งสองค่า พร้อม opensAt และจำนวน preQueue
Visitor token: ลงลายเซ็นแล้ว เก็บ room id, หมายเลข ticket หรือ หมายเลขอ้างอิงใน pre-queue, รุ่นของ room และเวลาที่ออก (payload ตามข้างบน) ticket นั้นกำลังรอหรือผ่านแล้วเป็นสถานะใน engine ไม่ได้อยู่ใน token
Cookie ยืนยันเจ้าของ qms_<roomId>: session id แบบสุ่มที่อ่านความหมายไม่ได้ (16–128 ตัวอักษร) ตั้งเป็น HttpOnly คู่กับ token ตอน /api/join และผูกกับ ticket ใน engine (เก็บแค่ hash) token ที่ส่งมาจาก browser อื่นที่ไม่ได้ต่อคิวไว้ จะไม่ได้ที่ในคิวนั้น การ join ที่ไม่มี cookie นี้ จะได้ cookie ใหม่ ดู OPERATIONS.md หัวข้อ How a pass is bound to a visitor
ขอบเขตของ cookie คิว (QM-504, QM-526 ข้อบังคับ): cookie ต่อ room คือ qm_<roomId>, qms_<roomId> และ qm_dk_<roomId> ใช้ Path=/ ต่อไป ไม่แคบ Path ลง เพราะ connector บน origin ของลูกค้าอ่าน cookie เหล่านี้ที่ Path=/ และถ้าแคบลงจะเหลือ cookie ซ้ำกับของเดิมที่เป็น Path=/ แทนที่จะทำแบบนั้น host ของคิวเก็บ cookie ไว้ไม่เกิน 8 room ต่อ browser (ROOM_COOKIE_CAP) ถ้าเกิน cookie ของ room ที่เก่าที่สุดจะถูกทำให้หมดอายุใน response เดียวกัน ความเสี่ยงที่ยอมรับ (QM-539): หน้าเว็บที่พาผู้เข้าชมผ่านเกิน 8 room ทำให้ cookie ของ room เก่าของผู้เข้าชมคนนั้นถูกลบได้
รุ่นของ room (generation) g: เพิ่มขึ้นเมื่อ room ถูกลบแล้วสร้างใหม่ token จากรุ่นก่อน:

/api/join ไม่ยอมรับ (ผู้เรียกได้ที่ใหม่ในคิว)
/api/notify ตอบ 409 stale_ticket
/api/status และ event stream ตอบ {expired:true, reason:"room_reset"}

ความยุติธรรม: มาก่อนได้ก่อน (FIFO) ตามหมายเลข ticket อย่างเคร่งครัด กลับมาใหม่ได้ที่เดิม (token ใน cookie/localStorage คู่กับ cookie ยืนยันเจ้าของ) token หาย = ไปต่อท้ายคิว
ต่ออายุ token (QM-391): การรออาจนานกว่าอายุ token (TOKEN_MAX_AGE_SEC) และอายุ cookie ของคิว (QUEUE_COOKIE_MAX_AGE_SEC) โดยเฉพาะ pre-queue ที่ opensAt อีกหลายวัน

เมื่อ visitor token ที่ส่งมามีอายุถึงครึ่งหนึ่งของค่าที่สั้นกว่าในสองค่านี้ /api/status และ event stream จะลงลายเซ็นใหม่ให้ ที่เดิม ({r, n|q, g} กับ iat ใหม่ ลงลายเซ็นด้วยชุด key ที่ใช้อยู่ตอนนั้น v2 และ kid จึงเป็นไปตาม TOKEN_SIGN_V2) และตั้งทั้ง qm_<roomId> และ qms_<roomId> ใหม่ (session id เดิม)
ทำเฉพาะเมื่อครบทุกข้อ: room ยังมีอยู่และ g เป็นรุ่นปัจจุบันของมัน; ที่นั้นยังรออยู่ (สถานะไม่ใช่ expired และไม่ใช่ passed ที่ใน pre-queue ก็นับ); และ qms_<roomId> ของ request พิสูจน์ความเป็นเจ้าของที่นั้นใน engine ได้ fingerprint ตรงกันอย่างเดียวไม่มีสิทธิ์ต่ออายุ
/api/status คืน token ใหม่เป็น token stream ที่เปิดด้วย token ที่ถึงเวลาต่ออายุ จะส่ง token มาในทุก frame และตั้ง cookie ใน response ของมัน stream ที่เปิดอยู่แล้ว ถ้า token ถึงเวลาต่ออายุ จะถูกปิด เพื่อให้ browser ต่อใหม่และได้ token ใหม่
หน้ารอเก็บ token เฉพาะเมื่อมันระบุที่เดียวกับที่ถืออยู่แล้ว
token ที่เกิน TOKEN_MAX_AGE_SEC ไปแล้วยังถูกปฏิเสธเหมือนเดิม การต่ออายุชุบชีวิตมันไม่ได้

การปล่อยคนออก (outflow): engine ย้ายคนจากรอ→ผ่าน ratePerMinute คนต่อนาที อย่างสม่ำเสมอ (แบ่งเป็นช่วงวินาที ไม่ปล่อยทีละก้อน) ticket ที่ผ่านแล้วใช้เข้าเว็บปลายทางได้ภายใน passedTtlSec (default 600)
เปิดขายตามเวลา (scheduled drop): room ตั้ง opensAt ได้

ก่อนเวลานั้นยังไม่มีคิวเลย คนที่เข้ามาจะถูกเก็บไว้ใน pre-queue (คิวก่อนเปิด) และได้หมายเลขอ้างอิง ที่ไม่บอกความหมาย ไม่ใช่หมายเลข ticket
เมื่อถึง opensAt pre-queue ถูกจัดเป็นลำดับ FIFO ด้วยการสลับลำดับแบบสุ่มระดับ crypto เวียนไปทีละผู้ใช้ (round-robin) เพื่อไม่ให้ที่ที่สองของผู้ใช้คนหนึ่งได้ลำดับก่อนที่แรกของผู้ใช้คนอื่น
ลำดับที่สุ่มได้ถูกบันทึกไว้ ถ้า restart คร่อมเวลาเปิด ระบบจะใช้ลำดับเดิมซ้ำ ไม่สุ่มใหม่
preQueueMaxPerIp (default 16, null = ไม่จำกัด, 1..100000) จำกัดจำนวนที่ต่อผู้ใช้ การ join ที่เกินได้ 429 prequeue_identity_limit โดยไม่ได้ token หมายเลขอ้างอิง หรือ cookie กลับไป pre-queue ที่เต็มเพดานได้ 503 prequeue_full
กฎที่ต้องเป็นจริงเสมอ: ลำดับที่มาถึงใน pre-queue ต้องไม่สัมพันธ์กับลำดับที่สุ่มได้ มาก่อนไม่ได้เปรียบอะไร

Ticket ผี (ghost tickets) (QM-345): pass จะจองช่อง maxConcurrent ให้เฉพาะเจ้าของที่ระบบเห็นตัว (join, /api/status หรือ heartbeat ของ /events) ภายใน presenceSec (default 30, null = ปิดกฎนี้)

ticket ของเจ้าของที่ไม่อยู่ ยังถูกปล่อยตามลำดับ FIFO แต่ pass ของมันไม่มีช่อง (เป็น pass ที่เลยช่วงรับสิทธิ์ แต่ยังใช้ที่ประตูได้ภายใน passedTtlSec) และไม่นับเป็นการปล่อยคนออกตามเวลา
pass ที่เจ้าของยังไม่เคยรู้ว่าผ่านแล้ว จะคืนช่องเมื่อไม่เห็นตัวครบ presenceSec
event pass ใน log แสดง ticket เหล่านั้นใน ns เพื่อให้การเล่นซ้ำ (replay) คืนค่าแบบไม่มีช่อง
queueMaxPerIp (default 16, null = ไม่จำกัด, 1..100000) จำกัดจำนวนที่ในคิวที่กำลังรอต่อที่อยู่ของ client การ join ใหม่ที่เกินได้ 429 queue_identity_limit และไม่ได้อะไรที่ใช้ได้กลับไป
ticket ที่ไม่มีเจ้าของบันทึกไว้ (ผู้เรียกภายใน engine) ได้รับยกเว้นทั้งสองกฎ

HTTP API (contract — UI builder เขียนโค้ดตามนี้)

นโยบาย versioning

ทุก route ด้านล่างเรียกได้ที่ /api/v1/<route> (แบบหลัก ตรึงเวอร์ชันไว้) และ ที่ /api/<route> ที่ไม่มีเวอร์ชัน (ชื่อเรียกอีกชื่อที่ใช้ได้ตลอดไป ใช้ handler เดียวกัน ตอบเหมือนกันทุก byte) snippet ถูกติดตั้งบน origin ของคนอื่น ซึ่งอัปเกรดพร้อม server นี้ไม่ได้ มันจึงเรียก /api/v1/* และถ้า server ตอบ 404 กับ prefix นี้ จะถอยไปใช้ /api/* หนึ่งครั้งต่อหน้า

การเปลี่ยนที่ทำให้ของเดิมพังได้ ออกเป็น /api/v2/* ส่วน v1 คงรูปแบบเดิม field ที่เพิ่มแบบไม่บังคับ ยังอยู่ใน v1 ได้
ชื่อเรียกแบบไม่มีเวอร์ชัน ไม่ได้ ถูกเลิกใช้ และจะไม่ถูกลบ มันตาม contract ใหม่ล่าสุดเสมอ การเชื่อมต่อที่ตรึงเวอร์ชันจึงห้ามใช้มัน
ส่วนที่ไม่มีเวอร์ชัน (ไม่อยู่ใน contract): /healthz, /w/:roomId, /snippet/*, /, /progress, /metrics, /events (ชื่อเรียกเปล่า ๆ ที่ใช้ได้ตลอดไปของ route ใน contract /api/events ดู Visitor ด้านล่าง ที่ใส่ไว้ตรงนี้เพื่อให้ build ที่สร้างรายการ path จากหัวข้อนี้ไม่ทำมันหล่นหาย), /docs (+ /docs/:name ซึ่งแสดง INTEGRATION.md, OPERATIONS.md และไฟล์นี้ ให้คนที่เห็นแค่ server ที่รันอยู่ได้อ่าน), /docs/th (+ /docs/th/:name คู่มือชุดเดียวกัน เป็นภาษาไทยจาก docs/th/<file>)
ใช้ HTTP method ผิดกับ path ใน contract → 405 + header Allow + {"code":"method_not_allowed"}
preflight OPTIONS ใช้การตัดสิน CORS เดียวกัน กับ method จริง ต้องไม่ประกาศ origin ที่ response จริงจะปฏิเสธ

Visitor

POST /api/join {roomId, token?} → {token, position, ahead, etaSec, state} (ตั้ง cookie qm_<roomId> ที่เก็บ token และ cookie ยืนยันเจ้าของแบบ HttpOnly qms_<roomId>) token รุ่นเดียวกันใน body หรือ cookie ได้ที่เดิม (หมายเลขอ้างอิงใน pre-queue จะถูกแลกเป็น ticket ที่สุ่มได้เมื่อประตูเปิด) กรณีที่ถูกปฏิเสธ:

429 rate_limited (JOIN_LIMIT_PER_MIN)
400 invalid_room_id / invalid_token_field
404 room_not_found
403 blocked_by_protection (ระบบกันบอทของ room อยู่ในโหมด enforce)
429 queue_identity_limit, 429 prequeue_identity_limit
503 prequeue_full
503 storage_unavailable (บันทึกการ join ลง disk ไม่ได้ จึงไม่แจก ticket)

GET /api/status?token= → {position, ahead, etaSec, state, passed, redirectUrl?} token มาจาก ?token= (ไม่ใช้บน inline host) หรือ cookie qm_<roomId> ถ้าไม่มีอันไหนใช้ได้ → 401 invalid_token
GET /api/events?token= → SSE: event status ที่มี JSON แบบเดียวกับ /api/status ส่งเมื่อมีการเปลี่ยนแปลง และส่ง heartbeat ทุก 5 วินาที มีเวอร์ชันเหมือน route อื่นใน contract (/api/v1/events) และ ยัง เรียกได้ที่ /events เปล่า ๆ ซึ่งหน้ารอที่มากับระบบใช้อยู่ ชื่อนี้ใช้ได้ตลอดไป ไม่ใช่ของเก่า: หน้ารอทุกหน้าที่เปิดอยู่ใน browser ตอนนี้ถือ EventSource ที่ชี้มาที่นี่ และมันต่อใหม่เองหลัง restart หรือ deploy ถ้าลบ path นี้ ผู้เข้าชมที่อยู่ในคิวตอนนั้นจะพัง ซึ่งเป็นกลุ่มคนที่ผลิตภัณฑ์นี้มีไว้เพื่อพวกเขา ขีดจำกัดของ stream: 503 sse_capacity เมื่อครบ SSE_MAX_TOTAL stream และ 429 sse_per_ip_limit เมื่อครบ SSE_PER_IP ต่อที่อยู่ ทั้งสองมี Retry-After: 5

เฟรม refresh (QM-469) เมื่อ token ของ stream ถึงเวลาต้อง sign ใหม่ (TOKEN_REFRESH_AFTER_MS หลัง iat ของมัน คือครึ่งหนึ่งของค่าที่น้อยกว่าระหว่าง TOKEN_MAX_AGE_SEC กับ QUEUE_COOKIE_MAX_AGE_SEC) และการ refresh นั้นจะได้รับอนุญาต server จะส่ง event: refresh ที่มีข้อมูล {} แล้วปิด stream เพราะ stream ตั้ง cookie ไม่ได้หลังส่ง header ไปแล้ว หน้ารอจะเปิด stream ใหม่เองครั้งเดียว response ของ stream ใหม่จะ sign ที่ในคิวใหม่และตั้ง cookie ทั้งสองใหม่ จากนั้นเฟรม status จะมี token ใหม่ติดไปด้วย การปิดจะช้ากว่าเวลาที่ถึงกำหนด ด้วย jitter ที่คงที่ต่อที่ในคิว: uint32_be(sha256("r|n|q|g|iat")[0..4]) % (floor(TOKEN_REFRESH_AFTER_MS / 10) + 1) ms คำนวณจากช่องใน payload ของ token (ช่องที่ token ไม่มี เช่น q ของ ticket จะเป็นข้อความ undefined ตามที่ JavaScript แสดง) จึงช้าได้ไม่เกิน +10% ของช่วงเวลานั้น และคนที่ join พร้อมกันด้วย iat เดียวกันจะไม่ต่อใหม่พร้อมกัน ระบบที่ port ไปต้องส่งเฟรมเดียวกันและใช้ jitter แบบเดียวกัน stream ที่การ refresh จะไม่ได้รับอนุญาต จะไม่ถูกปิดเพราะเรื่องนี้

GET /w/:roomId → ส่ง waiting.html (ใส่ roomId + JSON ของแบรนด์เป็น window.QM_CONFIG) qm_return ที่นโยบายส่งกลับของ room ไม่อนุญาต จะถูกตัดทิ้ง ไม่ถูกใช้

style และ script หลักของหน้ารอเป็นไฟล์แยก ไม่ได้ฝังในหน้า (QM-467): GET /assets/waiting-<hash>.css และ /assets/waiting-<hash>.js บน inline host อยู่ใต้ /__qm/assets/… ด้วย <hash> คือ 22 ตัวแรกของ SHA-256 แบบ base64url ของไฟล์ ส่งพร้อม Cache-Control: public, max-age=31536000, immutable process หนึ่งส่งได้เฉพาะ hash ของ build ตัวเอง ดังนั้นเมื่อมีหลาย instance หรือระหว่าง rolling deploy ทุก instance ต้องส่งได้ทุก hash ที่ instance ใดก็ตามยังแจกอยู่ ดู OPERATIONS.md หัวข้อ Waiting-page assets and live streams across a deploy
ผู้เข้าชมที่มาพร้อม token ที่ไม่เป็นที่ในคิวแล้ว จะได้ lapsed ใน config นั้น: "expired" เมื่อช่วงเวลาเข้าของเขาเองหมด, "reset" เมื่อเป็นเพราะฝั่งเรา (eject, purge, รีเซ็ต room) และไม่มีค่านี้เมื่อไม่มีอะไรหาย ทั้งสอง deployment คำนวณค่านี้จากคำที่ engine ใช้บอกเหตุที่ปฏิเสธ และหน้ารอมีประโยคสำหรับแต่ละค่าในทุกภาษา ถ้าไม่มีค่านี้ ผู้เข้าชมจะได้ยินว่า ticket "could not be verified" ซึ่งบอกความผิดพลาดที่ไม่ได้เกิดขึ้น token ที่รู้ว่าหมดสภาพแล้ว จะถูกถือเหมือนไม่มี token ด้วย ระบบจึงออกที่ใหม่ที่หน้ารอสัญญาไว้ได้จริง รวมถึงผู้เข้าชมที่ไม่มี JavaScript ซึ่งไม่มีทางอื่นกู้คืน

POST /api/notify {token?, email?} → ลงทะเบียนแจ้งเตือนเมื่อถึงคิว (หรือถอนออก ถ้า email ว่างหรือไม่ได้ส่ง) ticket มาจาก token ใน body หรือ cookie ของคิว ไม่เคยมาจาก URL
การแจ้งเตือนเมื่อถึงคิวผูกกับ ticket ดังนั้นทุกครั้งที่ server เปลี่ยน ticket ให้ใหม่ มันจะย้ายข้อมูลไปด้วย ได้แก่ตอนสุ่มลำดับ pre-queue และตอน rejoin ด้วย ticket ที่ engine ไม่ยอมรับ client ส่ง token ที่ใช้ไม่ได้แล้วมาตอน rejoin ก็เพื่อเรื่องนี้โดยเฉพาะ ส่วน purge หรือ eject จะลบข้อมูลนี้ทิ้ง เพราะ operator ทิ้งที่ในคิวนั้นแล้ว
ด้วยเหตุนี้ POST /api/join จึงตอบ notify ด้วย เป็น {emailMasked, requestedAt, delivery} หรือ null บอกว่ามีอะไรผูกไว้กับที่ที่มันเพิ่งระบุ ถ้า EMAIL_NOTIFY ปิดอยู่ จะไม่มี field นี้เลย หน้ารออ่าน "ไม่มี field" ว่า "ไม่มีการบอก" และอ่าน null ว่า "ไม่ได้เก็บอะไรไว้" และเลิกบอกว่าบันทึกแล้วในเมื่อ server ไม่มีข้อมูลนั้น
ก่อนถึง opensAt /api/join และ /api/status ตอบ {state:"scheduled", scheduled:true, preQueued:true, preCount, opensAt, now} โดย position และ ahead เป็น null และ token มีหมายเลขอ้างอิง pre-queue q แทน ticket n
error ทุกตัวฝั่งผู้เข้าชมเป็น {error, code} ให้แยกกรณีด้วย code รายการเต็มของฝั่งผู้เข้าชม อยู่ใน INTEGRATION.md หัวข้อ Error codes
frame ไหนที่มีเวลาของ server ต้องมี now (เวลา server เป็น epoch ms) คู่มาด้วย เช่น opensAt ของการเปิดขายตามเวลา และ messageAt เมื่อ operator ตั้งข้อความ เวลาของ server เป็นเวลาเดียวที่ส่งถึงผู้เข้าชมโดยไม่อิงนาฬิกาของเครื่อง และหน้ารอแสดงทุกเวลาที่มันโชว์ ตามนาฬิกาของ เครื่องผู้เข้าชม (instant - (now - clientNow)) เพราะผู้เข้าชมเทียบกับนาฬิกานั้น ถ้าไม่มี now เครื่องที่นาฬิกาเพี้ยนจะเห็นการนับถอยหลังที่แก้ความเพี้ยนแล้ว คู่กับ "doors open at" ที่ยังไม่แก้ และสองค่านี้ไม่ตรงกัน frame ที่ไม่มีเวลาของ server ไม่ต้องมี now

Edge check (ใช้โดย snippet)

GET /api/check?roomId=&token=&url= → {action: "pass"|"queue", reason?, waitingRoomUrl?, clearToken?, sess?, targeting?, …} ได้ pass เมื่อ room เป็น bypass/ไม่ active หรือ ticket ของ token ผ่านแล้วและยังไม่หมดอายุ room ที่ไม่รู้จักได้ 200 {action:"pass", reason:"no_room"} (ปล่อยผ่านเมื่อพัง) และถูกนับให้ operator เห็นใน /api/admin/health และ /metrics คำตอบ pass ที่ปล่อยใครเข้า จะตอบก็ต่อเมื่อ บันทึกการปล่อยลง disk แล้ว ถ้าบันทึกไม่ได้ได้ 503 storage_unavailable และการปล่อยนั้นถูกยกเลิก เพื่อให้ลองใหม่แล้วได้เข้า
กุญแจ door-session sess: ได้มากับ pass ที่เปิด (หรือเอาคืน) door session และต้องส่งกลับมา ทุกครั้งที่ตรวจครั้งต่อไป ทางใดทางหนึ่ง:

header X-QM-Session (snippet ใช้วิธีนี้ เพราะ header ไม่ทำให้ credential ไปอยู่ใน URL และ log)
?sess=
บน inline host ใช้ cookie แบบ HttpOnly qm_dk_<roomId>

clearToken: true แปลว่าให้ลบ token และกุญแจที่เก็บไว้ก่อน redirect เพราะ body อาจมี sess บน room ที่มีนโยบาย origin /api/check (และ OPTIONS ของมัน) จะส่ง Access-Control-Allow-Origin ให้เฉพาะ origin ของ browser ที่อยู่ใน tag origins ของ room (tagOrigins ถ้าไม่มีใช้ returnOrigins บวก origin ของ targetUrl) ดู INTEGRATION.md หัวข้อ The door-session key

?ip=&agent= คือการรับรองตัวผู้เข้าชมจริง (connector ฝั่ง server และ edge) และต้องมี Authorization: Bearer <PUBLIC_API_KEY> (หรือ ADMIN_KEY) ถ้าไม่มีได้ 401 unauthorized หรือ 401 credential_in_query เมื่อส่ง key มาเป็น ?key= การตรวจแบบ vouched ถูกจำกัดอัตรา ต่อที่อยู่ที่รับรองไว้ ไม่ใช่ต่อ colo ที่เรียกมา
url= คือหน้าที่กำลังเปิด มันตัดสิน ขอบเขต: หน้านี้เป็นของ room นี้หรือไม่ ถ้าไม่มี ใช้ header Referer แทน ถ้าไม่มีทั้งคู่ ผลการตรวจเป็น unknown และ ส่งเข้าคิวไว้ก่อน (ไม่มีทางปล่อยให้ไม่มีการคุ้มกันแบบเงียบ ๆ) ?targeting=1 ใส่รายการกฎทั้งหมดของ room ใน response
หน้าที่กฎของ room ไม่รวมไว้ ตอบ {action:"pass", reason:"out_of_scope"} โดยไม่ออกที่ในคิว
targeting มีเฉพาะ room ที่มีขอบเขต: {rev, rules, scope:"in"|"out"|"unknown", rule, action} room ที่ไม่มีกฎจะไม่มี key นี้เลย และทำงานเหมือนก่อนมีการกำหนดเป้าหมาย URL ทุกอย่าง

Targeting (public ใช้โดย edge connector)

GET /api/targeting?roomId= → {roomId, rev, scoped, updatedAt, patterns:[{pattern, action}]} ขอบเขต URL ของ room เพื่อให้ connector แบบ Worker/Lambda/nginx ดึงกฎตอนรัน แทนการเขียนกฎตายตัวไว้ มี ETag + 304 จึงเรียกถามบ่อย ๆ ได้โดยใช้ทรัพยากรน้อย

Install check และ connector registry (public)

GET /api/verify?roomId=&url=&origin=&connector=&version= → {ok, checks:[{id, status:"pass"|"fail"|"warn"|"info", title, detail?, fix?}], …} การตรวจก่อน deploy ที่ CLI หรือหน้าตั้งค่าของ connector ทุกตัวรัน

origin ถ้าไม่ส่ง ใช้ origin ของ url ถ้าไม่มีอีก ใช้ header Origin ของ request
ส่ง Public API key แบบ Bearer แล้วรายงานจะละเอียดขึ้น (ตรวจ key ด้วย) key ที่ส่งมาใน ?key= จะถูกรายงานเป็นข้อที่ไม่ผ่าน
ไม่มี roomId → 400 invalid_room_id
การตรวจถูกบันทึกไว้ให้รายการ "connectors that checked in" ใน console ดู INTEGRATION.md หัวข้อ Installable connectors

GET /api/verify.gif?roomId=&origin=&connector= → ผลเดียวกันแต่บอกเป็น status code สำหรับ sandbox ของ GTM ที่รู้ได้แค่ว่าภาพโหลดสำเร็จหรือไม่: 200 image/gif เมื่อ ok ไม่อย่างนั้น 424 {ok:false, error:"verify_failed", checks} X-QM-Verify บอก id ของข้อที่ไม่ผ่าน Cache-Control: no-store
GET /api/connectors → registry: เวอร์ชันของ connector แต่ละตัว คำสั่ง install/upgrade/verify URL ดาวน์โหลด และ SHA-256 สำหรับตรวจความถูกต้อง ตามที่ server นี้ ให้บริการ GET /api/connectors/wordpress/update → ข้อมูลเดียวกันในรูปแบบที่ตัวอัปเดต plugin ของ WordPress ใช้ ตัวไฟล์อยู่ใต้ /connectors/<name>/latest.{js,tgz,zip} (ไม่มีเวอร์ชัน)
/api/verify, /api/verify.gif และ /api/connectors ใช้โควตา CHECK_LIMIT_PER_MIN ร่วมกัน (429 rate_limited)

Health (public ไม่ต้อง authenticate)

GET /healthz, GET /api/health → ข้อมูลความพร้อม ตอบ 503 เมื่อ instance ไม่ ready (เช่น บันทึกการ join ไม่ได้) นอกนั้น 200 GET /api/version → ข้อมูลเดียวกัน ตอบ 200 เสมอ ไม่ถูกตัดทิ้งเมื่อ connection เต็มเพดาน ดู OPERATIONS.md หัวข้อ Readiness

POST /api/admin/session {key} พร้อม header X-QM-CSRF: 1 → ลงชื่อเข้า console: ตั้ง qm_console (HttpOnly, SameSite=Strict, Path=/api/admin, 12 ชม.) ซึ่งเป็นตัวอ้างอิง session ที่ลงลายเซ็นแล้วและไม่มี key อยู่ข้างใน ตอบ {ok, name, role, expiresInSec} DELETE /api/admin/session (header เดียวกัน) ลบ cookie และเพิกถอน session ฝั่ง server request ที่มี cookie แต่ไม่มี header Authorization ต้องส่ง X-QM-CSRF ในทุก method ที่ไม่ใช่ GET ไม่อย่างนั้นได้ 403 csrf_required request ที่มี Authorization ถูกตัดสินจาก header นั้นอย่างเดียว ดู OPERATIONS.md หัวข้อ Two keys, two blast radii
สิทธิ์:

ผู้ใช้	ทำอะไรได้
`viewer` และ monitor token	อ่าน (rooms, events, metrics, health, security, reports, สถานะ alert, audit) แต่ monitor token อ่าน audit, visitors และ targeting ไม่ได้
`operator`	ทุกอย่างของ viewer + เปลี่ยนสถานะคิวและการตั้งค่า room
`owner`/`ADMIN_KEY`	ทุกอย่างของ operator + จัดการ operator, ลบ room และสั่งหยุด server

GET /api/admin/operators, POST /api/admin/operators {name, role} → คืน key ครั้งเดียว DELETE /api/admin/operators/:id เพิกถอน ไม่มี route ไหนเปลี่ยน role ของ operator ที่มีอยู่แล้ว
GET /api/admin/audit → ใครทำอะไร เมื่อไร จากที่ไหน GET /api/admin/security → คะแนนการกันบอท และการปฏิเสธ GET /api/admin/reports?roomId=&bucket=hour|day → ข้อมูลย้อนหลัง (มี CSV ให้ใช้กับ BI)
GET /api/admin/alerts → สถานะ alert POST /api/admin/alerts ส่งการแจ้งเตือนทดสอบ (400 alerts_disabled ถ้าไม่มี ALERT_WEBHOOK_URL, 502 webhook_failed ถ้า webhook ปฏิเสธ)
POST /api/admin/shutdown → {ok, stopping, uptimeSec} แล้วหยุดอย่างเรียบร้อย (วิธีหยุดที่เขียนไว้ในเอกสารสำหรับ Windows) เฉพาะ owner
POST /api/admin/sse-ticket → ticket ใช้ครั้งเดียว อายุ 30 วินาที สำหรับ GET /api/admin/events?ticket=
GET /api/admin/rooms → รายการ room พร้อมสถิติสด {waiting, passedLastMin, rate, state, oldestWaitSec}

estWaitSec คือเวลารอของผู้เข้าชมที่เข้าคิว ตอนนี้ และเป็นตัวเลขที่ room ยืนยันได้จริงเท่านั้น
room ที่ไม่ได้ปล่อยใครเลย (paused, ratePerMinute: 0 หรืออัตราปล่อยที่วัดได้เป็นศูนย์) รายงาน null (ไม่มีขอบเขต) ไม่ว่าจะมีคนรออยู่หรือไม่
room ที่ประตูยังปิด รายงานเวลาที่เหลือก่อนเปิด บวกเวลาปล่อยคนที่ถือ ticket อยู่แล้ว ซึ่งเป็นผลรวมเดียวกับที่ /api/status บอกผู้เข้าชมที่กำลังรอ พร้อม estWaitFloor: true การสุ่มลำดับเป็นตัวตัดสินว่าที่ใน pre-queue ต้องรอนานกว่านั้นเท่าไร จึงไม่บวกอะไรเพิ่มให้
0 แปลว่า room จะปล่อยเข้าทันที

POST /api/admin/rooms สร้าง/แก้ room field ที่เขียนได้มีเท่านี้พอดี: {id, name, targetUrl, proxyOrigin?, ratePerMinute, maxConcurrent?, passedTtlSec?, sessionTtlSec?, sessionMaxSec?, branding?, returnOrigins?, tagOrigins?, autotune?, protection?, autoActivate?, urlPatterns?, opensAt?, preQueueMaxPerIp?, queueMaxPerIp?, presenceSec?, state?, onBackendDown?}

เก้าตัวที่ไม่ได้ชัดเจนในตัว อธิบายไว้เพราะแต่ละตัวคือความสามารถทั้งชุดที่เข้าถึงได้ผ่าน body นี้เท่านั้น:

proxyOrigin: โหมด inline (ที่อยู่ภายในที่ server นี้ส่งผู้เข้าชมที่ผ่านแล้วต่อไป)
sessionTtlSec / sessionMaxSec: ขีดจำกัดของ door session
autotune: ตัวปรับอัตราปล่อยคนอัตโนมัติ
protection: โหมดให้คะแนนบอท ({mode:"off"|"monitor"|"enforce"})
autoActivate: เปิดใช้คิวอัตโนมัติเมื่อถึงเกณฑ์
opensAt และ preQueueMaxPerIp: การเปิดขายตามเวลา และเพดานต่อผู้ใช้ของ pre-queue
queueMaxPerIp และ presenceSec: เพดานต่อที่อยู่ของคิวที่กำลังรอ และช่วงเวลายืนยันว่ายังอยู่ (ดู แนวคิดหลัก, Ghost tickets)
state: ตั้ง active/paused/bypass ในการเขียนครั้งเดียวกับค่าอื่น

onBackendDown ("closed" ซึ่งเป็น default หรือ "open") คือสิ่งที่ gate ของ room แบบ inline ทำระหว่างที่ backend ล่ม (ติดต่อ Valkey ไม่ได้ หรือ room กำลังถูกสร้างใหม่จาก journal): closed ตอบ browser navigation ด้วยหน้ารอใน retry mode (503 + Retry-After ไม่มีการรับคิว) และตอบ request อื่นด้วย 503 storage_unavailable ส่วน open ส่งต่อไปที่ proxyOrigin โดยไม่ผ่านคิว ค่าอื่นได้ 400 invalid_on_backend_down เมื่อใช้ STORE=memory ค่านี้ถูกเก็บไว้ แต่ไม่มีผล เพราะไม่มี backend ให้หาย
redacted: true ถูกปฏิเสธด้วย 400 redacted_shape แทนที่จะถือเป็น field ที่ไม่รู้จัก room ที่อ่านผ่านลิงก์ monitor ที่แชร์ จะกลับมาโดยลบที่อยู่ภายใน รายชื่อ origin ที่อนุญาต และกฎ URL ออก ถ้าส่ง body นั้นกลับไปตรง ๆ ค่าทั้งหมดนั้นจะถูกล้าง error นี้จึงบอกเรื่องนั้นแทนการบอกชื่อ field
รับ rate เป็นชื่อเรียกอีกชื่อของ ratePerMinute เพราะ GET /api/admin/rooms เรียก field เดียวกันนี้ว่า rate การอ่าน-แก้-เขียนกลับจึงไม่ต้องเปลี่ยนชื่อ ส่งทั้งสองได้ถ้าค่าตรงกัน ถ้าส่งทั้งสองแต่ค่าต่างกัน ได้ 400 conflicting_field ชื่อ field ใดที่ไม่อยู่ในรายการได้ 400 unknown_field ไม่ถูกข้ามแบบเงียบ ๆ เมื่อก่อนการพิมพ์ผิดตรงนี้ดูเหมือนแก้สำเร็จทุกอย่าง แต่ไม่มีอะไรเปลี่ยน
returnOrigins คือที่ที่ผู้เข้าชมที่ถึงคิวแล้ว ถูกส่งไป ได้ tagOrigins คือหน้าที่ อ่าน ผลการตรวจที่ประตูได้ (รายชื่อ CORS ของ browser) origin ของ targetUrl ของ room อยู่ในทั้งสองเสมอ tagOrigins: null (default) ใช้ตาม returnOrigins room ที่ตั้งไว้ก่อนแยกสองค่านี้จึงเหมือนเดิม ต้องแยกกันเพราะผิดแล้วพังคนละทาง: นโยบายส่งกลับที่ผิดคือ open redirect ส่วน tag origin ที่ขาดไป ทำให้หน้านั้นเปิดโดยไม่ต้องต่อคิวเลยแบบเงียบ ๆ
urlPatterns คือขอบเขตของ room เป็นการตั้งค่าที่เปลี่ยนได้ขณะระบบทำงาน: ไม่เกิน 25 กฎ กฎละไม่เกิน 300 ตัวอักษร และ wildcard * ไม่เกิน 10 ตัว กฎขึ้นต้นด้วย / (path), * (ที่ไหนก็ได้) หรือ https://host/path เต็ม (ระบุ origin) ! ข้างหน้าทำให้เป็นข้อยกเว้น ตัวพิมพ์เล็กใหญ่ถือว่าเหมือนกัน กฎที่ไม่มี ? เทียบกับ path อย่างเดียว ข้อยกเว้นชนะเสมอ ไม่ว่าจะเรียงไว้ลำดับไหน กฎที่ผลขึ้นกับลำดับทำให้ operator พลาดง่าย ไม่ใช่ข้อดี [] แปลว่าไม่มีขอบเขต: ทุกหน้าที่มี tag ต้องต่อคิว
branding.message คือข้อความของ operator ถึงผู้เข้าชมที่รออยู่ server ประทับเวลา branding.messageAt เมื่อข้อความเปลี่ยน และหน้ารอแสดงข้อความในกรอบที่มีเวลากำกับ ใน ทุก สถานะ รวมถึงตอนนับถอยหลังของการเปิดขายตามเวลา

DELETE /api/admin/rooms/:id
POST /api/admin/rooms/:id/state {state} (active/paused/bypass)
POST /api/admin/rooms/:id/rate {ratePerMinute} (รับ rate เป็นชื่อเรียกอีกชื่อ กฎเดียวกับข้างบน) มีผลทันที
POST /api/admin/rooms/:id/flush ปล่อย N คนเดี๋ยวนี้ {count}
POST /api/admin/rooms/:id/schedule {opensAt?, preQueueMaxPerIp?} ตั้ง/ล้างเวลาเปิดประตู ใช้เฉพาะ field ที่ส่งมา: ส่ง preQueueMaxPerIp อย่างเดียวคือปรับเพดาน และการเปิดขายยังตั้งเวลาไว้เหมือนเดิม ยกเลิกการเปิดขายต้องส่ง {"opensAt": null} อย่างชัดเจน body ที่ไม่มีทั้งสอง field ได้ 400 nothing_to_change ไม่ถูกข้ามแบบเงียบ ๆ
POST /api/admin/rooms/:id/eject {ticket} เพิกถอน pass ปิด session ที่เปิดอยู่ แล้วส่งไปท้ายคิว
POST /api/admin/rooms/:id/purge ทิ้งคนที่รออยู่ทั้งหมด โดยไม่ปล่อยใครเข้า

ใช้กับ room ที่งานจบไปแล้ว: ระบบเก็บคิวไว้ข้ามทุกการ restart และเมื่อก่อนทางออกเดียวคือลบ room
ไม่ออก pass และไม่บันทึกการปล่อยคน กราฟจึงไม่มียอดพุ่งที่ไม่ได้เกิดขึ้นจริง
ticket ที่ถูกทิ้งอ่านได้เป็น expired ส่วน room การตั้งค่า และประวัติยังอยู่
pre-queue ของ room ที่ตั้งเวลาไว้ถูกล้างด้วย
ตอบ {purged, stats} เมื่อบันทึกการทิ้งลง disk แล้ว (503 storage_unavailable ถ้าบันทึกไม่ได้) purged นับรวมที่ใน pre-queue ซึ่งแจ้งแยกไว้เป็น preQueue ด้วย

GET /api/admin/rooms/:id/visitors?ticket= หรือ ?ref= → ค้นผู้เข้าชมรายคนสำหรับงาน support (สถานะ ลำดับ อายุต่าง ๆ session การผูก เป็น digest ทางเดียวเท่านั้น ไม่มีตัวระบุดิบ) ref= แปลงรหัสสั้นที่หน้ารอแสดงให้ผู้เข้าชมเห็น ข้อความที่เขาอ่านให้ฟังทางโทรศัพท์จึงเป็นข้อความเดียวกับที่ใส่ในช่องค้น ถ้ารหัสตรงกับหลาย ticket จะคืนรายการ ticket ที่เป็นไปได้ ไม่เดา
GET /api/admin/rooms/:id/targeting?url= → กฎของ room พร้อม {matchCount, lastMatchedAt} ต่อกฎ และจำนวนการตรวจที่ไม่ตรงกฎไหน กับการตรวจที่มาโดยไม่มี URL url= (ไม่บังคับ) คือ การลองดู (dry run): กฎไหนจะชนะ โดยไม่แตะตัวนับ กฎที่ไม่เคยตรงเลยคืออาการที่มองเห็นได้ของ room ที่ชี้ไปผิดหน้า
GET /api/admin/events → SSE สถิติทุก 2 วินาทีของทุก room {rooms:[...], totals, sparkline data}

เฟรม delta (QM-468) ส่งเฟรมเต็ม (ไม่มีคีย์ delta) ตอนต่อ และอีกครั้งใน tick ถัดไป หลังจากนั้น แต่ละ tick เป็น {delta:true, rooms:[room ที่เปลี่ยน], removed:[ids], totals, …} คือเฉพาะ room ที่สถิติเปลี่ยนตั้งแต่ tick ก่อน กับ id ของ room ที่หายไป และคีย์อื่นเหมือนเฟรมเต็ม room ที่เปลี่ยน แทนที่ของเดิม room ใหม่ต่อท้าย (ลำดับของ server คือลำดับที่สร้าง) room ที่ถูกลบก็เอาออก tick ที่ลำดับ room เปลี่ยนจะส่งเป็นเฟรมเต็ม (QM-480) client ที่ได้ delta โดยยังไม่มีเฟรมเต็มอยู่ก่อน ต้องต่อใหม่ นั่นคือวิธี resync

GET /api/admin/metrics?roomId=&range= → ข้อมูลตามเวลา (joins/min, passes/min, ความยาวคิว) สำหรับกราฟ
GET /api/admin/health → การตั้งค่าที่มีผลจริง สถานะ storage คำเตือนเรื่องตั้งค่าผิด
POST /api/admin/monitor-token → ออก credential monitor แบบอ่านอย่างเดียว (ดูได้อย่างเดียว ไม่ใช่ ADMIN_KEY เด็ดขาด) GET แสดงลิงก์แชร์ที่ยังใช้ได้ (เป็นการอ่าน แต่ monitor token เองเรียกไม่ได้) DELETE ?id= เพิกถอนหนึ่งลิงก์ (?all=1 ทั้งหมด)
GET /metrics → ข้อมูลแบบ Prometheus ต้องมี credential สำหรับอ่าน (monitor token, viewer ขึ้นไป เพราะ room id และความยาวคิวเป็นข้อมูลลับทางธุรกิจ)
GET / → admin.html GET /progress → PROGRESS.html GET /docs → คู่มือ

เกณฑ์คุณภาพ (สิ่งที่ critic ใช้ตัดสิน)

หน้ารอ: สงบ มีแบรนด์ ลำดับแบบสด + เวลารอที่ตรงไปตรงมา แถบความคืบหน้า ใช้ได้กับทุกคน (ลดการเคลื่อนไหว, aria-live) ใช้บนมือถือได้ refresh หรือปิดแท็บแล้วไม่หาย redirect เองเมื่อผ่าน หน้าไม่กระตุก รับมือตอน offline/ต่อใหม่ได้
Dashboard: กราฟความยาวคิวแบบสด ปุ่มคุม room แต่ละห้องมีผลทันที เห็นคนแห่เข้ามาได้ในแวบเดียว ใช้ด้วยคีย์บอร์ดได้ ใช้ธีมมืดได้ ไม่มีข้อมูลปลอม
Engine: join พร้อมกัน 10k ครั้งต้องไม่ล่มและไม่สลับลำดับ ต้องเป็น FIFO เสมอ เปลี่ยนอัตรากลางช่วงคนแห่ ต้องมีผล restart กลางช่วงคนแห่ต้องไม่มีอะไรหาย (STORE=valkey)
ทุกส่วน: ไม่มี error ใน console ไม่มีปุ่มที่กดแล้วไม่ทำอะไร ไม่มีข้อความ lorem ipsum