UC_4.6.4: Settings — Controls (AI chat & Reduce motion)

Document References

Design asset note: the frames above are not yet committed to References/Wireframe/Stage 2/Settings/; this document cites the Figma node until the BA commits them (Ref: QnA_init_docs.md C-18(b), carried over from A-19(b)).

1. Overview

Out of scope — "Concierge": the client names this category "Controls & Concierge" and the WBS UI note reads "Persistent Controls block (2 toggles) + Concierge entry point", but no source (RFQ V7, Dashboard V7, Zapier V7, wireframe) defines what the Concierge entry point is, what it does, or which endpoint serves it, and the client's own QnA row records the point as still ambiguous. This UC therefore covers only the two toggles. The unrelated "Digital Concierge" of Zapier Flow 38 (Discord bot monitoring #the-pit) belongs to UC_4.5.2 and is not this control (Ref: QnA_init_docs.md C-03, BA confirmed 2026-08-12).

Design: Figma — Controls & Concierge, node 7878-116828

2. Trigger

• The trader clicks the user chip in the sidebar footer (displaying their initials + level, e.g. SD / Lvl 5) and selects Settings from the dropdown (Ref: UC_4.1.2 §2 Screen Description, row 6) → the Account screen renders and the Controls panel is visible immediately, on whichever tab is active (Ref: BR_4.6.4.1).
• The trader flips either toggle (Ref: BR_4.6.4.4).

3. Pre-conditions

• The trader is authenticated and inside the Dashboard shell (Ref: UC_4.1.1 §1 Overview).
• A Users record exists for the trader, carrying ai_enabled (Ref: BR_4.6.4.2). The Reduce Motion toggle has no server-side pre-condition — it reads the device's local store and works even before any backend call returns.

4. Post-conditions

• Desk Manager: the Users record reflects the flipped value in ai_enabled. No other column is touched (Ref: BR_4.6.4.2).
• Reduce Motion: the value is persisted in the browser's local store on the trader's current device. No backend record changes — no API call is made and no column is written (Ref: BR_4.6.4.2).
• Both preferences apply immediately in the current session with no page reload. The Desk Manager value then applies on every subsequent session and every device the trader logs in from; the Reduce Motion value applies on every subsequent session of that device/browser only (Ref: BR_4.6.4.5).
• Downstream consumers observe the new value: the Desk Manager widget (Ref: BR_4.6.4.6) and every animated surface of the Dashboard (Ref: BR_4.6.4.7).

5. Basic Flow — Toggle Desk Manager

1. The trader lands on the Account screen. The frontend calls GET /profile and reads ai_enabled from the response; the Reduce Motion position comes from the device's local store, not from this call (Ref: BR_4.6.4.2).
2. The Controls panel renders both toggles at their stored positions, each with its own tooltip icon (Ref: BR_4.6.4.3).
3. The trader flips the Desk Manager toggle.
4. The toggle moves to its new position immediately and is set to Disabled while the request is in flight (Ref: BR_4.6.4.4).
5. The frontend calls POST /ai-preference with {user_id, ai_enabled}.
6. On HTTP 200: the toggle is re-Enabled at its new position. No success toast and no confirmation popup is shown (Ref: BR_4.6.4.4).
7. The Desk Manager widget on the Command tab reacts to the new value (Ref: BR_4.6.4.6).

6. Alternative Flow — Toggle Reduce Motion

🔴 Changed 2026-08-24 — this flow no longer touches the backend. The client's answer is verbatim: "Reduce Motion: There is no backend API for this." The endpoint POST /accessibility-preference and the stored field ui_preferences.reduce_motion are withdrawn; the frontend owns this toggle end to end (Ref: BR_4.6.4.2).

