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

QnA Init Docs — Dashboard Common — Performance (12 Performance Metrics)

Phạm vi UC: UC_4.3 (12 Performance Metrics) — module Performance, category STAGE 2: DASHBOARD - COMMON (WBS xác nhận qua node script/parse_wbs.js --compact).

Ngày tạo: 2026-08-09 Ngày BA review: 2026-08-09 Phiên bản: v1 BA phụ trách: Trang Nguyen Trạng thái: ✅ BA đã trả lời toàn bộ A-01 → A-18 — 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 + Wireframe chi tiết

WBS row của UC_4.3 (References/WBS/BA internal - BA plan 2 - BA plan 2.csv, dòng 164) chỉ có module=Performance, function=12 Performance Metrics, uc_id=UC_4.3 — không có description/reference/mapping_be/mapping_fe. Đã tìm được nguồn ★★★ (Customer supplies V7) + Wireframe mới bổ sung (chưa commit) mô tả đầy đủ:

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 cho 12 metric: Sharpe Ratio, Sortino Ratio, Profit Factor, Win Rate, Risk/Reward, PnL Breakdown, Pulse Score, Holding Time, Avg Win vs Loss, Drawdown Heatmap, Equity Curve, Trade Efficiency (MFE). Đếm chính xác 12 metric (dòng "Win Rate & RR" trong bảng nguồn gộp 2 metric Win Rate + Risk/Reward → khớp tên UC "12 Performance Metrics").
RFQ_ Stack Trading Prop Tech V7.pdf §"Risk Metrics Endpoints" (dòng 2657–2720 bản extract v7_full.txt) — 5 REST endpoint: Get Equity Curve, Get Pulse History, Get Core Performance, Get Win Rate Grid Data, Get Efficiency Matrix Data.
RFQ_ Website and Dashboard Implementation V7.pdf §Part C (dòng 557–590 bản extract dashboard_v7_full.txt) — "Agency A is responsible for calculating all metrics (Sharpe, Pulse, etc.) and generating LLM responses; you [Agency B/frontend] are responsible for consuming the API and visualizing them."
Wireframe (untracked, mới thêm vào References/Wireframe/Stage 2/Performances/): Performance Overview - Day 0.png (empty state) và Performance Overview V1.2.png (populated state) — 2 file này là nguồn UI/UX duy nhất cho trang Performance, hiện 5 widget card: Sharpe ratio, Sortino ratio, Avg. win vs. loss (kèm Risk/Reward ratio), Holding time analysis, Trade efficiency matrix.
Global Header (Days remaining / Squawk box / Daily loss limit / Close in / notification bell) và Sidebar hiện trong cả 2 wireframe thuộc phạm vi UC_4.1.1–4.1.5 (Global shell, đã có SRS) — KHÔNG document lại ở đây, chỉ tham chiếu.
UC_4.1.2 (Sidebar Navigation, đã có SRS) đã xác nhận tab "Performance" trên sidebar trỏ đến chính UC_4.3 này.

[MISSING_DEPENDENCY RESOLVED] Kế thừa quyết định A-00 từ UC_4.2.1-4.2.5

docs/BA/UC_4.1-4.17/dashboard_common/UC_4.2.1-4.2.5/QnA_init_docs.md (mục A-00, đã BA chốt 2026-08-08) đã xác định: UC_4.3 sẽ là 12 metric page, sở hữu cả 4 metric hiện đang tạm viết đầy đủ công thức tại UC_4.2.x (Pulse → UC_4.2.2, Equity Curve → UC_4.2.3, Profit Factor → UC_4.2.4, Win Rate → UC_4.2.5). Header note trong UC_4.2.1-4.2.5_v1.md (dòng 23–25) ghi: "When UC_4.3 is authored, it becomes the canonical source for these formulas, and UC_4.2.2/UC_4.2.4/UC_4.2.5 below must be updated to a Markdown link reference instead of repeating the formula text" — lưu ý header note này chỉ liệt kê 3 UC (4.2.2/4.2.4/4.2.5), không liệt kê UC_4.2.3 (Equity Curve), dù mục A-00 gốc (dòng 45) nói "công thức các metric này" bao hàm cả 4 widget. Đây là điểm KHÔNG khớp nội bộ giữa 2 chỗ trong cùng 1 file → xem A-01 bên dưới.

