Câu hỏi và giả định phát sinh trong quá trình Init Flow (Agent 1 Auditor + Agent 2 Challenger) cho module Overview, category STAGE 2: DASHBOARD - COMMON

QnA Init Docs — Dashboard Common — Overview (Performance Widgets)

Phạm vi UC: UC_4.2.1 (Position Monitor Table), UC_4.2.2 (The Pulse), UC_4.2.3 (Equity Curve), UC_4.2.4 (Profit factor), UC_4.2.5 (Win Rate) — module Overview, category STAGE 2: DASHBOARD - COMMON (WBS xác nhận qua node script/parse_wbs.js --compact).

Ngày tạo: 2026-08-08 Ngày BA review: 2026-08-08 Phiên bản: v1 BA phụ trách: Trang Nguyen Trạng thái: ✅ BA đã trả lời toàn bộ A-00 → A-15 — sẵn sàng cho Step 3 (Architect viết SRS)

Ghi chú nguồn quan trọng — WBS trống, nhưng đã tìm được nguồn Customer supplies chi tiết

Cả 5 UC đều KHÔNG có description/reference/mapping_be/mapping_fe/mapping_design trong WBS (References/WBS/BA internal - BA plan 2 - BA plan 2.csv). Tuy nhiên, đã tìm được nguồn ★★★ (Customer supplies V7) mô tả đầy đủ công thức tính và cấu trúc dữ liệu cho toàn bộ 5 widget này:

RFQ_ Website and Dashboard Implementation V7.pdf §Part C (dòng 557-900 bản extract dashboard_v7_full.txt) — mô tả UI/UX từng widget.
RFQ_ Stack Trading Prop Tech V7.pdf §3.2 "Calculations and Endpoints for our Dashboard" (dòng 382-611 bản extract v7_full.txt) — bảng WebSocket event.
RFQ_ Stack Trading Prop Tech V7.pdf §"Risk Metrics Logic Definitions" (dòng 2505-2657 bản extract v7_full.txt) — công thức tính chi tiết từng metric.
RFQ_ Stack Trading Prop Tech V7.pdf §"Risk Metrics Endpoints" (dòng 2657-2714 bản extract v7_full.txt) — REST endpoint cho load-trang-đầu.

Nội dung nguồn này khớp với phân tích nội bộ trước đó tại docs/BA/UC_58-72/Dashboard_Overview_Plan.md (viết dưới numbering UC_58-72 cũ, đã lỗi thời — xem ghi chú re-map bên dưới), nhưng KHÔNG phải Customer supplies chính thức — chỉ dùng làm tài liệu tham khảo nội bộ, mọi trích dẫn trong bảng dưới đây đều tự verify lại trực tiếp từ v7_full.txt/dashboard_v7_full.txt (dòng số đã tự đọc lại, không copy nguyên dòng số từ file cũ).

Re-map numbering (không phải câu hỏi, chỉ để đối chiếu khi đọc Dashboard_Overview_Plan.md):

UC hiện tại (WBS)	UC cũ trong `Dashboard_Overview_Plan.md`
UC_4.2.1 Position Monitor Table	UC_70
UC_4.2.2 The Pulse	UC_73 (subset)
UC_4.2.3 Equity Curve	UC_73 (subset)
UC_4.2.4 Profit factor	UC_73 (subset)
UC_4.2.5 Win Rate	UC_73 (subset)

[MISSING_DEPENDENCY] UC_4.3 "12 Performance Metrics" chưa có SRS — nguy cơ duplicate nội dung

WBS xác nhận có UC_4.3 (category STAGE 2: DASHBOARD - COMMON, module Performance, function "12 Performance Metrics", status Todo) — đây là trang Performance đầy đủ, sở hữu 12 metric bao gồm cả 4 metric đang viết ở đây (Pulse, Profit Factor, Win Rate nằm trong "Risk Stats"/"Behavioral Stats"; Equity Curve cũng là 1 trong 12 metric).

Theo nguyên tắc Single Source of Truth (global-rules.md), công thức đầy đủ của 1 metric chỉ nên được định nghĩa Ở MỘT NƠI. Vì UC_4.3 chưa được viết (Todo), 4 widget Overview (UC_4.2.2/4.2.3/4.2.4/4.2.5) hiện đang là nơi đầu tiên viết công thức các metric này — cần BA quyết định hướng xử lý.

