# Waybills

<!-- wb-memory.v1
{
  "schemaVersion": "wb-memory.v1",
  "id": "screen.waybills",
  "kind": "screen",
  "title": "Waybills",
  "lifecycle": "active",
  "authority": "canonical",
  "areaId": "area.waybills",
  "routes": ["/waybills"],
  "links": [
    { "type": "uses-component", "targetId": "component.sidebar", "sourceRefIds": ["S6"] },
    { "type": "uses-component", "targetId": "component.main-container", "sourceRefIds": ["S6"] },
    { "type": "uses-component", "targetId": "component.header-widget", "sourceRefIds": ["S4"] },
    { "type": "uses-component", "targetId": "component.button", "sourceRefIds": ["S4"] },
    { "type": "uses-component", "targetId": "component.filter-row", "sourceRefIds": ["S4"] },
    { "type": "uses-component", "targetId": "component.table", "sourceRefIds": ["S4"] }
  ],
  "sourceRefs": [
    {
      "id": "S1",
      "kind": "prd",
      "authority": "evidence",
      "path": "plans/prds/20260909-1146-waybills-screen.prd.md",
      "status": "verified"
    },
    {
      "id": "S2",
      "kind": "spec",
      "authority": "canonical",
      "path": "specs/ux/components/organisms/sidebar.md",
      "status": "verified"
    },
    {
      "id": "S3",
      "kind": "code",
      "authority": "implementation",
      "path": "src/app/features/waybills/waybills.component.ts",
      "status": "verified"
    },
    {
      "id": "S4",
      "kind": "code",
      "authority": "implementation",
      "path": "src/app/features/waybills/waybills.component.html",
      "status": "verified"
    },
    {
      "id": "S5",
      "kind": "code",
      "authority": "implementation",
      "path": "src/app/app.routes.ts",
      "status": "verified"
    },
    {
      "id": "S6",
      "kind": "code",
      "authority": "implementation",
      "path": "src/app/app.component.html",
      "status": "verified"
    },
    {
      "id": "S7",
      "kind": "test",
      "authority": "evidence",
      "path": "src/app/features/waybills/waybills.component.spec.ts",
      "status": "verified"
    }
  ]
}
-->

## 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

1. A user opens `/waybills` or selects «Путевые листы».
2. The screen shows a heading, two inert header actions, a Filter Row, and
   19 waybill fixtures in eight columns.
3. 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]

## Related Flows

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?