Fast food restaurant head chef - daily prep quantity tool - same-weekday averages with adjustable buffer, items split into "rather under-prep" and "rather over-prep", method shown on the page

You are a coding agent building an internal tool for a
fast food restaurant. Build a single-file HTML tool
(HTML, CSS, JS all inline; no external dependencies,
no network requests; opens by double-click in any
browser) that computes daily prep quantities for the
head chef.

Input area:
- Sales data paste box: the last [4] weeks of daily
  sales by item; accepts direct pastes from
  spreadsheet software (tab-separated)
- Item typing: each item marked "rather under-prep"
  (made to order, a sellout is recoverable) or
  "rather over-prep" (needs prep or thawing, a sellout
  is unrecoverable today); default untyped, and
  untyped items are excluded from suggestions
- Adjustments: today's known reservations and group
  orders (added straight to the matching item); a
  conditions marker with three grades - normal /
  expect higher / expect lower

Computation (must be shown in a "How this is computed"
panel on the page, visible to the user):
- Base = same-weekday average over the N weeks, with
  each day's maximum dropped (removes group-order and
  event-day distortion)
- Rather under-prep: suggested prep = base; plus a
  "restock trigger line" at [70%] of base (ratio
  adjustable) - the day's sales touching the line
  starts an immediate top-up
- Rather over-prep: suggested prep = base × (1 +
  buffer factor), default [10%], user-adjustable
- Every suggested number displays which days' data
  fed it - numbers must trace to their sources

Output area:
- Prep suggestion table: item / base / suggested prep /
  type / trigger line or buffer note
- Missing-data flag: items with fewer than N weeks of
  data marked "insufficient data - using last week's
  same day", highlighted
- Print layout: the table prints on one page at a size
  that works taped up in the kitchen

Hard requirements:
- No external CDNs, fonts, or icons; no network
  requests of any kind; data never leaves the machine
- Handle at least [40] items without lag
- A clear-data button and an undo-last-paste action -
  someone will paste the wrong sheet, and they need
  a way back
- No forecasting charts and no "AI suggestions" - this
  tool does arithmetic only, and method transparency
  is requirement number one

Why it is written this way

The real constraint in prep is not "how much" but "what a sellout costs": an item fried to order can cost a guest ten minutes of waiting; an item marinated overnight, once gone, is gone for the day. Asymmetric costs mean asymmetric optimal strategies - hence the tool's first design decision, the two-way item typing: rather-under-prep items get a restock trigger line (prep lean, refill fast), rather-over-prep items get a buffer (accept closing-time waste). Generic inventory formulas ignore this and compute "correct on average".

The method panel exists because tools like this live or die at the first challenge: the owner asks "where did this number come from", the chef can't answer, and the tool is dead. Formulas, assumptions, and data sources stay visible, and every number names the days that fed it - being able to self-explain under challenge matters more than predictive precision.

Dropping each day's maximum guards against group-order contamination: one 50-piece group order drags the average up and inflates every subsequent day's prep. Same-weekday averaging (Tuesday vs. Tuesday) already absorbs the weekly rhythm; trimming the extremes makes the average safe to lean on.

No network and no external dependencies is the store-environment reality: the kitchen machine may be offline and nobody maintains dependencies, and data staying on the machine is the floor. Equally real is fat-fingering - clear and undo buttons aren't UX polish, they exist because someone will paste the wrong sheet.

Variables