Hệ quả bắt buộc khi Step 3 (Architect) viết UC_4.3:

UC_4.3 phải là nơi chứa công thức đầy đủ (canonical) cho toàn bộ 12 metric.
Sau khi UC_4.3 hoàn thành, phải quay lại sửa UC_4.2.1-4.2.5_v1.md: xoá công thức trùng lặp ở UC_4.2.2 (Pulse), UC_4.2.4 (Profit Factor), UC_4.2.5 (Win Rate) — thay bằng Markdown link trỏ tới anchor tương ứng trong UC_4.3 — theo đúng nguyên tắc Single Source of Truth (global-rules.md).
Xoá dòng "## Note on UC_4.3 dependency" (không còn là dependency chưa xử lý) và cập nhật UC Index table của UC_4.2.1-4.2.5 để trỏ sang UC_4.3.

Bảng QnA & Assumption

Nhóm 1 — Phạm vi 12 metric & quan hệ với UC_4.2.x / UC khác

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	Equity Curve (UC_4.2.3) có migrate công thức sang UC_4.3 như 3 metric kia không? Note gốc (A-00) nói "công thức các metric này" cho cả 4 widget, nhưng header note thực tế trong file chỉ liệt kê 3/4 (thiếu Equity Curve).	Có — để nhất quán, Equity Curve cũng nên migrate. Tuy nhiên công thức Equity Curve rất đơn giản ("Time-series data of account balance", input = Daily Balance snapshots) nên rủi ro thấp nếu giữ nguyên tại UC_4.2.3. Đề xuất: migrate luôn cho nhất quán 100% với A-00 gốc.	Có — migrate công thức Equity Curve sang UC_4.3 làm nguồn canonical (đồng bộ với Pulse/Profit Factor/Win Rate). Lưu ý bổ sung của BA: theo 2 wireframe Performance hiện có (`Performance Overview - Day 0.png` / `V1.2.png`) KHÔNG có widget/chart nào hiển thị Equity Curve trên trang Performance — vậy công thức chỉ tồn tại dưới dạng canonical reference (Document References + Business Rule) trong UC_4.3, còn UI hiển thị Equity Curve vẫn ở UC_4.2.3 (Overview) như hiện tại, không thêm widget mới trên trang Performance.	✅ Đã chốt
A-02	PnL Breakdown (Unrealized/Realized/Total — account-level aggregate, KHÁC với PnL per-position đã có ở UC_4.2.1 Position Monitor) không xuất hiện trong wireframe Performance page. UC nào sở hữu widget này — UC_4.3, hay PnL Gauge (UC_4.8.1 SIM / UC_4.11.2 LIVE)?	Loại khỏi UC_4.3 v1 — thuộc phạm vi PnL Gauge (UC_4.8.1/UC_4.11.2, môi trường-specific, ngoài phạm vi dashboard_common). UC_4.3 chỉ tham chiếu công thức, không sở hữu UI.	Đúng như đề xuất — loại khỏi UC_4.3 v1, thuộc phạm vi PnL Gauge (UC_4.8.1/UC_4.11.2). UC_4.3 chỉ tham chiếu công thức, không sở hữu UI.	✅ Đã chốt
A-03	Drawdown Heatmap ("Total Account Equity − Level's Hard Stop Loss threshold" = khoảng cách tới breach) không xuất hiện trong wireframe Performance page, cũng không khớp UI nào khác đã biết (không phải Daily Loss Limit bar — đó là 1 progress bar khác công thức). UC nào sở hữu widget này?	Chưa có wireframe/UC nào claim — đánh dấu [NOT YET DESIGNED], loại khỏi UC_4.3 v1 scope, chỉ giữ công thức tham khảo trong Document References. Khi có wireframe mới sẽ mở UC riêng hoặc bổ sung vào UC_4.3.	Đúng như đề xuất — không có UI Drawdown Heatmap trong UC_4.3, chỉ giữ công thức tham khảo trong Document References.	✅ Đã chốt
A-04	Trang Performance dùng REST-only (`Get Core Performance` "Triggered only on page load") theo RFQ — khác hẳn Overview (UC_4.2.x) dùng WebSocket real-time streaming. Xác nhận: Performance KHÔNG cần live-update qua WebSocket, chỉ refresh dữ liệu khi load lại trang / user quay lại tab?	Đúng — theo đúng RFQ, không thêm WebSocket ngoài spec.	KHÁC đề xuất ban đầu — Performance CÓ live-update qua WebSocket. Cơ chế: `GET /core-performance` khi load trang (như RFQ), sau đó cập nhật live qua sự kiện `PERFORMANCE_UPDATE` WebSocket khi trade close — đồng bộ đúng cơ chế đã dùng cho Profit Factor/Win Rate/Pulse trên Overview (Ref: `UC_4.2.1-4.2.5_v1.md` §UC_4.2.4 Basic Flow bước 4: "On trade close, the `PERFORMANCE_UPDATE` WebSocket event pushes an updated `profit_factor`, and the widget updates live.").	✅ Đã chốt (KHÁC đề xuất ban đầu — Architect cần đặc biệt lưu ý)
A-05	Global Header (Daily loss limit bar, Squawk box, Close in timer...) và Sidebar hiện trong cả 2 wireframe Performance — xác nhận đây KHÔNG thuộc phạm vi UC_4.3 (đã có UC_4.1.1-4.1.5 / UC_4.7.5 SIM / UC_4.11.5 LIVE sở hữu), UC_4.3 chỉ tham chiếu.	Đúng — Single Source of Truth, không lặp lại nội dung Global Shell trong UC_4.3.	Đúng — Single Source of Truth, không lặp lại nội dung Global Shell trong UC_4.3.	✅ Đã chốt

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	Bell curve (chuông Gauss) trên 2 card Sharpe/Sortino — là static decorative asset hay dynamic vẽ theo phân phối dữ liệu thật? Backend `Get Core Performance` chỉ trả về `sharpe_ratio: float` và `sortino_ratio: float` (1 con số, KHÔNG có mảng phân phối). Wireframe Day 0 (empty state, không có dữ liệu) vẫn hiện y hệt hình chuông đầy đủ như wireframe V1.2 (có dữ liệu) — chỉ khác giá trị số + vị trí vạch đứt nét. → Đây là bằng chứng mạnh cho thấy đường cong là static SVG cố định, chỉ có vạch đứt nét (marker) di chuyển theo vị trí tương ứng giá trị `sharpe_ratio`/`sortino_ratio` trên trục X (0.5 / 1 / 1.5).	Xác nhận: bell curve là static asset cố định hình dạng; chỉ vị trí vạch đứt nét + giá trị số + label ("Good"/"Excellent") là dynamic theo `sharpe_ratio`/`sortino_ratio` trả về từ BE. KHÔNG cần BE trả thêm mảng phân phối cho chart này.	Xác nhận đúng như đề xuất: bell curve là static asset cố định hình dạng; chỉ vị trí vạch đứt nét + giá trị số + label ("Good"/"Excellent") là dynamic theo `sharpe_ratio`/`sortino_ratio` trả về từ BE. KHÔNG cần BE trả thêm mảng phân phối.	✅ Đã chốt
A-07	Ngưỡng label định tính ("Good", "Excellent" — quan sát trên wireframe V1.2: Sharpe 1.42 → "Good", Sortino 1.78 → "Excellent") — không có trong RFQ. Ngưỡng số chính xác cho từng label (Poor/Fair/Good/Excellent...?) là gì?	Không có default an toàn — đề xuất dùng thang phổ biến trong ngành (Sharpe: `< 0` Poor, `0–1` Fair, `1–2` Good, `> 2` Excellent) làm placeholder, nhưng CHỜ BA/khách xác nhận số chính xác trước khi đưa vào BR chính thức (không fabricate ngưỡng nghiệp vụ).	Có ngưỡng chính xác do khách cung cấp trực tiếp (BA confirmation, 2026-08-09): mapping từ giá trị ratio (backend `sharpe_ratio`/`sortino_ratio`) sang label — Excellent: ≥ 1.50 · Good: 1.00 – 1.49 · Subpar: 0.50 – 0.99 · Poor: ≤ 0.49. Áp dụng đồng nhất cho cả Sharpe Ratio và Sortino Ratio. Đối chiếu wireframe: Sharpe 1.42 → Good ✓ khớp; Sortino 1.78 → Excellent ✓ khớp — xác nhận đúng thang này, KHÔNG dùng thang đề xuất ban đầu (Poor/Fair/Good/Excellent 4 mốc khác).	✅ Đã chốt (nguồn: client-provided threshold — thay thế hoàn toàn giả định placeholder ban đầu)
A-08	"Retail" / "Elite" badge ở 2 góc dưới mỗi bell curve — ngưỡng benchmark là gì? Nguồn benchmark từ đâu (toàn bộ user base thật, hay ngưỡng tĩnh hard-code)?	Không có default an toàn — đề xuất tạm coi là 2 mốc tĩnh trên trục X (không phải benchmark động từ population data thật, vì BE không có endpoint tính benchmark population) — CHỜ BA xác nhận.	Xác nhận đúng đề xuất — 2 mốc tĩnh (static), không phải benchmark động từ population data thật. Ý nghĩa: "Retail" = ngưỡng hiệu suất nghiệp dư (amateur-tier), "Elite" = ngưỡng hiệu suất chuyên nghiệp (professional-tier) — 2 label mô tả định tính cố định ở 2 đầu trục X của chart, không gắn với 1 giá trị ranh giới số cụ thể cần BE tính toán.	✅ Đã chốt

