CR Before/After Summary — Internal BA CSV Cross-Reference

Source of truth: References/CR/CR-index/1-58 [BA Internal] Stacktrading - Change requirement.csv (65 non-blank rows, CR_ID 1–60 plus a few split/blank-ID rows — see below). This file is the authoritative CR register; it is never edited based on References/CR/ folder content or on this audit.

Purpose: For every CR_ID in the internal BA CSV, this document records the Before/After business change, where it is (or is not) reflected in docs/BA, and its current status. It also cross-references the separate References/CR/<date>_... folder set and the informal STAGE-NNN / CR-YYYYMMDD-NNN tags already used inside the UC docs — these are related but distinct tracking schemes (see CLAUDE.md §Key files and the note at the end of this document).

Audit date: 2026-08-21. Tag convention introduced by this audit: [BA-CR-<CR_ID>], inserted next to the relevant BR/section header (or as a stub if no content existed yet) so a doc reader can trace straight back to the CSV row. Insertion does not remove or renumber any pre-existing CR-YYYYMMDD-NNN or STAGE-NNN citation already in the docs — those remain the primary citation for their own scheme; [BA-CR-N] is an additional cross-reference layer pointing at the CSV.

Status legend:

• ✅ Applied — Before/After content is fully reflected in docs/BA, tagged with [BA-CR-N] by this audit (or already unambiguously traceable via an existing CR-YYYYMMDD-NNN/STAGE tag).
• 🟡 Partially documented — content exists but incompletely, or only via a different scheme with no direct [BA-CR-N] tag added (effort/priority marks this low-risk to leave as-is, or a stub was added instead of a full rewrite).
• 🆕 Stub added this audit — zero prior content; a new BR stub with "pending BA write-up" framing was inserted.
• ⚠️ Needs BA input — flagged open question, ambiguous/garbled CSV text, or a large undocumented change; no doc edit made pending clarification.
• ⬜ Not yet in docs — confirmed no matching content anywhere in docs/BA; no stub added (out of scope for this pass, effort/priority too low, or nothing meaningful to stub).
• ⚪ No-op / config-only — change has no BA-doc surface (pure Sanity CMS config migration, 3rd-party vendor swap with no flow-logic change, etc.).

---

Quick index

---

CR 1

Module/Function: Auth0 integration — Login · UC: UC_3.1 · Date: 20/07/2026 · Type: REQ update

Before: User clicks "Login" → redirected to Auth0-hosted Universal Login page → enters credentials → Auth0 authenticates → redirected back with JWT.

After: Flow 1 – Trader: user enters email, clicks "Continue" → OTP email sent to inbox → user enters OTP on next screen → Auth0 authenticates → redirected back with JWT.

Doc location: docs/BA/UC_3.1-UC_3.2/UC_3.1_UC_3.2_Login.md describes the OTP-based Trader login flow in full (UC_3.1). No [BA-CR-1] tag added — the doc's entire UC_3.1 section is this flow, and the doc predates informal-tag conventions used elsewhere; tagging the whole UC header was judged unnecessary noise.

Status: 🟡 Partially documented (content present, no explicit [BA-CR-1] anchor).

CR 2

Module/Function: Login with Google · UC: UC_3.2 · Date: 20/07/2026 · Type: New REQ

Before: Not available.

After: Flow 2 — Internal employee login (Google SSO): Stack Trading staff with @stacktrading.com Google Workspace accounts authenticate via Google SSO; MFA (Google Authenticator) to be assessed as part of SSO login.

Doc location: docs/BA/UC_3.1-UC_3.2/UC_3.1_UC_3.2_Login.md UC_3.2 covers Google SSO domain-gating and MFA Passkey step (BR-07). This CR is the origin of UC_3.2; it is superseded/extended by CR_ID=52 (permission-group gating), which is tagged [BA-CR-52] (see below).

