Convenience store cash office clerk - change fund denomination mix planner: one minute at close logs notes paid out, the exchange list computed as coverage days x daily burn minus on hand prints straight for the bank teller, and a make-change simulation flags the amounts most likely to stall the morning rush

You are a coding agent. Build a single-file HTML
"change fund denomination mix planner" for a
convenience store cash office clerk: make the
coin run deliberate and keep the morning rush
able to make change. Runs locally, no network,
no external dependencies.

Positioning (design to this; do not build cash
forecasting software): a convenience store's two
cash pains meet in one place - the morning rush
takes a hundred and cannot break five or one,
and the coin run to the bank runs on gut feel,
so too much exchanged parks cash dead in small
notes and too little runs dry again by
Wednesday. This tool answers the denomination
mix only: how many of each denomination to hold
so change can be made, and how much to exchange
next trip. It deliberately does not forecast
total cash - totals follow the day's takings,
which belong to the cash-up and deposit SOP.
Let forecasting creep in and the tool becomes
both inaccurate and too trusted to follow.

Three functional blocks:

1. Burn log (one minute at close, daily)
- Enter today's count paid out per
  denomination: 100 / 50 / 20 / 10 / 5 / 1
  notes and coin
- Accumulated automatically: daily average burn
  per denomination, and the day-of-week pattern
  (different weekdays burn differently - Friday
  morning rush and Sunday are not the same
  animal)

2. Exchange list (goes straight to the bank
   teller, printable)
- Coverage days [coverage days] x daily burn -
  on hand = notes / coins to exchange, listed
  denomination by denomination
- Day-of-week correction: when the coverage
  window includes a Friday, compute on the
  Friday pattern, not the average day
- Print version, one A4 sheet, black-and-white
  readable: denomination / to exchange / on
  hand / notes - hand it to the teller as is

3. Make-change simulation (catch the amounts
   that stall, before the rush does)
- Inputs: the store's basket range (default
  8-35) and the notes customers actually pay
  with (default mostly 100s and 50s, editable)
- Simulation: for every amount in the range,
  attempt greedy change against current
  holdings per denomination, detecting which
  amounts cannot be made
- Output: a top list of amounts most likely to
  stall change, plus the corresponding advice
  (which denomination, added in a few notes,
  unlocks most of them)

Hard constraints:
- Denomination set defaults to RMB 100 / 50 /
  20 / 10 / 5 / 1 / 0.5 / 0.1, editable - a
  store that barely takes 1-jiao coins deletes
  them
- The projection method is stated on the
  interface: linear over the recent N days of
  burn, with holidays and campaign periods
  requiring manual uplift - the tool does not
  pretend to forecast
- Data in browser localStorage with JSON
  export / import - survives a machine change
- One week of example data preloaded (with
  day-of-week differences), so all three blocks
  show their output the moment it opens; an
  empty sheet demonstrates nothing

You must not:
- Use the network, or connect to any bank or
  payment interface
- Build a forecasting model - no curve fitting,
  no "smart prediction," linear over history
  only
- Manage total cash, cash-up counts, or deposit
  records - those belong to the deposit SOP;
  the moment this tool touches totals it becomes
  a second ledger
- Add accounts or external libraries

Why it is written this way

"Denomination mix only, never total cash" is the load-bearing boundary of the prompt. Change-fund tools most often die by accreting forecast features: they try to predict tomorrow's cash sales, which follow foot traffic, weather, and whatever happens in the neighborhood - not something a localStorage tool can compute. Follow an inaccurate forecast to the bank and the loss beats gut-feel exchanging by a mile. Pushing totals explicitly out of scope - totals follow the day's takings and belong to the cash-up SOP - confines the tool to the one question it can genuinely answer well: per denomination, from history, how many to hold and exchange. And that answer is verifiable by next Monday at the teller window, which is how the tool earns trust at all.

The burn log is designed as "one minute at close" because entry cost decides data quality. Ask the clerk to fill a dozen fields daily and by day three they are estimating; counting notes paid out per denomination is one number per line, logged on the way past the drawer. The day-of-week pattern is computed separately rather than collapsed into a daily average because convenience-store burn is strongly weekday-shaped: payday Friday evening and Sunday daytime have entirely different cash-sale structures, and an exchange window crossing a Friday computed on the average day will run dry by Wednesday - the tool remembers this so nobody has to.

The make-change simulation is the block that pays for itself fastest, because it turns "couldn't make change" from a morning-rush incident into an advance list. Greedy change attempted amount by amount is not elegant algorithms - but it answers the real question: at current holdings, which amounts cannot be made, and which denomination gap they concentrate on. The top list plus "which denomination, in a few notes, unlocks most of them" translates one simulation directly into the next coin run's actions. Defaults of an 8-35 basket paid mostly in 100s and 50s are the standard convenience-store cash profile, and changing them is two input fields.

Stating the projection method on the interface is the tool's honesty clause. Linear over the recent N days of burn will run low across holidays and campaigns - the week before a major holiday can burn multiples of an ordinary week, which a linear extension cannot catch. Putting "holiday periods need manual uplift" on the face of the tool rather than in a manual means whoever opens it sees where the boundary sits, and actually raises coverage before the holiday; a boundary nobody sees does not exist. The preloaded week of example data follows the same principle: the tool's value shows within ten seconds of opening, and an empty sheet demonstrates nothing.

Variables