StackTrading Docs
BA — Business AnalysisUC 4.1–4.17dashboard liveUC_4.12.5 — Daily Loss Limit (LIVE Global Shell)

QnA Init Docs — UC_4.12.5: Daily Loss Limit (LIVE Global Shell)

Ngày tạo: 2026-08-12 Phiên bản: v1 BA phụ trách: Trang Nguyen Ngày BA review: 2026-08-12 Trạng thái: ✅ BA đã trả lời 3/5 câu (2 câu còn 🟡 pending — 1 pending KHÁCH, 1 đã resolve qua research) — công thức Daily_Loss_Limit = Market_Loss_When_Stopped × Daily_Loss_Ratio, scope UI-only giữ nguyên, Defense Protocol impact (QN-4.12.5-03) đang chờ khách xác nhận

⚠️ Lưu ý đặc biệt: WBS record trống

WBS hiện tại của UC_4.12.5 chỉ có function name ("Daily loss limit"), toàn bộ description/mapping_be/mapping_fe/mapping_design/reference đều trống (stt: 0) — giống hoàn toàn tình trạng của SIM UC_4.7.5. Nội dung QnA dưới đây được synthesize từ:

  • docs/BA/UC_4.1-4.17/dashboard_sim/UC_4.7.5/QnA_init_docs.md (SIM sibling, đã BA confirm 6/6 câu — carried-forward làm baseline).
  • References/QnA from clients/03_STAGE2_DASHBOARD_EVALUATION/QnA_STAGE2_DASHBOARD_EVALUATION.md — STAGE2-003/004/007/031/032/033 (★★★ client-confirmed).
  • References/Customer supplies/zapier_v7_full.txt L189-204 (Table C Global Variables — Daily_Loss_Ratio = 0.33 (1/3)), L2952-2997 (Table A per-level Market_Loss_When_Stopped).
  • References/Customer supplies/dashboard_v7_full.txt L569-571 ("Global Header Progress Bar" Key Feature text).
  • docs/BA/Common_rule/common_rules.md#cr-13-rounding-to-2-decimal-places — CR-13 nay đã chính thức tồn tại (line 405), khác tình trạng "chưa tạo" mà SIM UC_4.7.5 gặp lúc trước.

Carried-forward context (đã confirm ở dashboard_common/UC_4.1.1-4.1.5/QnA_init_docs.md và SIM UC_4.7.5, KHÔNG hỏi lại)

  • ⚠️ Renumber Note: ID cũ UC_4.11.5 → renumber thành UC_4.12.5 (WBS update 2026-08-10).
  • A-04 (dashboard_common): Daily Loss Limit Bar SIM (UC_4.7.5, flat 7.5%) khác LIVE (UC_4.12.5, per-level Table A/B Market_Loss_When_Stopped) → 2 UC riêng, không share business rule tính toán — CHỈ share UI component/behavior.
  • QN-4.7.5-04/05 (SIM, đã confirm): Bar update real-time qua RULE_TRACKING WS, không cần polling. Bar chỉ owns UI component (progress bar rendering, visual states), toàn bộ breach consequence logic thuộc UC riêng (SIM: UC_4.10.1 → LIVE: UC_4.15.1 Soft Breach — Daily Loss Limit Hit).
  • QN-4.7.5-03 (SIM, đã confirm phần bar): khi Soft Breach, bar hiển thị max (đầy) + motion warning (hiệu ứng động, không chỉ đổi màu tĩnh).
  • QN-4.7.5-06 (SIM, đã confirm): thiếu wireframe riêng — giữ [BLOCKED — pending design] cho tới khi có Figma link.
