Cash office cold-chain freight allocation tool - weight, invoice value, or fixed-plus-variable, one method per route, and the rounding remainder lands on one store so every store can check the math

You are a coding agent. Build a single-file HTML
"cold-chain freight allocation calculator" for a
central kitchen cash office clerk: allocate one
delivery route's monthly freight across the stores
on that route, producing a breakdown ready to send
to stores for confirmation. Runs locally, no
network, no dependencies.

Usage scenario (design to this; do not build a
generic cost splitter):
- One route per calculation: route name, monthly
  freight total, number of stores
- One row per store: name, delivered weight for
  the month (kg), delivered invoice value, number
  of unload stops
- Own fleet: fill the total from monthly cost
  pooling; hired carrier: fill from the freight
  invoices. The tool does not care which source,
  only the total

Three allocation methods (single choice; each
shows one line in the UI on when it fits):
1. By weight: stores on the route receive similar
   product mixes
2. By invoice value: routes dominated by
   high-value cold-chain items
3. Fixed plus variable: every store first takes a
   fixed share ([percentage] of the total split
   evenly across stores), the balance allocated
   by weight - built for routes with a store that
   only receives small, light orders

Calculation rules:
- Each store's allocation rounds to the cent
- Rounding remainder: the gap between the store
  totals and the route total lands entirely on
  the last store, flagged in a "remainder" row -
  no proportional redistribution. After a
  redistribution no store can verify its own
  number with mental arithmetic, and
  reconciliation loses its point
- Fixed-plus-variable: a fixed percentage at or
  below 0 or at/above 100% raises an error
  message; never silently correct it
- A store with zero weight under the by-weight
  method raises an error (division impossible)
  and suggests switching to by-value or
  fixed-plus-variable; never skip the store
  automatically

Output:
- Summary block: route name, total, method,
  store count, which store carries the remainder
  and how much
- Detail table: store / weight / value /
  allocation / share / note (remainder flag) -
  copyable as aligned text with one click, ready
  to paste into the confirmation note to stores
- Per-store lookup: enter a store name, see its
  allocation under all three methods side by
  side - when a store objects, the first question
  is whether a different method is actually
  cheaper for it. That is the start of a
  negotiation

Implementation requirements:
- Single HTML file, inline CSS and JS, opens by
  double-click, no network requests
- Nothing persists; refresh clears. The page
  states: "This page stores nothing - save your
  allocation sheet before closing"
- Preload one sample route (three stores) so the
  three methods' differences are visible the
  moment the page opens

Why it is written this way

Parking the rounding remainder on one store and banning redistribution is the floor of the whole reconciliation logic. The dead knot of freight allocation is that every store will check its own number with a calculator: after a "smooth" proportional redistribution, every store's figure becomes the result of a long division nobody can reproduce, and verification dies - trust collapses into "whatever you say it is." With the remainder named and owned, the whole table becomes checkable by addition; the amount is too small for anyone to fight over, and the checkability is too complete for any store to dispute.

Three methods under a single choice, with no auto-recommendation, because the choice is a management decision, not a mathematical one: changing methods changes every store's money, and a tool that chooses is a tool making an interest distribution. The UI offers one line on when each method fits and leaves the decision with the clerk. On routes nobody is sure about, the per-store three-method comparison doubles as the meeting material with the stores - a basis for discussion, not a decision made in place of the meeting.

Fixed-plus-variable exists for the small-orders store. Under pure weight allocation, a store receiving a few light, high-value cases pays nearly nothing while the store taking the full pallet load carries the whole route's freight - the route's common costs (the run itself, the driver, the reefer running) and the load costs are smeared into one number. The fixed share splits the cost of the run across every stop (a stop is a stop), and the balance follows weight for the load; two accounts kept apart halves the ammunition on both sides of the complaint.

Nothing persisted plus opens-by-double-click is the precondition for the tool being usable in a cash office at all: financial data stays off the web and out of third-party forms, and there is no environment to install or account to register on reconciliation day. The preloaded sample route exists so a first-time user understands the three methods in ten seconds - a well-written manual loses to a finished table on the screen.

Variables