Vegetable stall checkout - have a coding agent build the customer tab-keeping tool: regulars take now and pay later, nothing slips, and you dare to bring it up when it ages

Build me a single-file HTML tab-keeping tool for the person running a vegetable stall's
checkout, used on a phone. The scene first: tabs happen daily - a regular with a dead
phone battery says "tomorrow, all together", the neighbouring stallholder walks off with
a bunch of scallions, the small restaurant down the lane settles monthly. Tabs kept in
the head get lost; a lost tab is a day's vegetables given away. The tool must make
"writing one down" fast enough that checkout never stops, and keep "who owes what, for
how long" visible at any moment.

Writing one down (the core flow, five seconds):
- Pick the person: a row of avatars for regulars (create once - name + one identifying
  note like "stall 3, northeast corner"), one tap thereafter
- Amount: big numeric keypad; one-tap quick labels for the goods ("napa cabbage" /
  "potatoes" / "scallions" / "mixed basket") fill the memo - or skip it
- Save. Done. No required field ever blocks the path

Ledger rules (fixed in code - this is what prevents a rotten book):
- Each tab records date, amount and the phrase; after saving, the amount is immutable -
  corrections happen by reversing the entry and writing a new one. Editable books rot
- Repayment supports full settlement and part payment: part payment posts a "payment"
  line, the balance recomputes, and the original tab's date never moves (tab age counts
  from the first entry - a part payment doesn't reset the clock)
- Per-person receivable = sum of open balances; the stall's total receivable sits alone
  at the top of the home screen

Collection help (the last block, and the hardest):
- One row per person: name / balance / days open; past the threshold in my settings,
  the whole row turns red
- Tapping a red row offers "copy payment nudge": a no-hard-feelings text message built
  as "greeting + what was taken (each entry's original phrase listed) + amount + one
  face-saving closer (default: 'whenever it's convenient, no rush')". The closer is
  editable in settings - the default suits regulars
- Monthly account customers (restaurants) get a "monthly" tag: excluded from red-row
  ageing, but the whole row changes colour on the last day of the month as a
  reconciliation reminder

Hard requirements:
- Single file, no build step, no CDN of any kind; works with the market's dead zones -
  data lives only in localStorage
- No accounts, no cloud sync - tab data leaving this phone becomes someone else's
  privacy problem
- The home screen IS the app: total receivable + red rows + regular avatars; anything
  needing more than two screens has failed
- Every destructive action asks twice (one misdeleted entry is one lost debt)

Why it is written this way

The entire design leans on one fact: the person entering the tab is mid-checkout. The customer is holding vegetables, someone is queuing behind them, and any extra step in the flow gets skipped - skip it three times and the tool is dead. "Five seconds, zero required fields" is not a UX nicety, it's the survival line; the quick-goods labels (one tap writes "scallions") exist purely to save five seconds of typing.

"Amounts immutable after save; corrections by reversal" is the anti-rot clause. If a ledger can be edited, it will be edited casually - a reduction becomes a "repayment", an increase becomes a quarrel - and within a month nobody trusts the book, including its owner. The reversal mechanism keeps every entry traceable, and a book's credibility is worth more than its convenience. "Part payment doesn't reset the clock" follows the same logic: a regular who repaid half still owes the other half, and the age of a debt counts from the day it was born - that's the only fair clock.

The nudge text is built as "structure + editable closer" rather than generated personality because the tone of a payment reminder depends entirely on the relationship - the words for a twenty-year regular and for the bistro are different animals, and a tool cannot know them. It arranges the facts (which entries, how much, how old) and leaves the soft landing to the stallholder. That is also the tool's boundary: the bookkeeping goes all the way down, but the asking is always a human's job.

Variables