1. Step 1 of §5 is identical, except that the Reduce Motion toggle takes no value from GET /profile — its position is read from the device's local store (Ref: BR_4.6.4.2).
2. Step 2 of §5 is identical — the panel renders both toggles with their tooltips (Ref: BR_4.6.4.3).
3. The trader flips the Reduce Motion toggle.
4. The toggle moves to its new position and stays Enabled. There is no request in flight, therefore no in-flight guard and no Disabled interval (Ref: BR_4.6.4.4).
5. The frontend writes the new value to the device's local store. No API call is issued — nothing about this flip reaches the backend (Ref: BR_4.6.4.2).
6. No success toast, no confirmation popup — the client explicitly ruled out the blocking-modal pattern used by the breach/reset flows (Ref: BR_4.6.4.4).
7. The new motion rule set applies across the Dashboard immediately, without a page reload (Ref: BR_4.6.4.7, BR_4.6.4.8).

Because nothing leaves the browser, this flow has no network failure path: no error toast, no position revert, and no state in which the rendered toggle and the persisted value disagree (Ref: §7 Exceptional Flow row 3).

7. Exceptional Flow

8. Business Rules

BR_4.6.4.1: Persistent Panel — Rendered on Every Settings Tab

The Controls panel sits below the tab list of the Account screen and is rendered on all four tabs of that screen, not just one (Source: References/WBS/[BA Internal] Stacktrading.csv line 176 — "from a persistent panel shown across all Settings tabs"; confirmed by the design frames, which show the identical panel on both the Profile & Preferences and the Billing tab).

Switching tabs never re-mounts, resets, or hides the panel, and never changes either toggle's position. The tab list itself and its tab → owning UC mapping belong to UC_4.6.2 BR_4.6.2.1, not to this UC.

BR_4.6.4.2: Data Contract — One Toggle Is a Backend Call, the Other Is Not

🔴 Changed 2026-08-24 (CTRL-EP-01 closed). The two toggles are not symmetric. v1–v3 specified a matching pair of write endpoints; the client's answer withdraws one of them outright: "Reduce Motion: There is no backend API for this. UI animation performance depends entirely on the specific hardware the trader is currently using." — while reaffirming the other: "AI Desk Manager Toggle: This must be a backend call… If the user turns this off, the backend must know immediately so we halt the background worker and stop spending API tokens to generate unused text."

A consolidated-endpoint proposal was raised in the same exchange and was not adopted. Ahead of this answer the BA put a single PUT /profile design to the client — build neither POST /ai-preference nor POST /accessibility-preference, and push both toggles as booleans inside one ui_preferences object ({"ui_preferences": {"desk_manager_enabled": true, "reduce_motion": true}}) — noting that RFQ V7 already specifies an AI Preference Toggle API while nothing in any source specifies one for Reduce Motion. The client's reply does not take that route: Reduce Motion loses its API entirely and the Desk Manager stays a backend call on the RFQ V7 contract. The consolidated proposal is therefore withdrawn and desk_manager_enabled is not a field in this specification — recorded here so the option is not re-opened without a new client decision (Ref: QnA_init_docs.md — Trả lời QnA 2026-08-24).

✅ Re-confirmed 2026-09-03 — [CTRL-EP-03] and [CTRL-EP-04] are now formally closed. Asked again which endpoint and which field the Desk Manager uses, the client answered: "The AI Preference Toggle has a dedicated backend endpoint because it controls core operational logic and costs, explicitly telling the Node.js middleware to stop pinging the Gemini API." Two consequences, both of which this document already specifies — the value of the answer is that they can no longer be re-opened:

• The endpoint is POST /ai-preference ([CTRL-EP-03] closed). The consolidated PUT /profile route is not adopted.
• The field is the flat column users.ai_enabled ([CTRL-EP-04] closed), not ui_preferences.desk_manager_enabled. The Gemini background worker therefore queries a boolean column, not JSONB — no change to the DB schema or the worker's query is needed.

The same answer explains the leftover ui_preferences column: it is kept "strictly as a future-proofing measure" with "no active parameters to parse… today", so BE must "maintain this column as an optional JSON object" for future frontend-only cross-device layout preferences. It is dormant by design — no toggle in this UC belongs in it (Ref: BR_4.6.2.15).

