StackTrading Docs

QnA Init Docs — UC_4.17.2: Settings — Account Actions: Resign Account (LIVE)

QnA Init Docs — UC_4.17.2 (Resign Account, LIVE)

FieldValue
UCUC_4.17.2 — Settings: Account Actions — Resign Account (LIVE)
BAQuynhAnh12
Ngày tạo2026-08-26
Doc liên quanUC_4.17.2_v1.md
Đánh sốTiếp nối dải của cụm LIVE Settings — UC_4.17.3 dùng A-40 → A-49, file này bắt đầu từ A-50. Các mục A-16.2 / A-25 / A-26 / A-47 là mục kế thừa, giữ nguyên ID gốc để không cắt đứt chuỗi tham chiếu

Cách đọc. Mỗi mục ghi rõ: câu hỏi, vì sao cần chốt, đề xuất của BA (nếu có), và mục đó đã được ghi vào SRS như thế nào — mọi mục còn mở đều được đánh dấu tại chỗ trong SRS, không mục nào bị "điền đại" bằng giả định.


1. Mục còn mở — chờ khách / chờ BA chốt

IDLoạiCâu hỏi / Vấn đềVì sao cần chốtĐề xuất của BAGhi ở SRSChủ sở hữuStatus
A-54IMPACTAi lấp khoảng trống giữa HTTP 200 và lúc status = 'Terminated' được ghi? Trên LIVE, status do Flow 7 Step 7 ghi chứ không phải POST /resign. Nên khi FE gọi GET /failure-state ngay sau khi nhận 200, Zapier có thể chưa chạy xong → API trả is_breached: false → Dashboard render bình thường đè lên một execution feed đã chết, Reset Associate Track vẫn Disabled, trader không có đường đi tiếp. Cùng lỗ hổng này khiến một Flow 7 lỗi/halt giữa chừng không thể phục hồi: gateway đã chết nhưng DB vẫn Active_DMA.Đây là khác biệt cấu trúc lớn nhất giữa LIVE và SIM (SIM middleware tự ghi status nên nhất quán ngay). Không có nguồn nào mô tả cơ chế bắc cầu. Rủi ro: trader bị kẹt vĩnh viễn ở trạng thái nửa vời.3 phương án: (a) FE lắng nghe WebSocket state-change rồi re-fetch (ít đụng BE nhất); (b) POST /resign ghi một interim status; (c) POST /resign ghi thẳng Terminated, Flow 7 không còn sở hữu bước ghi đó. BA nghiêng về (a).§5 step 7 (callout ⏳), §7 (2 bullet cuối), BR_4.17.2.5 step 8, BR_4.17.2.15BE + FE🔴 Chờ chốt — blocking
A-51SOURCE_GAPGiá trị state khoá gateway ở Day 0 cho LIVE chưa được doc nào sở hữu. UC_4.15.2 §5 Step 1 chỉ ghi "Lock: Disable order entry via Broker API". UC_4.10.2 §5 Step 3 trên SIM cũng chỉ ghi "Lock: Disable order entry via Broker API", không còn bảng giá trị theo gateway. Giá trị Rithmic Paper INACTIVE từng dùng cho SIM; note kiến trúc 2026-08-26 ghi Rithmic Live = Admin Only, khớp với câu trả lời của Rithmic Support trong _QNA_INDEX.md. MT5 = READONLY và TE = TRADING IS DISABLED BY RISK RULE thì nhất quán ở cả hai.BE không build được nếu không biết đặt account về state nào trên từng gateway. Đây là bảng dùng chung cho cả Hard Breach lẫn Resign nên phải nằm ở UC_4.15.2, không phải ở đây.Viết bảng LIVE một lần vào UC_4.15.2, rồi UC_4.17.2 reference sang. Giá trị đề xuất: Rithmic Live Admin Only · MT5 READONLY · TE TRADING IS DISABLED BY RISK RULE. SRS cố tình KHÔNG khẳng định các giá trị này.BR_4.17.2.5 step 2 + callout ⏳UC_4.15.2🔴 Chờ chốt — blocking
A-58IMPACTVa chạm email: Live_Account_Closed vs offer retention Flow 7B. Sau khi [RES-ZAPF-01] mở rộng trigger Flow 7B sang Terminated, trader LIVE resign nhận cả thư chấm dứt hợp đồng (Flow 7 Step 11) thư mời mua lại giảm giá (Flow 7B Path B), cách nhau khoảng 1 tiếng.Chính khách đã tự nêu vấn đề này ở O-30 và chưa trả lời. CR 2026-08-16_stagnation-email-collision-flow7-4b-7b xử lý một va chạm khác, không cover ca này. Ảnh hưởng thương hiệu + cần rule suppress/delay trong Zapier.Hoặc delay Flow 7B Path B thêm (VD 24h) khi termination_reason = 'VOLUNTARY_RESIGNATION', hoặc gộp offer vào chính Live_Account_Closed. Cần khách quyết.BR_4.17.2.9 (callout ⏳ cuối BR)Zapier / Marketing ops🔴 Chờ khách
A-57INTRA_RULE_CONTRADICTIONTrader đang trong 48h Defense freeze có được resign không? Lúc đó status = 'SUSPENDED_DEFENSE', nên cổng status phẳng ở BR_4.17.2.7 sẽ render nút Disabled. Nhưng vị thế của họ đã flat sẵn, và 48h đóng băng chính là lúc người ta quyết định rời đi. Bắt họ chờ hết freeze mới được resign không có lý do rủi ro nào.Nếu để Disabled thì có một khoảng 48h trader không có cách nào thoát; nếu để Enabled thì phải mở rộng cả cổng FE lẫn guard BE. Hai cách cho ra sản phẩm khác nhau.Cho phép resign — cổng đổi thành status IN ('Active_DMA', 'SUSPENDED_DEFENSE'). Không có rủi ro vốn vì tài khoản đã flat; và BR_4.17.2.10 vốn đã cho resign bypass Defense.BR_4.17.2.7 bảng state (dòng ⏳), §9.1 row 4Khách / BA🔴 Chờ chốt — blocking FE + BE
A-56IMPACTFounding Mentor: miễn trừ Digital Eviction có áp cho resign tự nguyện không? UC_4.15.2 §6 miễn cho Founding Mentor khỏi thu hồi role Discord + giữ nguyên pod — nhưng đó là đường Hard Breach. Hard Breach là sự kiện rủi ro ngoài ý muốn; resign là trader chủ động rời khỏi firm — đúng ca mà Digital Eviction sinh ra để xử lý.Không nguồn nào cover tổ hợp "Founding Mentor + voluntary resignation". Quyết sai theo hướng nào cũng tạo lỗi: hoặc đuổi nhầm một mentor sáng lập, hoặc để một người đã rời firm giữ nguyên quyền pod.Nghiêng về thu hồi (resign ≠ breach), nhưng đây là quyết định quan hệ đối tác, phải hỏi khách.§6.5 bước 2, BR_4.17.2.11Khách🔴 Chờ khách
A-63COPYCopy cho Row description ở bản LIVE. Chuỗi SIM "Permanently close your account and resign from the program. This action is immediate and irrevocable." thiếu đúng 2 hệ quả làm nên khác biệt của LIVE: mất toàn bộ lợi nhuận chưa vest, và mất quyền truy cập trading floor.FE cần chuỗi chính xác để build. Không nguồn nào cấp copy LIVE cho dòng này.Đề xuất mở rộng chuỗi để nêu 2 hệ quả trên; chờ khách duyệt wording.§9.1 row 3Khách🔴 Blocking FE
A-47 (kế thừa UC_4.17.3)APIproduct_id gửi kèm POST /calculate-cart khi bấm CTA [Start Associate Track] trên modal §9.4. SIM gửi "RESET". Scenario B của LIVE không đặt tên product, và A-25 vẫn để ngỏ chuyện nhánh resign có dùng "REBUY" hay không.BE + FE đều cần giá trị này. Nó cũng quyết định giá trader thấy.Phụ thuộc A-25. Nếu A-25 chốt theo hướng "có discount" → "REBUY".§9.4 row 4, BR_4.17.2.16UC_4.15.3🔴 Blocking BE + FE
A-25 (kế thừa UC_4.11.2 / UC_4.17.3)BIZTrader LIVE resign bị tính giá nào khi quay lại?đã trả lời một nửa bởi doc này. Phía email đã chốt: [RES-ZAPF-01] (2026-08-24) đưa mọi trader mất ghế vào funnel Flow 7B Path B với routing Retry_Discount chuẩn, ghi đè quyết định BA ngày 2026-08-12 ("resign không dùng Path B, mua giá đầy đủ"). Còn lại: CTA in-app có resolve về đúng mức giá product_id="REBUY" đó không?Nếu email chào giá giảm mà nút bấm trong app lại tính giá đầy đủ thì mâu thuẫn trực tiếp với trader. Đây là lý do mạnh nhất để chốt theo hướng có discount.Có discount — cùng routing với Hard Breach. Nhưng logic giá nằm ở UC_4.15.3 nên cần confirm chứ không tự áp.BR_4.17.2.9 (nửa email — ✅ đã đóng), BR_4.17.2.16 (nửa giá — ⏳)UC_4.15.3🟡 Nửa mở
A-60SCHEMAtermination_reason / termination_date vs failure_reason / failure_timestamp. CR-65 đổi tên cặp cột cho SIM; [RES-ZAPF-01] giữ tên gốc cho LIVE. Đây thực sự là 2 cặp cột trên cùng bảng users, hay 1 cặp bị doc gọi bằng 2 tên?Cron failsafe quét status IN ('Failed','Terminated') chung cho cả SIM lẫn LIVE, nhưng lại đọc termination_date ở nhánh LIVE và failure_timestamp ở nhánh SIM. Nếu là 1 cặp cột thì cron đơn giản; nếu là 2 cặp thì phải COALESCE.Đề xuất 1 cặp cột duy nhất, doc thống nhất tên. Nhưng phải BE xác nhận vì [RES-ZAPF-01] viết rõ "giữ nguyên cho cả hai".BR_4.17.2.14 (callout ⚠️), BR_4.17.2.17BE🟡 Blocking BE schema
A-62IMPACTFlow 7 Step 4 có retry flatten khi thị trường mở lại không? Nguồn mô tả nó là "second pass — a confirming safety re-check", tức chạy một lần. Một resign gửi vào cuối tuần có thể để lại vị thế mà cả hai pass đều không khớp, và LIVE không có Redis retry queue như SIM (BR_4.11.2.11).Nếu không retry, vị thế treo cho tới lúc purge ở archive_date — tức tài khoản đóng nhưng vẫn còn exposure thật trên sổ suốt 10 ngày. Đây là rủi ro vốn thật, không phải rủi ro UI.Xây retry queue cho LIVE giống SIM, hoàn thành job chỉ khi verify Open_Positions == 0 trên gateway.BR_4.17.2.18 (callout ⏳ cuối BR)BE🟡 Blocking BE
A-52CR_PENDINGCR-20260818-001 vẫn 🔴 Active (pending apply). Bước Pod Impact & Dispersal đã được đặc tả trong CR và được BR_4.17.2.11 reference, nhưng chưa được viết vào UC_4.15.2 §5 — pipeline ở đó vẫn chạy Digital Eviction → GL Posting, không có bước nào ở giữa.Bước này là nơi sở hữu duy nhất; nếu không apply thì cả Hard Breach lẫn Resign đều không build được phần pod.Apply CR vào UC_4.15.2 trước, UC_4.17.2 reference sang.BR_4.17.2.11 (⚠️ cuối BR)BA — UC_4.15.2🟡 BA action
A-55 ([RES-DEF-03])IMPACTPod Leader resign — thứ tự và xử lý lỗi. Flow 15A re-assign mentee trước hay sau khi account của leader bị terminate? Nếu không còn leader nào nhận, mentee mồ côi có vào waitlist không? Có giữ tạm registry row của leader tới khi re-assign xong không?Câu này BA đã hỏi khách trong CSV Settings: Resign Accountchưa được trả lời. Nếu terminate trước mà re-assign fail thì mentee treo vô thời hạn.Giữ registry row Terminated nhưng chỉ xoá liên kết mentee sau khi Flow 15A confirm; fallback = waitlist.§6.4 bước 4, BR_4.17.2.11Khách🟡 Chờ khách
A-61 (O-29(b) của khách)CONFLICTMốc EOM failsafe: 23:00 UTC hay 23:59? BR_4.15.2.7[RES-BIZ-03] ghi 23:00 UTC; [RES-BIZ-02] ghi "11:59 PM".Lệch 59 phút trên đúng cái cron sinh ra để chạy trước lúc CME quét sang tháng mới.SRS đi theo 23:00 UTC (giá trị mà BR sở hữu đang implement, và có đệm 1 tiếng cho batch). Cần khách chốt để đóng O-29(b).BR_4.17.2.17 (callout ⚠️)UC_4.15.2 / Khách🟡
A-64COPYModal cảnh báo Step 1 có liệt kê các hệ quả riêng của LIVE không? Copy đang kế thừa nêu: flatten vị thế, mất lợi nhuận chưa vest, mất quyền trading floor. Không nêu: thu hồi role Discord, giải tán pod, và việc severance có thể được chi trả. Cả ba đều là hệ quả thật.Đây là màn cảnh báo cuối cùng trước một hành động không thể hoàn tác. Thiếu thông tin = trader quyết định thiếu cơ sở. Nhưng tự ý thêm copy cho một hành động irreversible cũng không đúng.Đề xuất bổ sung 1 dòng về Discord/pod. Không nêu severance trong modal (xem A-26 — hứa tiền trước khi Marketing authorize là hứa hệ thống không giữ được).§9.2 row 4 + callout ⚠️Khách🟡
A-26 (kế thừa UC_4.11.2)COPYModal Resignation Complete bản LIVE có thêm dòng severance / exit interview không? Nửa "từ level nào" của câu hỏi này đã được trả lời: điều kiện là Severance_Pay > 0, không phải một con số level (BR_4.17.2.13). Còn lại đúng câu: modal có nhắc tới severance không.Nhắc thì trader an tâm; nhưng nêu con số trước khi Marketing bấm Authorize là hứa điều hệ thống chưa chắc chắn.Nếu có nhắc thì chỉ nêu định tính ("our team will contact you"), tuyệt đối không nêu số tiền.§6.3 bước 5, §9.4 row 2Khách🟡
A-50DESIGNKhông có Figma frame cho bản LIVE, và các frame SIM cũng chưa commit vào repo. References/Wireframe/ không có folder Settings ở bất kỳ stage nào; 3 frame SIM + screenshot Resignation Complete (2026-08-25) hiện chỉ được cite bằng Figma node / attachment.Doc không cite được path ổn định; QC không có artefact để đối chiếu. Cùng gap mà SIM đang track ở A-17 / A-23.Commit ảnh vào References/Wireframe/Stage 2.2/Settings/. Bản LIVE không cần frame riêng cho shell — nó kế thừa layout SIM; chỉ 2 chuỗi copy (A-63, A-64) là thật sự khác.Header §Document References, §9.1§9.4BA🟡 Housekeeping
A-53CROSS_UCCâu stale trong UC_4.15.2 §1. Vẫn ghi sub-account LIVE bị "hard-deleted immediately", mâu thuẫn với §4, §5 Step 7 và BR_4.15.2.7 — vốn nói account bị khoá Read-Only và chỉ purge ở archive_date hoặc khi Re-Buy.Nếu BE đọc §1 thì sẽ xoá account ngay Day 0 → phá vỡ chính cửa sổ 10 ngày mà [RES-BIZ-02] yêu cầu giữ. Trùng với UC_4.17.3 A-48.Sửa câu ở UC_4.15.2 §1. SRS này đi theo BR_4.15.2.7.§4 (bullet "Explicitly NOT"), BR_4.17.2.17UC_4.15.2🟡
A-59 ([RES-FRM-02])FORMULAAmount_Over_Stop_Loss > Severance_Pay → chặn sàn ở 0 hay ghi nhận thành nợ?Không thể xảy ra trên đường resign (deduction = $0 theo định nghĩa), nên không block doc này. Ghi lại để UC_7.5 xử lý.Chặn sàn ở 0 — không đòi lại tiền từ trader đã rời firm.BR_4.17.2.13 (bullet cuối)UC_7.5🟢
A-65 ([RES-DEF-02])BIZLịch sử nào sống sót qua một lần resign sang track mới — certificate đã đạt, trading journal, thống kê (win-rate, profit factor), role community.Các field compliance đã chốt (QnA FR-01) và role Discord đã chốt (BR_4.17.2.11); phần performance + certificate thì chưa. Ảnh hưởng Dashboard của trader quay lại, không ảnh hưởng màn này.Ngoài phạm vi UC này; thuộc UC_4.15.3UC_4.15.3🟢
A-16.2 (kế thừa UC_4.11.2)VALIDATIONMax length của ô nhập cụm từ xác nhận.Cần cho FE validation. Không ảnh hưởng logic.50 ký tự per CR-02 §2.2.§9.3 row 5Khách🟢

