UC_4.17.3: Settings — Account Actions: Reset Associate Track (LIVE)

---

Document References

⚠️ WBS gap — this UC_ID does not exist in the WBS yet. References/WBS/[BA Internal] Stacktrading.csv currently lists only UC_4.17.1 (Market Data Management) and UC_4.17.2 (Account Actions - Resign Account) under STAGE 2.2: DASHBOARD LIVE → Settings. UC_4.17.3 was assigned by BA instruction on 2026-08-26 to close open item A-23 of UC_4.11.1, which recorded that "the LIVE counterpart … which UC owns it" was unassigned. The WBS row must be added before this document is considered indexed — Ref: §10, A-40.

Design asset — the SIM frame governs the layout. Figma node 1-15026 (Account Actions tab, shown to BA 2026-08-26) is the authoritative frame for this screen's shell: the 5-tab list, the Controls panel, and an Account Actions card holding Reset Associate Track above Resign & Close Account. Button styling convention: Reset = Primary (gold/tan), Resign = Danger (red). LIVE inherits all of it.

The frame draws the button in its Enabled state only, because on SIM it is never Disabled (BR_4.11.1.3). That is a design omission, not a requirement gap — the client stated the LIVE behaviour explicitly, so the Disabled state is specified here as the standard disabled state of the same Primary button (Ref: BR_4.17.3.3, §9.1 row 4). No LIVE-specific variant needs to be drawn before FE can build it.

⏳ Still open on the design side: the frame is not committed to the repo (References/Wireframe/ has no Settings folder for any stage) — the same gap SIM tracks as A-17. And two copy strings genuinely differ on LIVE and cannot be inherited: the button label and the row description — Ref: §10, A-41, A-45, A-46.

Hand-off scope: this document owns the Reset Associate Track section on the LIVE Account Actions tab — its copy, its action button, the condition under which that button is Enabled, and the single POST /calculate-cart call the click issues. Everything after that call returns HTTP 200 — pricing routing, the Re-Buy modal, the payment gates and paths, the Live→SIM rollback provisioning and the success screen — is owned by UC_4.15.2 and the UC_4.15.3 modal flow it routes into, and is not restated here — Ref: BR_4.17.3.9.

Forward reference: UC_4.17.2 (Account Actions — Resign Account, LIVE) is not yet documented in this repo. It is the hard prerequisite for this use case (BR_4.17.3.4) and is referenced by ID throughout rather than by link. Its confirmed contract as of today — LIVE branch of POST /resign on Is_Professional == True → RESIGNATION_EXECUTED → Flow 20 → Flow 7 → status = 'Terminated' — is recorded in UC_4.11.2 BR_4.11.2.4 and QnA [RES-ZAPF-01], and that is all this document relies on.

Environment scope: LIVE only. The SIM counterpart is UC_4.11.1, whose rules are the opposite of this document's on the one point that matters: SIM is Enabled in every state, LIVE is Disabled in every state except one — Ref: BR_4.17.3.12.

---

1. Overview

Design: ⏳ No Figma node assigned. The WBS carries no design link for the LIVE Settings module beyond UC_4.17.1. Ref: §10, A-41.

2. Trigger

The trader clicks the action button in the Reset Associate Track row of the LIVE Account Actions tab (Ref: §9.1), while that button is Enabled — i.e. while users.status = 'Terminated' (Ref: BR_4.17.3.3).

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 (this UC) above the Resign & Close Account section (Ref: UC_4.17.2).

The tab stays reachable after termination. The Frosted Glass overlay applies to the Dashboard screen only; the Account screen renders normally, and the Dashboard login never expires — Ref: UC_4.15.2 §4 Post-conditions. Without that, a Terminated trader could never reach an Enabled button and the client's rule would be unreachable.

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

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 — Is_Professional == True. 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: CR-65 BE-1, UC_4.11.2 §A-39. A SIM trader is out of scope for this document — Ref: BR_4.17.3.12.
• For the section to render: none. The section renders in every LIVE account state; only the button's Enabled/Disabled state varies — Ref: BR_4.17.3.3.
• For the button to be Enabled: users.status = 'Terminated'. Reached by exactly two routes, both of which run the Atomic Kill Switch first — Ref: BR_4.17.3.4:
  1. Voluntary — the trader resigned via UC_4.17.2 → RESIGNATION_EXECUTED → Flow 20 → Flow 7 → status = 'Terminated', termination_reason = 'VOLUNTARY_RESIGNATION' (Source: QnA [RES-ZAPF-01]; Zapier Integration V7.pdf §Flow 20).
  2. Involuntary — Hard Breach Level Stop via UC_4.15.2, Stagnation (Flow 19) or a Defense-exhausted breach → Flow 7 → status = 'Terminated', failure_timestamp = NOW().
