Template — CRUD page

Status: v0.1.0 — Draft. Promoted from the KDS × gov.br Design System gap analysis (tools/design-gen/docs/govbr-ds-gap-analysis.md, GVB-18). Source: gov.br Padrão Digital transactional crud template.

R1 — Composition, not new UI

CRUD is a composition of existing patterns — this template defines how they connect, it does not introduce new components:

• List → specs/patterns/admin-data-table.kmd
• Detail (read) → a read view of one record
• Create / Edit → specs/patterns/form-page.kmd + specs/patterns/form-validation.kmd
• Delete → a confirmed destructive action (R5)

If a screen needs only one of these, use that pattern directly — reach for the CRUD template when the user manages a set of records end to end.

R2 — List (the entry point)

• The list is an admin data table: sortable/filterable columns, a Create primary action, and per-row actions (open, edit, delete).
• Row click opens detail (read) by default; edit is an explicit action, not an accidental click. Bulk actions (where relevant) follow the data-table spec, with confirmation for destructive ones.

R3 — Detail (read view)

• The detail view reads one record: grouped fields, related lists, and the actions available on it (Edit, Delete, and domain actions). It is not an edit surface — editing is an explicit transition to the form (R4).
• Provide clear back to the list (specs/navigation/back-behavior.kmd) and, where the set is ordered, prev/next between records.

R4 — Create / Edit (the form)

• Create and Edit use the form-page pattern (sections + sticky save bar) with the form-validation contract (inline + error summary + success). Create starts empty; Edit is pre-filled and dirty-tracked.
• A successful save confirms (specs/patterns/confirmation-page.kmd or an inline success) and returns to detail or list. The unsaved-changes guard applies to both.

R5 — Delete (confirmed, recoverable where possible)

• Delete is a confirmed destructive action: a dialog stating what will be removed and its consequences (pairs with specs/patterns/approval-gate.kmd when policy requires an extra gate). Never delete on a single unconfirmed click.
• Prefer soft-delete / undo where the domain allows (an "Undo" window beats a scary confirm). Hard deletes name what is lost.

R6 — Navigation & state

• The four surfaces form a coherent flow: list ⇄ detail ⇄ edit, list → create. Back always returns to the sensible parent; deep links to detail/edit work (the URL carries the record id).
• After create/delete, return to the list with the change reflected (and a confirmation), not to a stale cached view.

R7 — Accessibility & i18n

• Each surface has a real <h1> and landmarked structure; focus moves predictably on each transition (list→detail→edit→back).
• Destructive confirms are keyboard-operable and clearly labeled; the default focus is the safe choice.
• All chrome (actions, confirms, field labels, success/empty copy) is translatable per specs/i18n/contract.kmd.

Não-escopo

• The overview/analytics surface (specs/patterns/dashboard-page.kmd).
• Exportable reports (specs/patterns/report-page.kmd).
• The individual field/table components.
• Domain-specific workflow steps beyond generic CRUD (model as their own patterns).