44 lines
1.7 KiB
Markdown
44 lines
1.7 KiB
Markdown
# Contract: Operator Tools Dashboard
|
|
|
|
## Shared Base
|
|
|
|
- This pattern inherits the shared `table-management` contract:
|
|
`kit/patterns/table-management/contract.md`.
|
|
- Reuse shared toolbar/table/icon geometry from the base contract first, then define only
|
|
operator-specific behavior.
|
|
|
|
## Purpose
|
|
|
|
Provide a canonical structure for high-density operator/admin screens without encoding
|
|
domain-specific terminology or business rules.
|
|
|
|
## Required UI Regions
|
|
|
|
- Scope tabs (or equivalent segmented navigation)
|
|
- Queue/status filters
|
|
- Batch action bar with explicit selection count
|
|
- Primary queue table/list with stable row actions
|
|
- Safety/guardrail region (checklist, warnings, runbook notes)
|
|
|
|
## Selection and Batch Actions
|
|
|
|
- Batch actions must require explicit selection; never infer hidden rows by default.
|
|
- The UI must display selection counts for the current view and, if applicable, outside the current view/filter.
|
|
- Destructive or high-impact actions must route through an explicit confirmation step (modal or dedicated confirm state).
|
|
|
|
## Status and Queue Semantics
|
|
|
|
- Queue/status labels must be consistent across filters, row badges, and summaries.
|
|
- Failed items must remain easy to filter and retry without losing current scope context.
|
|
- Running/queued states should be visually distinct from done/failed states.
|
|
|
|
## Import / Export Placement
|
|
|
|
- Import preview and export actions should be discoverable near operator workflows.
|
|
- Export scope must remain explicit (`selected`, `filtered`, `all`) when ambiguity exists.
|
|
|
|
## Reuse Boundary
|
|
|
|
- Keep the pattern generic: host projects provide their own tool names, domain fields, and backend execution logic.
|
|
- This contract standardizes interaction semantics and layout zones, not business workflows.
|