Status: 🟡 Partially documented (base flow present; no [BA-CR-2] anchor on the original domain-gate rule since it's superseded in-place by CR_ID=52).

CR 3

Module/Function: 3rd party services — Zendesk · Date: 17/7/2026 · Type: REQ update

Before: Zendesk. After: Freshdesk.

Doc location: Vendor swap referenced inline wherever ticketing is mentioned (e.g. UC_2.7-2.8_v1.md line 1022: "Freshdesk compliance review ticket"). No dedicated BR — pure vendor-name substitution with zero effort logged (BA/BE/FE/QC/AQA all 0 in the CSV).

Status: ⚪ No-op / config-only.

CR 4

Module/Function: Impact → Everflow · Date: 26/7/2026 · Type: REQ update

Before: Using Impact. After: Using Everflow.

Doc location: UC_2.1-2.6_v1.md BR_2.6.1.3 fully documents the Everflow SDK/cookie/attribution flow (everflow_id, getTransactionId()). Vendor swap fully absorbed into the doc's baseline text, not cited as a standalone CR since effort = 0 across the board.

Status: ⚪ No-op / config-only (content present but as baseline text, not a flagged change).

CR 5

Module/Function: Marketing Site — Partners Page, "Apply to Partner Network" / "Submit Partner Application" · UC: UC_1.8.7 · Date: 24/7/2026 · Type: New REQ

Before: Not available.

After: Full Submit Partner Application event flow — form validation/CAPTCHA, loading/success states, GA4 + ActiveCampaign tracking, Klaviyo webhook (bypassing Zapier) for affiliate funnel, and a parallel Node.js/AWS SES alert email to partners@stacktrading.com.

Doc location: docs/BA/UC_1.1-1.9/UC_1.8.md UC_1.8.7. CSV marks Doc update status = Done.

Status: ✅ Applied.

CR 6

Module/Function: Stage 1, Step 5 PII Capture — ZIP postal code · UC: UC_2.6.1 · Date: 27/7/2026 · Type: New REQ

Before: No ZIP postal code field in Step 5; no ZIP table.

After: New country_zip_requirements table; new zip_code field on users; GET /system/status gains a zip_requirements field.

Doc location: docs/BA/UC_2.1-2.8/UC_2.1-2.6_v1.md and UC_2.7-2.8_audited-v1.md both reference zip_code/country_zip_requirements.

Status: ✅ Applied.

CR 7

Module/Function: Step 6 Payment — Apply promo code · UC: UC_2.7.8 · Date: 26/7/2026 · Type: New REQ

Before: No promo code table. After: Add a promo_codes table to the DB.

Doc location: UC_2.7-2.8_v1.md §"DB schema — promo_codes table" (line ~665) fully documents the schema. This is the base table that CR_ID=20 (pessimistic locking) and CR_ID=55 (1-to-1 product mapping, tagged [BA-CR-55]) build on top of.

Status: ✅ Applied.

CR 8

Module/Function: Crypto failure → Freshdesk ticket · UC: UC_2.7.5 · Date: 20/7/2026 · Type: REQ update

Before: The previous refund flow does not include sending a Freshdesk compliance ticket.

After: For crypto, log the transaction exception to the financial ledger and immediately generate a high-priority Freshdesk compliance review ticket for manual treasury desk restitution.

Doc location: UC_2.7-2.8_v1.md line 1022, cited there under CR-20260727-004 (the date-based scheme's ID for this exact rule — confirms this CSV row and that dated CR are the same business change, just two different ID schemes for one fact).

Status: ✅ Applied (already fully traceable via CR-20260727-004; no [BA-CR-8] tag added to avoid a redundant third label on an already double-cited rule).

CR 9

Module/Function: 5-failure email lock · UC: UC_2.8.1 · Date: 20/7/2026 · Type: New REQ

Before: No rule for blocking retries.

After: If payment fails ≥5 times in 10 minutes → 15-minute temporary lock on further submissions for that email address.

Doc location: Confirmed via QnA (QnA_init_docs_step6_7.md B-02: "5 failures → lock 15 phút... HTTP 429 nếu bypass"). Note: the CSV's original rule (email-based lock) was later superseded — UC_2.7-2.8_v1.md §"Founder Cohort check" preamble cites CR-20260728-002, which "changes the 5-Failure payment lockout from IP-based to Email-based blocking" — meaning at some point it briefly went IP-based before reverting/confirming email-based. The final email-based rule matches this CSV row.

Status: 🟡 Partially documented (rule confirmed via QnA and referenced in dated-CR history; no dedicated BR paragraph with a [BA-CR-9] tag added this audit — low priority, Client Decision column is blank in the CSV, meaning it may still be pending final approval).

CR 10.1

Module/Function: Admin BPS — Resend email, triggered by admin · UC: UC_2.8.2 · Date: 21/7/2026 · Type: New REQ

Before: Not available.

After: Flow 41 — POST /resend-welcome (admin_id, user_id, reason, transcript_url), generates fresh Claim-Account token, logs to BPS_Audit_Log, fires RESEND_WELCOME webhook. Blocked if credentials_claimed_at IS NOT NULL.

Doc location: Confirmed live in the codebase as CR-20260728-006 ("splits POST /resend-welcome into two endpoints: Admin-only... and new public...") — see UC_2.7-2.8_v1.md preamble.

Status: ✅ Applied.

CR 10.2

Module/Function: Stage 1, Step 7 Processing — Resend email, triggered by user (self-service) · UC: UC_2.8.2 · Date: 21/7/2026 · Type: New REQ

Before: Not available.

After: POST /public/resend-activation-link — anti-enumeration (always HTTP 200 regardless of email validity/claim status); redirect-to-Auth0 logic kept tied to URL token validation only, never to the public resend form.

Doc location: Same CR-20260728-006 as above; folder References/CR/2026-07-28_CR10-2_resend-activation-link-split/ already renamed to carry this CR_ID.

Status: ✅ Applied.

CR 11

Module/Function: Email send via AWS SES (post Step 6/7) · UC: UC_2.8.1 · Date: 25/7/2026 · Type: REQ update

Before: Only 1 email (Welcome_Sim_Challenge) sent, dispatching platform username/link/guides immediately on verification.

After: Split into Email 1 (Welcome — immediate on payment success, general messaging + Discord onboarding) and Email 2 (Claim Account — post-provisioning, contains the Claim link, platform_username, connection guide, Futures/Rithmic data-activation notice). ACTIVATION_TOKEN_EXP_HOURS env var controls expiry.

Doc location: UC_2.1-2.6_v1.md preamble cites CR-20260726-001 ("Welcome_Sim_Challenge split into 3 separate emails. Password field REMOVED from Phase 2") — note the CSV says 2 emails, the dated-CR note says 3; not a conflict this audit resolves (pre-existing dated-CR wording takes priority per the project's CR>QnA>Customer-supplies chain, and the actual doc content in UC_2.7-2.8_v1.md around SES-02/Welcome_Sim_Challenge matches a multi-email split). folder References/CR/2026-07-26_CR11_email-provisioning-split/ already renamed.

Status: ✅ Applied.

CR 12

Module/Function: Admin BPS — Break-glass runbook integration · UC: UC_10 · Date: 26/7/2026 · Type: REQ update

Before: No Admin UI, just an API endpoint.

After: POST /api/bps/manual-provision + a "Break-Glass Manual Provision" form in the BPS Ops Console UI; backend handles KMS-envelope encryption server-side, writes ciphertext credentials to the Users record, logs to BPS_Audit_Log, fires RESEND_WELCOME.

Doc location: docs/BA/UC_2.1-2.8/UC_2.7-2.8_v1.md — Break-Glass Runbook — Manual Account Provisioning section, tagged [BA-CR-12] by this audit.

Status: 🟡 Partially documented — the API-endpoint side is documented and now tagged, but per the CSV the Ops Console UI form (item 1 of the After-changes text) has WBS status "Todo" and Design status "Todo", and Client Decision is blank. The doc's Break-Glass Runbook section currently describes only the backend/API side; the UI form itself is not yet elaborated. Flagged here for BA follow-up — not stubbed further this audit since the API-side content (the bulk of the BR) is already solid.

CR 13

Module/Function: Zapier — Table A/B/J pricing change · Date: 26/7/2026 · Type: REQ update

Before: Not available. After: Change pricing of Table A, B, and J.

Doc location: Pure Zapier-table data values (pricing numbers), not a business-logic/flow change. Effort = 0 across all columns.

Status: ⚪ No-op / config-only.

CR 14

Module/Function: Stage 1, Step 7 — Klaviyo abandonment-nurture cancel · UC: UC_2.8.3 · Date: 27/7/2027 (CSV typo — year likely 2026) · Type: New REQ

Before: Not available.

After: When POST /claim-account returns HTTP 200, backend sets abandoned_step = 'Completed' and fires a completion event to Zapier to cancel the abandonment nurture sequence.

Doc location: UC_2.1-2.6_v1.md line 1418 — "'Completed' state — Klaviyo Kill Signal" — matches verbatim.

Status: ✅ Applied.

CR 15

Module/Function: Auth0 integration — Trader login, Remember device 30 days · UC: UC_3.1 · Date: 27/7/2027 (CSV typo — likely 2026) · Type: New REQ

Before: Not available.

After: Full remember-device flow: 15-min access token, SSO session cookie, auth0-mf 30-day trusted-device cookie; MFA skipped on trusted-device re-auth within 30 days; MFA re-required after 30-day cookie expiry.

Doc location: docs/BA/UC_3.1-UC_3.2/UC_3.1_UC_3.2_Login.md — Document References line, BR-06, and 6 other inline citations, all correctly citing CR-20260728-003. Folder References/CR/2026-07-28_CR15_remember-device-30-days/ already renamed.

Status: ✅ Applied (already correctly and fully cited; no edit needed).

CR 16

Module/Function: Stage 1, Step 0 — Cached pass rate · UC: UC_2.1.1 · Date: 28/7/2026 · Type: REQ update

Before: Daily cron counts Users table directly (Passed / Passed+Failed) → cached_pass_rate.

After: Cron now reads from the append-only Firm_Sim_Funnel_Snapshots table (populated by Zapier Flow 29 → POST /financial/daily-snap), summing sims_passed/sims_failed across historical rows instead of querying Users directly.

Doc location: UC_2.1-2.6_v1.md line 14, cited as CR-20260728-005. Folder References/CR/2026-07-28_CR16_pass-rate-aggregator-correction/ already renamed.

Status: ✅ Applied.

CR 17

Module/Function: Step 5 — Email OnBlur (blacklist/duplicate checks) · UC: UC_2.6.1 · Date: 29/7/2026 · Type: REQ update

Before: Blacklist/duplicate checks only ran in Zapier Flow 1 post-payment → required refunds on violation.

After: New blacklist table schema; both checks move to Step 5 onBlur (pre-payment) — block early, show error immediately; Flow 1 drops its refund/reject branch for these two reasons.

Doc location: UC_2.1-2.6_v1.md §5 Phase 0 (Blacklist Check & Duplicate Account Check). Folder References/CR/2026-07-27_CR17_blacklist-table-and-onblur/ already renamed.

Status: ✅ Applied.

CR 18

Module/Function: Add email confirm field · UC: UC_2.6.1 · Date: 29/7/2026 · Type: New REQ

Before: Not available.

After: Frontend-only Confirm Email field validating match against Email; not persisted to DB.

Doc location: UC_2.1-2.6_v1.md "BR_2.6.1.7: Confirm Email — Frontend-Only Match Validation" (linked directly from CSV row 50's Link docs column too). Folder References/CR/2026-07-29_CR18_confirm-email-field/ already renamed.

Status: ✅ Applied.

CR 19

Module/Function: Delete guest record · UC: UC_2.6.1 · Type: New REQ

Before: Not available.

After: Delete 'guest' + provider_event_id IS NULL records from Users table after 30 days (backend cron).

Doc location: UC_2.1-2.6_v1.md — BR_2.6.2.8: Guest Record Auto-Delete, tagged [BA-CR-19] by this audit.

Status: ✅ Applied.

CR 20

Module/Function: Step 6 — Promo Code Pessimistic Locking + promo_code_usage_log · UC: UC_2.7.8 · Type: REQ update

Before: current_usage_count only incremented after POST /execute-checkout succeeds → race condition risk; no usage-history table.

After: Deduct current_usage_count immediately on Pay click (reserve before outcome known); rollback +1 on payment failure. New promo_code_usage_log table.

Doc location: UC_2.7-2.8_v1.md, cited as CR-20260728-001. Folder References/CR/2026-07-28_CR20_promo-code-usage-log/ already renamed.

Status: ✅ Applied.

CR 21

Module/Function: Make payment — 10-minute timeout · UC: UC_2.8.1 · Type: New REQ

Before: Not available.

After: If the gateway doesn't respond within 10 minutes of POST /execute-checkout, frontend treats as failure — dissolves widget, shows a banner, allows retry; server-side webhooks catch delayed processing; double-pay handled by manual Ops refund.

Doc location: UC_2.7-2.8_v1.md. Folder References/CR/2026-07-30_CR21_payment-timeout-10min/ already renamed.

Status: ✅ Applied.

CR 22

Module/Function: Marketing site — Trading SEO page, Futures Page · UC: UC_1.7.2 · Type: New REQ

Before: Uses layout template shared with the Forex Template Page.

After: New dedicated layout with new motion design; client to supply info to BA for wireframe.

Doc location: docs/BA/UC_1.1-1.9/UC_1.7/UC_1.7.v1.md exists but was not checked line-by-line for a Futures-specific "new layout/motion" rewrite in this pass — Client Decision is blank in the CSV (not yet approved) and Design/WBS status columns are also blank, consistent with this still being in flux.

Status: ⬜ Not yet in docs (unapproved as of CSV date; no stub added — waiting on client wireframe input per the CSV's own After-text).

CR 23

Module/Function: Payment Partners — Payment method · UC: UC_2.7.1 · Type: REQ update

Before: Skrill, Nomupay, Nuvei, Dusupay. After: T360, Dusupay, PayRetailers.

Doc location: Split across two dated folders already renamed: References/CR/2026-07-26_CR23a_skrill-removed/ and References/CR/2026-07-30_CR23b_t365-replaces-nuvei-nomupay/. UC_2.7-2.8_v1.md preamble cites CR-20260726-002 ("Skrill REMOVED from payment methods").

Status: ✅ Applied.

CR 24

Module/Function: Marketing — Global Layout, CTA button (checkout entry / waitlist toggle) · UC: All · Type: REQ update

Before: CTA text/logic queried through backend. After: Configured through Sanity CMS.

Doc location: Folder References/CR/2026-07-31_CR24_cta-waitlist-toggle-sanity-config/ already renamed; UC_1.1-1.9 docs reference the Sanity-config CTA pattern broadly (Ref: CR-20260731-002 for the waitlist-flag variant specifically).

Status: ⚪ No-op / config-only (pure data-source migration, no business-rule change).

CR 25–37

Module/Function: 13 marketing-site rows (CR_ID 25 through 37), all dated 8/1/2026, all "Hardcode/Query through BE → Config through Sanity" for various homepage/career-path/rules/partners/insight-details sections.

Doc location: All 13 rows map to the single combined folder References/CR/2026-07-31_CR25-37_marketing-sanity-pricing-migration/ (already renamed, matching the batch nature of these rows — one client decision, one Slack thread, applied across many marketing pages at once). Individually reflected across docs/BA/UC_1.1-1.9/*.md wherever a "Config through Sanity" note appears (e.g. CR-20260731-001/-002 citations already present).

Status: ⚪ No-op / config-only for all 13 (pure CMS migration, no BR logic change — consistent with all effort columns being blank/0 across these rows).

CR 38

Module/Function: Stage 1, Step 5 — Email OnBlur / returning-user (Failed/Terminated) checkout pricing · UC: UC_2.6.1 · Date: 2/8/2026 · Type: REQ update · Assessment: Must have but can do later

Before: No specified pricing rule when a Failed/Terminated user re-enters Checkout.

After: Full Discount_Code_Duration_Days-gated pricing matrix (Reset Fee / Challenge Price / founder-locked prices, by within-window vs. expired-window, SIM vs. Live) plus a flow change: skip Claim Account screen, go straight to Interstitial (or straight to login if no new account needed), no email sent, backend treats it exactly like an in-app reset.

Doc location: docs/BA/UC_2.1-2.8/UC_2.1-2.6_v1.md Pricing Engine table row, tagged [BA-CR-38] by this audit as a cross-reference (not a full stub — fuller content already exists in References/CR/2026-08-02_CR38_returning-user-checkout-pricing/CR_summary.md, Ref CR-20260802-001, and in the Failure/Recovery research docs). The core UC_2.1-2.6 doc itself still lacks a dedicated BR write-up of the full branch logic — flagged in-line as "Not yet fully elaborated in this UC."

Status: 🟡 Partially documented — cross-referenced this audit; still needs a dedicated BR before dev handoff (per the doc's own flag). See also the two blank-CR_ID rows below (Failed-user flow / Terminated-user flow), which describe the same business change in more granular before/after form and are effectively duplicates/precursors of this CR_ID.

CR 39

Module/Function: Dashboard — Sidebar navigation, Log out · UC: UC_4.1.2 · Date: 23/07/2026 · Type: New REQ

Before: Not available. After: Add action to log out of the system.

Doc location: docs/BA/UC_4.1-4.17/dashboard_common/UC_4.1.1-4.1.5/UC_4.1.1-4.1.5_v1.md §UC_4.1.2 Profile-icon dropdown — Logout item, cross-referencing CR-20260806-001 for teardown detail. CSV Doc update status = Done, and its own Link docs column points directly at this file/anchor. Folder References/CR/2026-08-06_CR39_dashboard-logout-action/ already renamed.

Status: ✅ Applied (already fully cited via CR-20260806-001; no additional [BA-CR-39] tag needed — CSV's own Link docs column already resolves correctly).

CR 40

Module/Function: Stage 2 Dashboard SIM — Scenario A: Sim Reset (In-App) · UC: UC_4.10.3 · Date: 12/8/2026 · Type: REQ update

Before: POST /purchase-challenge-reset validation required Status == 'Failed' only.

After: Validation expanded to Status IN ('Failed', 'Active_SIM'); pricing route always uses within-window logic.

Doc location: docs/BA/UC_4.1-4.17/dashboard_sim/UC_4.10.3/UC_4.10.3_v1.md §3 Pre-conditions, cross-referenced as CR-20260812-001. CSV's own Link docs column resolves directly to this doc's §3. Folder References/CR/2026-08-12_CR40_purchase-challenge-reset-status-gate/ already renamed.

Status: ✅ Applied.

CR 41

Module/Function: Stage 2 Dashboard Common — Settings, Connection & Credentials · UC: UC_4.17.1 · Date: 12/8/2026 · Type: REQ update

Before: Reset password redirects to Rithmic; no password shown on dashboard; user sees password only via 3rd-party welcome email.

After: Show ASSIGNED password (reveal/hide + copy) directly on dashboard; no more 3rd-party trading-account email; POST /reset-platform-password redirects trader to 3rd-party provider to complete reset; dashboard never stores the new password.

Doc location: docs/BA/UC_4.1-4.17/dashboard_common/UC_4.6.1-4.6.4/UC_4.6.1_v1.md — BR_4.6.1.2 (Credentials Displayed Natively) and BR_4.6.1.5 (Password Reset — One-Way Overwrite), both tagged [BA-CR-41] by this audit.

Status: ✅ Applied.

CR 42

Module/Function: Stage 2 Dashboard Common — Settings, Billing · UC: UC_4.6.3 · Date: 12/8/2026 · Type: REQ update

Before: Simple text + "Manage Billing" button opening Invoices externally.

After: New design showing Invoices directly in-tab with description/status (API already exists).

Doc location: docs/BA/UC_4.1-4.17/dashboard_common/UC_4.6.1-4.6.4/UC_4.6.3_v1.md — BR_4.6.3.2: Tab Scope — Invoice History Only, No Billing Portal, tagged [BA-CR-42] by this audit.

Status: ✅ Applied.

CR 43

Module/Function: Stage 3 KYC — Flow 3B EXPIRED/ABANDONED auto-renewal · UC: UC_5.2 · Date: 12/8/2026 · Type: REQ update

Before: Zapier V7 only defines Outcomes A/B/C; EXPIRED/ABANDONED undocumented; veriff_attempts exists in schema but has no increment logic for these states.

After: New Outcome D — EXPIRED (Code 9104) and ABANDONED both auto-call POST /sessions, increment veriff_attempts, send Identity_Verification_Retry email; at attempt 2 also create a Freshdesk ticket concurrently; at attempt 3 switch to DECLINED path.

Doc location: docs/BA/UC_5.1-5.8/UC_5.2.md §BR_5.2.9 (Auto-renewal on expired/abandoned) and the "Outcome D" flow block, already cited under the informal tag STAGE3-023. Folder References/CR/2026-08-12_CR43_veriff-expired-abandoned-autorenew/ already renamed.

Status: ✅ Applied (already fully traceable via STAGE3-023; no additional [BA-CR-43] tag needed).

CR 44

Module/Function: Stage 3 Payout — Flow 3C Dots suspension listener · UC: UC_5.2 (CSV lists 5.2; actual home is UC_5.4) · Date: 12/8/2026 · Type: REQ update

Before: Flow 3C only listens for "Active and Payable"; no listener for Suspended/Paused/Failed; Dots_Profile_Action_Needed email only triggered inside the Level 6 path, not Stage 3.

After: New webhook listener for Dots status → Suspended/Paused/Failed sets payout_status = 'Suspended' and sends Dots_Profile_Action_Needed; on trader resolving the issue, Dots' "Active and Payable" webhook re-fires and re-triggers the aggregation check.

Doc location: docs/BA/UC_5.1-5.8/UC_5.4.md §BR_5.4.8 (Dots Suspension Webhook Listener) and §BR_5.4.9 (Action-Needed Email), already cited under informal tag STAGE3-038. Folder References/CR/2026-08-12_CR44_dots-suspension-listener-flow3h-gate/ already renamed.

Status: ✅ Applied (already fully traceable via STAGE3-038; no additional [BA-CR-44] tag needed). Note the CSV's UC_ID column (UC_5.2) is slightly off — the actual content lives in UC_5.4, not UC_5.2; flagging for BA to correct the CSV's own UC_ID column (not editing the CSV per the no-write-back rule — reporting only).

CR 45

Module/Function: Stage 3 Provisioning — Flow 3H broker API failure + retry logic · UC: UC_5.8 · Date: 12/8/2026 · Type: REQ update

Before: No failure handling documented for POST /provision-live-user failures, either broker.

After: Rithmic — batch retry hourly outside operating hours (weekend batch reprocess Sun 3:45pm CT). MT5/TraderEvolution — exponential backoff 1m→3m→5m→15m→30m→1h→hourly thereafter; notify support; log for debugging.

Doc location: docs/BA/UC_5.1-5.8/UC_5.8.md — the Exc-2 exception line and the STAGE3-024 informal marker, both tagged [BA-CR-45] by this audit.

Status: ✅ Applied.

CR 46

Module/Function: Stage 3 Provisioning — Flow 3H, provisioning live account (sub-account source) · UC: UC_5.8 · Date: 12/8/2026 · Type: REQ update

Before: Read the JSON attachment from the FCM email using Zapier Email Parser to extract the account ID.

After: Delete Flow 3B.2 and all inbound email-parser logic entirely; rithmic_subaccount_id assigned locally from a pre-provisioned bulk pool; institution_approval_status set synchronously with identity_status inside the Flow 3B APPROVED path; new local DB tracking table for the sub-account pool (assigned vs. available) to prevent duplicate assignment.

Doc location: Extensively documented under the informal tag STAGE3-037/STAGE3-039 (CR-20260813-001) across UC_5.1.md, UC_5.2.md, UC_5.3.md (deprecation notice), UC_5.4.md, UC_5.5.md, and most fully in UC_5.8.md §BR_5.8.3 (bulk-pool assignment, transaction-lock requirement, Ironbeam_Account_Pool table). The UC_5.8.md STAGE3-037 marker was additionally tagged [BA-CR-46] by this audit.

Status: ✅ Applied. No References/CR/ dated folder maps to this CR_ID — the two 2026-08-13 folders (dots-veriff-parallel-before-rippling, revert-dots-to-flow3a) and the 2026-08-12 universal-veriff-ironbeam-waived folder were individually re-read this audit and confirmed to describe different (related but distinct) topics: Dots/Veriff/Rippling call-sequencing, not the FCM-email-parser-to-bulk-pool change. Per the user's explicit rule, these folders are left unrenamed rather than force-mapped.

CR 47

Module/Function: Checkout Step 5 — Call calculate-cart · UC: UC_2.6.1 · Date: 13/8/2026 · Type: REQ update

Before: Calculate cart + sanction gate checked together in one step.

After: Sanction check runs when choosing Country/State; calculate-cart call moved to clicking "Next".

Doc location: docs/BA/UC_2.1-2.8/UC_2.1-2.6_v1.md §5 Basic Flow — BR_2.6.1.1: Sanctions Pre-Check & Tax Calculation Timing, tagged [BA-CR-47] by this audit. CSV's own Link docs column resolves directly to this section.

Status: ✅ Applied.

CR 48

Module/Function: Checkout Step 0 — Call system status (FATF Greylist handling) · UC: UC_2.1.1 / UC_2.1.2 · Date: 13/8/2026 · Type: REQ update · Assessment: Nice to have (Day 2)

Before: Not available.

After: GET /system/status returns required_flow: 'KYC_FIRST' instead of 403 for FATF Greylist countries; frontend renders a Veriff-initiation button instead of payment methods; POST /calculate-cart and POST /execute-checkout require a valid Approved Veriff session_id before charging for Greylist billing countries; these users skip KYC again when going live.

Doc location: Confirmed via targeted search — no matching content anywhere in docs/BA. WBS/Doc/Design update status are all "Todo" in the CSV, consistent with this being unbuilt.

Status: ⬜ Not yet in docs — no doc edit made. Per the user's original instructions this is reported rather than stubbed, since it is explicitly "Nice to have (Day 2)" and has zero prior BA content anywhere to anchor a cross-reference against (unlike CR_ID=51/52/55, which had at least a Figma link and clear scope to stub).

CR 49

Module/Function: Stage 2 Dashboard SIM — Soft/Hard breach % · UC: UC_4.10.1 / UC_4.10.2 · Date: 14/8/026 (CSV typo — likely 2026) · Type: New REQ

Before: Fixed formula — SIM_Stop = 7.5%, SIM_Target = 14% hardcoded.

After: New Zapier Table C fields SIM_stop_percent (default 7.5%) / SIM_target_percent (default 14%) — Ops-editable, no longer hardcoded.

Doc location: docs/BA/UC_4.1-4.17/dashboard_sim/UC_4.10.1/UC_4.10.1_v1.md §BR_4.10.1.6 and UC_4.10.2_v1.md, both cited as CR-20260820-001. Folder References/CR/2026-08-20_CR49_sim-stop-percent-table-c/ already renamed.

Status: ✅ Applied.

CR 50

Module/Function: Stage 1, Step 5 — Email and confirm-email field, domain block · UC: UC_2.6.1 · Date: 15/8/2026 · Type: REQ update

Before: Does not limit the domain of the email.

After: Block domain @stacktrading.com; inline message "Stacktrading email addresses are not allowed for this field."

Doc location: docs/BA/UC_2.1-2.8/UC_2.1-2.6_v1.md — BR_2.6.1.10: Company Email Domain Block, cited as CR-20260815-001. CSV's own Link docs column resolves directly here. Folder References/CR/2026-08-15_CR50_company-email-domain-block/ already renamed.

Status: ✅ Applied.

CR 51

Module/Function: Stage 1, Step 6 — Apply Promo Code, subtotal display · UC: UC_2.7.8 · Date: 15/8/2026 · Type: REQ update · Assessment: Must have but can do later

Before: Not available.

After: If a promo code is applied, display a Subtotal field directly below the promo code field (Figma node-id=9316-113269).

Doc location: docs/BA/UC_2.1-2.8/UC_2.7-2.8_v1.md — new BR_2.7.8.3: Subtotal Field Displayed Below Applied Promo Code, added this audit as a stub ([BA-CR-51]), since zero prior content existed. Status callout: "Stub added 2026-08-21 audit, pending BA write-up." Open item: exact field position/formatting needs BA confirmation against the Figma frame.

Status: 🆕 Stub added this audit.

CR 52

Module/Function: Stage 1, Authentication — Employee login, Google SSO permission gate · UC: UC_3.2 · Date: 15/08/2026 · Type: REQ update

Before: All @stacktrading.com employees can log in via Google SSO — domain match alone is the gate.

After: Only employees with an assigned Workspace group/permission can log in — Auth0 Admin SDK/Directory API fetches groups/isDomainAdmin, a post-login Action injects them as custom claims and maps specific groups to Auth0 roles; denial UX for a domain-matched-but-groupless employee is unspecified.

Doc location: docs/BA/UC_3.1-UC_3.2/UC_3.1_UC_3.2_Login.md — new BR-05: Google SSO Gated by Assigned Permission (Group Membership), added this audit as a stub ([BA-CR-52]). Open items: exact permission-group/role list; denial UX; interaction with the existing MFA Passkey step (BR-07).

Status: 🆕 Stub added this audit.

CR 53

Module/Function: Stage 1, Step 6 Payment — Flow 1 Provisioning Pipeline, is_founder derivation · UC: UC_2.8.2 · Date: 16/8/2026 · Type: REQ update

Before: is_founder inserted at transaction success based on Global_Var_Founder_Cohort (Table C) — a global switch, not price-based.

After: is_founder now derived by comparing the price the user actually paid against the Founder Price for their tier (Table J) — if they paid founder price, is_founder = TRUE.

Doc location: docs/BA/UC_2.1-2.8/UC_2.7-2.8_v1.md preamble and §"Founder Cohort check", cited as CR-20260820-002. Folder References/CR/2026-08-20_CR53_founder-flag-derivation-by-price-paid/ already renamed.

Status: ✅ Applied.

CR 54

Module/Function: Stage 2, Notification — Notification center, Billings & Subscriptions category · UC: UC_4.7.2 và UC_4.12.4 · Date: 15/08/2026 · Type: New REQ

Before: Not available.

After: New "Billings & Subscriptions" category, Flow 22 fires two WebSocket events: Payment Failure (WARN) and End-of-Month Downgrade (CRITICAL), each with a specified JSON payload.

Doc location: docs/BA/UC_4.1-4.17/dashboard_live/UC_4.12.4/UC_4.12.4_v1.md — BR_4.12.4.1 event-mapping table, marked 🆕 and cited CR-20260817-003 (the folder/index ID was itself corrected during a prior audit pass — originally self-declared -001, colliding with the FAQ CR, renumbered to -003). Folder References/CR/2026-08-17_CR54_billing-subscriptions-notification-category/ already renamed.

Status: ✅ Applied.

CR 55

Module/Function: Step 6 Payment — Apply Promo Code, 1-to-1 product mapping · UC: UC_2.7.8 · Date: 18/8/2026 · Type: (blank in CSV) · Assessment: Must have but can do later

Before: Not mapped to any specific product ID or transaction type.

After: Each promo code maps 1-to-1 to exactly one product ID (EVAL_L1, EVAL_L2, EVAL_L5, RESET, REBUY, EXTENSION, MARKET_DATA); a code created to waive one fee cannot be used against an unrelated fee.

Doc location: docs/BA/UC_2.1-2.8/UC_2.7-2.8_v1.md — new BR_2.7.8.7: Promo Code Mapped 1-to-1 to a Specific Product ID, added this audit as a stub ([BA-CR-55]). Open items: promo_codes schema needs a new product_id column (not yet reflected in the existing schema table); exact mismatch error copy unspecified.

Status: 🆕 Stub added this audit.

CR 56

Module/Function: Marketing site — FAQ section, all screens · Date: 13/08/2026 · Type: REQ update

Before: Each screen has its own FAQ category; items tagged per category and queried by category.

After: New Sanity settings tab listing every static page; each page selects individual items from a single master "All FAQ list" (per-item selection, not per-category).

Doc location: docs/BA/UC_1.1-1.9/UC_1.8.md — new §4.9 "Page-FAQ Mapping (canonical)" and BR_1.8.8.5, cited CR-20260817-001. CSV's own Link docs column resolves here. Folder References/CR/2026-08-17_CR56_faq-page-item-mapping-sanity/ already renamed.

Status: ✅ Applied.

CR 57

Module/Function: Comparison Hub — Config through Sanity · UC: UC_1.8.3 · Date: 13/08/2026 · Type: REQ update

Before: Hardcode the entire screen.

After: Hardcode layout/data for now; the 20+ battle cards configured via Sanity (each card = display name + link target, freely addable/removable, auto-laid-out).

Doc location: docs/BA/UC_1.1-1.9/UC_1.8.md — BR_1.8.3.8 (new battle-card grid rule), cited CR-20260817-002. Note this CR also reverted pricing data on this specific page back to hardcode (a related but separate decision scoped only to Comparison Hub, not overriding CR-20260731-001 elsewhere). Folder References/CR/2026-08-17_CR57_comparison-hub-battlecards-sanity/ already renamed.

Status: ✅ Applied.

CR 58

Module/Function: Homepage — Live Cryptographic Ledger, scroll/fetch UX · UC: UC_1.3.2 · Date: 13/08/2026 · Type: REQ update

Before: Auto-scroll pauses on hover (background fetch continues invisibly); manual scroll-down terminates auto-scroll with a "Resume Live Feed" button.

After: Fetching bound to motion — polling stops on any pause, resumes with one immediate fetch on release; hover-pause and manual-scroll-pause reframed as two distinct, non-overlapping states with an edge-triggered hover-arming rule; resume-while-cursor-still-inside must not self-cancel.

Doc location: docs/BA/UC_1.1-1.9/UC_1.1-1.6_v1.md §5.5/§5.6, new BR_1.3.2.5/BR_1.3.2.6, extensively logged in the UC's own changelog (2026-08-14 entry) as a "Team-initiated UX adjustment, confirmed by client."

Status: ✅ Applied (already fully documented with its own dedicated changelog entry; no [BA-CR-58] tag needed).

CR 59

Module/Function: Checkout — Stage 1, exit/navigation UX (back button, progress bar, browser history) · UC: All UC for Checkout · Date: 18/8/2026 · Type: REQ update · Assessment: Must have but can do later

Before: No back button; no action on clicking the progress bar; no specific logic for browser-back button.

After: Three related changes — (1) remove the "X" exit from all steps, render a Back arrow only on Step 1; (2) make progress-bar segments clickable to jump back to any completed (gold) step, but not forward to an incomplete step; (3) push each step to browser history so native back-button navigates exactly one step backward, not out of checkout. Client's own text flags this as still partially open — Step 7 (Claim Account → Interstitial) back-navigation is explicitly "we will check this again," and the progress-bar/back-button interaction on Step 1 needs its own UX confirmation.

Doc location: Confirmed via targeted search — no matching content anywhere in docs/BA. WBS/Doc/Design update status are all "Todo."

Status: ⚠️ Needs BA input — not stubbed this audit. This is explicitly flagged rather than stubbed because it's a large, multi-part UX change (3 distinct behaviors across every Checkout step) where the client's own CSV text still contains open self-questions ("We will check this again"); a partial stub risks committing to a UX decision the client hasn't finished making. Recommend a dedicated BA session before writing this into UC_2.1-2.8.

CR 60

Module/Function: Dashboard SIM — Failure & Recovery, Hard Breach Level Stop · UC: UC_4.10.2 · Date: 21/8/2026 · Type: REQ update · Assessment: Must do

Before: Both Reset and Rebuy exist — Reset (within Discount_Code_Duration_Days) reuses the current account/clears trade data; Rebuy (expired window) deletes the old account and provisions a new one; the choice depends solely on Discount_Code_Duration_Days.

After (as entered in CSV): "1. Only reset / 2 + 3. The time to " — the CSV's After-changes text is truncated/garbled mid-sentence for items 2 and 3. It's clear that Rebuy is being removed in favor of Reset-only, but the replacement rule for when to delete the trading account and archive dashboard data (previously governed by Discount_Code_Duration_Days) is not stated.

Doc location: No corresponding doc content — confirmed no docs/BA file reflects a Reset-only consolidation for Hard Breach yet. This is the CSV's newest row (2026-08-21, the audit date itself), consistent with it being freshly entered and possibly not yet fully typed out by the BA.

Status: ⚠️ Needs BA input — the CSV text itself is incomplete ("The time to " trails off with no continuation). Per the user's hard rule, this audit does not infer or write in a completion of the client's sentence; it is reported here as an open question for the BA to resolve directly in the CSV (source of truth), then re-flow into docs afterward.

---

Blank-CR_ID rows

Six CSV rows have no CR_ID value at all. Per CSV row order (not renumbered — the internal BA CSV is the source of truth and this document does not assign it new IDs):

(blank) CME market data ingestion

Module/Function: Dashboard SIM, Soft breach — ME data (CME Reference Data Ingestion cron) · UC: UC_4.9.1 · Date: 5/8/2026

Before: Original cron calls GET /v3/tradingSchedules?symbol=X once per whitelisted symbol (~31 calls/day) against the CME Reference Data API.

After: Replaced with a 2-endpoint design — 1 call to GET /v3/tradingHours (all quadrants/schedules) trimmed to a rolling 2-week window, plus 1 GET /v3/productDetails?masterSymbol={SYMBOL} call per whitelisted symbol to resolve globexGroupCode and match it to a quadrant/schedule. Adds a 7-day rolling DB failover if the 01:00 UTC cron fails to reach CME. Same downstream consumers (Dynamic Timekeeper, Soft Lock unfreeze, dashboard /system/market-status, holiday/halt awareness).

Doc location: docs/BA/UC_4.1-4.17/dashboard_sim/UC_4.9.1/UC_4.9.1_v1.md exists but was not verified this audit to contain the new 2-endpoint tradingHours/productDetails design — this is a large, detailed technical rewrite (the CSV's Before/After text alone runs to ~150 lines) that warrants its own dedicated read-through rather than a quick stub.

Status: ⬜ Not yet in docs (unverified/likely absent) — flagged for a dedicated follow-up pass, not stubbed given the size and technical density of the change.

(blank) Failed-user checkout flow

Module/Function: Checkout, Step 5 — flow for Failed-status users · UC: From UC_2.6.1 onwards · Date: 08/07/2026

Before: Flow is unclear — Failed-status users can continue but there's no logic for pricing or account creation.

After: Full Simulation-Failure (Reset) pricing/execution flow — identical four-way pricing branch (founder × within/expired window) later formalized as CR_ID=38 above. No email sent; bypasses Claim Account, goes straight to Interstitial; wipes failed state on payment.

Doc location: Same as CR_ID=38 — this row is CR_ID=38's earlier, more granular precursor (same content, split into "Failed" and "Terminated" sub-cases before CR_ID=38 consolidated them). See CR_ID=38 above for doc status.

Status: 🟡 Partially documented — superseded/consolidated by CR_ID=38; not separately stubbed to avoid duplicating the same open BR gap twice.

(blank) Terminated-user checkout flow

Module/Function: Flow for Terminated-status users · UC: From UC_2.6.1 onwards · Date: 08/07/2026

Before: Flow is unclear — Terminated-status users can continue but there's no logic for pricing or account creation.

After: Live Level 1-24 Failure (Re-Buy) — same four-way founder/window pricing branch, but backend archives the old live record and provisions a fresh simulation account (rather than resetting in place).

Doc location: Same as CR_ID=38 — this is the Live-side counterpart to the Failed-user row above, both folded into CR_ID=38's consolidated pricing rule.

Status: 🟡 Partially documented — superseded/consolidated by CR_ID=38; see CR_ID=38 above.

(blank) Founding mentor

Module/Function: Founding mentor · After changes (only field populated): "Stage 2 - Dashboard & Fomula"

Doc location/Status: This row has no Before-changes, UC_ID, Date, Type, or Source — it reads as a placeholder/section-divider row in the CSV rather than an actual change request (WBS/Doc/Design status all "Todo," every effort column blank). Not a real CR to action.

Status: ⬜ Not applicable — likely a CSV structural artifact, not a genuine CR. Flagged for the BA to confirm/remove at the source (not removed here, per the no-write-back rule).

---

Cross-scheme reconciliation notes

• Three ID schemes coexist in this project and this audit did not collapse them into one: (1) this CSV's plain CR_ID numbers — the authoritative register; (2) CR-YYYYMMDD-NNN, a date-based scheme used throughout docs/BA and indexed in References/CR/_CR_INDEX.md, each backed by a References/CR/<date>_... folder; (3) informal STAGE3-0NN/STAGE1-0NN markers used inline in some UC docs (mostly Stage 3 KYC/Live-onboarding docs), which predate and overlap with scheme (2) in places (e.g. STAGE3-037 is CR-20260813-001). Where a CSV row already had solid coverage under scheme (2) or (3), this audit added a [BA-CR-N] tag only where the existing citation didn't already make the traceability obvious, to avoid over-tagging.
• Folders in References/CR/ renamed to {date}_CR{ba_id}_{slug} this project (32 of ~53 total folders) map cleanly to a CSV CR_ID. The remaining unrenamed folders were individually checked against the CSV and confirmed not to correspond to any single CSV row (they document business changes agreed directly in BA/client sessions that were never separately logged as a numbered row in this CSV — e.g. the KYC/Dots/Rippling sequencing changes, the level-1-form-native-dashboard change, etc.). These are correctly left as-is per the explicit instruction not to force a mapping.
• This document adds no new References/CR/ folders and made zero edits to the internal BA CSV. All CSV content quoted above is read-only excerpting for audit purposes.