Adds POST /api/v1/optimization/nagercoil/riderassign. Nagercoil runs with one
rider, so this skips the matching/VRP/pattern logic in riderassign and straight-
assigns every order to the single rider, then reuses the shared TSP sequencer
(_sync_optimize_route) so stop order, cumulative kms and per-stop ETAs match the
main endpoint's response shape.
Rider defaults to Sivakumar Subramani (userid 852, 8248176099) via the
NAGERCOIL_RIDER constant; a `rider` object in the request body overrides it.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018jhRcey2fxhwz2SuPVm7c5
/root/Routes-api was not a repository. Work had been done directly here
and existed nowhere else, so deploying from git would have silently
reverted it -- which nearly happened with the Valhalla road-backend
probe. Now the box tracks origin/main, and any drift shows up in
git status instead of being invisible until something breaks.
Runtime state is untracked rather than committed. ml_data holds the live
FAISS delivery-history index and bandit state, and the .pkl files hold
live rider state; all are written by the running container. Tracking
them meant git status was 93 lines of noise that would bury a real source
change, and a stray `git checkout .` would have rolled learned behaviour
back to a months-old commit. They stay on disk, they just leave the index.
Also drops __pycache__ and three stray files (Untitled (2), input,
output) that were committed by accident and no longer exist here.
.env stays tracked but is marked skip-worktree: it is per-environment, so
it would otherwise read as modified forever.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
f804791 added app/routes/doormile.py against a base that predated the
Valhalla work. Rebasing it onto 9ef2f61 rewires it to what is really
running, without disturbing anything the server had: the RoadMatrix
probe, road_backend_status and the VALHALLA_URL switch are all intact.
The one thing the endpoint depends on is unchanged --
optimize_provider_payload(orders, start_coords=None) has the same
signature in the server's optimizer as in the version it was written
against -- so passing the kitchen through as the run's start still
works. Tests re-run against the server's code: all pass.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
/root/Routes-api on 31.97.228.132 is not a git repository. Work had been
done directly on the box and existed nowhere else -- a single rm -rf from
being lost, and impossible to review or roll back.
Deploying the previous HEAD over it would have silently reverted all of
this. Most visibly the Valhalla road-backend probe in main.py, whose own
comment explains why it exists: road sequencing degrades to aerial
silently by design, so an unreachable backend stays invisible, "which is
exactly how the expired Google key went unnoticed". Overwriting it would
have reintroduced precisely the failure it was written to catch, and the
service would have kept answering 200 throughout.
The server had also moved from Google Maps to Valhalla for road distance
(VALHALLA_URL, road_backend_status, +190 lines in route_optimizer),
extended docker-compose from 44 to 95 lines, and changed rider fetching,
health, dynamic config and the cache layer.
Only 10 files differ in substance. The other 27 that appeared to differ
were CRLF-vs-LF noise -- the server writes CRLF -- and are normalised to
LF here rather than committed as spurious whole-file rewrites.
Committed as-is, before any change of mine, so the diff that follows is
reviewable against what is actually running.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
POST /api/v1/optimization/doormile/sequence. Same optimizer, same
riders, same kitchens, same step semantics as the provider flow -- it
only differs in the shape of the payload. Doormile keys on bookingid and
sends pickuplatitude; the provider flow keys on deliveryid and sends
pickuplat. Rather than making Doormile translate itself into jupiter's
vocabulary on the way in and back out, it gets an endpoint in its own
terms. The routing is not reimplemented: this maps onto the internal
shape, calls the same optimize_provider_payload, and maps back.
start_coords is passed through, so a run starts from the kitchen instead
of being inferred from whichever stop happens to be first.
/optimization/createdeliveries is deliberately untouched -- jupiter is
live on it and tightening its body would break real deliveries. But that
endpoint takes list[dict], so a payload with the wrong field names
returns HTTP 200 "Success" with every coordinate defaulted to 0.0, no
reordering and all distances zero. Nothing depends on the new endpoint
yet, so it validates strictly and rejects that outright. It also rejects
0,0 coordinates: inside the valid range, but a point in the Atlantic
that drags an entire route toward it.
Single stop short-circuits to step 1 rather than spending an OR-Tools
solve. Duplicate bookingids are refused, since results are keyed back by
bookingid and a duplicate makes the caller's mapping ambiguous. Steps for
bookings the caller never sent are dropped -- callers write these onto
their own rows.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
