| QN-4.12.4-01 | [QUAN TRỌNG — theo A-08] LIVE dùng event set nào trong 5 category? SIM chỉ confirm được 2/5 category (Risk Warning: NC-RISK-01…05; System Status: NC-SYS-01) — 3 category còn lại (Level Events, Payout Events, Mentor/Community Prompts) chưa có event confirmed ở SIM. LIVE là môi trường có Payout thật (payout events), Level Events thật (24-level progression, Level-Up), Pod/Mentor system đầy đủ (khác SIM, nơi Pod bị "locked" theo QN-4.9.2 cũ) — vậy LIVE có khả năng là môi trường mà 3 category còn thiếu event ở SIM sẽ CÓ đầy đủ event? | Đề xuất: LIVE cần research/confirm riêng cho cả 5 category (không thể copy 6 event từ SIM vì A-08 đã xác nhận rõ 2 môi trường dùng event set khác nhau) — cụ thể:Level Events → liên kết LEVEL_PROMOTION, LEVEL_STOP_BREACH (đã có trong v7_full.txt §3.2); Payout Events → liên kết payout calculation/withdrawal flow (STAGE 5, chưa map event cụ thể); Mentor/Community Prompts → liên kết Pod System (Flow 15, Founding Mentor). Cần BA xác nhận danh sách event LIVE cụ thể cho từng category, hoặc xác nhận cùng 6 event base (NC-RISK-01…05, NC-SYS-01) VẪN áp dụng cho LIVE + bổ sung thêm event mới cho 3 category còn lại. | KHÁC đề xuất ban đầu (cụ thể hơn) — BA đưa nguyên văn comment khách, map trigger notification vào đúng backend event/flow đã có, kèm hành vi middleware:1. Level Events — trigger tại Flow 4 (Promotion), Flow 4B (Drawdown Defense Activated), Flow 7 (Account Failed/Terminated) → ghi vào user_notifications với category: "Level Events", severity: "INFO" (hoặc "CRITICAL" cho failure/defense).2. Payout Events — trigger tại Flow 5 (Payouts) khi transaction clear và Immutable Ledger update → category: "Payout Events", severity: "INFO".3. Mentor/Community Prompts — trigger tại Flow 10 khi user được match với Pod Leader → category: "Mentor/Community Prompts", severity: "INFO".4. Trigger bổ sung (không thuộc 3 category trên nhưng cùng khối comment khách): khi 72h Trading Plan SLA còn 24h → push severity: "WARN"; khi SLA 72h bị miss (breach) → push severity: "CRITICAL".Hành vi middleware (nguyên văn khách): "Whenever these events occur, the Node.js middleware must insert a record into the user_notifications table and simultaneously push the NOTIFICATION WebSocket payload to the frontend." | ✅ Confirmed (khác đề xuất ban đầu — mapping event cụ thể theo Flow, không phải danh sách event rời) |
| QN-4.12.4-02 | UI/UX layer (filter, badge, mark-as-read, pagination, empty state) — có giữ nguyên 100% pattern đã chốt ở SIM (UC_4.7.1-4.7.3), chỉ khác data/event, hay LIVE cần UX riêng? Đây là câu hỏi tổng hợp cho toàn bộ UI behavior đã confirm ở 3 UC SIM sibling. | Đề xuất: giữ nguyên toàn bộ UX pattern đã chốt ở SIM — (1) badge đếm tổng unread không theo filter (QN-4.7.1-03); (2) category filter multi-select default "All", Date filter dạng range, AND-combination (QN-4.7.2); (3) page size default 20, mark-as-read hover cá nhân hoặc "Mark as read" đánh dấu tất cả, empty state "There are no notifications yet", không có severity visual treatment, click row = expand/collapse only (QN-4.7.3). Chỉ event/data source khác (QN-4.12.4-01), UI component dùng chung code/component giữa SIM và LIVE. | BA confirm đúng nguyên văn đề xuất — giữ nguyên 100% pattern UI/UX đã chốt ở SIM (badge, filter, mark-as-read, empty state, click row). UC_4.12.4 chỉ cần mô tả các event type LIVE-only mới (QN-4.12.4-01), link sang SIM UC_4.7.1-4.7.3 cho UI/flow thay vì lặp lại mô tả. | ✅ Confirmed |
| QN-4.12.4-03 | Cơ chế cập nhật real-time — WS push giống SIM (GET /notifications chỉ dùng initial load) không? | Đề xuất: giữ nguyên cơ chế đã chốt ở SIM (QN-4.7.1-05) — WS push cập nhật store ngay lập tức,GET /notifications chỉ dùng initial load lúc mount component. Không có lý do nghiệp vụ để LIVE khác SIM ở tầng cơ chế kỹ thuật này. | BA confirm đúng nguyên văn đề xuất — giữ nguyên cơ chế đã chốt ở SIM (WS push cập nhật store ngay, REST chỉ dùng initial load). | ✅ Confirmed |
| QN-4.12.4-04 | Áp dụng CR-14 (WebSocket Reconnection Resiliency)? Notification Center là widget fed bởi WS event — theo CR-14, phải giữ giá trị cuối (danh sách notification hiện có) khi mất kết nối, không clear về rỗng, và tự động reconnect với exponential backoff. | Đề xuất: áp dụng CR-14 nguyên văn — không cần hỏi riêng, chỉ cần Architect trích dẫn đúng CR-14 khi viết SRS (giống UC_4.2.1-4.2.5 đã áp dụng). | — | ✅ Đã resolve qua research — áp dụng CR-14, không cần BA trả lời riêng |
| QN-4.12.4-05 | Áp dụng CR-06 (List Pagination default 10/page, options 10/20/50/100)? SIM đã confirm page size default 20 (khác default CR-06 là 10). Đây có phải override cố ý của Notification Center (cả SIM và LIVE) so với Common Rule chung, hay là lỗi chưa đồng bộ với CR-06? | Đề xuất: giữ default 20 cho Notification Center (cả SIM và LIVE) như đã chốt ở SIM QN-4.7.3 — ghi rõ trong SRS đây làoverride có chủ đích so với CR-06 default (10), không phải sai lệch. Cần BA xác nhận override này áp dụng luôn cho LIVE (không lý do gì LIVE khác SIM ở điểm này). | BA: "Giữ 10 bản ghi tương tự như đã viết ở các UC của SIM." ⚠️ CONFLICT — chưa tự resolve: câu trả lời "10 bản ghi" mâu thuẫn với page size 20 đã confirm ở SIM sibling QN-4.7.3 (được ghi rõ là override có chủ đích so với CR-06 default 10). Có thể BA đang muốn đổi cả 2 UC (SIM + LIVE) về default 10 theo CR-06 (bỏ override), hoặc chỉ nhớ nhầm số — ghi nhận nguyên văn, KHÔNG tự chọn 10 hay 20. | 🟡 ⏳ Chờ BA xác nhận lại — conflict với page size 20 đã confirm ở SIM QN-4.7.3 |