[codex] Assess DocketWorks design direction

[corrin]

Purpose

KAN-272 asks whether DocketWorks has a coherent app design direction. The product risk is that operational users must scan jobs, timesheets, purchasing, clients, and accounting views quickly and repeatedly; inconsistent density, hierarchy, status language, controls, and interaction patterns make the app harder to trust, harder to train, and more expensive to extend.

This draft should turn the current design state into a clear implementation plan. It is not expected to ship visual changes.

Delivered Value

The branch gives us a starting point for the design-direction assessment. Before it is ready to merge, it needs to convert that starting point into a short written verdict and an ordered backlog of follow-up work.

The assessment should make one important distinction clear: existing-screen inconsistency is a Claude Code audit-and-refactor problem, while Claude Design is useful later for flow, hierarchy, and screen exploration once the foundation is consistent.

Acceptance Criteria

Before merge, this PR must document:

1. Whether the current app is coherent, partly coherent, or fragmented.
2. The design principles DocketWorks should use for operational screens, covering density, hierarchy, tables/lists, forms, navigation, statuses, destructive actions, loading/empty states, and modal/drawer usage.
3. Evidence from the main workflow areas: jobs/kanban, timesheets, purchasing, clients, accounting/reporting, and shared UI patterns.
4. The existing patterns that should be preserved because they already work well.
5. The most important inconsistencies or usability risks, with examples from real workflows.
6. The business cost of those issues: slower scanning, weaker trust, harder training, or more expensive future changes.
7. Prioritised follow-up Jira tickets, each tied to user-visible value.
8. Which follow-up items belong to Claude Code consistency work, and which belong to later Claude Design flow/UX exploration.

Out Of Scope

This PR should not redesign the app, refactor UI implementation, or choose new flows. Merging it should mean the assessment is clear enough that the next branch can implement the highest-value consistency fixes without reopening the design question.

Validation

The branch currently passes the local pre-push gate, including backend type checking, frontend unit tests, linting, and frontend type checking.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 6dcb7efb-cac5-433a-9eda-38907a796573

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch codex/design-sync-extraction

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}