BBQ skewer-count to purchase-order converter - from "4,000 skewers on Friday" back into pounds of raw meat, packs of sticks, and bags of charcoal, then a text order ready to paste to the supplier

You are a coding agent. Build a single-file web tool for BBQ restaurant purchasing (HTML, CSS, and JS all inline; no external dependencies, no backend, no network requests), opened by double-click. Purpose: back-compute "what to order" from "how many skewers we expect to sell," and produce an order text ready to send to suppliers.

Three sections:

1. Item library (enter once, reuse forever)
- I enter each skewer item: name, category (meat / vegetable), net grams per skewer, yield (raw-to-skewered ratio), and the supplier's order multiple (by pound, box, or case, with the weight per multiple)
- Order multiples support whatever unit I type - the tool uses my units, not predefined ones

2. Order calculation
- I fill in this cycle's expected skewer counts, item by item
- Auto back-computed: raw requirement = expected count x net grams per skewer / yield; then rounded up to the supplier's order multiple, showing two columns - "required" and "actual order" - so the over-order surplus is visible at a glance
- Meat / vegetable subtotal rows: total weight and total value for this order (unit prices entered alongside)

3. Consumables and the order text
- Sticks: one per skewer x total expected count x [breakage rate, my input] -> rounded up to packs
- Charcoal: from my shop's own "charcoal per night" figure [ ] -> multiplied by the nights this order covers, rounded up to bags
- Order generation: one plain-text block grouped by supplier (who delivers what, how many multiples, unit price, value, total), dated at the end - copy it straight into a chat message to the supplier

Hard requirements:
- Zero numbers preset in the tool - yield, net weight, multiples, breakage rate all left empty for me; no built-in "industry reference values"
- All math live: change one count and the whole sheet refreshes without a button
- Item library in localStorage with JSON export / import
- The order text copies in one click and holds its formatting in a phone chat app
- Deliver a single .html file with three lines of usage notes at the top

You must not:
- Add logins, cloud sync, or external libraries - none of that survives in a single file
- Include sample items - an empty table is the correct state
- Offer "smart suggested quantities" - the tool converts and rounds; it does not decide how much we will sell

Why it is written this way

The heart is one reversed equation: raw requirement = count x net grams / yield. Hotpot and fast-food ordering think forward - sell this much, order this much. BBQ ordering is inherently backward: after deciding on 4,000 skewers, two conversions stand between that number and the purchase order - yield (trim loss leaves ten-plus percent of the weight on the cutting board) and the supplier's order multiples (whole boxes, whole cases) - and this equation runs in a purchaser's head daily. One wrong pass is either leftover marinated meat or an 11 p.m. stockout; weld it into the tool and the human contributes only "expected skewer counts," the single genuine judgment left.

"Required" and "actual order" side by side makes the rounding step visible. The surplus created by order multiples is normally invisible - a little extra on every item sums into that batch of meat in the reach-in nobody remembers ordering. With the surplus exposed, the purchaser can start arbitraging across items (can the over-round on lamb be offset against the over-round on beef?) - an optimization mental arithmetic never performs.

The order output is plain text, grouped by supplier, dated - because of how the order actually travels: small and mid-size suppliers take orders in chat apps, and a stably formatted text block that pastes cleanly beats any exported PDF. The last mile of an ordering tool is not computation; it is turning the computed result into a message someone actually sends.

"No smart suggested quantities" joins the zero-preset-numbers rule at the same root: how many skewers we expect to sell is the one judgment this tool deliberately leaves to the human, and the one it must never absorb - it depends on per-table averages, weather, match nights, regulars, everything living in the owner's head. The tool converts and rounds; the person judges demand. Drawing that division of labor clearly is what makes this a thing opened twice a day rather than another system with an account nobody logs into.

Variables