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

Document References

Design asset note. No LIVE design frame exists for this screen. The three SIM frames — Account Actions tab, Step 1 modal (Resign & Close Account), Step 2 modal (Confirm Resignation) — are the working source for the shell and the two friction modals, and the client-supplied Resignation Complete screenshot of 2026-08-25 is the source for §9.4. None of them is committed to References/Wireframe/ — Ref: UC_4.11.2 §Document References, §10 A-50.

⚠️ How to read this document — it is a delta on UC_4.15.2

A LIVE resignation and a LIVE Hard Breach converge on the same end state — users.status = 'Terminated' — and from that write onward they run the same pipeline: Flow 20 hands to Flow 7, Flow 7B Path B fires off the state change, the Dashboard frosts over, the 10-day archive window runs, and the re-entry purchase is the Scenario B Re-Buy. Only the trigger, four Flow 7 branch conditions and a handful of surface elements differ.

Where the behaviour is shared it is referenced, never restated. If a shared rule changes, it changes in UC_4.15.2 and this document inherits it.

Component split — shared vs unique

🔗 Referenced from UC_4.15.2 — reused verbatim, NOT respecified here. These are one codebase; a change lands there and this UC inherits it.

🔨 Unique to LIVE resignation — custom build, specified in full here.

Environment scope: LIVE only. The SIM counterpart is UC_4.11.2, whose end state and automation are different on the one point that matters: since CR-65 a SIM resignation writes status = 'Failed' and routes through Flow 2 → Flow 7B Path A, bypassing Flow 20 / Flow 7 / Flow 9 entirely. Flow 20 → Flow 7 (and Flow 9) survive intact — they are now LIVE-only, and this document owns their entry point. Ref: BR_4.17.2.19.

1. Overview

Design: ⏳ No LIVE Figma node assigned. The WBS carries no design link for UC_4.17.2. The SIM frames (Figma — Resign, node 7878-119388 · node 7878-119281) govern the shell and both friction modals; the Resignation Complete modal follows the client-supplied screenshot of 2026-08-25. Ref: §10, A-50.

2. Trigger

The trader clicks [Resign Account] in the Resign & Close Account row of the LIVE Account Actions tab (Ref: §9.1), while that button is Enabled — i.e. while users.status = 'Active_DMA' (Ref: BR_4.17.2.7).

Navigation path to that row:

1. The trader clicks the user chip in the sidebar footer and selects Settings from the dropdown. Ref: UC_4.1.2 §2 Screen Description, row 6.
2. The Account screen opens on its default active tab Connections & Credentials. Ref: BR_4.6.1.1.
3. The trader selects the Account Actions tab, which renders the Reset Associate Track section (UC_4.17.3) above the Resign & Close Account section (this UC).

This is the only path to the section — there is no deep link and no shortcut from the Dashboard. Ref: BR_4.17.2.1.

The two sections on this tab are mutually exclusive by construction. While the trader is trading, Resign & Close Account is Enabled and Reset Associate Track is Disabled. The moment this use case completes, the two swap — Ref: BR_4.17.2.7, BR_4.17.2.16, UC_4.17.3 BR_4.17.3.3.

3. Pre-conditions

• The trader is authenticated and inside the Dashboard shell. Ref: UC_4.1.1 §1 Overview.
• The trader holds a LIVE funded account that is still running — users.status = 'Active_DMA'. A Soft Breach daily-loss lockout still counts as running: it is a trading lock, not an account state (Ref: UC_4.15.1). An account already in status IN ('Failed', 'Terminated') cannot be resigned — Ref: BR_4.17.2.6, BR_4.17.2.7.
• Is_Professional == True — otherwise the request takes the SIM branch, owned by UC_4.11.2. This flag is the SIM/LIVE discriminator throughout the system; Current_Level must not be used, because a SIM account is provisioned at Current_Level 1, 2 or 5 and would collide with the LIVE range. Ref: BR_4.17.2.5, UC_4.11.2 §10 A-39 (BE-1).
• A LIVE trading sub-account exists on the execution gateway (Rithmic Live FCM, MT5 Live or TraderEvolution Live).

4. Post-conditions

Unique to resignation (specified here):

• The Day 0 gateway contract has run: order routing blocked (read-only), all open positions flattened, all working orders cancelled, and the LIVE sub-account left assigned and locked — no purge on Day 0. Ref: BR_4.17.2.5 steps 2–4, BR_4.15.2.7.
• users.status = 'Terminated', users.termination_reason = 'VOLUNTARY_RESIGNATION', users.termination_date = NOW(), and an audit record with action = 'RESIGN' is written — Ref: BR_4.17.2.14.
• The Drawdown Defense Protocol never runs, whatever the trader's level and whatever Defense_Used holds. Flow 4B is not reached — Ref: BR_4.17.2.10.
• If Severance_Pay > 0 for the trader's Current_Level, Flow 9 pays the full base amount with no deduction, because Amount_Over_Stop_Loss is $0 on this path — Ref: BR_4.17.2.13.
• Every Discord role is revoked and the trader's pod is dispersed — Ref: BR_4.17.2.11.
• GET /failure-state returns is_breached: true, state_reason: "RESIGNATION" and the same archive_date payload as a breach; the frontend uses state_reason to render the resignation modal (§9.4) instead of the Hard Breach Failure Modal — Ref: BR_4.17.2.15.
• The dashboard session is not terminated: access tokens are retained and the trader stays logged in — Ref: BR_4.17.2.8.
• The Reset Associate Track control above this section becomes Enabled, because its predicate users.status = 'Terminated' is now satisfied — Ref: BR_4.17.2.16, UC_4.17.3 BR_4.17.3.3.
• The challenge purchase fee is not refunded. A next-month market-data prepay may be refunded; the current month is never prorated — Ref: BR_4.17.2.12.

Shared with the Hard Breach path — owned by UC_4.15.2 §4 Post-conditions, not restated here:

Explicitly NOT post-conditions:

• The trader is not logged out. The RFQ's "logs them out of the dashboard and disables access" is superseded by [RES-BIZ-01] — Ref: BR_4.17.2.8.
• The LIVE sub-account is not deleted at T+0. It is locked Read-Only and purged only at archive_date or on a Re-Buy — Ref: BR_4.15.2.7. ⚠️ UC_4.15.2 §1 still carries a stale "hard-deleted immediately" sentence — Ref: §10 A-53.
• The Dashboard does not reset to D=0 at resignation. It freezes at the resignation snapshot and resets only when archive_date passes or a Re-Buy completes (Source: QnA FR-54, FR-31).

