Deduplicate overlapping rules across contracts
Each rule now has one owning contract; others point to it: validation and multi-step rules live in forms-validation (modal-workflows references them), pagination metadata lives in go-api (table-management references it), the async task flow lives in go-background-tasks (go-api references it), backup git-safety checks live in backup-management (go-database references it). Remove the leftover Vapor/Aqua baseline mention and stale kit/patterns paths, compress the batch-file-upload ADR narrative, and drop content-free pattern READMEs. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
# Contract: Modal Workflows
|
||||
|
||||
Version: 1.0
|
||||
Version: 1.1
|
||||
|
||||
## State Machine
|
||||
|
||||
@@ -29,11 +29,8 @@ closed → open → submitting → success | error
|
||||
|
||||
## Validation
|
||||
|
||||
- Validate on submit server-side. Client-side validation is optional progressive enhancement only.
|
||||
- Show field-level errors inline below each field.
|
||||
- Show a form-level error summary at the top if multiple fields fail.
|
||||
- Error messages must be human-readable and action-oriented: "Serial number is required" — not
|
||||
"serial_number: cannot be null".
|
||||
Validation UX follows the `forms-validation` contract (server-side on submit, inline field
|
||||
errors, form-level summary, human-readable messages).
|
||||
|
||||
## htmx Pattern (server-rendered modals)
|
||||
|
||||
@@ -44,15 +41,13 @@ POST /api/entity → 200 OK + HX-Trigger: "entitySaved" (success)
|
||||
```
|
||||
|
||||
- On success: server sends `HX-Trigger` header, JS listener closes modal and refreshes list.
|
||||
- On validation error: server re-renders the form partial with inline errors (422).
|
||||
- On validation error: server re-renders the form partial with inline errors (422, per `go-api`).
|
||||
- On server error: show generic error toast, log full error server-side.
|
||||
- Do not use `200 OK` for validation errors — use `422` so htmx can differentiate.
|
||||
|
||||
## Multi-Step Modals
|
||||
|
||||
Use only when the workflow genuinely requires staged input (e.g. import preview → confirm).
|
||||
Staged flows follow the `forms-validation` multi-step rules. Modal-specific:
|
||||
|
||||
- Use only when the workflow genuinely requires staged input (e.g. import preview → confirm).
|
||||
- Show a step indicator (Step 1 of 3).
|
||||
- Back button must restore previous step values.
|
||||
- Final confirm step must summarise what will happen before the destructive/irreversible action.
|
||||
- Single-step edits must NOT be split into multi-step without good reason.
|
||||
|
||||
Reference in New Issue
Block a user