Nhóm 3 — Avg win vs loss + Risk/Reward ratio

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	Thanh "tug of war" WIN (xanh) / LOSS (đỏ) chia theo tỷ lệ nào — theo % số lệnh thắng/thua (Win Rate), theo tỷ lệ $ Avg Win / Avg Loss, hay theo tỷ lệ Gross Profit/Gross Loss (Profit Factor)?	Đề xuất: theo tỷ lệ $ giữa Avg Win và Avg Loss (khớp trực tiếp với 2 số hiển thị ngay trên thanh) — không dùng Win Rate hay Profit Factor (2 số đó đã có widget riêng ở UC_4.2.4/4.2.5).	Đúng như đề xuất — theo tỷ lệ $ giữa Avg Win và Avg Loss (khớp trực tiếp 2 số hiển thị ngay trên thanh).	✅ Đã chốt
A-10	Icon mũi tên xu hướng (📈 cạnh Avg win, 📉 cạnh Avg loss) — ý nghĩa là gì? So sánh với kỳ trước (tuần/tháng trước)? Hay chỉ là icon trang trí cố định (📈 luôn cạnh Win, 📉 luôn cạnh Loss, không đổi theo dữ liệu)?	Đề xuất: icon trang trí cố định, không phải chart xu hướng động (không có nguồn BE nào cung cấp dữ liệu lịch sử để so sánh kỳ trước cho riêng 2 số này).	Đúng như đề xuất — icon trang trí cố định, không phải chart xu hướng động (không có nguồn BE nào cung cấp dữ liệu lịch sử để so sánh kỳ trước).	✅ Đã chốt
A-11	Risk/Reward ratio hiển thị format `"1.52:1"` — công thức nguồn (`v7_full.txt` §Risk Metrics) là "Average Win / Average Loss". Xác nhận format hiển thị đúng 2 chữ số thập phân theo CR-11 (numeric display) và làm tròn theo CR-13?	Đúng — áp dụng CR-11 + CR-13 tiêu chuẩn, không cần rule riêng.	Đúng — áp dụng CR-11 + CR-13 tiêu chuẩn, không cần rule riêng.	✅ Đã chốt

