QnA Init Docs — UC_4.15.3: Scenario B - Live Failure (In-App Re-Buy)
Ngày tạo: 2026-08-18 Phiên bản: v1 BA phụ trách: Huyen Dinh Trạng thái: ✅ Đã chốt — sẵn sàng chuyển Architect
Ghi chú kiến trúc (đề xuất, chờ BA xác nhận — xem QN-4.15.3-05): UC_4.15.3 (LIVE Re-Buy) là cặp tương đương của UC_4.10.3 (SIM Reset/Start New Track) — cùng category "Failure & Recovery", cùng kiến trúc gate (Status → Sanctions → Vaulted card) + payment flow (1-Click/Secure Checkout/Promo Code). Khác biệt chính: LIVE không có nhánh "Reset — tái sử dụng sub-account", mọi trường hợp Re-Buy đều tương đương nhánh "Start New Track" của SIM (hard-delete sub-account + provision mới), cộng thêm field-reset list riêng cho LIVE (FR-01) và pricing Founder đơn giản hơn (FR-16). Đề xuất Architect REFERENCE thẳng tới UC_4.10.3 cho phần payment flow/gate/promo code, chỉ viết riêng phần khác biệt LIVE.
Input gốc do anh cung cấp (bảng Definition/Trigger/Business logic/UI-UX/Zapier flow/Endpoints cho UC_4.15.3 — Scenario B) được đối chiếu với UC_4.10.3 (SIM — cùng function, khác environment),
QnA_STAGE2_FAILURE_AND_RECOVERY.md(FR-01 đến FR-54),common_rules.md, và WBS. Các câu hỏi dưới đây chỉ nêu phần khác biệt/mâu thuẫn/gap — phần nào input đã khớp 100% với QnA/SIM thì không raise lại.
UC_4.15.3 — Scenario B: Live Failure (In-App Re-Buy)
| 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.3-01 | 🔴**[CRITICAL — mâu thuẫn với QnA đã confirm] Founder pricing logic.** Input (Business logic, mục 1-2) viết: "1. IF is_founder==TRUE + within Discount_Code_Duration_Days → retrieve locked_reset_price. 2. IF is_founder==TRUE + expired → retrieve locked_rebuy_price." Tức input chia Founder pricing theo 2 nhánh window, dùng cả locked_reset_price VÀ locked_rebuy_price. Nhưng FR-16 (confirmed) nói rõ: Founder KHÔNG BAO GIỜ dùng locked_reset_price ở LIVE Re-Buy (field này chỉ dành cho SIM evaluation reset) — Founder LUÔN LUÔN dùng locked_rebuy_price, bất kể còn trong hạn hay đã hết hạn Discount_Code_Duration_Days. Input có bị soạn sai/nhầm với công thức SIM (UC_4.10.3 BR_4.10.3.1) không? | Theo FR-16: gộp mục 1+2 của input thành 1 rule duy nhất —is_founder==TRUE (bất kể window) → locked_rebuy_price. Không dùng locked_reset_price cho UC này. | Đây nha- Pricing Logic: 1 IF is_founder == TRUE → retrieve locked_rebuy_price. 3. IF is_founder = FALSE + within Discount_Code_Duration_Days → use formula: Challenge_Price × (1 − Retry_Discount)4. IF is_founder = FALSE + expired Discount_Code_Duration_Days → retrieved Full Challenge price (Table J)[Confirmed final — xem QN-01a]: rule pricing chính thức, thắng đoạn "Hỏi đáp số 1" step 2 (endpoint spec cần sửa khớp rule này khi build). | ✅ Đã chốt |
| QN-4.15.3-01a | 🔴**[FOLLOW-UP — đã giải quyết] Non-founder pricing có window-split không?** Đối chiếu QN-4.15.3-01 (Pricing Logic, business rule) vs đoạn "Hỏi đáp số 1" (step 2, endpoint spec) — step 2 thiếu điều kiện window cho non-founder. | Cần BA xác nhận nguồn nào đúng. | BA xác nhận: Pricing Logic ở QN-01 là rule đúng/chốt cuối (non-founder CÓ window-split — trong hạn thì Challenge_Price × (1 − Retry_Discount), hết hạn thì Full price Table J). "Hỏi đáp số 1" chỉ là đặc tả flow/endpoint BA đưa cho team build — không phải nguồn business rule riêng, step 2 của nó cần sửa lại cho khớp rule ở QN-01 (bổ sung điều kiện window cho non-founder khi build). | ✅ Đã chốt |
| QN-4.15.3-02 | 🟡Ranh giới scope với UC_4.15.4 (Defense Protocol Level 9+). Input (UI/UX, Step 1) liệt kê 4 modal biến thể khi Hard Breach: (a) Level 1-6, (b) Level 7-8, (c) Level 9+ với defense_used=FALSE, (d) Level 9+ với defense_used=TRUE. Nhưng UC_4.15.4 là 1 UC riêng tên "Scenario C: Defense Protocol (Level 9+)" — theo FR-51, khi Level 9-24 eligible, hệ thống hiển thị modal "Defense Protocol Activated" thay cho standard hard breach modal, không đi vào Re-Buy flow. Vậy UC_4.15.3 có cần viết chi tiết modal (c)/(d), hay chỉ cần viết (a)/(b) và REF sang UC_4.15.4 cho case Level 9+ (vì Level 9+ chỉ rơi vào Re-Buy flow này khi defense_used=TRUE — đã dùng hết defense bullet)? | UC_4.15.3 chỉ chi tiết modal (a) Level 1-6 và (b) Level 7-8 (severance, theo FR-30). Modal (c)/(d) cho Level 9+ REF sang UC_4.15.4 — Re-Buy flow (UC_4.15.3) chỉ áp dụng cho case (d)defense_used=TRUE (đã hết bullet, bị terminate thật), case (c) không vào flow này. | Uh 4.15.3 mô tả a và b thôi, c d sang 4.15.4 | ✅ Đã chốt |
| QN-4.15.3-03 | 🟢**"10 days" archive window có phải chính là Discount_Code_Duration_Days (Table C) không?** Input (UI/UX) ghi chú "Current logic for '10 days' - since 10 is not fixed" rồi liệt kê rule X ngày/Y giờ/<1 giờ giống UC_4.10.3. FR-54 (confirmed) xác nhận đúng logic countdown này, nói rõ archive_date = Failure + 10 Days, và cùng biến Discount_Code_Duration_Days cơ chế như SIM (Table C) — chỉ giá trị cấu hình cho LIVE hiện tại = 10 (SIM có thể khác). Xác nhận đúng: đây là cùng 1 biến Table C, LIVE chỉ có giá trị hiện tại khác SIM, không phải hardcode riêng? | Đúng — cùng biếnDiscount_Code_Duration_Days (Table C), LIVE hiện tại cấu hình = 10 ngày. Logic X ngày/Y giờ/<1 giờ tham chiếu thẳng FR-54, không viết lại. | Đúng vậy (Source: QnA FR-54, Table C) | ✅ Đã chốt |
| QN-4.15.3-04 | 🟡**[Gap — chờ FR-O-04] Futures Re-Buy — màn hình re-select Market Data.** Input (Zapier flow) không đề cập bước "re-select Market Data" sau khi user pass SIM lại. FR-32 (confirmed) xác nhận Futures Re-Buy vẫn phải re-select Market Data + trả phí add-on (vì setup_status đã reset NULL theo FR-01) trước khi tới POST /provision-live-user. Tuy nhiên UX cụ thể cho màn hình này là FR-O-04 — câu hỏi mở, khách CHƯA trả lời. UC_4.15.3 có cần block chờ FR-O-04, hay viết SRS với bước này đánh dấu [BLOCKED — pending FR-O-04] và không chặn tiến độ? | Không block. Viết SRS có nhắc bước "re-select Market Data" (Futures only, sau khi pass SIM lại, trước Live provisioning) theo FR-32, đánh dấu UX detail[BLOCKED — pending FR-O-04], không convert khỏi scope. | REF sang UC_5.6 (Flow 3F - Market Data Setup, live phase) — UC_5.6 mới đúng là nơi mô tả chi tiết flow re-select Market Data/activate feeds Rithmic cho live phase. UC_4.15.3 chỉ nhắc bước này tồn tại + REF link, không viết lại UX chi tiết. UX detail cụ thể vẫn [BLOCKED — pending FR-O-04] bên UC_5.6. | ✅ Đã chốt |
| QN-4.15.3-05 | 🟡**[PATTERN] Có nên REF thẳng UC_4.10.3 cho phần payment flow/gate/promo code, giống pattern UC_4.15.1↔UC_4.10.1?** UC_4.15.3 và UC_4.10.3 dùng chung: Gate 1 (Status check) → Gate 2 (Sanctions, Compliance_geo_restrictions) → Gate 3 (vaulted card customer_vault_id) → Path A (1-Click)/B (Secure Checkout)/C (Change Payment Method) → Promo Code flow (§6) → Payment Flow States (§6a, bảng case chuẩn) → Processing/Success/Failure screens. Khác biệt LIVE: (a) không có nhánh "Reset — tái sử dụng sub-account" (LIVE luôn hard-delete + provision mới), (b) Founder pricing đơn giản hơn (FR-16, chỉ 1 rule), (c) field-reset list riêng LIVE (FR-01), (d) trade/archival lifecycle khác (freeze tại breach metrics, không reset D=0 sớm — FR-31/FR-54), (e) endpoint tên khác (/initiate-rebuy theo WBS, xem QN-4.15.3-06). Đề xuất Architect viết UC_4.15.3 theo pattern REF-not-duplicate như UC_4.15.1, chỉ viết riêng 5 điểm khác biệt trên? | Có — REF thẳng UC_4.10.3 §5 (Gate/Path flow), §6 (Promo Code), §6a (Payment Flow States), §7 (Exceptional Flow payment cases) cho phần giống. Chỉ viết riêng: field-reset list, Founder pricing rule, archival lifecycle, endpoint LIVE-specific. | Đồng ý với assumption | ✅ Đã chốt |
| QN-4.15.3-06 | 🟢Endpoint naming — /initiate-rebuy? Input (Endpoints) chỉ liệt kê sequence không tên: "validate → price → sanctions → tax → charge → archive Live ledger → drop Live sub-account → POST /provision-sim-user → new credentials", và riêng POST /provision-sim-user (tái sử dụng, theo FR-01/UC_4.10.3 BR_4.10.3.3). Nhưng WBS (mapping_be) ghi rõ: "Build /initiate-rebuy endpoint". Xác nhận: toàn bộ sequence (validate→...→drop sub-account) là nội dung xử lý bên trong POST /initiate-rebuy (gọi tại bước "pay" click), và POST /provision-sim-user là endpoint riêng được gọi ở cuối (dùng chung với SIM Reset/Start New Track)? | Đúng —POST /initiate-rebuy là endpoint chính xử lý toàn bộ sequence pricing→charge→archive→drop; POST /provision-sim-user là endpoint dùng chung (Ref: UC_4.10.3 BR_4.10.3.3), được gọi ở bước cuối sau khi /initiate-rebuy complete. | Xem ở mục hỏi đáp số 1 bên dưới — xác nhận /initiate-rebuy xử lý toàn bộ sequence (Source: "Hỏi đáp số 1" §2026-08-18) | ✅ Đã chốt |
| QN-4.15.3-07 | 🟢Trigger status casing — 'terminated' hay 'Terminated'? Input (Trigger) viết "When: user_status = 'terminated'" (lowercase). FR-13 (confirmed) xác nhận DB value chuẩn là Status = 'Terminated' (viết hoa đầu, khác 'Failed' của SIM). Xác nhận SRS dùng đúng casing 'Terminated' theo FR-13, không dùng lowercase như input? | DùngStatus = 'Terminated' theo FR-13, sửa casing so với input gốc. | Đúng, theo FR-13 (Source: QnA FR-13) | ✅ Đã chốt |
| QN-4.15.3-08 | 🟢Field dots_payee_id — input xếp vào nhóm "remain intact", trùng khớp FR-01? Input (Business logic) liệt kê các field giữ nguyên: identity_status, contract_status, institution_approval_status, payout_status, dots_payee_id, veriff_failed_flag, veriff_attempts — khớp 100% với FR-01 (confirmed). Xác nhận không cần thay đổi gì, chỉ REF thẳng FR-01 khi viết SRS? | Khớp — REF thẳng FR-01, không viết lại danh sách field. | Đúng, khớp FR-01 (Source: QnA FR-01) | ✅ Đã chốt |
Hỏi đáp số 1:
Initiate Re-Buy (Challenge Retry) /initiate-rebuy
POST
user_id, payment_token (Optional), payment_method (Optional)
JSON { "status": "Success" }
- Validation: Check Status == 'Failed' OR Status == 'Terminated' on a Live DMA account profile to block active funded traders from abusing the link.
- Pricing Logic: If is_founder is TRUE, use their grandfathered locked_rebuy_price. If FALSE, query Table J to fetch the base Challenge Price corresponding to the user's active tier (Level 1, 2, or 5). Math: Discounted_Price = Challenge_Price * (1 - Retry_Discount).
- Sanctions Gate (Critical): Query the Users table via user_id to retrieve the stored billing_country and billing_region. Validate these against the Compliance_geo_restrictions PostgreSQL database table. Logic must explicitly allow traffic from nations with regional exemptions like Canada and Ukraine by evaluating the specific region parameter. IF a match is found where the database Country equals billing_country AND the
database Region equals 'All' or equals the billing_region: Return HTTP 403 Forbidden immediately with the restricted Country and Region names in the payload. 4. Tax Engine: Ping Quaderno API with billing_country and Discounted_Price to dynamically calculate required tax. 5. Math: Final_Charge = Discounted_Price
- Tax.
- Execution and UI Fallback: Check Users table for an existing customer_vault_id (NMI). IF a vaulted card exists, execute NMI server-to-server charge via selected MID for the Final_Charge. IF NO vaulted card exists, return a payload directing the frontend to jump to the standard Secure Checkout screen presenting the region-based options matching GET /system/status.
- Provisioning: If transaction is successful, archive the current failed live ledger data. Permanently drop the live sub-account to stop routing fees, reset the user profile back to an evaluation track at their current tier (Level 1, 2, or 5), and call the standard Provision Simulation User logic to issue a fresh challenge on the isolated simulation gateway.
Changelog
| Date | Version | Updated item | Before | After | Notes |
|---|---|---|---|---|---|
| 2026-08-18 | v1 | Initial creation | — | 8 QnA items | Init Flow Step 1+2 — challenged against UC_4.10.3 (SIM analog), QnA_STAGE2_FAILURE_AND_RECOVERY.md (FR-01 to FR-54), common_rules.md, WBS mapping_be. 3/8 items pre-filled từ confirmed QnA (FR-13, FR-01, FR-54); 5/8 items chờ BA xác nhận (1 CRITICAL — Founder pricing mâu thuẫn FR-16). |
| 2026-08-18 | v1.1 | QN-02, QN-05, QN-06 → chốt; QN-01, QN-06 bổ sung raw endpoint spec "Hỏi đáp số 1"; QN-01a mới | QN-02/05/06 ⏳ Chờ BA | ✅ Đã chốt | BA trả lời trực tiếp trong bảng. QN-01 (Founder pricing): BA chốt founder luôn dùng locked_rebuy_price (khớp FR-16) nhưng bổ sung rule non-founder có window-split — mục này lại mâu thuẫn với chính endpoint spec "Hỏi đáp số 1" (step 2) BA vừa cung cấp (không có window cho non-founder) và với glossary Re-Buy (common_rules.md). Raise thêm QN-4.15.3-01a [FOLLOW-UP CRITICAL] để BA xác nhận lại — chưa chốt được QN-01. QN-04 (Futures Market Data) vẫn chờ BA, chưa trả lời. |
| 2026-08-18 | v1.2 | QN-01, QN-01a → chốt | ⏳ Chờ BA | ✅ Đã chốt | BA xác nhận rule pricing ở QN-01 là chốt cuối (non-founder CÓ window-split: trong hạn → Challenge_Price × (1 − Retry_Discount), hết hạn → Full price Table J; founder luôn locked_rebuy_price, khớp FR-16). "Hỏi đáp số 1" chỉ là đặc tả flow/endpoint cho team build, không phải nguồn business rule — step 2 của nó cần sửa lại khi build cho khớp rule QN-01 (Architect sẽ note việc này ở SRS, không tự sửa raw input). Chỉ còn QN-04 (Futures Market Data, pending FR-O-04) chưa chốt. |
| 2026-08-18 | v1.3 | QN-04 → chốt | ⏳ Chờ BA | ✅ Đã chốt | BA chốt: REF sang UC_5.6 (Flow 3F - Market Data Setup, live phase, xác nhận qua WBS) cho bước re-select Market Data, không viết lại UX chi tiết trong UC_4.15.3. Toàn bộ 9 items đã chốt — QnA doc đủ điều kiện qua BA Review Gate, chuyển Agent 3 (Architect). |