• Only when Status = 'Terminated': archive_date is available for the account and returned by GET /failure-state. It decides the price the trader will be quoted, not whether the button is Enabled — Ref: BR_4.15.2.7, BR_4.17.3.5.

4. Post-conditions

• Pricing has been calculated and the Re-Buy Modal is open, with control passed to the LIVE recovery flow owned by UC_4.15.2 (state, window, provisioning) and rendered by UC_4.15.3 §10.3 (the modal itself).
• This use case changes no account state on its own. No charge is created, no sub-account is touched, and Status is unchanged by anything specified in this document — the click only prices the purchase and opens the modal (Ref: BR_4.17.3.9).
• No live exposure is ever closed by this screen. By construction the button cannot be clicked while exposure exists: it is Disabled until Terminated, and by the time Terminated is written every position has already been flattened and every working order cancelled by the Atomic Kill Switch (Ref: BR_4.17.3.4). This is the entire point of the client's rule.
• If the pricing call did not succeed, the trader remains on the Account Actions tab with the button re-Enabled and nothing changed (Ref: §7).

5. Basic Flow

Happy case — the trader has already reached Status = 'Terminated' (by either route in §3), is inside the Discount_Code_Duration_Days window, and holds a vaulted card. The states in which the button is Disabled are covered in §6.1; the expired window in §6.4.

1. The trader reaches the Account Actions tab per §2.
2. The Reset Associate Track section renders its title, its description and the action button. The button's Enabled/Disabled state follows Ref: BR_4.17.3.3; its label follows Ref: BR_4.17.3.5.
3. The trader clicks the button.
4. The button is disabled immediately and the section enters a loading state showing a spinner and the text "Calculating regional taxes...", rendered in place on the Account Actions screen (Ref: BR_4.17.3.10). The Failure Modal — "Trading Authority Revoked" — is not shown on this path (Ref: BR_4.17.3.7).
5. The frontend compares archive_date against NOW to determine whether the discount window is still open, and reads user.is_founder to determine the pricing tier. Both feed the three-way routing defined in Ref: BR_4.15.3.1. archive_date itself is broker-specific and is computed backend-side — Ref: BR_4.15.2.7.
6. The frontend calls POST /calculate-cart with the full payload. The backend returns the base price and tax_amount; Final_Charge = base_price + tax_amount.
7. On HTTP 200 the loading state ends and the Re-Buy Modal opens with the calculated pricing — control passes to UC_4.15.2, whose recovery path routes the purchase through UC_4.15.3 §5 Step 2.
8. Everything from this point on — the promo code entry point, the three gates (status, sanctions, vaulted card), Paths A/B/C, the payment states, the Live→SIM rollback provisioning (Case A / Case B), the Rithmic Futures Market Data re-select screen and the success screen — is owned downstream. This use case makes no statement about them (Ref: BR_4.17.3.9).
9. On a successful purchase the trader ends the flow on the Dashboard at Day 0 via the success screen's [Return to Dashboard] CTA, now on a new SIM evaluation account (Status = 'Active_SIM', new credentials on the Paper Trading Gateway) — the trader is not returned to the Account screen they started from (Ref: BR_4.17.3.11, BR_4.17.3.6).

6. Alternative Flows

6.1 Button Disabled — Every LIVE State Except Terminated

This is the default state of this screen for a LIVE trader, and the one the client's answer is actually about.

1. The trader reaches the Account Actions tab per §2 while users.status = 'Active_DMA' — trading normally, or under a Soft Breach daily-loss lockout (UC_4.15.1), or inside the 48-hour Defense Protocol cooling-off / Shadow Mode (UC_4.15.4).
2. The section renders, and the action button renders Disabled. No request is issued and no modal can open. Ref: BR_4.17.3.3.
3. The only route forward is the Resign & Close Account section directly below, owned by UC_4.17.2 — Ref: BR_4.17.3.4.
4. The button renders as the standard disabled state of the Primary button — no tooltip, no helper line. The section's explanatory copy is the row description (Ref: §9.1 row 3), which is where the LIVE wording must carry the message; the Resign & Close Account section it points at is directly below on the same screen, so no separate pointer element is needed — Ref: §9.1 row 4.

