UI Consistency

The workflow selector SHALL display all authorized workflows returned from the backend discovery endpoint.

- The menu SHALL include the built-in options Autoselect (Default) and None
- The menu SHALL include each workflow returned by /api/v1/workflows

The application SHALL support light and dark themes with a user-accessible toggle.

- A theme toggle button SHALL be present in the sidebar footer
- Theme preference SHALL be persisted in localStorage
- The data-theme attribute on document root SHALL reflect the current theme ("light" or "dark")
- Default theme SHALL be "light"

The sidebar logo and alt text SHALL be determined by the deployment hostname, not hardcoded. White-label deployments (e.g. beta.homeincentiveshub.com) SHALL display their own logo instead of the default UseJunior logo.

- Logo source and alt text SHALL be resolved via a branding configuration that maps hostnames to brand assets
- The hostname matching SHALL support both exact match and subdomain matching (e.g. homeincentiveshub.com matches beta.homeincentiveshub.com)
- Unknown hostnames SHALL fall back to the default UseJunior branding
- The branding configuration SHALL be the single source of truth for logo paths — no hardcoded logo paths in components
- Adding a new white-label brand SHALL require only a configuration entry and a logo asset, not component changes

Chat conversations, messages, and the active conversation SHALL be persisted with backend sync when chat persistence is enabled, and SHALL fall back to localStorage as a cache and offline bootstrap.

- The chat state (conversations, messages, activeConversationId) SHALL be stored in localStorage under the key chatState as a cache
- For domains with backend chat persistence enabled, the backend SHALL be the source of truth on startup
- On page load, localStorage MAY be used immediately for fast render, then reconciled with backend data (backend wins conflicts)
- Messages SHALL be limited to 100 per conversation to prevent localStorage overflow (~5MB limit)
- Transient state (processingChatIds, progressState, pendingContexts) SHALL NOT be persisted
- Invalid or missing stored values SHALL default to an empty state with no conversations
- Processing status SHALL be reset to 'idle' on restore (to prevent stuck "processing" states)
- Rationale: Users expect to return to their conversation after a page refresh; losing chat history is disruptive

The application SHALL provide a reusable ConfirmationModal component for confirming destructive or significant actions.

- ConfirmationModal SHALL use the HTML <dialog> element for native modal behavior
- ConfirmationModal SHALL support customizable title, message, and button text
- ConfirmationModal SHALL support a confirmVariant prop for styling (primary or danger)
- ConfirmationModal SHALL support an isLoading prop to show processing state
- ConfirmationModal message SHALL support HTML content via dangerouslySetInnerHTML
- ConfirmationModal SHALL close on backdrop click and Escape key
- ConfirmationModal SHALL be managed via uiStore state, not window globals

The chat interface SHALL provide modals for attaching context (contracts, deals, property profiles) to conversations.

- ContractGridModal SHALL fetch and display available contract sets from the API
- ContractGridModal SHALL show set name, contract count, and prompt count
- DealContextModal SHALL fetch and display available deals from the API
- PropertyContextModal SHALL allow creating, editing, and selecting property profiles
- Selecting an item in any context modal SHALL add it to pending attachments
- Context modals SHALL be managed via uiStore state

The contract analysis view SHALL provide a modal for viewing paragraph citations in context.

- CitationModal SHALL display the full paragraph text from the contract
- CitationModal SHALL highlight the cited section if applicable
- CitationModal state SHALL be managed in the contract analysis store
- Clicking a citation link in the grid SHALL open the CitationModal

The "Suggested Edits" column in the Review Workbench SHALL display a shimmer/pulse loading animation while edits are being generated.

- When a row's suggested edit is pending generation, the cell SHALL show an animated shimmer effect
- The shimmer SHALL replace the static em-dash (—) during loading
- The shimmer animation SHALL use animate-pulse or equivalent CSS animation
- The shimmer SHALL display descriptive text like "Generating..." alongside the animation
- Loading state SHALL be derived from: isPending prop OR (no opcodes AND review status is processing)
- Static em-dash (—) SHALL only appear when processing is complete with no suggested edit
- Rationale: Animated loading indicators communicate active processing, reducing user uncertainty

The sidebar SHALL support host-based configuration for section labels and visibility so tenant deployments can hide or rename sections.

The workflow selector SHALL filter available workflows based on tenant configuration.

Contract analysis actions that trigger long-running backend work SHALL show visible loading feedback and disable repeat actions while pending.

- Actions include sync, import, add column, delete column, delete contract, and regeneration
- While a mutation is pending, the initiating control SHALL display a spinner or in-progress label
- Related controls SHALL be disabled to prevent duplicate requests
- Loading feedback SHALL clear on both success and error

Playbook upload interactions SHALL display a visible loading indicator while the upload request or subsequent playbook list refetch is in progress.

- The Upload action SHALL show a spinner or inline loading indicator while the upload mutation is pending
- The playbook selector panel SHALL treat "loading" as true when either the upload mutation is pending OR the playbooks query is fetching
- Loading feedback SHALL clear on both success and error

The Grid Review feature SHALL provide a "New Grid" button that allows users to create an empty grid without importing from a shared folder.

- The "New Grid" button SHALL be visible in the GridSelectorPanel regardless of whether grids already exist
- Clicking "New Grid" SHALL prompt the user for a grid name
- After entering a valid name, the system SHALL call POST /api/v1/contracts/sets to create the grid
- After successful creation, the view SHALL navigate into the newly created grid
- If the user cancels the name prompt or enters an empty name, no grid SHALL be created

When a user imports a shared folder in the Grid Review, the system SHALL use the folder sync endpoint (POST /api/v1/contracts/folders/sync) which auto-creates a grid from the folder contents.

- The import handler SHALL NOT use the file import endpoint (POST /api/v1/contracts/files/import) for folder-level imports
- The sync endpoint auto-detects Google Drive vs SharePoint from the URL, so no source parameter SHALL be hardcoded
- After a successful folder sync, the grid list SHALL be refreshed and the user returned to the grid selector

Chat context attachments SHALL remain visible and active across follow-up messages until the user removes them.

User messages that include uploaded files SHALL display an attachment summary in the chat history.

Assistant messages with output attachments SHALL provide working download links using the token-based download endpoint.

When review edits are applied, the workbench UI SHALL immediately reflect applied status so users can navigate edits and download revised documents.

- Applied rows SHALL render the applied state (check icon + edit/bookmark links) instead of Apply/Ignore buttons.
- When there are zero open edits, "Apply All" and "Apply All + Comments" SHALL be disabled and non-interactive.
- After one or more edits are applied, the "Download Revised" action SHALL be enabled.

When a user edits the Recommended Response, the response cell SHALL display the edited text with an explicit "(edited)" indicator.

- The "(edited)" indicator SHALL appear immediately after the edited response text
- The edited response text SHALL reflect the user-provided content, not the pre-edit suggestion
- The indicator SHALL be styled consistently with other edited markers in the review table
- Rationale: Users must see which responses have been manually modified before applying edits

When a user edits the Recommended Response and then applies the edit, the edit genealogy SHALL display provenance indicating the response was user-edited.

- Genealogy SHALL include a provenance label such as "User Edited" or "User Modified"
- The provenance label SHALL appear alongside other source metadata in the genealogy popover
- This applies to edits generated from revised recommended responses as well as original AI responses

Edit genealogy SHALL render consistently regardless of whether edits are applied via "Apply" (single row) or "Apply All".

- Single-row Apply SHALL populate genealogy data in the same shape as Apply All
- The genealogy popover SHALL display the same sections and metadata for both flows
- The user SHALL NOT experience missing genealogy details when applying a single row