2. Mục được đóng bởi tài liệu này

ID / NguồnTrước đâyNayCăn cứ
UC_4.11.2 §9.4 row 3"⏳ Cửa sổ retention có áp cho LIVE resignation hay không — thuộc UC_4.17.2, chưa confirm"Có áp. Banner đếm ngược archive được render trên modal LIVE[RES-BIZ-02] (2026-08-24) — "Just retain the 10 day access. flow 20 → Flow 7. Same failsafe applies here." Ghi tại BR_4.17.2.17, §9.4 row 3
A-25 — nửa email"Trader LIVE resign có bị bỏ qua offer retention Flow 7B Path B không?" (quyết định BA 2026-08-12: có bỏ qua)Không bị bỏ qua — Flow 7B Path B vẫn chạy[RES-ZAPF-01] (2026-08-24) mở rộng trigger Flow 7B sang Failed OR Terminated với lý do rõ ràng: "every single trader who loses their seat, regardless of their level or how they lost it, gets dropped into the retention marketing funnel". Câu trả lời của khách 2026-08-24 thắng quyết định BA 2026-08-12 theo priority chain. Ghi tại BR_4.17.2.9. ⚠️ Kéo theo A-58 (va chạm email)
Ngưỡng severance3 con số mâu thuẫn cùng lưu hành: "Level 3+" (CSV Settings: Resign Account row Formula), "Level 7" (FR-30), "đừng hardcode" (FR-54)Severance_Pay > 0, evaluate động từ Table A/BFR-54 là bản correct mới nhất của khách và ghi đè cả hai con số level: "do NOT hardcode current_level >= 7… must evaluate the Severance_Pay value directly from the configuration matrix". Mọi hằng số level trong code/Zapier là defect. Ghi tại BR_4.17.2.13
UC_4.17.3 forward reference"UC_4.17.2 chưa có tài liệu… được reference bằng ID chứ không phải link"Đã có tài liệu. UC_4.17.3 có thể đổi sang link thậtGhi tại BR_4.17.2.16. Việc còn lại của BA: sửa các chỗ nhắc UC_4.17.2 trong UC_4.17.3 thành link
Amount_Over_Stop_Loss trên đường resignChưa doc LIVE nào ghi$0 → trader đủ điều kiện nhận 100% base Severance_PayQnA FR-20"if a trader voluntarily resigns, they have not breached the stop loss limit, so Amount_Over_Stop_Loss defaults to $0". Đây là số học, không cần nhánh riêng trong Flow 9. Ghi tại BR_4.17.2.13
Refund market data trên đường resignNote kiến trúc 2026-08-26 ghi "Bypass Market Data Refund"Bước Refund Check VẪN chạy — chỉ cho khoản prepay tháng sau, không prorate tháng đang chạy[MDM-BIZ-14] (2026-08-24) đảo chiều [MDM-BIZ-06]: bước này ở lại Flow 7 như một failsafe chống chargeback. Ghi tại BR_4.17.2.12
Discord role + pod trên LIVE[DL-BIZ-04] được UC_4.11.2 ghi là "vẫn valid cho LIVE, thuộc UC_4.17.2"Thu hồi toàn bộ role + giải tán podFlow 7 Step 8 + Step 8a — LIVE chạy Flow 7 nên chạy cả hai bước. Ghi tại BR_4.17.2.11. ⚠️ Còn A-56 (Founding Mentor) và A-52 (CR chưa apply)

