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

QnA Init Docs — Dashboard Common — Journal & Heatmap with 3 Sliders

Phạm vi UC: UC_4.4 (Journal & Heatmap with 3 Sliders) — module Journal/Calendar, 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 A-01 → A-17 — 2 mục (A-01, A-04) còn ở trạng thái [BLOCKED — chờ khách confirm], phần còn lại ✅ Đã chốt — đủ điều kiện tiến hành Step 3 (Architect viết SRS) với 2 mục blocked được loại trừ khỏi nội dung chính thức theo global-rules.md §QnA Before Docs

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.4 (References/WBS/BA internal - BA plan 2 - BA plan 2.csv, dòng 165) chỉ có module=Journal/Calendar, function=Journal & Heatmap with 3 Sliders, uc_id=UC_4.4 — 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_ Website and Dashboard Implementation V7.pdf §Part C (dòng 580–583 bản extract dashboard_v7_full.txt) — "Journal historic Heatmap & Daily Self-Rating Module. Typically a Monthly Calendar view. The self-rating journal entry must support an A+ through D grading rubric and three specific 5-point evaluation sliders: Entry quality, Exit quality, and Plan compliance text entry."
RFQ_ Stack Trading Prop Tech V7.pdf §"Daily Journal and Heatmap Endpoints" (dòng 2201–2239 bản extract v7_full.txt) — 2 endpoint: Create Entry (POST) và Get Monthly Journal Data (GET).
Wireframe (untracked, mới thêm vào References/Wireframe/Stage 2/Journal&Calendar/): Journal - Day 0.png (empty state), Calendar.png (populated state — March 2026), Journal Entry.png (modal chi tiết 1 ngày). 3 file này là nguồn UI/UX duy nhất, xác nhận trực tiếp: 7 stat card đầu trang, lịch tháng dạng heatmap, và modal "Journal entry" với đúng 3 slider (Entry quality / Exit quality / Plan compliance) + 5 stamp grade chọn tay (A+/A/B/C-/D) + Notes textarea.
Global Header và Sidebar hiện trong cả 3 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 "Journal" trỏ đến chính UC_4.4 này.
Đối chiếu công thức: Get Monthly Journal Data response gồm aggregate_metrics{monthly_pnl, winning_days, losing_days, win_rate, avg_win_day, avg_loss_day, days_traded, avg_rating} — khớp 1-1 với 7 stat card trên wireframe (Monthly P&L / Winning Days-Losing Days / Daily Win Rate / Avg Win Day / Avg Loss Day / Avg. rating / Days traded).

⚠️ [SOURCE_CONFLICT] Backend API extract KHÔNG khớp đầy đủ với Wireframe — [BLOCKED — chờ khách confirm], xử lý theo A-01 bên dưới

Đây là phát hiện quan trọng nhất của Init Flow này — Challenger Phase 1 Group D (Intra-rule) mở rộng sang cross-document, phát hiện Create Entry (backend, v7_full.txt) và Journal Entry modal (wireframe, mới hơn) không khớp cấu trúc dữ liệu:

	Backend`Create Entry` (POST) — `v7_full.txt` dòng 2206–2218	Wireframe`Journal Entry.png`
Input params	`date`, `rating` (Integer 1-5, chỉ 1 số duy nhất), `text_content`, `tags` (optional)	3 slider riêng biệt:Entry quality (0-5), Exit quality (0-5), Plan compliance (0-5) + 1 "Stamp today's grade" (chọn tay 1 trong 5 nhãn chữ: A+/A/B/C-/D) + Notes (text)
Output (`daily_records`)	`rating_score: int`, `stamp_grade: string`, `notes: string`	(khớp: card đầu modal hiện`stamp_grade` A+ + `daily_pnl`; nhưng 3 giá trị slider không có field tương ứng rõ ràng trong response)