Desk Manager — confirmed by source, by the client, and by the final contract of 2026-08-27. POST /ai-preference and the ai_enabled column are confirmed by RFQ_ Stack Trading Prop Tech V7.pdf §API table ("AI Preference Toggle") and Zapier Integration V7.pdf §Users table schema. The 2026-08-24 answer gave the reason the call is mandatory rather than optional — the flag drives a background worker that costs money while it runs (Ref: BR_4.6.4.6) — and the 2026-08-27 answer fixes the contract verbatim:

POST /ai-preference
{
  "user_id": "UUID",
  "ai_enabled": true
}
→ 200 OK

The endpoint is explicitly not folded into PATCH /profile ("không gộp chung vào profile nữa"), which is what keeps the profile endpoints reduced to a single field each (Ref: BR_4.6.2.15).

Reduce Motion — three things are withdrawn, not merely deferred:

Read path — two endpoints, two distinct jobs (confirmed 2026-08-28). The Desk Manager needs both, and they are not interchangeable:

ai_enabled must be added to the GET /profile response — mandatory, and the only outstanding backend item in this UC. The endpoint currently returns {profile_photo_url, email, phone_number, ui_preferences} (Source: RFQ_ Stack Trading Prop Tech V7.pdf §Page 36), which does not include it. The client's wording is unambiguous about the severity: having the field is "bắt buộc để Frontend khởi tạo đúng trạng thái ON/OFF của toggle Desk Manager ngay lúc load màn hình". Until BE ships it, this toggle cannot be built correctly (Ref: QnA_init_docs.md C-04).

Where it sits in the response: top-level ai_enabled, not inside ui_preferences. The 2026-08-28 answer allows either ("có trường ai_enabled (hoặc nằm trong ui_preferences)"). This document specifies the top-level field, because the write side already targets the dedicated users.ai_enabled column rather than the JSON blob — nesting the read inside ui_preferences would split one value across two shapes. ui_preferences remains dormant with no reader or writer anywhere in the Settings module (Ref: BR_4.6.2.15) — and the client confirmed on 2026-09-03 that this is intended, which removes the alternative: nesting ai_enabled inside a column the client describes as having "no active parameters to parse" is no longer a legitimate reading of the answer. Top-level ai_enabled is now the only shape. The same answer's alternative endpoint name GET /user-profile is likewise not adopted — GET /profile is the name every other UC in this cluster already reads from.

Local persistence key — confirmed 2026-08-27. The Reduce Motion value is stored in localStorage under the key stacktrading.reduce_motion, type Boolean, so it survives page reloads and new sessions on that device. The v4 caveat that the key name was BA-proposed and "not a client-confirmed contract" is withdrawn — the key is now part of the specification. Absence of the key means the trader has never set the toggle on this device, which resolves to the default Off (Ref: BR_4.6.4.5).

Boundary with UC_4.6.2 is unchanged. UC_4.6.2 still neither reads nor writes ui_preferences, even though the RFQ's Update User Profile signature lists it as an optional parameter (Ref: BR_4.6.2.11; QnA_init_docs.md A-18). Nothing moves to UC_4.6.2 as a result of this change — ui_preferences simply loses its only documented consumer, which the client confirmed on 2026-09-03 is the intended end state ([CTRL-EP-05]).

BR_4.6.4.3: Labels and Tooltips

Both strings are client-authored and are used verbatim (Source: QnA from clients — Settings, Controls & Concierge UI/UX row, Adrian Stack 2026-08-10). The trailing period is intentional here: these are descriptive tooltips, not error messages, so the no-trailing-period rule for error strings does not apply.

Label change: the toggle previously called AI Chat in the RFQ and in the earlier wireframes is renamed Desk Manager, aligning the Settings label with the widget name used on the Command tab. The underlying data contract is unchanged — still users.ai_enabled via POST /ai-preference (Source: same QnA row — "LABEL CHANGE: rename the toggle in the Settings / Controls section from 'AI Chat' to 'Desk Manager'… The underlying data contract is unchanged").

Tooltip trigger and dismissal behaviour follow Ref: CR-10.