Nhóm 4 — Holding time analysis

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	Box "Risk Mitigation Audit" hiển thị text tự động sinh (ví dụ: "Cutting losing trades 62% faster than riding winning ones...") khớp với field `risk_mitigation_text: string` trong response `holding_time` của `Get Core Performance` (nguồn `v7_full.txt` dòng 2686). Nội dung text này do BE tự generate theo rule cố định (template dựa trên `avg_win_min`/`avg_loss_min`), hay do LLM (Gemini, giống GEKKO/The Desk Manager) generate tự do?	Đề xuất: BE generate theo template cố định (so sánh % chênh lệch avg_win_min vs avg_loss_min, điền vào câu mẫu có sẵn) — KHÔNG phải LLM-generated (RFQ không đề cập LLM cho phần này, khác hẳn The Desk Manager/GEKKO là AI riêng biệt).	Đúng như đề xuất — BE generate theo template cố định (so sánh % chênh lệch avg_win_min vs avg_loss_min, điền vào câu mẫu có sẵn), KHÔNG phải LLM-generated.	✅ Đã chốt
A-13	Trục Y của chart Holding Time Analysis chạy từ -100 đến 100 (không có đơn vị rõ ràng trên wireframe) — trong khi trục X là Holding Duration (phút, 0–75+min). Trục Y đại diện cho gì — mật độ phân phối (density, %) hay P&L trung bình tại mỗi khoảng thời gian giữ lệnh?	Không có default rõ ràng từ nguồn — đề xuất: trục Y là mật độ phân phối tương đối (density %, cùng cơ chế Gaussian Kernel Density Estimation mà BE dùng để sinh toạ độ `wins_distribution`/`losses_distribution` — Ref nguồn `v7_full.txt` §Holding Time, "Node.js backend must apply a Gaussian Kernel Density Estimation function... Output 50 evenly spaced X and Y coordinate points"), phần Win vẽ dương (trên trục 0), phần Loss vẽ âm (dưới trục 0, giá trị Y là -density) để tạo hiệu ứng "mirror".	Đúng như đề xuất — trục Y là mật độ phân phối tương đối (density %) sinh bằng Gaussian Kernel Density Estimation, Win vẽ dương/Loss vẽ âm để tạo hiệu ứng mirror.	✅ Đã chốt