Backend extract chỉ có 1 field rating (số nguyên 1-5) — không có 3 field riêng cho Entry quality/Exit quality/Plan compliance. Response daily_records cũng chỉ có rating_score (1 số) + stamp_grade (1 chữ) — không thấy 3 giá trị slider được trả về riêng lẻ để hiển thị lại khi user mở lại modal xem 1 ngày đã chấm điểm trướ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	[SOURCE_CONFLICT] Backend cần bổ sung 3 field riêng (`entry_quality`, `exit_quality`, `plan_compliance`, mỗi field Integer 0-5) vào `Create Entry` input VÀ vào response `daily_records` của `Get Monthly Journal Data` (để hiển thị lại đúng vị trí 3 slider khi user mở lại 1 ngày đã chấm) — thay vì chỉ 1 field `rating` chung? Đây là gap giữa RFQ backend (cũ, có thể chưa cập nhật theo wireframe V1.2 mới) và wireframe (mới hơn).	Có — đây là gap RFQ chưa cập nhật, phải raise cho BE bổ sung 3 field riêng biệt.`rating`/`rating_score` cũ có thể giữ lại làm giá trị trung bình cộng (derived) của 3 slider, hoặc bỏ hẳn — cần BA quyết định hướng nào.	[BLOCKED — chờ khách confirm] BA: "Hãy hoàn thiện doc theo các field hiện đang có. Thông tin này đang chờ khách confirm." → Step 3 phải viết SRS dựa trên field backend hiện có (`rating` Integer 1-5, `rating_score`/`stamp_grade`/`notes` trong response) — UI vẫn mô tả đúng 3 slider theo wireframe (đã được duyệt design), nhưng phần data-contract/API input-output cho 3 slider phải đánh dấu rõ [PENDING CLIENT CONFIRMATION] trong SRS thay vì tự đặt tên field mới (`entry_quality`/`exit_quality`/`plan_compliance`) như đề xuất ban đầu — KHÔNG fabricate cấu trúc API chưa được xác nhận.	🟡 [BLOCKED] — có hướng xử lý, loại trừ phần field mapping chưa xác nhận khỏi nội dung chính thức, không block toàn bộ Step 3
A-02	Quan hệ giữa 3 slider và "Stamp today's grade" — "Stamp" là do user tự chọn tay độc lập (như hiện trên wireframe, 5 stamp bấm chọn, không thấy dấu hiệu auto-suggest), hay được hệ thống tự động đề xuất dựa trên điểm trung bình 3 slider (ví dụ: (4+5+5)/3 = 4.67 → gợi ý "A+")?	Đề xuất: user tự chọn tay hoàn toàn độc lập với 3 slider (đúng theo những gì thấy trên wireframe — không có UI gợi ý/pre-select tự động dựa trên slider). 3 slider mang tính chất "self-rating" phân tích chi tiết, còn stamp là đánh giá tổng thể chủ quan riêng của user.	Đúng như đề xuất — user tự chọn tay hoàn toàn độc lập với 3 slider. 3 slider mang tính chất "self-rating" phân tích chi tiết, còn stamp là đánh giá tổng thể chủ quan riêng của user.	✅ Đã chốt
A-03	RFQ nói"A+ through D grading rubric" — nếu đọc theo thang điểm chữ Mỹ chuẩn thì có thể gồm nhiều nấc hơn (A+, A, A-, B+, B, B-, C+, C, C-, D+, D, D-...), nhưng wireframe "Stamp today's grade" chỉ hiện đúng 5 lựa chọn cố định: A+, A, B, C-, D (không có A-, B+, B-, C, C+, D+, D-, F). Xác nhận đây là toàn bộ rubric (chỉ 5 nấc, không phải bị cắt do giới hạn màn hình)?	Xác nhận 5 nấc cố định theo đúng wireframe (A+, A, B, C-, D) — không mở rộng thêm nấc nào khác, vì wireframe không có UI scroll/expand cho hàng stamp.	Xác nhận đúng đề xuất — 5 nấc cố định theo wireframe (A+, A, B, C-, D), không mở rộng thêm nấc nào khác.	✅ Đã chốt
A-04	"Avg. rating" stat card đầu trang hiện "B+" — nhưng "B+" không nằm trong 5 stamp lựa chọn được (A+/A/B/C-/D, xem A-03) ở modal Journal Entry. Vậy "Avg. rating" tháng được tính bằng cách nào ra 1 nhãn không tồn tại trong tập giá trị gốc? Cần 1 bảng ánh xạ chữ→số (vd A+=5, A=4.5, B=3.5, C-=2, D=1) rồi tính trung bình rồi map ngược lại số→chữ (dùng thang mở rộng hơn 5 nấc chỉ để hiển thị số trung bình)?	Đề xuất: cần bảng mapping số học đầy đủ cho TẤT CẢ nấc chữ chuẩn (kể cả nấc không xuất hiện trong 5 lựa chọn chấm tay, dùng riêng cho mục đích hiển thị trung bình) — nhưng đây là logic nghiệp vụ cần BA/khách xác nhận công thức chính xác, không tự suy diễn thang điểm.	[BLOCKED — chờ khách confirm] BA: "Đang chờ khách hàng confirm thông tin này." → Step 3 phải mô tả widget "Avg. rating" trong Screen Description (vị trí, format hiển thị) nhưng KHÔNG được tự đặt công thức mapping chữ→số→chữ — đánh dấu công thức tính là [PENDING CLIENT CONFIRMATION], không viết thành Business Rule chính thức cho tới khi có xác nhận.	🟡 [BLOCKED] — có hướng xử lý (loại trừ công thức, giữ UI description), không block toàn bộ Step 3
A-05	3 slider trên wireframe hiển thị dạng5 khối vuông rời rạc tô đầy dần (discrete, không phải slider kéo liên tục) — giá trị hiển thị dạng phân số `X/5` (vd `4/5`, `5/5`). Xác nhận đây là control kiểu click-to-select mức trong thang 0-5 rời rạc (giống rating sao 5 cánh, không cho phép giá trị thập phân như 3.5), KHÔNG phải slider kéo tự do?	Đúng — click chọn 1 trong 5 mức rời rạc (1-5), khớp UI 5-block trên wireframe. Field type chính xác cần dùng trong Screen Description: không phải "Slider" kiểu range kéo tự do — cần raise pattern candidate cho`skill_shared_validation_rules.md` Field Type Glossary nếu chưa có type phù hợp (Ref: A-13).	Đúng — click chọn 1 trong 5 mức rời rạc (1-5), khớp UI 5-block trên wireframe.	✅ Đã chốt