BR_4.6.4.4: Immediate Commit on Flip — No Save Button, No Confirmation

Each toggle is autonomous. Flipping it is the whole interaction:

• Commit point: the flip itself. There is no [Save Changes] button, no [Cancel], and no staged/dirty state for these two controls (Source: QnA from clients — Settings, Controls & Concierge Trigger row — "applied immediately (real-time), no reload needed").
• No confirmation popup on either toggle, in either direction. The client explicitly ruled out the blocking-modal pattern used by the breach/reset flows (Source: same QnA category, Definition row — "NO confirmation popup needed - no blocking modal like the breach/reset pattern").
• Optimistic display (Desk Manager): the toggle moves to its new position on click, before the response returns, so the interaction reads as instant.
• In-flight guard (Desk Manager only): while its request is outstanding, that toggle is Disabled. This prevents a rapid double-click from issuing two writes whose responses could land out of order (Ref: §7 row 6). The other toggle stays Enabled — the two controls are fully independent and never block each other.
• Reduce Motion has no in-flight state at all. It issues no request, so it is never Disabled, never optimistic (the local write is the commit), and never reverts. A rapid double-flip simply lands on whichever position the trader stopped at — there is no ordering problem to guard against (Ref: BR_4.6.4.2).
• On failure: applies to the Desk Manager only — the toggle reverts to its previous position and an error toast is shown (Ref: §7 rows 2 and 5). Reduce Motion has no failure path (Ref: §7 row 3).
• On success: no toast on either toggle. Ref: TS-DASH-01 is reserved for a tab's [Save Changes] action and does not fire here.

Interaction with the host tab's form. The panel is completely independent of whichever tab is rendered next to it:

• Flipping a toggle does not mark the host tab's form dirty (Ref: BR_4.6.2.8).
• Flipping a toggle while the host tab's form is dirty does not trigger the unsaved-changes warning Ref: CF-01 — no navigation occurs and no staged form value is touched. The form keeps every entered value and its [Save Changes] button keeps its current state (Ref: BR_4.6.2.9).

BR_4.6.4.5: Preference Scope — Desk Manager Per User, Reduce Motion Per Device

🔴 Changed 2026-08-24 (C-15 split). v1–v3 specified both values as per-user, server-side. That now holds for the Desk Manager only. The client's stated reason for making Reduce Motion device-local is a hardware one, not a storage-convenience one: "UI animation performance depends entirely on the specific hardware the trader is currently using. A user may need to reduce motion on a weak travel laptop but keep the animations active on their powerful home desktop." A per-account value would be wrong behaviour, not merely a different implementation — it would carry the laptop's setting onto the desktop.

Consequences:

• Desk Manager. localStorage is never the source of truth for this toggle; the Users record is.
• Reduce Motion. The device's local store is the source of truth. Turning it on for a travel laptop leaves the desktop untouched, and vice versa. There is no "sync my accessibility settings" behaviour and none is expected.
• A new device, a new browser, or a cleared browser store starts Reduce Motion at its default (below) — the trader sets it once per device. This is not data loss: nothing was ever promised to persist beyond that device.
• Both values apply to the authenticated Dashboard only (UC_4.x). The public marketing site (UC_1.x) is out of this UC's scope and does not read either value — even though the Reduce Motion value now lives in the browser rather than the database; if the marketing site needs motion reduction, that remains an OS-level prefers-reduced-motion concern at the CSS layer, unrelated to this toggle (Ref: QnA_init_docs.md C-14).
• Multi-tab behaviour: if the trader has the Dashboard open in more than one tab, flipping either toggle in one tab does not update the other tab's rendered toggle until that tab is reloaded. Preference changes are not broadcast — not over WebSocket for the Desk Manager, and no cross-tab storage-event sync is required for Reduce Motion. This is accepted behaviour, not a defect: the persisted value is authoritative and the next load in any tab reflects it (Ref: QnA_init_docs.md C-15, as amended 2026-08-24).

Default values — Desk Manager ON, Reduce Motion OFF.