5. Basic Flow

1. The trader opens the Account Actions tab. The Resign & Close Account row renders with [Resign Account] Enabled — Ref: §9.1, BR_4.17.2.7.

2. The trader clicks [Resign Account]. The Step 1 warning modal opens — Ref: §9.2, BR_4.17.2.2.

3. The trader clicks [Continue to Resign]. The Step 1 modal closes and the Step 2 confirmation modal opens with an empty phrase input — Ref: §9.3, BR_4.17.2.3.

4. The trader types the confirmation phrase RESIGN into the input. The value is compared case-sensitively on every keystroke; the [Resign & Close Account] button stays Disabled until the value matches exactly. Paste is permitted and leading/trailing whitespace is trimmed before comparison — Ref: BR_4.17.2.4.

5. The trader clicks [Resign & Close Account]. The button is disabled immediately on click and enters a loading state — Ref: BR_4.17.2.6. The frontend calls POST /resign with {user_id, confirmation_phrase}.

6. The Middleware Hub executes the LIVE resignation sequence synchronously — Ref: BR_4.17.2.5:

   1. Validates confirmation_phrase.
   2. Reads Is_Professional from the decoded JWT claims → True → LIVE branch.
   3. Blocks order routing at the execution gateway (read-only / freeze), 4. flattens all open positions, 5. cancels all working orders. If the market is closed the flatten is queued for retry rather than blocking the response — Ref: BR_4.17.2.18.
   4. Inserts an audit record with action = 'RESIGN'.
   5. Emits the RESIGNATION_EXECUTED webhook to Zapier Flow 20. The dashboard session itself is not torn down — Ref: BR_4.17.2.8.

7. The backend returns HTTP 200 OK. The frontend then, without showing any success screen — Ref: BR_4.17.2.15:

   1. Closes the Step 2 modal and leaves the session untouched (no token clearing, no logout, no redirect to login).
   2. Re-fetches the account state (GET /failure-state), which now returns is_breached: true, state_reason: "RESIGNATION" and archive_date.
   3. Redirects the trader from the Account / Settings screen back to the main Command Center / Dashboard, because the Frosted Glass state renders on the Dashboard only — Ref: BR_4.15.2.2.
   4. The Dashboard renders in Frosted Glass — freezing the background metrics at the millisecond of resignation — and the non-dismissible Resignation Complete modal opens over it — Ref: §9.4.

   ⏳ A race exists between step 7.2 and Flow 7. status = 'Terminated' is written by Flow 7, not by POST /resign, so GET /failure-state may still read Active_DMA when the frontend calls it milliseconds after the HTTP 200. Ref: BR_4.17.2.15, §10 A-54.

8. Asynchronously — Flow 20 → Flow 7, specified once at UC_4.15.2 §5 and deliberately not restated here. Flow 20's only action is to trigger Flow 7 with Reason Code = VOLUNTARY_RESIGNATION (Source: Zapier Integration V7.pdf §Flow 20). Flow 7 then runs its full pipeline — Defense Gate (skipped, Ref: BR_4.17.2.10) → Refund Check → Ledger Close → Liquidation second pass → Balance Check → Retention Gate → Flow 9 (Ref: BR_4.17.2.13) → Post-Termination Access Control → Digital Eviction → Pod Impact & Dispersal (Ref: BR_4.17.2.11) → GL Posting → Feedback Survey Gate → Notification (Live_Account_Closed). The four branch conditions that differ from the Hard Breach path are listed at BR_4.17.2.9. None of it blocks the HTTP 200 returned in step 7.

9. In parallel — Flow 7B Path B. The status = 'Terminated' write fires the separate Flow 7B listener, which runs a 1-hour cool-down → purchase check → pricing route → Klaviyo Retention_Offer_Discount. Client-confirmed for the resignation path by [RES-ZAPF-01] — Ref: BR_4.17.2.9, BR_4.17.2.16.

[POST /resign — Node.js middleware, synchronous]
   ├─ validate phrase → Is_Professional == True → LIVE branch
   ├─ gateway read-only → flatten → cancel → audit action = 'RESIGN'
   └─ emit RESIGNATION_EXECUTED
                    │
                    ├──▶ 200 OK ──▶ GET /failure-state ──▶ redirect to Dashboard
                    │                                   ──▶ Frosted Glass + §9.4 modal
                    │
                    └──▶ [Flow 20] ──▶ [Flow 7, Reason = VOLUNTARY_RESIGNATION]
                                          ├─ Defense Gate ......... SKIPPED (BR_4.17.2.10)
                                          ├─ Refund Check ......... next-month data prepay only
                                          ├─ Ledger Close / Liquidation / Balance Check
                                          ├─ Retention Gate ──▶ [Flow 9] full Severance_Pay
                                          ├─ Access Control ....... status = 'Terminated'
                                          ├─ Digital Eviction ..... revoke ALL Discord roles
                                          ├─ Pod Impact ──▶ [Flow 15A] if Pod Leader
                                          ├─ GL Posting ........... QuickBooks
                                          ├─ Survey Gate .......... if pod_leader_id NOT NULL
                                          └─ Notification ......... Live_Account_Closed (SES-20)
                                                    │
                    status = 'Terminated' ──────────┴──▶ [Flow 7B Path B] retention offer

6. Alternative Flows

6.1 The trader cancels at either step

• Clicking [Cancel] on the Step 1 modal closes the modal and returns the trader to the Account Actions tab. No request is sent.
• Clicking [Cancel] on the Step 2 modal closes the entire flow and returns the trader to the Account Actions tab — it does not return to Step 1. Anything typed into the phrase input is discarded. Re-entering the flow starts again from step 2 of the Basic Flow with an empty input — Ref: BR_4.17.2.3.

6.2 Level 9+ trader with Defense still available

1. The trader is at Current_Level >= 9 with Defense_Used == False — i.e. they would be eligible for the 48-hour Drawdown Defense cooling-off if they had breached (UC_4.15.4).
2. The flow is the full §5 Basic Flow, unchanged. Nothing about Defense is surfaced in the UI, and no Defense-related copy is added to either friction modal.
3. Flow 7 Step 1 evaluates Resignation == True before the eligibility check and short-circuits straight to Liquidation. Defense_Used is not consumed and Flow 4B is never triggered — Ref: BR_4.17.2.10.

