Risks
P1 — Must Address Before Building
Information Overload
Showing everything about a vehicle on one screen could overwhelm users on small screens.
Mitigation: Tabs separate content. Quick actions are contextual — only relevant options appear. Moked cards are collapsible.
Offline Disruption
The current offline architecture is deeply tied to per-workflow controllers.
Mitigation: The service and data layer is not touched. This redesign only changes navigation and presentation. PhotoUploadService, SQLite queues, and deferred uploads remain exactly as they are.
Performance
Loading all mokeds, subitems, and photos for a vehicle on one screen could be slow.
Mitigation: Tabs lazy-load on demand (Photos tab only loads when tapped). Photo thumbnails are compressed. SubItem lists are virtualized.
P2 — Plan For, Handle During Build
Complex Flows in Panels
Some workflows (appraisal: 10 steps, pickup: 7 steps) are too complex for slide-in panels.
Mitigation: Complex flows stay full-screen with a "← Back to Vehicle" breadcrumb. Only simple and medium actions use panels.
GetX Controller Lifecycle
Current architecture relies on per-route GetX Bindings. The vehicle detail view manages multiple concerns in one screen.
Mitigation: New VehicleDetailController pattern. Don't reuse existing workflow controllers — create new lightweight action handlers that delegate to the same services.
Migration Friction
Users have muscle memory for the current card-based navigation.
Mitigation: Phased rollout. Vehicle Hub is additive in Phase 1 — old cards remain functional. Users adopt at their own pace.
P3 — Monitor
Deep Link Compatibility
Existing deep links (e.g., /pending-office/:itemId) need to keep working.
Mitigation: Maintain existing routes as redirects. They can optionally open the vehicle view with the relevant tab and action pre-selected.