🔴 Reduce Motion default reversed 2026-08-27 — C-07 is superseded. v1–v4 defaulted Reduce Motion to On, on BA instruction of 2026-08-12. That is withdrawn. The new default is Off, and the stated reason is the one this document flagged as the risk of the old default: a new trader must see "đầy đủ hiệu ứng Level-Up Cinematic hoành tráng và nhấp nháy đỏ CRITICAL của Market Status" — the motion-first experience the RFQ's cinematic and motion-reference material is built around. This closes the open question carried since 2026-08-12 and re-raised on 2026-08-24 when the per-device scope made the old default repeat on every machine.

The per-device scope now cuts the other way, and that is the point. Under the old On default, a trader using three machines had to switch the toggle off three times to get the experience the product is designed around. Under Off, the trader who actually needs motion reduction — the "weak travel laptop" case that made this preference device-local (BR_4.6.4.5 opening note) — switches it on for that one machine, and their powerful desktop is untouched. Default and scope now point the same direction: the exception is configured where it applies, and nowhere else.

Once the trader changes a toggle, that choice is what loads afterwards — the Desk Manager choice on every subsequent login anywhere, the Reduce Motion choice on every subsequent session of that same device/browser. Neither is ever re-defaulted by a new session or a level promotion; a new device re-applies only the Reduce Motion default, never the Desk Manager one.

The browser's prefers-reduced-motion (operating-system accessibility setting) is not consulted at any point — neither to seed the first load nor to override the stored value. The default above is fixed (BA decision, 2026-08-12 — Ref: QnA_init_docs.md C-08, which supersedes the earlier OS-seeding proposal). This decision stands after both the 2026-08-24 scope change and the 2026-08-27 default reversal: moving Reduce Motion into the browser puts the OS signal within easy reach of the frontend, but it is still deliberately not read.

⚠️ Note for anyone reading the changelog. The default has returned to the Off value it held in v1, but only half of the v1 behaviour is back. v1 paired Off with seeding from the OS prefers-reduced-motion setting; v2 removed both. v5 restores the Off default and leaves the OS seeding removed — a trader whose operating system requests reduced motion still sees full motion until they flip this toggle themselves. That is deliberate (C-08), not an oversight in the reversal.

✅ The consequence flagged in v3–v4 is resolved, not merely accepted. Those versions recorded that an On default inverted the motion-first presentation the RFQ is built around, and asked for client confirmation. The answer of 2026-08-27 is to flip the default, so the concern no longer applies: a new trader on a new device sees the full motion presentation — the Level-Up Cinematic (BR_4.6.4.8) and the CRITICAL blinking on Market Status (BR_4.6.4.7) — without touching a setting.

What changes for QC: the default test path is now the full-motion path, and the reduced-motion rule set of BR_4.6.4.7 is reached only after an explicit opt-in. Any test written against v1–v4 that assumed a fresh browser starts with motion suppressed is wrong against this version and must be re-baselined.

BR_4.6.4.6: Downstream Effect of ai_enabled

The widget itself is owned elsewhere — SIM: UC_4.8.3 (Ref: BR_4.8.3.3, which already defines the "Disabled in settings" placeholder); LIVE: UC_4.12.3 (not yet documented in this repo). This UC owns only the flag.

Further consequences of turning the Desk Manager off and back on:

• Commentary history is discarded on switch-off. Every card generated before the flag went false is cleared — the toggle does not merely hide the stack, it drops it. When the trader switches the toggle back on, the widget starts from the same empty state a brand-new account sees ("No data available" — Ref: BR_4.8.3.3) and repopulates from scratch as new events fire. There is no archive, no restore, and no way to recover the discarded cards from the UI (Source: BA instruction, 2026-08-12 — Ref: QnA_init_docs.md C-11).
• No backfill. The engine is stateless (Source: RFQ_ Stack Trading Prop Tech V7.pdf §3.2.1). Events that fired while the flag was false generate no commentary and are never replayed. Commentary resumes from the next qualifying event onward.
• No Token Bucket consumption while off. The 10-critiques-per-hour-per-user budget (Ref: BR_4.8.3.2) is only drawn down by an actual LLM call, which does not happen while the flag is false.