6.3 Trader eligible for severance (Severance_Pay > 0)

1. The flow is the full §5 Basic Flow, unchanged. No severance amount is quoted anywhere in this use case's screens — the friction modals and the Resignation Complete modal make no financial promise.
2. Flow 7 Step 6 (Retention Gate) looks up Severance_Pay from Table A/B by Current_Level, finds it > 0, and executes Flow 9.
3. Because the reason code is VOLUNTARY_RESIGNATION, Amount_Over_Stop_Loss is $0 and the trader is authorised for 100 % of the base Severance_Pay — Ref: BR_4.17.2.13.
4. Payout is not automatic: it waits on a Marketing user clicking Authorize inside the Zapier Interface after the exit interview. Owned by UC_7.5 / BR_4.15.2.5.
5. ⏳ Whether the Resignation Complete modal appends a severance / exit-interview line is not decided — Ref: §10, A-26 (inherited).

6.4 Trader is a Pod Leader or a Pod Mentee

1. The flow is the full §5 Basic Flow, unchanged. The pod consequence is entirely back-end and is not surfaced in the friction modals.
2. Flow 7's Pod Impact & Dispersal step branches on the trader's pod role — decrementing the mentor's Current_Count and clearing pod_leader_id for a mentee, or terminating the registry row and firing POD_LEADER_TERMINATED → Flow 15A for a leader. Ref: BR_4.17.2.11, CR-20260818-001.
3. Flow 7's Feedback Survey Gate reads pod_leader_id. Because a LIVE trader can hold one, the Typeform exit survey link is appended to the Live_Account_Closed email and last_survey_date is updated — the one Flow 7 step that is dead in SIM and live here. Ref: BR_4.17.2.9.
4. ⏳ Ordering is unresolved: whether mentee re-assignment completes before the leader's account is terminated, and what happens when no receiving leader exists. Ref: §10, A-55 ([RES-DEF-03], still unanswered by the client).

6.5 Founding Mentor (Role_Flag = 'Founding Mentor')

1. The flow is the full §5 Basic Flow for everything up to Flow 7.
2. ⏳ Open. On the Hard Breach path a Founding Mentor is explicitly exempted from Digital Eviction — "Discord roles are NOT revoked, Pod assignments remain intact" (UC_4.15.2 §6). Whether that exemption also covers a voluntary resignation is not stated by any source: a breach is an involuntary risk event, whereas a resignation is the trader choosing to leave the firm, which is exactly the case Digital Eviction exists for. This document does not pick a side — Ref: §10, A-56.
3. The Founding Mentor Dashboard overlay is a Hard Breach mechanism keyed to a breach event. It is not rendered on the resignation path — the resignation modal of §9.4 is selected by state_reason == "RESIGNATION" regardless of Role_Flag — Ref: BR_4.17.2.15.

7. Exceptional Flow

• [If POST /resign fails with a network error, timeout or HTTP 5xx]

  • The Step 2 modal stays open and the trader remains on it.
  • The system displays Ref: TE-SYS-01.
  • The [Resign & Close Account] button is re-Enabled so the trader can retry manually. The system does not auto-retry — Ref: BR_4.17.2.6.

• [If the session / access token has expired — HTTP 401]

  • The system displays Ref: TE-AUTH-01 and redirects to the Auth0 login.

• [If POST /resign returns HTTP 409 — the account is already closed]

  • One condition covers every case: status IN ('Failed', 'Terminated') — Ref: BR_4.17.2.6. It fires on a double submission, a retry after an unnoticed success, a second browser tab, and on an attempt to resign an account already closed by a Hard Breach, a Stagnation timeout or an Ops termination.
  • No DB write and no webhook occur, so RESIGNATION_EXECUTED does not fire again, Flow 7 does not run twice, and no duplicate Live_Account_Closed email or second severance authorisation is created.
  • The Step 2 modal closes and Ref: TE-DASH-01 is displayed. The frontend then runs the standard state refresh — the trader lands on the Frosted Glass Dashboard, and state_reason decides which modal renders: the Resignation Complete modal (§9.4) if they had genuinely resigned, or the Hard Breach Failure Modal (UC_4.15.3 §10.1–§10.4) if the account had closed for another reason. The session is not touched.
  • In practice this path is close to unreachable from the UI, because BR_4.17.2.7 renders the [Resign Account] button Disabled in exactly these states. It remains specified as the backend authority.

• [If the market is closed or halted when the flatten step executes]

  • The resignation is not blocked and POST /resign still returns HTTP 200. The account is switched to read-only immediately, so no new exposure can be opened.
  • Convergence on Open_Positions == 0 is reached asynchronously — Ref: BR_4.17.2.18.

• [If a downstream Zapier step fails — Flow 20 does not fire, or Flow 7 halts mid-pipeline]

  • POST /resign has already returned HTTP 200 and the gateway is already flat and locked, so the trader's market exposure is closed regardless. No capital is at risk.
  • ⏳ But the account can be left in a stuck intermediate state: order routing dead, yet users.status still 'Active_DMA', so GET /failure-state returns is_breached: false, the Dashboard renders unfrosted over a dead feed, Reset Associate Track stays Disabled and the trader has no path forward. No source specifies a reconciliation or alerting mechanism — Ref: §10, A-54.

• [If the trader reaches the Dashboard before Flow 7 has written Terminated]

  • GET /failure-state returns is_breached: false and the Dashboard renders normally over a dead execution feed. The trader can see the state but can place no order.
  • ⏳ Not specified by any source. See A-54 for the two candidate fixes (frontend polls / re-fetches on the WebSocket state-change event, or POST /resign writes an interim state itself).

8. Business Rules

BR_4.17.2.1: Scope of This Use Case Within the Account Screen

The Account screen hosts a tab list and a persistent Controls panel; the Account Actions tab itself contains two independent sections. This use case owns only the Resign & Close Account section, its two friction modals and the post-resignation modal, on the LIVE side. Everything else is owned elsewhere:

This UC makes no statement about the display or enablement of the Reset Associate Track section beyond recording that its predicate becomes true — Ref: BR_4.17.2.16.

BR_4.17.2.2: Two-Step Friction Confirmation Is Mandatory