Nhóm 5 — Trade efficiency matrix

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	Overlay "Sweet spot" / "Elite performance zone" trên chart — là vùng tính động theo cụm điểm dữ liệu thật của user (dynamic clustering), hay là 1 khung toạ độ cố định (static zone, ví dụ luôn nằm ở góc trên-phải X>75%, Y>3.1)?	Đề xuất: static zone cố định theo toạ độ cứng (góc trên-phải của chart) — không có nguồn BE nào tính toán "zone" động; endpoint `Get Efficiency Matrix Data` chỉ trả về mảng điểm `{timestamp_utc, trade_efficiency_percent, risk_reward}`, không có field zone/cluster.	Đúng như đề xuất — static zone cố định theo toạ độ cứng (góc trên-phải), không có tính toán "zone" động từ BE.	✅ Đã chốt
A-15	Dropdown lookback ở góc phải widget hiện mặc định "Last 100 trades" — endpoint `Get Efficiency Matrix Data` hỗ trợ `lookback_count` (Integer: 10, 30, 50, 100, 200). Xác nhận dropdown có đủ 5 option này (giống UC_4.2.5 Win Rate Grid đã dùng cùng bộ giá trị), mặc định chọn 100?	Đúng — đồng bộ 5 option với UC_4.2.5 (10/30/50/100/200), mặc định 100 theo wireframe.	Đúng — đồng bộ 5 option với UC_4.2.5 (10/30/50/100/200), mặc định 100 theo wireframe.	✅ Đã chốt
A-16	Trục X (0%–100%) = `trade_efficiency_percent` (MFE Efficiency), trục Y (0–4.1) = `risk_reward` per-trade — mỗi chấm tròn = 1 lệnh đã đóng, màu xanh = Winning trades / đỏ = Losing trades (khớp legend cuối chart). Xác nhận đúng mapping trục theo response `Get Efficiency Matrix Data`?	Đúng theo cấu trúc response nguồn — không cần hỏi thêm.	Đúng theo cấu trúc response nguồn — không cần hỏi thêm.	✅ Đã chốt

