Malatang delivery combo-design tool - compress the pick-and-weigh fridge into three combo cards, with meat/veg gram weights, prices, and margin guardrails computed in one pass

You are a senior front-end engineer. Build me (the delivery
operations lead of a malatang shop) a single-file HTML
combo-design tool: no external dependencies, no build step,
save as .html and open by double-click, works in mobile
browsers, all computation local.

Tool name: Delivery Combo Card Designer

1. Base data entry (persisted in localStorage; everything
recalculates on edit)
- Dine-in meat/veg weights: median meat grams, median veggie
  grams (estimated from dine-in weighing records or receipt
  sampling - flagged as sampled values)
- Dine-in median ticket (last 30 days)
- Costs: meat per 100g (weighted by this shop's meat mix of
  beef rolls / meatballs / sliced lamb) and veggie per 100g
  (weighted the same way)
- Tier count: 2-4, default 3
- Two guardrails: food-cost share-of-price ceiling (default
  40%) and minimum margin per combo (I fill in)

2. Combo generation (button)
- Gram weights per tier, anchored on the dine-in medians:
  veggie tier = veggie median x 1.1 (a veggie tier's
  experience is carried by volume), standard tier = 90% of
  both medians, deluxe = meat median x 130% + veggie median;
  other tier counts interpolate proportionally. Every number
  is manually adjustable, with margins recalculating live
- Price per tier: dine-in median ticket x tier coefficient
  (0.8 / 1.0 / 1.3), rounded to whole yuan minus one
  (19 / 25 / 31 style price points)
- Margin per tier: price − (meat grams ÷ 100 x meat cost +
  veggie grams ÷ 100 x veggie cost) − per-order packaging
  cost (entered separately; the default stays empty and the
  tool refuses to run without it)
- Two checks: food-cost share over the ceiling → row turns
  red with "adjust weight or price"; margin below the
  minimum → yellow warning
- Each tier displays a "dine-in benchmark" line: this tier's
  combined weight equals what share of a typical dine-in
  bowl - keeping customer expectations aligned with the
  price

3. Combo card export
- One plain-text block per tier: editable combo name
  (placeholder names I can rename), contents (meat Xg +
  veggie Xg, plus an editable fixed-items line like "beef
  rolls, fish balls, wide noodles, greens"), price
- One-click copy, paste straight into the platform's item
  description

4. Acceptance tests (self-test all four before delivering)
1. Enter meat median 200g, veggie median 250g, meat cost
   4 yuan/100g, veggie cost 0.8 yuan/100g, median ticket
   25 yuan - the standard tier should generate roughly
   "180g meat + 225g veggie at 25 yuan" showing margin and
   cost share
2. Change veggie cost to 3 yuan/100g - the veggie tier
   immediately turns red (cost share over the line) while
   the deluxe tier stays clear
3. Set the minimum margin to 8 yuan - any tier under 8 yuan
   turns yellow
4. Clear localStorage and reload - an empty-state prompt
   appears, not an error

Interface: single screen, inputs above results; wide number
fields and big buttons - data entry happens in the shop with
paper in hand.

Constraints:
- No CDNs, fonts, or icon libraries - fully offline
- No accounts, no cloud sync - localStorage only
- No pre-filled "industry gram weights" or "industry
  tickets" - every number is mine to enter
- Gram weights are raw-basis only (matching the dine-in
  scale); no cooked-weight option anywhere, so the two bases
  can never fight

Why it is written this way

Combos are the unavoidable crossing for pick-and-weigh malatang entering delivery, but most shops design them by imitation: copy a competitor's tiers and prices without ever checking them against their own two anchors - the dine-in median ticket and their own meat/veg costs. The tool's whole design re-anchors combos to those two numbers: gram weights derive from the dine-in medians (a customer's expectation of "how much malatang is a portion" is that bowl they eat in-store), and prices derive from the dine-in ticket (the number delivery customers benchmark against in memory). Anchor wrong, and however elaborate the tiers, you're pricing on somebody else's cost structure.

The "dine-in benchmark" line is easy to overlook and quietly essential: it converts each tier into "what fraction of a dine-in bowl," because that's where the customer's review expectations form. Sell a standard tier at dine-in price, and it must carry dine-in volume; charge 80% of dine-in and ship 60% of the weight, and the review reading "smaller than in-store" writes itself. Price and weight have to move together - the tool forces both numbers into one row.

The veggie tier gets its own volume bump (veggie median x 1.1) as a rule of thumb: a veggie tier competes on traffic, not profit, so its experience can't feel thin - and veggie cost share runs structurally high (vegetables are cheap but the ticket is small), making it the tier most likely to hit the red line. Acceptance test 2 targets exactly this: raise veggie cost, and the veggie tier must flag instantly. That test isn't hypothetical - it's the most common way veggie combos die.

"Packaging cost empty by default, tool refuses to run" is a deliberate hard stop: packaging is a real cost in delivery margin and the most forgotten one. The tool would rather refuse to generate anything than print a margin table with packaging missing - the same discipline as "no pre-filled industry data": make the user type one more number rather than inventing one for them.

Raw-weight basis, welded shut with no cooked-weight option, exists because the dine-in scale weighs raw product (customers bowl raw items onto it). If the combo card advertises cooked weight, the two bases collide, and every dine-in regular ordering delivery concludes the delivery shrank. One basis, all the way through, is the floor for any conversion tool like this.

Variables