3. Giả định BA đã áp dụng (không cần khách trả lời, nhưng ghi lại để truy vết)

IDGiả địnhLý doGhi ở SRS
A-66Cụm từ xác nhận trên LIVE giống SIM: RESIGN, phân biệt hoa/thường, hard-code. Không dùng cụm mạnh hơn cho LIVE.Khách trả lời "Giống SIM" cho row Trigger của cột LIVE. Không nguồn nào đề xuất cụm riêng cho LIVE, và tách ra sẽ fork một validator mà backend dùng chung cho cả hai nhánh.BR_4.17.2.4
A-67Nút [Resign Account] không bao giờ bị ẩn, chỉ Disabled; không tooltip, không helper line.Khớp pattern của section anh em (UC_4.17.3 §9.1 row 4, đã được BA chốt ngày 2026-08-26 là "no tooltip, no helper line"). Copy giải thích duy nhất nằm ở row description.§9.1 row 4
A-68Modal §9.4 được chọn bằng state_reason == "RESIGNATION", kể cả với Founding Mentor. Overlay Founding Mentor là cơ chế của Hard Breach, gắn với một breach event — không render trên đường resign.Overlay đó tồn tại để xử lý một sự kiện vi phạm rủi ro. Resign không sinh ra LEVEL_STOP_BREACH, nên không có event nào để overlay bám vào.§6.5 bước 3, BR_4.17.2.15
A-69Guard chống chạy 2 lần key trên status đơn thuần (IN ('Failed','Terminated') → 409), không key trên cặp status + termination_reason.Đồng bộ với BE-2 đã chốt bên SIM. Trên LIVE rủi ro còn cao hơn: một lần chạy Flow 7 thứ hai sẽ post lại QuickBooks, gửi lại Live_Account_Closed, và tạo task authorize severance thứ hai.BR_4.17.2.6
A-70Không có cảnh báo nào về Defense trong 2 modal friction, kể cả với trader Level 9+ còn nguyên Defense_Used.Không nguồn nào đề xuất; thêm vào là tự phát minh requirement. Bản thân BR_4.17.2.10 đã ghi rõ resign bypass Defense — nếu khách muốn cảnh báo, đó là một CR.§6.2 bước 2, BR_4.17.2.10
A-71virtual_equity bị đóng về 0 (Flow 7 Step 3) không làm trắng Dashboard đóng băng. Snapshot dưới lớp kính mờ là bản chụp tĩnh equity/balance/closed-trades tại failure_timestamp, không phải virtual_equity live.Nếu hai thứ là một thì trader sẽ nhìn thấy tài khoản $0 dưới lớp frost — phá vỡ chính mục đích giữ 10 ngày. UC_4.15.2 §4 mô tả rõ đó là "static snapshot".BR_4.17.2.14 (đoạn Ledger lifecycle)

4. Ghi chú cho BA

  • Không có CR mới được mở bởi tài liệu này. Mọi conflict phát hiện đều nằm trong phạm vi các câu trả lời khách đã có hoặc các open item khách đã tự nêu (O-29, O-30).
  • 3 chỗ SRS ghi đè nguồn cũ, đều được ghi lại tại chỗ + trong Changelog, không sửa lặng lẽ: ngưỡng severance (A-25 mục "đóng"), Flow 7B Path B, và bước Refund market data.
  • 2 chỗ SRS cố tình KHÔNG khẳng định vì không nguồn nào sở hữu: giá trị state khoá gateway trên LIVE (A-51) và cách xử lý race Terminated (A-54). Cả hai được raise thay vì đoán.
  • Việc BA cần làm sau khi khách duyệt: (1) thêm dòng UC_4.17.3 vào WBS (A-40 của UC_4.17.3, vẫn mở); (2) sửa forward reference trong UC_4.17.3 thành link; (3) apply CR-20260818-001 vào UC_4.15.2 (A-52); (4) sửa câu stale ở UC_4.15.2 §1 (A-53); (5) viết bảng gateway state LIVE vào UC_4.15.2 (A-51).

On this page