Nhóm 6 — Empty state (Day 0) & vòng đời dữ liệu

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-17	Toàn bộ 5 widget ở trạng thái Day 0 (chưa có lệnh nào) hiển thị placeholder `"--"` cho giá trị số, nhưng riêng "Avg. win vs. loss" hiển thị `"--"` kèm icon mũi tên vẫn còn nguyên (📈/📉), và Risk/Reward ratio hiển thị `"--"`. Xác nhận toàn bộ 5 widget dùng chung 1 pattern empty-state: giữ nguyên layout/chart tĩnh, chỉ thay số liệu động bằng `"--"`?	Đúng — pattern nhất quán trên toàn bộ 5 widget, khớp trực tiếp với 2 file wireframe (Day 0 vs V1.2 chỉ khác nhau ở phần số liệu/marker động).	Đúng — pattern nhất quán trên toàn bộ 5 widget, khớp trực tiếp với 2 file wireframe (Day 0 vs V1.2 chỉ khác nhau ở phần số liệu/marker động).	✅ Đã chốt
A-18	Impact khi user Reset (SIM) / Re-Buy (LIVE) / chuyển Level — 12 metric này có scope "current level" (theo `Get Core Performance` — "Calculates the global metrics for the user's current level"). Khi user pass level lên level mới, hoặc Reset/Rebuy sau khi Fail (Ref: STAGE2-020→030 trong `QnA_STAGE2_DASHBOARD_EVALUATION.md`) — toàn bộ 12 metric có reset về trạng thái Day 0 (0 lệnh) không, đồng bộ với việc trade history được archive sang `user_account_history`?	Có — đồng bộ với STAGE2-002 (Reset/Rebuy: "The active dashboard view and charts reset to zero") đã được client confirm cho toàn bộ dashboard. Áp dụng tương tự cho trang Performance.	Có — đồng bộ với STAGE2-002 (Reset/Rebuy: "The active dashboard view and charts reset to zero") đã được client confirm cho toàn bộ dashboard. Áp dụng tương tự cho trang Performance.	✅ Đã chốt
A-19	BR_4.3.8 gộp 2 nội dung (Live update WebSocket + Reset khi Level change/Reset/Re-buy) dưới 1 rule, và liệt kê "advances to a new level" là 1 trigger reset riêng biệt — giống hàm ý level up sẽ đưa widget về lại trạng thái Day 0 như 1 hành động "reset" chủ động. BA đặt câu hỏi ngược lại: level up có thực sự nên "back về Day 0" không, hay đó chỉ là hệ quả tự nhiên của scope "current level" đã có sẵn ở BR_4.3.7/BR_4.3.4/BR_4.3.5 (không phải 1 rule reset riêng cần đặc tả)?	Đề xuất: xoá BR_4.3.8, tách phần Live update sang Basic Flow step 7 (đã có nội dung tương đương), phần "reset khi level up" không cần rule riêng — vì BR_4.3.7 (Empty State Day 0, scope theo current level) đã tự nhiên cover trường hợp này khi user vừa lên level mới (0 lệnh đóng ở level mới).	Xác nhận theo đề xuất — xoá BR_4.3.8. Giữ nguyên BR_4.3.7 (scope "current level", không thêm ngoại lệ cho level-up). Xác nhận rõ: khi user lên level mới, 12 metric vẫn hiển thị Day 0 empty state vì chưa có lệnh đóng ở level mới — đây là hệ quả của scope hiện có, không phải hành vi mới, không phải regression so với yêu cầu ban đầu ("level up không back Day 0") vì bản chất user đang ở "Day 0 của level mới", không phải "Day 0 của tài khoản".	✅ Đã chốt

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

