UC_4.11.1: Settings — Account Actions: Reset Associate Track (SIM)

Scope — read this first. This document specifies one control: the [Reset Associate Track] button on the Account Actions tab. It answers three questions and nothing else:

1. Where the button lives and how the trader reaches it — §2.
2. When it is Enabled — BR_4.11.1.3.
3. What the click fires — BR_4.11.1.4.

Everything that happens after the click is UC_4.10.3 — Scenario A: Sim Reset (In-App), which already registers this screen as its Entry Point 2 and specifies the whole path in §5.3: loading state, pricing, the Reset Modal, the gates, the payment paths, provisioning and the success screen. None of it is restated here — Ref: BR_4.11.1.5.

---

Document References

---

1. Overview

Design: Figma — Account Actions (Reset Associate Track), node 1-15026

2. Trigger

The trader clicks [Reset Associate Track] on the Account Actions tab while the button is Enabled (Ref: BR_4.11.1.3).

Navigation path — the only one (Ref: BR_4.11.1.2):

1. Sidebar footer user chip → Settings. Ref: UC_4.1.2 §2 row 6.
2. The Account screen opens on its default tab Connections & Credentials. Ref: BR_4.6.1.1.
3. The trader selects the Account Actions tab → the Reset Associate Track section renders.

3. Pre-conditions

• The trader is authenticated and inside the Dashboard shell. Ref: UC_4.1.1 §1.
• The trader holds a SIM evaluation account (Is_Professional == False). LIVE is out of scope — Ref: BR_4.11.1.8.
• Status is Active_SIM or Failed — the two entry states this screen serves. They differ in what the trader is walking away from:

Both states render the same button and run the same flow (§5). What differs downstream is the price and the Status transition, both owned by UC_4.10.3 — see §4.

4. Post-conditions

At the hand-off point — where this use case ends, identical in both entry states:

• POST /calculate-cart returned HTTP 200 and the Reset Modal is open; control passed to UC_4.10.3 §5.3 Step 2.
• No account state changed. No charge, no Status transition, no sub-account touched — including from Active_SIM, where the running evaluation is still fully intact. Abandoning the modal costs the trader nothing. Ref: BR_4.11.1.5, BR_4.11.1.7.
• On failure, the trader stays on the Account Actions tab with the button re-Enabled — Ref: §7.

At the end of the purchase — owned by UC_4.10.3, recorded here only so the two entry states can be told apart, not restated:

Source for the Status column: BR_4.10.3.5 — "Status in DB changes from 'Failed' → 'Active_SIM' on the post-Hard-Breach path. For Early Reset (input already Status = 'Active_SIM'), Status does not change."

Neither path ever produces Status = 'Failed'. That value is written only by UC_4.10.2 (Hard Breach), UC_4.10.4 (stagnation expiry) or UC_4.11.2 (resignation) — never by a reset.

5. Basic Flow

1. The trader reaches the Account Actions tab per §2.
2. The Reset Associate Track section renders — title, description, button. The button is Enabled (Ref: BR_4.11.1.3).
3. The trader clicks [Reset Associate Track].
4. The button is disabled and the frontend calls POST /calculate-cart with product_id="RESET". Ref: BR_4.11.1.4.
5. Hand-off. On HTTP 200 the Reset Modal opens and control passes to UC_4.10.3 §5.3. This UC ends here — Ref: BR_4.11.1.5.

6. Alternative Flows

None. The flow in §5 is identical in every SIM account state — same button, same single call, same modal. What differs is the price, and the price is decided by UC_4.10.3, not by this screen — Ref: BR_4.11.1.6.

7. Exceptional Flow

8. Business Rules

BR_4.11.1.1: What This UC Owns

This UC owns only the Reset Associate Track section of the Account Actions tab. Everything else on the Account screen is owned elsewhere:

BR_4.11.1.2: One Entry Point Only

The section is reachable only through user chip → Settings → Account Actions tab. There is no deep link, no shortcut from the Dashboard, and no route landing directly on the tab — the Account screen always opens on Connections & Credentials (Ref: BR_4.6.1.1).

The section holds no editable field, so leaving the tab needs no unsaved-changes interception.

BR_4.11.1.3: Button Enablement — Enabled in Every SIM Account State

The [Reset Associate Track] button is Enabled for a SIM trader in every account state. It is never hidden, never Disabled, and carries no tooltip.

Two notes:

• Terminated is not a SIM state. Since 2026-08-25 no SIM flow produces it; it survives on LIVE only (UC_4.17.2). Ref: CR-65.
• Enabled ≠ authorised. Status is re-checked server-side as Gate 1 at the modal's CTA, which accepts Failed and Active_SIM — Ref: UC_4.10.3 §5.1 Step 2.

