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

Sources at §11, change history at §Changelog.

1. Overview

Referred to, not repeated here

2. Trigger

The trader clicks [Resign Account] in the Resign & Close Account row of the Account Actions tab (§9.1).

Navigation: sidebar user chip → Settings → the Account screen opens → the trader selects the Account Actions tab.

3. Pre-conditions

• The trader is authenticated and inside the Dashboard shell.
• users.status = 'Active_SIM' — BR_4.11.2.6.
• Is_Professional == False.
• A trading sub-account exists on the execution gateway (Rithmic Paper, MT5 Sim or TraderEvolution Sim).

4. Post-conditions

• The gateway is read-only, all open positions are flattened and all working orders cancelled. The sub-account stays assigned and connected — no purge on Day 0 (UC_4.10.2 §5 Step 3, was BR_4.10.2.9).
• users.status = 'Failed', users.failure_reason = 'VOLUNTARY_RESIGNATION', users.failure_timestamp = NOW(), plus an audit row with action = 'RESIGN' — BR_4.11.2.10.
• Discord roles are revoked by Flow 20 — BR_4.11.2.9.
• The trader receives the Klaviyo Challenge_Failed email after Flow 7B's 1-hour cool-down, unless they repurchase inside it — BR_4.11.2.8.
• GET /get-failure-state returns is_breached: true, state_reason: "RESIGNATION", archive_date — BR_4.11.2.12.
• The Dashboard renders in Frosted Glass with the Resignation Complete modal on top — §9.4.
• The trader stays logged in — BR_4.11.2.7.

5. Basic Flow

1. The trader opens the Account Actions tab. The Resign & Close Account row renders — §9.1.
2. The trader clicks [Resign Account]. The Step 1 warning modal opens — §9.2.
3. The trader clicks [Continue to Resign]. Step 1 closes; the Step 2 confirmation modal opens with an empty input — §9.3.
4. The trader types RESIGN. The value is compared case-sensitively on every keystroke; the CTA stays disabled until it matches exactly — BR_4.11.2.3.
5. The trader clicks [Resign & Close Account]. The button disables and shows a loading state; the frontend calls POST /resign with {user_id, confirmation_phrase}.
6. The Middleware Hub executes the whole sequence synchronously — BR_4.11.2.4:
   1. Validate confirmation_phrase.
   2. Switch the gateway to read-only.
   3. Flatten all open positions.
   4. Cancel all working orders. (If the market is closed, the flatten is queued for retry rather than blocking the response — BR_4.11.2.11.)
   5. Insert the audit record, action = 'RESIGN'.
   6. Write users.status = 'Failed', failure_reason = 'VOLUNTARY_RESIGNATION', failure_timestamp = NOW().
   7. Fire the RESIGNATION_EXECUTED webhook to Zapier.
7. The backend returns HTTP 200 OK. The frontend:
   1. Closes the Step 2 modal, leaving the session untouched.
   2. Re-fetches GET /get-failure-state + GET /system/status → is_breached: true, state_reason: "RESIGNATION", archive_date.
   3. Redirects to the Command Center / Dashboard.
   4. Renders the Frosted Glass Dashboard with the non-dismissible Resignation Complete modal on top — §9.4.
8. Asynchronously, in parallel — the trader waits on neither:
   1. Flow 20 catches RESIGNATION_EXECUTED, calls POST /discord/revoke-all-roles, and terminates — BR_4.11.2.8, BR_4.11.2.9.
   2. The status → 'Failed' database change triggers Flow 7B Path A: 1-hour cool-down → purchase check → pricing route → Klaviyo Challenge_Failed. Refer to UC_4.10.2 §5 Step 8.

[POST /resign — Node.js middleware, synchronous]
   gateway read-only → flatten → cancel → audit
   DB: status = 'Failed', failure_reason = 'VOLUNTARY_RESIGNATION'
        │
        ├──▶ 200 OK ──▶ redirect to Dashboard ──▶ Frosted Glass + §9.4 modal
        │
        ├──▶ RESIGNATION_EXECUTED ──▶ [Flow 20 — router]
        │                                  └─ POST /discord/revoke-all-roles → terminate
        │
        └──▶ DB state change 'Failed' ──▶ [Flow 7B Path A]
                                              ├─ Cool-Down (1 hour)
                                              ├─ Purchase Check
                                              └─ Klaviyo "Challenge_Failed"