CR Conflict Check: Đã đọc References/CR/_CR_INDEX.md toàn bộ 25 CR — không có CR nào ảnh hưởng trực tiếp module Performance/12 Performance Metrics.
QnA Pre-Check: Đã đọc toàn bộ References/QnA from clients/03_STAGE2_DASHBOARD_EVALUATION/QnA_STAGE2_DASHBOARD_EVALUATION.md (27 câu đã trả lời) — không có câu nào trả lời trực tiếp chi tiết UI/công thức của Sharpe/Sortino/Holding Time/Trade Efficiency; chỉ có STAGE2-002 liên quan gián tiếp (Reset/Rebuy reset dashboard) → dùng cho A-18.
Same-category consistency: Sibling UC cùng category STAGE 2: DASHBOARD - COMMON: UC_4.1.1-4.1.5 (Global Shell, đã có SRS, tham chiếu không lặp lại), UC_4.2.1-4.2.5 (Overview, đã có SRS — xem [MISSING_DEPENDENCY RESOLVED] ở trên, quan hệ 2 chiều bắt buộc update sau khi UC_4.3 hoàn thành), UC_4.4 (Journal/Calendar, đang init song song, không overlap trực tiếp với UC_4.3 — Journal dùng dữ liệu P&L theo ngày, Performance dùng dữ liệu theo lệnh/level, không trùng widget).
Cross-folder dependency: PnL Breakdown (A-02) → có thể thuộc UC_4.8.1 (PnL Gauge, dashboard_sim, chưa có SRS) / UC_4.11.2 (PnL Gauge, dashboard_live, chưa có SRS). Drawdown Heatmap (A-03) → chưa xác định UC sở hữu, có thể là UC mới chưa mở trong WBS.
Orphan-UC check: UC_4.3 xác nhận tồn tại trong WBS qua node script/parse_wbs.js --compact (category STAGE 2: DASHBOARD - COMMON, module Performance) — không phải orphan.
Trading Functionality note: Kế thừa từ UC_4.2.x — toàn bộ Dashboard là read-only display, Performance page không có action đặt/sửa/hủy lệnh.

Ghi chú Phase 2.5 — Impact Analysis

Trang Performance là read-only (không có action tạo/sửa/xoá dữ liệu trực tiếp trên trang này — toàn bộ dữ liệu do BE tính sẵn và trả về qua REST). Duy nhất 1 "state-changing action" gián tiếp ảnh hưởng: chọn lookback_count trên dropdown Trade Efficiency Matrix → gọi lại API Get Efficiency Matrix Data, không có cascade effect, không cần confirmation popup, không có uniqueness constraint.
Impact từ UC khác vào trang này: Reset/Rebuy (A-18), chuyển Level (A-18) → đã có QnA STAGE2 hỗ trợ.

Hướng dẫn cho BA

