The Order of the Walk — The Order on the Order Form Is Not the Warehouse's Order

This is not a specific business. We constructed the shape exactly as it works in a small logistics warehouse, and we do not name where. The SKUs and rack coordinates are invented; the code, screens and logs actually ran.

An order form is the sequence the customer put things in. A warehouse is the sequence the racks are in.

The two have nothing to do with each other. And yet most picking lists are printed in order-form sequence. So a person goes to aisle 1, then aisle 4, then back to aisle 1.

Measure instead of assert

Anyone can say "sorting makes it faster". This sample computes both routes and puts them on the screen together.

as typed 106 steps · walking order 82 steps · saved 24 steps

Walk it as typed and it is 106 steps; walk it in rack order and it is 82. A 24-step difference comes out of one five-line order.

The step calculation is crude on purpose.

/// Crude on purpose: moving along an aisle costs one per bay, and changing
/// aisle costs the walk to the end and back. It does not need to be a real
/// floor plan to show that the two sequences are not the same length.

Even without a real warehouse floor plan, that the two sequences are not the same length is visible. That is all this piece claims; claim more and you need the floor plan.

The sort is not data

An order must not have a "sequence" field. Sequence comes out of location; it does not arrive.

/// The same lines, in the sequence a person actually walks.
List<Line> get _walkOrder => List.of(_lines)
  ..sort((a, b) {
    final byAisle = a.slot.aisle.compareTo(b.slot.aisle);
    if (byAisle != 0) return byAisle;
    return a.slot.bay.compareTo(b.slot.bay);
  });

Move an item to a different rack and the sequence changes by itself from the next pick onward. Had the sequence been stored, somebody would have to recompute all of it, and because nobody does, the list slowly goes wrong.

The verification confirms that sequence.

grep -q "walking order: A1-03-L1 -> A1-14-L2 -> A2-09-L1 -> A4-02-L3 -> A4-12-L2" captures/run.log \
  || { echo "   the route changed — check whether it is still a walk"; exit 1; }

And the harness checks the sort itself.

final sorted = List.of(slots)..sort();
expect(slots, sorted, reason: 'the route must be in walking order');

The steps saved must not be in the source

Where the number 24 came from is the whole of this piece's credibility. So if that number is in the source, the verification fails.

SAVED=$(grep -o "saved [0-9]* steps" captures/run.log | head -1 | awk '{print $2}')
[ "$SAVED" -gt 0 ] || { echo "   walking order saved nothing — the claim fails"; exit 1; }
if grep -RIn --exclude-dir=captures -F "$SAVED steps" pick_server/bin pick.mbd >/dev/null 2>&1; then
  echo "   the saving $SAVED is written literally in the source — it must be measured"
  exit 1
fi

   walking order saved 24 steps, and that number is nowhere in the source

This check is the shape first used in A Log You Can Ask. If a figure on screen is embedded in the source as a string, it is not a computation but a drawing.