6. Alternative Flow

[Trader cancels at Step 1] — the modal closes and returns to the Account Actions tab. No request is sent.

[Trader cancels at Step 2] — the whole flow closes and returns to the Account Actions tab; it does not return to Step 1, and the typed value is discarded. Re-entering starts again from Basic Flow step 2 with an empty input.

7. Exceptional Flow

[POST /resign fails — network error, timeout or HTTP 5xx] The Step 2 modal stays open, TE-SYS-01 is displayed, and the CTA is re-enabled so the trader can retry manually. The system does not auto-retry.

[POST /resign returns HTTP 409 — the account is already Failed] Covers a double submission, a retry after an unnoticed success and a second browser tab. No DB write and no webhook occur. The modal closes, TE-DASH-01 is displayed, and the standard state refresh runs. The session is untouched.

[The market is closed or halted when the flatten executes] The resignation is not blocked and POST /resign still returns 200. The account is read-only immediately, so no new exposure can open. The middleware queues a retry and re-issues the flatten at the next market-open tick, completing only once Open_Positions == 0 is verified — BR_4.11.2.11.

8. Business Rules

BR_4.11.2.1: Two-Step Friction Confirmation Is Mandatory

Resignation must be gated behind two sequential modals; one confirmation is not enough.

• Step 1 — Warning. States that the action is immediate and irrevocable and lists its consequences. Collects no input. §9.2
• Step 2 — Confirmation. Requires the trader to type a confirmation phrase before the final action becomes available. §9.3

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

BR_4.11.2.2: [Cancel] Is the Only Exit

Both friction modals apply the same rules: no [X] control, overlay click does not dismiss, Esc does not dismiss. [Cancel] is therefore the only way out without resigning. [Cancel] on Step 2 exits the whole flow — there is no path back to Step 1 — and the phrase input is always empty when Step 2 opens.

BR_4.11.2.3: Confirmation Phrase — RESIGN, Case-Sensitive, Exact

BR_4.11.2.4: POST /resign Execution Sequence

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

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

Returns HTTP 200 OK. The Middleware Hub executes every step itself, synchronously; the sequence is irreversible once started.

The status write is made inside the request, before the 200 OK, so GET /get-failure-state reports the closed state on the frontend's very next call and the Frosted Glass renders with no wait on Zapier.

Branch key — Is_Professional, read from the decoded JWT claims. False is the branch this document specifies. It is the only field stable across the whole account lifecycle: written False at provisioning, flipped to True only when the trader signs the Live agreement at Flow 3E. Current_Level is not a valid key — it is set to 1, 2 or 5 at provisioning from the purchased product_id (Eval_1 / Eval_2 / Eval_5) — and status is not a valid key because it is volatile.

BR_4.11.2.5: Single Execution Guarantee

The sequence is destructive, so it must run at most once per account.

• Frontend: the CTA disables on click and shows a loading state, preventing a double submission from the same modal.

• Backend:

  IF status = 'Failed' → HTTP 409 Conflict, halt.
  No DB write, no webhook.

Once the account is 'Failed' the gateway has already blocked order routing, flattened every position and cancelled every working order — there is nothing left to resign. A second resignation would overwrite failure_reason, destroying the record of why the evaluation ended, and would re-fire the status change → a second Flow 7B run → a duplicate Challenge_Failed email.

The system never retries POST /resign automatically. Any retry is an explicit user action (§7).

BR_4.11.2.6: Resignation Is Permitted Only While the Evaluation Is Live

The [Resign Account] button is Enabled only while users.status = 'Active_SIM' and Disabled once it is 'Failed'. A trader whose account has already failed still reaches this tab — the Frosted Glass covers the Dashboard only — so the Disabled state is on-screen and must be built. A request that still reaches the backend is rejected with 409 (BR_4.11.2.5).

BR_4.11.2.7: The Session Survives Resignation

The source phrasing "logs the user out" does not apply: the trader is not logged out of the dashboard. Confirmed 2026-09-03.

BR_4.11.2.8: Post-Resignation Automation — Flow 20 Routes, Flow 7B Communicates

Two things run in parallel after the 200 OK, and the trader waits on neither.

