generated from john/python-template
UI update planning continued
This commit is contained in:
Jim Lancaster
@@ -0,0 +1,144 @@
|
||||
# Person Acceptance Criteria
|
||||
|
||||
Purpose: Define implementation-ready acceptance criteria for Person Create, Read, Update, and Delete workflows.
|
||||
|
||||
Companion documents:
|
||||
- docs/ui/entities/person/user-journey.md
|
||||
- docs/ui/entities/person/schema-mapping.md
|
||||
|
||||
## Scope
|
||||
|
||||
This checklist covers:
|
||||
1. Create flow
|
||||
2. Read flow
|
||||
3. Update flow
|
||||
4. Delete flow
|
||||
|
||||
This checklist does not cover:
|
||||
1. advanced metadata_ editing UX
|
||||
2. structured-name schema migration implementation
|
||||
3. bulk merge or dedup workflow design
|
||||
|
||||
## Create Acceptance Criteria
|
||||
|
||||
### CR-1 Person creation entry
|
||||
1. Given a Person page
|
||||
2. When the user selects Create new person
|
||||
3. Then the user can open a Person create form
|
||||
|
||||
### CR-2 Required field validation
|
||||
1. full_name is required
|
||||
2. Save is blocked when full_name is empty
|
||||
3. Inline feedback is shown for required-field errors
|
||||
|
||||
### CR-3 Optional field handling
|
||||
1. Optional fields may be blank without blocking create
|
||||
2. Date raw and exact fields can coexist
|
||||
3. Exact date remains canonical when both exact and raw are provided
|
||||
|
||||
### CR-4 Successful create outcome
|
||||
1. Given valid input
|
||||
2. When the user saves
|
||||
3. Then the Person record is created
|
||||
4. Then success feedback is shown
|
||||
5. Then the user is routed to Person detail page
|
||||
|
||||
### CR-5 Create failure outcome
|
||||
1. Given backend failure during create
|
||||
2. Then clear error feedback is shown
|
||||
3. Then entered values are retained where possible
|
||||
4. Then no false success feedback is shown
|
||||
|
||||
## Read Acceptance Criteria
|
||||
|
||||
### RD-1 Person detail retrieval
|
||||
1. Given a valid Person id
|
||||
2. When the user opens the Person detail page
|
||||
3. Then the system displays Person metadata for that record only
|
||||
|
||||
### RD-2 Metadata visibility
|
||||
1. The page shows full_name and available optional person fields
|
||||
2. created_at and updated_at are shown as system-managed, read-only values
|
||||
|
||||
### RD-3 Linked documents section
|
||||
1. Given no linked DocumentPerson rows
|
||||
2. Then the page shows a no linked documents yet empty state
|
||||
3. Given linked documents exist
|
||||
4. Then the page shows linked document entries
|
||||
|
||||
### RD-4 Read failure state
|
||||
1. Given a nonexistent Person id
|
||||
2. Then the UI shows a clear not found state without crashing
|
||||
|
||||
## Update Acceptance Criteria
|
||||
|
||||
### UP-1 Edit entry
|
||||
1. Given a loaded Person detail page
|
||||
2. When the user selects Edit person
|
||||
3. Then editable controls are shown for allowed fields only
|
||||
|
||||
### UP-2 Editable fields
|
||||
1. Editable: full_name, display_name, maiden_name, birth/death fields, places, biography, portrait_path
|
||||
2. Not editable: id, created_at, updated_at
|
||||
3. metadata_ remains hidden in first release
|
||||
|
||||
### UP-3 Required validation
|
||||
1. full_name remains required
|
||||
2. Save is blocked with inline feedback when full_name is empty
|
||||
|
||||
### UP-4 Successful save
|
||||
1. Given valid input
|
||||
2. When the user saves
|
||||
3. Then changes persist
|
||||
4. Then success feedback is shown
|
||||
5. Then the user remains on Person detail with refreshed values
|
||||
|
||||
### UP-5 Save failure
|
||||
1. Given backend failure during save
|
||||
2. Then clear error feedback is shown
|
||||
3. Then the user-entered values remain available for retry where possible
|
||||
4. Then no false success feedback is shown
|
||||
|
||||
## Delete Acceptance Criteria
|
||||
|
||||
### DL-1 Delete entry and confirmation
|
||||
1. Given a Person detail page
|
||||
2. When the user selects Delete person
|
||||
3. Then a confirmation dialog appears with permanent-action wording
|
||||
|
||||
### DL-2 Relationship guardrails
|
||||
1. Delete is allowed only when relationship policy allows it
|
||||
2. If linked DocumentPerson rows must be removed first, delete is blocked
|
||||
|
||||
### DL-3 Blocked delete behavior
|
||||
1. When blocked
|
||||
2. Then the UI explains why deletion is blocked
|
||||
3. Then the UI identifies linked-document dependency presence
|
||||
4. Then the UI provides navigation to cleanup paths
|
||||
|
||||
### DL-4 Successful delete
|
||||
1. Given no blocking dependencies
|
||||
2. When the user confirms delete
|
||||
3. Then the Person record is removed
|
||||
4. Then success feedback is shown
|
||||
5. Then the user returns to the Person list page
|
||||
|
||||
### DL-5 Delete failure
|
||||
1. Given backend failure during delete
|
||||
2. Then clear error feedback is shown
|
||||
3. Then the user remains on Person detail with retry path
|
||||
|
||||
## Cross-Criteria Quality Gates
|
||||
|
||||
### QG-1 Separation of intent and implementation
|
||||
1. UX intent remains in user-journey.md
|
||||
2. current versus target implementation mapping remains in schema-mapping.md
|
||||
|
||||
### QG-2 Traceability
|
||||
1. Each accepted behavior maps to at least one future UI action or service call path
|
||||
2. No acceptance criterion contradicts the deferred-item policy
|
||||
|
||||
### QG-3 First-release constraints
|
||||
1. metadata_ remains hidden in first release
|
||||
2. structured name field split remains deferred
|
||||
3. recipient and multi-person role management stays in later revisions
|
||||
Reference in New Issue
Block a user