QnA Init Docs — UC_8.2.8 (Flow 11

UC liên quan: UC_8.2.8 — Flow 11: Waitlist Processor Trigger: Một Pod Leader Active có thêm suất trống (4 sự kiện — POD-WAIT-18) Agent tạo: Agent 1 (Auditor) + Agent 2 (Challenger), theo system_init_workflow.md — Init Flow Ngày tạo: 2026-10-12 · Phiên bản: v1 BA phụ trách: Anh Hoang Ghi chú: Thay thế bản QnA_init_docs 2026-10-09/12 (đã xoá cùng UC cũ). Giữ nguyên ID cũ (A-, C-, N-) để truy vết BA chốt. Câu đã chốt gom vào §1; §3 chỉ còn câu mở. Phân chia sở hữu: UC_8.2.1 §4.1 — UC này sở hữu vòng đời status pod của trader.

0. Compliance Checklist (Agent 1 — Auditor)

#	Hạng mục	Kết quả	Ghi chú
1	Source pre-flight	✅	CR: `CR-20260818-001` (Flow 7 mentee rời → giảm `Current_Count` → Flow 11). QnA: `POD-WAIT-*` round 1–3 (v1.7). Nguồn gốc: Zapier Integration V7.pdf §Flow 11, §Flow 12, §Flow 15A/15B · RFQ_ Stack Trading Prop Tech V7.pdf §Process Waitlist Queue
2	CR-08 Timestamp	✅	`Join_Date`, thời điểm gửi lời mời, mốc 48 giờ
3	CR-18	✅	Bấm xác nhận trùng (`POD-WAIT-21`)
4	CR-15.2 Slack	✅	Flow 11 không có Slack alert
5	WBS	✅	`UC_8.2.8`, category STAGE 6
6	`[MISSING_DEPENDENCY]`	⚠️	Flow 15A (`UC_8.2.9`), Flow 15B (`UC_8.2.10`) chưa có SRS; Flow 12 không có UC riêng
7	`[CROSS_UC_CONFLICT]`	⚠️	UC_4.14.2 chưa có các status mới — xem N-03

1. Đã chốt — không hỏi lại

ID	Nội dung đã chốt	Nguồn
Q-01	Waitlist xét theo leader vừa có suất trống, áp waterfall Flow 10: Asset (bắt buộc) → Style (ưu tiên, theo danh sách Style của leader) → FIFO theo `Join_Date`	`POD-WAIT-02/10`, A-15
Q-02	Waitlist là hàng chờ thật, FIFO theo `Join_Date`; status `Waitlist`; cách lưu do BE quyết	`POD-WAIT-01/15`, A-09
Q-03	Không ai cùng Asset → suất để trống	`POD-WAIT-10`
Q-04	Waitlist không hết hạn, không hậu quả tự động; Ops tự lo nguồn cung leader	`POD-WAIT-14`
Q-05	Dashboard không hiển thị vị trí, thời gian chờ, bước xác nhận suất	`POD-XF-08`, UC_4.14.2 BR_4.14.2.5
Q-06	4 sự kiện kích hoạt Flow 11: `Current_Count` giảm · leader mới `Active` · Ops tăng `Max_Capacity` · leader `Suspended` → `Active` còn suất. Flow tạo ra sự kiện gọi Flow 11 ngay sau đó	`POD-WAIT-06/18`, A-01, A-12
Q-07	Leader `Suspended` / `Terminated` → cả pod bị rã qua Flow 15A; Flow 11 không mời ai vào pod đó	A-13
Q-08	Mỗi suất trống gọi `POST /process-waitlist-queue` 1 lần, mỗi lần trả 1 trader (`next_candidate_id` = UUID trader khớp cũ nhất); bắt buộc row-locking	`POD-WAIT-07/17`, C-02
Q-09	Giữ chỗ: khi mời, Middleware tăng `Current_Count` ngay + status `Waitlist` → `Pending_Pod_Confirmation`. Flow 10 giữ nguyên (thấy suất trống ⇒ waitlist không có ai phù hợp)	`POD-WAIT-03/04`, A-02, A-03
Q-10	Hệ thống gửi payload `Pod_Spot_Available_Confirm` tới Klaviyo API; Klaviyo gửi email + theo dõi bấm link. Khác `Pod_Waitlist_Notification` (lúc vào hàng) và `Pod_Assignment_Confirmation` (sau khi vào pod)	`POD-WAIT-16`, A-14, A-18
Q-11	Link xác nhận: dùng 1 lần, hết hạn 48 giờ, không bắt đăng nhập	A-07
Q-12	Bấm link — kiểm tra lại: trader `Failed`/`Terminated` hoặc Level ≥ 7 → từ chối, hiện `This invitation is no longer valid`, giảm `Current_Count` → Flow 11 chạy lại. Leader không còn `Active` → chạy matching Flow 10; không có suất → `Waitlist` đầu hàng. Đạt → `Assigned`, gửi `Pod_Assignment_Confirmation`, gán Discord role, không tăng `Current_Count` lần nữa	`POD-WAIT-19`, A-06
Q-13	Bấm trùng / Klaviyo bắn trùng → đọc status đã cập nhật và drop (CR-18)	`POD-WAIT-21`, A-08
Q-14	Không bấm trong 48 giờ → status `Waitlist_Ghost` (rời waitlist) + giảm `Current_Count` → Flow 11 chạy lại	`POD-WAIT-05`, A-04
Q-15	`Inactive_Hold` khi đang chờ: giữ bản ghi + `Join_Date`, bị bỏ qua khi chọn; Reactivate → về `Waitlist` đúng vị trí cũ	`POD-WAIT-12` (partial), A-10 (phần đã chốt)
Q-16	Zombie kích hoạt lại khi pod cũ đầy → giữ `Join_Date` gốc (email SES-30 đã sửa thành "you will resume your position on the waitlist.")	`POD-WAIT-20`, C-03 (thay `POD-WAIT-13`)
Q-17	Mentee vào waitlist vì leader bị terminate (Flow 15A không ghép được) → cuối hàng, tính từ lúc vào hàng	C-04, A-11
Q-18	`Pod_Waitlist_Notification` gửi 1 lần mỗi khi vào hàng, cho cả 3 cách vào hàng (Flow 10, 15A, 12); không gửi định kỳ	A-16
Q-19	Chỉ Middleware ghi `Current_Count`	A-17 (phần đã chốt)
Q-20	Webhook no-op → common rule CR-18	P-01

2. Câu cũ đã chuyển sang UC khác (không hỏi ở đây)

ID cũ	Nội dung	Chuyển sang
A-17 (phần reconcile)	Job đối chiếu `Current_Count`	UC_8.2.1 A-12
N-04	Trader `Waitlist_Ghost` gửi lại form Flow 10	UC_8.2.1 A-02

3. Câu hỏi còn mở (Agent 2 — Challenger)

ID	Câu hỏi	Giả định (BA/QC đề xuất)	BA chốt (ưu tiên cao nhất)	Trạng thái
N-01	Ai đếm 48 giờ và chạy nhánh Ghost? Zapier Integration V7.pdf Flow 11 ghi IF No Click: Klaviyo triggers the removal and signals the system to move to the next oldest — cần làm rõ Klaviyo báo về Middleware bằng cách nào. Nhánh Ghost ghi DB (đổi status, giảm `Current_Count`) — chỉ Middleware được ghi `Current_Count`; Klaviyo không có sẵn sự kiện "không bấm sau 48 giờ" để báo về.	Middleware tự đếm: lưu thời điểm gửi lời mời, job định kỳ (mỗi giờ) chuyển lời mời quá 48 giờ sang Ghost. Không phụ thuộc Klaviyo.		⏳ Chờ BA 🔴
N-02	Trader bấm link thì thấy gì, ở đâu? Khách muốn hiện `This invitation is no longer valid` ⇒ phải có trang hiển thị; nhưng `POD-WAIT-08` mô tả click là Klaviyo bắn webhook (không hiện gì). Cần chốt: link trỏ về đâu; trang kết quả ở đâu; nội dung cho từng ca (thành công · link hết hạn / đã dùng · được ghép leader khác · về hàng chờ · bị từ chối).	Link trỏ về trang kết quả đơn giản của Stack Trading (không cần đăng nhập), Sotatek build; khách đưa copy từng ca. Khách trả lời 2026-10-22 (một phần): bấm sau 48 giờ (VD giờ thứ 49) → chặn, coi như hết hạn. Trang hiển thị và nội dung từng ca: vẫn mở.		⏳ Chờ BA 🔴
N-03	Status mới vs thẻ My POD (UC_4.14.2). `pod_status` của `Get Pod Data` chỉ có `Assigned` · `Waitlist` · `null` · `SUSPENDED_DEFENSE` · `Locked`. (1) `Active_Pod_Member` có chính là `Assigned`? (2) Thẻ hiện gì cho `Pending_Pod_Confirmation`, `Waitlist_Ghost`?	(1) Là một — dùng 1 giá trị. (2) `Pending_Pod_Confirmation` → Pending Mentor Allocation; `Waitlist_Ghost` → Unassigned (nút [Join a POD]).	(1) ✅ Khách chốt 2026-10-13 (`POD-WAIT-22`): cùng một status — dùng `Assigned`, bỏ `Active_Pod_Member`. (2) còn mở. (2) `Waitlist_Ghost`: khách chốt 2026-10-22 — xử lý như Unassigned, thẻ My POD hiện [Join a POD], vào lại bằng form Style Flow 10. `Pending_Pod_Confirmation`: còn mở.	⏳ Chờ BA 🟠
N-05	"Đầu hàng" nghĩa là gì? (Q-12 — leader không còn `Active` lúc bấm, không có suất khác.) Tuyệt đối đầu hàng hay về vị trí cũ theo `Join_Date`? Có gửi lại `Pod_Waitlist_Notification`?	Về vị trí cũ theo `Join_Date` (nhất quán Q-16). Không gửi lại email.	Không phải đầu hàng. Trader về cuối hàng, xếp theo `Join_Date` là thời điểm trader về waitlist. BA chốt 2026-11-09 (khác `POD-WAIT-19` ghi "đầu hàng"). Đã áp vào UC E_8.2.8.12, BR_8.2.8.2.	✅ Đã chốt
N-06	Zombie đang ở pod (chưa từng ở waitlist) kích hoạt lại khi pod cũ đầy → "giữ `Join_Date` gốc" nhưng trader không có `Join_Date` waitlist. Dùng ngày nào?	⚠️ No safe default — hỏi khách. Gợi ý: ngày trader gửi form Style lần đầu (Flow 10).	`pod_join_date` (ngày vào pod) khác `Join_Date` (ngày vào waitlist); vào waitlist không đổi `pod_join_date`. Trader đang ở pod bị Zombie rồi kích hoạt lại → chạy lại ghép pod Flow 10, không ưu tiên pod cũ (chỉ về pod cũ nếu tình cờ được chọn); không có leader còn suất → vào waitlist cuối hàng, `Join_Date` = thời điểm vào waitlist. BA chốt 2026-11-09. Đã áp vào UC BR_8.2.8.2, UC_4.14.2, UC_4.17.1.	✅ Đã chốt
N-07	Sau khi bị từ chối lúc bấm (Q-12): status thành gì, có rời waitlist không? Trader `Pending_Pod_Confirmation` vào `Inactive_Hold` trong 48 giờ thì sao?	Bị từ chối → rời waitlist, status pod rỗng. `Inactive_Hold` trong 48 giờ → xử lý như không bấm (Q-14).	Theo giả định. Bị từ chối → status pod `null`, rời waitlist. Bị Flow 12 quét trúng khi đang `Pending_Pod_Confirmation` → `Waitlist_Ghost` ngay lúc Flow 12 chạy, `Current_Count` giảm 1 lần duy nhất. BA chốt 2026-11-09. Đã áp vào UC E_8.2.8.10, E_8.2.8.11, BR_8.2.8.4.	✅ Đã chốt
N-08	Ops tăng `Max_Capacity` / đổi leader Suspended → Active bằng công cụ gì? `[POD-JOIN-18]` `[POD-XF-05]` Sửa tay DB thì không có gì gọi Flow 11 (Q-06).	Ops sửa qua 1 thao tác BPS do Sotatek build; thao tác đó gọi Flow 11 ngay sau khi lưu. Khách ghi 2026-10-22 (câu hỏi giảm `Max_Capacity`): Ops tăng `Max_Capacity` bằng cách sửa trực tiếp trong DB, "the system must trigger the processor" — chưa nói cơ chế kích hoạt, vẫn mở. Giảm `Max_Capacity`: không đẩy mentee ra, chờ tự giảm (đã viết vào UC BR_8.2.8.1).		⏳ Chờ khách 🟠
N-09	🆕 Gửi lời mời sang Klaviyo bị lỗi (Klaviyo API lỗi / timeout) sau khi đã giữ chỗ → trader không nhận email nhưng 48 giờ sau vẫn bị đánh Ghost.	Klaviyo lỗi → retry 3 lần; vẫn lỗi → huỷ giữ chỗ: giảm `Current_Count`, trả trader về `Waitlist` (giữ `Join_Date`), log + Slack Ops.		⏳ Chờ BA 🟠
A-10	(phần còn mở) Trader terminate / resign / lên Level 7 khi đang chờ có bị loại khỏi waitlist không? `[POD-WAIT-12]`	Rời waitlist khi `Assigned`, `Waitlist_Ghost` / Unassigned, `Failed` / `Terminated` (resign cũng là `Terminated`), hoặc lên Level 7+ Alumni. 3 status đang ở waitlist: `Waitlist`, `Inactive_Hold`, `Pending_Pod_Confirmation`. Status pod lưu cột riêng, tách `users.status`. Tài khoản Locked (DTO / Hiatus) khi đang chờ → bỏ qua khi chọn như `Inactive_Hold`, tới khi về `Active`. Khách trả lời 2026-10-22.	✅ Đã chốt
A-19	🆕 Cái gì báo cho Zap Flow 11 chạy? Đã chốt flow tạo ra suất trống gọi Flow 11 ngay sau đó (Q-06), nhưng chưa chốt cơ chế: Middleware gửi webhook tới Zap, hay Zap tự kiểm tra; truyền những gì (`leader_id`, số suất trống) để Zap gọi `/process-waitlist-queue` đủ số lần (Q-08). V7 ghi trigger "`Current_Count` giảm trong SQL" — Zapier không tự thấy thay đổi trong database.	Middleware (nơi duy nhất ghi `Current_Count` — Q-19) ngay sau khi ghi xong 1 trong 4 sự kiện gửi webhook tới Zap Flow 11 kèm `leader_id` + số suất trống; Zap gọi `/process-waitlist-queue` mỗi suất 1 lần.		⏳ Chờ BA 🟠
A-20	🆕 Ai gửi `Pod_Spot_Available_Confirm` sang Klaviyo? `POD-WAIT-07`, `POD-XF-07` ghi Middleware/backend gửi; `POD-WAIT-17` và V7 Flow 11 ghi Zapier dùng `next_candidate_id` để gửi.	Middleware gửi ngay sau khi giữ chỗ (cùng cách với `Pod_Assignment_Confirmation`, `Pod_Waitlist_Notification` — UC_8.2.1 API_8.2.1.3; link xác nhận do Middleware tạo). Zap Flow 11 chỉ gọi endpoint.		⏳ Chờ BA 🟡
A-21	🆕 `Process Waitlist Queue API` không có `leader_id`. RFQ_ Stack Trading Prop Tech V7.pdf ghi input `leader_id (Optional)`; `POD-WAIT-02` chốt waitlist xét theo leader vừa trống chỗ. Khi không truyền `leader_id` thì endpoint chọn trader theo tiêu chí nào?	Flow 11 luôn truyền `leader_id`; không truyền → trả kết quả rỗng, không chọn ai.		⏳ Chờ BA 🟡

4. Việc nội bộ phát sinh

#	Việc	Owner
1	Thêm `Pod_Spot_Available_Confirm` vào tracking Table D2 (Klaviyo)	BA
2	Gửi khách: N-08, A-10	BA
3	Cập nhật UC_4.14.2 theo N-03 sau khi chốt	BA

Tổng kết trạng thái

Đã chốt: Q-01 → Q-20 (gồm toàn bộ BA chốt cũ: A-01 → A-18 trừ phần mở, C-01 → C-05, P-01).
Chờ BA: N-01, N-02, N-03, N-09, A-19, A-20, A-21.
Chờ khách: N-08.
Đã chốt 2026-11-09 (BA): N-05, N-06, N-07.
Đã chốt 2026-10-22 (khách): A-10. Trả lời một phần: N-02 (ca hết hạn), N-03 (Waitlist_Ghost).

QnA Init Docs — UC_8.2.8 (Flow 11 - Waitlist Processor)