IDCâu hỏiGiả định (BA/QC đề xuất)BA chốt (ưu tiên cao nhất)Trạng thái
QN-4.12.5-01Công thức LIVE — dùng trực tiếp Market_Loss_When_Stopped (Table A/B per-level) làm giới hạn ngày, hay áp dụng hệ số Daily_Loss_Ratio = 1/3 (Table C) lên giá trị đó? STAGE2-007/031 phân biệt: SIM = flat 7.5% Max_Drawdown_Threshold; LIVE = dùng Table A/B trực tiếp theo level, với Daily_Loss_Ratio (1/3) là "Ratio of Daily Loss Limit to Total Account Stop Loss" — tức Daily Loss Limit LIVE = Market_Loss_When_Stopped × 1/3 (không phải dùng thẳng Market_Loss_When_Stopped làm giới hạn ngày).Đề xuất: Daily_Loss_Limit (LIVE) = Market_Loss_When_Stopped(level) × 1/3, dùng đúng phân số 1/3 (không phải số thập phân 0.33) để tránh sai số, sau đó round to 2 decimal theo CR-13. Ví dụ Level 1: Market_Loss_When_Stopped (Table A) × 1/3. Cần BA xác nhận đúng công thức này cho LIVE (khác hoàn toàn công thức flat 7.5% của SIM).BA confirm đúng công thức: Daily_Loss_Limit = Market_Loss_When_Stopped × Daily_Loss_Ratio, Daily_Loss_Ratio lấy từ Zapier Table C, notional per-level từ Table A (Forex)/Table B (Futures). BA cho ví dụ thực tế: "$25,000 → $412.50". ⚠️ Ghi nhận nguyên văn — chuỗi tính toán trung gian từ $25,000 ra $412.50 chưa được BA nêu rõ từng bước (nếu áp Daily_Loss_Ratio = 1/3 trực tiếp lên $25,000 sẽ ra ~$8,333, không khớp $412.50) — cần BA/khách bổ sung bước tính cụ thể (có thể Market_Loss_When_Stopped không phải $25,000 mà là 1 giá trị per-level khác, hoặc có hệ số trung gian chưa nêu). BA cũng confirm link công thức/logic này sang UC phần failure & challenge (khớp đề xuất cross-ref UC_4.15.1 đã đưa ra).✅ Đã chốt công thức (đúng đề xuất) — ⚠️ ví dụ số $25,000→$412.50 cần làm rõ thêm bước tính, ghi nguyên văn không tự suy diễn
QN-4.12.5-02Scope của UC_4.12.5 — chỉ document UI progress bar, KHÔNG viết công thức tính toán chi tiết (theo tiền lệ SIM QN-4.7.5-02/05)? Đề xuất giữ đúng nguyên tắc single-source-of-truth: UC_4.12.5 chỉ tiêu thụ giá trị đã tính sẵn (dist_daily_loss/daily_loss_limit từ RULE_TRACKING WS), công thức đầy đủ + breach consequence link sang UC_4.15.1 (Soft Breach — Daily Loss Limit Hit, LIVE).Đề xuất giữ nguyên scope hẹp như SIM: UC_4.12.5 = UI component (progress bar rendering, % fill, màu, motion warning khi breach). Business logic/formula → refer CR-13 cho rounding, refer UC_4.15.1 cho breach consequence đầy đủ.BA confirm đúng đề xuất — giữ scope UI-only, business logic/công thức đầy đủ tham chiếu sang UC failure & challenge (UC_4.15.1).✅ Confirmed
QN-4.12.5-03Bar hiển thị gì khi Defense Protocol active (Level 9+)? Theo Table F (Defense_Configuration_Matrix), khi Defense Protocol trigger, New_Limit = Floor(Original_Limit × Defense_Notional_Multiplier, 100) — áp dụng cho Notional. Câu hỏi: giới hạn Daily Loss (dial/bar của UC_4.12.5) có tự động recalculate theo Defense_Stop_Loss_Percent (seed 0.05) khi Defense active không, hay Daily Loss Limit giữ nguyên theo level gốc trong suốt thời gian Defense (chỉ Notional bị giảm, không phải Daily Loss)? Đây là câu hỏi song song với QN-4.12.2-02 (PnL Gauge dial ends) — cùng root cause (Defense Protocol impact), nên đề xuất BA trả lời 2 câu cùng lúc để đảm bảo nhất quán.Đề xuất: Daily Loss Limit bar recalculate theo New_Stop_Loss = Original_Stop_Loss × (1 - Defense_Stop_Loss_Percent) trong thời gian Defense active, cross-ref UC_4.15.4 (Scenario C: Defense Protocol) cho logic đầy đủ — nhưng đây là suy diễn, cần BA xác nhận vì không có nguồn trực tiếp mô tả Daily Loss Limit dưới Defense Protocol (chỉ có Notional được mô tả rõ).BA: "Pending chờ KH confirm." — khác với câu song song QN-4.12.2-02 (PnL Gauge dial ends dưới Defense Protocol), BA ĐÃ chốt trả lời dứt điểm ("giữ nguyên thang cũ"); còn câu này (Daily Loss Limit dưới Defense Protocol) BA CHƯA tự chốt được, cần đợi khách xác nhận riêng. Giữ nguyên trạng thái pending, KHÔNG suy diễn theo hướng đề xuất ban đầu.⏳ Chờ KH (khách) — khác QN-4.12.2-02 (đã chốt), câu này chưa có câu trả lời dứt điểm
QN-4.12.5-04CR-13 nay đã tồn tại chính thức — SRS có thể link trực tiếp common_rules.md#cr-13 thay vì viết công thức inline, đúng theo điều kiện đã đặt ra ở SIM QN-4.7.5-01?Đề xuất: đúng, dùng link CR-13 trực tiếp (không cần inline formula + TODO note như tình trạng cũ của SIM lúc CR-13 chưa tồn tại).Đề xuất hợp lý, không cần hỏi riêng — CR-13 đã confirmed tồn tại tại common_rules.md line 405.✅ Đã resolve qua research — dùng link trực tiếp, không cần BA trả lời riêng
QN-4.12.5-05Wireframe/Figma riêng cho bar LIVE — có khác SIM không? SIM đã xác nhận thiếu wireframe (QN-4.7.5-06, giữ [BLOCKED — pending design]). LIVE có Figma link riêng không, hay dùng chung component UI với SIM (chỉ khác nguồn số liệu)?Đề xuất: dùng chung UI component với SIM (cùng progress bar, cùng behavior khi breach — max + motion warning) — chỉ khác nguồn công thức tính giới hạn (QN-4.12.5-01). Nếu không có Figma riêng, giữ [BLOCKED — pending design] như SIM.BA confirm đúng đề xuất — dùng chung UI component với SIM, chỉ khác nguồn công thức. Giữ [BLOCKED — pending design] do chưa có Figma riêng.✅ Confirmed

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

  • CR Conflict Check: CR-13 (Rounding) áp dụng — đã confirmed tồn tại, không còn pending như tình trạng SIM lúc trước.
  • Same-category consistency: Sibling LIVE Global Shell UC_4.12.1-4.12.4/4.12.6 — không UC nào khác trùng nội dung Daily Loss Limit.
  • Cross-category dependency: Breach consequence logic → cross-ref UC_4.15.1 (Failure & Recovery, Soft Breach — Daily Loss Limit Hit); Defense Protocol impact → cross-ref UC_4.15.4 (Scenario C: Defense Protocol Level 9+), đồng thời song song với QN-4.12.2-02 (PnL Gauge).
  • Orphan-UC check: UC_4.12.5 xác nhận tồn tại trong WBS, status_design: "Done" nhưng KHÔNG có mapping_design/description — giống hoàn toàn tình trạng SIM UC_4.7.5.