Resignation MUST be gated behind two sequential modals; a single confirmation is not sufficient (Source: RFQ_ Website and Dashboard Implementation V7.pdf §Part C — "which should have friction behind it"):

• Step 1 — Warning: states that the action is immediate and irrevocable and lists its consequences. No input is collected. Ref: §9.2.
• Step 2 — Confirmation: requires the trader to manually type a confirmation phrase before the final action becomes available. Ref: §9.3.

The two steps are separate modals that replace one another, not a single modal with swapped content. POST /resign is called only from Step 2.

The friction mechanism is identical to SIM (BR_4.11.2.1) and the client confirmed "Giống SIM" for the LIVE Trigger row (Source: QnA Stage 2 - Dashboard & Fomula (Settings).csv, category Settings: Resign Account, row Trigger). It is specified here in full rather than referenced, because this document owns the LIVE modals and their copy — Ref: §9.2–§9.3.

BR_4.17.2.3: Modal Dismissal — [Cancel] Is the Only Exit

Both friction modals apply the same dismissal rules:

• Neither modal renders a close [X] control.
• Clicking the overlay area outside the modal does not dismiss it.
• The Esc key does not dismiss it.
• Consequently, [Cancel] is the only way to leave either modal without resigning.
• [Cancel] on Step 2 exits the whole flow back to the Account Actions tab; there is no path back to Step 1.
• The Step 2 phrase input is always empty when the modal opens. A value typed in a previous, cancelled attempt is never restored.

BR_4.17.2.4: Confirmation Phrase Matching — Case-Sensitive, Exact

• The expected phrase is RESIGN, in full upper case. Matching is case-sensitive: Resign, resign and any other casing variant do not satisfy the condition (Source: QnA from clients — STAGE 2 Settings, [RES-TRIG-01], Adrian Stack 2026-08-12 — "Yes. Must be typed exactly in the proper case."; phrase confirmed as RESIGN by BA 2026-08-21, Ref: BR_4.11.2.3).
• The comparison runs on every keystroke (onChange), so the CTA flips to Enabled at the exact moment the value matches.
• A mismatch surfaces no inline error message. The Disabled CTA is the only feedback (Source: same QnA, [RES-UI-01] — "Do not leave it enabled just to display error states.").
• No lockout, no retry limit, no error overlay. There is no threshold on how many times the trader may type a wrong value and no penalty for doing so. The trader can also leave the modal and start over any number of times.
• The input accepts pasted content; clipboard input is not blocked.
• Leading and trailing whitespace is trimmed before the value is compared, per CR-02 §2.1. Whitespace inside the value is not altered.
• The string is hard-coded, not configurable. The frontend validator hard-codes RESIGN and the backend validates against the same literal. It is not read from Global Variables / Table C — an Ops edit that desynchronised the two layers would leave the CTA permanently disabled and make resignation unreachable. Ref: UC_4.11.2 §10 A-37.
• The phrase does not vary by environment. SIM and LIVE both require RESIGN; no source proposes a stronger LIVE phrase, and introducing one would fork a validator that the backend shares across both branches.
• ⏳ Still open: the input's maximum length (BA proposal: 50 characters per CR-02 §2.2) — Ref: §10, A-16.2 (inherited).

BR_4.17.2.5: POST /resign Execution Sequence — LIVE Branch

POST /resign
Content-Type: application/json
Authorization: Bearer <JWT_Token>

{ "user_id": "UUID", "confirmation_phrase": "RESIGN" }

Returns HTTP 200 OK. The Middleware Hub executes steps 1–7 itself, synchronously; the sequence is irreversible once started.

Branch discriminator — Is_Professional, read from the decoded JWT claims (BE-1, confirmed 2026-08-25):

Execution sequence:

Step 8 is the LIVE/SIM structural difference. On SIM the middleware writes the terminal status itself, so the state is consistent the instant the endpoint returns. On LIVE the write is Zapier's, so there is a real window in which the gateway is dead but the database still says Active_DMA — Ref: §7, §10 A-54.

⏳ Per-gateway Day 0 state values are not owned anywhere on LIVE. UC_4.15.2 §5 Step 1 says only "Lock: Disable order entry via Broker API". The SIM table (UC_4.10.2 §5 Step 3) gives Rithmic Paper INACTIVE · MT5 Sim READONLY · TE Sim TRADING IS DISABLED BY RISK RULE, while the 2026-08-26 architecture note gives Rithmic Live Admin Only for the same step, matching the Rithmic Support answer recorded in _QNA_INDEX.md ("lock Account Status = Admin Only"). The values are not restated here as fact — the LIVE table belongs in UC_4.15.2 and must be written there once, for both paths. Ref: §10, A-51.

Deviation from the source, client-confirmed. RFQ_ Stack Trading Prop Tech V7.pdf and RFQ_ Website and Dashboard Implementation V7.pdf describe the last step as "logs the user out". That half is superseded by [RES-BIZ-01] (2026-08-12) — Ref: BR_4.17.2.8. The "Trigger Flow 20" half is not superseded on LIVE — CR-65 scoped that removal to SIM only.

BR_4.17.2.6: Single Execution Guarantee — Guard on status Alone

Because the sequence in BR_4.17.2.5 is destructive, it must run at most once per account:

• Frontend: the [Resign & Close Account] button is disabled immediately on click and shows a loading state, preventing a double submission from the same modal.

• Backend: the guard keys on status alone —

  IF status IN ('Failed', 'Terminated') → HTTP 409 Conflict, halt. No DB write, no webhook.

  This covers every already-closed account in one condition: hard-breached (Terminated + Drawdown), stagnated (Terminated + STAGNATION), Ops-terminated, already resigned, and a SIM-side Failed record.

Why status alone and not the pair. By the time an account is Terminated, the Atomic Kill Switch has already blocked order routing, flattened every position and cancelled every working order. There is nothing left to resign — no live exposure, no capital at risk. Allowing a resignation on top would overwrite termination_reason (e.g. Drawdown → VOLUNTARY_RESIGNATION), destroying the record of why the seat was actually lost — and on LIVE that record drives money: it decides whether Flow 9 deducts Amount_Over_Stop_Loss or pays the full base amount (BR_4.17.2.13). A second Flow 7 run would also re-post to QuickBooks, re-fire Live_Account_Closed and create a second severance authorisation task. Same rule as SIM (BR_4.11.2.5, BE-2), with materially higher stakes.

