Snack stall inventory count specialist - half-prepped goods back-to-raw-material conversion tool - fold assembled skewers, marinating meat, and mixed sauce back into kilograms, bags, and buckets that match how you buy

Build me a single-file HTML conversion tool for counting half-
prepared goods back into raw materials at a snack stall. It
opens directly in the browser, works offline, installs
nothing, and stores data only in localStorage.

Write this background into the tool's intro: when a stall's
count never matches its books, half the cause isn't shrinkage
- it's units. Purchases arrive as kilograms of meat, bags of
powder, jugs of oil; what sits at the stall is 80 assembled
skewers, a tub of marinating meat, a bucket of mixed sauce.
Until half-preps fold back into raw-material units, the two
totals talk past each other. This tool does exactly one job:
convert half-preps back into raw materials, add them to the
raw stock, and produce a "raw-material-basis total" that can
actually be checked against the purchase records.

Data entry:
1. Conversion table (owner-filled; the tool ships with zero
   preloaded conversions): one row per half-prep - name /
   unit (skewer, tub, bucket) / raw-material equivalent
   [ounces of raw meat, grams of powder, oil - fill per
   this stall's own recipe] / effective date of that
   conversion
2. Tonight's count: raw materials entered directly
   (kilograms, bags, buckets - same units as the purchase
   records); half-preps entered as quantities, each pointing
   at a conversion row
3. Last count's closing balance and interim purchases
   (optional; only with these does the tool show usage for
   the period)

Core features:
- Conversion page: enter half-prep quantities, pick the
  conversion row, see the raw-material equivalent; rows
  carry effective dates, and pre-change rows never apply to
  post-change counts
- Raw-material-basis totals table: direct raw count + all
  half-prep conversions = total per raw material, shown
  alongside interim purchases and last closing balance - one
  glance shows which material reconciles and which doesn't
- Dual-conversion self-check: when the same half-prep exists
  under an old and a new conversion, show both totals and
  their difference, and let me confirm which applies - the
  tool never chooses my recipe for me
- Usage comparison (appears only when purchases were
  entered): usage this period = last balance + purchases -
  this total; any material with an implausibly large usage
  gets a yellow flag reading "check the conversion first,
  suspect the stock second"

Output: a one-page count card - raw-material-basis totals,
conversion detail, dual-conversion check results; print-
friendly, ready to order against tomorrow morning.

Rules (for the coding agent):
- No default conversions of the "one skewer = X grams of
  meat" or "one bucket = Y bags" kind - empty table at
  startup, every row owner-entered
- Conversions carry effective dates; recipe changes add a
  new row and never edit an old one - historical counts must
  not recompute under a new recipe
- Single file, plain English UI, localStorage persistence,
  survives a refresh; no accounts, no cloud sync, no
  features beyond what is specified above

Why it is written this way

When a stall's count never matches its books, the most common culprit isn't lost goods - it's units: purchases in kilograms and bags, holdings in "80 skewers and a tub of marinating meat." Two vocabularies counting one stock never reconcile, orders go out against the wrong number, and loss analysis runs on a broken base. This tool does exactly one thing - fold half-preps back into raw-material units and total. That's the smallest lever available: unify the units and half of all "variances" vanish on their own, leaving only the ones worth investigating.

Conversions start as an empty table, with nothing preloaded, because that's the tool's honesty floor. "How much meat per skewer" varies by a factor of two between stalls: skewer size, ladle depth, marinade thickness are each stall's own recipe. Ship a "generic" conversion and every total the tool prints carries an invisible error - worse than not computing at all. An empty table is uglier, but every number in it comes from the owner's own recipe: the tool computes an account, never an estimate.

Effective dates on conversions, with recipe changes adding rows instead of overwriting, is a design that comes from being burned: shrink the skewers in March, and if the old row were edited in place, January's stored totals would silently recompute under the new ratio - history changes itself, and that month's variances turn to mush. A recipe is a timeline, not a table, and the effective date is the anchor of that timeline.

The dual-conversion self-check never picks a basis for the owner: during a recipe transition, both versions compute, the difference sits in plain view, and a human decides which applies. A tool can align units; it cannot decide "which one is really our skewer" - hold that line, and the count card that comes out of the printer is safe to order tomorrow's stock from.

Variables