Braised-food marketing planner - the promo break-even calculator, a small tool: spend-and-save, percent-off, and buy-N-get-one side by side, each with the volume it must clear to be worth running

Build a single-file HTML promo break-even calculator for a braised-food
chain's marketing planner - used before a promo design is finalized, to
put spend-and-save, percent-off, and bundle mechanics into one table
and see the volume each must clear to be worth running.

Inputs (typed on the page):
- Category's everyday average ticket and everyday margin rate
- Mechanic parameters: spend X save Y (multiple tiers allowed);
  storewide Z% off; second item half price (or buy N get 1 free)
- Budget cap for the promo (total give-away ceiling)
- Reference: the highest increment this store has ever achieved
  in a promo, in tickets

Computation and output:
- One row per mechanic: average discount per ticket / budget-funded
  volume (= budget cap / per-ticket discount) / margin-covered volume
  (= total give-away / per-ticket margin)
- The comparison table sorts by margin-covered volume, smallest first
- Red line: any mechanic whose margin-covered volume exceeds the
  historical best increment gets the whole row flagged red with the
  line: "this mechanic requires a volume this store has never
  achieved - choose with care"
- One summary line at the top: which of the three mechanics is
  effectively the deepest discount (e.g. second-item-half-price
  converted to an effective rate), the structural difference stated
  in one sentence

Implementation requirements:
- Single file, no external dependencies, no network requests - data
  never leaves the browser
- Parameters persist via localStorage, survive refresh, one-click
  clear
- Print-friendly comparison table, one A4 page
- Thresholds and reference values are editable on the page, never
  hard-coded
- No accounts, no multi-user anything

Notes for the coding agent:
- Compute both budget-funded and margin-covered volumes; they differ:
  budget-funded is what the cap finances, margin-covered is what the
  increment margin must deliver to pay for the give-away - take the
  larger as the "real bar," give it its own bolded column
- The per-ticket margin basis includes sauce and packaging cost; the
  page states this basis so the user can verify it themselves
- Invalid mechanic parameters (e.g. inverted spend-save tiers) get a
  red inline error, never a silent correction

Why it is written this way

Structural differences between mechanics only become visible side by side: 6-off-30 feels mild, yet per-ticket it is not necessarily shallower than 12% off storewide; second-item-half-price is frequently the deepest line on the board and gives away physical product on top. The effective-depth summary line exists for exactly this - meetings compare vibes, the tool converts all three vibes into one unit first. Sorting by margin-covered volume rather than discount size matters because a bigger give-away may buy a bigger increment; the bar, not the price, is the comparable number.

The historical-best-increment red line is the soul of the tool. It doesn't judge whether a design is good; it judges whether the store's own history has ever demonstrated the volume the design requires. The benchmark is internal, not industry - an industry average can't be sourced, and wouldn't transfer to this store anyway. Exceeding the line doesn't forbid the mechanic; it means walking in knowing the plan bets on an outcome that has never happened here, and that warning lands differently from the tool than from the one skeptic in the room.

Computing budget-funded and margin-covered separately, then taking the larger, blocks a common confusion: a spent budget is not a recovered budget. The cap says how long the money lasts; the margin-covered figure says whether the increment pays for the give-away. Two different quantities routinely get used interchangeably in review meetings. And invalid parameters error in red rather than being silently fixed, because a silently corrected input produces a number nobody questions at the meeting - bad input should die at the input step.

Variables