Toast Message & Popup — Master List
Project: Stack Trading Date Created: 2026-07-23 Version: v3.44 Last Updated: 2026-10-31
0. Component Type Legend
| Type | Prefix | Behaviour |
|---|---|---|
| Toast | TS / TE | Auto-dismiss (10s), non-blocking. Positioned top-right corner. Does NOT halt the flow. No buttons. |
| Banner | BN | Persistent message anchored in-page (top-of-screen / inline). Non-modal. |
| Overlay / Popup | OV | Blocking popup over the current screen. User must act via a button. |
| Confirm | CF | Confirmation popup requiring an explicit user decision. |
| Inline | IN | Red inline error under a field (percommon_rules.md). |
| Full-page | FP | Full-screen block / error page. NOT a toast. |
Critical rule: 404 → full-page (
FP-01); 500 → full-page (FP-03); 403 → full-page / inline hard stop (FP-02/IN-01); 400 → full-page (FP-04).
1. Toast Messages
Non-blocking, auto-dismiss (10s). Positioned top-right corner. No buttons.
Auth0 boundary: Login, Sign-up, invalid-credentials, account-lockout, and password-reset UI are Auth0-hosted (Universal Login redirect) — owned by Auth0, NOT our app. Do NOT spec app-side toasts for "wrong password" / "email already exists" / "reset link sent". Our app only owns the states below.
| ID | Context | Toast Content | Type |
|---|---|---|---|
| TS-01 | Newsletter subscribe success (marketing) | "You're subscribed. Welcome to the desk." | Success |
| TE-SYS-01 | No network, request timeout, or HTTP 500 — initial page load OR action failed. Also covers client-side timeout / no server response (no HTTP status at all). | "Unable to connect. Please check your network and try again" | Error |
| TE-AUTH-01 | Session / Access token expired (401) — post-login | "Your session has expired. Please log in again" → redirect to Auth0 login | Error |
| TE-AUTH-02 | Silent token refresh failed → forced re-auth | "Your session has expired. Please log in again" → redirect to Universal Login | Error |
| TE-AUTH-04 | MFA / FIDO2 Passkey step-up failed on high-risk mutation | "Additional verification failed. Please try again to continue." | Error |
| TS-DASH-01 | Settings — an explicit save action returns HTTP 200: any tab's [Save Changes], plus the profile-photo commit. In Profile & Preferences this covers both commit paths: PATCH /profile (phone, via [Save Changes]) and PATCH /profile-photo (photo, via Crop Image [Done] or [Confirm] in CF-03) — on a photo commit the blocking overlay OV-09 closes first, then this toast is raised; the two are never shown together. Not raised by the Preferences toggles (Desk Manager, Reduce Motion), which persist silently — Ref: UC_4.6.4 §9.1 rows 4 and 7. Ref: UC_4.6.2 §5 / BR_4.6.2.16 / BR_4.6.2.15. | "Changes saved successfully" | Success |
| TE-DASH-01 | In-Dashboard purchase (Time Extension, Reset, Rebuy, Market Data): backend rejects charge because account Status changed between modal open and CTA click (e.g., Status transitioned from Active_SIM to Failed or Promoting while modal was open). Ref: UC_4.10.4 §6, UC_4.10.3 §7. | "Something went wrong. Please reload for latest data." | Error |
| TE-DASH-02 | Time Extension 1-Click modal Pay click — server-side re-check detects Challenge_Extension_Days (Global Variables Table) or extension_fee (Table J) has changed since the modal opened. No charge created. Modal closes immediately, toast displays. Ref: UC_4.10.4 §5. | "Terms have been updated. Please click Extend Time to review the new terms." | Error |
| TE-JRN-01 | POST /journal-entries returns HTTP 400 — server-side validation rejects the payload (e.g. malformed date, rating outside the 1–5 range, notes exceeding the 500-char limit) despite passing client-side checks. Ref: UC_4.4 §BR_4.4.13. | "The server cannot understand the request. Please check your inputs and try again" | Error |
| TE-JRN-02 | GET /monthly-journal-data or POST /journal-entries returns HTTP 404 — requested resource/route not found. Edge case, not expected in normal navigation. Ref: UC_4.4 §BR_4.4.13. | "We couldn't load this data. Please refresh and try again" | Error |
| TE-JRN-03 | Shared system toast — any API call returns HTTP 503 (service temporarily unavailable — maintenance/overload). Not exclusive to Journal: currently surfaced by GET /monthly-journal-data / POST /journal-entries per UC_4.4 §BR_4.4.13, and reusable as-is by any other endpoint that returns 503 — no new ID needed per case. | "The service is temporarily unavailable. Please try again in a few minutes" | Error |
| TE-JRN-04 | GET /monthly-journal-data or POST /journal-entries returns HTTP 504 — gateway timeout, backend did not respond in time. Ref: UC_4.4 §BR_4.4.13. | "The request timed out. Please try again" | Error |
| TS-POD-01 | Community page — My POD card while discord_user_id IS NULL (trader not in a pod, or already assigned to a pod): the trader activates [Link Discord to Unlock]. Fired together with the highlight/pulse treatment on The PIT card's Link your Discord account first block, and on mobile with the smooth auto-scroll to that card. No modal and no navigation occurs. Ref: UC_4.14.2 §BR_4.14.2.3. | "Discord authentication is required for Pod routing." | Info |
| TS-CERT-01 | Career tab Latest certificate panel or the level certificate modal — the trader activates the Copy Link share target and the browser accepts the clipboard write. The URL copied is the Public Token URL, or the Redacted Token URL when the Redacted version toggle is ON. Not shown if the browser refuses the write. Ref: UC_4.16.1 §BR_4.16.1.15. | "Link copied to clipboard" | Success |
| TS-MDM-01 | Settings → Market Data Management → Add Saved Card succeeds — card entered in the add-card form, or Apple Pay / Google Pay. Ref: UC_4.17.1 §9.7 | "Payment method added successfully." | Success |
| TS-MDM-02 | Market Data Management → trader clicks [Resubscribe] on a feed paused by Flow 12 while still inside the paid month (no checkout, no charge) and POST /toggle-market-data succeeds. [FEED] = exchange name (CME, CBOT, NYMEX, COMEX). Ref: UC_4.17.1 §6.3 | "[FEED] data feed reactivated. Data may take a few minutes to resume." | Success |
| TS-MDM-03 | Action Required: Exchange Agreements Pending (OV-15) → trader clicks [Resend Instructions] and POST /resend-rtrader-instructions succeeds (Flow 39 emails the R|Trader Pro signing steps). The modal closes, then this toast fires at the top-right corner. Failure → TE-SYS-01. Ref: UC_4.17.1 §9.6 · UC_9.17 §1b | "Send instruction successfully, please check your mail." | Success |
| TE-MDM-01 | Market Data Management → Confirm Switch in CF-06 — the switch from card to Alternative Payment Method fails. Trader stays on the card. Ref: UC_4.17.1 §9.7 | "Failed to switch payment method. Please try again." | Error |
| TE-MDM-02 | Market Data Management → Delete in CF-05 — Delete Saved Card fails. Card stays in the list. Ref: UC_4.17.1 §9.7 | "Failed to delete card. Please try again." | Error |
| TE-MDM-03 | Market Data Management → Done in Change Payment Method / Change Payment Card with a card selected — Update Subscription Payment / setting is_default fails. Previous default kept. Ref: UC_4.17.1 §9.7 | "Failed to update default payment method. Please try again." | Error |
| TE-MDM-04 | Market Data Management → Add Saved Card returns HTTP 422 — the payment provider declines the method. Nothing added; form keeps its values. Ref: UC_4.17.1 §9.7 | "The payment provider declined this payment method. Please try another card." | Error |
| TE-MDM-05 | Market Data Management → Add Saved Card returns HTTP 409 — the card is already saved on the account. Nothing added; form keeps its values. Ref: UC_4.17.1 §9.7 | Title: "Card Already Added"Body: "This card is already saved to your account. Please select it from your existing payment methods or try adding a different card." | Error |
| TE-MDM-06 | Market Data Management → Add Saved Card fails for any reason other than 409 / 422 (5xx, timeout, network). Nothing added; form keeps its values. Ref: UC_4.17.1 §9.7 | "Failed to add payment method. Please try again." | Error |
| TE-MDM-07 | Market Data Management → POST /execute-checkout dedup check returns HTTP 409 — this feed was already paid for successfully. No charge. Ref: UC_4.17.1 Stage 2 | "This feed is already active on your account." | Error |
| TE-MDM-08 | Market Data Management → CTA click in Subscribe to Market Data — server-side re-check finds the feed price in Table C changed since the modal opened. No charge; modal closes. Ref: UC_4.17.1 Stage 2 | "The price of this feed has been updated. Please click Subscribe to review the new price." | Error |
2. Banners (BN)
Persistent, non-modal in-page messages. No auto-dismiss; cleared when the condition resolves.
| ID | Context | Banner Content | Type |
|---|---|---|---|
| BN-01 | POST /execute-checkout frontend session timeout (10-minute rule) — payment result not resolved within window. Also renders on FP-06 for the Dusupay/T365 full-page redirect flow when the 10-minute timeout elapses while the user is on that screen. | "Payment session expired. If you already submitted your payment, please check your email for confirmation. If you have not paid yet, please try again." | Error |
| BN-02 | CRM API fails on Waitlist form submit — UC_2.1.3 | "Unable to submit. Please try again" | Error |
| BN-03a | Post-payment 403 — refund in progress. Renders on the Service Unavailable screen while refund is being processed. Wireframe: User has paid --_ 403 or blacklist --_ refunding.png | "Your transaction is being refunded." | Info |
| BN-03b | Post-payment 403 — refund completed. Renders on the Service Unavailable screen after refund signal confirmed. Wireframe: User has paid --_ 403 or blacklist - refunded.png | "Your transaction is refunded." | Info |
| BN-05 | User clicks a "Claim Your Account" link that has already been claimed (credentials_claimed_at IS NOT NULL) — distinct from a time-based JWT expiry. Renders on a login screen (not the generic expired-link screen). Wireframe: Click a used Claim account link.png | "You have already claimed this account, please login." | Info |
| BN-06 | SIM provisioning or Auth0 account creation exhausts the backend auto-retry mechanism (3 attempts) and genuinely fails — Step 7 Phase 3 (Provisioning). Renders on the provisioning interstitial screen. Ref: UC_2.8.4 §6 Exceptional Flow / UC_2.8.2 §Step 3 Exception. Paired with dispatch of Ref: SES-23. | "A provisioning issue occurred. Please check your email for technical support details." | Error |
| BN-07 | POST /execute-checkout dedup check: provider_event_id already exists for this user_id — a previous payment for this order already succeeded (not triggered by a failed or still-in-progress payment — Ref: BR_2.8.1.5). Ref: UC_2.8.1 §5 step 6.0 / §6 Exceptional Flow — HTTP 409. | "You have an unclaimed account. Please check your email for your activation link." | Error |
| BN-08 | User clicks [Activate Account] twice in quick succession (e.g. the same claim link opened in two browser tabs) before the first click's request has finished. Renders on the current Phase 2 "Create an Account" screen (Ref: UC_2.8.3 §5) instead of the Phase 3 interstitial. | "This account has already been activated. Please try logging in — if your trading floor is still being set up, we'll notify you by email once it's ready." | Error |
| BN-09 | 1-Click modal CTA click (Path A) — NMI Customer Vault returns an expired card error code. Processing Payment popup closes → modal re-displayed with this banner. Canonical case row (applies to Time Extension, Reset, and Re-Buy 1-Click modals alike): UC_4.10.3 §6a — Card expired. CTA button label changes to "Change payment method" — on click → Path C (Secure Checkout). No charge created. No auto-fallback to Path B. | "Your saved card has expired. Please update your payment method in Account Settings." | Error |
| BN-10 | Second independent successful charge detected for the same user_id after an earlier charge already succeeded (user retried past the 10-minute timeout and both cleared) — Ref: BR_2.8.1.4 [CHR-21]. Renders on Step 6 (Payment) in place of the normal success transition. Ref: UC_2.8.1 §6 Exceptional Flow — Double-Payment Detected Post-Success. Main checkout (Phase 1) only — user has no account yet, copy below references the Claim Account link. | "It looks like you were charged twice for this order. Your duplicate payment will be refunded. Your account is still being created — please check your email for the Claim Account link." | Error |
| BN-11 | Double Payment on an in-dashboard 1-Click Modal / Secure Checkout purchase (Reset, Re-Buy, Time Extension) — user ignores the 10-minute timeout warning, retries, and both the original (delayed) payment and the retry payment clear via webhook. Same underlying mechanism as BN-10 (Ref: BR_2.8.1.4 [CHR-21]) but the user already has an active account — no Claim Account link applies. Ref: UC_4.10.3 §6a — Double Payment. | "It looks like you were charged twice for this purchase. Your duplicate payment will be refunded." | Error |
| BN-12 | On the FP-06 "Verifying Your Payment..." screen — backend confirms PAYMENT_RESULT = failure (genuine decline) for the Dusupay/T365 full-page redirect attempt. Paired with a [Return to Payment page] button that navigates back to Step 6 (Ref: UC_2.8.1 §5 outcome 7c). | The raw decline reason returned by Dusupay/T365 for this attempt (same convention as UC_2.8.1 §5 step 8.3). | Error |
| BN-13 | User attempts to pay via T365 or Dusupay, but the transaction amount exceeds the provider's maximum transfer threshold. Renders on the FP-06 screen and is paired with a [Return to Payment page] button that navigates back to Step 6. Ref: UC_2.7.7 §4 / UC_2.7.9 §5. | "Your transaction has exceeded the maximum transfer amount allowed. Please contact the support team if you believe this is an error." | Error |
| BN-14 | User attempts to pay via T365, but the transaction amount is below the provider's minimum transfer threshold. Renders on the FP-06 screen and is paired with a [Return to Payment page] button that navigates back to Step 6. Ref: UC_2.7.9 §5. | "Your transaction is below the minimum transfer amount allowed. Please contact the support team if you believe this is an error." | Error |
| BN-15 | Backend fails to receive a response from Dusupay or T365 within 30 seconds when initiating the payment at POST /execute-checkout. The request is automatically failed and aborted before redirect. Renders on the FP-06 screen and is paired with a [Return to Payment page] button that navigates back to Step 6 — same pattern as BN-13/BN-14. Ref: UC_2.7.7 §4 / UC_2.7.9 §5. | "Unable to connect. Please check your network and try again" | Error |
| BN-16 | Step 5 Email onBlur — Duplicate Account Check: existing record status IN ('Failed','Terminated') AND cart asset_class mismatches the record's persisted asset_class (HTTP 409 from POST /capture-lead, Step B). Renders at the top of the Step 5 screen (persistent, non-modal). Ref: BR_2.6.2.11. | "Your email is linked to an existing [Profile Asset Class] account. You cannot switch asset classes on a reset. Please change your selection to match your account, or log in to your dashboard to reset your evaluation." [Profile Asset Class] = "Futures" / "Forex" per the existing record's asset_class. | Error |
| BN-17 | Step 5 Email onBlur — Duplicate Account Check: existing record status IN ('Failed','Terminated'), cart asset_class matches the record's persisted asset_class, but cart product_id (Step 2 package selection) mismatches the record's persisted current_level (HTTP 409 from POST /capture-lead, Step B). Renders at the top of the Step 5 screen (persistent, non-modal). Ref: BR_2.6.2.12. [CHR-118] | "Your current account is linked to [Evaluation package]. You cannot switch your package on a reset. Please change your selection to match your account, or log in to your dashboard to reset your evaluation." [Evaluation package] = "Associate Track" / "Accelerated Associate Track" / "Advanced Associate Track" per the existing record's current_level. | Error |
| BN-18 | Step 5 Email onBlur — Duplicate Account Check: existing record role_flag = 'Founding_Mentor' AND cart asset_class mismatches Pod_Leader_Registry.Asset_Class declared in the Flow 1.5 Typeform (HTTP 409 from POST /capture-lead, Step B). Renders at the top of the Step 5 screen (persistent, non-modal). Ref: UC_8.2.13 BR_8.2.13.25. [CHR-145] | "Your Founding Mentor profile is registered for [Profile Asset Class]. Please change your asset class selection to match your profile to continue." [Profile Asset Class] = "Futures" / "Forex" per Pod_Leader_Registry.Asset_Class. | Error |
| BN-19 | Step 5 Email onBlur — Duplicate Account Check: existing record role_flag = 'Founding_Mentor', asset class matches, but cart product_id (Step 2 package selection) is not EVAL_L1 (HTTP 409 from POST /capture-lead, Step B). Renders at the top of the Step 5 screen (persistent, non-modal). Ref: UC_8.2.13 BR_8.2.13.26. [CHR-145] | "Your Founding Mentor coupon applies to the Associate Track only. Please select the Associate Track to continue." | Error |
| BN-20 | Step 5 Email onBlur — Duplicate Account Check: existing record role_flag = 'Founding_Mentor' AND Pod_Leader_Registry.Asset_Class IS NULL (Flow 1.5 Step 9 Typeform not yet submitted) (HTTP 409 from POST /capture-lead, Step B). Renders at the top of the Step 5 screen (persistent, non-modal). Ref: UC_8.2.13 BR_8.2.13.25. [CHR-145] | "Please complete your Founding Mentor profile form before checking out." | Error |
3. Blocking Overlays / Popups (OV)
Distinction:
- Popup: Replaces the current screen content entirely. No background visible.
- Overlay: Renders on top of the existing screen with a dimmed background.
Close icon [✕]: All OV entries have a [✕] icon at the top-left corner, except where explicitly noted as exception. On close → user returns to the screen that triggered the overlay/popup.
User must act via the button(s) listed. Overlay copy inside Quebec (Flow D) checkout must render in French, including error messages (STAGE1-020) — see §7.
Note on OV-04: Since the Waitlist Gate moved from an overlay-on-checkout-page to a dedicated Waitlist page (Ref: UC_2.1.3), OV-04 no longer renders as a blocking popup/overlay over another screen — its success content simply replaces the form content within the Waitlist page, with the page's own Header/Footer untouched. Listed as Type "Page state" (not Popup/Overlay) to reflect this; all other OV-01–OV-08 entries remain true Popup/Overlay per the distinction above.
| ID | Trigger | Content | Button | Type |
|---|---|---|---|---|
| OV-01 | GET /public/platform-options returns empty array (all platforms inactive) — Step 3 | Title: "Trading platforms are temporarily unavailable"Body: "Trading platforms are temporarily unavailable. Please refresh or try again shortly." (Source: QnA STAGE1-011) | Return to Homepage (none — no close icon) | Popup |
| OV-02 | methods[] from /system/status empty (all payment rails down) — Step 6 | Title: "Payment methods are unavailable"Body: "Payment processing is temporarily undergoing maintenance. Please refresh or contact our support team." | Return to Homepage (none — no close icon) | Popup |
| OV-03 | 5 consecutive payment declines in a rolling 10-min window (all methods). 15-min block tracked by email address (Redis); direct API → 429. Ref: CR-20260728-002. | Title: "Transaction locked"Body: "Transaction locked due to multiple failures. Please use an alternative payment rail or check with your bank." | Return to Homepage (none — no close icon) | Popup |
| OV-04 | Waitlist Lead Capture Form submitted successfully (allow_signups == FALSE) — UC_2.1.3. Renders as a page-content state on the dedicated Waitlist page (not an overlay/popup over another screen) — Header/Footer chrome around it is unaffected. | Title: "THANK YOU / ACCESS GRANTED"Body: "Your request has been successfully registered. You are now on the priority waitlist." | Return to Homepage | Page state |
| OV-05 | User clicked pay; payment verification in progress — Step 7 Phase 1 | Gold spinner + "Please do not refresh the page or click the back button. This may take a few moments." | (none — no close icon; submit disabled to prevent double charge) | Popup |
| OV-06 | Payment cleared; transitioning to Phase 2 (account claim) — Step 7 Phase 1 | Header: "Payment Successful" Gold checkmark icon.Auto-dismisses after 2 seconds → checkout transitions to confirmation state. | (none — no close icon; auto-dismiss after 2 s) | Popup |
| OV-07 | SIM provisioning or Auth0 account creation exhausts the backend auto-retry mechanism (3 attempts) and genuinely fails. Covers: Auth0 account creation failure (Ref: UC_2.8.3 §5) AND SIM provisioning / Auth0 failure at the Phase 3 provisioning interstitial (Ref: UC_2.8.4 §6) AND SIM provisioning failure on Reset/Re-Buy after payment already succeeded, including repeat CTA clicks on the Hard Breach Popup while the prior failure is unresolved (Ref: UC_4.10.3 §7 Exceptional Flow). Paired with dispatch of Ref: SES-23. | Header: "Account Creation Failure"Body: "Payment Successful. We are experiencing a temporary delay generating your secure dashboard login. Our Operations team has been alerted and will email your access link shortly." | (none — no close icon) | Overlay |
| OV-08 | Step 6 Pay click: server-side price/tax re-check detects price has changed — e.g. Founder cohort slot filled up reverting to Standard pricing, or tax rate changed since POST /calculate-cart. No charge created, no promo reserved. Ref:BR_2.1.5.2 | Title: "Please refresh to get the latest price"Body: "The pricing for this package has just been updated. Please refresh the page to see the latest price before continuing." | Refresh now — closes this overlay and refreshes the Order Summary with the updated price/tax. No page reload. (none — no close icon) | Popup |
| OV-09 | Settings → Profile & Preferences → a profile-photo commit is in flight (on success it closes and TS-DASH-01 is raised): the trader clicked [Done] in the Crop Image modal (signed URL → PUT to S3 → PATCH /profile-photo), or [Confirm] in CF-03 (PATCH /profile-photo with profile_photo_url: null). Ref: UC_4.6.2 §6 Alternative Flow A / BR_4.6.2.6. | Gold spinner + "Updating avatar..." | (none — no close icon; dismissed by the system on success or failure. On failure the previous avatar is restored and the matching error toast is shown) | Popup |
| OV-10 | User clicked pay via a NMI-routed method only (Credit Card / Apple Pay / Google Pay, Ref: UC_2.8.1 outcome 7a) — Step 7 Phase 1. Renders first, then transitions to OV-05 once the NMI card-verification step returns. Does NOT apply to Crypto, Bank Transfer, Dusupay, or T365. | Gold spinner + "Verifying your card with your bank" | (none — no close icon; submit disabled to prevent double charge) | Popup |
| OV-11 | 4 minutes have elapsed since the provisioning-status polling call first fired on the Phase 3 interstitial. Shown only once per provisioning attempt — once dismissed, does not re-trigger on refresh or re-entry via the claim link. Checkout flow only — does NOT apply to Reset or Re-Buy. [CHR-88] | Title: "Account creation in progress"Body: "Your account is currently being provisioned. You may stay on this page and wait, or safely navigate away. We will email you as soon as the setup is complete." | Keep waiting — dismisses the overlay; stays on the interstitial. If the session token has already arrived by click time, redirects straight to the Auth0 login screen instead. Return to Homepage (none — no close icon) | Popup |
| OV-12 | Market Data Management → POST /execute-checkout returns success from the Subscribe to Market Data modal. Ref: UC_4.17.1 §9.5 row 1 | Tick icon.Title: "Subscription Confirmed"Body: "[FEED] Level 2 is now active on your account." · "Next charge of $[Total] on [MMM DD, YYYY], covering [next month]." — date = EOM−3 (card) or EOM−7 (APM)Note: "Feed activation may take a few minutes. If prompted, sign the exchange agreement in R|Trader Pro to complete setup." | Back to Market Data — closes and refreshes the tab. (none — no close icon) | Overlay |
| OV-13 | Market Data Management → POST /execute-checkout returns a charge error. Ref: UC_4.17.1 §9.5 row 2 | Warning icon.Title: "Payment Failed"Body: card → "We couldn't charge your card ending in [last4]." · APM → "We couldn't complete your payment via [method name].", then "No subscription was created and you have not been charged." | Card → Try another card (opens Change Payment Card) · APM → Try again (back to the Subscribe modal) · Cancel. (none — no close icon) | Overlay |
| OV-14 | Market Data Management → Cancel Subscription returns success after CF-04. Ref: UC_4.17.1 §9.5 row 4 | Tick icon.Title: "Subscription Cancelled"Body: "[FEED] Level 2 will remain active until [MMM DD, YYYY]." · "After that date the feed will be disabled." · "You can subscribe again from [MMM DD, YYYY]" | Back to Market Data — closes and refreshes the tab. (none — no close icon) | Overlay |
| OV-15 | Futures trader opens or navigates to the "Command" tab while CME Market Data Agreements are unsigned (Signed_Completely is not Yes). Shown on every visit to the Command tab while the condition holds; dismiss stores no state — it reappears on the next visit. Stops once Signed_Completely = Yes. (Source: Flow 39 update 2026-11-05) Ref: UC_4.17.1 §9.6 · UC_9.17 §1b | Title: "Action Required: Exchange Agreements Pending"Body: "You must log into the R|Trader Pro desktop terminal to digitally sign your CME exchange agreements. Your data feeds cannot activate until this step is complete." | Resend Instructions — calls POST /resend-rtrader-instructions; on success modal closes and TS-MDM-03 fires; on 429/422 inline error shown inside modal, modal stays open. · Cancel — closes the modal; no API call; modal reappears on next visit to the Command tab while agreements remain unsigned. (none — no close icon) | Overlay |
| OV-16 | Market Data Management → trader returns from the APM provider's page (Dusupay / T365) after paying; shown over the Market Data Management tab until the payment result arrives. Ref: UC_4.17.1 §9.5 row 8 | Gold spinner.Title: "Processing payment..."Body: "We are waiting for the final confirmation from your payment provider. This usually takes a few seconds. Please do not refresh the page." | (none — no close icon; closes on result: success → OV-12, failure → OV-13) | Overlay |
4. Full-Page Blocks (FP)
Not toasts. Full-screen block / error pages.
| ID | Trigger | Content | Button |
|---|---|---|---|
| FP-01 | Page not found (404) | Title: "Page Not Found"Body: "The server cannot find the requested page. If you believe this to be an error, please review our FAQ." | Return to Homepage |
| FP-02 | Sanctioned region — Gate 2 / Flow F (HTTP 403 at page load)Refer design: References\Wireframe\Stage 1\Flow F Gate 2 - Geoblock (Absolute).png | "Service Unavailable — Stack Trading's evaluation services are not available in your region due to regulatory restrictions. We are unable to process registrations or accept payments from your current location. If you believe this is an error, please contact support@stacktrading.com with your location details." | Return to Homepage |
| FP-03 | Server error (500) | Title: "Something Went Wrong"Body: "Your request could not be processed. Please try again. The server encountered an unexpected condition that prevented it from fulfilling the request." | Return to Homepage |
| FP-04 | Bad request (400) | Title: "Bad Request"Body: "The server cannot understand the request due to bad syntax or malformed request. If you believe this to be an error, please review our FAQ." | Return to Homepage |
| FP-05 | Link invalid (e.g. user changes the token). Ref: UC_2.8.3 §5. | Title: "Invalid Link"Body: "This activation link is no longer valid. Please contact support if you need help." | Return to Homepage |
| FP-06 | Dusupay/T365 hosted page redirects back (Return URL) after the user completes the payment attempt — Ref: UC_2.8.1 §5 outcome 7c. | Title: "Verifying Your Payment..." (gold script-style heading)Body: "We are waiting for the final confirmation from your payment provider. This usually takes a few seconds. Once completed, we will automatically redirect you to the Activate Account page. Please do not close this window or refresh the page."Gold spinner. On failure, a banner renders on this same screen — a genuine decline uses BN-12, a 10-minute timeout uses BN-01, a transfer-amount limit breach uses BN-13/BN-14, and a 30s provider-initiation timeout uses BN-15. | (none while waiting) |
5. Inline Errors & Hard Stops (IN)
Not toasts. Red inline messages anchored under a field / in-page.
| ID | Trigger | Content | Button |
|---|---|---|---|
| IN-01 | POST /calculate-cart returns 403 at Step 5 (VPN / restricted billing country) | Inline red warning:"Due to regulatory restrictions, Stack Trading cannot accept clients from this jurisdiction." | (none — hard stop; auto-clears when valid country selected) |
| IN-02 | Step 5 EmailonBlur — Blacklist Check match (HTTP 403 from POST /capture-lead, Step A). STAGE1-083. | "Account restricted. Please contact support." (does not reveal blacklist reason) | (none — hard stop; [Next] disabled until email is edited to a value that clears the check) |
| IN-03 | Step 5 EmailonBlur — Duplicate Account Check: existing record status = 'Active_SIM' or 'Active_DMA' (HTTP 409 from POST /capture-lead, Step B). STAGE1-084. | "You already have an active account." | (none — hard stop; [Next] disabled until email is edited to a value that clears the check) |
| IN-04 | Step 5 EmailonBlur — Duplicate Account Check: existing record status = 'Guest' AND provider_event_id IS NOT NULL (paid, not yet claimed — HTTP 409). STAGE1-084. | "You have an unclaimed account. Please check your email for your activation link." | (none — hard stop; [Next] disabled until email is edited to a value that clears the check) |
| IN-05 | Step 5 Confirm EmailonBlur — value does not match the Email field (valid format, but different from Email). Ref: BR_2.6.1.7. | "Emails do not match." | (none — error; auto-clears when values match) |
| IN-07 | Step 5 Confirm EmailonBlur — value is not a valid email format (fails CR-09 §9.1 format validation). Ref: BR_2.6.1.7. | "Please enter a valid email address." | (none — error; auto-clears when valid format entered) |
| IN-06 | Phone onBlur / on submit, or Country Code dropdown change — Duplicate Phone Number Check (HTTP 409, same-country scope: dial code + number must both match). Shared by every phone field in the system: Phase 2 Account Claim (POST /claim-account — Ref: BR_2.8.3.4) and Settings → Profile & Preferences (PATCH /profile — Ref: BR_4.6.2.4). | "This phone number is already registered to another account." | (none — hard stop; the screen's primary button — [Activate Account] / [Save Changes] — stays disabled until the phone number is edited to a unique value) |
| IN-08 ⛔ RETIRED 2026-08-24 | IN-08 in new docs. Ref: BR_4.6.2.3. | (none — error; [Save Changes] disabled until the value passes) | |
| IN-09 ⛔ RETIRED 2026-08-24 | IN-09 in new docs. Ref: BR_4.6.2.4. | (none — hard stop; [Save Changes] disabled until phone is edited to a unique value) | |
| IN-10 | Settings → Profile & Preferences → on [Save Changes] — the backend finds the submitted phone number identical to the account's current one. Not evaluated on onBlur. Ref: BR_4.6.2.5. The only Settings-specific phone string that survives — neither CR-09 §9.2 nor the checkout block has a counterpart, because the checkout phone field has no "currently saved" value to compare against. | "The new phone number cannot be the same as your current one" | (none — error; [Save Changes] disabled until the trader edits the number) |
| IN-11 | Step 5 Email onBlur OR Confirm Email onBlur — value's domain is @stacktrading.com (Ref: BR_2.6.1.10). CR-20260815-001. | "Stacktrading email addresses are not allowed for this field" | (none — hard stop; [Next] disabled until the field is edited to a non-blocked domain) |
| IN-12 | Step 5 [Next] click — POST /calculate-cart backend Address Validation Gate returns HTTP 400 for billing_country IN ('US','CA'): Google Address Validation API flags a mismatch among State/Province, City, and ZIP / Postal Code (Ref: BR_2.6.1.12). [CHR-87] | "ZIP code does not match the billing address. Please enter the correct ZIP code" | (none — hard stop; [Next] re-enabled once ZIP is edited to a value that passes validation) |
| IN-14 | Forumpay crypto payment — Modal 2 (QR code, State B) is open and awaiting PAYMENT_RESULT when Forumpay returns an explicit underpayment error (user sent less than the required amount). Renders in-modal, anchored under the QR code section; Modal 2 stays open — does not close or revert to Modal 1. Treated as a Failed transaction. Ref: UC_2.7.5 §6 Exceptional Flow — Underpayment. Transaction canceled; Forumpay auto-emails the user refund-claim instructions directly. | "Your payment could not be completed because the amount sent was less than required. You will receive an email to claim a refund, or you can send the remaining amount to make this transaction successful." | (none — user may close the modal manually per the existing [User closes modal while payment is processing] case) |
| IN-15 | Forumpay crypto payment — the rate-lock window closes (Modal 2 Timer Expired, State C — 30 minutes for stablecoins, 15 minutes for non-stablecoins, Ref: BR_2.7.5.6). This alert always renders once the window closes, regardless of whether the user already sent funds: if funds were sent before the window closed, Forumpay may still confirm the payment as Successful (Passed) even though this alert is shown; if the user sends funds after the window closed, Forumpay returns an explicit late-payment error and the transaction is automatically treated as Failed & Canceled. Ref: UC_2.7.5 §6 Exceptional Flow — Late Payment. For the Failed & Canceled case, Forumpay auto-emails the user refund-claim instructions directly. | "Time is expired. Please reload to get the latest crypto amount due. If you made the transaction before the timer expired, it may still complete successfully — please wait. If you send funds after the timer has expired, the transaction will fail and you will receive a refund via email." | [Reload] — fetches a new rate and restarts the countdown (30 minutes for stablecoins, 15 minutes for non-stablecoins); re-enters Modal 2's QR code state (State B) |
| IN-PROMO-01 | Promo code applied successfully — inline text below promo input field at Step 6 (UC_2.7.8) | "Promo code applied!" | (none — success; disappears when user edits the input field) |
| IN-PROMO-02 | Promo code invalid or expired (HTTP 422) — inline text below promo input field at Step 6 (UC_2.7.8). Also shown if code is re-validated at POST /execute-checkout and fails. | "Invalid promo code. Please check and try again" | (none — error; cleared when user edits the input field) |
| IN-PROMO-03 | User has exceededmax_uses_per_user for this promo code (HTTP 422 with per-user limit signal) — inline text below promo input field at Step 6 (UC_2.7.8). | "You have already used this promo code the maximum number of times allowed." | (none — error; cleared when user edits the input field) |
| IN-PROMO-04 | Applied promo code fails re-validation atPOST /execute-checkout time (expired or limit exhausted by another user between Apply and Pay) — inline text below promo input field at Step 6 (UC_2.7.8). Formerly OV-08 (overlay); converted to inline banner pattern. | "This promo code has expired or has already been used. Please apply a different code or continue without a promo code." | [Remove] — manual button; clears the input and re-enables [Apply]. Input is NOT auto-cleared. |
| IN-PROMO-05 | Promo code is valid but its mapped product_id does not match the product_id in the cart — checked at [Apply] click (POST /calculate-cart, HTTP 422), same timing as IN-PROMO-02. Inline text below promo input field at Step 6 (UC_2.7.8), and on the Reset/Re-Buy modals (UC_4.10.3 §6 / UC_4.15.3 §6). Ref: UC_2.7.8 BR_2.7.8.7. [CHR-55] | "Invalid promo code for this product" | (none — error; cleared when user edits the input field) |
Field-level validation errors (required, format, max/min length) follow CR-01 · CR-02 · CR-03 — not listed here.
6. Confirmation Popups (CF)
| ID | Title / Trigger | Content | Buttons |
|---|---|---|---|
| CF-01 | Unsaved changes navigation warning | "Are you sure you want to leave this page? Unsaved changes will be lost." | Cancel / Leave |
| CF-02 | Settings → Connections & Credentials → trader clicks [Password Reset] on the Assigned Password row. Ref: UC_4.6.1 §5 step 9 / BR_4.6.1.5. | ⚠️ BA draft, wording pending client sign-off ([CC-UI-02]): "You'll be taken to your trading platform's own password reset page. StackTrading does not perform the reset and does not store the new password — the Assigned Password shown here will not change."🔴 The former client-verbatim string "This will instantly overwrite your current platform password and generate a new one. You will be logged out of active sessions." is withdrawn 2026-08-21 — Confirm no longer overwrites or generates anything. | Cancel / Confirm — Confirm calls POST /reset-platform-password, which returns the gateway's own reset-page destination; the frontend opens it in a new tab. No StackTrading write. ⚠️ No reset URL has been supplied for any gateway yet. |
| CF-03 | Settings → Profile & Preferences → trader clicks [Remove Photo]. Required because the removal commits immediately and is not reversible via [Cancel] — the stored S3 object is hard-deleted. Ref: UC_4.6.2 §6 Alternative Flow B / BR_4.6.2.14. | Title: "Remove your photo?"Body: (none — title only) | Confirm / Cancel — stacked vertically, Confirm on top (Primary/gold), Cancel below (Secondary). Confirm calls PATCH /profile-photo with profile_photo_url: null; Cancel closes the popup and changes nothing |
| CF-04 | Market Data Management → trader clicks [Unsubscribe] on an Active feed card (never CME). Ref: UC_4.17.1 §9.5 row 3 | Title: "Unsubscribe from [FEED] Level 2?"Sub-text: "Your feed stays active until [MMM DD, YYYY] - the end of your current billing month"Body: "You won't be charged again. No refund is issued for the current month." · "You can subscribe again from [MMM DD, YYYY]." | Unsubscribe — calls Cancel Subscription → OV-14 / Keep Subscription — closes, no change |
| CF-05 | Market Data Management → Change Payment Method / Change Payment Card → trader clicks [Delete] on any saved card, whether or not it funds a subscription. Ref: UC_4.17.1 §9.5 row 6 | Title: "Delete this payment card?"Sub-text: "[BRAND] Ending in [last4] · Expires [MM/YY]" | Delete — Delete Saved Card; failure → TE-MDM-02 / Cancel — closes, card untouched |
| CF-06 | Market Data Management → Change Payment Method → trader clicks [Done] with Alternative Payment Method selected while on automatic card billing. Ref: UC_4.17.1 §9.5 row 7 | Title: "Switch to Manual Billing?"Sub-text: "Your market data is currently renewed automatically."Body: "By switching to a manual payment method, you must actively pay your invoice before the end of each calendar month. If an invoice remains unpaid by the last day of the month, your live data feeds will be disabled." | Confirm Switch — moves the trader to manual billing; failure → TE-MDM-01 / Keep Automatic — closes, card unchanged |
7. Localization — Quebec / Flow D (French)
| Scope | Rule |
|---|---|
| Checkout UI (Flow D) | Rendered natively in French. |
| Error messages inside French checkout | Must be translated to French (OV-01…OV-04, IN-01, BN-, TE- shown within checkout). |
| Canada outside Quebec | Defaults to Flow A (English). |
8. Changelog
| Date | Version | Updated item | Before | After | Notes |
|---|---|---|---|---|---|
| 2026-11-08 | v3.45 | TS-MDM-03 (copy + trigger); OV-15 (trigger + button behaviour) | TS-MDM-03: modal described as closing; toast text "Instructions sent. Please check your email." OV-15: trigger said "at most once per login; not reopened in the same session once closed"; Resend button said only POST /resend-rtrader-instructions → Flow 39, no explicit success/failure UX. | TS-MDM-03: toast text updated to Figma-confirmed copy "Send instruction successfully, please check your mail."; trigger description adds that modal closes first then toast fires, with explicit Failure → TE-SYS-01 note. OV-15: trigger updated — modal shown on every Command tab visit while unsigned, not once per login (per Flow 39 update 2026-11-05); Resend button now specifies on success modal closes → TS-MDM-03 fires; on 429/422 inline error shown inside modal (modal stays open). | Client Figma (node-id=26316-62224) confirmed UX 2026-11-08. Companion change: UC_9.17.md v1.5. |
| 2026-10-31 | v3.44 | IN-15 copy + description (Forumpay Timer Expired alert) | Described the rate-lock window as a flat 15 minutes; copy only said a refund follows "if you have made transaction," without distinguishing funds sent before vs. after expiry. | Description now notes the window is 30 minutes for stablecoins / 15 minutes for non-stablecoins (Ref: BR_2.7.5.6). Copy updated: "Time is expired. Please reload to get the latest crypto amount due. If you made the transaction before the timer expired, it may still complete successfully — please wait. If you send funds after the timer has expired, the transaction will fail and you will receive a refund via email." | Client instruction, 2026-10-31. Companion change: UC_2.7-2.8_v1.md v4.22 (new BR_2.7.5.6, Late Payment case split into before/after-expiry outcomes). |
| 2026-10-30 | v3.43 | BN-18, BN-19, BN-20 (new) [CHR-145] | No checkout banner for Founding Mentor asset class / package / profile mismatches. | Added BN-18 (cart asset class ≠ Typeform Asset_Class), BN-19 (package ≠ EVAL_L1), BN-20 (Typeform profile not submitted). All persistent top-of-Step-5 banners, modeled on BN-16/17. | CHR-145 (BA 2026-10-30). Companion change: UC_8.2.13_v1.md v2.6 (BR_8.2.13.25/26). |
| 2026-10-26 | v3.42 | IN-14 copy (underpayment) | "Your payment could not be completed because the amount sent was less than required. You will receive an email to claim a refund." | "Your payment could not be completed because the amount sent was less than required. You will receive an email to claim a refund, or you can send the remaining amount to make this transaction successful." | Client instruction, 2026-10-26. Companion change: UC_2.7-2.8_v1.md v4.21 (UC_2.7.5 §6 Underpayment case). |
| 2026-10-19 | v3.41 | IN-13 → BN-16, IN-16 → BN-17 (pattern correction) | Both the Asset Class Match Check message (IN-13) and the new Evaluation Package Match Check message (IN-16, added at v3.40) were modeled as inline field-level errors — but both are account-state conflicts unrelated to any single field, so they render as persistent top-of-screen banners instead, matching the BN pattern used elsewhere for Duplicate Account Check halts. | Removed IN-13 and IN-16. Added BN-16 (same copy as former IN-13, Ref: BR_2.6.2.11) and BN-17 (same copy as former IN-16, Ref: BR_2.6.2.12, [CHR-118]). No copy changes — IDs and section only. | User correction, 2026-10-19. Companion change: UC_2.1-2.6_v1.md v37 (IN-13/IN-16 refs updated to BN-16/BN-17). |
| 2026-10-19 | v3.40 | IN-16 (new) | Duplicate Account Check's Failed/Terminated branch only checked asset class (IN-13) — a returning user could pass that check but reset into a different Evaluation Package tier than their existing account. | Added IN-16 "Your current account is linked to [Evaluation package]. You cannot switch your package on a reset. Please change your selection to match your account, or log in to your dashboard to reset your evaluation." — fires when cart product_id (Step 2) mismatches the existing record's current_level, checked after the asset-class match passes. | Client requirement (chat), 2026-10-19. Tagged [CHR-118]. Companion change: UC_2.1-2.6_v1.md v36 (new BR_2.6.2.12). ⚠️ Superseded by v3.41 same day — IN-16 renumbered to BN-16. |
| 2026-10-15 | v3.39 | TE-MDM-07, TE-MDM-08, OV-16 (new) | Market Data had no message for a duplicate purchase, a price change at CTA click, or the APM return screen. | Added TE-MDM-07 "This feed is already active on your account." · TE-MDM-08 "The price of this feed has been updated. Please click Subscribe to review the new price." · OV-16 "Processing payment..." popup over the Market Data Management tab | Companion change: UC_4.17.1 v16. |
| 2026-10-13 | v3.38 | TS-MDM-03 (new) | Resend Instructions success had no registered toast. | Added TS-MDM-03 "Instructions sent. Please check your email." | Companion change: UC_4.17.1 v13. |
| 2026-10-13 | v3.37 | TS-MDM-02 (new) | Free Resubscribe on Market Data Management had no registered success toast. | Added TS-MDM-02 "[FEED] data feed reactivated. Data may take a few minutes to resume." | Companion change: UC_4.17.1 v12. |
| 2026-10-13 | v3.36 | TS-MDM-01, TE-MDM-01…06, OV-12…15, CF-04…06 (new) | Settings → Market Data Management toasts and popups were written inline in UC_4.17.1 with no registry ID. | Registered: TS-MDM-01 (method added) · TE-MDM-01 switch failed · TE-MDM-02 delete failed · TE-MDM-03 default update failed · TE-MDM-04 422 provider declined · TE-MDM-05 409 Card Already Added · TE-MDM-06 other add failure · OV-12 Subscription Confirmed · OV-13 Payment Failed · OV-14 Subscription Cancelled · OV-15 Action Required: Exchange Agreements Pending · CF-04 Unsubscribe · CF-05 Delete this payment card? · CF-06 Switch to Manual Billing? | Companion change: UC_4.17.1 v11. |
| 2026-10-08 | v3.35 | IN-14, IN-15 (new) | No inline error distinguished Forumpay (formerly Triple-A) Underpayment or Late Payment from a generic decline inside Modal 2 — Underpayment fell through to the raw-error-message toast, and Late Payment had no refund-claim mention in its Timer Expired inline alert. | Added IN-14 — in-modal underpayment error on Modal 2 (QR code state), without closing it: "Your payment could not be completed because the amount sent was less than required. You will receive an email to claim a refund." Added IN-15 — late-payment error replacing the Timer Expired inline alert, with a refund-email line appended: "Time is expired. Please reload to get the latest crypto amount due. If you have made transaction, you will get a refund via email.", paired with the existing [Reload] button. Both tied to the Forumpay rebrand; Forumpay auto-emails the user refund-claim instructions directly — our system sends no refund email itself. Overpayment is unchanged — it is a success outcome (OV-06, no new entry). | Client instruction, 2026-10-08 — Triple-A → Forumpay rebrand, same UI/UX, rate-lock window shortened 25min → 15min. Companion change: UC_2.7-2.8_v1.md (UC_2.7.5 §6/§7, new BR_2.7.5.5). Supersedes CR-20260810-001; new CR: CR-20261008-001. |
| 2026-10-03 | v3.34 | OV-11 (new) | Did not exist. Phase 3 "Setting up your trading floor" interstitial (Ref: UC_2.8.4) had no timeout and no user-facing messaging while waiting. | Added OV-11 "Account creation in progress" — fires 4 minutes after the provisioning-status polling call first fired, shown once per attempt (no re-trigger on refresh or re-entry). Keep waiting dismisses and stays on the interstitial (or redirects to Auth0 login if provisioning already completed by click time); Return to Homepage navigates to the home page. Checkout flow only — does not apply to Reset or Re-Buy. | Client requirement (chat). Tagged [CHR-88]. Companion change: UC_2.7-2.8_v1.md (new version) — UC_2.8.4 §5/§7 new BR_2.8.4.3. |
| 2026-09-28 | v3.33 | OV-10 (new) | Did not exist. Step 7 Phase 1 went straight from Pay click into OV-05 (generic "payment verification in progress") for every method, including NMI-routed ones (Credit Card / Apple Pay / Google Pay). | Added OV-10 — gold spinner + "Verifying your card with your bank", rendered before OV-05 and only for NMI-routed methods (Credit Card / Apple Pay / Google Pay, Ref: UC_2.8.1 outcome 7a). Transitions into the existing OV-05 once the NMI card-verification step returns. Does not apply to Crypto, Bank Transfer, Dusupay, or T365 — those are unchanged. | User instruction, 2026-09-28. Companion change: UC_2.7-2.8_v1.md v4.14 (UC_2.8.1 §5 outcome 7a, UC_2.7.3 §3 Case C, UC_2.7.4 §3 Case C). |
| 2026-09-23 | v3.33 | IN-10 (trigger) | Trigger read "Phone onBlur / on submit — the submitted E.164 value is identical to the currently saved one", i.e. the check was described as running client-side when the trader left the field. Button column read "[Save Changes] disabled until the value differs". | Trigger is now [Save Changes] only — the backend compares the submitted number against the stored one; nothing is evaluated on onBlur. Button column reads "[Save Changes] disabled until the trader edits the number". | BA instruction 2026-09-23. Copy unchanged. IN-10 is used only by Settings → Profile & Preferences, so no other UC is affected. Companion change: UC_4.6.2_v1.md v17 (BR_4.6.2.5, §7 row 6). ⚠️ IN-06 carries the same stale onBlur trigger for the Settings screen, but it is shared with checkout (UC_2.8.3, another BA's UC) and is therefore left unchanged. |
| 2026-09-27 | v3.32 | OV-07 (trigger description extended, no content change) | OV-07's Ref list only cited UC_2.8.3 §5 and UC_2.8.4 §6 (onboarding-context provisioning failure); did not mention the Reset/Re-Buy context, even though the same overlay is reused there. | Extended OV-07's trigger description to also cite UC_4.10.3 §7 Exceptional Flow — SIM provisioning failure on Reset/Re-Buy after payment already succeeded, including repeat CTA clicks on the Hard Breach Popup while the prior failure is unresolved. Header/Body/behaviour unchanged — reused the existing overlay instead of UC_4.10.3 defining a duplicate new modal/section. | User instruction, 2026-09-27. Companion: UC_4.10.3_v1.md v4.10. |
| 2026-09-23 | v3.31 | TE-DASH-02 (new) | Did not exist. Challenge_Extension_Days (Global Variables Table) had no re-validation gate at Time Extension Pay click — only extension_fee/tax is re-checked via the shared price-lock mechanic (UC_4.10.3 §6/OV-08). | Added TE-DASH-02 "Terms have been updated." — fires when the backend re-check at Pay click detects Challenge_Extension_Days or extension_fee changed since the Time Extension modal opened. Modal closes immediately, toast displays, user returns to Dashboard (toast copy does not instruct a re-click); if the user wants the new terms they re-open "Extend Time", which naturally re-runs POST /calculate-cart. | Client direct instruction, 2026-09-23 — variable re-validation at checkout for Time Extension. Companion change: UC_4.10.4_v1.md v1.5 (new Gate 4, BR_4.10.4.3). |
| 2026-09-19 | v3.30 | IN-13 (new) | Did not exist. Duplicate Account Check's Failed/Terminated branch allowed the flow through unconditionally — no inline error existed for a returning user whose cart asset class did not match their prior account's asset class. | Added IN-13 "Your email is linked to an existing [Profile Asset Class] account. You cannot switch asset classes on a reset. Please change your selection to match your account, or log in to your dashboard to reset your evaluation." — fires when the backend Duplicate Account Check detects a Failed/Terminated record whose persisted asset_class does not match the cart's asset_class. | User requirement (chat), 2026-09-19. No CR/QnA source. Companion change: UC_2.1-2.6_v1.md v32 (new BR_2.6.2.11). |
| 2026-09-16 | v3.29 | BN-15 (new); FP-06 (cross-refs updated) | The [Timeout calling provider] case for Dusupay/T365 (backend gets no response from the provider within 30s at POST /execute-checkout) rendered a top-right auto-dismiss toast (TE-SYS-01), inconsistent with the sibling [Transaction exceeds maximum amount]/[Transaction below minimum amount] cases on the same screen, which render a persistent BN-13/BN-14 banner on FP-06. | Added BN-15 "Unable to connect. Please check your network and try again" — same copy as TE-SYS-01, but rendered as a persistent banner on FP-06, paired with the same [Return to Payment page] button as BN-13/BN-14. FP-06's failure-state note updated to list all four banners (BN-12, BN-01, BN-13/BN-14, BN-15). | Client requirement, 2026-09-16 — unify the 30s provider-timeout failure UI with the max/min transfer-amount banner pattern. Companion change: UC_2.7-2.8_v1.md v4.12 (UC_2.7.7 §4, UC_2.7.9 §5). |
| 2026-09-07 | v3.23 | IN-12 (new) | Did not exist. No inline error for a US/CA Address Validation Gate mismatch at Step 5. | Added IN-12 "ZIP code does not match the billing address. Please enter the correct ZIP code" — fires when the backend Google Address Validation API gate flags a mismatch among State/Province, City, and ZIP for billing_country IN ('US','CA'). | Client chat requirement, 2026-09-06. Tagged [CHR-87]. Companion change: UC_2.1-2.6_v1.md v25 (new BR_2.6.1.12). |
| 2026-09-07 | v3.24 | BN-09 (new — reuses removed slot) | Did not exist. No banner covered the expired vaulted card case on 1-Click modals — the card expired error code from NMI was not distinguished from other decline types. | Added BN-09 "Your saved card has expired. Please update your payment method in Account Settings." — fires on Time Extension, Reset, and Re-Buy 1-Click modals. CTA changes to "Change payment method" → Path C. | Client supplement, 2026-09-07. TC: SC-TE-CARD-12. |
| 2026-09-15 | v3.28 | BN-13, BN-14 (new) | No frontend banner for T365/Dusupay transfer amount limits. | Added BN-13 (Max transfer amount exceeded) and BN-14 (Min transfer amount not met). Both render on FP-06. | Client requirement, 2026-09-15. Companion change: UC_2.7-2.8_v1.md v4.11. |
| 2026-09-15 | v3.27 | FP-06 (new), BN-12 (new), BN-01 (trigger note added) | No full-page "processing" state existed for a payment redirect return flow. Dusupay/T365 opened the hosted payment link in a new browser tab while OV-05 held on the checkout tab. | Added FP-06 "Verifying Your Payment..." — dedicated screen the Dusupay/T365 Return URL lands on after the current, active tab is redirected completely to the hosted page (no secondary tab) and the payment attempt finishes. Added BN-12 for a genuine decline while on FP-06, paired with a [Return to Payment page] button. BN-01 (10-minute timeout, copy unchanged) now also explicitly renders on FP-06 for this flow, with the same button. | Client requirement, 2026-09-15 — Dusupay/T365 full-page redirect flow (Step 1 full redirect, Step 2 Return URL to FP-06, Step 3 success transition to OV-06/Activate Account or failure via BN-12/BN-01). Companion change: UC_2.7-2.8_v1.md v4.10. |
| 2026-09-10 | v3.26 | BN-09 — "Applies to" links consolidated; BN-11 (new) | BN-09 pointed at UC_4.10.3 §7 / UC_4.10.4 §6 / UC_4.15.3 §7 (each had its own standalone card-expired case). Double Payment on the Reset/Re-Buy/Time-Extension §6a table had no user-facing banner defined ("No user-facing error at click time"). | BN-09 now points to the single canonical case row in UC_4.10.3 §6a — the standalone case in §7 of UC_4.10.3/UC_4.10.4/UC_4.15.3 was deleted (no longer duplicated in Basic/Exceptional Flow). Added new BN-11 "It looks like you were charged twice for this purchase. Your duplicate payment will be refunded." — business rule correction: the Double Payment case in §6a now does display a banner. Distinct from BN-10 because the user already has an active account (no Claim Account link applies). | BA feedback, 2026-09-10 — user review of §6a table. |
| 2026-09-08 | v3.25 | BN-10 (new) | Did not exist. BR_2.8.1.4 (Accidental Double-Payment After Timeout Retry, [CHR-21]) had backend refund/ticketing logic but no frontend banner for when both charges clear as success. | Added BN-10 "It looks like you were charged twice for this order. Your duplicate payment will be refunded. Your account is still being created — please check your email for the Claim Account link." — fires on Step 6 when a second independent charge for the same user_id also succeeds; screen stays on Step 6 instead of transitioning to Phase 2. | Client note (chat), 2026-09-08. Companion change: UC_2.7-2.8_v1.md — new "[Double-Payment Detected Post-Success]" Exceptional Flow entry + BR_2.8.1.4 frontend behavior note + Step 6.5 double-payment gate. |
| 2026-09-07 | v3.23 | IN-12 (new) | Did not exist. No inline error for a US/CA Address Validation Gate mismatch at Step 5. | Added IN-12 "ZIP code does not match the billing address. Please enter the correct ZIP code" — fires when the backend Google Address Validation API gate flags a mismatch among State/Province, City, and ZIP for billing_country IN ('US','CA'). | Client chat requirement, 2026-09-06. Tagged [CHR-87]. Companion change: UC_2.1-2.6_v1.md v25 (new BR_2.6.1.12). |
| 2026-09-04 | v3.21 | IN-PROMO-05 (new) | Did not exist. promo_codes had no product-ID mapping, so no error existed for a valid code applied against the wrong product. | Added IN-PROMO-05 "Invalid promo code for this product" — fires when a promo code is valid but its mapped product_id does not match the cart's product_id. | CHR-55. Companion change: UC_2.7-2.8_v1.md v4.4 (new BR_2.7.8.7). |
| 2026-08-28 | v3.20 | TS-DASH-01 (scope) · OV-09 (cross-ref) | TS-DASH-01 was scoped to [Save Changes] only and explicitly excluded the photo path: "In Profile & Preferences that is PATCH /profile (phone) only; a photo commit uses OV-09 and fires no toast on success." A trader who clicked [Done] in the Crop Image modal got no success confirmation. | TS-DASH-01 now covers both Settings commit paths — PATCH /profile (phone) and PATCH /profile-photo (photo, on Crop Image [Done] and on [Confirm] in CF-03). Sequencing stated: OV-09 closes first, then the toast; never both at once. OV-09 gains the matching cross-reference. | User request 2026-08-28 (UC_4.6.2 v12 / BR_4.6.2.16): a photo save is a save, so it reports success like every other Settings save. Copy and ID unchanged — no new toast was created and no other consumer of TS-DASH-01 is affected. |
| 2026-08-27 | v3.18 | TE-JRN-03 (scope) | Context wording implied TE-JRN-03 was a Journal-only toast: "GET /monthly-journal-data or POST /journal-entries returns HTTP 503". | Reworded to state it is a shared system toast for any HTTP 503 response, currently surfaced by the Journal APIs per UC_4.4 §BR_4.4.13 but reusable by any other endpoint without a new ID. Copy unchanged. | BA instruction 2026-08-27 — TE-JRN-03 is a generic 503 toast, not scoped to Journal; clarify so other UCs can reference it directly instead of minting duplicate IDs. |
| 2026-08-26 | v3.17 | TS-CERT-01 (new) | Did not exist. No toast covered a copy-to-clipboard confirmation anywhere in the app, although Level Up Cinematic Scene Handling.pdf §3 requires one: "Clicking this must copy the unique public URL directly to the user's system clipboard with a lightweight toast notification confirming the copy." | Added TS-CERT-01 "Link copied to clipboard" (Success toast) for the Copy Link share target on the level certificate modal and the Career tab Latest certificate panel. Trailing period stripped per global-rules.md → Error Handling. | Source: Level Up Cinematic Scene Handling.pdf §3 Dashboard UI & Interaction Logic (client-supplied, References/Customer supplies/(Stage 2) Community & Settings/). The source mandates the toast but supplies no copy — the string is BA-authored and follows the existing Success-toast pattern of TS-DASH-01. Ref: UC_4.16.2 v1 BR_4.16.2.15 / §9.1 row 12 / §9.2 row 3. |
| 2026-08-27 | v3.19 | IN-06 — trigger widened | Trigger listed only onBlur / on submit. | Trigger now also fires on Country Code dropdown change; scope note added (dial code + number must both match — same-country). | Companion change: UC_2.7-2.8_v1.md v4.1. Client directive (chat), 2026-08-27. |
| 2026-08-25 | v3.15 | BN-09 (removed) | BN-09 — error banner shown when selected market data feeds exceeded $54.00/month cap. Referenced by UC_4.15.2 BR_4.15.2.8 and UC_4.15.3. | Removed — this case cannot occur. The maximum Non-Pro bundle is 4 exchanges at $18 × 3 + 1 free = $54 flat. There is no selection combination that exceeds the cap; the error is unreachable. All cross-references in UC_4.15.2 and UC_4.15.3 also removed. | BA decision 2026-08-25. |
| 2026-08-24 | v3.14 | TE-JRN-01 (copy) | "We couldn't save your entry. Please check your inputs and try again" | "The server cannot understand the request. Please check your inputs and try again" | Copy aligned to standard HTTP 400 language for consistency with FP-04 body copy. |
| 2026-08-24 | v3.13 | IN-08 (retired) · IN-09 (retired) · IN-06 (scope widened) · IN-10 (note) | Settings → Profile & Preferences owned three private phone-error strings: IN-08 "Invalid phone number format. Please check and try again", IN-09 "This phone number is already registered with another account", IN-10. IN-06 was scoped to Phase 2 Account Claim only, and CR-09 §9.2 / IN-06 were deliberately not reused (QnA_init_docs A-09/A-10/A-12). | IN-08 and IN-09 retired. The Settings phone field now uses the shared copy verbatim: empty → "Please enter phone number" and invalid format/length → "Please enter a valid phone number" from CR-09 §9.2; duplicate → IN-06. IN-06's trigger widened to cover both phone fields (checkout POST /claim-account + Settings PATCH /profile) and its Button column generalised to "[Activate Account] / [Save Changes]". IN-10 kept and annotated as the only surviving Settings-specific phone string. Both retired rows stay in the table struck through, so existing links do not 404. | BA instruction 2026-08-24 — reverses the 2026-08-11 decision recorded in QnA_init_docs.md A-09/A-10/A-12 ("tạo chuỗi riêng cho Settings"): "chỉnh lại validation rule cho phone number, refer đến 9.2 Phone Number Field của Common Rule và checkout block, không sử dụng validation rule text hiện tại của field phone number nữa". One phone field, one set of strings, system-wide. CR-09 §9.2 itself is unchanged — this change makes Settings conform to it rather than editing it. UC_2.8.3 (checkout) is behaviourally unaffected; only IN-06's trigger text broadened. Ref: UC_4.6.2 v10 BR_4.6.2.3 / BR_4.6.2.4. |
| 2026-08-21 | v3.12 | CF-02 (copy + buttons column) | Client-verbatim copy from 2026-08-17: "This will instantly overwrite your current platform password and generate a new one. You will be logged out of active sessions." Buttons column read simply "Confirm calls POST /reset-platform-password", carrying the overwrite model. | Copy withdrawn and replaced with a BA draft flagged ⚠️ pending client sign-off: "You'll be taken to your trading platform's own password reset page. StackTrading does not perform the reset and does not store the new password — the Assigned Password shown here will not change." Buttons column now states what Confirm actually does — returns the gateway's reset destination, opened in a new tab, with no StackTrading write — and flags that no reset URL exists yet for any gateway. | Follows the client instruction of 2026-08-20 (reset handed to the third party) and the BA/client answer of 2026-08-21: "giờ confirm chỉ dẫn sang tab mới để trader reset password thôi. Không overwrite vào assigned password nữa." The old string described the overwrite model that UC_4.6.1 v1.5 already removed, so the popup copy was the last place still asserting it. The modal is retained — it warns the trader they are leaving the Dashboard and that the on-screen value will stop being accurate. Ref: UC_4.6.1 v1.7 BR_4.6.1.5 / §9.1 row 12. |
| 2026-08-21 | v3.11 | CF-03 (copy + buttons) | BA-authored placeholder, flagged ❓ "no design frame exists for this popup": body copy "Remove your profile photo? Your avatar will revert to your initials across the Dashboard and the current image cannot be recovered.", buttons Cancel / Remove in the horizontal CF-01/CF-02 layout. | Replaced with the design copy: Title "Remove your photo?", no body text. Buttons are Confirm / Cancel, stacked vertically with Confirm on top (Primary/gold) and Cancel below (Secondary). ❓ flag removed. | BA supplied the design frame 2026-08-21. Note the layout differs from CF-01/CF-02 (horizontal Cancel-then-Confirm): this popup stacks its buttons and puts the affirmative action first. Verb also differs — Confirm, not Remove. |
| 2026-08-21 | v3.10 | OV-09, CF-03, TS-DASH-01, IN-09 (endpoint references only) | All four pointed at POST /profile, the single write endpoint from RFQ_ Stack Trading Prop Tech V7.pdf §Page 36. | Re-pointed to the split endpoints: OV-09 and CF-03 now name PATCH /profile-photo; IN-09 names PATCH /profile; TS-DASH-01 gained a line clarifying that in Profile & Preferences it covers the phone save only — a photo commit shows OV-09 and fires no success toast. | Sotatek BE team API review 2026-08-21 (UC_4.6.2 v8 / BR_4.6.2.15): POST → PATCH, and one write endpoint split into PATCH /profile-photo + PATCH /profile. Reference-only change — no copy, trigger condition, or button label was touched. |
| 2026-08-21 | v3.9 | OV-09, CF-03 (both new) | Did not exist. UC_4.6.2 staged the profile photo locally and committed it through [Save Changes], so there was no in-flight avatar state to cover and no destructive removal to confirm. | Added OV-09 — gold spinner + "Updating avatar...", the blocking overlay shown while a profile-photo commit runs. Added CF-03 — "Remove your profile photo? Your avatar will revert to your initials across the Dashboard and the current image cannot be recovered.", buttons Cancel / Remove. | BA instruction 2026-08-21 (UC_4.6.2 v7): the photo now commits immediately on Crop Image [Done] and the old S3 object is hard-deleted, independent of [Save Changes] — which forces [Remove Photo] to commit immediately too, hence the confirmation. ❓ Both strings are BA-authored; the design set has an "Updating avatar..." frame but no frame for the removal confirmation. TS-DASH-01 is unchanged and now covers the phone save only. |
| 2026-08-19 | v3.8 | TE-SYS-01 (Context) | "No network — initial page load OR action failed." Did not mention timeout or 500 explicitly. | "No network, request timeout, or HTTP 500 — initial page load OR action failed. Also covers client-side timeout / no server response (no HTTP status at all)." Added Ref to UC_4.4 §BR_4.4.13. | User request: sync TE-SYS-01's timeout wording with UC_4.4's BR_4.4.13, which reuses TE-SYS-01 for both its 500 row and its "Timeout / no network" row. TE-JRN-04 (504) definition below is left as-is — UC_4.4 dropped only its own table row referencing it, not this master-list entry. |
| 2026-08-19 | v3.7 | TE-JRN-01, TE-JRN-02, TE-JRN-03, TE-JRN-04 (all new) | Did not exist. UC_4.4 (Journal & Heatmap) had no dedicated error toasts for GET /monthly-journal-data or POST /journal-entries failing with a specific HTTP status. | Added 4 new error toasts, one per non-network HTTP status the Journal APIs can return: TE-JRN-01 (400 — validation), TE-JRN-02 (404), TE-JRN-03 (503), TE-JRN-04 (504). 401 and 500 reuse the existing TE-AUTH-01/TE-SYS-01 respectively — no new IDs needed for those two. | User request — build a per-status-code error-message table for UC_4.4 covering 401/400/404/500/503/504. Ref: UC_4.4 §BR_4.4.13. |
| 2026-08-18 | v3.6 | BN-08 (new) | Did not exist — no banner covered clicking [Activate Account] twice before the first click's request finished. | Added — banner shown when the user clicks [Activate Account] twice (e.g. same link opened in two tabs) before the first submission finishes. "This account has already been activated. Please try logging in — if your trading floor is still being set up, we'll notify you by email once it's ready." | Ref: UC_2.8.3 §5 new "[Clicking Activate Account twice]" case. Client supplement (chat), 2026-08-18. |
| 2026-08-17 | v3.6 | CF-02 (new) | Did not exist. The Connections & Credentials reset action was specified as a route-out to the gateway's own portal, so no app-side confirmation was needed. | Added — platform password reset confirmation modal. Copy is client-supplied verbatim: "This will instantly overwrite your current platform password and generate a new one. You will be logged out of active sessions." Buttons Cancel / Confirm; Confirm calls POST /reset-platform-password. | Client-confirmed (Adrian Stack, 2026-08-17): "Do not link out externally. When a user clicks 'Request Password Reset', it must open an internal confirmation modal with a warning." Ref: QnA STAGE 2 Settings [CC-BIZ-06]; UC_4.6.1 v1.4 BR_4.6.1.5 / §9.1 row 12. Modal has no wireframe yet ([CC-UI-02]). |
| 2026-08-14 | v3.5 | FP-05 (new) | Did not exist. | Added — Invalid Link full-page block. Trigger: link invalid (e.g. user changes the token). Title "Invalid Link", body "This activation link is no longer valid. Please contact support if you need help.", button "Return to Homepage". | Ref: UC_2.8.3 §5 new "[Claim link invalid]" case. |
| 2026-08-06 | v3.0 | FP-01 (404), FP-03 (500), FP-04 (400 — new) | FP-01: single-line "Page not found or has been removed", button "Back to Home" (Design pending). FP-03: single-line "The system is currently unavailable. Please try again later", button "Back to Home" (Design pending). FP-04: did not exist. | FP-01: added Title "Page Not Found" + Body "The server cannot find the requested page. If you believe this to be an error, please review our FAQ." + button "Return to Homepage". Removed (Design pending). FP-03: added Title "Something Went Wrong" + Body "Your request could not be processed. Please try again. The server encountered an unexpected condition that prevented it from fulfilling the request." + button "Return to Homepage". Removed (Design pending). FP-04: added placeholder for 400 Bad Request (pending BA content from Figma node-id=8058-108939). Updated §0 critical rule: added 400 → FP-04. | BA provided Figma content for 404 & 500 screens. 400 screen pending — Figma inaccessible. |
| 2026-07-27 | v1.6 | BN-01 (renumbered to BN-04) | Described the old post-payment 409 duplicate-account flow (checkout-time trigger). | Marked ⚠️ Superseded by IN-02/IN-03/IN-04; kept for history only; renumbered from BN-01 to BN-04. | Blacklist/Duplicate checks moved to Step 5 emailonBlur per STAGE1-083/STAGE1-084. |
| 2026-07-27 | v1.6 | BN-01 (repurposed) | ID freed up by the BN-04 renumber above. | Added —POST /execute-checkout gateway timeout banner. "Time out. Please try again" | Source: UC_2.8.1 §5 step 8 / §6 Exceptional Flow. BA feedback item 23. |
| 2026-07-27 | v1.6 | OV-08 → IN-PROMO-04 | Modeled as a blocking overlay with [OK] button. | Converted to inline banner pattern below the promo input, with manual [Remove] button; input retains the invalid code (not auto-cleared). Removed OV-08 entry entirely. | BA feedback item 10 — invalid-promo re-validation should not block the whole screen. |
| 2026-07-27 | v1.6 | IN-02 (new) | Did not exist. | Added — Step 5onBlur Blacklist Check hard stop. "Account restricted. Please contact support." | Source: STAGE1-083 (confirmed Adrian Stack 2026-07-27). BA feedback item 7. |
| 2026-07-27 | v1.6 | IN-03 (new) | Did not exist. | Added — Step 5onBlur Duplicate Account Check, Active_SIM/Active_DMA. "You already have an active account." | Source: STAGE1-084 (confirmed Huyen Dinh + Adrian Stack 2026-07-27). BA feedback item 7. |
| 2026-07-27 | v1.6 | IN-04 (new) | Did not exist. | Added — Step 5onBlur Duplicate Account Check, Guest + provider_event_id IS NOT NULL. "You have an unclaimed account. Please check your email for your activation link." | Source: STAGE1-084. BA feedback item 7. |
| 2026-07-27 | v1.6 | BN-05 (new) | Did not exist. | Added — used Claim Account link banner on login screen."You have claimed this account, please login." | Source: WireframeClick a used Claim account link.png. Ref'd from UC_2.8.3 §5. |
| 2026-07-28 | v1.8 | OV-08 (new) | Referenced fromBR_2.1.5.2 as "OV-07" but that ID was already in use for the Auth0 account-creation-failure overlay — dangling/conflicting reference. | Added as OV-08 (OV-07 stays as-is for its existing Auth0 failure case) — Step 6 Pay-click price-change popup (Founder cohort sold out). "Please refresh to get the latest price" / "Refresh now". | BA feedback — price recheck at Pay click. |
| 2026-07-28 | v1.9 | OV-03 (trigger text) | "15-min IP block (Redis); direct API → 429". | "15-min block tracked by email address (Redis); direct API → 429." Added Ref: CR-20260728-002. | CR-20260728-002 — Failed Payment Lockout changed from IP-based to Email-based blocking. |
| 2026-07-28 | v1.9 | BN-05 (copy) | "You have claimed this account, please login." | "You have already claimed this account, please login." | STAGE1-101 confirmed copy fix — clarify the account was previously claimed. |
| 2026-07-29 | v2.0 | IN-05 (new) | Did not exist. | Added — Step 5 Confirm EmailonBlur mismatch/invalid format hard stop. "Emails do not match." | CR-20260729-001; Client (chat), 2026-07-29. Ref: UC_2.6.1 BR_2.6.1.7. |
| 2026-07-30 | v2.1 | IN-06 (new) | Did not exist. | Added — Phase 2 Account Claim PhoneonBlur Duplicate Phone Number Check. "This phone number is already registered to another account." | Phase 2 Account Claim requirement update. |
| 2026-07-30 | v2.2 | UC_2.8.4 §6 — Provisioning frontend timeout removed; BN-06 (new) | Frontend enforced a max 60s timeout on POST /claim-account; on timeout, a [Retry] button + error banner rendered, with a 3-outcome (A/B/C) idempotent retry table. Did not exist: BN-06. | Removed the 60s frontend timeout and [Retry] button entirely — interstitial holds indefinitely until the session token arrives. Failure handling delegated to the existing backend auto-retry mechanism (Ref: UC_2.8.2 §Step 3 Exception — 5s/30s backoff, 3 attempts). If all attempts fail, backend fires Freshdesk ticket + dispatches SES-23 email; frontend shows banner BN-06 (new) "A provisioning issue occurred. Please check your email for technical support details." on the provisioning screen — no user-facing retry action. | Client confirmed (chat), 2026-07-30 — remove 60s provisioning timeout/retry mechanism. |
| 2026-07-30 | v2.3 | BN-03a/BN-03b, OV-01…OV-08, §7 table (formatting fix) | Missing space before bold markers (refund**in progress**, in**French**, Defaults to**Flow A**); OV table Content cells crammed Title/Header + Body onto one line with ambiguous *** boundaries, causing literal * rendering. OV-01 Body text was truncated ("...Please refresh or tryco*"). | Added missing space before bold markers. Restructured OV Content cells to use <br /> between Title/Header and Body so each renders on its own line. Completed OV-01 Body text per confirmed source. | Formatting-only fix, no content/meaning change except OV-01 Body completion. Source: QnA STAGE1-011 (References/QnA from clients/02_STAGE1_CHECKOUT_ONBOARDING/QnA_STAGE1_CHECKOUT_ONBOARDING.md). |
| 2026-07-30 | v2.4 | BN-01 (trigger + copy) | POST /execute-checkout gateway timeout (2-minute rule). Copy: "Time out. Please try again". Timeout was a hard block requiring gateway response. | Changed to frontend session timeout (10-minute rule) — the frontend independently gives up waiting on the third-party gateway/webhook after 10 minutes regardless of backend state, so users who walk away mid-payment aren't permanently blocked. Copy: "Payment session expired. If you already submitted your payment, please check your email for confirmation. If you have not paid yet, please try again." | Client feedback (chat) — frontend must not permanently lock on a timeout it doesn't control; backend webhooks remain the source of truth in the background. Ref: UC_2.8.1 §5 step 8 / §6 Exceptional Flow / BR_2.8.1.1 / BR_2.8.1.3 / new BR_2.8.1.4. |
| 2026-07-30 | v2.5 | BN-01, OV-05 (anchors); OV table <br /> tags | BN-01 and OV-05 had no <a id> anchor, so the new cross-references added in v2.4 (list-toast-popup.md#bn-01, #ov-05 from UC_2.7-2.8_v1.md) pointed at nothing. OV-01…OV-08 Content cells used bare <br /> (not self-closed), invalid in the MDX/JSX pipeline used by docs-site. | Added <a id="bn-01"></a> and <a id="ov-05"></a>. Normalized all <br /> in the OV table (OV-01, OV-02, OV-03, OV-04, OV-06, OV-07, OV-08) to self-closed <br />. | Self-review while auditing the v2.4 change for broken links — no content/meaning change. Note: most BN-/OV-/FP-*/TE-SYS-01 anchors elsewhere in this file are still missing, and even existing <a id> anchors are stripped by the docs-site Fumadocs build (confirmed via built HTML — links still work in raw/GitHub markdown rendering). Tracked as a separate, wider follow-up — not fixed here. |
| 2026-08-01 | v2.6 | OV-04 (Type, Button, §3 note) | Type = "Overlay"; Button column = "Return to Homepage | [✕]"; rendered as a blocking overlay on top of the checkout page. | Type changed to "Page state"; [✕] close icon removed from Button column (only "Return to Homepage" remains); added a note under §3 explaining OV-04 now renders as page content on the dedicated Waitlist page rather than a blocking overlay. | Follow-up to Gate 1 Waitlist overlay → dedicated page change (Ref: UC_2.1-2.6_v1.md changelog v5). User decision (BA session), 2026-08-01 — no more Close button on the Waitlist page; Header/Footer unaffected. |
| 2026-08-02 | v2.7 | FP-02 (Button) | Button = (none — hard stop) | Button = Return to Homepage | Client feedback — 403 screen must have a Return to Homepage button, not an empty hard stop. |
| 2026-08-04 | v2.8 | IN-05 (split), IN-07 (new) | IN-05 covered both mismatch AND invalid format with one message "Emails do not match." | Split into two: IN-05 → mismatch only ("Emails do not match."); new IN-07 → invalid format ("Please enter a valid email address."). | BA directive — separate error messages for email format vs mismatch on Confirm Email field. |
| 2026-08-06 | v2.9 | BN-07 (new) | Did not exist. | Added —POST /execute-checkout dedup check banner. "You have an unclaimed account. Please check your email for your activation link." | Source: BA gap analysis — UC_2.8.1 POST /execute-checkout lacked a pre-gateway idempotency check; HTTP 409 exceptional flow was dangling with no trigger in §5. |
| 2026-08-08 | v3.1 | OV-08 — Trigger + [Refresh now] behavior | Trigger listed only Founder cohort sold out; [Refresh now] button had no spec'd behavior; no note that promo is not reserved. | Added tax rate change as second trigger. Added note "no promo reserved". Spec'd [Refresh now]: closes overlay and refreshes Order Summary with updated price/tax — no page reload. | BA directive 2026-08-08. |
| 2026-08-08 | v3.2 | BN-07 — trigger description corrected | Said provider_event_id could mean the payment was "in-flight or completed" — contradicts the schema (only ever written on success). | Corrected to "a previous payment already succeeded" only. Cross-referenced new BR_2.8.1.5 (UC_2.7-2.8_v1.md), which allows retry when the prior payment failed or is still in progress. | Client supplement (chat), 2026-08-08. |
| 2026-08-11 | v3.4 | TS-DASH-01, IN-08, IN-09, IN-10 (all new) | Did not exist. The Settings module had no Save-success toast, and no inline errors for the Profile & Preferences phone field. | Added TS-DASH-01 "Changes saved successfully" (Success toast, shared by every Settings tab with a Save button). Added IN-08 "Invalid phone number format. Please check and try again", IN-09 "This phone number is already registered with another account", IN-10 "The new phone number cannot be the same as your current one". | BA decision 2026-08-11 (QnA_init_docs UC_4.6.2 A-09/A-10/A-11/A-12): Settings gets its own phone-error strings taken from the BA design; the checkout strings (CR-09 §9.2 and IN-06) are deliberately left unchanged, so UC_2.8.3 is not affected. All four strings had their trailing period stripped from the design copy per global-rules.md → Error Handling. |
| 2026-08-09 | v3.3 | TE-DASH-01 (new) | Did not exist. | Added — In-Dashboard purchase charge rejected because account Status changed between modal open and CTA click. "Something went wrong. Please reload for latest data." | Per BA feedback on UC_4.10.4 (feedback #10): close popup, hiện toast này khi Status không còn Active_SIM tại thời điểm charge. |
| 2026-08-15 | v3.5 | OV-07 (header + trigger scope), BN-06 (removed) | OV-07 header was "Payment Successful" (the body's own leading sentence promoted to the header) — misleading for a failure case (flagged as naming misnomer in QC, GAP-P2-05). BN-06 duplicated the same SIM/Auth0 provisioning-failure case as a separate Error banner on the Phase 3 interstitial (Ref: UC_2.8.4 §6), conflicting with OV-07's coverage of the same failure at Phase 2 (Ref: UC_2.8.3 §5). | OV-07 header changed to "Account Creation Failure". Body copy unchanged (still opens with "Payment Successful." to reassure the user the charge went through before explaining the account-setup delay). OV-07 trigger description widened to explicitly cover both Auth0 failure (UC_2.8.3 §5) and the Phase 3 interstitial SIM/Auth0 failure (UC_2.8.4 §6) as one single overlay. BN-06 row removed entirely — provisioning failure now always renders as OV-07, never a banner. | Client directive (chat), 2026-08-15 — consolidate provisioning-failure UI to one overlay; fix misnomer header (title must not read as a success state), keep "Payment Successful" as the reassurance line inside the body. Cross-ref: UC_2.7-2.8_v1.md UC_2.8.4 §4/§6 updated to match. |