Note — Soft Breach and Shadow Mode are trading locks, not account states. In both, users.status is still 'Active_DMA', so this section behaves exactly as in the normal trading state: Disabled. This is the opposite of SIM, where a Soft Breach lockout leaves the button Enabled (BR_4.11.1.3) — and the divergence is the point: on SIM the capital is virtual, on LIVE both states still carry open positions in a real market.

6.2 Enabled After a Voluntary Resignation (Terminated, termination_reason = 'VOLUNTARY_RESIGNATION')

The route the client's answer prescribes.

1. The trader completes the two-step friction barrier of UC_4.17.2. POST /resign takes the LIVE branch (Is_Professional == True), emits RESIGNATION_EXECUTED → Flow 20 → Flow 7 with Reason = VOLUNTARY_RESIGNATION, and Flow 7 writes status = 'Terminated' (Ref: UC_4.11.2 BR_4.11.2.4 table row True | LIVE, UC_4.15.2 §5 Step 1 Defense Gate — "IF Resignation == True → SKIP Defense Gate, proceed directly to Liquidation").
2. The trader is not logged out and can return to the Account Actions tab at any time.
3. The Reset Associate Track button is now Enabled. The flow is the full §5 Basic Flow, steps 1–9.
4. ⏳ What the trader is charged on this branch is not fully closed. UC_4.11.2 §10 A-25 records a BA decision of 2026-08-12 that "a resigned LIVE trader re-enters as a new Associate Track purchase; the Scenario B In-App Re-Buy path (product_id="REBUY", POST /initiate-rebuy) and the Flow 7B Path B retention offer are not used on the resignation path" — still pending client confirmation. If that decision stands, the resignation branch does not get the Retry_Discount price of BR_4.15.3.1 and this screen's click resolves to a different product_id. This document does not pick a side — Ref: §10, A-25 (inherited), BR_4.17.3.6.

6.3 Enabled After a Hard Breach (Terminated, failure_timestamp set)

Applies when the trader never resigned — the account was terminated by the Atomic Kill Switch of UC_4.15.2, by the Stagnation Monitor (Flow 19), or by a breach with Defense already exhausted.

1. The button is Enabled on exactly the same predicate — status = 'Terminated'. The reason the account closed does not change this screen's behaviour; the client's condition is on status alone (Ref: BR_4.17.3.3).
2. The flow is the full §5 Basic Flow. Pricing follows BR_4.15.3.1 with no ambiguity on this branch — this is the canonical Scenario B Re-Buy.
3. The trader may reach the same modal two ways at once. The Dashboard's Failure Modal re-summons on every Dashboard visit until a purchase completes (UC_4.15.3 §5 Step 0), while this screen offers the same purchase without it. Both converge on the same Re-Buy Modal — Ref: BR_4.17.3.7.

6.4 Discount Window Already Expired (Terminated, NOW > archive_date)

Applies when the archive_date failsafe has already fired — the historical ledger has been purged from the active Dashboard view, the Dashboard has reset to a blank D=0 state, and the broker-side cleanup has run (Rithmic: Live User ID disabled, market data revoked, LIVE sub-account unassigned · MT5/TE: LIVE sub-account hard-deleted). Ref: BR_4.15.2.7.

1. The button stays Enabled. The client's condition is status = 'Terminated', which does not change when the window closes. Expiry changes the price, never the enablement — Ref: BR_4.17.3.3, BR_4.17.3.5.
2. Steps 1–6 of the §5 Basic Flow run unchanged.
3. On HTTP 200 the Re-Buy Modal opens priced at the Full Challenge Price (Table J) for a standard trader, or at locked_rebuy_price for a founder — the founder route ignores the window entirely. Ref: BR_4.15.3.1.
4. Provisioning downstream follows Case B instead of Case A — the failsafe has already cleaned up, so only the new SIM sub-account is provisioned. Ref: BR_4.15.2.7.

6.5 Founding Mentor (Role_Flag = 'Founding Mentor')

