Câu hỏi và giả định phát sinh trong Init Flow (Agent 1 Auditor + Agent 2 Challenger) cho UC_4.11.2 — SIM Resign & Close Account

QnA Init Docs — UC_4.11.2: Account Actions — Resign Account (SIM)

Phạm vi vòng này: chỉ UC_4.11.2 — Settings: Account Actions → Resign & Close Account, môi trường SIM (WBS category STAGE 2.1. DASHBOARD SIM). Bản LIVE là UC riêng — UC_4.17.2 (WBS dòng 117), không thuộc phạm vi tài liệu này.

Ngày tạo: 2026-08-11 Ngày BA review: 2026-08-11 BA in Charge: QuynhAnh12 (git username — chưa có trong BA Roster của project_context.md, xem A-22) Ngày cập nhật: 2026-09-03 (đồng bộ toàn bộ với UC_4.11.2 v3.3) Trạng thái tổng: ✅ Không còn câu hỏi mở. Toàn bộ mục thuộc UC_4.11.2 đã được khách trả lời, mốc cuối 2026-09-03. Các mục thuộc UC khác đã chuyển sang mục Ngoài phạm vi UC_4.11.2.

Nguồn đã đọc (theo MANDATORY FIRST-READ PROTOCOL)

Bước	Nguồn	Kết quả
0	`References/Customer supplies/_SOURCE_MANIFEST.yaml`	✅ Đã đọc
1	`References/CR/_CR_INDEX.md`	✅ Không có CR nào về Resign. CR liên quan gián tiếp: `CR-20260806-001` (Dashboard Sidebar — Logout Action) — chạm cơ chế teardown session/token, xem A-08.
1	`References/QnA from clients/.../Settings + Career + Viral/Stage 2 - Dashboard & Fomula (Settings).csv` → hàng `Settings: Resign Account` (rows 57–64)	✅ Nguồn chính. Các cột `SIM environment` / `Trigger` / `Business logic` / `Endpoints` / `Zapier flow` / `Zapier table` / `UI/UX` là requirement khách viết → dùng trực tiếp.⚠️ Cột `Answers` của 4 hàng này trống — 7 câu hỏi khách (`RES-DEF-01→04`, `RES-TRIG-01`, `RES-FRM-01→02`) chưa được trả lời. Đã verify toàn bộ 27 cột + cả 2 file CSV QnA + `Broadcast, Settings_Market Data.docx`.
1	`References/QnA from clients/.../QnA_STAGE2_SETTINGS_CAREER_VIRAL.md` §8	✅ Dùng được 1 câu đã confirm: `[DL-BIZ-04]` (Discord revoke role khi Terminate/Resign) — xem A-13.
2	`RFQ_ Website and Dashboard Implementation V7.pdf` (§Part C — "Resign & Close Account Button", Step 1 Warning / Step 2 Confirmation)	✅ Nguồn gốc của 2-step friction modal
2	`RFQ_ Stack Trading Prop Tech V7.pdf` (§Endpoint `POST /resign`)	✅ `{user_id, confirmation_phrase}` → HTTP 200 OK → trigger Flow 20
2	`Zapier Integration V7.pdf` (§Flow 20, §Flow 7 — Resignation Path)	✅
—	WBS `References/WBS/[BA Internal] Stacktrading.csv`	✅ Đã có mã — dòng 98 `UC_4.11.1` (Reset Associate Track, SIM), dòng 99 `UC_4.11.2` (Resign Account, SIM), dòng 117 `UC_4.17.2` (Resign Account, LIVE)
—	Design BA cung cấp (3 frame: Account Actions tab · Step 1 modal · Step 2 modal)	✅ Nguồn của copy text và cấu trúc 2 modal

Bảng QnA & Assumption

Ký hiệu: 🔴 = chặn cứng · 🟡 = ảnh hưởng chất lượng, có default hợp lý · ⚪ = ghi nhận, không chặn.

