StackTrading Docs

QnA Init Docs — UC_4.1-4.5: Dashboard - Common (Global Shell)

Câu hỏi và giả định phát sinh trong quá trình Init Flow (Agent 1 Auditor + Agent 2 Challenger) cho module Global Shell

QnA Init Docs — Dashboard Common Global Shell

Phạm vi UC (ban đầu, trước BA review): UC_4.1.1 → UC_4.1.6, UC_4.7.1 → UC_4.7.4, UC_4.11.1 → UC_4.11.5 (module Global shell / Global Shell trong WBS, thuộc category STAGE 2: DASHBOARD - COMMON, STAGE 2.1. DASHBOARD SIM, STAGE 2.2: DASHBOARD LIVE)

Phạm vi UC (sau BA review — final, xem "Scope Impact" §): Chỉ còn UC_4.1.1 → UC_4.1.5 (Dashboard Layout, Sidebar Navigation, Market Status Widget + banner CR-20260727-005, Newsquawk Audio Stream, Launch Trading Terminal) thực sự thuộc Dashboard Common Global Shell. Các UC còn lại (UC_4.1.6, UC_4.7.1-4.7.4, UC_4.11.1-4.11.5) đã được BA xác nhận dời ra khỏi phạm vi tài liệu Common — tách theo SIM/LIVE hoặc theo module Overview (chi tiết ở bảng A-04 → A-08 và "Scope Impact" bên dưới).

Ngày tạo: 2026-08-06 Ngày re-sync theo WBS mới: 2026-08-06 Ngày BA review: 2026-08-06 BA in Charge: trang.nguyen25 Trạng thái tổng: ✅ BA đã trả lời toàn bộ A-01→A-15 — xem "Scope Impact" bên dưới trước khi qua Step 3 (còn 3 điểm mở: ảnh 1 cho A-01, tên folder đích cho A-04, API endpoint client cho A-14)


⚠️ Renumber Note — WBS BA-internal mới (2026-08-10)

BA đã break lại danh sách function theo UC mới trong References/WBS/[BA Internal] Stacktrading.csv. Phần thân tài liệu này (A-01 → A-15, các câu trả lời của BA) được giữ nguyên mã UC cũ để không sửa lịch sử review. Khi đọc, tra mã mới theo bảng sau:

Mã cũ trong tài liệu nàyFunctionMã mới (WBS 2026-08-10)
UC_4.1.6Daily Loss Limit Bar (đã tách SIM/LIVE)SIM → UC_4.7.5 · LIVE → UC_4.12.5
UC_4.11.1Countdown Timer (LIVE)UC_4.12.1
UC_4.11.2PnL Gauge (LIVE)UC_4.12.2
UC_4.11.3The Desk Manager (LIVE)UC_4.12.3
UC_4.11.4Notification Center (LIVE)UC_4.12.4
UC_4.11.5Level Progression (LIVE)UC_4.12.6
UC_4.11.1 → UC_4.11.5 (dải LIVE Global Shell)Global Shell (LIVE)UC_4.12.1 → UC_4.12.6
UC_4.2.6Không còn trong WBS
UC_4.1.7Chỉ là mã giả định trong A-09, chưa từng tồn tại

Điểm mở #2 trong "Scope Impact" (tên folder đích cho các UC tách SIM/LIVE) đã được giải quyết: docs/BA/UC_4.1-4.17/dashboard_sim/ cho SIM, docs/BA/UC_4.1-4.17/dashboard_live/ cho LIVE, docs/BA/UC_4.1-4.17/dashboard_common/ cho Common — mỗi nhóm UC một subfolder riêng.

Bản SRS UC_4.1.1-4.1.5_v1.md (v8) đã được map lại sang mã mới — dùng file đó làm nguồn cross-ref chuẩn, không dùng mã trong tài liệu QnA này.


Re-sync Note — WBS source đã đổi từ CSV sang XLSX

WBS source file đã được BA cập nhật: References/WBS/[BA Internal] Stacktrading - BA plan 2 (1).csv (cũ) → References/WBS/[BA Internal] Stacktrading - Plan 2.xlsx (mới). File cũ không còn tồn tại trên disk (chỉ còn trong git history).

Do script/parse_wbs.js trước đây chỉ đọc CSV, script đã được cập nhật để tự nhận diện .xlsx (ưu tiên) hoặc .csv (fallback), kèm module đọc XLSX thuần Node.js mới (script/lib_xlsx_min.js, không cần thêm dependency ngoài). Đã verify lại: node script/parse_wbs.js --compact chạy đúng trên WBS mới, tổng 177 UC (khớp tổng cũ).

