QnA Init Docs — UC_4.15.4: Scenario C - Defense Protocol (Level 9+) (LIVE)
Ngày tạo: 2026-08-18 Phiên bản: v1 BA phụ trách: [TBD] Trạng thái: ✅ Đã chốt — BA đã phản hồi toàn bộ QnA (2026-08-18)
BA directive (đề xuất, chờ xác nhận): Khác với các UC 4.15.1-4.15.3, UC_4.15.4 (Defense Protocol) không phải biến thể LIVE của 1 UC SIM sibling — đây là flow LIVE-only, không có SIM analog (SIM Reset không có "cooling-off + reduced params" path). Vì vậy không áp dụng pattern REF-not-duplicate với UC_4.10.x. Điểm cần REF: (a) UC_4.15.2 (Hard Breach LIVE) cho phần "Level 9-24 gate check trước khi breach modal hiển thị" (input UC_4.15.2 QN-4.15.2-01 đã note case Level 9-24 defense/severance), (b) UC_4.15.3 (Re-Buy LIVE) cho ranh giới scope — UC_4.15.3 chỉ nhận traffic Level 9+ khi
defense_used=TRUE(đã hết bullet), UC_4.15.4 sở hữu casedefense_used=FALSE. Cả 2 UC sibling này vẫn⏳ Chờ BA review, nên ranh giới scope chưa lock 100% — xem QN-4.15.4-05.
Input gốc (Definition/Trigger/Formula/Flow 4 Trigger B "Drawdown Defense Path"/Flow 21 "Principal Partner Accrual"/UI-UX) được đối chiếu với
zapier_v7_full.txt(Table F dòng 786-793, Flow 4/Flow 7 dòng 1440-1660, Flow 21 dòng 2162-2176),v7_full.txt(LEVEL_STOP_BREACH event dòng 430-459,POST /system/set-account-statedòng 1160-1194),QnA_STAGE2_FAILURE_AND_RECOVERY.md(FR-29 → FR-54),CR-20260816-001, vàlist_email.md. Các câu hỏi dưới đây chỉ nêu gap thật trong source hoặc thiếu sót trong input so với QnA/CR đã confirm — phần nào input đã khớp 100% thì không raise lại (xem mục 🟢 Pattern check).
UC_4.15.4 — Scenario C: Defense Protocol (Level 9+) (LIVE)
| ID | Câu hỏi | Giả định (BA/QC đề xuất) | BA chốt (ưu tiên cao nhất) | Trạng thái |
|---|---|---|---|---|
| QN-4.15.4-01 | 🟡**[Gap — thiếu trong input] Immutable Ledger logging khi vào Defense.** v7_full.txt dòng 1160-1194 (endpoint POST /system/set-account-state) ghi rõ: "Drawdown Defense Logic: IF state=='Locked' AND context=='Defense', middleware Node.js phải native init Ethers.js wallet và execute contract.recordMetric() (metric_category="Risk Management Protocol", metric_value="Drawdown Defense Deployed (Seat Protected)", receipt_hash=[Internal Event ID])." Input Business logic (Flow 4 Trigger B, bước gọi POST /system/set-account-state) không đề cập bước ghi Immutable Ledger này. Đây có phải yêu cầu backend bị input bỏ sót (do brevity khi paste), hay đây là scope không áp dụng cho Defense (chỉ áp dụng path khác)? | Có khả năng cao input chỉ tóm tắt business logic, không cố ý loại bỏ backend requirement này. Đề xuất SRS thêm bước ghi Immutable Ledger vào cuối "Set Defense Lock" step, citev7_full.txt §POST /system/set-account-state, dùng đúng metric_category/metric_value như source. | Đồng ý bổ sung, lấy nguyên văn từ source: khi Set Account State chuyển state='Locked' AND context='Defense', middleware Node.js phải native init Ethers.js wallet và execute contract.recordMetric() với metric_category="Risk Management Protocol", metric_value="Drawdown Defense Deployed (Seat Protected)", receipt_hash=[Internal Event ID]. Thêm bước này vào cuối "Set Defense Lock" step trong SRS, viết y nguyên như source (không cite, theo quy tắc QN-4.15.4-07). | ✅ Đã chốt |
| QN-4.15.4-02 | 🟡**[Gap — CR-20260816-001 chưa được input tích hợp] Email suppression khi Defense trigger từ Flow 19 (Stagnation).** Input Flow 4 Trigger B mô tả "Send Drawdown_Defense_Activated_Initial" như 1 bước cố định, không có gate nào check nguồn gọi. Nhưng CR-20260816-001 (Active, HIGH) + FR-52 (confirmed) yêu cầu: nếu Flow 4B được trigger từ Flow 19 (Stagnation path, khi Level>=9 AND Defense_Used==False tại mốc days_remaining < 0) thì PHẢI suppress Drawdown_Defense_Activated_Initial — Flow 19 tự gửi Stagnation_Defense_Activated riêng, tránh double notification. Input UC_4.15.4 có nên thêm gate check IF incoming Reason Code == STAGNATION: SKIP Send Drawdown_Defense_Activated_Initial vào bước Notify, hay đây thuộc scope riêng của Flow 19 (UC khác)? | Thêm gate suppression vào Business Rules của UC_4.15.4 (vì Flow 4B — nơi thực thi gate — chính là core flow của UC này), cite trực tiếp CR-20260816-001 + FR-52, theo đúng pattern đã áp dụng ở UC_4.15.2 (QN-4.15.2-04). | Có | ✅ Đã chốt |
| QN-4.15.4-03 | 🟡**[Data gap — email ID không nhất quán giữa 2 câu QnA] Defense_Protocol_Recharged email — SES ID nào?** FR-39 (confirmed) nói email này gửi qua AWS SES, thêm vào Table D1. Nhưng FR-50 lại hỏi "check template email Defense_protocol_recharge tại SES-27" — trong khi list_email.md hiện tại chỉ có SES-10 đến SES-15 (không có SES-27, và cũng không có entry riêng cho Defense_Protocol_Recharged/Defense_protocol_recharge). Input UC_4.15.4 cũng không đề cập bước gửi email này (chỉ có Drawdown_Defense_Activated_Initial và Drawdown_Defense_Ready). Cần: (a) xác nhận Defense_Protocol_Recharged có thuộc scope UC_4.15.4 không (trigger tại thời điểm nào — lúc recharge bullet, thuộc Flow 4/21?), (b) SES-27 là ID thật hay chỉ là placeholder tạm trong Google Sheet chưa sync vào list_email.md? | Đề xuất: (a)Defense_Protocol_Recharged thuộc scope UC_4.15.4 — trigger khi defense_attempt_count reset/recharge thành công (Flow 4 chuẩn cho Level 9-17, hoặc Flow 21 Principal Accrual cho Level 18+). (b) Flag list_email.md cần update thêm SES-27 = Defense_Protocol_Recharged (AWS SES, theo FR-39/FR-50) — đây là task đồng bộ tài liệu, không block SRS, nhưng SRS nên cite SES-27 với note [PENDING SYNC — list_email.md]. | Có thuộc scope nhé. mà flow 4A và flow 21 đều trigger email này mà? check lại xem?[QC verify] Đã check lại zapier_v7_full.txt: dòng 1384-1387 (Flow 4, standard accrual Level 9-17) — IF Promotions_Since_Defense >= 2: Set Defense_Used=False, Reset Promotions_Since_Defense=0, Notify: Send Defense_Protocol_Recharged Email; dòng 2172-2175 (Flow 21, Principal Accrual Level 18+) — IF Months_Since_Trigger >= 6 AND Status != 'In_Defense': Set Defense_Used=False, Update Last_Defense_Recharge_Date=Today, Notify: Send Defense_Protocol_Recharged Email. Xác nhận đúng — cả 2 flow đều trigger email này, cùng 1 template, 2 nguồn gọi khác nhau theo tier level (9-17 vs 18+). SRS sẽ note rõ 2 trigger source. | ✅ Đã chốt |
| QN-4.15.4-04 | 🟢**[Pattern check — cần làm rõ trong SRS, không phải câu hỏi mới] Defense_Trigger_Date vs Last_Defense_Recharge_Date — 2 field tách biệt.** Input Flow 4 Trigger B chỉ liệt kê "Defense_Trigger_Date" khi set defense; không đề cập Last_Defense_Recharge_Date. FR-48 (confirmed) xác nhận đây là 2 field hoàn toàn khác nhau: Defense_Trigger_Date = timestamp lúc trader breach & được defense cứu; Last_Defense_Recharge_Date = timestamp lúc hệ thống forgive/trả lại defense bullet (set tại Flow 4 standard accrual Level 9-17 hoặc Flow 21 Level 18+, không phải tại UC_4.15.4). Xác nhận SRS UC_4.15.4 chỉ set Defense_Trigger_Date (đúng như input), còn Last_Defense_Recharge_Date thuộc scope UC khác (Level Progression / Recharge flow, không phải UC_4.15.4)? | Đồng ý — UC_4.15.4 chỉ setDefense_Trigger_Date tại thời điểm trigger. Last_Defense_Recharge_Date REF sang UC sở hữu Flow 4 standard accrual/Flow 21 (có thể là UC_4.12.6 Level Progression — cần WBS xác nhận UC nào sở hữu Flow 21, xem QN-4.15.4-05). | Hiện tại trong UC 4.15.4 thì sẽ nói qua về mechanism (set Defense_Trigger_Date), còn full flow của recharge (set Last_Defense_Recharge_Date tại Flow 4 standard accrual/Flow 21) thì ref UC_8.4.2 nhé — nhưng UC này hiện chưa viết nên chưa cần gắn ref link, chỉ note tên UC bằng text thường (không đóng thành markdown link tới file không tồn tại). | ✅ Đã chốt |
| QN-4.15.4-05 | 🟡**[MISSING_DEPENDENCY — đã sửa: KHÔNG missing] UC_4.12.1 (Countdown Timer), UC_4.12.2 (PnL Gauge), UC_4.12.3 (Desk Manager) chưa có SRS?** Input UI/UX yêu cầu: (a) PnL Gauge phải active hiển thị 48h countdown timer (khớp FR-51), (b) Defense modal/lock KHÔNG được block main nav/Settings/Desk Manager widget. Cả 3 UC LIVE này (dashboard_live/UC_4.12.1, UC_4.12.2, UC_4.12.3) chưa có folder/SRS — nhưng có nên REF sang UC tương đương bên SIM không? | (a) — không block. UC_4.15.4 viết SRS với countdown requirement ở mức business rule, đánh dấu chi tiết UI là[MISSING_DEPENDENCY]. | Có SRS docs rồi nha. Bạn mô tả highlevel là vẫn chạy rồi ref sang nhóm UC Global Shell và Overview bên dashboard SIM là dc[QC verify] Đã check: dashboard_sim/UC_4.8.1 = PnL Gauge (đã có SRS UC_4.8.1_v1.md, BR_4.8.1.1/4.8.1.4 đã note sẵn state "Drawdown defense enabled" là LIVE-only, N/A on SIM — đúng use case này), dashboard_sim/UC_4.8.3 = The Desk Manager (đã có SRS UC_4.8.3_v1.md, đã note rule "never blocks trade execution"). Không có [MISSING_DEPENDENCY] thật — chỉ cần REF sang UC_4.8.1 (PnL Gauge, đặc biệt BR_4.8.1.1/BR_4.8.1.4 — countdown label pattern "Breached (Drawdown Defense Enabled)" + "47h 59min 59sec" đã có sẵn) và UC_4.8.3 (Desk Manager, non-blocking rule) làm pattern LIVE-delta, không viết lại từ đầu. | ✅ Đã chốt |
| QN-4.15.4-06 | 🟡**[Cross-UC pattern check — đã sửa lại] UC_4.15.4 dùng chung Frosted Glass UI trong 48h, nhưng KHÔNG có rule archive_date/D=0.** UC_4.10.2 (SIM)/UC_4.15.2 (LIVE Hard Breach) dùng pattern "Frosted Glass permanence" + archive_date (Failure+10 Days) cho termination thật. Defense Protocol dùng chung visual style Frosted Glass (desaturate/freeze overlay) trong lúc account bị Locked 48h, nhưng vì đây không phải termination (FR-34: account/Auth0 không bị xóa, chỉ hard freeze tạm) nên KHÔNG có rule archive_date (Failure+10 Days) hay reset D=0 nào áp dụng — sau 48h account tự resume nguyên trạng, không cần Re-Buy/Reset. | Đồng ý — UC_4.15.4không áp dụng D=0/archive_date lifecycle (pattern đó chỉ dành cho termination path UC_4.15.2/4.15.5). UI pattern đúng là "Locked/read-only, temporary 48h", tự động unlock — không REF tới UC_4.10.2 cho phần này. | cái defense dùng chung frosted glass trong 48h nhé nhưng k có rule archive hay D=0 | ✅ Đã chốt |
| QN-4.15.4-07 | 🟢**[Pattern check, không phải câu hỏi mới] Futures normalization multiplier.** Input Flow 4 ví dụ Futures Defense Calculation (Normalization Multiplier = Max_Forex_Notional / Futures_Capital) khớp 100% với FR-33 (confirmed, bao gồm cả 2 lỗi toán học đã được khách correct: 12,500 × 0.06 = 750, và Floor rounds DOWN không round nearest). Xác nhận SRS viết thẳng theo input (đã đúng), REF FR-33 làm nguồn, không cần sửa gì? | Đồng ý — input đã khớp FR-33 100%, viết thẳng, cite FR-33. | Không được cite cái gì cả, viết vào docs SRS là source of truth. Ví dụ lấy y nguyên ok. [QC note] Áp dụng: SRS viết công thức/ví dụ Defense Calculation (bao gồm Futures normalization) trực tiếp làm nội dung Business Rule chính, không gắn tag (Source: ...) — SRS chính là tài liệu source of truth cho dev, không phải research note. | ✅ Đã chốt |
| QN-4.15.4-08 | 🟢**[Pattern check] Table F là 1 dòng flat cho toàn range Level 9-24, không phải lookup per-level như Table A/B.** zapier_v7_full.txt dòng 786-793 xác nhận Table F "Defense_Configuration_Matrix" chỉ có 1 row "Seed Data (Levels 9-24)" với Defense_Notional_Multiplier=0.25, Defense_Profit_Target_Percent=6%, Defense_Stop_Loss_Percent=5% — khác với Table A/B (Hard Breach) là per-level lookup. Input khớp đúng cấu trúc này. Xác nhận SRS ghi rõ Table F là single flat row (không phải per-level), để tránh Architect nhầm sang pattern lookup như UC_4.15.2? | Đồng ý — SRS note rõ Table F flat structure, tránh nhầm với Table A/B per-level lookup pattern của UC_4.15.2. | đồng ý | ✅ Đã chốt |
Changelog
| Date | Version | Updated item | Before | After | Notes |
|---|---|---|---|---|---|
| 2026-08-18 | v1 | Initial creation | — | 8 QnA items | Init Flow Step 1+2 — challenged againstzapier_v7_full.txt (Table F, Flow 4/7/21), v7_full.txt (LEVEL_STOP_BREACH, POST /system/set-account-state), QnA_STAGE2_FAILURE_AND_RECOVERY.md (FR-29→FR-54), CR-20260816-001, list_email.md, WBS (UC_4.12.1-4.12.3 missing-dependency check). |
| 2026-08-18 | v1.1 | BA phản hồi 8/8 QnA | ⏳ Chờ BA | ✅ Đã chốt | BA đã trả lời trực tiếp toàn bộ 8 câu. Điểm chốt quan trọng: (1) Immutable Ledger logging → thêm vào cuối "Set Defense Lock" step, viết y nguyên không cite. (2) CR-20260816-001 suppression gate → thêm vào Business Rules. (3) Defense_Protocol_Recharged — QC verify xác nhận CẢ Flow 4 (Level 9-17) VÀ Flow 21 (Level 18+) đều trigger email này, cần note rõ 2 nguồn gọi trong SRS. (4) Last_Defense_Recharge_Date — REF text-only (không link) sang UC_8.4.2 (chưa viết). (5) UC_4.12.1/4.12.2/4.12.3 — QC verify xác nhận KHÔNG phải [MISSING_DEPENDENCY]: PnL Gauge/Desk Manager đã có SRS ở dashboard_sim/UC_4.8.1 và UC_4.8.3 (BR_4.8.1.1/4.8.1.4 đã sẵn state "Drawdown defense enabled" cho đúng use case này) — SRS UC_4.15.4 REF sang 2 UC này, không viết lại. (6) Defense dùng chung Frosted Glass overlay trong 48h, nhưng KHÔNG có archive_date/D=0 lifecycle (khác Hard Breach). (7)+(8) SRS viết công thức Defense Calculation/Table F trực tiếp làm nội dung chính, không gắn citation tag — SRS là source of truth. |
✅ BA Review Gate — Đã thông qua
Toàn bộ 8/8 QnA đã được BA chốt (2026-08-18). Agent 3 (Architect) có thể tiến hành viết SRS cho UC_4.15.4, tuân theo các điểm đã chốt ở trên (đặc biệt: REF sang UC_4.8.1/UC_4.8.3 cho PnL Gauge/Desk Manager, REF text-only sang UC_8.4.2 cho Recharge flow, không cite nguồn cho công thức Defense Calculation, thêm Immutable Ledger logging + CR-20260816-001 suppression gate vào Business Rules).