QnA Init Docs — UC_4.15.2: Hard Breach - Level Stop (LIVE)
Ngày tạo: 2026-08-18 Phiên bản: v1.1 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 (kế thừa pattern từ UC_4.15.1): LIVE Hard Breach (UC_4.15.2) dùng cùng kiến trúc/flow với SIM Hard Breach (UC_4.10.2) — Atomic Kill Switch, Founding Mentor overlay, Frosted Glass permanence, D=0/archive_date lifecycle... đều giống 100%. Điểm khác biệt DUY NHẤT là công thức trigger (LIVE dùng
Market_Loss_When_Stoppedtheo Table A/B per-level lookup, thay vì SIM's flat 7.5% × Notional — đã confirm là khác biệt có chủ đích, KHÔNG phải lỗi, theo changelog UC_4.10.2). Khi Architect viết SRS: bất kỳ phần nào giống SIM thì REFERENCE thẳng tới UC_4.10.2 (anchor link), KHÔNG viết lại nội dung.BA correction quan trọng (QN-03, đã chốt): LIVE Hard Breach KHÔNG có "Reset" — chỉ có "Re-buy". Vì trading account bị hard-delete ngay lập tức tại T+0 (khác với SIM chỉ lock read-only rồi mới xóa sau khi archive window hết). Data/dashboard thì vẫn giữ frozen tới khi hết archive window (~10 ngày, đọc dynamic từ
Discount_Code_Duration_Daystrong Zapier Table C, KHÔNG hardcode), sau đó mới reset về D=0.
Input gốc (bảng Definition/Trigger/Business logic/UI-UX/Founding Mentor edge case/Zapier flow 7-7B-9-19) được đối chiếu với UC_4.10.2 (SIM),
zapier_v7_full.txt(Flow 7/7B/9/19/20/21, dòng 1638-2176), vàQnA_STAGE2_FAILURE_AND_RECOVERY.md(FR-01 → FR-54, đã trả lời đầy đủ). Các câu hỏi dưới đây chỉ nêu gap thật trong source hoặc mâu thuẫn nội bộ cần BA xác nhận cách viết SRS — phần nào input đã khớp 100% với QnA/SIM sibling thì không raise lại (xem Compliance Checklist đính kèm).
UC_4.15.2 — Hard Breach: Level Stop (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.2-01 | 🔴 [BLOCKING gap] UI/UX row bị cắt giữa câu. Input gốc: "1. If user is in level 1 and 2: Display [Figma link]. 2. If user is in level" — không có nội dung tiếp theo. Cần: (a) nội dung đầy đủ cho "level [X]" case 2 là gì (level nào, hiển thị gì)? (b) có case 3/4 khác nữa không (VD level 7-8 có Severance notice riêng theo FR-30, level 9-24 có Defense notice riêng)? | Suy theo FR-30 (đã confirm cho toàn bộ Failure & Recovery module, áp dụng chung cho cả breach path Daily Loss / Level Stop): Level 1-6 = standard failure modal; Level 7-8 = Risk Parameter Breached modal + Severance notice; Level 9-24 = Drawdown Defense notice (nếu còn defense) hoặc Failure+Severance notice (nếu đã dùng defense). Đề xuất áp dụng nguyên logic FR-30 này thay cho câu bị cắt, không cần hỏi lại riêng theo case "level X". | Chuẩn rồi đấy. Muốn xem mô tả UX chính xác thì hãy tự xem trong file References/Wireframe/Stage 2.2/Failure and recovery | ✅ Đã chốt |
| QN-4.15.2-02 | 🔴 [Intra-source contradiction, đã resolve theo QnA — chỉ cần BA xác nhận cách viết] Input có 2 chỗ nói về Severance eligibility mâu thuẫn nhau: Flow 7 Step 6 dùng dynamic check (Severance_Pay > 0 từ Table A/B → đúng theo FR-54), nhưng section "Flow 9" riêng phía dưới lại ghi cứng Eligibility: Current_Level >= 3 (giống với zapier_v7_full.txt dòng 1676/1779 — đây là câu stale, đã bị FR-30/FR-54 override 2 tuần trước). Theo priority chain (QnA ★★★ > Customer supplies ★★★, và văn bản input cũ hơn ngày trả lời FR-54), QnA thắng. | SRS bỏ hoàn toàn mọi số Level hardcode (>=3, >=7) trong mô tả Flow 9 — chỉ mô tả duy nhất: "Lookup Severance_Pay field từ Table A/B theo current_level của user. Nếu Severance_Pay > 0 → Execute Flow 9. Nếu == 0 hoặc NULL → Skip." | Chốt trigger flow 9 là:Flow 9: Severance Protocol- Trigger:+ If Severance_Pay > 0: Execute Flow 9 (Severance payout).+ If Severance_Pay == 0 (or NULL): Skip Flow 9. | ✅ Đã chốt |
| QN-4.15.2-03 | 🟡 D=0 / archive_date lifecycle — hoàn toàn không xuất hiện trong input gốc. FR-31/FR-54 đã confirm rõ cho LIVE: (1) Breach → dashboard freeze ngay tại metrics breach, KHÔNG reset D=0; (2) giữ frozen 10 ngày (archive_date = Failure + 10 Days, do Get Failure State API trả về); (3) hết archive_date → historical ledger purge khỏi UI, frontend reset về D=0; (4) Re-Buy trước khi hết 10 ngày → atomic reset ngay, wipe failed state + D=0 cho challenge mới. Có cần thêm nguyên block này vào SRS Post-conditions (reference tới UC_4.10.2 nếu SIM đã có block tương tự), hay LIVE có khác biệt nào riêng (VD 10 ngày có đổi thành số khác cho LIVE không)? | Thêm nguyên block D=0/archive_date lifecycle vào Post-conditions của UC_4.15.2, REF tới UC_4.10.2 (SIM) nếu cấu trúc giống 100%, số ngày (10 days) giữ nguyên — không có tín hiệu nào từ QnA cho thấy LIVE dùng số ngày khác. | 1. Cái số 10 đó không phải fixed mà lấy từ trường trong bảng zapier nên b tự check lại2. Trên live, logic là hard breach thì xóa trading account ngay lập tức nhé, nhưng data thì chỉ bị archived sau khoảng 10 ngày -> nên sau đó mới reset về D=03. LIVE thì auto xóa account nên chỉ có rebuy, k có reset | ✅ Đã chốt |
| QN-4.15.2-04 | 🟢 [Xác nhận reference, không phải câu hỏi mới] CR-20260816-001 (Active, "Stagnation Path Double Notification Collision") mô tả đúng chính xác logic suppress email mà Flow 19 trong input đã có sẵn ("but do not send the Drawdown_Defense_Activated_Initial email" / "but do not send the Live_Account_Closed email"). Xác nhận SRS chỉ cần cite CR-20260816-001 làm nguồn chính thức cho đoạn suppression logic này (không cần raise thêm câu hỏi, vì input + CR + FR-29/FR-52 đã đồng nhất 100%)? | Đồng ý — cite CR-20260816-001 trực tiếp trong Business Rules của SRS khi mô tả suppression logic Flow 19→Flow 7/Flow 4B. | Chuẩn rồi. Ở UC LIVE ref sang SIM là được nhé | ✅ Đã chốt |
| QN-4.15.2-05 | 🟢 [Xác nhận reference — Founding Mentor block] Founding Mentor edge-case trong input khớp 100% với POD-FM-01→06 (QnA_STAGE2_COMMUNITY_LIVE_BROADCAST.md) và FM-01→12 (QnA_STAGE2_FOUNDING_MENTOR.md) đã confirmed — không có mâu thuẫn mới. Xác nhận SRS viết block này bằng cách REF trực tiếp tới UC_4.10.2 §6 Alternative Flow (Founding Mentor Hard Breach — đã có sẵn overlay spec đầy đủ: Header/Content/Button/wireframe/acknowledgement logic), chỉ note phần khác biệt (nếu có) là "SIM → chuyển sang mua Reset" vs "LIVE → chuyển sang mua Re-buy (locked_rebuy_price nếu is_founder)"? | Đồng ý REF tới UC_4.10.2 §6/§7, chỉ viết riêng phần CTA khác biệt (Reset vs Re-buy pricing). | Đúng rùi | ✅ Đã chốt |
| QN-4.15.2-06 | 🟢 [Pattern check] Input ghi trực tiếp Market_Loss_When_Stopped: Table A (Forex), Table B (Futures) không qua biến trung gian. UC_4.15.1 (Soft Breach LIVE) đã chốt dùng pattern Daily_Loss_Limit = Market_Loss_When_Stopped × Daily_Loss_Ratio để trace rõ nguồn Table C. Với Hard Breach, Market_Loss_When_Stopped đã LÀ giá trị cuối (không qua tỷ lệ nào nữa) — xác nhận SRS viết thẳng Equity <= Market_Loss_When_Stopped (Table A/B lookup theo current_level), không cần thêm biến trung gian nào? | Đồng ý viết thẳng, không cần biến trung gian — khác với Soft Breach (có tỷ lệ 1/3), Hard Breach lấy nguyên giá trị Table A/B. | Uh k cần biến trung gian đâu | ✅ Đã chốt |
Ghi chú bổ sung (BA correction, verified against source trước khi đưa vào SRS)
Về QN-03 điểm (1) — verified: field chính xác trong Zapier Table C là Discount_Code_Duration_Days (default = 10 ngày, đọc dynamic, operations có thể đổi bất kỳ lúc nào không cần deploy code) — đúng theo UC_4.10.2 BR_4.10.2.3. SRS của UC_4.15.2 phải dùng đúng tên field này (không viết "10 days" như một hằng số cố định), và REF thẳng tới BR_4.10.2.3 thay vì viết lại.
Về QN-03 điểm (2)+(3) — đây là khác biệt kiến trúc THỰC SỰ giữa LIVE và SIM (không phải chỗ nào cũng giống 100% như directive ở đầu file nói), cần Architect đặc biệt chú ý khi viết SRS:
| SIM (UC_4.10.2) | LIVE (UC_4.15.2) | |
|---|---|---|
| Account tại T+0 | Lock Read-Only (KHÔNG xóa) | Hard-delete ngay lập tức qua DeleteUser API (dừng luôn $25/platform fee) |
| Account bị xóa lúc nào | Sau khi hết Discount_Code_Duration_Days (cron job gọi DeleteUser) | Ngay tại T+0, cùng lúc với breach |
| Data/dashboard frozen | Giữ nguyên tới hết Discount_Code_Duration_Days, sau đó purge + reset D=0 | Giống — giữ frozen tới hết Discount_Code_Duration_Days, sau đó purge + reset D=0 (KHÔNG đổi ở phần này) |
| CTA sau breach | Reset (mua evaluation mới) | Re-buy (mua lại Live evaluation) — KHÔNG có khái niệm "Reset" cho LIVE |
Architect cần viết rõ Post-conditions theo bảng trên: Immediate (T+0) của LIVE phải nêu account bị hard-delete ngay (khác SIM), còn phần data/archive/D=0 lifecycle thì REF nguyên khối tới UC_4.10.2 vì logic thời gian giống nhau.
Changelog
| Date | Version | Updated item | Before | After | Notes |
|---|---|---|---|---|---|
| 2026-08-18 | v1 | Initial creation | — | 6 QnA items | Init Flow Step 1+2 — challenged against UC_4.10.2 (SIM sibling), zapier_v7_full.txt Flow 7/7B/9/19/20/21 (dòng 1638-2176), QnA_STAGE2_FAILURE_AND_RECOVERY.md (FR-01→FR-54), QnA_STAGE2_FOUNDING_MENTOR.md (FM-01→12), QnA_STAGE2_COMMUNITY_LIVE_BROADCAST.md (POD-FM-01→06), and _CR_INDEX.md (CR-20260816-001). |
| 2026-08-18 | v1.1 | All 6 QnA items — Status column | ⏳ Chờ BA (all) | ✅ Đã chốt (all) | BA đã trả lời toàn bộ QnA trực tiếp trong file. BA correction quan trọng ở QN-03: LIVE KHÔNG có "Reset", chỉ có "Re-buy" vì account bị hard-delete ngay tại T+0 (khác SIM chỉ lock read-only); số ngày archive window đọc dynamic từ Discount_Code_Duration_Days (Table C), không hardcode 10. Verified field name against UC_4.10.2 BR_4.10.2.3 trước khi ghi vào ghi chú bổ sung. |
✅ BA Review Gate — Hoàn tất
Toàn bộ 6 câu hỏi đã được BA trả lời và chốt (2026-08-18). Init Flow tiếp tục sang Agent 3 (Architect) để viết SRS chính thức cho UC_4.15.2.