BR_4.11.1.4: The Click Fires Exactly One Request

POST /calculate-cart with product_id="RESET" — the only request this UC owns.

• The button is disabled at the moment of click, before the request is issued, and stays disabled while the call is in flight. A double-click cannot produce a second call or a second modal.
• On HTTP 200 the button is not re-enabled behind the modal — the modal owns the screen. Ref: BR_4.11.1.5.
• On failure the button is re-Enabled for a manual retry. The system never auto-retries: a retry re-prices the purchase and must be deliberate. Ref: §7.
• The loading state shown during the call (spinner + "Calculating regional taxes...") is specified in UC_4.10.3 §5.3 Step 1.

BR_4.11.1.5: Hand-off — Everything After the Click Belongs to UC_4.10.3

This screen is Entry Point 2 of UC_4.10.3. From the click onward, follow UC_4.10.3 §5.3. This document makes no statement about, and must never restate:

• Pricing and the four-way route — BR_4.10.3.1.
• The Reset Modal, the promo code flow, the base-price lock and the tax re-calculation at pay click.
• Gate 1 (status), Gate 2 (sanctions), Gate 3 (vaulted card); Paths A / B / C.
• POST /purchase-challenge-reset, POST /provision-sim-user, and every post-payment consequence — trade archive, balance reset, Status transition, Frosted Glass removal, credentials.
• The success screen and its [Return to Dashboard] CTA — the flow ends on the Dashboard at Day 0, not back on the Account screen.

Two behaviours this UC does assert about the boundary itself:

• The Hard Breach Popup is never shown on this path. That popup is Dashboard-only (Ref: BR_4.10.2.2); clicking here goes straight to the pricing call, and this screen never navigates to the Dashboard to show it. This is the defining difference between Entry Point 1 and Entry Point 2.
• There is no separate confirmation dialog before the modal. The Reset Modal is the confirmation — reset is a paid action, so the payment modal carries it. No typed-phrase friction barrier of the kind Resign & Close Account uses (Ref: BR_4.11.2.1). Abandoning the modal changes nothing.

When UC_4.10.3 changes, this document does not — the hand-off is by reference, not by copy.

BR_4.11.1.6: Pricing Is Not Decided Here

Price and modal are resolved server-side on POST /calculate-cart and specified in BR_4.10.3.1 — four routes over Discount_Code_Duration_Days × is_founder. Not restated here.

One consequence is worth recording for this entry point:

A trader who resets proactively from a running evaluation (Status = 'Active_SIM') can only land on the within-window routes — A (founder → locked_reset_price) or C (standard → Reset Fee by Current_Level + Asset_Class). There is no countdown to expire: Discount_Code_Duration_Days runs from failure_timestamp, and an active account has none. The Early Reset override in BR_4.10.3.1 states this explicitly: "always uses the within Discount_Code_Duration_Days pricing tier (no window check performed)".

For a Failed account entering from this screen the normal window check applies, so routes B and D remain reachable — Ref: §10, A-25.

BR_4.11.1.7: Early Reset From an Active Evaluation Forfeits It

Enabling the button in Active_SIM makes reset destructive: the account being reset still has progress. The client specified the backend consequence (Adrian Stack, 2026-08-12, row Endpoints):

Boundaries this document asserts:

• Nothing is forfeited on this screen. Delete-pay-provision runs on the purchase call, not on POST /calculate-cart. A trader who opens the modal and abandons it keeps their evaluation intact — positions and progress included.
• The forfeit is not refunded and not reversible. The original fee is gone; the new challenge is a new purchase.
• Provisioning itself is owned by BR_4.10.3.2 (Case A / Case B), not by this UC.

BR_4.11.1.8: SIM Only

Every rule here is written for a SIM trader (Is_Professional == False). No individual rule is gated on environment — the document as a whole is.

The LIVE counterpart is UC_4.17.3, and its rules are the opposite of this document's: Disabled in every LIVE state except Terminated, resignation via UC_4.17.2 is a hard prerequisite, and the purchase is a Re-Buy (POST /initiate-rebuy), never a Reset — Ref: BR_4.17.3.3, BR_4.17.3.6.

9. Screen Description

9.1 Account Actions tab — Reset Associate Track section

Only this section is specified. Resign & Close Account below it belongs to UC_4.11.2 §9.1; the tab list and Controls panel belong to the shell — Ref: BR_4.11.1.1.

10. Open Items Pending Client Confirmation

Closed:

---

Changelog