| A-01 | 🔴 Vùng input của SIM: hidden hay disabled + locked, và dùng copy nào? Khách đưa 2 phương án hiển thị × 2 phương án copy nhưng không chốt cái nào. Nguyên văn: "the text input box and 'Send' button must be either completely hidden or disabled with a locked state. Use the placeholder text 'Pass the Associate Track to unlock chat' or 'Chat unlocks at Level 1'." [C-9] → đây là hành vi chính của UC này, không chốt thì không viết được Screen Description. | Chọn disabled + locked (input không focus được, nút Send disabled) + copy Pass the Associate Track to unlock chat.Lý do: (a) ẩn hẳn input khiến SIM không hiểu vì sao mình không gửi được, còn locked state tự giải thích lý do; (b) copy này khớp ngôn ngữ nút card My POD Pass the Associate Track to Unlock, giữ nhất quán toàn màn Community; (c) giữ nguyên chiều cao panel → không vỡ grid 2×2 (nguyên tắc khách đã áp 2 lần [C-2], [C-17]). | Bypass — BA chỉ đạo 2026-08-10: không cần chốt, viết SRS thẳng theo bộ answer khách đã trả lời trong CSV. | ⏭️ Bypass (BA, 2026-08-10) |
| A-02 | 🔴 [INTRA_RULE_CONTRADICTION] SIM + chưa link Discord → vùng input hiện gì? Hai luật của khách chồng nhau và cho ra 2 kết quả khác nhau:(a) [C-9] — SIM → "hidden or disabled with a locked state" + placeholder Pass the Associate Track to unlock chat.(b) [C-12] A18 — chưa link Discord → "the ability to send messages should be hidden (hidden, not just disabled)".→ Phần lớn trader SIM rơi vào cả hai cùng lúc (token link gửi qua email onboarding, nhiều người bỏ qua). Nếu chọn (a) disabled+locked mà (b) bắt hidden thì 2 luật loại trừ nhau. | Luật SIM [C-9] thắng. Với SIM, việc link Discord không mở được quyền gửi (vẫn Level 0 → vẫn Public (Read)) → nêu lý do "chưa link Discord" là sai nguyên nhân, gây hiểu nhầm rằng chỉ cần link là chat được. Luật (b) chỉ áp cho LIVE Level 1+ chưa link (thuộc UC_4.14.1). SIM luôn hiện đúng 1 state: disabled + locked + copy của A-01, bất kể discord_user_id null hay không. | Bypass — BA chỉ đạo 2026-08-10: không cần chốt, viết SRS thẳng theo bộ answer khách đã trả lời trong CSV. | ⏭️ Bypass (BA, 2026-08-10) |
| A-03 | 🔴 [INTRA_RULE_CONTRADICTION] Trader SIM chạy /link được gán role gì — và role đó có mở quyền gửi tin không?(a) [S-22] — bot verify token → ghi discord_user_id → gán role Associate Trader.(b) [C-9] + Discord Server Details.md — #live-broadcast-chat scope: Associate Trader trở lên = Read/Write; bảng role ghi Associate Trader = Levels 1 to 5 (tức đã LIVE).→ Nếu SIM (Level 0) chạy /link mà thật sự nhận role Associate Trader thì theo (b) họ có Read/Write — trái thẳng với [C-9] "SIM read-only". Bảng role còn có 1 role Associate riêng ("paid track status but still in the associate phase") — nhiều khả năng đây mới là role đúng cho SIM. | Role gán cho SIM khi /link là Associate (membership group của giai đoạn evaluation), KHÔNG phải Associate Trader (Levels 1–5). Chỉ Associate Trader trở lên mới có Read/Write ở #live-broadcast-chat. → Dashboard khoá vùng input dựa trên level/account type của trader (level == 0 / SIM), không dựa trên discord_user_id.⚠️ Nếu BA xác nhận giả định này → cần sửa lại [S-22] và ghi nhận cho UC_4.6.2 (Discord Linking) + Flow 1 Step 6. | Bypass — BA chỉ đạo 2026-08-10: không cần chốt, viết SRS thẳng theo bộ answer khách đã trả lời trong CSV. | ⏭️ Bypass (BA, 2026-08-10) |
| A-04 | 🔴 Tên hiển thị trong bubble lấy từ nguồn nào? Khách mâu thuẫn ngay trong cùng 1 ô CSV, và chính khách ghi chú yêu cầu BA cross-check:(a) [C-12] A1–A3 — "the user's exact Discord server nickname passed via the author field… Roles (Coach/Mentor) are appended automatically based on Discord role metadata."(b) [C-12] A16 (Adam) — "There should be a symbolic link between the trader details and their discord details. Using that link with its associated trader, display who the message is from." → tức lấy từ profile trader phía StackTrading.→ Design đang có 2 kiểu bubble: Trader 0x4F (ẩn danh) và Coach T. (có title) — không biết nguồn nào sinh ra kiểu nào thì không viết được rule hiển thị. | (a) thắng — author = Discord server nickname + role suffix tự động từ Discord role metadata. Lý do: đây là nguồn duy nhất thực sự có trong WebSocket payload đã chốt { author, message_text, timestamp } [C-14]; ý (b) của Adam vẫn được thoả mãn vì discord_user_id chính là symbolic link giữa trader và Discord — và cả 2 câu đều thống nhất user không tự đặt được title Coach [C-12] A3. Kiểu Trader 0x4F là nickname do chính user đặt trên Discord, không phải hash do hệ thống sinh ([C-12] A2 đã phủ định việc sinh hash). | Bypass — BA chỉ đạo 2026-08-10: không cần chốt, viết SRS thẳng theo bộ answer khách đã trả lời trong CSV. | ⏭️ Bypass (BA, 2026-08-10) |
| A-05 | 🔴 [CROSS_UC_CONFLICT với UC_4.5.1] Chat đóng lúc nào khi Ops tắt broadcast giữa lúc user đang xem?(a) [C-10] — "the chat panel immediately clears the active messages and transitions to the empty state" khi broadcast chuyển offline.(b) BR_4.5.1.3 (BA đã chốt 2026-08-10) — FE chỉ gọi GET /community/live-broadcast đúng 2 lần (page load + countdown về 0), cấm polling và cấm WS channel riêng → "session end is not auto-detected mid-view".→ Với ràng buộc (b), FE không có kênh nào để biết is_live vừa tắt → chữ "immediately" ở (a) không thể thực hiện được. | Áp đúng cơ chế đã chốt ở UC_4.5.1: chat panel chuyển sang empty state cùng thời điểm với video — tức ở lần load trang / điều hướng vào Community kế tiếp, không phải realtime. Chữ "immediately" trong [C-10] được hiểu là "ngay khi UI nhận biết được trạng thái offline", không phải "trong vòng vài giây kể từ lúc Ops bấm nút".Phương án thay thế (cần khách duyệt, phát sinh CR): backend gửi 1 WS event BROADCAST_OFFLINE trên chính channel DISCORD_CHAT_STREAM đã có — không phải WS channel mới nên không vi phạm ràng buộc [C-2]. | Bypass — BA chỉ đạo 2026-08-10: không cần chốt, viết SRS thẳng theo bộ answer khách đã trả lời trong CSV. | ⏭️ Bypass (BA, 2026-08-10) |
| A-06 | Ngưỡng ký tự để bắt đầu truncate Read more là bao nhiêu? Khách xác nhận hành vi nhưng để ngỏ con số: "Still open: the exact character threshold at which a message gets truncated." [C-12] A17. Kết hợp với giới hạn 2.000 ký tự/tin [C-12] A4 → 1 tin dài nhất có thể chiếm rất nhiều dòng. | Truncate ở 4 dòng hiển thị (~280 ký tự), tính theo số dòng chứ không theo số ký tự cứng — vì chiều rộng panel thay đổi theo breakpoint, ngưỡng ký tự cố định sẽ cho kết quả khác nhau giữa desktop và mobile. | ✅ CLOSED 2026-08-24 — khách defer cho Sotatek quyết ("I'll defer to you"), đề xuất bên trái được duyệt. Chốt: clamp 4 dòng render ở mọi breakpoint; ~280 ký tự chỉ là mốc tham chiếu desktop cho khách hình dung + dựng test data, không phải cơ chế enforce. Read more chỉ hiện khi body thực sự bị cắt (đo scroll height > visible height, re-check khi resize) — cấm quyết định bằng đếm ký tự, nếu không sẽ có case tin vừa đúng 4 dòng ở màn rộng vẫn mọc nút trỏ vào chỗ không bị cắt. Chọn 4 dòng vì 2-3 dòng sẽ bắn Read more lên cả tin chat thường (noise), còn >4 dòng thì 1 tin 2.000 ký tự (~30 dòng) đã nuốt gần hết panel. Đã viết vào BR_4.9.1.9, §5 step 5, §9 row 3 + row 4. ⚠️ Message defer của khách chưa được log vào References/CR/. | ✅ Closed (BA, 2026-08-24) |
| A-07 | Read more làm "chat window grow" — giãn theo chiều nào? Khách nói "makes that chat window grow" [C-12] A17, tức cả khung chat chứ không riêng bubble. Trong grid 2×2, chat nằm cùng hàng với Live Broadcast → cần chốt: khung chat đẩy cao cả hàng (video giãn theo / lệch hàng), hay giãn nội dung trong chiều cao cố định + cuộn nội bộ? | Giãn trong chiều cao cố định + cuộn nội bộ. Cùng nguyên tắc "so the UI grid does not break" khách đã áp cho case TBD [C-2] và cho card My POD [C-17]. Bubble mở rộng hết nội dung, khung chat không đổi chiều cao, user cuộn trong panel; read less ở góc dưới phải khung chat để thu lại. | ✅ CLOSED 2026-08-24 — chốt cùng lượt với A-06, đề xuất bên trái được duyệt. Panel giữ nguyên chiều cao, cuộn nội bộ: video Live Broadcast không resize, card My POD phía dưới không bị đẩy, grid 2×2 không xê dịch. Giải quyết mâu thuẫn giữa "makes that chat window grow" [C-12] A17 và "so the UI grid does not break" [C-2] nghiêng về vế sau — "grow" hiểu là vùng đọc nở ra trong panel, không phải panel nở ra. Đây cũng là điều kiện để read less ở góc dưới phải hoạt động được: cần biên panel cố định thì nút mới neo được. Chốt kèm 4 case phái sinh, đã viết vào BR_4.9.1.9: (1) 1 tin expand tại 1 thời điểm — expand tin B thì tin A tự collapse, khớp việc khách đặt 1 nút read less cho cả khung chat chứ không per-bubble; (2) read less sticky, luôn thấy kể cả khi cuộn giữa tin dài; (3) expand không được kích hoạt auto-scroll của BR_4.9.1.8 — giữ nguyên vị trí đỉnh tin vừa mở, nếu không màn sẽ nhảy mất đúng chỗ vừa bấm; (4) tin đang expand bị purge khỏi rolling window 50 → state chết theo, không warning, không giữ lại. | ✅ Closed (BA, 2026-08-24) |
| A-08 | 🔴 Chat panel thuộc màn nào — Community Page hay Command Center? [C-34] nói rõ: #the-pit "feeds the Community Page", còn #live-broadcast-chat "feeds the chat UI specifically on the Command Center". Nhưng RFQ_ Website and Dashboard Implementation V7.pdf đặt Live Chat Feed trong mục §Community Page Implementation, và design/wireframe cũng đặt chat panel cạnh video trên Community Page. → Ảnh hưởng thẳng tới §2 Trigger và §3 Pre-conditions của UC. (Trùng câu hỏi treo #3 trong SIM_Community_Wireframe_Brief.md.) | Community Page thắng. Lý do: (a) RFQ Dashboard V7 — tài liệu đặc tả UI chính thức — xếp Live Chat Feed vào §Community Page Implementation; (b) [C-10] chốt chat mở/đóng cùng cờ is_live với video, mà video nằm trên Community Page → tách 2 màn sẽ phá vỡ ràng buộc đồng bộ này; (c) design khách đã duyệt đặt chat cạnh video. Câu "on the Command Center" của [C-34] được hiểu là cách gọi chung cho Dashboard, không phải chỉ định 1 màn khác. | Bypass — BA chỉ đạo 2026-08-10: không cần chốt, viết SRS thẳng theo bộ answer khách đã trả lời trong CSV. | ⏭️ Bypass (BA, 2026-08-10) |
| A-09 | Badge online count đếm phạm vi nào, và lấy dữ liệu từ đâu? [C-12] A15 nói đếm member online của chính channel đó, poll ~1 phút. Nhưng ở card The Pit, đúng vấn đề này đã được đóng ngược lại: "The metrics shown here can reflect the entire Discord server, not just The Pit channel" — vì widget.json chỉ trả presence_count server-wide, không expose số liệu theo channel [C-37]. → Badge chat gặp đúng giới hạn kỹ thuật đó, nên con số per-channel nhiều khả năng cũng không lấy được. | Áp cùng kết luận đã chốt cho The Pit: badge hiển thị presence server-wide, lấy từ endpoint GET /community/server-status (backend caching proxy, Redis TTL 30s) đã tạo cho UC_4.5.2 — không gọi Discord trực tiếp từ browser, không tạo cơ chế poll thứ hai. Nhãn hiển thị nên đổi thành Members online cho đúng bản chất (đồng bộ với đề xuất A-02 của UC_4.5.2). | Bypass — BA chỉ đạo 2026-08-10: không cần chốt, viết SRS thẳng theo bộ answer khách đã trả lời trong CSV. | ⏭️ Bypass (BA, 2026-08-10) |
| A-10 | SIM đang Soft Breach / Hard Breach / đã fail Associate Track — chat feed có bị khoá thêm không? Trader vẫn login và vẫn vào được Community Page (Ref: UC_4.10.1, UC_4.10.2). Thêm 1 lớp: Flow 7 (Digital Eviction) chạy POST /discord/revoke-all-roles revoke hết role [S-20] → trader mất role nhưng vẫn ở trong server. Không dòng nào trong CSV nói chat bị ảnh hưởng. (Trùng câu hỏi treo #4 trong SIM_Community_Wireframe_Brief.md.) | Không khoá gì thêm. SIM vốn đã read-only ở mọi trạng thái account → breach không làm thay đổi state nào của panel này. Feed vẫn hiển thị đầy đủ; vùng input vẫn ở đúng state A-01. Nhất quán với BR_4.5.1.1 (BA đã chốt: breach chỉ chặn giao dịch, không chặn nội dung community). | Bypass — BA chỉ đạo 2026-08-10: không cần chốt, viết SRS thẳng theo bộ answer khách đã trả lời trong CSV. | ⏭️ Bypass (BA, 2026-08-10) |
| A-11 | SIM read-only có giữ đủ các affordance ĐỌC không? Khách chỉ khoá quyền gửi (write), không nói gì về thao tác đọc. Cần chốt rõ để không vẽ/viết thiếu: badge New Messages ([C-12] A7), Read more / read less ([C-12] A17), cuộn lịch sử trong rolling window 50 tin ([C-12] A9). | SIM giữ đầy đủ, y hệt LIVE. Đây là thao tác đọc, không nằm trong phạm vi bị khoá của [C-9] (chỉ nói text input box và nút Send). Ghi rõ trong SRS để tránh hiểu nhầm "read-only = panel tĩnh". | Bypass — BA chỉ đạo 2026-08-10: không cần chốt, viết SRS thẳng theo bộ answer khách đã trả lời trong CSV. | ⏭️ Bypass (BA, 2026-08-10) |
| A-12 | Phạm vi UC: có document chiều outbound trong UC_4.9.1 không? Các nội dung khách đã chốt nhưng chỉ áp cho người gửi được tin: POST /community/chat/send + rate limit 1 req/s [C-14], toast Message rate limit reached. Please wait a moment. [C-12] A12, Enter / Shift+Enter [C-13] A3, maxlength=2000 [C-12] A4, Batch Worker + Redis queue. | Không viết chi tiết outbound vào UC_4.9.1 — UC này là ONE-WAY (inbound only). Các mục trên ghi ở Phần 1 của QnA làm nguồn cho UC_4.14.1 (Discord Chat Stream TWO-WAY — LIVE). UC_4.9.1 chỉ nêu 1 câu ranh giới trỏ sang UC_4.14.1, tuân thủ Single Source of Truth. | Bypass — BA chỉ đạo 2026-08-10: không cần chốt, viết SRS thẳng theo bộ answer khách đã trả lời trong CSV. | ⏭️ Bypass (BA, 2026-08-10) |
| A-13 | Mất kết nối WebSocket / đang reconnect — panel hiển thị gì? Tài liệu không spec. Đây là state SIM gặp thường xuyên hơn LIVE vì SIM chỉ nhận inbound, cả phiên chỉ phụ thuộc vào 1 kết nối WS duy nhất. | Hiện banner mảnh trong panel (phía trên list bubble): Reconnecting…. List tin nhắn cũ giữ nguyên trên màn, không xoá, không phủ mờ — vì xoá sẽ bị nhầm với empty state No live chat của case Offline [C-10]. Tự retry, không bắt user reload trang. | Bypass — BA chỉ đạo 2026-08-10: không cần chốt, viết SRS thẳng theo bộ answer khách đã trả lời trong CSV. | ⏭️ Bypass (BA, 2026-08-10) |