feat:

[kirillakovalenko]

Description

Today, optimization assumes total delivery demand fits within total vehicle capacity. When users have more deliveries than the fleet can carry in a single pass, they have no clean way to optimize a partial set and defer the rest. The VROOM backend already returns an unassigned array (vroomResponse.ts), so the building block exists — we need to surface it through the Manage page (/edit) and Results page (/results) flow.

This feature lets users optimize even when demand exceeds capacity: the system packs the most efficient deliveries into routes, sends those to the Results page, and leaves the overflow on the Manage page tagged as un-optimized so they can be carried into the next optimization round.

Goal

Let users optimize when total delivery demand exceeds total fleet capacity, routing the deliveries that fit and clearly deferring the rest for a later round.

Scope

In scope

• Remove the precondition/block that prevents optimization when total demand > total capacity; submit the full set and let the solver assign what fits.
• Surface the solver's unassigned deliveries back to the Manage page instead of failing the whole optimization.
• Optimized (assigned) deliveries appear on the Results page; un-optimized (unassigned) deliveries remain on the Manage page.
• Add a visual tag/badge on Manage-page delivery cards marking deliveries that were not optimized in the last run.
• Navigation guard: once the user edits any delivery (or vehicle) on the Manage page, block navigation to the Results page until they re-run Optimize. Re-enable the Results link only after a successful optimization reflecting the current Manage-page state.
• On Export from the Results page, remove the optimized (tagged-as-routed) deliveries from the Manage page, leaving the un-optimized deliveries intact for the next round.

Out of scope

• Changing the solver's internal assignment/efficiency algorithm (we rely on VROOM's existing route packing and unassigned output).
• Multi-round auto-optimization (automatically looping until all deliveries are routed).
• Vehicle-side capacity editing or fleet-sizing suggestions.
• Persisting deferred deliveries across full app reloads/sessions beyond current storage behavior.

Acceptance Criteria

• Submitting deliveries whose total demand exceeds total fleet capacity no longer errors or blocks; optimization completes and returns routes for the deliveries that fit.
• Deliveries the solver could not assign (unassigned) remain on the Manage page after optimization; assigned deliveries appear on the Results page.
• Each un-optimized delivery on the Manage page shows a clear visual tag/badge distinguishing it from optimized/unprocessed deliveries.
• After editing any delivery or vehicle on the Manage page, the Results navigation (sidebar/results button) is disabled and cannot be reached until Optimize is re-run successfully.
• Re-running Optimize after edits re-enables Results navigation and reflects the updated input.
• Exporting from the Results page removes the optimized deliveries from the Manage page while keeping the un-optimized (tagged) deliveries available for the next optimization round.
• Tests cover: optimize with demand > capacity, the unassigned-deliveries-stay-on-Manage behavior, the navigation guard, and the export-deletes-optimized behavior.

Assignee

@Gill87