✅ BA đã trả lời toàn bộ A-01 → A-18 (2026-08-09, 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: Equity Curve — migrate công thức sang UC_4.3 (đồng ý), nhưng KHÔNG có widget/chart Equity Curve nào trên trang Performance theo wireframe hiện có — chỉ là canonical reference, UI vẫn ở UC_4.2.3.
A-04: Performance CÓ live-update qua WebSocket (PERFORMANCE_UPDATE, đồng bộ cơ chế đã dùng ở UC_4.2.4) — ngược hẳn với đề xuất ban đầu là REST-only theo literal RFQ text. Đây là điểm quan trọng nhất ảnh hưởng kiến trúc Basic Flow/Exceptional Flow của UC_4.3.
A-07: Có bộ ngưỡng số chính xác do khách cung cấp cho label Sharpe/Sortino (Excellent ≥1.50 / Good 1.00–1.49 / Subpar 0.50–0.99 / Poor ≤0.49) — thay thế hoàn toàn thang đề xuất ban đầu (Poor/Fair/Good/Excellent với mốc khác).

Các mục còn lại (A-02, A-03, A-05, A-06, A-08→A-18) đượ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.3 (chờ BA trả lời xong UC_4.4 trước khi Architect chạy đồng thời cho cả 2 UC — xem docs/BA/UC_4.1-4.17/dashboard_common/UC_4.4/QnA_init_docs.md).

Changelog

Date	Version	Updated item	Before	After	Notes
2026-08-09	v1	Initial creation	—	18 QnA items (A-01→A-18) + 1 mục [MISSING_DEPENDENCY RESOLVED] kế thừa A-00 từ UC_4.2.1-4.2.5	Init Flow Step 1+2, folder mới tạo cho module Performance (dashboard_common). Nguồn: `v7_full.txt` §Risk Metrics Logic Definitions/Endpoints + wireframe `Performance Overview - Day 0.png` / `Performance Overview V1.2.png`
2026-08-09	v1.1	BA review — trả lời toàn bộ A-01→A-18	Toàn bộ ⏳ Chờ BA	Toàn bộ ✅ Đã chốt (A-01/A-04/A-07 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-09
2026-08-15	v1.2	BA restructure — xoá BR_4.3.8, tách nội dung Live Update còn lại vào Basic Flow step 7	BR_4.3.8 gộp 2 nội dung: (1) Live update qua `PERFORMANCE_UPDATE` WebSocket, (2) Reset về empty state khi Level change / Reset (SIM) / Re-buy (LIVE)	Đã xoá BR_4.3.8. Nội dung (1) Live update giữ nguyên, chuyển vào Basic Flow step 7 (đã có sẵn câu tương đương) — các Ref trỏ tới BR_4.3.8 trong Post-conditions, Basic Flow, bảng Screen Description (dòng 1/3/5/6/9/10) đổi sang trỏ Basic Flow step 7. Nội dung (2) Reset: bỏ "advances to a new level" khỏi trigger reset — BA xác nhận level up KHÔNG đưa widget về Day 0 empty state theo cách hiểu ban đầu; tuy nhiên vì BR_4.3.7 (Empty State Day 0) và Basic Flow step 1/BR_4.3.4/BR_4.3.5 vẫn giữ đúng RFQ v7 — 12 metric scope theo current level (Source: RFQ_ Stack Trading Prop Tech V7.pdf §Risk Metrics Endpoints "Get Core Performance": "Calculates the global metrics for the user's current level... Holding time is locked to the current level history") — BA xác nhận lại (2026-08-15) hành vi cụ thể: khi user vừa lên level mới (0 lệnh đóng ở level mới), widget vẫn hiển thị Day 0 empty state đúng theo BR_4.3.7 hiện có, không có ngoại lệ riêng cho level-up. Exceptional Flow chỉ còn liệt kê Reset(SIM)/Re-buy(LIVE) là trigger reset rõ ràng; level-up dẫn tới Day 0 là hệ quả tự nhiên của scope "current level" (không phải một rule reset riêng), nên không cần rule riêng cho nó.	BA confirmation, 2026-08-15 — qua 2 vòng hỏi lại để giải quyết mâu thuẫn giữa yêu cầu ban đầu ("level up không back Day 0") và định nghĩa "current level" đã có trong RFQ v7/BR_4.3.7; BA chốt: giữ đúng RFQ, không tạo ngoại lệ.

QnA Init Docs — UC_4.3: Dashboard Common — Performance (12 Performance Metrics)