design and docs

Author: KSemenenko

AGENTS.md

@@ -8,10 +8,10 @@ Stack: `.NET 10`, Blazor WebAssembly, Razor Class Library, xUnit, bUnit, Playwri
 `PrompterOne` is a standalone browser-first WebAssembly app.
 
 - `src/PrompterOne.App` is the only runnable host.
-- `src/PrompterOne.Shared` contains routed Razor UI, exact `new-design` styling, and browser interop.
+- `src/PrompterOne.Shared` contains routed Razor UI, exact `design` styling, and browser interop.
 - `src/PrompterOne.Core` contains TPS, RSVP, preview, workspace, media-scene, and streaming domain logic.
 - `tests/` contains all automated test projects.
-- `new-design/` is the visual and interaction source of truth.
+- `design/` is the visual and interaction source of truth.
 
 There is no backend in the runtime shape. The app must boot directly in the browser from the WebAssembly host.
 
@@ -289,10 +289,10 @@ Repo-specific design rules:
 - Keep shared build settings in `Directory.Build.props`.
 - Keep shared package versions in `Directory.Packages.props`.
 - Keep the pinned SDK version in `global.json`.
-- Treat `new-design/index.html`, `new-design/tokens.css`, `new-design/components.css`, `new-design/styles.css`, and `new-design/app.js` as the exact design reference.
-- Treat every file under `new-design/` as a static design/prototype reference only. Production UI must be implemented as Blazor components in `src/PrompterOne.Shared`; do not ship raw `new-design` HTML as runtime UI.
-- Do not re-invent the UI when the answer should be “port the markup and classes from `new-design`”.
-- For parity tasks, port the full routed screen from its matching `new-design/*.html` reference, not just isolated high-signal blocks. Settings, Editor, Learn, Teleprompter, and Go Live must match the reference screen in layout and intended interaction while staying Blazor/C# owned.
+- Treat `design/index.html`, `design/tokens.css`, `design/components.css`, `design/styles.css`, and `design/app.js` as the exact design reference.
+- Treat every file under `design/` as a static design/prototype reference only. Production UI must be implemented as Blazor components in `src/PrompterOne.Shared`; do not ship raw `design` HTML as runtime UI.
+- Do not re-invent the UI when the answer should be “port the markup and classes from `design`”.
+- For parity tasks, port the full routed screen from its matching `design/*.html` reference, not just isolated high-signal blocks. Settings, Editor, Learn, Teleprompter, and Go Live must match the reference screen in layout and intended interaction while staying Blazor/C# owned.
 - About content must stay factual and current: do not invent team members or contributor names; use Managed Code attribution and official company links only.
 - Do not introduce a server host for the app runtime.
 - Preserve stable `data-testid` selectors on core flows because the Playwright suite depends on them.
@@ -305,7 +305,7 @@ Repo-specific design rules:
 - Any vendored runtime JavaScript SDK that tracks an upstream GitHub repo MUST have an automated watcher job that checks new GitHub releases and opens a repo issue describing the required update when a newer release appears.
 - Teleprompter TPS speed modifiers MUST affect both playback timing and subtle word- or phrase-level letter spacing, so slower spans open up slightly and faster spans tighten slightly without hurting readability.
 - Teleprompter reader word styling MUST mirror TPS/editor inline semantics: explicit inline TPS tags control per-word emphasis and color, while section or block emotion sets card context and must not recolor every reader word.
-- Teleprompter block transitions MUST stay visually consistent: outgoing cards move upward and incoming cards rise from below in the same direction every time; alternating up/down travel is forbidden.
+- Teleprompter block transitions MUST stay visually consistent: outgoing cards move upward and incoming cards rise from below in the same direction every time; alternating up/down travel is forbidden, and extra settling, bounce, or intermediate card states are forbidden.
 - Learn and Teleprompter are separate screens with separate style ownership; do not bundle RSVP and teleprompter reader feature styles into one shared screen stylesheet or let one page inherit the other page's visual treatment.
 - User preferences persistence MUST sit behind a platform-agnostic user-settings abstraction, with browser storage implemented via local storage and room for other platform-specific implementations; theme, teleprompter layout preferences, camera/scene preferences, and similar saved settings belong there instead of ad-hoc feature stores.
 - Build quality gates must stay green under `-warnaserror`.
@@ -351,7 +351,7 @@ Ask first:
 
 ### Likes
 
-- exact fidelity with `new-design`
+- exact fidelity with `design`
 - thin WASM host boundaries
 - browser-realistic UI verification
 - domain logic that stays reusable and serializable
@@ -364,13 +364,14 @@ Ask first:
 - progress updates that imply a fix is done before there is concrete implementation and verification evidence; keep status factual and let the user verify final behavior personally
 - automated test or coverage runs for UI-behavior fixes before the user has manually checked the change locally; wait for the user's confirmation before resuming automation
 - mixed-language root README or public entry docs; keep them English-only unless the user explicitly asks otherwise
