mchus/bible
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Deduplicate overlapping rules across contracts

Browse Source 
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:
Michael Chus
2026-06-12 10:00:02 +03:00
parent 558f6e5601
commit 421d004faf
13 changed files with 36 additions and 137 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
rules/patterns/modal-workflows/README.md
View File

@@ -1,9 +0,0 @@
# Modal Workflow Pattern
This pattern package captures modal-based create/edit/remove workflows for server-rendered Go
web UIs.
Synthesis sources:
- detailed enterprise UI interaction contracts
- operational admin workflows in Go web apps

17
rules/patterns/modal-workflows/contract.md
View File

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