Đã re-map toàn bộ 15 UC trong phạm vi tài liệu này (UC_4.1.1→4.1.6, UC_4.7.1→4.7.4, UC_4.11.1→4.11.5) bằng cách so sánh field-by-field (category, module, function, description, reference, mapping_be, mapping_fe, mapping_3rd, status_design, mapping_design, ba_pic, link_doc) giữa WBS cũ và WBS mới:

  • Kết quả: KHÔNG có thay đổi nội dung nghiệp vụ nào cho cả 15 UC — category/module/function placement giữ nguyên, description/reference/mapping giữ nguyên. Toàn bộ 15 câu hỏi A-01 → A-15 dưới đây vẫn còn nguyên giá trị, chưa có câu nào bị vô hiệu hoá bởi WBS mới.
  • 2 khác biệt duy nhất tìm thấy trong WBS mới, cả hai đều không ảnh hưởng nội dung QnA:
    • Cột Status document (tên cũ) đã được đổi tên thành BA document status (tên mới), và có thêm cột mới Client approval (hiện đang trống cho toàn bộ 15 UC trong scope).
    • eta_document hiển thị dạng chuỗi khác (ví dụ "2/8/2026""Sun Feb 08 2026 07:00:00 GMT+0700 (Indochina Time)") — chỉ là khác format do Excel serialize date cell, cùng ngày, không phải thay đổi lịch trình.
  • Đã kiểm tra riêng WBS-level (ngoài phạm vi 15 UC, chỉ để tham khảo — không thuộc câu hỏi nào ở đây): tổng số UC toàn WBS giảm 178→177 dòng do 1 dòng trùng UC_ID (UC_4.5.2) đã được dedupe theo key trong parse_wbs.js; UC UC_4.2.6 (ngoài scope, category STAGE 2: DASHBOARD - COMMON) không còn xuất hiện trong WBS mới; UC UC_4.8.3 (ngoài scope, category STAGE 2.1. DASHBOARD SIM) là UC mới xuất hiện. Cả hai đều không thuộc phạm vi Global Shell nên không ảnh hưởng tài liệu này.

Kết luận: File QnA này không cần sửa nội dung A-01 → A-15. PAUSE gate vẫn giữ nguyên, chờ BA trả lời như cũ.


⚠️ Scope Impact — BA đã trả lời và thay đổi phạm vi tài liệu (2026-08-06)

BA đã review và trả lời trực tiếp toàn bộ A-01 → A-15 (xem cột "BA chốt"/"Trạng thái" trong bảng dưới). Nhiều câu trả lời làm thay đổi phạm vi (scope) so với đề xuất ban đầu của Agent 2 — cụ thể:

1. UC bị loại khỏi phạm vi tài liệu UC_4.1-4.11 (Dashboard Common Global Shell):

UCLý do loại (theo BA)Dời tới đâu
UC_4.1.6 (Daily Loss Limit Bar)Rule SIM (flat 7.5%) khác LIVE (per-level Table A/B) → phải tách UC, không viết chung ở CommonTách 2 UC mới: 1 ở folder SIM Global Shell, 1 ở folder LIVE Global Shell (tên folder đích: chưa chốt — cần BA xác nhận)
UC_4.7.4 (Countdown Timer, SIM)Cùng lý do tách SIM/LIVEFolder SIM Global Shell (tên đích chưa chốt)
UC_4.11.1 (Countdown Timer, LIVE)Cùng lý do tách SIM/LIVE; đồng thời vẫn [BLOCKED] vì WBS description = "Detailed functions will be defined later"Folder LIVE Global Shell (tên đích chưa chốt), giữ [BLOCKED]
UC_4.8.1 (PnL Gauge, SIM) + UC_4.11.2 (PnL Gauge, LIVE)BA xác nhận đây là widget thuộc module Overview, không thuộc Global Shell (khác với đề xuất ban đầu cho là "cấp global header")Ngoài phạm vi Init Flow lần này — thuộc folder Overview SIM/LIVE (chưa viết)
UC_4.8.3 (The Desk Manager, SIM) + UC_4.11.3 (The Desk Manager/Gekko, LIVE)BA xác nhận widget = Gekko nhưng thuộc module Overview, không thuộc Global ShellNgoài phạm vi Init Flow lần này — thuộc folder Overview SIM/LIVE (chưa viết)
UC_4.7.1-4.7.3 (Notification Center, SIM) + UC_4.11.4 (Notification Center, LIVE)BA xác nhận SIM và LIVE có event set khác nhau (không chỉ khác nguồn data) → không gộp 1 business ruleTách 2 UC riêng theo SIM/LIVE (tên folder đích chưa chốt)
UC_4.11.5 (Level Progression, LIVE)Cùng pattern tách SIM/LIVE theo Global Shell — dù nội dung UI/link-to-CareerPath (A-12) vẫn giữ nguyên như đề xuấtFolder LIVE Global Shell (tên đích chưa chốt)