Ghi chú Phase 2.5 — Impact Analysis

Không có state-changing action trực tiếp trên widget này (read-only display bar, chờ xác định công thức nguồn theo QN-4.12.5-01/03).

Changelog

DateVersionUpdated itemBeforeAfterNotes
2026-08-12v1Initial creation—5 QnA items (công thức LIVE per-level + Defense Protocol impact là gap chính; CR-13 nay đã resolve, khác SIM lúc trước)Init Flow Step 1+2. WBS record trống — nội dung synthesize từ SIM UC_4.7.5 + STAGE2-031 + Table A/C/F.
2026-08-12v1.1BA review — trả lời 3/5 câuToàn bộ ⏳ Chờ BAQN-4.12.5-01 ✅ Confirmed công thức (Market_Loss_When_Stopped × Daily_Loss_Ratio, ví dụ $25,000→$412.50 — ⚠️ bước tính trung gian chưa rõ); QN-4.12.5-02/05 ✅ Confirmed (đúng đề xuất); QN-4.12.5-03 ⏳ Chờ KH — pending khách xác nhận, KHÁC QN-4.12.2-02 (đã chốt dứt điểm)BA (Trang Nguyen) trả lời trực tiếp 2026-08-12

UC_4.12.5 — Daily Loss Limit (LIVE Global Shell)

Daily Loss Limit progress bar — Global Shell, Dashboard LIVE

SRS: UC_4.12.5 — Daily Loss Limit Bar (LIVE)

Next Page

On this page

⚠️ Lưu ý đặc biệt: WBS record trốngCarried-forward context (đã confirm ở dashboard_common/UC_4.1.1-4.1.5/QnA_init_docs.md và SIM UC_4.7.5, KHÔNG hỏi lại)Ghi chú Phase 2.2 — WBS Cross-UC Consistency CheckGhi chú Phase 2.5 — Impact AnalysisChangelog