Readiness
| Dimension | Status and evidence |
|---|---|
| Specification | The approved first-version scope is documented as a desktop fixture prototype. [S1] |
| Figma | No Figma authoring or exact-node verification is in scope; the user screenshot records visual intent only. [S1] |
| Local prototype | Implemented as the /waybills fixture screen with 19 static rows and inert controls. [S2] |
| Verification | Focused feature, Sidebar, and shell tests; Angular and Storybook builds; design-system and Memory checks passed. Browser QA covered the current desktop browser size. [S2] |
lifecycle: active documents the current product area; it does not assert an
implemented or validated route.
Value
This area lets internal-logistics users inspect a compact list of waybills and their visible lifecycle state in the desktop prototype. [S1] [S2]
Users and JTBD
The modeled user needs to review the driver, vehicle, trailer, timestamps, and status of a waybill from a dense list. Production roles and permissions are not defined by the fixture. [S1]
Boundaries
The area contains the /waybills fixture screen and its static list.
It does not define a production backend, persistence, search, filtering logic,
waybill form, link destination, mobile layout, or Figma artifact. [S1]
Glossary
ТС: vehicle shown on the waybill row.Путевой лист: the list record represented by a static fixture.
Screens and Flows
screen.waybills: desktop list screen reached from the Internal Logistics Sidebar. [S1] [S2]- No cross-screen business flow is defined in the first version. [S1]
Current Rules and Decisions
The screen reuses the owned design system and keeps all data and controls inside an explicit fixture/stub boundary. [S1] [S2]
Open Questions
- Which production route, detail view, and permissions should an ID open?
- Which data contract and filtering behavior should replace the fixtures?