• A second gate exists at the Flow 20 trigger — filter Is_Professional == True, so a stray RESIGNATION_EXECUTED from a SIM regression is dropped before Flow 7 can run its LIVE teardown on simulated capital. Ref: BR_4.11.2.8 (BE-6).
• The system never retries POST /resign automatically. Any retry is an explicit user action — Ref: §7 Exceptional Flow.

BR_4.17.2.7: Resignation Is Permitted Only While the LIVE Seat Is Active

The Resign & Close Account section is available only while the trader still has a seat to resign — a LIVE account that is still running:

Button state. The [Resign Account] button renders Disabled whenever status IN ('Failed', 'Terminated'). The trader remains logged in after any of these events (BR_4.17.2.8) and can still reach the Account Actions tab, so the Disabled state is reachable and must be specified. The button is never hidden — the section stays visible so the trader can see the path exists. A request that still reaches the backend is rejected with HTTP 409 per BR_4.17.2.6.

The gate is a plain status check. No termination_reason lookup is needed on either the frontend or the backend.

This is the exact inverse of the section above it. Reset Associate Track is Disabled in every state except Terminated; Resign & Close Account is Enabled only while Active_DMA. Exactly one of the two is actionable at any moment, which is the client's intent: a LIVE trader must resign before they can re-buy, precisely so live market exposure is flattened through the Kill Switch rather than abandoned by a purchase. Ref: UC_4.17.3 BR_4.17.3.4, BR_4.17.2.16.

Neither the Soft Breach lockout nor the Frosted Glass overlay blocks navigation into the Account screen — Ref: UC_4.15.2 §4.

BR_4.17.2.8: The Session Survives Resignation

Three layers are affected, and they must not be conflated — this is exactly the separation the client insisted on in [RES-BIZ-03]:

• Current session — retained. The trader is not logged out. Access tokens are not cleared, the Auth0 session is untouched and no redirect to the login page occurs (Source: [RES-BIZ-01], Adrian Stack 2026-08-12 — "Do not clear the session tokens or log the user out… so they can instantly purchase a new challenge without the friction of logging back in.").
• Trading functionality — dead. Execution privileges are revoked at the gateway on Day 0 ("their actual trading terminal connection is dead", [RES-BIZ-03]) and the Dashboard is locked behind the Frosted Glass state. The sub-account itself stays alive, locked, until archive_date — Ref: BR_4.17.2.5, BR_4.17.2.17.
• Dashboard login — retained permanently. "The user's web dashboard login remains active so they can access their history and purchase a Reset" ([RES-BIZ-03]). The login account survives so the trader can buy a new Associate Track.

Consequences:

• The shared Logout mechanism (CR-20260806-001, Ref: CR Index) is not invoked by resignation. Resign and Logout are independent paths.
• Session-scoped side effects that Logout performs — access-token clearing, redirect target, Newsquawk audio stop (Ref: BR_4.1.4.3), WebSocket closure — do not run on resignation. The trading WebSocket subscriptions are closed by the backend as part of the read-only switch, not by a session teardown.
• The trader can still reach every non-Dashboard screen (Account, Billing, Journal) and can still log out manually from the sidebar user chip.
• Discord access is a separate matter and is not preserved — the roles are revoked by Flow 7, Ref: BR_4.17.2.11.

BR_4.17.2.9: Post-Resignation Automation — Flow 20 → Flow 7, and the Four Branches That Differ

Rule. A LIVE resignation is routed as a termination. RESIGNATION_EXECUTED triggers Flow 20 (Trader Resignation Handler), whose sole action is to trigger Flow 7 (Financial Reporting / Recycling Logic) with Reason Code = VOLUNTARY_RESIGNATION (Source: Zapier Integration V7.pdf §Flow 20; QnA [RES-BIZ-02] — "flow 20 → Flow 7"; QnA FR-21).

What fires, and where it is documented. From the moment Flow 7 picks up the event, the pipeline is the Hard Breach pipeline and is specified once, at UC_4.15.2 §5 Basic Flow. Only four branch conditions resolve differently:

Do not restate the Flow 7 mechanics in this document. If they change, they change in UC_4.15.2 and this UC inherits the change automatically. The only resignation-specific inputs to the pipeline are the Reason Code and the resulting Amount_Over_Stop_Loss = $0.

Flow 7B Path B also fires — client-confirmed, and it reverses an earlier BA decision. Flow 7B is a separate database-webhook listener, not a step of Flow 7. Its trigger was widened on 2026-08-24: "please update the trigger for Flow 7B. It must fire when an account status changes to EITHER Failed OR Terminated. This ensures every single trader who loses their seat, regardless of their level or how they lost it, gets dropped into the retention marketing funnel to buy a new evaluation" (Source: [RES-ZAPF-01]).

⚠️ This supersedes the BA decision of 2026-08-12 — "a resigned LIVE trader re-enters as a new Associate Track purchase; the Scenario B In-App Re-Buy path and the Flow 7B Path B retention offer are not used on the resignation path". That decision was recorded at the time as BR_4.11.2.16 in the SIM document; it was removed in UC_4.11.2 v3.2, and on LIVE the re-entry purchase is owned by UC_4.15.3 — Scenario B: Live Failure (In-App Re-Buy), not by UC_4.11.2. A client answer of 2026-08-24 beats a BA decision of 2026-08-12, and [RES-ZAPF-01] is unambiguous that the widening exists specifically to catch resigning LIVE traders. UC_4.11.2 A-25 is answered on the email side by this document. Whether the in-app CTA price follows the same routing is a downstream question — Ref: BR_4.17.2.16, §10 A-25.

⏳ Known email collision, client-acknowledged and unresolved. A resigning LIVE trader now lands in both Flow 7 Step 11 (Live_Account_Closed — a termination letter) and Flow 7B Path B (a discounted come-back offer), roughly an hour apart. Recorded by the client's own follow-up as O-30. No suppression or delay rule has been specified — Ref: §10, A-58.

BR_4.17.2.10: Resignation Bypasses the Drawdown Defense Protocol Entirely

Rule. Flow 7 Step 1 evaluates Resignation == True before the Defense eligibility check and short-circuits directly to Liquidation (Source: Zapier Integration V7.pdf §Flow 7 Step 1; UC_4.15.2 §5 Step 1 — "IF Resignation == True → SKIP Defense Gate, proceed directly to Liquidation"; QnA FR-03).