1. Enablement is unchanged — status = 'Terminated' is the only condition (Ref: BR_4.17.3.3).
2. The Founding Mentor overlay and its acknowledgement gate are a Dashboard mechanism (Ref: UC_4.15.2 §6 Alternative Flow, UC_4.15.3 §2 Entry Point 3). Like the Failure Modal, it is not rendered on this path — Ref: BR_4.17.3.7.
3. Pricing is locked_rebuy_price regardless of the window — Ref: BR_4.15.3.1.
4. ⏳ Open: whether reaching the Re-Buy Modal from Settings is allowed to bypass the Founding Mentor overlay acknowledgement, or whether the acknowledgement is a hard prerequisite that must be enforced here too. The two source documents describe the overlay only as a Dashboard gate and are silent on this screen — Ref: §10, A-44.

7. Exceptional Flow

• [If the trader clicks the button repeatedly]

  • The first click disables the button and starts the loading state, so no second POST /calculate-cart is issued and no second modal can open. Ref: BR_4.17.3.10.

• [If POST /calculate-cart fails — HTTP 5xx, timeout, or no network]

  • The loading state ends, the modal does not open, and the trader stays on the Account Actions tab with the button re-Enabled.
  • The system displays Ref: TE-SYS-01.
  • The system does not auto-retry — retrying is a fresh click by the trader. Ref: BR_4.17.3.10.

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

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

• [If POST /calculate-cart returns HTTP 403 — sanctioned region]

  • The sanctions check is real-time and runs on this call as well as on the purchase call. The handling is the one already specified for the LIVE Re-Buy flow — Ref: UC_4.15.3 §7 Exceptional Flow, which routes the trader to Ref: FP-02. This use case adds no separate handling.

• [If Status changes between page render and the click — e.g. the archive_date failsafe fires, or an Ops action reopens the account]

  • Not detected on this screen. It is caught by Gate 1 at the CTA click inside the Re-Buy Modal, which validates Status == 'Terminated', closes the modal and displays Ref: TE-DASH-01 — Ref: UC_4.15.3 §5 Step 2 Gate 1, §7.
  • The Enabled state on this screen is not an authorisation. The backend gate remains the authority — Ref: BR_4.17.3.3.

• [If a request reaches the backend while the account is still Active_DMA — a bypassed or stale Disabled state]

  • Gate 1 on POST /initiate-rebuy rejects it, since it accepts 'Terminated' only (Ref: UC_4.15.3 §5 Step 2 Gate 1). The client's 2026-08-12 answer confirmed POST /initiate-rebuy is "No change", so no LIVE-side backend widening is required by this document — the widened validation in that answer applies to POST /purchase-challenge-reset, which is SIM-only. Ref: BR_4.17.3.6.

8. Business Rules

BR_4.17.3.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 Reset Associate Track section on the LIVE side. Everything else is owned elsewhere:

This UC makes no statement about the display or enablement of the Resign & Close Account section — it only depends on that section's outcome.

BR_4.17.3.2: The Section Has Exactly One Entry Point

The Reset Associate Track section is reachable only through the sidebar footer user chip → dropdown → Settings → Account Actions tab (§2). There is no deep link to it, no shortcut from the Dashboard, and no route that lands on the Account Actions tab directly — the Account screen always opens on Connections & Credentials first (Ref: BR_4.6.1.1).

In particular, the Dashboard Failure Modal's own CTA is not an entry point to this section — it opens the Re-Buy Modal directly, bypassing Settings altogether (Ref: UC_4.15.3 §2 Entry Point 1).

The section holds no editable field, so switching tabs away from it needs no unsaved-changes interception.

BR_4.17.3.3: Button Enablement — Disabled Until Status = 'Terminated'

The action button is Disabled for a LIVE trader in every account state except Terminated. It is never hidden. Client-confirmed (Source: QnA from clients — Stage 2 - Dashboard & Fomula (Settings).csv, category Settings: Reset Associate Track, rows Business logic / UI/UX, [RAT-BIZ-04], Adrian Stack, 2026-08-12):

"Live Traders: the button 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."