-- design drift from `new-design`
+- design drift from `design`
 - made-up About/team content or stale attribution; About must point to real Managed Code ownership and official links
 - any visible typing latency in the editor; plain input must feel immediate with no observable delay
 - teleprompter controls that fade so much they become hard to see during real reading
-- teleprompter paragraph repositioning or per-word vertical transform updates that make the text jump; `new-design/teleprompter.html` motion is the required reference
+- teleprompter paragraph repositioning, line hopping, or per-word vertical transform updates that make the text jump; `design/teleprompter.html` motion is the required reference, with steady bottom-to-top movement and no extra animation layers beyond the reference
 - any green teleprompter shell or background treatment; Teleprompter must stay on its dark reader palette and use emotion only for accents, not green screen-wide fills
 - Learn and Teleprompter style boundaries bleeding through a shared feature stylesheet; their visuals must stay isolated by page-owned style manifests
+- Learn RSVP compositions that shift when shorter or longer words render; changing word length must not move the overall RSVP component or its anchored centerline
 - teleprompter camera starting enabled by default; default reader startup should keep the camera off until the user explicitly enables it
 - editor keystroke paths that persist, compile, or rebuild shared session state; keep plain typing in memory and move heavier local sync to debounce or autosave
 - murky JavaScript or interop layers that keep product UI behavior in JS when Blazor can own it cleanly

README.md

@@ -27,7 +27,7 @@ Architecture map: [docs/Architecture.md](docs/Architecture.md)
 ## Key Properties
 
 - standalone Blazor WebAssembly runtime with no server backend
-- UI ported from [`new-design/`](new-design/) as the design source of truth
+- UI ported from [`design/`](design/) as the design source of truth
 - TPS-focused editor for prompt-ready scripts
 - RSVP/Learn mode with ORP-style word rendering
 - browser-side media scene, device setup, and live preview