ID	Câu hỏi	Giả định (BA/QC đề xuất)	BA chốt (ưu tiên cao nhất)	Trạng thái
A-00	UC_4.2.2/4.2.3/4.2.4/4.2.5 (widget Overview) nên viết công thức đầy đủ ngay bây giờ (vì UC_4.3 chưa tồn tại), hay chỉ mô tả UI hiển thị rút gọn + để trống phần công thức chờ UC_4.3?	Viết công thức đầy đủ ngay trong UC_4.2.x lần này (tránh block công việc), kèm ghi chú rõ trong SRS: "Công thức định nghĩa tại đây; khi UC_4.3 được viết, UC_4.3 sẽ là nguồn canonical và UC_4.2.x sẽ update thành Markdown link tới UC_4.3 thay vì lặp lại nội dung."	Đúng như đề xuất: Viết công thức đầy đủ ngay trong UC_4.2.x lần này (tránh block công việc), kèm ghi chú rõ trong SRS: "Công thức định nghĩa tại đây; khi UC_4.3 được viết, UC_4.3 sẽ là nguồn canonical và UC_4.2.x sẽ update thành Markdown link tới UC_4.3 thay vì lặp lại nội dung."	✅ Đã chốt

Bảng QnA & Assumption

UC_4.2.1 — Position Monitor Table

Nguồn: RFQ_ Website and Dashboard Implementation V7.pdf §Part C ("Position Monitor. This will be a live grid showing Open Positions, Average Entry, P&L etc. Must include an 'Est. Swap' column to account for overnight fees on Forex pairs.") · RFQ_ Stack Trading Prop Tech V7.pdf §3.2 event POSITION_METRICS (streams {symbol, side, net_pos, unrealized_pnl, realized_pnl, total_pnl, est_swap}, throttle 1000ms, bắn mỗi khi fill/partial-fill/close) · §Risk Metrics Logic Definitions "PnL Breakdown" (Unrealized = Σ((Current Price − Avg Entry)×Position Size×Tick Value); Realized = Σ Net PnL các lệnh đóng trong session; Total = Unrealized + Realized).

ID	Câu hỏi	Giả định (BA/QC đề xuất)	BA chốt (ưu tiên cao nhất)	Trạng thái
A-01	Cột "Average Entry" — `dashboard_v7_full.txt` liệt kê rõ cột này trong UI requirement, nhưng payload `POSITION_METRICS` (`v7_full.txt` §3.2) KHÔNG có field `avg_entry_price`/tương đương. Đây là gap thật giữa 2 nguồn ★★★ cùng cấp (UI spec có, WS payload spec thiếu). Cột này lấy dữ liệu từ đâu?	Đề xuất: đây là thiếu sót phía BE spec — BE cần bổ sung field `avg_entry_price` (float) vào payload `POSITION_METRICS`. KHÔNG tự ý bỏ cột "Average Entry" khỏi SRS vì nguồn UI yêu cầu rõ ràng.	BA bác đề xuất. UI trong wireframe thực tế cũng không có thông tin này nên không cần thêm thông tin này.	❌ Rejected (đề xuất giữ cột bị bác) — [SCOPE FIX]: bỏ hẳn cột "Average Entry" khỏi scope UC_4.2.1, không cần BE bổ sung field `avg_entry_price`.
A-02	`est_swap` cho vị thế Futures — nguồn ghi rõ Est. Swap chỉ để "account for overnight fees on Forex pairs". Với vị thế Futures, cột này hiển thị gì?	Hiển thị `0.00` (payload vẫn trả field `est_swap` cho mọi position, BE set = 0 cho Futures) — không ẩn cột, vì bảng cần hiển thị đồng nhất khi user có thể mở cả vị thế Futures lẫn Forex cùng lúc (multi-asset).	BA bác đề xuất "hiển thị $0 cho Futures". Chỉ hiển thị cột `est_swap` cho Forex track — ẩn hoàn toàn cột này với Futures (không hiển thị $0, ẩn cả cột). Bổ sung Business Rule mới về hành vi hiển thị: (1) Frontend Rendering & Visibility Window: cột Est. Swap animate vào view đúng 60 phút trước giờ Forex rollover (16:00 CT / 17:00 EST), và biến mất 1 phút sau khi rollover hoàn tất. Nếu cột đã hiện nhưng BE chưa push dữ liệu swap → hiển thị placeholder trung tính (hoặc `$0`). (2) Dynamic Streaming: mỗi khi BE nhận ước tính swap mới từ execution gateway, push `est_swap` cập nhật qua kênh `POSITION_METRICS` WS như bình thường (vẫn tuân thủ throttle 1 evaluation/giây). (3) Asynchronous Updates: bảng FE update từng row độc lập theo dữ liệu đến (per position/symbol) — KHÔNG chờ tính toán đồng bộ theo batch cho toàn bộ vị thế cùng lúc.	✅ Đã chốt (thay thế đề xuất ban đầu) — [SCOPE FIX]: `est_swap` chỉ hiện cho Forex, ẩn hoàn toàn với Futures, kèm Business Rule visibility window mới.
A-03	Totals row — nguồn không mô tả rõ totals row cộng dồn những cột nào.	Totals row cộng: `unrealized_pnl`, `realized_pnl`, `total_pnl`, `est_swap`. KHÔNG cộng `net_pos` (không có ý nghĩa nghiệp vụ khi cộng dồn units của nhiều symbol khác nhau).	BA bác đề xuất. Trên UI và mô tả không có thông tin totals row.	❌ Rejected (đề xuất tính totals row bị bác) — [SCOPE FIX]: KHÔNG có totals row trong UC_4.2.1, bỏ khỏi scope.
A-04	Empty state — không có mô tả UI khi không có open position nào. [PATTERN] — dạng câu hỏi này có thể lặp lại ở nhiều bảng dữ liệu khác trong dự án, đề xuất chuẩn hoá vào `common_rules.md` nếu BA xác nhận cùng 1 pattern áp dụng toàn hệ thống.	Hiển thị empty state text "No open positions" giữa bảng (thay placeholder rows).	Đúng như đề xuất: hiển thị empty state text "No open positions" giữa bảng (thay placeholder rows).	✅ Đã chốt
A-05	Overflow cột Symbol — global-rules yêu cầu mọi cột text phải khai overflow behavior, nguồn không mô tả.	Symbol: Truncate with tooltip (Ref: CR-10 Tooltip Interaction) nếu vượt độ rộng cột. Side: hiển thị dạng Badge (Long/Short), không cần overflow rule riêng.	Đúng như đề xuất: Symbol dùng Truncate with tooltip (Ref: CR-10 Tooltip Interaction) nếu vượt độ rộng cột; Side hiển thị dạng Badge (Long/Short), không cần overflow rule riêng.	✅ Đã chốt