Switching the Desk Manager off is therefore destructive to commentary history and not undoable — the only reversible part is the feature itself, not the cards it had already produced.

✅ Re-confirmed 2026-08-24 — the reason the call is mandatory. The client's answer states why the Desk Manager toggle cannot follow the Reduce Motion pattern: "This must be a backend call. The Desk Manager commentary is generated asynchronously by our Node.js backend pinging the Gemini API. If the user turns this off, the backend must know immediately so we halt the background worker and stop spending API tokens to generate unused text." Two requirements follow: (1) the backend is notified immediately on flip — the value cannot be held client-side and reconciled later; (2) the worker is halted, not merely muted — the cost saving is the point of the flag, so an implementation that keeps generating commentary and discards it at the frontend fails this rule.

✅ Confirmed 2026-08-21 (C-10 closed). The branch above is no longer BA-proposed. The answer is verbatim: "skip call hoàn toàn — không gọi Gemini, không trừ token bucket, không push GEKKO_CHATTER." All three consequences are therefore binding, not inferred: (1) no Gemini request is issued while ai_enabled = false, so the LLM cost of a trader with the toggle off is zero; (2) the Token Bucket of BR_4.8.3.2 is not drawn down; (3) no GEKKO_CHATTER message is published at all — the widget's "Disabled in settings" placeholder is driven by the flag the frontend already reads, never by an empty push. The flag check happens in the worker, before the LLM call — hiding the output at the frontend while still calling Gemini is explicitly not the specified behaviour.

BR_4.6.4.7: Reduce Motion — Rule Set

When Reduce Motion is On — a value the frontend reads from the device's local store, never from the backend (Ref: BR_4.6.4.2) — the Dashboard applies the following three rules to every animated surface it renders (Source: QnA from clients — Settings, Controls & Concierge Definition + Business logic rows, Adrian Stack 2026-08-10):

This is a scope directive by category, not an exhaustive component list — the client stated the rule set, not the inventory. Every UC that owns an animated surface is responsible for honouring these three rules; the rule set is defined once here and referenced, never restated.

Known downstream surfaces already documented in this repo (non-exhaustive — any animation added later falls under the same rules automatically):

Animations already in progress when the toggle is flipped to ON settle at their final state rather than rewinding or cutting mid-frame.

Turning the toggle back OFF restores normal motion from that moment forward; animations that were suppressed while it was ON are not replayed.

BR_4.6.4.8: Reduce Motion and the Level-Up Cinematic

🔴 Reversed 2026-08-21 (C-13 re-answered). v1/v2 specified that reduce_motion = true skipped the cinematic entirely — the WebM/HEVC background and Lottie overlays were "not loaded at all", the staggered text reveal and animated QR were not played, and the Certificate modal rendered directly "at the state the cinematic would have concluded on". That is withdrawn. The answer is: "Cũng hiện motion, nhưng hiện motion chạy từ Certificate modal trực tiếp" — the motion still plays; what changes is where it starts from.

The Level-Up celebration is the one surface where the three rules of BR_4.6.4.7 do not apply as written. This rule overrides them for this surface only.

When a LEVEL_PROMOTION event fires while Reduce Motion is On on the device the trader is using (Ref: BR_4.6.4.5 — the same trader may see the full pre-roll on another device):

