# Repair Sheets ## Readiness | Dimension | Status and evidence | | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Specification | Current first desktop version. It defines visible content and local prototype boundaries, not production business rules. The existing repair-request screen supplied the local composition precedent. [S1] | | Figma | No Figma authoring or fresh exact-node verification is in scope. The user supplied a screenshot as visual intent; it is not a reusable Figma source. | | Local prototype | Implemented at `/repair-sheets`: user-collapsible Sidebar state, 16 local fixtures, optional local filters, the creation-menu visual stub, and an owned Main Container. Its active Table stays contained in the shared default `m` rail. [S9] [S10] | | Verification | D-053 focused tests passed (6/6) on 2026-09-30. Browser QA at a 1600px desktop viewport verified five Badge appearances, both tooltip texts, Table-only horizontal scrolling, and arrow-key tab navigation. Review remains pending. | `lifecycle: active` records the current design work, not an implemented or validated production screen. ## Purpose The screen lets the design team inspect a dense list of repair sheets inside `Ремонт и ТО`. It turns the supplied portal screenshot into an owned desktop Angular prototype while preserving explicit boundaries for fixtures and visual stubs. The existing repair-request screen supplies the local composition precedent. [S1] ## Layout Contract The shell selects Main Container's default `m` rail, with a 1440px maximum, inside the surface padding. The Repair Sheets heading, `Создать ремлист` action, horizontal tabs, Filter Row, any Table Action Bar, and Table viewport have the same rail bounds at every available width. Repair Sheets defines no screen-only exception or Table variant. Its 2212px internal grid and horizontal viewport remain Table-owned; `ID` and row actions remain sticky at their respective edges. The browser page and Main Container do not provide horizontal scrolling or a Table breakout. ## Source and Route - Route: `/repair-sheets`. [S4] - Entry point: `Ремонтные листы` is the second child of `Ремонт и ТО`, directly after the planned visual-only `Аналитика ремонтов` entry. The group follows `Логистика внутренняя`, uses the `repair` icon, and its selected repair-sheets item maps to `/repair-sheets`. The Sidebar preserves the active destination when its parent group is opened. [S5] [S7] [S8] - Neighboring `Путевые листы` is an implemented Sidebar destination to `/waybills`; it carries no shared business state with this fixture screen. [S4] [S5] - Existing `/` repair requests screen remains a separate route and is not replaced. [S1] ## Primary Scenario 1. A user opens `/repair-sheets` and sees the `Ремонт и ТО` Sidebar state and `Ремонтные листы` heading. [S4] [S5] [S7] [S8] 2. The user opens `Создать ремлист` and sees `Ручной` and `Экстренный`; choosing an item only closes the menu in this version. [S1] 3. The default `Активные` tab presents 16 local fixture rows. Its Filter Row and 2212px Table grid viewport share Main Container's default `m` rail at every width. The grid scrolls horizontally only inside Table; `ID` stays fixed on the left and row actions stay fixed on the right. [S1] The user can add `ID`, `Дата создания`, `Статус`, or `ТС`; each optional control opens immediately and filters only these fixtures. [S9] [S10] 4. The user may switch to each of the other three tabs. Each keeps the shell and creation action visible, with an intentionally empty content area. [S1] ## Alternate Scenarios - `Повторный ремонт`, `Гарантийный ремонт`, and `Отклонить` are visual stubs: they do not navigate, mutate data, download, or open forms. Each ID is a native Table link with a `#` fixture destination; a repair-sheet detail route remains outside this prototype. [S9] [S10] ## States, Errors, and Edge Cases - The first version has a populated Active state and three intentionally empty tab panels. [S1] - No loading, network error, permission, persistence, or access-denied state is defined because the screen uses local fixtures only. [S1] - Long comments are constrained to roughly 360 px through existing table-cell behavior; their exact clipping behavior follows the owned component. [S1] ## Data and Integration Boundary The table has 16 static rows and the visible columns ID, creation and approval dates, vehicle, supplier, cost, comment, repair-sheet type and date, status, UPD data, and actions. No backend contract, API request, mutation, download, persistence, production navigation, or mobile layout is defined. [S1] Only controls visible in the supplied reference or later directly requested by the user belong to this screen. The Table uses its standard Filter Row with `+ Фильтр` and `Сбросить фильтры`; export, search, and column-management controls remain absent until their screen-specific requirement is confirmed. ## D-044 Active-table status fixtures The `Активные` fixture uses the following screen-local Badge appearances. They are visual fixture states, not a production status or payment-data contract. | Status | Badge appearance | Context hint | | ---------------------- | ---------------- | -------------------------------------- | | `Не согласован` | `error` | None | | `Предварительный` | `default` | `Нет платёжного поручения` | | `Файлы не прикреплены` | `clear` | None | | `Согласован` | `success` | None | | `Оплачен` | `info` | `e8c7f90a-e2cd-4283-9632-80ad300f5706` | The context-info affordance is rendered only for `Предварительный` and `Оплачен`; it is absent for every other listed status. Its tooltip supplies the row's status-specific fixture text above; status labels remain visible text as well as color-coded. [S9] [S11] ## D-039 Filter Row behavior `ID` (searchable select), `Дата создания` (calendar), `Статус` (select), and `ТС` (searchable select by vehicle number) are optional local fixture filters. Choosing one adds it, sets its controlled open state, and excludes it from the menu. Closing an empty control or using its `remove` action clears and removes it; reset clears all values, optional controls, and open state. The filters apply only to the existing 16 static rows and add no backend, persistence, production API, or mobile behavior. [S9] [S10] ## Components and Accessibility - The composition uses owned Sidebar, Main Container, Header Widget, Button, Dropdown, Filter Row, horizontal Tabs, and Table components. The shared Main Container Table rule keeps the heading, creation control, tabs, Filter Row, any Action Bar, and Table grid viewport within the same default `m` rail. [S1] [S5] - Table status remains textual as well as color-coded. A status context hint, where present, uses its exact tooltip text; it is not a substitute for the status label. Icon-only row actions receive Russian accessible labels. [S9] - Sidebar selects the active Repair Sheets subtab in `Ремонт и ТО`; Dropdown supports menu keyboard control, Escape, and focus return; Tabs support arrow keys, Home, End, and tab/panel relationships. [S2] [S3] [S6] [S7] [S8] ## Related Flows No cross-screen business flow is defined. Sidebar navigation can move between the implemented `Ремонт и ТО` destinations, `/repair-sheets` and `/`, without shared data or action state. Its `Аналитика ремонтов` sibling is planned and visual-only: no route or transition is defined. Creation, row actions, and ID destinations stay outside the prototype until a later authorized task defines their destination and data contract. [S1] [S4] [S5] [S7] [S8] ## Verification D-038 passed the focused Main Container/App suites, `npm run build`, `npm run build-storybook`, `npm run check:design-system`, and `npm run check:memory`. Browser QA at a 2500px desktop viewport confirmed that the default `m` rail is 1440px and centered with both expanded and collapsed Sidebar, and that its Table and grid viewport share the rail edges. That D-038 check covered the former 2244px grid. The current 2212px grid keeps horizontal scrolling inside Table; neither the browser page nor Main Container gains horizontal overflow. D-053 Browser QA on 2026-09-30 checked the sticky ID and action columns, five Badge appearances, and both status-specific tooltips at a 1600px desktop viewport. The keyboard-focusable Main Container scrollport and existing Repair Sheets accessibility tree remain required. The component-profile `ui:flow verify` record carries the focused-tests, component-states, and keyboard-a11y evidence for D-038. It is component QA, not a pixel-parity or screen-approval gate. Existing accessibility behavior remains required: the create menu closes on Escape with focus returned, and Tabs respond to arrow keys and Home. D-038 verification predates the D-039 optional-filter behavior; D-039 focused screen coverage exercises adding, opening, filtering, removing, and resetting local filters without asserting browser or Figma parity. [S11] ## Open Questions - What data model and action outcomes should replace the fixtures and stubs? - Which form, permission, route, and download behaviors are required after the first prototype version? - What screen, route, and data boundary should make `Аналитика ремонтов` an implemented destination?