Repository navigation
UX: Files for Processing empty state lacks a clear next user action #87
Description
Status: Candidate UX/UI finding — not approved implementation work.
Source: automated UX audit (Grok Bot)
Last verified:master@e96a3ea
Surface: other
Classification: UX-FRICTION / FEEDBACK
Confidence: mediumSecurity: Follow
SECURITY.md. Do not expose real storage paths from production libraries in public issues; this audit used testing mode and observed UI copy only.
Finding
Files for Processing empty state explains a filesystem inbox path and offers Refresh folder scan, but does not connect to a clear next user action (upload / New File / copyable instructions). Global New File is not linked from this empty state.
Reproduction
- Open Files for Processing when empty.
- Read empty-state copy and available actions.
Deterministic empty-state observation this pass.
Current behavior
Backend-oriented empty copy + Refresh only; no primary “add a PDF” path tied to the route.
Expected / improved behavior
Primary Add PDF / Open New File CTA, plus clearer “where files come from” help. If filesystem-only ingestion is intentional, say so in user language and make the instruction/path actionable (copyable / open-instructions dialog) without requiring users to already know server layout.
User impact
Users who open Processing directly may not know how to get a first file into the queue.
Evidence
- Tested commit:
master@e96a3ea - Surface labeled
otherin taxonomy terms; UI name is Files for Processing.
Likely affected area
Hypothesis: Processing empty-state copy and actions.
Recommended direction
User-action-first empty state; keep Refresh as secondary. Non-goal: changing ingestion architecture in this finding.
Acceptance criteria
- Empty Processing presents a clear next action for a first-time user.
- Filesystem-only constraints, if any, are explained in plain language.
Existing issue / roadmap overlap
Related roadmap: #40 Processing Inbox V2. This finding is limited to empty-state next-action clarity in the current UI.
No overlapping ux-finding for Processing empty-state next action.
Assessment
- Priority: P3
- Areas:
area:ux - Change risk: low
This issue records a UX/UI finding for review. It does not authorize implementation.
Found using Grok Bot
Metadata
Metadata
Assignees
Labels
Projects
- StatusShow more project fieldsInbox

Activity
Fooftilly commentedon Oct 6, 2026
Sequencing / roadmap overlap
Strong overlap with #40 Processing Inbox V2. #40 adds a clearer ingestion queue and web-UI add/upload flow, which is likely to replace this current empty-state/Refresh-only interaction. Prefer using #87 as an acceptance criterion for the #40 empty state rather than implementing a temporary CTA on the current surface unless #40 is deliberately postponed.