Community supermarket backroom manager - pre-holiday storage capacity calculator; order volume times carton volume against available backroom space, a three-light utilization gauge, and when it won't fit, which category to cut first by storage condition

You are a coding agent. Build a single-file
HTML "pre-holiday storage capacity
calculator" for a community supermarket
backroom manager: before the holiday order
goes out, find out whether the backroom can
hold it. Runs locally, no network, no
external dependencies.

Positioning (design to this; it is not an
inventory system): the backroom manager's
worst day is not slow sales - it is stock
arriving with nowhere to put it. Cartons in
the aisle fail the fire inspection; cartons
at the cold-room door break the temperature.
This tool does volume arithmetic and tiered
lights only: how much space exists, how much
the order consumes, what to cut first when
it does not fit. It deliberately does not
forecast sales - "how much to order" is
buying's job; the tool answers "will it fit
if we do."

Three blocks:

1. Capacity entry
- Room basics: clear interior length x
  width x height of the usable zone
  (excluding aisles; the tool reminds that
  aisles stay reserved per fire code and
  never fold into capacity)
- Racking: per bay width x depth x levels
  and bay count; rack volume computes
  itself
- Cold room: entered separately (one or
  more), computed apart from ambient
- Current utilization: either a hand-
  entered "already-used share" or an
  estimate from existing stock - one of
  the two

2. Order check
- Paste the order list (plain table paste
  supported): item / cartons / per-carton
  LxWxH (or volume) / storage class, one
  of: flat-stackable / rack-only /
  cold-chain
- Items missing volume but having weight
  get a conversion box with common carton
  presets (e.g. 500ml x 24 bottles
  approx 0.03 m3), all presets editable
- Output:
  Total utilization (ambient and cold
  room, one each)
  Three lights: below [green line]% fine;
  between [green line]-[red line]% re-slot
  the racks; above [red line]% cut the
  order
  Utilization by class: how much each
  storage class consumes
  Aisle spill estimate: flat-stacked goods
  beyond rack capacity spill into aisles;
  the tool computes "how much aisle gets
  consumed" separately - that number is
  the direct fire-risk readout

3. Cut suggestions (appears only when it
   does not fit)
- Fixed priority for "cut what first":
  flat-stackable bulk with slow turns
  (case drinks, paper towels) > flat-
  stackable bulk with fast turns >> cold-
  chain items - when the cold room is
  over, chilled goods are the last thing
  to cut; the suggestion flips to "order
  more often, less per time" instead of
  cutting total quantity
- Every suggestion carries a number: cut
  [quantity] cartons of this item and
  utilization drops to X%
- Suggestions stop at category and carton
  count; the tool never edits the order

Hard constraints:
- Every formula displays beside its result
  (utilization = required volume / capacity)
  so the numbers can be checked by hand
- Entries persist in localStorage; export
  and import as JSON for multi-store reuse
- Ships with a sample order preloaded
  (including one "cold room over capacity"
  scenario) so the three lights and cut
  suggestions are visible on first open
- Conversion presets are labeled
  "estimate" and never pretend to be exact

You shall not:
- No network, no inventory or ordering
  system interfaces
- No sales forecasting, no "smart order
  suggestions" - how much to order is
  buying's business; the tool answers fit
- No 3D warehouse modeling or slot maps -
  this is a calculator, not a WMS
- No accounts, no external libraries

Why it is written this way

Backroom capacity before a holiday was never hard to compute - it was simply never computed in time: the order meeting ends, the order goes out, and the first person to learn it won't fit is standing there on delivery day, when the only remaining move is blocking the aisle - and blocking the aisle (fire inspection, goods temperature at the cold-room door) always costs more than trimming a few cartons off the order. So the tool's position is fixed at "before the order goes out": it does not solve how to store, only whether to place the order - converting the capacity question from a receiving-day problem into an ordering-day problem.

Utilization gets three tiers rather than one precise number because usable capacity is inherently fuzzy: whether the space above the top rack level counts, how high flat stacks may go - every store differs. But the two outer lines ("under 70% anything goes, above 90% something breaks") are universal, and the middle tier leaves room to re-slot. The separate aisle-spill figure is the most practical line in the tool: flat-stacked goods beyond rack capacity necessarily spill into aisles, so "how much aisle gets consumed" is the fire-risk readout in one number - put that in front of the backroom manager and the store manager, and the cut-the-order debate ends itself.

The cut-priority embeds one counter-intuitive rule: when the cold room is over, do not cut chilled goods - order more frequently instead. Cutting ambient bulk delays it by two days; cutting chilled goods means empty chillers until the next truck. Small-and-often relieves cold-room pressure immediately. Hard-coding this is freezing an experienced backroom manager's judgment into the default option - the tool suggests, but every suggestion carries its number (cut how many cartons, utilization drops to what), and the decision stays with the human.

This is a sibling of the shelf-capacity quick calculator, answering the opposite question: that one answers "will the shelf sell it," this one answers "will the room hold it" - and only the two answers together bound how much to order for the holiday. Boundaries stay fixed as ever: no forecasting, no system hooks, no slot maps; the tool holds exactly its one square.

Variables