generated from john/python-template
UI updates, changes sync'd to UI docs
This commit is contained in:
@@ -76,12 +76,12 @@ This checklist does not cover:
|
||||
1. Given a valid job id
|
||||
2. When the user opens Job detail
|
||||
3. Then job metadata for that record only is shown
|
||||
4. Then source preview or source warning state is shown
|
||||
4. Then document-scoped navigation links for Sources and Jobs are shown
|
||||
|
||||
### RD-4 Detail execution context visibility
|
||||
1. provider, model, and prompt_name are displayed when known
|
||||
2. status lifecycle value is visible
|
||||
3. source-level transcription and revision context is visible
|
||||
3. source-level transcription and revision context remains deferred in the current UI
|
||||
|
||||
### RD-5 Missing and invalid id states
|
||||
1. Given an invalid job id format
|
||||
@@ -92,25 +92,18 @@ This checklist does not cover:
|
||||
## Update Acceptance Criteria
|
||||
|
||||
### UP-1 Revision edit entry
|
||||
1. Given a job detail page with source context
|
||||
2. When the user enters revision edit flow
|
||||
3. Then revised_text input is available
|
||||
1. Given a job detail page
|
||||
2. When the user opens the page
|
||||
3. Then document-scoped navigation links are available
|
||||
|
||||
### UP-2 Revision validation
|
||||
1. revised_text cannot be saved as empty after trimming
|
||||
2. Warning feedback is shown for invalid empty input
|
||||
1. source revision editing remains deferred in the current UI
|
||||
|
||||
### UP-3 Successful revision save
|
||||
1. Given valid revision text
|
||||
2. When the user saves
|
||||
3. Then revised_text persists
|
||||
4. Then success feedback is shown
|
||||
5. Then refreshed revision content is visible
|
||||
1. deferred until the source revision UI is restored
|
||||
|
||||
### UP-4 Revision save failure
|
||||
1. Given backend failure during revision save
|
||||
2. Then clear error feedback is shown
|
||||
3. Then the user-entered text remains available for retry where possible
|
||||
1. deferred until the source revision UI is restored
|
||||
|
||||
### UP-5 Job lifecycle state update visibility
|
||||
1. status changes from queued to processing to terminal states are reflected in UI
|
||||
@@ -120,30 +113,19 @@ This checklist does not cover:
|
||||
## Delete Acceptance Criteria
|
||||
|
||||
### DL-1 Delete entry and confirmation
|
||||
1. Given a job detail context with delete affordance
|
||||
2. When the user selects delete job
|
||||
3. Then a permanent-action confirmation dialog appears
|
||||
1. job deletion is deferred in the current UI
|
||||
|
||||
### DL-2 Dependency guardrails
|
||||
1. If deletion policy requires retention handling for related JobSource history, delete is blocked
|
||||
2. If deletion policy allows dependent cleanup path, delete can proceed
|
||||
1. deferred until a job delete flow is reintroduced
|
||||
|
||||
### DL-3 Blocked delete behavior
|
||||
1. When blocked
|
||||
2. Then UI explains dependency constraints
|
||||
3. Then UI provides cleanup guidance
|
||||
1. deferred until a job delete flow is reintroduced
|
||||
|
||||
### DL-4 Successful delete
|
||||
1. Given no blocking dependencies
|
||||
2. When the user confirms deletion
|
||||
3. Then job is removed
|
||||
4. Then success feedback is shown
|
||||
5. Then the user returns to Jobs list
|
||||
1. deferred until a job delete flow is reintroduced
|
||||
|
||||
### DL-5 Delete failure
|
||||
1. Given backend failure during delete
|
||||
2. Then clear error feedback is shown
|
||||
3. Then the user remains in Job context with retry path
|
||||
1. deferred until a job delete flow is reintroduced
|
||||
|
||||
## Cross-Criteria Quality Gates
|
||||
|
||||
|
||||
Reference in New Issue
Block a user