2. UC còn lại thực sự thuộc phạm vi Dashboard Common Global Shell (không bị BA yêu cầu tách): UC_4.1.1, UC_4.1.2, UC_4.1.3, UC_4.1.4, UC_4.1.5 — đây là 5 UC duy nhất Agent 3 (Architect) viết SRS trong lần này, dưới folder docs/BA/UC_4.1-4.5/ (đã đổi tên từ UC_4.1-4.11UC_4.1-4.5 theo yêu cầu BA 2026-08-06, khớp đúng range 5 UC thật thuộc scope; title tài liệu = "Dashboard - Common"). (Cập nhật 2026-08-08: folder này đã được chuyển vào docs/BA/UC_4.1-4.17/dashboard_common/ và đổi tên, đặt cùng cấp với dashboard_sim; nội dung 5 UC không đổi. Cập nhật tiếp 2026-08-08: 3 file (CU, QnA, index) được gom vào subfolder docs/BA/UC_4.1-4.17/dashboard_common/UC_4.1.1-4.1.5/, theo đúng pattern mỗi nhóm UC có subfolder riêng như dashboard_sim/UC_4.9.x/.)

3. Nội dung mới cần đưa vào UC_4.1.1 (theo A-09/A-10/A-11): thêm Business Rule mô tả banner CR-20260727-005 (Dashboard Data-Feed Lock Status), áp dụng cho cả Futures và Forex (không chỉ Futures), ẩn banner khi user hoàn tất ký (cơ chế kỹ thuật polling/webhook cụ thể vẫn [ASSUMPTION] — pending BE xác nhận).

4. 3 điểm còn mở, cần BA bổ sung trước khi Agent 3 viết SRS cho UC_4.1.1-4.1.5:

#Điểm mởLiên quanTrạng thái
1BA đề cập "check layout theo ảnh 1" cho UC_4.1.1 nhưng chưa có file ảnh đính kèm trong phiên làm việc nàyA-01⏳ Cần BA gửi lại ảnh (attach file hoặc đường dẫn trong repo)
2Tên folder đích cho các UC tách SIM/LIVE (UC_4.1.6, UC_4.7.x, UC_4.11.x, UC_4.8.x) — hiện chưa có folder docs/BA/ nào đặt tên riêng cho "SIM Global Shell" / "LIVE Global Shell" hoặc "Overview SIM/LIVE"A-04, A-05, A-06, A-07, A-08⏳ Cần BA xác nhận naming convention (theo project_context.md § UC_NAMING: UC_[start]-[end])
3API endpoint thật cho Newsquawk token (UC_4.1.4) — client sẽ cung cấp sauA-14⏳ Pending client, giữ [ASSUMPTION] tạm thời trong SRS

