Hotpot restaurant head chef - soup-base cost card tool: have a coding agent build a single-file page that works out each base's cost structure and which ingredient moves the margin

You are a coding agent. Build me a single-file HTML soup-base
cost card tool for a hotpot restaurant's head chef. It must
open by double-click in a browser: no network, no installs,
no external resources of any kind (no fonts, no icon packs,
no CSS frameworks).

1. Feature requirements
1. Pot types: add and remove pot types (e.g. full spicy /
   clear / split half-and-half); each type is one cost card
2. Ingredient rows: add and remove rows per card with
   fields - ingredient name, per-pot quantity, quantity
   unit (g / ml / piece), purchase price (entered per
   kg / liter / piece; the tool converts to per-pot
   automatically)
3. Card totals: per-pot ingredient cost (row sum), the
   base's selling price (user-entered), margin dollars,
   margin percent
4. Cost structure: each card lists every ingredient's
   share of cost; any row over [X]% of cost is highlighted
   as a "cost driver"
5. Cross-card comparison: one table comparing cost / price /
   margin percent across all pot types
6. Price-shock sandbox: change any ingredient's unit price
   and every card recalculates live - this is the tool's
   core scenario: an ingredient jumps in price, and you
   immediately see what it did to the base cost and the
   margin that's left

2. Data requirements
- All data in localStorage; closing the tab loses nothing
- One-click CSV export (pot type x ingredient x cost
  structure) and one-click wipe (with a confirm dialog)
- The tool ships with zero sample prices, default recipes,
  or industry averages - the empty state says "create your
  first pot type" and nothing else; every number comes from
  user entry

3. Defensive requirements
- Unit-conversion edges: grams with kilograms, milliliters
  with liters - results must be correct when mixed; if a
  row's quantity unit and price unit can't reconcile,
  flag it inline instead of computing garbage
- Deleting a pot type deletes its rows with it
- Any invalid input (non-numeric, negative) is excluded
  from totals and marked red
- Double-sided pots like half-and-half: a row may be
  flagged "one portion each side", and the cost counts
  the portion twice

4. Interface requirements
- Single-column layout usable at phone width (head chefs
  mostly check on a phone)
- Numbers right-aligned; percentages to one decimal
- No login, no multi-user, no cloud sync

Deliverable: one complete HTML file with all CSS and JS
inlined, working on double-click. Append usage notes of
two hundred words or fewer, in English only.

Why it is written this way

Soup-base costing is hard not because the math is hard but because the data is scattered: a dozen-plus ingredients across different vendors and different unit conventions (tallow by the kilo, chilies by the jin, stock by the vat). Doing it by hand costs an afternoon, so in practice everyone falls back to the coarse "bucket purchase price" number, and the true per-pot cost stays murky forever. The tool crushes the cost of "running the numbers" to seconds - and the price-shock sandbox is the real usage scenario: the day an ingredient jumps, it answers "is the base margin still holding?" instead of waiting for month-end inventory to reveal it backwards.

"No sample prices, no default recipes" is the single most important discipline for a tool like this: coding agents have a stubborn habit of pre-filling plausible-looking demo data so the empty screen demos well. But in a costing tool, any pre-filled number gets quoted as an industry average - a fabricated tallow price is more harmful than no tool at all. The empty state forces users to enter their own figures; the tool's only jobs are speed and arithmetic correctness.

Unit conversion and "one portion each side" are hotpot-specific traps: purchasing by the kilo while recipes dose by the gram is the norm; a half-and-half pot doses both sides, and missing that layer halves the computed cost. These are spelled out as defensive requirements because a coding agent will not think of them on its own - it has never stood a shift at the pot station.

Variables