feat: bootstrap design kit and vaporwave demo baseline
This commit is contained in:
13
kit/patterns/operator-tools/README.md
Normal file
13
kit/patterns/operator-tools/README.md
Normal file
@@ -0,0 +1,13 @@
|
||||
# Operator Tools Pattern
|
||||
|
||||
Universal pattern for complex operator/admin dashboards in Go web applications.
|
||||
|
||||
This pattern standardizes:
|
||||
|
||||
- scope tabs and queue/status filters
|
||||
- operations queue tables with row actions
|
||||
- batch actions with explicit selection
|
||||
- import/export shortcuts near operator workflows
|
||||
- safety checklists and confirmation routing
|
||||
|
||||
See `contract.md` for behavior rules.
|
||||
36
kit/patterns/operator-tools/contract.md
Normal file
36
kit/patterns/operator-tools/contract.md
Normal file
@@ -0,0 +1,36 @@
|
||||
# Contract: Operator Tools Dashboard
|
||||
|
||||
## 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.
|
||||
Reference in New Issue
Block a user