Waybills

Readiness

Dimension	Status and evidence
Specification	The agreed first desktop version and fixture boundary are documented. [S1]
Figma	No Figma write or fresh exact-node check is in scope; the user screenshot is intent, not a Figma source. [S1]
Local prototype	Implemented at `/waybills` with 19 static rows, optional local filters, and inert header and row actions. [S3] [S4] [S5]
Verification	Focused Waybills, shell, and Sidebar tests; Angular and Storybook builds; design-system and Memory checks passed. Browser QA covered the current desktop browser size. [S7]

lifecycle: active records current screen documentation, not an implemented or validated UI.

Purpose

The screen lets a user inspect visible waybill fixtures in Internal Logistics while retaining explicit limits around static data and inert controls. [S1] [S3]

Source and Route

Route: /waybills. [S5]
Entry and return path: the Sidebar items «Путевые листы» and «Ремонтные листы» respectively. The shell owns those two route changes. [S2] [S6]

Primary Scenario

A user opens /waybills or selects «Путевые листы».
The screen shows a heading, two inert header actions, a Filter Row, and 19 waybill fixtures in eight columns.
The user can add an optional filter; it opens immediately and filters only the local fixtures. [S3] [S4]

Alternate Scenarios

The user may return to /repair-sheets through the neighboring Sidebar item.
A link-formatted number remains on the same screen because no destination has been specified. [S3] [S6]

States, Errors, and Edge Cases

The first version has one populated fixture state with statuses «Открыт», «Создан», and «Закрыт». [S3]
Loading, empty, network-error, no-access, persistence, and confirmation states are outside the proposed fixture boundary. [S1]
The first column remains Table-owned sticky content; horizontal scrolling is confined to the Table viewport. [S1]

Data and Integration Boundary

The screen uses 19 static rows. Header actions and row numbers remain visual stubs without requests, mutations, navigation, downloads, or persistent state. No backend or mobile behavior is specified. [S1]

D-039 Filter Row behavior

№ путевого листа (searchable select), Водитель (searchable select), Статус (select), and Дата создания (calendar) 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 19 static rows and add no backend, persistence, production API, or mobile behavior. [S3] [S4] [S7]

Components and Accessibility

The composition uses owned Sidebar, Main Container, Header Widget, Button, Filter Row, and Table components. Status text remains visible in addition to its visual treatment. Header buttons require accessible names, and inert link-formatted numbers must not navigate by mouse or keyboard. [S1]

No cross-screen business flow is defined. The Sidebar movement merely switches between neighboring prototype routes. [S6]

Verification

The focused Waybills, Sidebar, and shell suites passed for D-034. That prior result predates D-039. D-039 focused screen coverage exercises adding, opening, filtering, removing, and resetting local filters without asserting browser or Figma parity. The earlier suites cover fixtures, inert row links, route state, and limited Sidebar destinations. D-034 also recorded passing npm run build, npm run build-storybook, npm run check:design-system, and npm run check:memory; that record is not a D-039 verification result. [S7]

Browser QA at the current desktop browser size confirmed direct /waybills loading, Sidebar switching with browser Back and Forward, Filter Row menu selection, and inert row-number links. Human review and approval have not been requested.

Open Questions

What detail screen or external destination should an ID open?
Which filter choices, loading states, and permissions are required when a real data contract is introduced?