Warehouse scan shipped at Luke's: schema, mobile flow, and coverage

Luke's warehouse intake had outgrown manual handling. The process worked when volume was low, but scan events, container moves, and assignment updates were too easy to lose in handoffs between floor operations and admin updates. We shipped a full warehouse-scan slice on 2026-05-17 — schema and API changes, mobile admin workflow, tests, and docs — then followed with a live-feedback fix pass on 2026-06-04. The result is a tighter intake path that is easier to operate and easier to trust.

This post covers what shipped in commits a0614ce, aad7ecd, and 5dab888, and why this sequence mattered.

What shipped in the rollout

The core rollout landed in a0614ce with one integrated scope:

• warehouse scan schema and backend support,
• scan and container APIs (create/list/move/scan paths),
• mobile admin flow in admin/warehouse.php,
• warehouse-focused tests and documentation updates.

This was intentional packaging. Splitting schema, APIs, and UI into separate releases would have created a period where operators could see controls that were not backed by stable data paths, or backend paths without usable floor tooling. Shipping them together made the first production week about real workflow usage instead of integration cleanup.

Why test coverage shipped in the same window

aad7ecd tightened test posture around the same slice:

• 90% unit coverage gate,
• full API integration coverage for core CRUD and POST flows,
• Playwright E2E coverage for admin/UI and API paths,
• CI-friendly handling for JSON body reads in CLI test contexts.

The point was not to chase a vanity metric. The point was to keep warehouse intake changes from regressing under normal product work. Once scan and move flows are in daily use, breakage cost rises fast. Coverage turned this from "watch production and hope" into "breakage surfaces in tests first."

What changed after live floor feedback

5dab888 is the practical reality check commit. After warehouse usage, Luke surfaced three specific friction points:

• intake needed to target a dedicated warehouse-intake auction flow,
• scan-created items needed clean handling for blank descriptions,
• operators needed faster bulk SKU paste and line-item delete controls in warehouse browse/admin contexts.

This is exactly what good rollout sequencing should produce: ship a coherent first version, run it in real conditions, then tighten based on direct operator feedback instead of assumptions.

Operational impact

The immediate benefit is less translation work between physical intake and admin state. Warehouse actions now have first-class API paths and UI controls designed for the same flow, not patched together from unrelated screens.

The second benefit is confidence. With tests and live-feedback fixes in place, operators and engineering can iterate without reintroducing the same intake failures each week.

What this means for similar teams

If your warehouse tooling is still a mix of manual notes and partial admin controls, the transferable pattern here is straightforward:

1. ship schema + API + operator UI as one slice,
2. ship tests in the same window, not later,
3. schedule a fast live-feedback pass after first floor usage.

That three-step sequence is what turned this from a feature drop into an operable intake workflow.