Why the bypass is correct and not a loss of protection. Drawdown Defense exists to give a senior trader a second chance after an involuntary risk event. A resignation is the trader's own decision to leave the firm — there is nothing to protect them from, and forcing a 48-hour cooling-off on someone who has explicitly asked to be let go would trap them in a Shadow Mode account they no longer want.

Consequence for the UI: nothing is surfaced. Neither friction modal mentions Defense, offers it as an alternative, or warns a Level 9+ trader that they are forgoing it. No source proposes such a warning, and adding one would be inventing a requirement. Ref: §6.2.

BR_4.17.2.11: Discord Roles ARE Revoked, and the Pod Is Dispersed

Rule. Unlike SIM, a LIVE resignation runs the full community teardown. This is the path [DL-BIZ-04] was written for.

Digital Eviction (Flow 7 Step 8) — POST /discord/revoke-all-roles with { user_id }:

Pod Impact & Dispersal (Flow 7 Step 8a) — inserted immediately after Digital Eviction by CR-20260818-001:

Why the pod step is not optional. Without it a departed mentee's seat is never released, so the mentor's pod looks permanently full; and a departed leader's mentees hang indefinitely against a terminated account. The client's own framing: "This ensures the ecosystem correctly heals itself whether a student or a teacher drops out!"

The same two steps run on the LIVE Hard Breach path (UC_4.15.2) — same Flow 7 Steps 8 / 8a, same outcome. Resignation is not a special case: on LIVE the trader is leaving the firm, and the roles represent a professional standing that no longer applies.

⚠️ Two dependencies before this rule is buildable: CR-20260818-001 is still 🔴 Active (pending apply) and has not been written into UC_4.15.2 §5 (A-52), and the Founding Mentor exemption question is open (A-56) — Ref: §10.

BR_4.17.2.12: No Refund of the Challenge Fee — the Market Data Prepay Is the Only Reversible Charge

• The challenge purchase fee is never refunded on resignation. The trader forfeits the remainder of their engagement (Source: RFQ_ Website and Dashboard Implementation V7.pdf §Part C).

• All unvested profits are forfeited. A LIVE trader's accrued-but-unpaid profit share does not survive resignation — this is the consequence the Step 1 warning modal exists to state (§9.2).

• The Market Data Refund Check does run (Flow 7 Step 2), and it is the only money that can flow back:

  	Rule
  Scope	Next month's prepay only. IF Next_Month_Data_Paid == True → POST /issue-refund with { user_id, type: "MARKET_DATA" }
  Not in scope	The current month is never prorated. CME bills per calendar month; the month in progress is consumed
  Why the step survives	It is a chargeback failsafe — refusing to reverse a charge for a month the trader will never trade invites a dispute (Source: [MDM-BIZ-14], 2026-08-24, which reversed the earlier [MDM-BIZ-06] decision to delete this step)
  Non-reversible rails	If Gateway_Source rejects automated reversal, the middleware logs the exception to the financial ledger and raises a high-priority Freshdesk ticket with user_id, transaction_id, gateway_source, refund_amount — it never blocks Flow 7. Ref: UC_4.15.2 §5 Step 2

• Severance is not a refund and must not be presented as one. It is a contractual payment computed from the trader's level, and it is paid regardless of whether they later re-buy — Ref: BR_4.17.2.13, BR_4.15.2.5.

BR_4.17.2.13: Severance (Flow 9) — Only the Two Resignation-Specific Inputs Are Asserted Here

The severance mechanism is not owned by this document. The eligibility gate, the deduction math, the Path A/B/C payout routing, the human authorisation step, the ActiveCampaign task, the exit interview and the Polygon + QuickBooks recording are specified at BR_4.15.2.5 and owned in full by UC_7.5 — Severance (Flow 9). Nothing about them is restated here.

What this use case does assert — two inputs, and only two:

Consequence — the deduction resolves to zero, so an eligible trader receives 100 % of the base amount:

Authorized_Amount = Severance_Pay − (Amount_Over_Stop_Loss IF > $100)
                  = Severance_Pay − $0
                  = Severance_Pay

This is arithmetic, not a special case. No resignation-specific branch is needed in Flow 9: the same formula that deducts slippage on a breach naturally returns the full amount when there is no slippage to deduct. Ref: QnA FR-20, FR-26.

Eligibility is a dynamic lookup, never a hard-coded level.

IF Severance_Pay > 0   (Table A for Forex / Table B for Futures, by Current_Level) → Execute Flow 9
IF Severance_Pay == 0  or NULL                                                     → Skip Flow 9

⚠️ Three stale thresholds circulate in the sources and none of them is the rule. The QnA CSV row for this section says "LIVE — chỉ Level 3+"; FR-30 corrected that to "Severance now starts at Level 7"; and FR-54 then corrected both — "do NOT hardcode current_level >= 7… the middleware and Zapier must evaluate the Severance_Pay value directly from the configuration matrix". The Severance_Pay > 0 test is the current, client-confirmed rule and is what BR_4.15.2.5 already implements. Any level number written into code or Zapier is a defect.

Not asserted by this document, and deliberately so:

• The severance amount is never displayed in any screen this UC owns. The friction modals make no financial promise, and §9.4 quotes no figure — the amount is communicated by the exit-interview call, and it is not final until a Marketing user authorises it.
• The payout appears on the trader's Billing screen, owned by UC_4.6.3 — Ref: BR_4.15.2.5.
• ⏳ [RES-FRM-02] is unanswered: what happens if Amount_Over_Stop_Loss > Severance_Pay on some other path — floor at zero or record a debt. It cannot arise on the resignation path, so it does not block this document — Ref: §10, A-59.

BR_4.17.2.14: Database Writes at Resignation vs Archive

Three separate moments write data, and they must not be merged:

• At POST /resign (T+0), written by the middleware:

  Column	Value
  audit.action	'RESIGN' (with user_id, timestamp = NOW())

  That is all the endpoint writes to users. The status transition is Zapier's — Ref: BR_4.17.2.5 step 8.

• At Flow 7 Step 7 (Post-Termination Access Control), written by Zapier / the middleware call it makes:

  Column	Value
  users.status	'Terminated' — not 'Failed'. 'Failed' is the SIM resignation end state — Ref: BR_4.17.2.19
  users.termination_reason	'VOLUNTARY_RESIGNATION'
  users.termination_date	NOW()

  This is the write the automation layer keys on: it fires Flow 7B and it is what GET /failure-state reads.

