Fruit shop stocktaker - have a coding agent build the freshness-graded inventory valuation tool - stock isn't counted, it's appraised

Build me a single-file HTML inventory valuation tool for a fruit shop
stocktaker, used on a phone after close. The soul of this tool first:
counting fruit stock is impossible - half a box, three melons, a pile of
loose oranges - and even a perfect count answers the wrong question.
The right question is "how much is this stock worth tomorrow?" Valuation
= quantity x cost x freshness factor. This tool makes those three taps
fast.

Daily entry (one row per active item; rough numbers are the point):
- Item name, quantity left (about X lbs / pieces / cases - estimates
  written as estimates)
- Cost (purchase-invoice basis; unknown items marked "to fill" - never
  blocks entry)
- Freshness grade, one tap of three:
  A (firm - sells at full price tomorrow and the day after)
  B (slipping - must move tomorrow morning: markdown or cut-fruit)
  C (critical - unsold tomorrow is a write-off)
- One special flag: unopened case (appraise whole, never open it)

Calculation logic (fixed in code, each line explained on screen in one
plain sentence):
- Grade A value = quantity x cost x 1 (no haircut)
- Grade B = quantity x cost x B factor (settings; calibrate after the
  first week)
- Grade C = quantity x cost x C factor (lower still - clearance basis)
- Total stock value = the three summed; B and C value and share shown
  separately - that share IS tomorrow's action list

Output area (one screen):
- Today's total stock value and the change versus yesterday: rising -
  selling well and buying well; falling - freshness walking downhill;
  three falling days in a row triggers a red flag
- "Must move tomorrow morning" list: B and C items sorted by value
  descending, one suggested destination per row (B markdown / B cut
  fruit / C clearance) - suggestions; the human decides, never the tool
- A "copy today's valuation" button: plain text - total, B/C share,
  must-move list - pastes to the owner or the books

Hard requirements:
- Single file, no build step, no CDN of any kind, opens in a phone
  browser
- Data only in localStorage, never off the device; no accounts, no
  cloud sync
- Entry fits one screen: name + quantity + grade, three taps per item -
  anything over ten seconds per item and this tool gets abandoned;
  cut features before cutting speed
- All factors live in settings; no number hardcoded - shops differ too
  much. The tool supplies the formula; the shop owns the parameters

Why it is written this way

"You can't count it" is the tool's founding argument: conventional inventory apps demand a precise quantity, which fruit can neither supply (half boxes, loose stock, estimated weights) nor use - a precise count priced without a freshness haircut still yields a fiction. Swapping the paradigm to "estimated quantity x graded factor" admits two blurs and returns one usable coarse number: roughly what today's stock is worth. Which is the only number the owner and the accountant actually ask for.

The graded factors' real output isn't the total - it's the B/C share. The total is a finance-side result; the share is an operating signal: a high share means "a batch of stock must move tomorrow before it converts itself into write-offs," and the must-move list hands over the items and suggested destinations - the stocktake turns from bookkeeping into deployment. Three falling days flagged red whispers a colder suspicion: maybe sales aren't the problem - maybe the incoming stock's freshness itself has been sliding, and the buying deserves a look.

Entry speed sits in the hard requirements next to single-file because it is the tool's survival line: 9:30 pm, tired and hungry, and a tool that takes longer than ten seconds an item dies within a week. Every design compromise (three grades not five, destinations as suggestions not workflow, quantities welcome as "about") serves the same end - one minute per night that becomes a habit.

Keeping the factors in settings rather than the code carries a quieter reason: the factors are a shop's own trading history compressed - this shop's slipping bananas still fetch 70%, that shop's only 50%. Defaults for week one, then a calibration against the markdown log - and the longer the tool runs, the more the parameters resemble this shop's personality. That, not decimal precision, is what "accurate valuation" actually means.

Variables