1. The frontend still redirects the trader to the Command tab, exactly as it does with motion enabled (Source: QnA from clients — Settings, Level-Up & Certificate UI/UX row, Adrian via Figma comment).
2. The trader lands directly on the Certificate modal. The full-screen cinematic is not played as a pre-roll ahead of it. The Certificate is the sequence's terminal state in any case — "At the conclusion of the animation (the final certificate state), the UI will present an expanded share menu" (Source: Level Up Cinematic Scene Handling.pdf §3) — so nothing in the narrative is lost by starting there.
3. The motion still runs, anchored at that modal. Reduce Motion On does not mean "no animation" on this surface: the celebration is preserved and plays from the Certificate modal rather than building up to it.
4. Every action on the modal is unaffected: Share (X, LinkedIn, Facebook, Reddit, Copy Link), Download Certificate, and the Redacted PII toggle all behave as normal.
5. The public shareable route (/milestone/[unique-id]) is unaffected in every case. It is an unauthenticated route (Source: Level Up Cinematic Scene Handling.pdf §2), so it never reads the trader's Reduce Motion value — which in any case now lives only in the trader's own browser and is not available to any other visitor's session (Ref: BR_4.6.4.2) — and always mounts the full cinematic component — a visitor's experience of a shared milestone does not depend on the owner's accessibility preference.

The trader therefore loses neither the milestone nor the celebration — only the run-up to it.

⚠️ Open — which layers play, and where they render. The answer settles that motion plays and where it starts; it does not enumerate what plays. The sequence is a live composite of five layers — pre-rendered WebM/HEVC background with alpha, Lottie signature/vector overlays, a Framer Motion dynamic data layer, a dynamically generated QR resolving to PolygonScan, and a client-orchestrated audio stack (Source: Level Up Cinematic Scene Handling.pdf §1). Four questions must be closed before this surface can be built:

#	Question	Why it matters
1	Does the motion render inside the modal frame, or full-screen behind it?	Determines the component boundary and the modal's own entry animation
2	Which of the five layers play — all of them, or the Framer Motion / Lottie layers without the WebM background?	The < 300 KB performance budget and the RFQ's "reduced-motion guards" were what drove the v1 "load nothing" rule. If the background video now loads regardless, that budget no longer holds
3	Does the audio layer play?	Autoplay is gated behind a user-interaction unmute (Level Up Cinematic Scene Handling.pdf §1), and unexpected sound is exactly the class of thing a reduced-motion preference is normally taken to suppress
4	If motion plays in both toggle states, what does the toggle actually change on this surface beyond skipping the pre-roll — and is a distinct reduced variant needed at all?	Determines whether the cinematic needs one build or two

This UC owns the flag, not the cinematic. The four answers belong in the Level-Up & Certificate UC when it is authored; this rule records what has been decided so far and must be re-read there (Ref: QnA_init_docs.md C-13). Note also that Level Up Cinematic Scene Handling.pdf is not yet registered in _SOURCE_MANIFEST.yaml — a BA follow-up outside this UC.

BR_4.6.4.9: Identical for SIM and LIVE — No Environment Branching

Both toggles behave identically for SIM (Evaluation) and LIVE (funded) accounts: same labels, same tooltips, same endpoints, same storage, same downstream effects (Source: QnA from clients — Settings, Controls & Concierge category, LIVE column: "Same as SIM for all 3 controls. Same AI engine, same toggle logic").

No rule in this UC is gated on account type, level, or environment. The ai_enabled flag reaches whichever Desk Manager widget applies to the trader's environment — SIM UC_4.8.3 or LIVE UC_4.12.3 — through the same flag (Ref: BR_4.6.4.6).

BR_4.6.4.10: Toggles Stay Available Regardless of Account Status

Both toggles remain Enabled and writable for as long as the trader can reach the Dashboard — including while the account is in a Hard Breach / Frosted Glass state (Ref: UC_4.10.2), in ReadOnly after a resignation, or mid-promotion. These are personal accessibility and display preferences, not trading actions, so no account-status gate applies to them.

The Desk Manager widget may independently stop rendering under those states — that is the widget's own visibility rule (Ref: BR_4.8.3.3) and is not affected by, and does not affect, the toggle in this panel.

There is no rate limit, cool-down, audit-log entry, or notification email on either toggle. A Desk Manager flip writes the Users record and nothing else; a Reduce Motion flip writes the device's local store and nothing else — it produces no server-side trace of any kind, so the value cannot be inspected, reported on, or supported from the admin side (Ref: BR_4.6.4.2).

9. Screen Description

9.1 Account screen — Controls panel

Changelog