Bảng QnA & Assumption — Calendar / Trading Journal (trang chính)

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	Scope tính toán 7 stat card (Monthly P&L, Winning/Losing Days, Daily Win Rate, Avg Win/Loss Day, Avg. rating, Days traded) — theo đúng tháng đang xem trên Calendar navigator (`month`, `year` params của `Get Monthly Journal Data`), KHÔNG phải all-time. Xác nhận đúng?	Đúng — khớp trực tiếp input params`user_id, month, year` của endpoint nguồn.	Đúng — khớp trực tiếp input params `user_id, month, year` của endpoint nguồn.	✅ Đã chốt
A-07	Ranh giới "ngày giao dịch" (trading day) dùng để bucket `daily_pnl` — theo UTC midnight thông thường (CR-08), hay theo Exchange Reset session (18:00 EST cho Futures / 17:00 EST cho Forex — cùng mốc reset dùng cho Pulse Score, nguồn `v7_full.txt` §Pulse Score "It should reset to 100 at the start of every daily trading session")? Nếu 2 widget dùng 2 ranh giới ngày khác nhau (Journal vs Pulse Score) sẽ gây lệch số liệu giữa các trang.	Đề xuất: dùng chung Exchange Reset session boundary (giống Pulse Score) để đảm bảo nhất quán "ngày giao dịch" xuyên suốt toàn bộ Dashboard — KHÔNG dùng UTC midnight thuần.	Đúng như đề xuất — dùng chung Exchange Reset session boundary (giống Pulse Score) để đảm bảo nhất quán "ngày giao dịch" xuyên suốt toàn bộ Dashboard, KHÔNG dùng UTC midnight thuần.	✅ Đã chốt
A-08	`daily_pnl` cho ngày hiện tại (đang giao dịch dở, phiên chưa đóng) — có tính cả Unrealized P&L (theo công thức Net_P&L = Realized + Unrealized, đã confirm ở STAGE2-032) hay chỉ Realized (vì các ngày quá khứ hiển nhiên chỉ còn Realized, do vị thế đã đóng hết cuối phiên)?	Đề xuất: đồng bộ công thức Net_P&L = Realized + Unrealized (STAGE2-032) cho ngày hiện tại đang mở; các ngày quá khứ tự động = Realized-only (vì không còn vị thế mở).	Đúng như đề xuất — đồng bộ công thức Net_P&L = Realized + Unrealized (STAGE2-032) cho ngày hiện tại đang mở; các ngày quá khứ tự động = Realized-only.	✅ Đã chốt
A-09	Ô lịch"No trade day" (không có giao dịch) — hiện tại là placeholder xám, không có `daily_pnl`/stamp. User có click được vào ô này để mở modal "Journal entry" không (ghi chú chủ quan dù không có lệnh nào), hay ô này hoàn toàn không tương tác được?	Đề xuất: cho phép click mở modal ngay cả ngày không có giao dịch (self-rating/notes không nhất thiết phải gắn với P&L — RFQ nói rõ đây là "Self-Rating Module" ghi nhận subjective notes, "user-generated and date-based", không bắt buộc phải có trade). Khi đó "Daily P&L" trong modal hiển thị`$0` hoặc `--`.	Cho phép click mở modal ngay cả ngày không có giao dịch (self-rating/notes không nhất thiết phải gắn với P&L). Khi đó "Daily P&L" trong modal hiển thị `$0` (chốt dứt điểm — KHÔNG dùng `--` như 1 trong 2 phương án đề xuất ban đầu).	✅ Đã chốt (thu hẹp đề xuất 2 phương án `$0`/`--` xuống còn `$0` duy nhất)
A-10	Multiple entries per day — Backend note rõ ràng còn bỏ ngỏ 2 hướng: "If an entry already exists for this date, append the text or update the rating (logic should support multiple entries per day or upsert based on business rule)". Wireframe chỉ hiện 1 stamp + 1 P&L / 1 ô ngày (không thấy dấu hiệu nhiều entry/ngày trên Calendar) → xác nhận model là upsert (1 entry/ngày/user, ghi đè khi sửa lại), không phải append-nhiều-entry?	Đúng — upsert model, 1 entry duy nhất mỗi ngày mỗi user, sửa lại = ghi đè toàn bộ field (rating/sliders/stamp/notes) của entry ngày đó.	Đúng — upsert model, 1 entry duy nhất mỗi ngày mỗi user, sửa lại = ghi đè toàn bộ field (rating/sliders/stamp/notes) của entry ngày đó.	✅ Đã chốt
A-11	Điều hướng tháng (nút`<` `>` cạnh "March 2026") — có giới hạn không cho xem tháng tương lai (chưa tới, chưa có dữ liệu) không? Có giới hạn xem quá khứ xa nhất (vd trước ngày tài khoản được provision) không?	Đề xuất: disable nút`>` (Next) khi đã ở tháng hiện tại (không cho xem tương lai); disable nút `<` (Previous) khi đã lùi tới tháng tài khoản được tạo (`created_at`/ngày provision) — tránh hiển thị data rỗng vô nghĩa trước khi tài khoản tồn tại.	Đúng như đề xuất — disable nút `>` (Next) khi đã ở tháng hiện tại; disable nút `<` (Previous) khi đã lùi tới tháng tài khoản được tạo (`created_at`/ngày provision).	✅ Đã chốt
A-12	"Grade distribution" legend (A+ x4, A x6, B x13, C x6, D x4 trên wireframe mẫu) — đếm theo đúng 5 nấc stamp (A+/A/B/C-/D, xem A-03), hay theo thang mở rộng hơn? Lưu ý mẫu wireframe hiện nhãn "C x6" (không phải "C-") — có thể là lỗi đặt tên trên wireframe (nên là C- để khớp 5 stamp option) hoặc xác nhận có tồn tại nấc "C" riêng biệt với "C-".	Đề xuất: đây là lỗi label trên wireframe — nên đọc là "C-" để khớp đúng 5 stamp option duy nhất tồn tại trong hệ thống (A+/A/B/C-/D). Cần BA xác nhận lại với khách/design team vì có thể ảnh hưởng đến đúng 1 trong 5 nhãn hiển thị.	Xác nhận đúng đề xuất — đây là lỗi label trên wireframe, đọc là "C-" để khớp đúng 5 stamp option duy nhất tồn tại trong hệ thống (A+/A/B/C-/D).	✅ Đã 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-13	Field type chính xác cho 3 "slider" (Entry quality/Exit quality/Plan compliance) trong Screen Description — theo`skill_shared_validation_rules.md → Section 5 Field Type Glossary`, không được dùng type chung chung "Slider". Đề xuất field type mới: "Discrete Rating Selector (1-5)" hay dùng type đã có sẵn nào tương đương?	[PATTERN] Đề xuất bổ sung field type mới vào Field Type Glossary — "Discrete Rating Selector (N-point)" — vì đây là pattern có khả năng tái sử dụng ở UC khác (không chỉ Journal).	BA: "Hiện tại có trường thông tin rating tuy nhiên, đang đề xuất tách 3 slider này thành 3 trường input riêng. Đang chờ khách hàng confirm." — cùng nội dung [BLOCKED] với A-01 (backend field split). Riêng câu hỏi field-type-glossary (thuần FE, không phụ thuộc backend) được xử lý độc lập: UI 3 slider đã được duyệt qua wireframe bất kể backend giữ 1 field hay tách 3 field, nên Architect dùng pattern candidate "Discrete Rating Selector (1-5)" làm field type khi viết Screen Description ở Step 3, không cần chờ thêm.	🟡 [BLOCKED — phần backend field split, đồng bộ A-01] / ✅ [phần FE field-type-glossary, không block]
A-14	Notes textarea trong modal — áp dụng giới hạn ký tự mặc định theoCR-02 §2.2 (Textarea = 500 ký tự), hay backend `text_content (String)` có giới hạn riêng khác 500?	Đề xuất: áp dụng CR-02 mặc định (500 ký tự) — RFQ không nêu giới hạn riêng cho`text_content`.	Đúng như đề xuất — áp dụng CR-02 mặc định (500 ký tự), RFQ không nêu giới hạn riêng cho `text_content`.	✅ Đã chốt
A-15	Nút"Save changes" — nếu user đóng modal (click X hoặc click ra ngoài) khi form đã dirty (đã đổi ít nhất 1 slider/stamp/notes) mà chưa bấm Save — có áp dụng CR-05 Unsaved Data Navigation Warning (popup CF-01) không?	Đề xuất: có — áp dụng CR-05/CF-01 tiêu chuẩn, nhất quán với các form khác trong hệ thống.	KHÁC đề xuất ban đầu — KHÔNG áp dụng CR-05/CF-01. Nếu user click ra ngoài modal hoặc bấm nút X đóng khi chưa Save, modal đóng ngay lập tức, không hiển thị popup xác nhận nào — thay đổi bị huỷ bỏ âm thầm. Đây là exception riêng cho UC_4.4, không theo pattern CR-05 mặc định.	✅ Đã chốt (KHÁC đề xuất ban đầu — Architect cần đặc biệt lưu ý, ghi rõ đây là exception so với CR-05)
A-16	Toast báo kết quả khi bấm "Save changes" — thành công/thất bại — chưa có ID toast phù hợp trong`list-toast-popup.md` (đã kiểm tra §1 Toast Messages, không có toast "save success" chung nào). Cần thêm toast mới.	[PATTERN] Đề xuất thêm 2 toast mới vào`list-toast-popup.md`: TS-xx ("Journal entry saved.", Success) và tái sử dụng TE-SYS-01 (network/action failed) cho trường hợp lỗi — cần BA đặt tên ID chính thức.	KHÁC đề xuất ban đầu — Không cần thêm toast popup. Bấm "Save changes" không hiển thị toast (thành công lẫn thất bại) — không tạo TS-xx mới, không cần cập nhật `list-toast-popup.md`. Phản hồi trực quan cho user chỉ đến từ việc modal đóng lại và Calendar/stat card cập nhật ngay (Ref: Impact Analysis §Cascade effect).	✅ Đã chốt (KHÁC đề xuất ban đầu — loại bỏ hoàn toàn pattern candidate toast mới)
A-17	Card "Daily P&L" đầu modal hiện`stamp_grade` (A+) cạnh giá trị P&L — nếu user mở modal cho 1 ngày chưa từng chấm điểm trước đó (chưa có entry), card này hiển thị gì thay vì stamp? Có icon rỗng/placeholder không?	Đề xuất: hiển thị placeholder rỗng (icon vòng tròn viền nét đứt, không tô màu — tương tự cách "No trade day" hiện trên Calendar) cho tới khi user chọn 1 stamp và Save.	Đúng như đề xuất — hiển thị placeholder rỗng (icon vòng tròn viền nét đứt, không tô màu — tương tự "No trade day" trên Calendar) cho tới khi user chọn 1 stamp và Save.	✅ Đã 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 Journal/Calendar.
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 UI/công thức Journal; STAGE2-032 (Net_P&L = Realized + Unrealized) và STAGE2-002 (Reset/Rebuy reset dashboard về 0) dùng gián tiếp cho A-08 và impact analysis bên dưới.
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 — không overlap trực tiếp, Overview show Position Monitor/Pulse/Equity/Profit Factor/Win Rate theo thời gian thực, Journal show theo ngày lịch sử), UC_4.3 (Performance, đang init song song — không overlap widget, xem ghi chú UC_4.3 §Nhóm 1).
Cross-UC data consistency risk (A-07): Nếu Journal dùng ranh giới ngày khác với Pulse Score (UC_4.2.2, đã có SRS với công thức reset theo Exchange session), sẽ phát sinh mâu thuẫn dữ liệu giữa 2 trang cho cùng 1 "ngày giao dịch" — đây là rủi ro cross-UC thực sự, không chỉ lý thuyết.
Orphan-UC check: UC_4.4 xác nhận tồn tại trong WBS qua node script/parse_wbs.js --compact (category STAGE 2: DASHBOARD - COMMON, module Journal/Calendar) — không phải orphan.
Trading Functionality note: Kế thừa từ UC_4.2.x — Dashboard read-only cho phần trade execution; tuy nhiên UC_4.4 khác các UC dashboard_common khác ở chỗ đây là UC DUY NHẤT có action ghi dữ liệu (Create Entry) — cần đặc biệt chú ý Impact Analysis (xem dưới) vì đây không phải widget hiển thị thuần tuý.