• At archive — whichever comes first, Re-Buy or archive_date: a user_account_history snapshot is created — history_id (UUID PK), user_id (FK), email, previous_level, final_status, failure_reason, archived_at, user_snapshot (JSONB). It is written once, either when the trader re-buys (UC_4.15.3 §4) or when archive_date fires (BR_4.15.2.7 Pre-Archive Gate) — never twice.

Field-name mapping — DB column vs API field vs Zapier input. These are three names for the same fact and are frequently confused:

⚠️ LIVE keeps termination_*; SIM migrated to failure_*. CR-65 renamed termination_reason → failure_reason and termination_date → failure_timestamp for SIM only. On LIVE the original column names stand, per [RES-ZAPF-01] ("termination_reason = 'VOLUNTARY_RESIGNATION' và termination_date = NOW() giữ nguyên cho cả hai"). ⏳ Whether these are genuinely two column pairs or one pair with two names in the docs is a schema question that must be settled before implementation — Ref: §10, A-60.

Ledger lifecycle. virtual_equity is set to 0 by Flow 7 Step 3 (Ledger Close) — POST /financial/reset-ledger with deactivate: true. This is the opposite of SIM, where the ledger is left frozen at the snapshot (BR_4.11.2.10) because Flow 7 does not run there. On LIVE virtual_equity is the internal balance tracker for real capital, and closing it is what makes the GL Posting of Step 9 meaningful. The Dashboard snapshot the trader sees under the frost is not virtual_equity — it is the static equity / balance / closed-trades capture taken at failure_timestamp (UC_4.15.2 §4), so zeroing the ledger does not blank the frozen view.

BR_4.17.2.15: Post-Resignation Dashboard State — GET /failure-state Contract

There is no success screen. The confirmation that the resignation executed is carried by the modal header itself (Source: [RES-BIZ-01] — "Do not build a success screen… simply refresh the user's dashboard state.").

Rendering — inherited, not restated. The Frosted Glass treatment is exactly the Hard Breach treatment and is owned by BR_4.15.2.2 and UC_4.15.2 §4: Dashboard-screen-only blur over the static snapshot captured at failure_timestamp, permanent until a Re-Buy completes, notification bell still running, and every other screen rendering normally. This UC adds no rendering rule of its own — the only difference is which modal sits on top (§9.4 instead of the Hard Breach Failure Modal).

State contract — the resignation branch:

Response shape on the resignation branch:

{
  "is_breached": true,
  "state_reason": "RESIGNATION",
  "archive_date": "2026-08-31T23:00:00Z"
}

• archive_date is computed by the backend per broker and returned as a finished ISO 8601 string. The frontend counts down passively and never applies the Rithmic month-end rule itself — Ref: BR_4.17.2.17, BR_4.15.2.7.
• The frontend selects the modal from state_reason, never by inference — "RESIGNATION" → §9.4; "BREACH" → the Failure Modal variant matrix at BR_4.15.2.6.

⏳ The one contract gap on LIVE: who writes Terminated, and when. On SIM, POST /resign writes the status itself, so GET /failure-state is authoritative the instant the endpoint returns. On LIVE the write is Flow 7 Step 7, so the state refresh in §5 step 7.2 can land before Zapier has run and read back is_breached: false. No source specifies how the frontend bridges that window. Ref: §7, §10, A-54.

Modal behaviour.

• The modal is non-dismissible — no [X], overlay click and Esc do nothing, and there is no secondary button — Ref: §9.4.
• Navigation isolation is shared, not resignation-specific — the sidebar, the user chip (including Logout) and every Settings / Account tab stay interactive behind the overlay, so the trader is never trapped. Owned by UC_4.15.2 §4.
• The modal re-renders on every Dashboard load or reload until a new Associate Track is purchased.

BR_4.17.2.16: Re-Entry After Resignation — This Action Is What Unlocks It

Rule. Completing this use case is the hard prerequisite for LIVE re-entry. Until users.status = 'Terminated' is written, the Reset Associate Track control directly above this section is Disabled — "A live trader must use 'Resign & Close Account' first to safely flatten all live market exposure. The 'Start New Associate Track' button only becomes enabled once their status is Failed or Terminated" (Source: QnA [RAT-BIZ-04], Adrian Stack 2026-08-12). Ref: UC_4.17.3 BR_4.17.3.3, BR_4.17.3.4.

The two ways back in, both landing on the same modal:

Everything past the click is owned downstream and is not restated here:

LIVE has no Reset. What the returning trader buys is a Re-Buy — a brand-new evaluation on a fresh SIM sub-account, starting at Day 1 with empty data. There is no in-place reset path on LIVE at all — Ref: UC_4.17.3 BR_4.17.3.6.

Severance and re-entry are independent. "Severance is paid regardless of whether the trader chooses to execute a Re-Buy" (BR_4.15.2.5). Buying a new track does not forfeit the payout, and taking the payout does not bar a return.

⏳ What the trader is charged is not fully closed. BR_4.17.2.9 settles the email side — [RES-ZAPF-01] puts a resigned LIVE trader into the Flow 7B Path B retention funnel with the standard discount routing. Whether the in-app CTA resolves to the same product_id="REBUY" price, or to a full-price new Associate Track per the superseded BA decision of 2026-08-12, is owned downstream and still tracked as A-25 / A-47 — Ref: §10. A retention email offering a discount while the in-app button charges full price would be incoherent, which is the strongest argument for closing A-25 in favour of the discount.

BR_4.17.2.17: Retention and Archive Window — Owned by UC_4.15.2

Resignation does not wipe the dashboard immediately. The client answered this directly: "Just retain the 10 day access. flow 20 → Flow 7. Same failsafe applies here" (Source: [RES-BIZ-02]).

The retention window, the archive_date calculation, the broker-specific failsafe actions, the Pre-Archive Gate and the rationale for the Forex/Futures split are identical to the Hard Breach path and are owned by BR_4.15.2.7 and BR_4.15.2.3. Nothing about them is restated here — if a rule changes, it changes there.

Everything unique to resignation, in full:

Two implementation constraints this UC asserts:

• archive_date is computed by the backend and returned as a finished ISO 8601 string; the frontend counts down passively and never applies the Rithmic month-end rule itself — Ref: BR_4.17.2.15, §9.4 row 3.