@@ -54,7 +54,7 @@ Canonical inspiration: [cameron/squirt](https://github.com/cameron/squirt)
 - routed UI, CSS, browser interop: [`src/PrompterOne.Shared`](src/PrompterOne.Shared)
 - reusable domain logic: [`src/PrompterOne.Core`](src/PrompterOne.Core)
 - automated tests: [`tests/`](tests/)
-- visual reference: [`new-design/`](new-design/)
+- visual reference: [`design/`](design/)
 
 Further reading:
 

docs/ADR/ADR-0002-go-live-operational-studio-surface.md

@@ -6,7 +6,7 @@ Related Features: [Go Live Runtime](/Users/ksemenenko/Developer/PrompterOne/docs
 
 ## Implementation plan (step-by-step)
 
-- [x] Audit the existing routed `Go Live` page against `new-design/golive.html`.
+- [x] Audit the existing routed `Go Live` page against `design/golive.html`.
 - [x] Replace the design drifted routing form layout with a studio shell that matches the design rails and canvas.
 - [x] Bind the studio shell to real browser media state, real scene cameras, and honest destination readiness summaries.
 - [x] Keep detailed provider setup in `Settings` and reduce `Go Live` to operational toggles plus links back to setup.
@@ -16,13 +16,13 @@ Related Features: [Go Live Runtime](/Users/ksemenenko/Developer/PrompterOne/docs
 ## Context
 
 - The prior `Go Live` page mixed an operational studio surface with a large lower deck of inline provider forms.
-- That shape diverged from `new-design/golive.html`, pushed the most important controls below the fold, and encouraged duplicate ownership of provider credentials between `Go Live` and `Settings`.
+- That shape diverged from `design/golive.html`, pushed the most important controls below the fold, and encouraged duplicate ownership of provider credentials between `Go Live` and `Settings`.
 - The product already has browser media services, scene state, output runtime services, and persisted provider settings. The problem was not missing capability; it was a blurred page contract.
 - The user explicitly asked for a real `Go Live` studio with camera switching, live preview, honest data, and design fidelity instead of a fake or placeholder surface.
 
 Goals:
 
-- Keep `Go Live` visually faithful to `new-design/golive.html`.
+- Keep `Go Live` visually faithful to `design/golive.html`.
 - Make `Go Live` operational, not administrative.
 - Keep live status, room state, and destination readiness truthful to what the browser runtime actually knows.
 - Cover the main studio flow with automated component and browser tests.
@@ -157,6 +157,6 @@ flowchart LR
 
 ## References
 
-- [new-design/golive.html](/Users/ksemenenko/Developer/PrompterOne/new-design/golive.html)
+- [design/golive.html](/Users/ksemenenko/Developer/PrompterOne/design/golive.html)
 - [docs/Features/GoLiveRuntime.md](/Users/ksemenenko/Developer/PrompterOne/docs/Features/GoLiveRuntime.md)
 - [docs/Architecture.md](/Users/ksemenenko/Developer/PrompterOne/docs/Architecture.md)

docs/Architecture.md

@@ -6,7 +6,7 @@
 
 The acceptance target is a browser-only runtime that:
 
-- matches the local `new-design/` UI closely
+- matches the local `design/` UI closely
 - parses and exports TPS content
 - supports RSVP learn mode and teleprompter reading mode
 - keeps media, scene, and streaming state client-side
@@ -49,7 +49,7 @@ flowchart LR
     App["src/PrompterOne.App<br/>Standalone WASM host"]
     Shared["src/PrompterOne.Shared<br/>Razor pages, layout, CSS, JS interop"]
     Core["src/PrompterOne.Core<br/>TPS, RSVP, workspace, media, streaming"]
-    NewDesign["new-design/<br/>HTML/CSS/JS reference + parser sources"]
+    NewDesign["design/<br/>HTML/CSS/JS reference + parser sources"]
     Tests["tests/*<br/>xUnit + bUnit + Playwright"]
 
     App --> Shared
@@ -71,8 +71,8 @@ flowchart LR
 
 ### UI Design Principles
 
-- `new-design/` is the visual source of truth for layout, hierarchy, spacing, controls, color direction, and interaction tone.
-- UI work should port markup, structure, and class intent from `new-design/` instead of inventing a parallel design language.
+- `design/` is the visual source of truth for layout, hierarchy, spacing, controls, color direction, and interaction tone.
+- UI work should port markup, structure, and class intent from `design/` instead of inventing a parallel design language.
 - Routed screens should keep strong visual identities while still using the shared shell and contracts from `AppShell`.
 - Stable `data-testid` hooks are part of the UI contract, not optional test-only extras.
 - Browser-first behavior matters more than server assumptions. Media, storage, and stream state stay client-side.
@@ -366,7 +366,7 @@ If a native embedded browser host returns later, media access must not rely on s
 - routed Razor screens: `library`, `editor`, `learn`, `teleprompter`, `go-live`, `settings`
 - vertical slices own their routed pages, components, renderers, and feature-local services under folders such as `Editor/`, `Library/`, `Teleprompter/`, and `GoLive/`
 - only true cross-cutting UI assets stay outside feature slices: `Contracts/`, `Localization/`, `wwwroot/`, root bootstrap files, and `AppShell/`
-- exact design shell and imported `new-design` assets
+- exact design shell and imported `design` assets
 - shared UI localization catalog for supported browser cultures
 - browser interop and app DI wiring
 - browser-backed `IUserSettingsStore` wiring for persisted reader, theme, scene, and studio preferences
@@ -381,7 +381,7 @@ If a native embedded browser host returns later, media access must not rely on s
 
 Rules:
 
-- keep markup aligned with `new-design`
+- keep markup aligned with `design`
 - do not move business logic here if it belongs in `Core`
 - preserve `data-testid` selectors for browser tests
 

docs/Features/GoLiveRuntime.md

@@ -6,8 +6,9 @@
 
 The current page layout is a production-style studio surface:
 
-- top session bar follows `new-design/golive.html`: back to Read, script title + session badge, centered session timer, panel toggles, mode switch, settings shortcut, REC, and the main stream action on the far right
-- the studio shell follows the same three-column grid as `new-design/golive.html`: a compact left input rail, a dominant center canvas/program stage, and a dedicated right operational rail
+- the routed `Go Live` page owns its own studio chrome and suppresses the shared app header while the route is active, so `design/golive.html` remains the only topbar on that screen
+- top session bar follows `design/golive.html`: back to Read, script title + session badge, centered session timer, panel toggles, mode switch, settings shortcut, REC, and the main stream action on the far right
+- the studio shell follows the same three-column grid as `design/golive.html`: a compact left input rail, a dominant center canvas/program stage, and a dedicated right operational rail
 - left input rail for scene cameras, add-camera action, utility sources, and microphone route status
 - center program stage for the selected program source and current script/session state
 - scene controls bar for scene chips, layout controls, transitions, and the primary `Take To Air` action
@@ -184,6 +185,7 @@ flowchart LR
 - `Go Live` must auto-seed the first available browser camera into the scene when the scene is empty and devices are available.
 - `Go Live` must show the selected program source in the center monitor and the currently on-air source in the right preview rail until the operator explicitly takes the selected source live.
 - `Go Live` must show a stable empty preview state instead of mounting camera interop when the current scene has no cameras.
+- the routed `Go Live` page must not stack the shared app header above the studio topbar; the studio topbar is the only route chrome on that screen
 - any shared `Go Live` localized copy must come from `PrompterOne.Shared.Localization.UiTextCatalog`, so supported browser cultures localize the studio surface without feature-local string copies.
 - quick destination cards must only expose honest readiness summaries and arm/disarm toggles; fake in-page credential editors are forbidden on the operational studio surface
 - legacy streaming settings must normalize to the current included program cameras so existing browser storage keeps working