Ghi chú Phase 2.5 — Impact Analysis (MANDATORY — UC_4.4 có state-changing action)

Action: Create/Update Journal Entry (POST, upsert theo ngày — xem A-10)

Uniqueness constraint: 1 entry duy nhất / user / ngày (theo giả định upsert tại A-10 — cần BA chốt).
Cascade effect: Ghi vào daily_records → ảnh hưởng trực tiếp 7 stat card đầu trang (aggregate_metrics, đặc biệt avg_rating — xem A-04) và "Grade distribution" legend của tháng đó — phải tính lại (re-fetch hoặc optimistic update) ngay sau khi Save thành công.
Reversibility: Có thể sửa lại (upsert ghi đè) bất kỳ lúc nào, không có xoá entry rõ ràng trong RFQ (không có endpoint Delete Entry) — cần hỏi BA có cần chức năng xoá entry không (chưa raise thành ID riêng, gộp chung xem xét khi viết BR ở Step 3 nếu BA thấy cần).
Concurrent access: Chỉ 1 user sở hữu dữ liệu Journal của chính họ (không multi-user editing cùng 1 entry) — rủi ro race condition thấp, không cần rule riêng.

Hướng dẫn cho BA

🟡 BA đã trả lời toàn bộ A-01 → A-17 (2026-08-09, xem cột "BA chốt"/"Trạng thái" trong từng bảng ở trên). 2 mục vẫn ở trạng thái [BLOCKED — chờ khách confirm], KHÔNG phải do thiếu BA quyết định mà do phụ thuộc xác nhận từ khách hàng (đã có hướng xử lý rõ ràng để không chặn Step 3):