Đề xuất: Agent 3 có thể tiến hành viết SRS cho UC_4.1.1 → UC_4.1.5 ngay (5 UC này đã đủ thông tin, trừ điểm mở #1 cho riêng UC_4.1.1 và #3 cho riêng UC_4.1.4 — có thể viết với [BLOCKED]/[ASSUMPTION] tag rõ ràng ở đúng 2 chỗ đó). Các UC còn lại (UC_4.1.6, UC_4.7.x, UC_4.8.x, UC_4.11.x) không viết trong lần này — chờ BA tạo/xác nhận tên folder đích (điểm mở #2) rồi mới bắt đầu Init Flow riêng cho từng folder đó.


Bảng QnA & Assumption

IDCâu hỏi / Vấn đềGiả định (BA/QC đề xuất)BA chốtTrạng thái
A-01UC_4.1.1 Dashboard Layout: WBS không có description/reference/BE/FE mapping. Không tìm thấy đoạn source text riêng nào mô tả "layout tổng thể" trong dashboard_v7_full.txt, v7_full.txt, hay 2 Technical Proposal — chỉ có Tech Stack chung (React.js, Tailwind, Redux/Zustand) ở Part C. Scope của UC này là gì?Đề xuất: UC_4.1.1 chỉ mô tả cấu trúc khung layout tổng quát (persistent header + sidebar + content area) làm UC "umbrella" tham chiếu tới các UC con (4.1.2 → 4.1.6), không có business rule riêng, chỉ có Overview + reference tới Figma (chưa có mapping_design xác nhận).Đúng như đề xuất: UC_4.1.1 chỉ mô tả cấu trúc khung layout tổng quát của toàn màn hình dashboard, các mục thông tin bên trong tham chiếu tới các UC con. BA yêu cầu check layout theo "ảnh 1" (đính kèm).✅ Confirmed — ⚠️ chưa nhận được file "ảnh 1" qua kênh chat này (không có ảnh đính kèm trong tool context). Xem A-16.
A-02UC_4.1.2 Sidebar Navigation: Đã search toàn bộ v7_full.txt, dashboard_v7_full.txt, v6_full.txt, StackTrading_Technical_Proposal_v2.4.docx.md, StackTrading_Backend_Technical_Proposal_v1.6.docx.mdkhông tìm thấy đoạn nào mô tả Sidebar Navigation (menu items, route map, collapse/expand behavior). Không có mapping_design (Figma link) trong WBS. Đây là gap nguồn thật sự.Không thể tự suy diễn menu item vì có thể sai với thiết kế thật — đề xuất liệt kê menu items dựa trên các page đã biết tồn tại trong WBS category STAGE 2: DASHBOARD - COMMON/SIM/LIVE (Overview, Performance, Journal/Calendar, Community, Settings) làm placeholder [ASSUMPTION], chờ Figma/client xác nhận cấu trúc chính thức.Đúng: Sidebar Navigation cũng chỉ mô tả cấu trúc khung chung (danh sách tab). Khi chọn từng tab trên nav bar → navigate và tham chiếu tới UC con mô tả hành vi chi tiết của trang đó (không lặp lại nội dung trang con trong UC_4.1.2).✅ Confirmed
A-03UC_4.1.5 Launch Trading Terminal: Source (dashboard_v7_full.txt §Part C, dòng 633-639) chỉ mô tả logic khi platform_selection == "TradingView" → hiện nút "Launch TV Web Terminal" mở tv.stacktrading.com. Zapier Table I (Platform Registry) liệt kê các platform khác cho Futures: TradeSea (thay NinjaTrader theo CR-20260720-001), Quantower, ATAS, MotiveWave, Sierra Chart — đều là desktop app, và MetaTrader 5 (Forex). Với các platform này, UC có cần hiện nút "Launch" nào không, hay ẩn hoàn toàn nút Launch?Đề xuất: nút "Launch Trading Terminal" CHỈ hiện khi platform_selection == "TradingView"; các platform desktop khác (TradeSea/Quantower/ATAS/MotiveWave/Sierra Chart/MT5) không có nút Launch trên dashboard (trader tự mở app desktop, không qua web).Confirmed đúng theo đề xuất: nút "Launch TV Web Terminal" CHỈ hiển thị khi platform_selection == "TradingView"; ẩn hoàn toàn nút Launch ở các platform khác (TradeSea/Quantower/ATAS/MotiveWave/Sierra Chart/MT5).✅ Confirmed
A-04UC_4.1.6 Daily Loss Limit Bar: Theo QnA đã confirm STAGE2-031 (2026-08-05, override STAGE2-003/007): SIM dùng flat 7.5% notional cho mọi tier; LIVE dùng Market_Loss_When_Stopped theo level (Table A/B). UC_4.1.6 nằm ở category STAGE 2: DASHBOARD - COMMON (dùng chung cho cả SIM/LIVE, không tách UC riêng). Xác nhận: 1 UC duy nhất, giá trị giới hạn lấy từ nguồn khác nhau theo environment tại BE (FE chỉ render % progress nhận từ RULE_TRACKING WS event dist_daily_loss/daily_loss_limit), đúng không?Đề xuất: đúng — 1 UC chung, BR ghi rõ 2 nhánh giá trị (SIM = flat 7.5%, LIVE = per-level Table A/B) như 2 dòng trong cùng Business Rule, không tách UC.BA bác đề xuất — ngược lại với đề xuất ban đầu. Daily Loss Limit Bar KHÔNG viết chung trong folder Common (UC_4.1-4.11) nữa. Do rule SIM và LIVE khác nhau (flat 7.5% vs per-level Table A/B), phải tách thành 2 UC riêng — 1 UC trong phạm vi tài liệu SIM Global Shell, 1 UC trong phạm vi tài liệu LIVE Global Shell. Chưa chốt tên folder đích cụ thể.❌ Rejected (đề xuất "1 UC chung ở Common" sai) — [SCOPE CHANGE]: UC_4.1.6 bị loại khỏi phạm vi tài liệu UC_4.1-4.11 này, dời sang 2 UC mới ở folder SIM Global Shell + LIVE Global Shell (folder đích cần BA xác nhận tên — xem A-16).
A-05UC_4.7.4 vs UC_4.11.1 Countdown Timer (LIVE): WBS UC_4.11.1 ghi rõ description = "Detailed functions will be defined later" (ETA 9/8/2026, status_design = "Checking"). Đây là tín hiệu rõ ràng rằng nội dung LIVE chưa sẵn sàng. Có nên viết UC_4.11.1 trong lần này không?Đề xuất: loại UC_4.11.1 ra khỏi phạm vi lần viết doc này, đánh dấu [BLOCKED] trong SRS index, chờ WBS được BA cập nhật description trước khi viết. Chỉ viết UC_4.7.4 (SIM, đã có đầy đủ description + Figma + BE/FE mapping).BA bác đề xuất "giữ chung 1 chỗ". Không giữ UC_4.7.4 trong phạm vi tài liệu Common (UC_4.1-4.11) — 2 Countdown Timer (SIM = UC_4.7.4, LIVE = UC_4.11.1) đều tách ra viết ở 2 folder tài liệu riêng (SIM Global Shell, LIVE Global Shell). Folder UC_4.1-4.11 này chỉ giữ danh sách các UC Dashboard Common (không thuộc SIM/LIVE riêng).❌ Rejected (đề xuất ban đầu sai hướng) — [SCOPE CHANGE]: cả UC_4.7.4 và UC_4.11.1 bị loại khỏi phạm vi tài liệu UC_4.1-4.11, dời sang 2 folder SIM/LIVE Global Shell riêng (tên folder đích cần BA xác nhận — xem A-16). UC_4.11.1 tại LIVE vẫn [BLOCKED] chờ description do WBS ghi "Detailed functions will be defined later".
A-06UC_4.11.2 PnL Gauge (LIVE): WBS không có description, nhưng dashboard_v7_full.txt dòng 572-575 (Part C Key Features) mô tả "PnL Gauge: dial 4 trạng thái (Starting point / Drawdown defense enabled / Breached-Account Disabled / Level Up)" nằm cùng nhóm với "Global Header Progress Bar" — gợi ý đây là widget cấp header/persistent, khác với mini equity-sparkline gauge ở UC_4.8.1 (module Overview, ngoài phạm vi Global Shell). Xác nhận UC_4.11.2 = gauge 4-trạng thái cấp global header (không phải sparkline Overview)?Đề xuất: đúng, UC_4.11.2 mô tả PnL Gauge 4-trạng thái persistent (tham chiếu WS event RULE_TRACKING/LEVEL_STOP_BREACH/LEVEL_PROMOTION); UC_4.8.1 (Overview, ngoài scope) là gauge/sparkline riêng trong trang Overview — 2 UC khác nhau, không trùng.BA sửa lại phần đề xuất bị nhầm hướng. Đúng là gauge có 4 trạng thái (giữ nguyên phần này). Nhưng KHÔNG phải widget "cấp global header" tách biệt — PnL Gauge (SIM = UC_4.8.1, LIVE = UC_4.11.2) vẫn thuộc module Overview, chỉ tách UC riêng theo SIM/LIVE (rule khác nhau), không thuộc Global Shell.⚠️ Partially confirmed — "4 trạng thái" đúng, nhưng "thuộc Global header/Global Shell" bị bác. [SCOPE CHANGE]: UC_4.11.2 (và UC_4.8.1 tương ứng) không thuộc phạm vi tài liệu UC_4.1-4.11 (Global Shell) — thuộc module Overview, viết ở folder Overview SIM/LIVE riêng (ngoài phạm vi Init Flow lần này).
A-07UC_4.11.3 The Desk Manager (LIVE): WBS không có description, nhưng dashboard_v7_full.txt dòng 896-900 mô tả "GEKKO_CHATTER" — LLM commentary cards (Discipline pass/fail tags). Xác nhận widget này thuộc Global Shell (hiển thị persistent/floating trên mọi trang) chứ không phải một page riêng?Đề xuất: đúng, The Desk Manager là widget floating/persistent (Global Shell), nội dung lấy từ GEKKO_CHATTER channel qua WebSocket, không có page riêng.BA bác đề xuất "thuộc Global Shell". Xác nhận The Desk Manager = Gekko (đúng phần mapping GEKKO_CHATTER). Nhưng widget này thuộc module Overview, không thuộc Global Shell. Sẽ được viết ở folder tài liệu SIM và LIVE (UC_4.8.3 / UC_4.11.3), không nằm trong folder Dashboard Common (UC_4.1-4.11) này.❌ Rejected (đề xuất "Global Shell" sai) — [SCOPE CHANGE]: UC_4.11.3 và UC_4.8.3 (The Desk Manager/Gekko) không thuộc phạm vi tài liệu UC_4.1-4.11 — thuộc module Overview, viết ở folder Overview SIM/LIVE riêng (ngoài phạm vi Init Flow lần này).
A-08UC_4.11.4 Notification Center (LIVE): WBS không có description. UC_4.7.1-4.7.3 (SIM) đã có đầy đủ description/BE/FE/Figma. Xác nhận LIVE có hành vi giống hoàn toàn SIM (chỉ khác nguồn dữ liệu environment), hay có khác biệt (ví dụ thêm category severity riêng cho LIVE risk events)?Đề xuất: giống hành vi SIM 100% (bell icon, filter, mark-as-read, pagination), chỉ khác nguồn WS event bind theo environment context của user hiện tại — không cần UC riêng về business rule, chỉ khác data source.BA bác phần "giống 100%, chỉ khác data source". Notification Center SIM và LIVE có khác biệt về dữ liệu event giữa 2 environment (không chỉ là bind nguồn khác nhau — nội dung/loại event khác nhau giữa Sim và Live). Cần viết UC riêng cho từng environment với event set riêng, không dùng chung 1 business rule.❌ Rejected (đề xuất "giống 100%" sai) — cần tài liệu hoá riêng event set cho UC_4.7.1-4.7.3 (SIM) và UC_4.11.4 (LIVE); không gộp chung business rule. UC_4.11.4 vẫn ngoài phạm vi tài liệu Common này (thuộc LIVE Global Shell riêng).
A-09CR-20260727-005 (Dashboard Data-Feed Lock Status Banner): CR ghi rõ "Affected: future Dashboard UC (to be authored)". Banner này nên gắn vào UC nào? Ứng viên: (a) UC_4.1.3 Market Status Widget (cùng nhóm hiển thị trạng thái hệ thống ở header), hoặc (b) 1 UC mới độc lập (ví dụ UC_4.1.7).Đề xuất: gắn vào UC_4.1.3 Market Status Widget như 1 Business Rule bổ sung (banner hiển thị khi Rithmic feed bị lock ở exchange-gateway level, dùng đúng copy đã client-approved trong CR_summary.md), vì cùng thuộc nhóm "system/feed status" ở header — không tạo UC mới để tránh phân mảnh.BA bác cả 2 ứng viên (a)/(b). Không gắn banner vào UC_4.1.3 và không tạo UC riêng — đưa case có banner này vào UC_4.1.1 Dashboard Layout (mô tả banner như 1 case/state của layout tổng quát chung).❌ Rejected (2 ứng viên đề xuất đều sai) — [SCOPE FIX]: banner CR-20260727-005 gắn vào UC_4.1.1 Dashboard Layout (không phải UC_4.1.3, không tạo UC mới).
A-10CR-20260727-005 — Forex applicability: CR_summary.md tự ghi nhận đây là open item: banner mô tả cơ chế Rithmic (Futures) signature-gate; chưa xác nhận Forex (MT5/TraderEvolution) có luồng signature-gate tương đương hay không.Đề xuất tạm: banner chỉ áp dụng cho Futures (Rithmic) trong lần viết này; Forex sẽ bổ sung sau khi CR được client xác nhận — đánh dấu rõ trong BR là "Futures only, pending confirmation for Forex".BA bác đề xuất "chỉ Futures". Banner áp dụng cho cả Futures và Forex, không giới hạn chỉ Rithmic/Futures.❌ Rejected (đề xuất "Futures only" sai) — BR banner (viết trong UC_4.1.1 theo A-09) phải cover cả 2 nhánh Futures (Rithmic) và Forex (MT5/TraderEvolution), không đánh dấu "Futures only".
A-11CR-20260727-005 — Auto-clear mechanism: CR_summary.md ghi nhận cơ chế tự động ẩn banner (polling vs webhook khi user hoàn tất ký RTrader Pro) chưa được client xác nhận.Đề xuất tạm: dùng cơ chế polling định kỳ (ví dụ mỗi 30s gọi lại GET /system/market-status hoặc endpoint feed-status tương đương) làm [ASSUMPTION], thay placeholder khi có xác nhận chính thức (ưu tiên WebSocket event nếu BE cung cấp).BA bác đề xuất polling. Cơ chế đơn giản hơn: banner chỉ ẩn khi user đã hoàn tất ký (R|Trader Pro) — không cần polling định kỳ, việc ẩn banner gắn liền với event "ký xong" (không có chi tiết cơ chế kỹ thuật kèm theo — polling/webhook cụ thể chưa nêu).
A-12UC_4.11.5 Level Progression — Table A/B ownership: UI toggle 3 track (US Flex/Standard/International Contractor) hiển thị dữ liệu compensation theo level, nhưng bảng dữ liệu gốc (Table A/B — Compensation/Loss-When-Stopped) thuộc phạm vi Career Path (UC_58-72/UC_72_CareerPath), không phải Global Shell. Xác nhận UC_4.11.5 chỉ mô tả UI/UX của widget map + toggle + gọi API, và link tới Career Path docs cho định nghĩa Table A/B (không duplicate nội dung bảng), đúng theo nguyên tắc single-source-of-truth?Đề xuất: đúng — UC_4.11.5 chỉ định nghĩa UI Level Map + toggle track + API contract lấy dữ liệu hiển thị; Business Rule sẽ link (không copy) tới docs/BA/UC_72_CareerPath/... cho định nghĩa chi tiết Table A/B.BA confirm đúng nguyên văn đề xuất: UC_4.11.5 chỉ định nghĩa UI Level Map + toggle track + API contract lấy dữ liệu hiển thị; Business Rule sẽ link (không copy) tới docs/BA/UC_72_CareerPath/... cho định nghĩa chi tiết Table A/B.✅ Confirmed (giữ nguyên đề xuất — lưu ý UC_4.11.5 hiện đã dời khỏi phạm vi tài liệu Common này theo pattern SIM/LIVE tách riêng ở A-05/A-06/A-07, sẽ áp dụng nguyên tắc link-không-copy này tại folder LIVE Global Shell đích).
A-13Notification categories (Risk Warning, Level Events, Payout Events, System Status, Mentor/Community Prompts — nguồn dashboard_v7_full.txt dòng 667-671 và WBS UC_4.7.2): danh sách này có phải final/exhaustive hay còn có thể mở rộng? Có cần định nghĩa enum này trong Common Rule (dùng chung nhiều UC) hay giữ local trong UC_4.7.x?Đề xuất: giữ nguyên 5 category trên làm danh sách chính thức (theo source ★★★), không thêm/bớt; không cần tạo Common Rule riêng vì hiện chỉ 1 UC dùng enum này.BA confirm giữ nguyên: giữ 5 category như đề xuất, KHÔNG đưa vào Common Rule.✅ Confirmed (giữ nguyên đề xuất — lưu ý: theo A-08, SIM/LIVE có thể có event set khác nhau, nhưng danh sách 5 category cấp-1 này vẫn giữ nguyên/không tách theo A-13).
A-14UC_4.1.4 Newsquawk Audio Stream — token endpoint: Source (v7_full.txt dòng 3390, StackTrading_Technical_Proposal_v2.4.docx.md dòng 588-590) chỉ nêu yêu cầu "Token-Based Authentication" khi kết nối Squawk Relay, nhưng không có tên endpoint cụ thể để FE lấy token. Cần API contract rõ ràng để viết BE mapping.Đề xuất [ASSUMPTION]: BE cung cấp GET /audio/squawk-token trả về short-lived JWT, FE append vào query string/header khi connect tới Icecast stream. Cần BA/BE xác nhận tên endpoint thật.BA: endpoint API thật sẽ do khách hàng (client) cung cấp sau — tạm pending.⏸️ Pending (giữ nguyên [ASSUMPTION] placeholder GET /audio/squawk-token trong lúc chờ; đánh dấu [BLOCKED — awaiting client API contract] trong SRS, không dùng làm final endpoint cho tới khi client xác nhận).
A-15[INTRA_RULE_CONTRADICTION] Time Extension eligibility scope: dashboard_v7_full.txt dòng 679 quy định trigger Extend Time = "user is in the 'Associate Track' (Sim) AND days_remaining < 10" (giới hạn track cụ thể). Nhưng WBS mapping_be của UC_4.7.4 chỉ ghi "calculate days_remaining ... If < 10, include extend_eligible flag" — không nhắc lại điều kiện "chỉ Associate Track". Đây là mâu thuẫn Allow⇄Forbid tiềm ẩn: nếu BE chỉ check days_remaining&lt;10 mà không check track, user ở track khác (Accelerated/Advanced) có thể vô tình được extend_eligible=true. Cần xác nhận điều kiện đầy đủ.Đề xuất: BE phải check cả 2 điều kiện (track == Associate AND days_remaining &lt; 10) trước khi set extend_eligible=true — theo source ★★★ dashboard_v7_full.txt (ưu tiên cao hơn vì mô tả chi tiết hơn WBS mapping_be tóm tắt).BA bác đề xuất "chỉ Associate Track". Rule KHÔNG giới hạn chỉ Associate Track — áp dụng cho cả 3 track: Associate, Accelerated, Advanced. Điều kiện đúng: days_remaining &lt; 10 (không cần check track cụ thể, hoặc check track ∈ {Associate, Accelerated, Advanced} = tất cả track hiện có).❌ Rejected (đề xuất source dashboard_v7_full.txt dòng 679 — "chỉ Associate Track" — bị BA bác, override bằng câu trả lời trực tiếp này) — BR final: extend_eligible = true khi days_remaining &lt; 10, áp dụng cho mọi track (Associate/Accelerated/Advanced), không giới hạn riêng Associate. Cần đối chiếu lại với dashboard_v7_full.txt dòng 679 — có thể source gốc đã lỗi thời hoặc chỉ áp dụng ví dụ cho Sim track phổ biến nhất; BA answer ở đây thắng theo priority chain (BA trực tiếp trả lời qua chat = tương đương QnA confirmed, ưu tiên hơn Customer supplies).

Ghi chú Phase 2.2 — WBS Cross-UC Consistency Check

  • Cấu trúc trùng lặp SIM/LIVE: Module Global shell tồn tại ở 2 category riêng (STAGE 2.1. DASHBOARD SIM: UC_4.1.x + UC_4.7.x; STAGE 2.2: DASHBOARD LIVE: UC_4.11.x). UC_4.1.1-4.1.6 nằm ở category STAGE 2: DASHBOARD - COMMON (dùng chung, không tách SIM/LIVE riêng) — đã đối chiếu, không phát hiện xung đột cấu trúc, chỉ cần lưu ý khi đặt tên file/section.
  • Orphan-UC check: Không phát hiện UC nào bị tham chiếu nhưng thiếu trong WBS.
  • Missing-dependency check: UC_4.11.5 phụ thuộc dữ liệu Table A/B thuộc Career Path (đã nêu ở A-12); UC_4.1.6 phụ thuộc RULE_TRACKING WS event (đã có nguồn xác nhận ở v7_full.txt).

Ghi chú Phase 2.5 — Impact Analysis (mandatory, state-changing actions trong phạm vi)

ActionUniquenessCascadeReversibilityConcurrency
Reactivate market feed (POST /toggle-market-data)Theo userCập nhật Data Feed Status badge, credentials cardReversible (có thể pause lại)Không có race điều kiện đặc biệt được ghi nhận trong source
Mark notification as read (POST /notifications/mark-read)Theo user, single/batchCập nhật unread badge countReversible về mặt state nhưng source không mô tả "mark as unread"Batch action cần xác nhận idempotency khi double-click "Mark all as read" — chưa có source, đề xuất thêm vào A-16 nếu BA muốn mở rộng
Purchase Time Extension (POST /purchase-time-extension)Theo userCập nhật days_remaining, tắt pulse/glow, có thể trigger thanh toán qua Secure Checkout (Path A)Không reversible (giao dịch thanh toán)Source đã mô tả UI Fallback khi thiếu vaulted card — đã đủ, không cần thêm câu hỏi mới ở vòng này

Hướng dẫn cho BA

Đã nhận đủ câu trả lời cho A-01 → A-15 (xem cột "BA chốt"/"Trạng thái" trong bảng, và tổng hợp ở § "Scope Impact"). Trước khi tôi tiến hành Step 3 (Architect) cho 5 UC còn lại trong phạm vi (UC_4.1.1 → UC_4.1.5), vui lòng xác nhận/bổ sung 3 điểm mở:

  1. Gửi file/link "ảnh 1" cho UC_4.1.1 (layout tổng thể) — theo yêu cầu ở A-01.
  2. Xác nhận tên folder đích cho các UC đã tách khỏi phạm vi Common (UC_4.1.6, UC_4.7.1-4.7.4, UC_4.8.1/4.8.3, UC_4.11.1-4.11.5) — ví dụ UC_4.7-4.10 cho SIM Global Shell, UC_4.11-4.16 cho LIVE Global Shell, hoặc theo convention khác BA muốn.
  3. Endpoint API Newsquawk token (UC_4.1.4) — vẫn đang chờ client, có thể để [ASSUMPTION] tạm trong SRS nếu BA đồng ý đi tiếp.

Nếu BA muốn tôi viết SRS ngay cho UC_4.1.1 → UC_4.1.5 với 2 điểm mở #1/#3 đánh dấu [BLOCKED]/[ASSUMPTION] tạm, chỉ cần xác nhận "OK viết UC_4.1.1-4.1.5". Việc viết UC còn lại (đã tách sang SIM/LIVE) sẽ chờ điểm mở #2.

On this page