Coffee shop corporate order feasibility tool - whether to take the 30-cup meeting order, when to start pulling shots, and your price floor, on one page

Please build me a single-file HTML corporate-order feasibility
tool for a coffee shop. It opens straight in the browser, no
network, no dependencies, data stored locally only.

Put this background in the tool's intro: office coffee for
meetings and afternoon tea is a common incremental order for
coffee shops, but two accounts must be settled before you
reply "yes, we can" - the capacity account (how long a few
dozen cups occupy the espresso machine, and whether that
collides with the store's rush) and the pricing account
(beyond ingredients there is delivery, packaging wear, and
the opportunity cost of peak capacity given up). The tool
puts both accounts on the table before the planner commits.

Data it takes in:
1. The order: per drink - name, cup count, minutes per cup,
   category (espresso / pour-over / pre-batched cold brew;
   pre-batched cold brew occupies no machine time)
2. Capacity: cups the espresso machine can pull in parallel,
   baristas on shift, packing time per order
3. The store's rush table: per time slot (e.g. 8:00-9:30)
   tagged "rush / off-peak", editable
4. Timing: requested delivery time, delivery mode (own
   courier / third-party runner), one-way delivery minutes
5. Cost bases (all the shop's own numbers, no defaults
   built in): ingredient cost per cup per drink, cost per
   delivery run, per-order amortized wear for insulated
   bags and carriers, and a peak-occupation rate (what one
   minute of rush capacity is worth; leave blank and the
   tool counts it as 0 and says so explicitly)

Core behavior:
- Shot timeline: total production time from "parallel cups x
  baristas on shift"; pre-batched cold brew listed separately
  outside machine time; each timeline segment that falls
  inside a rush slot is marked red
- Must-start time = delivery time - packing - transit -
  production - a [15]-minute buffer; if the start time lands
  inside a rush, or the timeline overlaps rush by more than
  [30] minutes, flag a capacity conflict
- Under conflict, offer alternatives instead of deciding:
  nearest off-peak delivery windows (found automatically) or
  a reduced cup count the capacity can absorb - the user
  chooses, the tool does not
- Price floor = ingredients + delivery + packaging wear +
  peak-occupation cost; also show a suggested quote range at
  the user's markup of [ ]% - floor and range side by side,
  markup editable
- One-page decision card: a verdict of take / adjust / do
  not take, the timeline, must-start time, floor price and
  range, and a risk list (e.g. "transit estimated on normal
  traffic - rain not included")

Constraints (for the coding agent):
- Per-cup costs, rush windows, and markup come only from
  input - no industry default values anywhere in the tool
- Single file, English UI, localStorage persistence,
  print-friendly; no accounts, no login, no cloud sync

Why it is written this way

The trap in corporate orders is not "can we make it" but the moment you say yes: the client wants delivery at 10:00, the planner says sure, and only later does the math show 30 lattes monopolizing the machine for 40 minutes right on top of the worst of the morning rush - the shop queues, the order runs late, both ends burn. So the core of this tool is the timeline, not the quote - production time and the store's rush go on one axis and the conflict becomes visible; pricing is downstream. The must-start back-calculation (delivery - transit - packing - production - buffer) gives "can we" a mechanical answer instead of on-the-spot gut feel.

Peak-occupation cost is an optional toggle rather than a fixed line because the same rush hour stolen means completely different things to a two-group flagship and a single-group hole-in-the-wall; bake it in and the small shop reads "every such order loses money," leave it out and the big shop gives capacity away for free. The rate is user-entered, or zero-but-stated - consistent with this site's standing rule of no built-in industry defaults. Any cost number pre-filled on the user's behalf becomes a wrong decision basis for some class of shop.

"Do not take, here are alternative windows" is allowed as an output verdict, and that is the verdict tier most tools are missing. Most calculators grind away at the numbers and can never say no; whereas the real discipline of order-taking is that some orders are worth less than declining them - surfacing the nearest off-peak windows and letting the user choose beats squeezing out a barely-feasible plan every time.

Variables