A-01 [BLOCKED]: Backend giữ nguyên field rating (Integer 1-5) hiện có — KHÔNG tự đặt tên field mới entry_quality/exit_quality/plan_compliance. SRS sẽ mô tả đúng UI 3 slider theo wireframe (đã duyệt design), nhưng đánh dấu rõ phần data-contract/API cho 3 slider là [PENDING CLIENT CONFIRMATION].
A-04 [BLOCKED]: Widget "Avg. rating" được mô tả về mặt UI/vị trí trong Screen Description, nhưng công thức tính (mapping chữ→số→chữ) KHÔNG được viết thành Business Rule chính thức cho tới khi khách xác nhận — đánh dấu [PENDING CLIENT CONFIRMATION].
A-13 có cùng gốc rễ với A-01 (backend field split) nhưng phần field-type-glossary cho FE (thuần UI, không phụ thuộc backend) đã được BA mở khoá riêng — dùng "Discrete Rating Selector (1-5)" ngay tại Step 3.

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-09: "Daily P&L" cho ngày không giao dịch hiển thị đúng $0 (thu hẹp từ 2 lựa chọn đề xuất ban đầu $0/-- xuống còn 1).
A-15: KHÔNG áp dụng CR-05/CF-01 (Unsaved Data Navigation Warning) cho modal Journal Entry — đóng modal ngay lập tức khi click ra ngoài/click X mà chưa Save, không có popup xác nhận. Đây là exception so với pattern CR-05 mặc định toàn hệ thống — SRS cần ghi rõ đây là ngoại lệ có chủ đích, không phải thiếu sót.
A-16: Không thêm toast nào cho action Save changes (thành công lẫn thất bại) — loại bỏ hoàn toàn pattern candidate toast mới đã đề xuất ban đầu.