UC_4.2.2 — The Pulse

Nguồn: RFQ_ Stack Trading Prop Tech V7.pdf §Risk Metrics Logic Definitions "Pulse Score" — reset về 100 đầu mỗi phiên (Exchange Reset: 18:00 EST Futures / 17:00 EST Forex). Deductions: -25 (Averaging Down — đặt lệnh cùng chiều/cùng symbol khi Unrealized P&L đang âm), -20 (Increasing Risk — dời Hard Stop xa hơn giá thị trường), -15 (Erratic Sizing — khối lượng lệnh > 2× khối lượng trung bình 10 lệnh gần nhất, bỏ qua partial fill). Rewards: +5 (Pyramiding — thêm vị thế cùng chiều khi đang lãi), +10 (Reducing Risk — dời Hard Stop gần hơn giá thị trường/chốt lời). Endpoint Get Pulse History (GET, user_id + limit, trả Array[[timestamp_utc, integer_score]]).

ID	Câu hỏi	Giả định (BA/QC đề xuất)	BA chốt (ưu tiên cao nhất)	Trạng thái
A-06	[INTRA_RULE_CONTRADICTION tiềm ẩn — cơ chế cập nhật real-time] Đã kiểm tra kỹ payload `PERFORMANCE_UPDATE` WS (`v7_full.txt` §3.2, dòng 409-432): chỉ có `sharpe_ratio, sortino_ratio, profit_factor, win_rate_percent, avg_win, avg_loss, latest_trade{...}, holding_time{...}` — KHÔNG có field `pulse_score`. Đồng thời `PERFORMANCE_UPDATE` chỉ fires "upon the closure of a trade", trong khi Pulse Score deduction/reward xảy ra tại thời điểm đặt lệnh/sửa lệnh (Averaging Down, Increasing Risk, Erratic Sizing đều là hành động submit/modify order — không nhất thiết trùng thời điểm đóng lệnh). Vậy widget "The Pulse" cập nhật real-time bằng cơ chế nào?	Không có safe default rõ ràng — đề xuất cần 1 WS event riêng (vd `PULSE_UPDATE`) fire tại thời điểm order action ảnh hưởng điểm, hiện CHƯA có trong bảng §3.2 nguồn — đây là gap kiến trúc thật, không phải chỉ thiếu UI. Tạm thời: [ASSUMPTION] FE poll `GET /pulse-history?limit=1` mỗi 30s làm giải pháp tạm cho tới khi BE xác nhận cơ chế push.	Khách (client) đã bổ sung xác nhận trực tiếp: cơ chế real-time là qua WebSocket, bổ sung field mới `current_pulse_score` vào payload (field mới — client note "add new"). Đây là field bổ sung vào cơ chế push hiện có, không cần FE polling như đề xuất tạm.	✅ Đã chốt (thay thế giả định polling) — BE bổ sung field `current_pulse_score` vào WS payload (client chưa nêu chính xác field này gắn vào event nào trong bảng §3.2 hiện có hay là 1 event mới — Architect ghi rõ tên field `current_pulse_score` khi viết SRS, note phần "tên event cụ thể" là chi tiết kỹ thuật để BE xác nhận thêm, không block viết SRS).
A-07	UI representation trên Overview — nguồn chỉ định nghĩa công thức tính điểm (0-100), không mô tả cách hiển thị widget rút gọn trên Overview (số đơn thuần, hay kèm label trạng thái/mini trend).	[ASSUMPTION] hiển thị số điểm hiện tại (0-100) + label trạng thái ngắn dạng text (chưa có ngưỡng cụ thể cho label, cần BA bổ sung nếu muốn dùng). Không có mini sparkline (khác PnL Gauge).	BA sửa lại đề xuất. Trên UI không hiển thị thông tin trạng thái (label), chỉ hiển thị số đơn thuần.	✅ Đã chốt (đơn giản hơn đề xuất) — UC_4.2.2 chỉ hiển thị số điểm 0-100, KHÔNG có label trạng thái, KHÔNG có mini sparkline.
A-08	Xem [MISSING_DEPENDENCY] UC_4.3 ở đầu tài liệu — công thức Pulse Score viết ở đây có nguy cơ duplicate với UC_4.3.	Xem A-00.	Xem A-00.	✅ Đã chốt (tham chiếu A-00)

