Hotpot restaurant purchasing - next-day order sheet tool: have a coding agent build a single-file page that computes order quantities on four replenishment rhythms, not one

You are a coding agent. Build me a single-file HTML next-day
order sheet generator for a hotpot restaurant buyer. It must
open by double-click in a browser: no network, no installs,
no external resources of any kind.

1. Base data
1. Item library: add and remove items, each with - name,
   replenishment rhythm (choose one: same-day fresh /
   frozen turnover / next-day produce / shelf-stable
   dry), unit, safety-stock days (defaults by category:
   same-day fresh 0.5, frozen 3, next-day produce 1,
   dry goods 7 - all editable)
2. Daily entry: item, today's sales, today's waste,
   current on-hand, in-transit quantity

2. Core math (routed by replenishment rhythm; formulas
   fixed and displayed next to results so a human can
   see them)
- Same-day fresh: order = tomorrow's projected usage -
  on-hand - in-transit (zero safety stock; same-day
  goods never carry overnight)
- Frozen turnover: order = tomorrow's projected usage x
  (1 + safety days) - on-hand - in-transit
- Next-day produce: same as frozen, with this
  category's own safety figure
- Shelf-stable dry: only flag a reorder when "on-hand +
  in-transit - tomorrow's projected usage" falls below
  the safety line, showing the top-up amount; on normal
  days these items never appear on the order sheet
- Tomorrow's projected usage = today's sales x tomorrow's
  factor (the factor is entered by a person - see below)
- Any item computing negative clamps to 0 with a "no
  shortage" tag

3. The tomorrow factor (the soul of this tool; it must be
   human judgment)
- A factor panel: base 1.0, adjustable globally, with
  per-item overrides; the panel lists common adjustment
  reasons (holiday, weather swing, in-store event,
  nearby construction) as checkbox reminders - reminders
  only, never auto-editing; after checking a reason,
  the number is still typed by a person
- The tool must contain zero "holiday auto-scaling"
  rules

4. Output
1. Category order-sheet view: four sub-sheets by
   replenishment rhythm, each copyable as plain text to
   a supplier (item, quantity, unit, notes field)
2. Urgency rows: lines with order > 0 get an urgent tag;
   frozen lines below the supplier's minimum order show
   a "top-up reminder" (minimums registered per item
   in the library)
3. Data in localStorage; one-click CSV export including
   daily entries and factors, so month-end reviews can
   find which day's factor was wrong

5. Defensive requirements
- Unit-mismatch guard: item unit inconsistent with entry
  unit -> flag red, refuse to compute
- Factor untouched -> compute at 1.0 with a prominent
  "no adjustment made this run" banner
- All formulas visible: every result row shows its
  arithmetic (today's sales x factor - on-hand -
  in-transit); a black-box number is not acceptable

Deliverable: one complete HTML file with all CSS and JS
inlined. Append usage notes in English, two hundred words
or fewer.

Why it is written this way

Most ordering tools fail on conventions, not arithmetic: one sheet carrying goods whose shelf lives run from one day to one year, all run through one formula - so fresh goods inherit the frozen category's three-day safety stock (and rot on day one) while dry goods appear on the sheet daily (ordered in crumbs forever). The core design here is routing: four categories, four formulas, each dictated by the physics of the goods - same-day fresh carries nothing overnight so its safety stock is zero, and shelf-stable goods shouldn't appear on an order sheet at all on normal days. Formulas stay fixed and print next to the results, so the buyer can see where any number came from and knows which input to fix when it's wrong.

"The tomorrow factor must be human judgment" is the tool's most important boundary. The seductive direction for ordering tools is automated demand prediction, but single-store data is thin, hotpot traffic swings hard on weather and holidays, and any built-in model fails silently on the first downpour - the numbers still look plausible. This tool declines instead: it externalizes "tomorrow differs from today" into an explicit factor panel, lists common adjustment reasons as checkbox nudges, and keeps the hand on the number human. That turns the question from "do you trust the system" into "did you remember to set the factor" - and errors become auditable, since the exported CSV keeps every day's factor for a month-end look at which day's guess was off.

The top-up reminder and the negative-clamp are the grinding details of real ordering: frozen suppliers have minimums, a suggested 3 kg against a 10 kg minimum means the buyer has to remember to pad the order themselves, and a negative quantity pasted straight to a supplier is an incident. Leave these out of the requirements and the coding agent ships a textbook formula wrapped in an unusable workflow.

Variables