TourPolicyIfc

The order a vehicle visits the stops it has committed to.

This is the decision multi-load adds, and it is the dispatcher's. With one task there is no decision: collect, then deliver. With several there is an order, and the order is most of what makes a multi-load fleet good or bad — so it is a seam rather than a rule, because otherwise every study of a multi-load fleet would be a study of whichever heuristic was written here.

A vehicle executes tours; it does not author them (A7). A vehicle may compute a candidate order — that is how a bid prices the marginal cost of taking a task, and because a policy is a pure function the bid can call the very policy the dispatcher will use, so the quote and the plan cannot disagree. What a vehicle may never do is commit to one.

The contract

• The returned list must contain exactly the stops it was given — remaining plus insert, by identity, no more and no fewer. A violation raises FleetTourException naming the policy and what was added or dropped.

• Precedence: a task's pickup must come before its set-down.

• Capacity: walking the stops and counting one on at each pickup and one off at each set-down, the running count must never exceed the vehicle's load capacity. This is what makes the problem non-trivial: an insertion can be the cheapest and still infeasible.

• Pure and deterministic. No state across calls, no randomness without an explicit stream, and no mutation of anything it is handed.

The framework validates all three rather than trusting them, and refuses rather than quietly repairing: a framework that reorders a policy's answer has taken the decision away from it.

Inheritors