UC_4.2.3 — Equity Curve

Nguồn: RFQ_ Stack Trading Prop Tech V7.pdf §Risk Metrics Logic Definitions "Equity Curve" — time-series account balance, input = Daily Balance snapshots, output = Array[Timestamp, Value]. Endpoint Get Equity Curve (GET, user_id + timeframe [1D/1W/1M], "Triggered on page load and when the user clicks the 1D/1W/1M filter").

ID	Câu hỏi	Giả định (BA/QC đề xuất)	BA chốt (ưu tiên cao nhất)	Trạng thái
A-09	1D/1W/1M filter — gọi lại API mỗi lần đổi filter, hay pre-fetch cả 3 timeframe 1 lần? Nguồn ghi "triggered ... when the user clicks the filter" → gợi ý gọi lại mỗi lần đổi.	Gọi lại `GET /equity-curve?timeframe=` mỗi lần user đổi filter (không cache/pre-fetch cả 3 cùng lúc).	Đúng như đề xuất: gọi lại `GET /equity-curve?timeframe=` mỗi lần user đổi filter (không cache/pre-fetch cả 3 cùng lúc).	✅ Đã chốt
A-10	[CROSS_UC_CONFLICT tiềm ẩn — xuyên 2 folder tài liệu] `dashboard_v7_full.txt` §Part C mô tả PnL Gauge (UC_4.8.1, folder `dashboard_sim`) có "mini equity curve sparkline showing PnL over time" — cùng loại dữ liệu với Equity Curve full ở đây, chỉ khác cách hiển thị. Dùng chung 1 endpoint `GET /equity-curve` (PnL Gauge gọi với timeframe cố định để render bản rút gọn), hay 2 nguồn dữ liệu riêng? Câu hỏi này đã được đưa song song vào QnA của UC_4.8.1 (`dashboard_sim/UC_4.8.1/QnA_init_docs.md`) — BA chỉ cần trả lời 1 lần, áp dụng cho cả 2 UC.	Dùng chung 1 endpoint `GET /equity-curve?timeframe=`, PnL Gauge gọi cố định `timeframe=1D` để tránh duplicate logic tính toán.	Đúng như đề xuất: dùng chung 1 endpoint `GET /equity-curve?timeframe=`, PnL Gauge (UC_4.8.1) gọi cố định `timeframe=1D` để tránh duplicate logic tính toán. Áp dụng đồng thời cho UC_4.8.1.	✅ Đã chốt
A-11	Empty state ngày đầu tiên — user mới tạo account, chưa có snapshot balance nào. Đường Equity Curve hiển thị gì?	[ASSUMPTION] hiển thị đường phẳng tại giá trị starting balance/Notional cho tới khi có snapshot đầu tiên (chưa có nguồn xác nhận).	Đúng như đề xuất: hiển thị đường phẳng tại giá trị starting balance/Notional cho tới khi có snapshot đầu tiên.	✅ Đã chốt