Why the client's "Failed or Terminated" becomes Terminated alone here. 'Failed' is the SIM terminal value: [RES-ZAPF-01] confirms "SIM Resignation → status = Failed; LIVE Resignation → status = Terminated", and UC_4.15.2 §4 writes 'Terminated' on a LIVE Hard Breach. No LIVE flow produces 'Failed'. The client's two-value phrasing is a single predicate written once and reused across both environments — the same shape as the Flow 7B trigger (status IN ('Failed','Terminated')) and GET /failure-state, both of which deliberately keep both branches because SIM and LIVE share the endpoint (Ref: CR-65 BE-3, UC_4.11.2 BR_4.11.2.12). Applied to a LIVE-only screen the predicate collapses to one value. Implementing the frontend as status IN ('Failed','Terminated') is harmless and equivalent; implementing it as status == 'Terminated' is exact. Confirmed as the intended narrowing by BA instruction, 2026-08-26.

The Enabled state is not an authorisation. Status is re-checked server-side as Gate 1 at the CTA inside the Re-Buy Modal, which accepts 'Terminated' only (Ref: UC_4.15.3 §5 Step 2). A stale Disabled/Enabled state on this screen changes nothing about what the backend will accept — Ref: §7.

BR_4.17.3.4: Resignation Is a Hard Prerequisite — the Reason Is Live Market Exposure

The Disabled state is not a soft nudge; it is the mechanism by which the system guarantees that no LIVE trader can walk away from real market exposure by buying something. The client stated the reason explicitly: "Live traders must use the 'Resign & Close Account' button first to safely flatten all live market exposure" ([RAT-BIZ-04]).

Why this is the opposite of SIM. On SIM, BR_4.11.1.7 lets a trader forfeit a running evaluation straight from this section — the backend deletes the active sub-account, takes payment and provisions a fresh one. That routine is acceptable on simulated capital. On LIVE the same routine would mean the platform destroying a sub-account that may hold open positions in a real market: unhedged exposure with no owner, no flatten, no cancel of working orders, and a General Ledger that never closes. The client's rule removes the possibility entirely rather than adding a warning to it.

What the resignation guarantees before this button ever becomes clickable. Both routes into 'Terminated' run the same Atomic Kill Switch (Ref: UC_4.15.2 §5 Step 1):

Consequently §4 can assert that this screen never closes live exposure: by the time the button is clickable there is none left. This use case builds no flatten, cancel or lock logic of its own — it inherits the guarantee and does nothing more than refuse to act before it holds.

BR_4.17.3.5: Button Label — the Client Names a Different String Than the SIM Screen

The client's LIVE answer names the control "Start New Associate Track", not "Reset Associate Track": "The 'Start New Associate Track' button only becomes enabled once their status is Failed or Terminated" ([RAT-BIZ-04]). The section itself is still titled Reset Associate Track in the WBS and on the SIM frame.

⏳ Four strings currently name the same control across the repo, and the client has selected none of them:

This document does not pick one — Ref: §10, A-45. It is the LIVE twin of the still-open SIM item A-05, where the client offered three post-expiry strings across two answers and selected none.

The label does not drive the routing. Price and modal are decided server-side on the pricing call from archive_date and is_founder (Ref: BR_4.15.3.1); the label is presentation only. Unlike SIM, the label does not need to change at the window boundary — there is no Reset-vs-New-Track split on LIVE to signal, only a price difference (Ref: BR_4.17.3.6, §6.4).

BR_4.17.3.6: LIVE Has No Reset — This Control Buys a Re-Buy

Despite the section name, nothing on the LIVE side is reset. The client and the LIVE architecture are consistent on this:

"LIVE has no 'Reset' option, only 'Re-Buy' — every LIVE failure requires purchasing a brand-new evaluation." (Source: UC_4.15.2 §Architecture note, from the BA-confirmed answer "LIVE thì auto xóa account nên chỉ có rebuy, k có reset" — QnA_init_docs UC_4.15.2 QN-03.)

What that means concretely for this screen:

The trader ends the flow on a SIM account, not a LIVE one. This is the single most consequential fact behind a control whose label says "Reset Associate Track", and the section's description copy must make it unambiguous — Ref: §9.1 row 3, §10 A-46.

⏳ product_id is not stated for this call. SIM sends product_id="RESET"; the LIVE Scenario B documents describe POST /calculate-cart "with the full payload" without naming the product, and UC_4.11.2 A-25 leaves open whether the resignation branch even uses product_id="REBUY". Ref: §10, A-47.

BR_4.17.3.7: This Entry Point Bypasses the Failure Modal

