UI slog grinds on

docs/ui/entities/source/user-journey.md

@@ -15,7 +15,8 @@ Managing Source records is page-first:
 1. The user starts from a transcription job flow.
 2. The user adds one or more source files.
 3. The system creates Source records linked to the Document and linked to the Job through JobSource.
-4. The user reviews source lists by document and can navigate to the owning Document or Job.
+4. The user reviews source lists from a dedicated Sources page.
+5. The user opens Source detail to review preview, metadata, transcription text, and revision text.
 
 ## 2. User Goal
 
@@ -32,22 +33,29 @@ The user wants to:
 ### 3.1 Source List Surface
 
 A Source list surface should support:
-1. listing source pages for a selected Document
+1. listing source pages globally or filtered by selected Document or Job
 2. sorting by page_number
 3. opening the owning Document or Job context
+4. opening Source detail for a selected source
 
 ### 3.2 Source Detail Surface
 
-Source detail and revision surfaces are deferred in the current UI.
+Source detail supports:
+1. pan/zoom image or PDF preview
+2. read-only source metadata (page number, names, timestamps)
+3. read-only original transcription text
+4. editable revision text with save action
 
 ## 4. Entry Points
 
 Primary entry points:
 1. from Job workflow, Add sources while creating or configuring a job
-2. from Job detail, open source preview and revision editor
+2. from Job detail, open filtered Sources for the current Job
+3. from Document detail, open filtered Sources for the current Document
+4. from global navigation, open all Sources
 
 Current implementation note:
-1. source interaction currently occurs in job-create and document-scoped source list flows
+1. source interaction occurs in job-create flow and dedicated Sources list/detail flows
 
 ## 5. Create Source Flow
 
@@ -120,11 +128,12 @@ The user wants to view each page file and understand file identity and processin
 ### 6.2 Read Surface Expectations
 
 The UI should show:
-1. source lists grouped by Document
+1. source lists for current context (all, document-filtered, or job-filtered)
 2. upload_name as the original user-provided filename
 3. filename as the stored system filename
 4. page_number and ordering context
 5. the owning Document and Job navigation context
+6. direct action to open Source detail
 
 ### 6.3 Read Empty and Missing States
 
@@ -143,7 +152,7 @@ The user primarily tracks page-level source records while preserving raw machine
 ### 7.2 Intended Editable Fields
 
 Editable in first release:
-1. revised_text in a later revision, not in the current simplified UI
+1. revised_text in Source detail
 
 Read-only in first release:
 1. upload_name
@@ -157,11 +166,11 @@ Read-only in first release:
 ### 7.3 Revision Save Behavior
 
 On save:
-1. validate revision text is non-empty when the revision UI exists in a later release
-2. persist revised_text when the revision UI exists
-3. set date_revised when the revision UI exists
-4. show success feedback when the revision UI exists
-5. keep user in current source context when the revision UI exists
+1. validate revision text is non-empty after trimming
+2. persist revised_text
+3. set date_revised
+4. show success feedback
+5. keep user in current source context
 
 ### 7.4 Revision Failure Behavior
 
@@ -217,3 +226,4 @@ Deferred to future revisions:
 2. multi-file upload progress and resumable upload UX
 3. revision history versions beyond a single revised_text field
 4. richer per-page status dashboards
+5. source delete UI with dependency-aware confirmation