generated from john/python-template
145 lines
4.9 KiB
Markdown
145 lines
4.9 KiB
Markdown
# Job Acceptance Criteria
|
|
|
|
Purpose: Define implementation-ready acceptance criteria for Job Create, Read, Update, and Delete workflows.
|
|
|
|
Companion documents:
|
|
- docs/ui/entities/job/user-journey.md
|
|
- docs/ui/entities/job/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. provider-specific transcription internals
|
|
2. advanced workflow scheduling and queue orchestration controls
|
|
3. multi-job bulk operations
|
|
|
|
## Create Acceptance Criteria
|
|
|
|
### CR-1 Job creation entry
|
|
1. Given the user is on the Jobs page
|
|
2. When the user selects Create job
|
|
3. Then the user is taken to Job detail/create mode
|
|
|
|
### CR-2 Required create values
|
|
1. document_id must be selected before submit
|
|
2. at least one source file must be uploaded before submit
|
|
3. each uploaded file creates a Source linked to the selected Document
|
|
4. each created Source is linked to the new Job through JobSource
|
|
|
|
### CR-3 Source ordering behavior
|
|
1. Given multi-file or folder upload
|
|
2. When source records are created
|
|
3. Then page ordering follows alphabetical order of original filenames
|
|
4. Then helper text explains how filename conventions control ordering
|
|
|
|
### CR-4 Provider/model/prompt visibility
|
|
1. provider, model, and prompt_name are visible in create flow when known
|
|
2. provider, model, and prompt_name are visible in detail flow when known
|
|
3. if values are unknown at create time, UI shows clear unknown or pending state without blocking submit
|
|
|
|
### CR-5 Successful create outcome
|
|
1. Given valid inputs
|
|
2. When the user submits create
|
|
3. Then the Job record is created and linked to selected Document
|
|
4. Then source and JobSource records are created for uploads
|
|
5. Then job status is queued or processing based on execution timing
|
|
6. Then the user is routed to Job detail mode
|
|
|
|
### CR-6 Create failure outcome
|
|
1. Given create validation or persistence failure
|
|
2. Then clear error feedback is shown
|
|
3. Then no false success feedback is shown
|
|
4. Then entered selections are preserved where possible
|
|
5. Then retry path remains available
|
|
|
|
## Read Acceptance Criteria
|
|
|
|
### RD-1 Jobs list retrieval
|
|
1. Given one or more jobs exist
|
|
2. When the user opens the Jobs page
|
|
3. Then all jobs are listed in a table or equivalent list surface
|
|
|
|
### RD-2 Jobs list fields
|
|
1. Jobs list shows job id
|
|
2. Jobs list shows status
|
|
3. Jobs list shows created or updated timestamps
|
|
4. Jobs list shows retry_count when available
|
|
5. Jobs list provides navigation to Job detail for each row
|
|
|
|
### RD-3 Job detail retrieval
|
|
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 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 remains deferred in the current UI
|
|
|
|
### RD-5 Missing and invalid id states
|
|
1. Given an invalid job id format
|
|
2. Then UI shows invalid job id state without crashing
|
|
3. Given a valid but nonexistent job id
|
|
4. Then UI shows job not found state without crashing
|
|
|
|
## Update Acceptance Criteria
|
|
|
|
### UP-1 Revision edit entry
|
|
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. source revision editing remains deferred in the current UI
|
|
|
|
### UP-3 Successful revision save
|
|
1. deferred until the source revision UI is restored
|
|
|
|
### UP-4 Revision save failure
|
|
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
|
|
2. retry_count updates are reflected when retry logic runs
|
|
3. users cannot directly edit lifecycle state fields in first release
|
|
|
|
## Delete Acceptance Criteria
|
|
|
|
### DL-1 Delete entry and confirmation
|
|
1. job deletion is deferred in the current UI
|
|
|
|
### DL-2 Dependency guardrails
|
|
1. deferred until a job delete flow is reintroduced
|
|
|
|
### DL-3 Blocked delete behavior
|
|
1. deferred until a job delete flow is reintroduced
|
|
|
|
### DL-4 Successful delete
|
|
1. deferred until a job delete flow is reintroduced
|
|
|
|
### DL-5 Delete failure
|
|
1. deferred until a job delete flow is reintroduced
|
|
|
|
## 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 UI action or service path
|
|
2. No acceptance criterion contradicts first-release deferred items
|
|
|
|
### QG-3 First-release constraints
|
|
1. Jobs page remains list-all with explicit Create job action
|
|
2. Job create requires Document selection and source upload
|
|
3. provider/model/prompt_name are visible to users when known
|
|
4. manual retry controls may remain deferred while status visibility is required
|