Các mục còn lại (A-02, A-03, A-05, A-06, A-07, A-08, A-10, A-11, A-12, A-14, A-17) đượ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 và UC_4.4 (cả 2 UC đã qua BA review, chỉ còn 2 mục [PENDING CLIENT CONFIRMATION] riêng của UC_4.4 sẽ được đánh dấu rõ trong SRS thay vì fabricate).

Changelog

Date	Version	Updated item	Before	After	Notes
2026-08-09	v1	Initial creation	—	17 QnA items (A-01→A-17) + 1 mục [SOURCE_CONFLICT] (backend API vs wireframe field mismatch)	Init Flow Step 1+2, folder mới tạo cho module Journal/Calendar (dashboard_common). Nguồn:`v7_full.txt` §Daily Journal and Heatmap Endpoints + `dashboard_v7_full.txt` §Part C + wireframe `Journal - Day 0.png` / `Calendar.png` / `Journal Entry.png`
2026-08-09	v1.1	BA review — trả lời toàn bộ A-01→A-17	Toàn bộ ⏳ Chờ BA	15/17 ✅ Đã chốt (A-09/A-15/A-16 khác đề xuất ban đầu — xem "Hướng dẫn cho BA"); A-01, A-04 (+ phần backend của A-13) ở trạng thái 🟡 [BLOCKED — chờ khách confirm], có hướng xử lý rõ ràng để không chặn Step 3	BA (Trang Nguyen) trả lời trực tiếp qua chat 2026-08-09

QnA Init Docs — UC_4.4: Dashboard Common — Journal & Heatmap with 3 Sliders