Klaviyo payload. The emitted Challenge_Failed event carries failure_reason = 'VOLUNTARY_RESIGNATION' alongside user_name and Pricing_Logic_Amount. Emitting that field is the Sotatek scope. What Klaviyo does with it — one template with a conditional block, or two templates under the same event — is a Stack Trading marketing-ops configuration and is not specified here.

BR_4.11.2.9: Discord Roles Are Revoked by Flow 20

Flow 20 calls POST /discord/revoke-all-roles.

BR_4.11.2.10: Database Writes at Resignation

Written by the middleware inside POST /resign:

The status transition is what triggers Flow 7B (BR_4.11.2.8).

virtual_equity is not touched. It stays frozen at the resignation snapshot for the whole retention window — this is the P&L and Balance the Frosted Glass Dashboard renders so the trader can review their history.

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

Flattening uses market orders, which cannot fill while the market is Closed or Halted. This does not block the resignation: order routing is blocked at the gateway before the flatten is attempted, so no new exposure can open, and the status write and everything downstream proceed regardless.

The failure mode this prevents. A trader can click Resign at any hour — a weekend is the obvious case. Without the queue the flatten is rejected once and never retried, so the position hangs until the purge sweeps the sub-account away, closing the evaluation with open exposure on the books for the whole window.

BR_4.11.2.12: Post-Resignation Dashboard State — GET /get-failure-state

There is no success screen. The frontend refreshes the dashboard state and the modal header carries the confirmation.

Rendering. The Frosted Glass treatment is exactly the Hard Breach treatment — refer to UC_4.10.2 BR_4.10.2.2 and UC_4.10.2 §4 for the full display and re-summon rules → Wireframe: Dashboard - Day 0 + Hard breach.png. This UC adds no rendering rule of its own; the only difference is which modal sits on top.

API contract:

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

Modal behaviour. Non-dismissible — no [X], overlay click and Esc do nothing, no secondary button. It re-renders on every Dashboard load or reload until a new Associate Track is purchased. The sidebar, the user chip and every Settings/Account tab stay interactive behind the overlay, so the trader is never trapped.

BR_4.11.2.13: Retention and Archive Window

The window starts at failure_timestamp, written by POST /resign (BR_4.11.2.10).

Everything after that is identical to the Hard Breach path. Refer to:

No resignation-specific scheduled job is built — the archive and gateway purge at archive_date are handled by the existing Hard Breach failsafe cron.

9. Screen Description

9.1 Account Actions tab — Resign & Close Account section

Only the Resign & Close Account row is specified here.

9.2 Step 1 modal — Resign & Close Account

The warning copy is a shared string by design decision: it mentions unvested profits and trading-floor access, neither of which applies to this account type — the account trades virtual capital and holds no profit share. It is displayed verbatim regardless — QnA_init_docs.md A-02.

9.3 Step 2 modal — Confirm Resignation

9.4 Post-resignation modal — Resignation Complete

This modal is the only visual difference between a resignation and a Hard Breach. Everything behind it — the Frosted Glass, the frozen snapshot, the archive window, the reset flow — is Hard Breach behaviour, referenced not restated (BR_4.11.2.12).

Rendered over the Frosted Glass Dashboard immediately after POST /resign returns 200, selected by state_reason == "RESIGNATION"; where state_reason == "BREACH" the Hard Breach Popup (UC_4.10.3 §10.1) renders instead. Layout reuses the Hard Breach Popup template. Copy, banner and CTA label come from the client-supplied screenshot of 2026-08-25.

Dismissal rules — BR_4.11.2.12:

• No [X], no [Cancel], no secondary CTA. Overlay click and Esc do not dismiss.
• 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).
• Sidebar navigation and the user chip (Logout) stay interactive.

10. Open Items

None. Every item on this use case was confirmed by the client on 2026-09-03: the trader is not logged out of the dashboard · users.status = 'Active_SIM' is the correct in-progress value · Current_Level is 1, 2 or 5 · the modal CTA is [Start Associate Track] and is intended to differ from the Hard Breach Popup · the endpoint is GET /get-failure-state · the confirmation-phrase input accepts 50 characters.

11. Document References

Design frames are not yet committed to References/Wireframe/Stage 2/Settings/; this document cites the Figma nodes until the BA commits them.

Changelog