Clicking the button goes straight to the pricing call. The Failure Modal — the Dashboard-only "Trading Authority Revoked" modal that re-summons on every Dashboard visit until a purchase completes (Ref: UC_4.15.3 §5 Step 0, BR_4.15.2.2) — is never rendered on this path, and this screen never navigates the trader to the Dashboard in order to show it. The same holds for the Founding Mentor overlay (Ref: §6.5).

This is the defining difference between the entry points into the LIVE Re-Buy purchase, and it matches the structure UC_4.15.3 §2 already documents: Entry Point 1 starts at the Failure Modal, Entry Point 2 is this screen and skips it, Entry Point 3 is the Founding Mentor acknowledgement. All three converge on the same Re-Buy Modal.

The Frosted Glass overlay itself is unaffected by anything on this screen — it is removed only when a purchase completes (Ref: BR_4.15.2.2).

BR_4.17.3.8: No Separate Confirmation Step — the Re-Buy Modal Is the Confirmation

There is no additional confirmation dialog between the button and the Re-Buy Modal, and no typed-phrase friction barrier of the kind the neighbouring Resign & Close Account section uses. Client-confirmed for this category: "No extra confirmation dialog is introduced — the 1-Click Confirmation Modal (Base Price / Tax / Final Total + vaulted card) remains the confirmation step in every state." (Source: same CSV, row UI/UX, 2026-08-12).

The purchase is a paid action, so the payment modal already carries the confirmation, and the trader can abandon it at any point before the CTA without any state change.

On LIVE this rule carries less weight than on SIM, because the destructive step has already happened: by the time the button is clickable the account is Terminated, the positions are flat and the ledger is closed. There is nothing left for a confirmation dialog to protect. The friction that matters on LIVE sits one section below, in UC_4.17.2 — Ref: BR_4.17.3.4.

BR_4.17.3.9: Hand-off Boundary — No Pricing, Payment or Provisioning Logic Lives Here

This use case owns exactly one request: POST /calculate-cart. It owns none of the following, all of which belong to UC_4.15.2 and the UC_4.15.3 modal flow it routes into, and must not be duplicated or contradicted here:

When either document changes, this one does not need to change with it — the hand-off is by reference, not by copy.

BR_4.17.3.10: One In-Flight Pricing Request Per Click

The button is disabled at the moment of click, before the request is issued, and stays disabled for as long as the loading state is on screen. Consequently:

• A double-click or a rapid repeat click cannot produce a second POST /calculate-cart, and cannot open two Re-Buy Modals.
• On success, the button is not re-enabled behind the modal — the modal owns the screen from that point (Ref: BR_4.17.3.9).
• On any failure, the loading state ends and the button is re-Enabled so the trader can retry manually. The system never retries automatically, because a retry re-prices the purchase and must be a deliberate act.

BR_4.17.3.11: The Flow Ends on the Dashboard, Not on the Account Screen

A purchase started from this section ends where a purchase started from the Dashboard ends: on the success screen "Track Started", whose [Return to Dashboard] CTA closes the screen, removes the Frosted Glass and shows the Dashboard at Day 0 on the new SIM account (Ref: UC_4.15.3 §4 Post-conditions).

For Rithmic Futures traders one screen is interposed first: the non-dismissible Market Data re-select screen, which the trader cannot skip and which blocks Dashboard access until submitted (Ref: BR_4.15.2.8). Forex traders (MT5, TraderEvolution) go straight to the success screen.

The trader is deliberately not returned to the Account Actions tab they started from. If the trader abandons the Re-Buy Modal instead of paying, they return to the Account Actions tab with nothing changed.

BR_4.17.3.12: This Document Is LIVE Only

Every rule in this document is written for a LIVE trader (Is_Professional == True). No rule is gated on environment — the document as a whole is. The SIM counterpart is UC_4.11.1, and the two are not variants of one rule set — they are opposites on the point that matters:

This document closes UC_4.11.1 §10 A-23 — "The LIVE counterpart … Which UC owns it, and what a LIVE trader buys once enabled". The owner is UC_4.17.3; what the trader buys is a Re-Buy (Ref: BR_4.17.3.6). The WBS row still has to be created — Ref: §10, A-40.

9. Screen Description

9.1 LIVE Account Actions tab — Reset Associate Track section

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

⏳ No LIVE design frame exists (Ref: §10, A-41). Copy marked "inherited" is taken from the SIM frame (UC_4.11.1 §9.1) as the working assumption; copy marked ⏳ is genuinely undecided and must not be implemented before the client answers.

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