UC_4.2.4 — Profit factor

Nguồn: RFQ_ Stack Trading Prop Tech V7.pdf §Risk Metrics Logic Definitions "Profit Factor" — Gross Profit (Σ|PnL| lệnh thắng) / Gross Loss (Σ|PnL| lệnh thua), scope "current level closed trades"; nếu Gross Loss = 0 → trả Gross Profit (tránh chia 0). Xuất hiện ở 2 nguồn dữ liệu: Get Core Performance (scope "current level", trả profit_factor) và Get Win Rate Grid Data (scope theo lookback 10/30/50/100/200 trades, trả period_profit_factor) — 2 field cùng tên nghiệp vụ nhưng khác scope.

ID	Câu hỏi	Giả định (BA/QC đề xuất)	BA chốt (ưu tiên cao nhất)	Trạng thái
A-12	Scope hiển thị trên Overview — "current level" (toàn bộ trade từ khi lên level hiện tại) hay theo lookback window?	Overview widget dùng scope "current level" (nguồn `Get Core Performance`/`PERFORMANCE_UPDATE` WS) — không có lookback selector trên Overview (selector chỉ ở trang Performance đầy đủ UC_4.3, xem A-00).	Đúng như đề xuất: scope "current level" (toàn bộ trade từ khi lên level hiện tại).	✅ Đã chốt
A-13	Chưa có trade nào đóng (Gross Profit = Gross Loss = 0) — công thức nguồn chỉ cover trường hợp Gross Loss = 0 VÀ Gross Profit > 0 (trả Gross Profit), chưa cover trường hợp cả 2 = 0.	[ASSUMPTION] hiển thị "—" khi chưa có trade nào đóng ở level hiện tại (phân biệt rõ với trường hợp Profit Factor = giá trị Gross Profit khi toàn bộ lệnh đều thắng).	BA sửa lại đề xuất. Chưa có trade nào thì clamp về `0` (không dùng "—").	❌ Rejected một phần (đề xuất "—" bị thay) — Final: hiển thị `0` khi chưa có trade nào đóng ở level hiện tại, không dùng "—".

UC_4.2.5 — Win Rate

Nguồn: RFQ_ Stack Trading Prop Tech V7.pdf §Risk Metrics Logic Definitions "Win Rate & RR" — Win Rate % = (số lệnh thắng / tổng số lệnh) × 100, scope "All closed trades". Endpoint Get Core Performance trả win_rate_percent (scope current level); endpoint Get Win Rate Grid Data trả thêm trade_results: [boolean...] (dùng để render dot grid đỏ/xanh theo lookback).

ID	Câu hỏi	Giả định (BA/QC đề xuất)	BA chốt (ưu tiên cao nhất)	Trạng thái
A-14	Dạng hiển thị trên Overview — số % đơn giản (theo `Get Core Performance`) hay dot grid trực quan (theo `Get Win Rate Grid Data`)? 2 endpoint đều liên quan Win Rate nhưng UI hoàn toàn khác nhau.	Overview widget = số % đơn giản (`win_rate_percent`, scope current level) — dot grid chi tiết theo lookback thuộc trang Performance đầy đủ (UC_4.3, xem A-00).	Đúng như đề xuất: Overview widget = số % đơn giản (`win_rate_percent`, scope current level) — dot grid chi tiết theo lookback thuộc trang Performance đầy đủ (UC_4.3).	✅ Đã chốt
A-15	[Lưu ý cho Architect — không phải câu hỏi cần BA trả lời] `dashboard_v7_full.txt` §Part C liệt kê "Trade Efficiency Matrix (Scatter Plot — rendered in UI as 'Win rate vs. risk/reward')" — đây là UI label gây nhầm lẫn: về công thức, đây là metric MFE Trade Efficiency (%), KHÔNG phải Win Rate %. Khi viết SRS (Step 3), Architect cần phân biệt rõ 2 khái niệm, không gộp nhầm nội dung "Trade Efficiency Matrix" vào UC_4.2.5.	— (ghi chú kỹ thuật, không cần BA chốt)	—	✅ Đã resolve qua research

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

