| A-01 | [INTRA_RULE_CONTRADICTION] Hai câu trả lời của khách mâu thuẫn trực tiếp trong cùng 1 bộ answer:(a) [C-2] — "Do not implement continuous polling or a dedicated WebSocket channel for the timer."(b) [C-5] — "Session End: As soon as the backend flags is_live as false, the UI transitions directly back to the countdown state."→ FE chỉ gọi API đúng 2 lần (page load + countdown=0). Với 1 user đang mở tab và đang xem phiên live, không có bất kỳ kênh nào để FE biết Ops vừa tắt is_live. Câu (b) về mặt kỹ thuật không thể thực hiện được với ràng buộc (a). | FE không tự phát hiện session end. Khi Ops tắt cờ, user đang xem vẫn thấy iframe YouTube — YouTube tự hiện "This live stream has ended". UI chỉ chuyển về countdown state ở lần load trang / điều hướng vào Community tiếp theo.Đề xuất bổ sung (cần khách duyệt): tái sử dụng event COMMUNITY_LIVE đã có sẵn trong RFQ V7 (§3.2.1.A — "Triggered globally via webhook when the official Stack Trading YouTube stream goes live") làm 1 WS event global 2 chiều (live on/off) — không phải WS channel riêng cho timer nên không vi phạm (a). | Chốt phương án "không tự phát hiện" — viết SRS đúng nguyên văn ràng buộc [C-2]: FE chỉ gọi API 2 lần, không thêm WS event. User đang xem khi Ops tắt cờ sẽ thấy overlay "This live stream has ended" của YouTube; UI chỉ về countdown ở lần load trang / điều hướng vào Community tiếp theo. Giới hạn này được ghi rõ trong SRS (Ref: BR_4.5.1.3). | ✅ Đã chốt (BA, 2026-08-10) |
| A-02 | Khi is_live = true, field next_broadcast_timestamp trong response trả gì? Table C chỉ track 1 phiên kế tiếp gần nhất [C-4] — nên nó đang là timestamp của chính phiên đang chạy (đã qua), hay của phiên sau, hay null? Ảnh hưởng trực tiếp tới việc UI có dựng được countdown cho phiên kế tiếp ngay sau khi phiên hiện tại kết thúc hay không. | Khi is_live=true → FE bỏ qua next_broadcast_timestamp, chỉ render player. Countdown chỉ tính khi is_live=false. Nếu lúc đó timestamp đã lỗi thời (< now) → xử lý y hệt case A-06 (giữ 00:00:00 + Starting soon). | Không đưa vào UC. BA đánh giá câu hỏi thiên về technical, không thuộc phạm vi SRS. Giả định bên trái không được áp dụng khi viết docs. | ❌ Không viết vào UC (BA, 2026-08-10) |
| A-03 | Tên các segment trên thanh lịch phiên (THE OPEN, THE GAP) lấy từ đâu? Chính khách nêu gap này và chưa chốt: "These names should really be passed from the backend schedule table. I think that is missing, so the front end either has to hardcode or we add a segments array to the JSON output." [C-4] | Bổ sung mảng segments[] vào response GET /community/live-broadcast (mỗi phần tử: label, start_time, end_time). Không hardcode FE — hardcode sẽ khiến mọi thay đổi lịch phát sóng phải deploy lại code, trái nguyên tắc "Ops tự chỉnh Table C không cần code deployment" [C-8].⚠️ Nếu chốt phương án này → phát sinh CR (thêm field vào endpoint + thêm cột vào Table C). | [ĐÃ CHỐT — khách trả lời 2026-08-10] Khách bổ sung mảng schedule[] (không phải segments[]) vào GET /community/live-broadcast, mỗi phần tử { time, label }, nguồn từ biến mới Broadcast_Schedule (JSON Array) trên Table C. FE iterate mảng này để render thanh lịch phiên — không hardcode, đúng như đề xuất bên trái. Đã viết vào BR_4.5.1.2 + BR_4.5.1.9 (UC v3). | ✅ Đã chốt — khách confirm (Adrian Stack, 2026-08-10); viết vào UC v3 (BA, 2026-08-12) |
| A-04 | Title dài: khách nói "If the title is long, wrap it to the next line. Do not use an ellipsis, clip the text cleanly." [C-5] — "wrap xuống dòng" và "clip gọn" là 2 hành vi khác nhau. Wrap tối đa mấy dòng rồi mới clip? Hay wrap vô hạn, không bao giờ clip? | Wrap tối đa 2 dòng, quá 2 dòng thì clip cứng không có ... (đúng nguyên văn "clip the text cleanly"). Chọn 2 dòng để không đẩy vỡ chiều cao khung video trong grid 2×2 — cùng nguyên tắc "so the UI grid does not break" khách đã áp cho case TBD [C-2]. | Không đưa vào UC. BA đánh giá nhóm câu hỏi này sai về mặt flow nghiệp vụ hoặc quá thiên về technical, không thuộc phạm vi SRS. Giả định bên trái không được áp dụng khi viết docs. | ❌ Không viết vào UC (BA, 2026-08-10) |
| A-05 | Múi giờ: toàn bộ giờ trong wireframe fix cứng CST (08:00 CST THE OPEN, Next session starts at 09:30 CST). Trader ngoài US sẽ đọc sai giờ. Có convert theo local timezone của user không, hay giữ CST và ghi rõ nhãn? (Trùng câu hỏi treo #8 trong SIM_Community_Wireframe_Brief.md.) | Giữ nguyên CST kèm nhãn hiển thị rõ ràng — nhất quán với toàn bộ ngôn ngữ vận hành của firm (CME session, market open/close đều theo CST) và khớp đúng wireframe khách đã duyệt. Countdown vẫn tính bằng UTC nên không sai giờ thực tế. | Không đưa vào UC. BA đánh giá nhóm câu hỏi này sai về mặt flow nghiệp vụ hoặc quá thiên về technical, không thuộc phạm vi SRS. Giả định bên trái không được áp dụng khi viết docs. | ❌ Không viết vào UC (BA, 2026-08-10) |
| A-06 | Lần gọi GET /community/live-broadcast tại thời điểm countdown = 00:00:00 bị lỗi mạng / 5xx / timeout thì UI xử lý sao? Khách chỉ spec case is_live=false, không spec case call thất bại [C-2]. | Xử lý y hệt case is_live=false: giữ đồng hồ 00:00:00 + subtext Starting soon. Không hiện error toast, không auto-retry vô hạn (tránh vi phạm ràng buộc "no continuous polling"). User reload trang thì gọi lại. | Không đưa vào UC. BA đánh giá nhóm câu hỏi này sai về mặt flow nghiệp vụ hoặc quá thiên về technical, không thuộc phạm vi SRS. Giả định bên trái không được áp dụng khi viết docs. | ❌ Không viết vào UC (BA, 2026-08-10) |
| A-07 | Cơ chế phát hiện ad-blocker chặn iframe là gì? Khách chỉ nói "If a client-side extension prevents the iframe from mounting, display a simple, static text block" [C-4] — không nói detect bằng cách nào. | Dùng onerror của iframe + timeout kiểm tra iframe mount (ví dụ 5 giây không mount được → coi như bị chặn) → render text block tĩnh Please disable ad-blockers to view the live broadcast. Không icon, không nút retry (đúng brief LB-3). | Không đưa vào UC. BA đánh giá nhóm câu hỏi này sai về mặt flow nghiệp vụ hoặc quá thiên về technical, không thuộc phạm vi SRS. Giả định bên trái không được áp dụng khi viết docs. | ❌ Không viết vào UC (BA, 2026-08-10) |
| A-08 | Trạng thái đang tải (từ lúc mount component tới lúc có response GET /community/live-broadcast) hiển thị gì? Tài liệu không spec. | Hiện skeleton giữ đúng kích thước ô grid của widget (không spinner toàn trang, không đẩy layout khi data về). Áp thẳng nguyên tắc "không được vỡ grid" khách đã nhắc 2 lần [C-2], [C-17]. | Không đưa vào UC. BA đánh giá nhóm câu hỏi này sai về mặt flow nghiệp vụ hoặc quá thiên về technical, không thuộc phạm vi SRS. Giả định bên trái không được áp dụng khi viết docs. | ❌ Không viết vào UC (BA, 2026-08-10) |
| A-09 | SIM đang Soft Breach / Hard Breach / đã fail Associate Track — Community Page nói chung và Live Broadcast nói riêng có bị khoá theo không? Trader vẫn login được và vẫn vào được Community Page (Ref: UC_4.10.1, UC_4.10.2), nhưng không dòng nào trong CSV nói Community bị ảnh hưởng. (Trùng câu hỏi treo #4 trong SIM_Community_Wireframe_Brief.md.) | Không khoá Live Broadcast. Khách đã khẳng định đây là "a universal community feature… fully unlocked and available to all authenticated users" [C-1] và endpoint trả 200 cho mọi authenticated user, không có logic phân biệt trạng thái account [C-6]. Soft/Hard Breach chỉ chặn giao dịch, không chặn nội dung community. | Chốt: KHÔNG khoá. Live Broadcast hiển thị và hoạt động đầy đủ ở mọi trạng thái account, kể cả Soft Breach / Hard Breach / fail Associate Track. Ghi vào SRS (Ref: BR_4.5.1.1). | ✅ Đã chốt (BA, 2026-08-10) |
| A-10 | Newsquawk auto-off: BR_4.1.4.4 (UC_4.1.4) quy định khi user vào màn Live Broadcast / Community thì Newsquawk audio tự chuyển Off để không chồng tiếng. Rule này có áp dụng cả khi broadcast đang Offline (không có tiếng nào để chồng) không? | Auto-off chỉ khi is_live = true. Khi Offline không có audio nào phát → tắt Newsquawk là làm mất thông tin của trader mà không đổi lại được gì. Khi phiên chuyển sang Live thì mới auto-off. | [ĐÃ CHỐT — BA xác nhận 2026-08-12] Áp dụng đúng giả định bên trái: auto-off chỉ khi is_live = true. Đã viết vào BR_4.5.1.11 (UC v3), kèm cảnh báo BR_4.1.4.4 (UC_4.1.4) hiện đang ghi điều kiện rộng hơn (auto-off ngay khi vào màn Community) và cần chỉnh cho khớp. | ✅ Đã chốt — viết vào UC v3 (BA, 2026-08-12) |
| A-11 | Khi user quay lại tab sau nhiều giờ (visibilitychange) — widget có tự refetch để đồng bộ lại trạng thái không? Liên quan trực tiếp A-01: nếu không refetch, user có thể nhìn khung countdown sai suốt nhiều giờ. | Refetch đúng 1 lần khi tab quay lại foreground và countdown đã ≤ 0. Đây là event-driven, không phải polling → không vi phạm ràng buộc [C-2]. Là cách rẻ nhất giảm nhẹ A-01 nếu khách không duyệt WS event. | Không đưa vào UC. BA đánh giá nhóm câu hỏi này sai về mặt flow nghiệp vụ hoặc quá thiên về technical, không thuộc phạm vi SRS. Giả định bên trái không được áp dụng khi viết docs. | ❌ Không viết vào UC (BA, 2026-08-10) |
| A-12 | [PATTERN] Rule "field trả về empty/null → ẩn hẳn container, không render placeholder rỗng, để các element xung quanh khép lại" ([C-5] cho title) — có nên chuẩn hoá thành 1 Common Rule dùng chung cho toàn bộ Dashboard widget không? | Có — đề xuất thêm CR-14: Empty/Null Field Container Collapse vào docs/BA/Common_rule/common_rules.md. Hiện rule này đang lặp lại rải rác ở nhiều widget (Live Broadcast title, The Pit metrics [C-37] "If we are unable to fetch this data, hide it"). | Không đưa vào UC. BA đánh giá nhóm câu hỏi này sai về mặt flow nghiệp vụ hoặc quá thiên về technical, không thuộc phạm vi SRS. Giả định bên trái không được áp dụng khi viết docs. | ❌ Không viết vào UC (BA, 2026-08-10) |