Readiness
| Dimension | Status and evidence |
|---|---|
| Specification | Current description of the team's local desktop prototype; production roles and business rules are not defined. [S2] [S3] |
| Figma | Earlier reference: [S4] and repair-requests.figma-target.json. Neither was freshly verified against Figma in D-026; they do not prove parity with current local code. |
| Local prototype | Implemented at /: 23 fixture rows, 13 columns, local filters, and owned design-system composition. [S2] [S3] [S6] |
| Verification | D-026: npm test -- --watch=false passed (56 files, 535 tests). D-031 later ran application and Storybook builds plus Browser QA at 1440×900 and 1920×1080 for the shared shell; no fresh Figma comparison is claimed. [S5] |
Purpose
/ is a desktop local prototype for inspecting repair requests. It composes the
owned Sidebar, Header Widget, filters, and a 13-column Table. All records are
fixtures; no backend calls, persistence, permissions, or production destinations
are defined. These are the team's generated components in this repository, with
no asserted mapping to developers' production components. [S1] [S2] [S3]
Source and Route
- Route:
/insrc/app/app.routes.ts. [S6] - Shell:
WblSidebarComponentandWblMainContainerComponentinsrc/app/app.component.*; the shell handlescollapsedChangeand gives the main container the sole vertical scrollport. [S1] - Entry point:
Заявки на ремонтis the third child ofРемонт и ТО, directly afterРемонтные листы. Selecting it maps to/; the group followsЛогистика внутренняяand uses therepairicon. [S8] [S9] Аналитика ремонтовis the first sibling in that group, but is a planned visual-only entry: it has no route, screen, or navigation outcome in this prototype. [S8] [S9]- Screen:
src/app/features/repair-requests/repair-requests.component.*. [S2] [S3] - Component owners: current
src/app/design-systemand the local inventory. The immutable Source snapshot is historical migration evidence. - Prior design reference: Repair Requests target and [S4]. The target describes earlier fixtures and assembly; it is not a current runtime contract. For example, its 11-row fixture differs from the current 23-row local fixture. [S2]
Primary Scenario
- The user opens
/and sees the owned Sidebar withЗаявки на ремонтin theРемонт и ТОgroup and theЗаявки на ремонтheader. [S1] [S3] [S6] [S8] - The Table receives 23 fixture rows and 13 columns. The ID column requests initial descending sorting; the owned Table sorts locally with pagination hidden and keeps edge columns fixed within horizontal overflow. [S2] [S3] [S7]
- Request-ID range, creation-date range, status, vehicle, and optional depot filters update computed local rows without a network query. [S2] [S3]
- Reset clears filter state and hides the optional depot filter. Create, download, and row actions are visual stubs; the feature binds no business handlers or destination routes for them. [S2] [S3]
Alternate Scenarios
- A filter combination with no matching rows selects the Table's filtered-empty state. [S2] [S3]
Автоколоннаmay be added as an optional filter; removing it clears its selected depot. [S2] [S3]- Vehicle filtering permits multiple selections. [S2] [S3]
Components and Accessibility
- Sidebar owns the shell navigation visuals and emits the fixed repair-and-maintenance item; the shell owns the route mapping. [S8] [S9]
- Main Container owns the shared desktop frame and vertical scrollport. [S1]
- Header Widget receives the title
and the
Создать заявкуaction. [S3] - Table receives explicit columns and rows; Table Cell renders text, number, badge, link, and action data. [S2] [S3]
- Projected Filter Row controls are Range, Calendar Range, and Select dropdowns. [S3]
- Table, rows, and icon-only actions receive Russian accessible labels. Status is conveyed by text as well as color. This source inspection does not prove the full keyboard or assistive-technology journey. [S2] [S3]
States, Errors, and Edge Cases
- Populated and filtered-empty states are wired to static local data. [S2] [S3]
- Reset is disabled when no filter value is applied. [S2] [S3]
- Repeated request IDs exist in the fixture; the Table row ID also includes the fixture index to keep row identity distinct. [S2]
- Calendar
todayand reference date are fixed at2026-05-02for this fixture. [S3]
Data and Integration Boundary
- Fixture links use
href="#"; no details route is implemented. [S2] - Backend contracts, persistence, permissions, pagination, loading, error, and access-denied scenarios are not part of this prototype. [S2] [S3]
- The current table mapping displays one leading vehicle icon and standard text/description fields. Earlier target details do not override local code. [S2]
- No production integration or developer transfer is scheduled by this spec.
D-039 Filter Row behavior
The permanently visible request-ID range, creation-date range, status, and
vehicle filters are pinned; Автоколонна is optional. The screen owns one
controlled openedFilterId: opening a new control closes an empty depot
control, and closing an empty optional depot control removes it. A depot with a
selected value remains visible until its semantic remove action.
Pinned actions reset only their screen-owned fixture values. Full reset clears every value, removes the optional depot control, and closes every overlay. These filters update only the existing 23 local rows; no backend, persistence, or production filtering is introduced. [S2] [S3] [S5]
Related Flows
No cross-screen business flow is defined. The Sidebar exposes the two implemented
repair destinations, / and /repair-sheets, without shared data or action
state. Аналитика ремонтов remains planned and visual-only until a later
authorized task defines its screen and route. [S8] [S9]
Verification
D-026, 2026-09-05: npm test -- --watch=false passed 56 files / 535 tests;
that historical suite result predates D-039. The current focused screen spec
covers status filtering/reset, lifecycle-controlled pinned and optional filters,
and the three row-action helper labels. [S5]
The screen tests do not exercise every dropdown, sorting, action execution, or Figma parity scenario. D-031 Browser QA verified the shared shell at 1440×900 and 1920×1080: no global horizontal overflow, vertical scrolling in Main Container, and horizontal Table overflow preserved within the table region.
Open Questions
- Which additional fixture states or local visual actions should be modeled?
- Figma assembly owners and screen parity need exact-node evidence before any new claim of visual verification.
- Production data schemas and action destinations remain unspecified.
- The planned repair-analytics entry needs a screen, route, data boundary, and navigation outcome before this prototype can describe it 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.