• No resignation-specific scheduled job is built. The archive + gateway purge at archive_date is the existing Hard Breach failsafe cron, which must scan on status IN ('Failed','Terminated') + time and never filter on termination_reason:

  Forex (MT5 / TE):   status IN ('Failed','Terminated') AND NOW >= termination_date + Discount_Code_Duration_Days
  Futures (Rithmic):  status IN ('Failed','Terminated') AND NOW >= Min(termination_date + Discount_Code_Duration_Days,
                                                                      23:00 UTC on the last calendar day of the month)

  Filtering on termination_reason = 'Drawdown' would skip every resigned and stagnated account forever — never unassigned (Rithmic), never hard-deleted (MT5 / TE) — and the per-user platform connection fee plus next month's CME entitlements would keep billing on dead accounts. Same rule as SIM BE-5, Ref: BR_4.11.2.13.

⚠️ The EOM failsafe timestamp is inconsistent across the sources. BR_4.15.2.7 and [RES-BIZ-03] say 23:00 UTC; [RES-BIZ-02] says "11:59 PM". This document follows 23:00 UTC — it is the value the owning BR already implements and the one that leaves a batch buffer before CME's month roll. The 59-minute discrepancy is the client's own open item O-29(b) — Ref: §10, A-61.

BR_4.17.2.18: Flatten Proceeds Even When the Market Is Closed

Flattening uses market orders, which cannot fill while the market is in a Closed or Halted state (Ref: UC_4.1.3). This does not block the resignation:

• Order routing is blocked at the gateway at BR_4.17.2.5 step 2 before the flatten is attempted, so no new exposure can be opened even while a position is still outstanding.
• POST /resign still returns HTTP 200 and still emits RESIGNATION_EXECUTED; the resignation is never held open waiting for a fill.
• Convergence is closed by Flow 7 Step 4 (Liquidation second pass), which exists precisely as a confirming re-check on top of the real-time Kill Switch. The job is complete only when the gateway reports Open_Positions == 0. Ref: UC_4.15.2 §5 Step 4.
• The LIVE sub-account stays alive and locked until archive_date (BR_4.15.2.7), so there is a full retention window in which to converge.

Why this rule exists at all. A Hard Breach fires off live market data (ACCOUNT_METRICS), so by definition the market is open when its flatten runs. A resignation can be submitted at any hour — a weekend is the obvious case — so it is the only path on which an unfilled flatten is reachable.

LIVE needs no dedicated retry queue; SIM does. SIM bypasses Flow 7, so it had to build a Middleware Redis queue to replace the second pass (BR_4.11.2.11). On LIVE the second pass is still there. ⏳ What is not specified is whether Flow 7 Step 4 itself retries at the next market open, or runs once and moves on — the source describes it as a single confirming pass. If it does not retry, a weekend resignation with an unfilled position has no closing mechanism at all. Ref: §10, A-62.

BR_4.17.2.19: This Document Is LIVE Only

The SIM counterpart is UC_4.11.2. The two share the entire frontend and diverge completely from the moment POST /resign reads Is_Professional:

One frontend, two backends. The friction gate, the phrase, the modal structure and the post-resignation modal template are shared code; the environment is decided server-side. A frontend that branched on environment would be duplicating a decision the backend already owns.

This document closes UC_4.11.2 §9.4 row 3 — "⏳ Whether the retention window applies to a LIVE resignation is owned by UC_4.17.2 and not confirmed here". It does apply, per [RES-BIZ-02], and the Archive Countdown Banner therefore renders on the LIVE modal — Ref: BR_4.17.2.17, §9.4.

9. Screen Description

9.1 LIVE Account Actions tab — Resign & Close Account section

Only the Resign & Close Account row is specified here. The Reset Associate Track row above it belongs to UC_4.17.3; the tab list, the screen title and the Controls panel belong to the shell — Ref: BR_4.17.2.1.

⏳ No LIVE design frame exists. Copy is inherited from the SIM frame (UC_4.11.2 §9.1) as the working assumption — Ref: §10, A-50.

9.2 Step 1 modal — Resign & Close Account

Copy is shared with the SIM environment by design decision — the warning text names unvested profits and trading-floor access, which apply literally on LIVE and only nominally on SIM. Ref: UC_4.11.2 §9.2.

⚠️ The warning is incomplete for LIVE. It does not mention Discord role revocation, pod dispersal, or severance eligibility — all three are real LIVE consequences (BR_4.17.2.11, BR_4.17.2.13). Whether to extend the copy is an open item, not a silent addition — Ref: §10, A-64.

9.3 Step 2 modal — Confirm Resignation

9.4 Post-resignation modal — Resignation Complete (LIVE)

This modal is the only visual difference between a LIVE resignation and a LIVE Hard Breach. Everything behind it — the Frosted Glass, the frozen snapshot, the archive window, the Re-Buy flow — is the Hard Breach behaviour, referenced not restated (Ref: BR_4.17.2.15, BR_4.17.2.17).

Rendered over the Frosted Glass Dashboard once GET /failure-state returns state_reason == "RESIGNATION" — where state_reason == "BREACH" the Failure Modal variant matrix (BR_4.15.2.6, rendered at UC_4.15.3 §10.1–§10.4) renders instead. Layout reuses the Failure Modal template including its Archive Countdown Banner, minus any secondary button.

Source of the copy: client-supplied modal screenshot + written flow, 2026-08-25 (the LIVE variant), recorded for continuity at UC_4.11.2 §9.4 and owned here.

Dismissal rules — Ref: BR_4.17.2.15:

• No [X] control, no [Cancel] button, no secondary CTA.
• Overlay click does not dismiss; Esc does not dismiss.
• The archive countdown banner is rendered while the retention window is open, and disappears once it expires — Ref: BR_4.17.2.17.
• The modal re-opens on every Dashboard load or reload until a new Associate Track is purchased, and remains permanent after the window expires (only the countdown banner disappears). The sidebar navigation and the user chip (Logout) stay interactive.
• Alternate entry to the same purchase flow: the now-Enabled Reset Associate Track button on the Account Actions tab, which bypasses this modal and goes straight to pricing calculation. That section is owned by UC_4.17.3 — Ref: BR_4.17.2.16.

10. Open Items Pending Client Confirmation

The following points sit on the main flow of this use case and are deliberately left unspecified rather than assumed. Each is tracked in QnA_init_docs.md.

Closed by this document:

Changelog