Readiness
| Dimension | Status and evidence |
|---|---|
| Specification | Current description of the local desktop prototype; production roles and business rules remain open. [S1] [S2] |
| Figma | Earlier screen evidence is referenced in screen.repair-requests; it was not freshly checked in D-026. [S2] |
| Local prototype | Implemented at / with 23 fixture rows and local filters, and at /repair-sheets with 16 fixture rows and mock controls. [S1] [S2] [S4] |
| Verification | Source and existing focused tests inspected; execution results and their limits belong to the screen's Verification section. No area-wide usability or production validation is claimed. [S2] |
Value
This area provides a local desktop prototype for inspecting repair requests and their visible status, vehicle, service, cost, schedule, and mileage. It helps the design team review a dense list composition using its own generated components. The fixture does not establish production business rules or measured product outcomes. [S1] [S2]
Users and JTBD
The modeled task is inspecting a repair-request list. Exact production roles, permissions, and responsibility boundaries are not established by the fixture. [S1]
Boundaries
In scope: the / repair-request list, /repair-sheets, local visual fixtures,
filtering, local table interaction, and the fixed Ремонт и ТО Sidebar group.
That group follows Логистика внутренняя, uses the repair icon, and orders
its entries as Аналитика ремонтов, Ремонтные листы, and Заявки на ремонт.
Repair Sheets follows the repair-request composition precedent and keeps
creation, actions, download, and filters as explicit mocks. [S3] [S4] [S5] [S6]
Backend contracts, mutations, persistence, authorization, production
destinations, mobile layouts, and responsive adaptations are outside this
prototype. Its components belong to this repository; compatibility with
developers' production components is not asserted. [S1] [S2]
Glossary
ТС: vehicle.СТО: vehicle service station.Ремонтный лист: the repair-sheet reference shown by the fixture.
These terms describe visible content; no production schema is inferred. [S1]
Screens and Flows
screen.repair-requests: local list prototype at/. [S2]screen.repair-sheets: desktop fixture list at/repair-sheets, with route state,Ремонт и ТОSidebar entry, 16 local rows, and mock controls. The existing repair-request screen is its local composition precedent. [S3] [S4]Аналитика ремонтов: a planned visual-only Sidebar entry. It has no screen, route, data, or navigation outcome in the current prototype. [S5] [S6]- No cross-screen flow is currently defined.
Current Rules and Decisions
- Reusable visuals come from the owned local design system. [S1]
- The prototype is desktop-only and uses static fixtures. [S1] [S2]
- The application shell maps
Ремонтные листыto/repair-sheetsandЗаявки на ремонтto/; the Sidebar emits their fixed IDs and does not navigate itself.Аналитика ремонтовremains planned and visual-only. [S5] [S6] - Its tables keep edge columns fixed and horizontal overflow inside the table region. D-031 Browser QA confirmed this boundary at 1440×900 and 1920×1080.
Open Questions
- Which additional visual scenarios should the design team prototype?
- Production API, permissions, routes, error states, pagination, and action availability remain undefined; this task does not schedule that integration.
- The repair analytics destination requires a future authorized screen and route task before it can be described as implemented.
Documentation Review
Readiness review: D-026 (GitLab task);
verified member danil-lebedev / GitLab 8269564; agent codex;
session 01a0725e-9ce7-7070-bd66-3b8a92ab9006. This review inspected tracked
local sources; it did not re-verify Figma or establish production behavior.