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