CR Conflict Check: Đã đọc References/CR/_CR_INDEX.md (24 CR active) — không có CR nào tham chiếu trực tiếp Position Monitor/Pulse/Equity Curve/Profit Factor/Win Rate/module Overview. CR-20260727-005 (Data-Feed Lock Banner) và CR-20260806-001 (Sidebar Logout) đều đã được gán vào UC_4.1.1/UC_4.1.2/UC_4.1.4 theo QnA đã confirm (dashboard_common/UC_4.1.1-4.1.5/QnA_init_docs.md A-09/A-10) — không ảnh hưởng cụm UC_4.2.x.
Same-category consistency: Sibling UC cùng category STAGE 2: DASHBOARD - COMMON: UC_4.1.1-4.1.5 (Global Shell, đã có SRS), UC_4.3 "12 Performance Metrics" (module Performance, Todo — xem [MISSING_DEPENDENCY] A-00), UC_4.4 (Journal/Calendar, Todo, không overlap trực tiếp).
Cross-folder dependency: UC_4.2.3 (Equity Curve, dashboard_common) ↔ UC_4.8.1 (PnL Gauge mini sparkline, dashboard_sim) — xem A-10.
Orphan-UC check: Cả 5 UC_ID (UC_4.2.1 → UC_4.2.5) đã xác nhận tồn tại trong WBS qua node script/parse_wbs.js --compact — không phải orphan.
Trading Functionality note: dashboard_v7_full.txt §Part C ghi rõ "Trading Functionality: None. Execution happens on external platforms." — xác nhận toàn bộ Dashboard (bao gồm 5 widget này) là read-only display, không có action đặt/sửa/hủy lệnh trực tiếp trên Dashboard.

Ghi chú Phase 2.5 — Impact Analysis

Không phát hiện state-changing action trực tiếp trên 5 widget này (toàn bộ là read-only display, dữ liệu đến từ WebSocket push hoặc REST GET). Không cần Impact Analysis table cho create/edit/delete/toggle vì các widget không có action nào thuộc loại này.

Hướng dẫn cho BA

✅ BA đã trả lời toàn bộ A-00 → A-15 (2026-08-08, xem cột "BA chốt"/"Trạng thái" trong từng bảng ở trên). Tóm tắt các điểm BA chốt khác với đề xuất ban đầu (Architect cần đặc biệt lưu ý khi viết SRS, KHÔNG dùng giả định gốc):

A-01: Bỏ hẳn cột "Average Entry" khỏi UC_4.2.1 (khác đề xuất ban đầu — đề xuất muốn giữ + raise BE).
A-02: est_swap ẩn hoàn toàn với Futures (không phải hiển thị $0 như đề xuất), kèm Business Rule mới về visibility window (60 phút trước/1 phút sau Forex rollover) + dynamic streaming + async per-row update.
A-03: Không có totals row (khác đề xuất ban đầu muốn tính tổng 4 cột).
A-06: BE bổ sung field current_pulse_score vào WS payload (khác đề xuất tạm dùng polling GET /pulse-history).
A-07: Chỉ hiển thị số điểm Pulse đơn thuần, không có label trạng thái (đơn giản hơn đề xuất).
A-13: Clamp về 0 khi chưa có trade nào đóng (khác đề xuất hiển thị "—").

Các câu còn lại (A-00, A-04, A-05, A-09, A-10, A-12, A-14) được confirm đúng như đề xuất ban đầu.

Sẵn sàng tiến hành Step 3 — Architect viết SRS cho UC_4.2.1 → UC_4.2.5.

Changelog

Date	Version	Updated item	Before	After	Notes
2026-08-08	v1	Initial creation	—	15 QnA items (A-01→A-15) + A-00 MISSING_DEPENDENCY	Init Flow Step 1+2, folder mới tạo cho module Overview (dashboard_common)
2026-08-08	v1.1	BA review — trả lời toàn bộ A-00→A-15	Toàn bộ ⏳ Chờ BA	Toàn bộ ✅ Đã chốt (A-01/A-02/A-03/A-06/A-07/A-13 khác đề xuất ban đầu — xem "Hướng dẫn cho BA")	BA (Trang Nguyen) trả lời trực tiếp qua chat 2026-08-08

QnA Init Docs — UC_4.2.1-4.2.5: Dashboard Common — Overview (Performance Widgets)