## Description Replace the PC builder’s shared state management using React Context and `useState` with Redux Toolkit. This makes our use of Redux explicit and aligns with the project’s state-management requirement. Currently: - `BuildProvider` holds selected components in `useState`. - `BuildContext` and `useBuild()` expose `parts`, `addPart`, `removePart`, and `resetBuild`. - `BuildProvider` reads and writes the build using the `pc-builder` key in `localStorage`. - `BuildProvider` also displays the component-removal notification. Redux stores shared application state in a central store. Components dispatch actions to request changes, and reducers define how those actions update the state. Components use selectors to read the values they need. Redux Toolkit is the officially recommended way to implement Redux. It provides `configureStore` for creating the store and `createSlice` for defining state, reducers, and generated actions together. React Redux provides the `Provider`, `useSelector`, and `useDispatch` integration. ### Intended implementation - Create a Redux store using `configureStore`. - Create a `buildSlice` containing selected components keyed by category, with `addPart`, `removePart`, and `resetBuild` actions. - Add typed selector and dispatch hooks for TypeScript. - Replace `BuildContext` and `useBuild()` usage with Redux selectors and dispatched actions. - Replace the state-provider setup with React Redux’s `Provider`. - Preserve local storage persistence and compatibility with existing saved builds. - Move removal-notification rendering into a UI component so notifications continue working when the existing `BuildProvider` is removed. Reducers should only update state. - Keep local UI state, such as open dialogs, image errors, and expanded panels, in `useState`. - Leave catalogue fetching and caching unchanged. This should preserve the current user experience while giving the team a clear, consistent approach to managing shared build state. ## Acceptance criteria - [x] Redux Toolkit and React Redux are installed and configured. - [x] Selected build components are stored in a typed Redux `build` slice. - [x] Adding, replacing, removing, and clearing components work through Redux actions. - [x] Each component category still has at most one selected part. - [x] All current build consumers use Redux selectors and actions instead of `BuildContext`. - [x] The old Context-based build state and unused provider code are removed, without introducing a second copy of build state. - [ ] Existing builds saved under `pc-builder` load correctly after the migration. - [x] Build changes persist across browser reloads, including component removal and clearing the build. - [x] Build totals, selected-component counts, compatibility checks, and publishing continue to use the current selections. - [ ] Replacement confirmation and add/remove feedback continue to work. - [ ] Local UI state and catalogue fetching/caching retain their existing behaviour. - [ ] Automated tests cover the build reducers and persistence, including loading an existing saved build. - [ ] Existing tests are updated for Redux and pass. - [ ] Frontend lint and production build pass. - [ ] Adding, replacing, removing, clearing, and restoring a build are manually verified. - [ ] The README explains Redux Toolkit’s role and the updated state flow. ## Dependencies - Add `@reduxjs/toolkit` and `react-redux`. - Preserve the existing `PcPart` data structure, local storage format, and reusable success notification. - No known blocking issues.