Redesign the LUT Builder workflow and interface

[Today20092]

Problem Statement

The LUT Builder is functionally capable, but its interface reads as an internal engineering utility rather than a focused professional color-production application. Configuration appears after exposure editing, unrelated controls share equal visual weight, the graph does not communicate enough exposure context, and generation/import/export compete for attention. Users need a clearer path from camera and display configuration through false-color band design to a verified LUT download.

Solution

Reshape the existing single-page application into a clear four-stage workflow:

1. Configure the camera profile, target display, cube size, band mode, and output.
2. Design exposure bands in a dominant full-width workspace.
3. Configure encoded-signal warnings when required.
4. Generate the LUT through a clearly identified primary action.

Retain the existing dark imaging-oriented presentation and behavior while improving hierarchy, grouping, readable exposure feedback, responsive layout, keyboard usability, and status communication. Reuse the current components and state model; this is an interface refactor, not a new application architecture.

User Stories

1. As a cinematographer, I want camera and target-display settings to appear before exposure editing, so that I understand the context in which band values are interpreted.
2. As a LUT author, I want the exposure editor to be the dominant workspace, so that the application's primary purpose is immediately clear.
3. As a LUT author, I want editor controls grouped by purpose, so that global width, color automation, movement, and band creation are not confused.
4. As a LUT author, I want Add band to be visually distinct from bulk editing actions, so that I can expand the false-color scheme confidently.
5. As a LUT author, I want each band to have a visible identity, color, value, width, and action, so that editing multiple bands remains understandable.
6. As a LUT author, I want the selected band to remain synchronized between the graph and row editor, so that I always know what I am changing.
7. As a camera operator, I want zero exposure and the graph's units to be clearly identified, so that I can interpret the visualization quickly.
8. As a camera operator, I want the selected band's center and boundaries to be distinguishable, so that its monitored range is unambiguous.
9. As a keyboard user, I want to reach and operate every editing control with a visible focus state, so that pointer input is optional.
10. As a user with reduced vision, I want readable text and sufficient contrast, so that secondary information remains usable in the dark interface.
11. As a LUT author, I want encoded-signal warnings to appear in the workflow only when relevant, so that advanced controls do not obscure routine work.
12. As a LUT author, I want the primary action to name the configured transformation, so that I can verify the intended LUT before downloading it.
13. As a LUT author, I want import and configuration export to remain available as secondary actions, so that they do not compete with LUT generation.
14. As a LUT author, I want generation progress, success, validation, and failure messages near the final action, so that outcomes are easy to associate with their cause.
15. As a laptop user, I want the complete workflow to remain usable at narrow widths without clipped controls, so that the tool is not limited to large displays.
16. As an existing user, I want current preview, import, export, and generation semantics preserved, so that the visual refactor does not change generated LUT behavior.

Implementation Decisions

• Keep the application as one focused page; do not add navigation, tabs, dashboards, or a sidebar.
• Present configuration before the main exposure workspace, using a compact responsive arrangement.
• Keep the exposure-band editor full width and visually dominant.
• Separate editor controls into global band geometry, color automation, movement, and band creation groups.
• Keep Add band as the clearest editor action while bulk color application remains secondary.
• Give band rows visible ordinal identities and keep their selected state synchronized with the graph.
• Keep color swatches and hexadecimal values together; retain direct numeric editing with visible units or unit-bearing labels.
• Make destructive row removal quiet by default and clearly destructive when invoked.
• Label the graph axis with its current unit, emphasize the zero/reference position, and provide a concise selected-band readout.
• Distinguish a band's center from its half-width boundaries without relying solely on color.
• Keep signal-warning controls logically after exposure editing and hide or de-emphasize inactive detail where practical.
• Use a deliberate primary-action treatment for LUT generation and include the configured camera-to-display transformation in its label when space permits.
• Keep configuration import/export as secondary actions.
• Preserve current state transformations, API contracts, generation behavior, and local-only operation.
• Reuse existing UI primitives and dependencies. Do not add a component framework or state-management layer.
• Responsive layouts may stack controls, but must preserve workflow order and operable targets.
• Preserve and improve current ARIA labels, keyboard interaction, focus visibility, live status messages, and non-color identification.

Testing Decisions

• Test externally observable behavior rather than Tailwind class names or component internals.
• Reuse the existing editor tests for band ordering, movement, width, fill boundaries, palette application, import, and export behavior.
• Reuse the existing exposure-graph tests for interaction semantics and add focused cases only where new observable labels or selection feedback require them.
• Reuse the existing web integration tests to verify preview and generation contracts remain unchanged.
• Require the frontend production build and type checking to pass.
• Perform a manual visual check at desktop and narrow viewport sizes because the repository has no screenshot-regression seam.
• Perform a keyboard-only walkthrough covering configuration, graph selection/movement, band fields, add/remove actions, warning controls, import/export, and generation.
• Do not introduce a new component-testing or visual-regression framework solely for this refactor.

Out of Scope

• Changes to LUT mathematics, camera profiles, color science, API schemas, or generated .cube contents.
• A live camera/image preview.
• User accounts, cloud storage, preset synchronization, or collaboration.
• Multiple pages, navigation, dashboards, onboarding tours, or theme selection.
• New graph reference markers that are not already supported by reliable camera-profile data.
• A new design system or replacement of existing UI dependencies.
• Automated screenshot testing infrastructure.

Further Notes

The desired result should feel like a professional technical imaging tool: restrained, readable, and task-focused. Hierarchy should come primarily from spacing, typography, grouping, and contrast rather than added ornament. The current screenshot and interface review in the planning conversation are the visual baseline.

This specification is implemented through four dependency-ordered child tickets. The parent remains open until the final verification ticket confirms all child acceptance criteria and the complete workflow.