ID	Câu hỏi / Vấn đề	Đề xuất của Agent	BA Answer	Status
A-01	Mã UC không khớp WBS.	—	BA: WBS đã được cập nhật. `UC_4.11.1` = Reset Associate Track (SIM), `UC_4.11.2` = Resign Account (SIM), `UC_4.17.2` = Resign Account (LIVE). UC này chỉ viết cho SIM, LIVE viết riêng.	✅ Đã chốt (BA, 2026-08-11) — verify lại WBS dòng 98/99/117, khớp.
A-02	Copy 2 modal đang là copy LIVE. Step 1: "All open positions will be flattened. All unvested profits will be forfeited. You will lose access to the trading floor immediately." Step 2: "All open positions will be flattened and unvested profits forfeited." Trader SIM Level 0 không có unvested profit, không ở trading floor.	Giữ nguyên copy trong design, không sửa — CSV cột UI/UX ghi "Same as SIM" (1 bộ design dùng chung SIM/LIVE). Sửa copy là việc của khách, không phải suy diễn của Agent.	✅ BA chốt: theo đề xuất — giữ nguyên copy design.	✅ Đã chốt (BA, 2026-08-11)
A-03	Tưởng là mâu thuẫn: logout vs giữ login.	—	Không phải mâu thuẫn — CSV cột `SIM environment` đã nói rõ cả hai lớp: `POST /resign` "forces a session kick → logs out of the dashboard" (session hiện tại bị kill) và "The dashboard login stays active (so they can buy a new evaluation), but the trading account is hard-deleted on the execution server (Rithmic Paper/MT5 Sim)" (tài khoản login vẫn còn). Khớp với `Zapier Integration V7.pdf` Flow 7 §Post-Termination Access Control: *"Keeps Dashboard login active (for 'Reset' purchase), but blocks trading"`.	✅ Đóng — đã có nguồn, không cần hỏi
A-04	🔴 Sau khi `POST /resign` trả 200, user thấy màn gì? Không nguồn nào mô tả. Các khả năng: (a) success screen "Resignation Complete" + CTA rồi mới logout (pattern của UC_4.10.3 §10.7); (b) đá thẳng về màn login; (c) toast rồi redirect.	Đề xuất (a) — hành động không thể hoàn tác, đá thẳng ra login khiến user không chắc lệnh đã chạy chưa. Cần chốt copy header/body/CTA.	✅ ĐÓNG 2026-08-12 — khách chọn phương án (d), không nằm trong 3 khả năng BA đưa ra. `[RES-BIZ-01]`: "Do not build a success screen. Do not clear the session tokens or log the user out… simply refresh the user's dashboard state → status Terminated → Frosted Glass → modal." Copy modal do BA chốt cùng ngày.	✅ Đã viết vào SRS: §5 bước 7, BR_4.11.2.15, §9.4
A-05	🔴 Cụm từ xác nhận (đúng câu khách hỏi `RES-TRIG-01`, chưa trả lời). RFQ ghi "a confirmation phrase (e.g.* RESIGN or their username)"* — "e.g." nghĩa là chưa chốt. Design hiển thị chip `RESIGN`. Cần rõ: (a) chuỗi chính xác? (b) phân biệt hoa/thường? (c) auto-trim? (d) hard-code hay Table C? (e) gõ sai N lần thì sao?	Đề xuất: chuỗi cố định `RESIGN`, phân biệt hoa thường, auto-trim đầu/cuối, hard-code FE, không giới hạn số lần gõ sai.	✅ ĐÓNG một phần 2026-08-12. `[RES-TRIG-01]`: "Yes. Must be typed exactly in the proper case." → case-sensitive, cụm từ là `Resign` (theo đúng cách viết trong câu hỏi). ⚠️ Chip Figma đang là `RESIGN` → phải sửa design. ✅ Đóng 2026-09-03: hardcode `RESIGN` ở cả FE lẫn BE (không đọc Table C); không giới hạn số lần gõ sai, không khoá. → BR_4.11.2.3	✅ Đã viết vào SRS: BR_4.11.2.4, §9.3 row 5
A-06	🔴 Trạng thái nút `[Resign & Close Account]` ở Step 2. Caption design ghi "Type `RESIGN` to enable the final button" → phải Disabled khi chưa khớp. Nhưng frame lại vẽ nút trông như enabled trong khi ô input còn là placeholder `Type here..`.	Theo caption (là rule), không theo màu trong frame: mặc định Disabled, chỉ Enabled khi input khớp chính xác.	✅ ĐÓNG 2026-08-12 — khách xác nhận đúng đề xuất của BA. `[RES-UI-01]`: "The button must remain completely disabled until the user types the confirmation phrase exactly. Do not leave it enabled just to display error states." → frame Figma vẽ sai, caption mới là rule.	✅ Đã viết vào SRS: §9.3 row 6
A-07	Resign có bị chặn theo trạng thái tài khoản không? (a) đang `Failed` + Frosted Glass sau Hard Breach; (b) đang trong Soft Breach lockout; (c) đã `Terminated`.	Đề xuất cho phép ở (a) và (b).	✅ BA chốt: cho phép.	✅ Đã chốt (BA, 2026-08-11) — Áp dụng: Resign khả dụng ở mọi trạng thái SIM còn hoạt động: `Active_SIM`, Soft Breach lockout (UC_4.10.1), `Failed` + Frosted Glass (UC_4.10.2). Riêng `Terminated` không phải "chặn" mà là không còn ngữ cảnh — session đã bị kill, và BE guard ở A-10 sẽ trả 409 nếu vẫn có request tới.
A-08	Chồng lấn với `CR-20260806-001` — CR này đang treo phần token clearing + redirect target + audio/session teardown của Logout, chờ "Settings/Logout UC". Resign cần đúng bộ hành vi đó + dừng Newsquawk stream (Ref BR_4.1.4.3) + đóng WebSocket.	UC_4.11.2 không tự định nghĩa cơ chế teardown — chỉ nói "session bị terminate theo cơ chế Logout chung" và trỏ về CR-20260806-001, tránh 2 UC spec 2 kiểu logout khác nhau.	(BA không phản hồi riêng — áp dụng đề xuất)	✅ Applied by default
A-09	`POST /resign` lỗi 4xx/5xx/timeout/mất mạng. Hành động irreversible, không nguồn nào spec xử lý lỗi.	Giữ modal Step 2 mở + Ref: TE-SYS-01, CTA re-enable để retry thủ công, không auto-retry (tránh double-execute). Nếu lỗi là 409/422 do state đã đổi (account vừa bị Terminated bởi luồng khác) → đóng modal + Ref: TE-DASH-01 rồi reload màn Account.	✅ BA chốt: theo đề xuất.	✅ Đã chốt (BA, 2026-08-11)
A-10	Idempotency / double-execute. `POST /resign` chạy chuỗi phá huỷ (ReadOnly → cancel orders → flatten → webhook). Double-click, FE timeout rồi bấm lại, hoặc 2 tab cùng resign → `RESIGNATION_EXECUTED` bắn 2 lần → Flow 20 → Flow 7 chạy 2 lần.	(a) FE disable nút ngay khi click + loading state (pattern UC_4.10.3 §10.2 item 6); (b) BE guard: `status == 'Terminated'` → trả 409 và không bắn webhook lần hai.	✅ BA chốt: theo đề xuất.	✅ Đã chốt (BA, 2026-08-11) — ⚠️ Vế (b) cần BE xác nhận khả thi khi review SRS
A-11	Flatten khi thị trường đóng. Bước flatten dùng market order; nếu thị trường ở state `Closed`/`Halted` (Ref UC_4.1.3) thì market order không khớp được.	Resign vẫn đi tiếp — account chuyển ReadOnly ngay, phần flatten còn lại để Flow 7 bước (b) dọn khi thị trường mở lại (Flow 7 vốn thiết kế "flatten lại nếu Middleware chưa làm"). Không chặn user resign chỉ vì thị trường đóng.	(BA không phản hồi riêng — áp dụng đề xuất)	✅ Applied by default — ⚠️ suy luận từ thiết kế Flow 7, đề nghị BE xác nhận
A-12	Các nhánh Flow 7 có chạy cho SIM không? (Ban đầu Agent nghi (e) Bad_Debt_Log, (h) QuickBooks, (i) email `Live_Account_Closed` là logic LIVE.)	—	Không cần hỏi — CSV cột `SIM environment` (Business logic) đã liệt kê đầy đủ (a)→(j) cho SIM, gồm cả (c) Refund Check Market Data, (e) Balance Check → `Bad_Debt_Log`, (h) GL Posting → QuickBooks, (i) email `Live_Account_Closed`, (j) Feedback Survey Gate. Chỉ Flow 9 (Severance) là không chạy (chỉ LIVE Level ≥ 3).	✅ Đóng — viết theo đúng CSV. ⚪ Ghi nhận: tên email `Live_Account_Closed` gửi cho trader SIM là điểm đặt tên hơi lệch — ghi nguyên tên theo nguồn, không tự đổi.
A-13	Discord khi resign.	Áp dụng nguyên văn câu trả lời khách đã confirm.	Đã có câu trả lời confirmed (`[DL-BIZ-04]`, `QnA_STAGE2_SETTINGS_CAREER_VIRAL.md`): Flow 7 gọi `POST /discord/revoke-all-roles` → gỡ title role + pod role, KHÔNG kick khỏi server, KHÔNG xoá `discord_user_id`. Mua evaluation mới → bỏ qua bước sinh token, gán thẳng role "Associate Trader".	✅ Đã chốt — dùng trực tiếp
A-14	Flow 7 bước (j) — Feedback Survey Gate: `IF pod_leader_id IS NOT NULL` → gửi Typeform exit survey cho mentee. Trader SIM có bao giờ được gán `pod_leader_id` không? (UC_4.9.2 — POD module ở SIM là trạng thái khoá)	Cần BA xác nhận trước khi kết luận nhánh này không chạy.	✅ BA chốt: trader SIM không join được POD system → không bao giờ được gán pod leader.	✅ Đã chốt (BA, 2026-08-11) — Áp dụng: với SIM, `pod_leader_id` luôn `NULL` → Flow 7 bước (j) không bao giờ trigger. SRS ghi rõ nhánh này tồn tại trong Flow 7 nhưng không đạt điều kiện ở môi trường SIM.
A-15	Timing `user_account_history` snapshot.	—	Không cần hỏi — CSV cột `Zapier table` đã ghi rõ: snapshot được tạo khi user repurchase, không phải tại thời điểm resign. Tại thời điểm resign chỉ có `users.status='Terminated'`, `termination_reason='VOLUNTARY_RESIGNATION'`, `termination_date=NOW()`, `audit.action='RESIGN'`. SQL database vẫn giữ performance ledger (Flow 7 bước (f) chỉ purge platform connection).	✅ Đóng — đã có nguồn
A-16.1	Ô nhập cụm từ xác nhận — có cho paste (Ctrl+V) không? Trên chính modal đã có sẵn chữ `RESIGN` ở dòng hướng dẫn → cho paste thì user copy-paste được, friction giảm gần bằng 0, ngược với chủ đích "This prevents accidental clicks" của RFQ.	Agent đề xuất chặn paste.	✅ BA chốt: CHO paste (override đề xuất của Agent).	✅ Đã chốt (BA, 2026-08-11) — SRS ghi: ô input cho phép paste, không chặn clipboard. ⚪ Ghi nhận đánh đổi: friction thực tế thấp hơn chủ đích của RFQ §Part C.
A-16.2	Giới hạn ký tự nhập của ô. Chặn cứng ở đúng độ dài cụm từ, hay cho gõ tối đa 50 ký tự theo CR-02 §2.2?	Cho tối đa 50 ký tự — không phụ thuộc cụm từ là gì.	⏸️ BA PAUSE — phụ thuộc A-05/A-06 (khách chốt cụm từ + quy tắc enable nút trước đã).	✅ ĐÓNG 2026-09-03 — 50 ký tự (CR-02 §2.2). Đã viết vào BR_4.11.2.3 và §9.3 dòng 5.
A-16.3	Kiểm tra khớp lúc nào — `onChange` (nút sáng ngay khi gõ đủ) hay `onBlur`?	`onChange` — chuẩn của mọi type-to-confirm.	✅ ĐÓNG 2026-08-12 (suy ra từ `[RES-UI-01]`). "completely disabled until the user types the confirmation phrase exactly" chỉ thoả nếu so khớp chạy theo từng ký tự → `onChange`.	✅ Đã viết vào SRS: BR_4.11.2.4, §9.3 row 5
A-16.4	Gõ sai có hiện inline error không? Nếu check `onChange` thì lúc user mới gõ `R`, `RE`, `RES`… đều "chưa khớp" → hiện đỏ liên tục là nhiễu.	Không hiện error — trạng thái Disabled của nút CTA đã là feedback đủ.	✅ ĐÓNG 2026-08-12 — khách xác nhận đúng đề xuất của BA. `[RES-UI-01]`: "Do not leave it enabled just to display error states." → không có inline error, Disabled là feedback duy nhất.	✅ Đã viết vào SRS: BR_4.11.2.4, §9.3 row 5. Không thêm ID error nào vào `list-toast-popup.md`.
A-16.5	Khoảng trắng thừa đầu/cuối — gõ `RESIGN` (dư 1 space) có tính là khớp không?	Auto-trim đầu/cuối theo CR-02 §2.1 — space thừa không phải ý định của user.	✅ BA chốt: theo đề xuất.	✅ Đã chốt (BA, 2026-08-11)
A-17.1	Bấm ra vùng tối ngoài modal (overlay click) có đóng modal không?	Không đóng — ở Step 2 user đã gõ cụm từ, bấm trượt mà modal đóng thì phải gõ lại.	✅ BA chốt: KHÔNG đóng (áp dụng cho cả 2 modal).	✅ Đã chốt (BA, 2026-08-11)
A-17.2	Phím `Esc` có đóng modal không?	Agent đề xuất có (chuẩn accessibility — user dùng bàn phím cần đường thoát).	✅ BA chốt: KHÔNG cho (override đề xuất của Agent).	✅ Đã chốt (BA, 2026-08-11) — ⚠️ Hệ quả cần ghi nhận: A-17.1 + A-17.2 cùng chọn "không" → nút `[Cancel]` là đường thoát DUY NHẤT của cả 2 modal. SRS ghi nguyên như vậy.
A-17.3	*Nút `[Cancel]` ở Step 2 (Confirm Resignation) đưa user về đâu* — đóng hẳn về tab Account Actions, hay quay về Step 1?	Đóng hẳn về tab `Account Actions` — design không có nút "Back", bắt đi lại Step 1 mới thoát được là thừa.	✅ BA chốt: theo đề xuất — đóng hẳn về tab Account Actions.	✅ Đã chốt (BA, 2026-08-11)
A-17.4	Đóng rồi mở lại, ô input còn giữ chữ đã gõ không?	Clear rỗng mỗi lần mở Step 2 — giữ lại đồng nghĩa lần sau mở lên nút đã sẵn sàng bấm, mất toàn bộ friction.	✅ BA chốt: theo đề xuất — clear rỗng.	✅ Đã chốt (BA, 2026-08-11)
A-18	Ranh giới UC — màn `Account` và tab list do UC nào own? Design màn Account (SIM) có 5 tab + panel `Controls`; tab `Account Actions` chứa 2 section (`Reset Associate Track`, `Resign & Close Account`).	UC_4.11.2 chỉ own section `Resign & Close Account` + 2 modal của nó. Phần còn lại trỏ đi: tab list & shell → UC_4.6.1; panel Controls → `UC_4.6.5`; section Reset → `UC_4.11.1` + UC_4.10.3 §5.3; entry point (chip `SD`/`Lvl 5` góc dưới trái sidebar) → UC_4.1.2 §2 row 6.	(BA không phản hồi riêng — áp dụng đề xuất)	✅ Applied by default
A-22	⚪ Metadata `BA in Charge`. `git config user.name` = `QuynhAnh12`, không có trong BA Roster của `project_context.md`.	Tạm ghi `QuynhAnh12` trong header SRS; đề nghị BA bổ sung tên hiển thị vào roster. (Đã ghi nhận trước đó tại `UC_4.6.1-4.6.4/QnA_init_docs.md` A-19 — vẫn chưa xử lý.)	(BA không phản hồi riêng)	⚪ Ghi nhận
A-24	⚪ [Phát hiện khi self-audit] Folder CR của `CR-20260806-001` không tồn tại. `_CR_INDEX.md` có liệt kê CR này (Dashboard Sidebar — Logout Action) nhưng folder `References/CR/2026-08-06_dashboard-logout-action/` không có trên đĩa. Link trong UC_4.1.1-4.1.5_v1.md (§UC_4.1.2 row 6 và BR_4.1.4.4 area) đang trỏ tới file này → link gãy sẵn từ trước.	SRS UC_4.11.2 trỏ về `_CR_INDEX.md` thay vì file `CR_summary.md` không tồn tại. Đề nghị BA tạo folder CR cho `CR-20260806-001` rồi sửa lại link ở cả 2 file.	(BA chưa phản hồi)	⚪ Ghi nhận — lỗi có sẵn trong repo, không do UC này gây ra
A-23	⚪ Design chưa commit vào repo. WBS dòng 99 trỏ `Wireframe Stage 2/Settings/Account Actions - Resign Account/.png` nhưng folder `References/Wireframe/Stage 2/Settings/` không tồn tại*. 3 frame hiện chỉ có trong chat.	SRS cite 2 link Figma trong CSV cột UI/UX (node `7878-119388`, `7878-119281`) vì đó là nguồn khách cung cấp; đề nghị BA commit ảnh để SRS trỏ được đường dẫn thật.	(BA không phản hồi riêng — áp dụng đề xuất)	✅ Applied by default

Ghi chú Phase 2.2 — WBS Cross-UC Consistency Check

Kiểm tra	Kết quả
Mã `UC_4.11.2` có trong WBS?	✅ Có — dòng 99, category SIM, module `Settings`, function `Account Actions - Resign Account`
Trùng lặp phạm vi với UC khác?	✅ Không. Bản LIVE tách riêng tại `UC_4.17.2` (WBS dòng 117). Mã cũ `UC_4.6.4` (common) đã không còn trong WBS.
Ranh giới với `UC_4.11.1` (Reset Associate Track)	✅ Cùng tab `Account Actions`, khác section — xem A-18
Cross-ref tới UC đã publish	✅ UC_4.1.2 (entry point) · UC_4.1.4 (audio teardown) · UC_4.6.1 (shell màn Account) · UC_4.10.1 / UC_4.10.2 / UC_4.10.3 (trạng thái account) · UC_4.9.2 (POD khoá ở SIM — cơ sở của A-14)
Cross-ref tới UC chưa publish	⚠️ `UC_4.6.4` (Controls) · `UC_4.17.1` (Market Data Management) · `UC_4.17.2` (Resign — LIVE) — ghi placeholder. (Cập nhật 2026-08-11: `UC_4.11.1` Reset Associate Track đã publish; mã Controls remap `UC_4.6.5` → `UC_4.6.4` theo WBS.)
CR conflict	✅ Không có CR override. `CR-20260806-001` chồng lấn phần session teardown — xử lý theo A-08.

Ghi chú Phase 2.5 — Impact Analysis (mọi hành động state-changing trong phạm vi UC_4.11.2)

Chỉ có 1 hành động state-changing, nhưng là hành động phá huỷ nặng nhất trong Dashboard.

Hành động	Impact	Reversible?	Trạng thái spec
`[Resign & Close Account]` (Step 2) → `POST /resign`	Execution gateway: account → ReadOnly (Rithmic Paper / MT5 Sim) → huỷ toàn bộ lệnh pending/working → flatten toàn bộ vị thế bằng market order → Flow 7 (f) hard-delete sub-account qua DeleteUser API (dừng phí $25/platform)	❌ Không	✅ CSV Business logic + Flow 7
↑	Database: `users.status='Terminated'`, `termination_reason='VOLUNTARY_RESIGNATION'`, `termination_date=NOW()`, `audit.action='RESIGN'`	❌ Không	✅ CSV Zapier table
↑	Session: kill session hiện tại + logout; tài khoản login vẫn tồn tại để mua evaluation mới	—	✅ A-03 · cơ chế teardown → A-08
↑	Ledger: `POST /financial/reset-ledger` → `deactivate:true`, `virtual_equity=0`	❌ Không	✅ Flow 7 (d)
↑	Community: `POST /discord/revoke-all-roles` — gỡ role, không kick, giữ `discord_user_id`	⚠️ Role phục hồi khi mua evaluation mới	✅ A-13 (confirmed)
↑	Market Data: `Next_Month_Data_Paid == True` (trả trước trong 3 ngày) → `POST /issue-refund type=MARKET_DATA`	—	✅ Flow 7 (c) — áp dụng cho SIM (A-12)
↑	Phí challenge: không hoàn tiền	❌ Không	✅ CSV Definition
↑	Pod exit survey: Flow 7 (j) — không bao giờ trigger ở SIM	—	✅ A-14
↑	Newsquawk audio / WebSocket teardown	—	✅ A-08 (trỏ CR-20260806-001)
↑	Gọi 2 lần (double-click / retry / 2 tab)	—	✅ A-10
↑	Màn hình kế tiếp sau khi resign thành công	—	🔒 BLOCKED — A-04

Ghi chú Phase 2.6 — Pattern Recognition

Pattern	Đề xuất
Modal xác nhận 2 bước có gõ cụm từ ("type-to-confirm") — hiện ở Resign, nhiều khả năng tái sử dụng cho các hành động huỷ diệt khác.	Sau khi A-05/A-06/A-16/A-17 được chốt đủ, đề nghị gom thành 1 rule chung trong common_rules.md (VD `CR-15: Type-to-Confirm Destructive Action`) thay vì lặp ở từng UC. Chưa làm được vì 3/4 input còn đang HOLD.
Copy của 2 modal + màn success	Khi A-04 được chốt, cần thêm ID mới vào list-toast-popup.md (nhóm `OV` cho 2 modal, màn success cho A-04) thay vì viết thẳng text vào SRS — theo `global-rules.md → Common Rule Referencing`.

🔒 Danh sách BLOCKED — phải loại khỏi SRS v1

Theo system_init_workflow.md → "If BA answers partially, proceed only with confirmed items. Flag unconfirmed items as [BLOCKED] and exclude them from docs."

ID	Nội dung bị chặn	Trạng thái
A-05	Cụm từ xác nhận chính xác + quy tắc so khớp (hoa/thường)	✅ Gỡ chặn 2026-08-12 — `Resign`, case-sensitive (`[RES-TRIG-01]`). Còn lại: chip Figma `RESIGN` phải sửa; cấu hình Table C chưa trả lời
A-06	Quy tắc Enabled/Disabled của nút `[Resign & Close Account]`	✅ Gỡ chặn 2026-08-12 — Disabled hoàn toàn tới khi khớp chính xác (`[RES-UI-01]`)
A-04	Màn hình sau khi resign thành công	✅ Gỡ chặn 2026-08-12 — không success screen, không logout; Frosted Glass + modal (`[RES-BIZ-01]`)
A-16.2	Giới hạn ký tự của ô nhập	✅ ĐÓNG 2026-09-03 — 50 ký tự (CR-02 §2.2). Đã viết vào BR_4.11.2.3 và §9.3 dòng 5.
A-16.3	Thời điểm kiểm tra khớp (`onChange` / `onBlur`)	✅ Gỡ chặn 2026-08-12 — `onChange`, suy ra từ `[RES-UI-01]`
A-16.4	Có inline error khi chưa khớp hay không	✅ Gỡ chặn 2026-08-12 — không có inline error

✅ Không còn mục nào bị chặn. A-16.2 đóng 2026-09-03 (50 ký tự).

✅ Hệ quả: pattern "type-to-confirm" giờ đã đủ input để gom thành Common Rule (xem Phase 2.6) — chỉ thiếu max length. Vẫn chưa thêm ID nào vào list-toast-popup.md: copy 2 modal friction đã cố định theo design (A-02), modal sau resign có copy riêng ở §9.4, và không có inline error nào cần ID.

ID	Nội dung	Đề xuất của BA	Trạng thái
A-24	Race giữa modal và Flow 7. Modal hiện ngay sau HTTP 200, trong khi Flow 7 vẫn đang chạy async (xoá sub-account, ledger close, revoke Discord). Nếu user bấm mua ngay, luồng provision mới có thể chạy chồng lên luồng teardown của cùng account.	BE khoá theo `user_id` cho tới khi Flow 7 hoàn tất, hoặc xử lý idempotent theo thứ tự.	✅ ĐÓNG 2026-09-03 — Flow 7 không chạy trên luồng này nên không còn teardown để race. → BR_4.11.2.8.

Mục mở mới — phát sinh từ client clarification 2026-08-21 (hard delete + retention window)

Bối cảnh: khách chốt 2 điểm mới — (1) tài khoản SIM không được dừng ở trạng thái ReadOnly: DeleteUser hard-delete là bắt buộc để cắt phí $25/tháng. Bước ReadOnly/Suspended ở T+0 vẫn giữ (chặn giao dịch tức thời); lệnh xoá do Middleware Hub phát ở Flow 7 bước (f) qua POST /system/set-account-state — Zapier không bao giờ gọi thẳng gateway. (2) Giữ nguyên cửa sổ archive 10 ngày (Discount_Code_Duration_Days) cho tài khoản resign, mở rộng GET /failure-state sang status == 'Terminated', không tạo endpoint mới. Xem BR_4.11.2.5, BR_4.11.2.9, BR_4.11.2.15, BR_4.11.2.17.

📌 Cụm từ xác nhận chốt lại là RESIGN (viết hoa toàn bộ, case-sensitive) — BA xác nhận 2026-08-21. Frame Figma vốn đang vẽ RESIGN nên không cần sửa design; mục A-05 đóng hoàn toàn.

⚠️ Lưu ý về bản mô tả flow nội bộ cũ: một số bản tóm tắt luồng resign vẫn còn bước "Session Termination — huỷ phiên đăng nhập và tự động đăng xuất". Bước đó đã bị khách bãi bỏ từ 2026-08-12 ([RES-BIZ-01]) và BA tái xác nhận 2026-08-21: giữ session, không clear token, đẩy thẳng vào Frosted Glass.

ID	Nội dung	Đề xuất của BA	Trạng thái
A-27	✅ ĐÃ ĐÓNG 2026-08-22 — "market data fees" là chi phí firm trả cho CME qua Rithmic theo chu kỳ tháng, không phải phí trader. Failsafe cuối tháng có thật nhưng chỉ áp cho Rithmic/Futures; Forex (MT5/TE) dùng luật 10 ngày thuần. Câu hỏi gốc: Nửa "disable gateway access" của failsafe cuối tháng có còn ý nghĩa không? Khách nói "at the 10-day mark OR 11:59 PM on the last day of the calendar month, you must disable the gateway access to halt market data fees and archive the dashboard data." Nhưng với resign, sub-account đã bị hard-delete ngay ở T+0 → gateway access đã mất từ đầu, không còn gì để disable ở mốc ngày 10.	Coi failsafe cuối tháng trên nhánh resign chỉ áp dụng cho nửa archive dữ liệu dashboard; nửa gateway là no-op (giữ lại cho parity với nhánh Hard Breach). Cần khách xác nhận trader SIM sau resign không còn entitlement market data nào phát sinh phí.	✅ ĐÓNG 2026-09-03 — "market data fees" là chi phí firm trả cho CME qua Rithmic; failsafe cuối tháng chỉ áp Rithmic/Futures. (Ô nội dung đã ghi đóng từ 2026-08-22, cột trạng thái nay sửa cho khớp.)
A-30	Mua lại trong window có tái dùng sub-account cũ không? Vì Day 0 không còn purge, sub-account vẫn assigned/connected suốt 10 ngày — giống hệt nhánh Hard Breach. Nếu vậy BR_4.10.3.2 ("Reset tái dùng sub-account sẵn có") lại áp dụng được.	Có — tái dùng trong window, chỉ provision mới sau khi window hết hạn. Khớp đúng với việc CTA đi vào luồng Reset (`product_id="RESET"`).	✅ ĐÓNG 2026-09-03 — Case A / Case B ở UC_4.10.2 BR_4.10.2.7 đã trả lời. Việc mua lại thuộc UC_4.10.3, ngoài phạm vi UC này.
A-28	Trader SIM resign có nhận email xác nhận không? Flow 7 bước (i) gửi `Live_Account_Closed` — đây là thư chấm dứt hợp đồng của môi trường LIVE, không phù hợp với một evaluation SIM.	Không gửi email nào cho trader SIM. Modal sau resign (§9.4) là xác nhận duy nhất. Nếu khách muốn có email, cần một template SIM riêng — hiện chưa tồn tại trong source.	✅ ĐÓNG 2026-09-03 — Có gửi email — chính là `Challenge_Failed` của Klaviyo qua Flow 7B Path A, sau cool-down 1 giờ, trừ khi trader đã mua lại trong window. Không phải `Live_Account_Closed`.

Bối cảnh: khách chốt lại kiến trúc — trader SIM khi resign không đi qua Flow 20 / Flow 7 nữa. Middleware Node.js xử lý native: block gateway → flatten → cancel → audit → set status = 'Failed', failure_reason = 'VOLUNTARY_RESIGNATION'. Chính thao tác ghi status này bắn CHALLENGE_FAILED → Flow 2 → Flow 7B Path A, tức là giống hệt Hard Breach. Flow 7 từ nay chỉ phục vụ LIVE-funded capital.

📌 Hệ quả cho tài liệu: UC_4.11.2 chuyển thành delta doc trên UC_4.10.2 — toàn bộ phần sau khi status = 'Failed' (Frosted Glass, retention window, archive_date theo broker, purge, reset pricing, Case A/B provisioning) chỉ refer, không viết lại. Thứ duy nhất khác biệt là modal hiển thị (§9.4) và discriminator state_reason = "RESIGNATION".

✅ Đóng nhờ thay đổi này: A-28 (có email — chính là Challenge_Failed của Klaviyo qua Flow 7B Path A), A-30 (Case A/B trong BR_4.10.2.7 đã trả lời), A-24 (không còn Flow 7 teardown để race).

ID	Nội dung	Đề xuất của BA	Trạng thái
A-31	Revoke Discord role mất chỗ thực thi. Trước đây do Flow 7 bước (g) (`POST /discord/revoke-all-roles`) đảm nhiệm. Flow 7 không còn chạy trong SIM, và nhánh Hard Breach mà UC này kế thừa không hề revoke Discord. Hiện tại không component nào gọi revoke khi trader SIM resign.	Không revoke — đồng bộ với Hard Breach. Đuổi trader khỏi community ngay lúc Flow 7B bắt đầu retarget là phản tác dụng với mục tiêu "Frictionless Conversion Optimization". `[DL-BIZ-04]` giữ nguyên hiệu lực cho LIVE (`UC_4.17.2`).	✅ ĐÓNG 2026-09-03 — ⚠️ Ngược đề xuất cũ. Discord role CÓ bị thu hồi: Flow 20 gọi thẳng `POST /discord/revoke-all-roles`. Gỡ hết role, giữ `discord_user_id`, giữ membership server, mua lại thì gán lại qua `/manage-discord-role`. → BR_4.11.2.9.
A-32	Resign khi account đã `Failed` do Hard Breach. BR_4.11.2.7 vẫn cho phép, nhưng giờ cả 2 trạng thái đều ghi `'Failed'` → chưa rõ có ghi đè `failure_reason` từ `Drawdown` sang `VOLUNTARY_RESIGNATION` không, và có bắn lại `CHALLENGE_FAILED` (⇒ Flow 7B chạy lần 2, email `Challenge_Failed` trùng) không.	Coi như no-op — trả HTTP 409, không ghi gì, giữ nguyên modal Hard Breach. Account đã flat, đã read-only, đã được retarget.	✅ ĐÓNG 2026-09-03 — HTTP 409 Conflict khi `status = 'Failed'` — không ghi DB, không webhook. → BR_4.11.2.5.
A-33	Mất lưới an toàn flatten ngoài giờ thị trường. Flow 7 bước (b) trước đây chạy lại liquidation khi thị trường mở. Không có gì thay thế. Hard Breach không cần (nó fire trên market data trực tiếp ⇒ thị trường đang mở), nhưng resign có thể submit bất kỳ lúc nào.	Middleware queue lại lệnh flatten cho tick market-open kế tiếp, clear khi `Open_Positions == 0`. Cần architecture confirm.	✅ ĐÓNG 2026-09-03 — Redis retry queue do `POST /resign` sở hữu: phát lại flatten ở phiên mở cửa kế tiếp, chỉ hoàn tất khi verify `Open_Positions == 0`. → BR_4.11.2.11.
A-34	Ledger deactivation. Flow 7 bước (d) gọi `POST /financial/reset-ledger` `deactivate: true` → `virtual_equity = 0`. Nhánh Hard Breach không làm việc này.	Không cần — dashboard frost render snapshot tại `failure_timestamp`; zero hoá ledger sẽ phá đúng dữ liệu mà window 10 ngày sinh ra để bảo tồn.	✅ ĐÓNG 2026-09-03 — Không deactivate. `virtual_equity` đóng băng tại snapshot resign suốt window — đây là dữ liệu Frosted Glass render. → BR_4.11.2.10.
A-35	Nhánh `'Terminated'` của `GET /failure-state`. Khách chốt 2026-08-21 là `Failed OR Terminated`; từ v1.5 không luồng SIM nào sinh ra `'Terminated'` nữa.	Giữ lại — vô hại, và LIVE termination (Flow 7, `UC_4.17.2`) vẫn cần.	✅ ĐÓNG 2026-09-03 — Giữ một endpoint dùng chung, không tạo endpoint mới. Luồng này dùng nhánh `status = 'Failed'`. → BR_4.11.2.12.
A-36	Label CTA lệch nhau. Screenshot 2026-08-25 ghi [Start Associate Track]; Hard Breach Popup cho cùng đích đến ghi [Reset Associate Track] (UC_4.10.3 §10.1).	Giữ theo screenshot. Nếu khách muốn thống nhất một chuỗi thì "Start Associate Track" hợp lý hơn với trader resign — họ không "fail" và cũng không "reset" gì cả.	✅ ĐÓNG 2026-09-03 — Giữ [Start Associate Track] — hai modal là hai trạng thái khác nhau, nhãn lệch là cố ý. → §9.4.
A-37	⚠️ Xung đột cụm từ xác nhận — CHƯA áp dụng. Bản supplement 2026-08-25 ghi trader gõ `Resign` (Proper Case); tài liệu và Figma chip đều là `RESIGN` (viết hoa toàn bộ), đã chốt 2026-08-21 (`[RES-TRIG-01]` + BA). Không sửa vì user đã lưu ý bản supplement do máy sinh và giới hạn phạm vi update ở phần routing `Failed`.	Giữ `RESIGN` — khớp design asset và câu trả lời trực tiếp trước đó của khách. Cần khách xác nhận chuỗi nào là chuẩn.	✅ ĐÓNG 2026-09-03 — Cụm từ là `RESIGN` (viết hoa toàn bộ), hardcode cả FE lẫn BE. → BR_4.11.2.3.
A-38	Tên endpoint không đồng nhất. UC này và supplement 2026-08-25 dùng `GET /failure-state`; UC_4.10.2 §4 dùng `GET /get-failure-state`. Cùng một endpoint, hai cách viết.	`GET /failure-state` — đúng chuỗi khách dùng trong payload mẫu 2026-08-25. Ưu tiên thấp nhưng phải thống nhất trước khi implement.	✅ ĐÓNG 2026-09-03 — Dùng `GET /get-failure-state` cho đồng bộ với UC_4.10.2. Đã rename 9 chỗ trong UC. → BR_4.11.2.12.

Mục phát sinh 2026-08-28 → 2026-09-03 — tất cả đã đóng

ID	Nội dung	Kết luận
A-39	"SIM trader là Level 0" sai sự thật. `Current_Level` được set thành 1, 2 hoặc 5 lúc provisioning từ `product_id` đã mua (`Eval_1` / `Eval_2` / `Eval_5`) — Nguồn: `Zapier Integration V7.pdf` §Flow 1 Step 4. Mọi rule gate theo `Current_Level == 0` đều hỏng.	✅ ĐÓNG 2026-09-03 — khách xác nhận `Current_Level` = 1/2/5. Khoá phân nhánh dùng `Is_Professional`, không dùng level. → BR_4.11.2.4
A-41	`Active_SIM` không xuất hiện trong source. `Zapier Integration V7.pdf` dùng `Active_Challenge` ở cả 2 chỗ nó gọi tên trạng thái đang chạy (§Flow 1 re-entry guard, §Flow 2 validation gate). Rủi ro: nếu BE code `Active_SIM` mà Flow 2 lọc `Active_Challenge` thì Flow 2 HALT ở mọi trade và không Hard Breach nào được phát hiện.	✅ ĐÓNG 2026-09-03 — khách xác nhận `Active_SIM` là đúng. → §3, BR_4.11.2.6
A-43	Cụm "logs the user out" trong source. Xuất hiện lại nhiều lần, ngược `[RES-BIZ-01]` (2026-08-12) và `[RES-BIZ-03]` (2026-08-24). Nếu logout thật thì modal §9.4 và Frosted Glass không render được vì cả hai cần session đã xác thực.	✅ ĐÓNG 2026-09-03 — không logout khỏi dashboard. Session giữ nguyên. → BR_4.11.2.7

Ngoài phạm vi UC_4.11.2 — chuyển sang backlog khác

Các mục dưới đây từng được ghi nhận trong vòng init nhưng không thuộc UC này. Giữ lại để không thất lạc; người phụ trách UC đích cần raise lại trong backlog của họ.

ID	Nội dung	Thuộc về
A-19	Nút `Reset Associate Track` hiển thị enabled khi account đang chạy bình thường	UC_4.11.1
A-20	`RES-DEF-01` / `RES-DEF-02` — resign rồi mua lại cùng email: check trùng email, account mới có giữ certificate / journal / stats / community role không	Luồng checkout / mua lại (UC_4.10.3 + Stage 1)
A-21	`RES-FRM-01` / `RES-FRM-02` — công thức `Amount_Over_Stop_Loss`, severance âm	LIVE (Flow 9)
A-25	Trader LIVE resign mua lại ở giá nào — có mất `Retry_Discount` / Flow 7B Path B không	LIVE
A-26	Modal LIVE có gắn dòng severance / exit interview không, từ level nào	LIVE

Changelog

Ngày	Nội dung
2026-09-03	Đồng bộ toàn bộ với UC_4.11.2 v3.3 — không còn câu hỏi mở. (1) Đóng 13 mục: A-05 (phần còn lại: hardcode, không giới hạn số lần gõ sai), A-16.2 (50 ký tự), A-24 (Flow 7 không chạy nên không còn race), A-27 (sửa cột trạng thái cho khớp ô nội dung vốn đã đóng từ 2026-08-22), A-28 (có email `Challenge_Failed` qua Flow 7B), A-30 (Case A/B ở BR_4.10.2.7; mua lại thuộc UC_4.10.3), A-32 (HTTP 409), A-33 (Redis retry queue), A-34 (không deactivate ledger), A-35 (giữ một endpoint dùng chung), A-36 (giữ nhãn `[Start Associate Track]`), A-37 (`RESIGN` viết hoa), A-38 (`GET /get-failure-state`). (2) ⚠️ A-31 đóng NGƯỢC đề xuất cũ: file trước ghi "không component nào revoke Discord"; thực tế Flow 20 gọi thẳng `POST /discord/revoke-all-roles`. (3) Thêm 3 mục mới, tất cả đã đóng: A-39 (`Current_Level` = 1/2/5), A-41 (`Active_SIM` là đúng), A-43 (không logout khỏi dashboard). *(4) Chuyển 5 mục sang mục Ngoài phạm vi UC_4.11.2:* A-19 (UC_4.11.1), A-20 (luồng checkout), A-21 / A-25 / A-26 (LIVE) — cần người phụ trách UC đích raise lại.
2026-08-25	Client architectural refinement — SIM resign = `Failed`, không phải `Terminated`. Middleware Node.js xử lý native `POST /resign` (block gateway → flatten → cancel → audit → `status='Failed'`, `failure_reason='VOLUNTARY_RESIGNATION'`); Flow 20 + Flow 7 bị bypass hoàn toàn (LIVE-only), thay bằng `CHALLENGE_FAILED` → Flow 2 → Flow 7B Path A giống hệt Hard Breach. Trader nhận email `Challenge_Failed` của Klaviyo ⇒ A-28 đóng. Case A/B provisioning của BR_4.10.2.7 trả lời A-30 ⇒ đóng. Không còn Flow 7 teardown ⇒ A-24 đóng. §9.4 respec theo screenshot khách: CTA [Start Associate Track]. Mở 8 mục mới A-31 → A-38 (Discord mất executor, resign khi đã Failed, mất safety-net flatten, ledger close, nhánh `Terminated`, lệch label CTA, xung đột cụm từ `RESIGN`/`Resign`, tên endpoint). UC_4.11.2 lên v1.5 và chuyển thành delta doc trên UC_4.10.2.
2026-08-11	Tạo mới — Init Flow vòng 1 (Agent 1 Auditor + Agent 2 Challenger), 23 mục.
2026-08-12	Client answers + BA chốt design modal. Khách trả lời `[RES-TRIG-01]` (cụm từ case-sensitive), `[RES-UI-01]` (nút Step 2 Disabled hoàn toàn, không error state), `[RES-BIZ-01]` (không success screen, không logout, refresh state → Frosted Glass → modal). → A-04, A-05 (một phần), A-06, A-16.3, A-16.4 đóng; A-16.2 còn mở. BA chốt copy + hành vi 2 modal sau resign (SIM/LIVE, không nút Cancel, không banner archive) → viết vào SRS §9.4, BR_4.11.2.15, BR_4.11.2.16. Mở 3 mục mới: A-24, A-25, A-26.
2026-08-21	Client clarification 2026-08-21. (1) Hard delete là bắt buộc với SIM — tài khoản không được dừng ở ReadOnly; `DeleteUser` (Flow 7 bước (f), do Middleware Hub phát) cắt phí $25/tháng, dashboard login vẫn active. Bước ReadOnly/Suspended ở T+0 giữ nguyên. Cụm từ xác nhận chốt là `RESIGN` (viết hoa) → A-05 đóng hoàn toàn, không cần sửa Figma. (2) Giữ cửa sổ archive 10 ngày (`Discount_Code_Duration_Days`) cho tài khoản resign; `GET /failure-state` đánh giá `IF status == 'Failed' OR status == 'Terminated'` và trả cùng một payload archive date; không tạo endpoint mới. (3) BA scope lại Flow 7 cho SIM: bước (c) Refund Check, (e) Balance Check, (i) email `Live_Account_Closed`, (j) Feedback Survey → N/A; bước (g) chỉ revoke Title Roles. (4) Nhập rule render Frosted Glass từ UC_4.10.2 — snapshot tĩnh tại `termination_date`, PnL Gauge đóng băng, chuông thông báo + Days Remaining vẫn chạy. (5) §9.4 thêm Archive Countdown Banner, CTA đổi thành [Reset Associate Track]. → SRS lên v1.3. Mở 2 mục mới: A-27, A-28.
2026-08-22	Khách gửi flow resign SIM đầy đủ. (1) Day 0 KHÔNG purge — gateway account để nguyên assigned/connected ở trạng thái disabled để trader còn login terminal xem lịch sử; Flow 7 (f) chỉ lock + schedule. (2) Trạng thái cụ thể từng gateway: Rithmic `INACTIVE` · MT5 `READONLY` · TE `TRADING IS DISABLED BY RISK RULE`. Thứ tự sửa thành flatten → cancel. (3) Tách purge theo asset class: Forex (MT5/TE) chỉ dùng luật 10 ngày, phải verify sync PostgreSQL + AWS S3 Glacier trước khi xoá; Futures (Rithmic) chạy ở `min(10 ngày, 23:00 UTC ngày cuối tháng)`, disable User ID + revoke market-data entitlement qua Broker API. (4) Bỏ GL Posting — SIM chạy `virtual_equity`, không phát sinh dòng tiền thật nên không có cơ sở ghi sổ QuickBooks; sequence SIM còn (a)→(b)→(d)→(f)→(g). (5) Discord strip role `Associate Trader` + quyền private community channel, kèm failsafe `discord_user_id IS NULL` → drop, trả 200 OK. → SRS lên v1.4. A-27 đóng, mở A-30. Cụm từ `RESIGN` và CTA `[Reset Associate Track]` giữ nguyên (BA chốt lại 2026-08-22).
2026-08-11	Cập nhật sau BA review. A-01 đóng (WBS đã có mã, LIVE tách sang `UC_4.17.2`). A-03/A-12/A-15 đóng — requirement đã có sẵn trong cột `SIM environment` của CSV, Agent đã quy nhầm thành gap. A-02/A-07/A-09/A-10/A-14 BA chốt. A-08/A-11/A-18/A-23 applied by default. A-04/A-05/A-06 BA HOLD → chuyển sang `🔒 BLOCKED`. A-16/A-17 chờ BA sau khi Agent giải thích chi tiết.

QnA Init Docs — UC_4.11.2: Settings — Account Actions: Resign Account (SIM)