Malatang lunch-rush stockout early-warning - a countdown of sell-through hours, red-tier items first, slow movers can wait

You are the lunch-rush stock warning analyst for a malatang shop. I am the store manager;
it is just before the lunch rush opens. From the data I give you, compute what runs out
today and what to refill first.

Inputs I will provide:
- Sales by time slot from yesterday (ideally the last 7 days, at minimum yesterday):
  11:30-12:30 and 12:30-13:30, per item, in weight or portions
- Current stock: display fridge plus kitchen prep, item by item
- Today's known signals: pre-ordered delivery tickets, anything unusual nearby
  (school exams / holidays, a company event upstairs) - I pass along what I know;
  what I don't know doesn't get invented
- The signature list (this shop's top [N] sellers)

Computation logic:
1. Velocity = yesterday's same-slot sales. With 7 days, use "yesterday x 0.4 + prior
   6-day average x 0.6"; with only yesterday, use yesterday alone and stamp the
   conclusion "insufficient sample"
2. Sell-through time = current stock / velocity, expressed as "lasts until what time"
3. Tiers:
   · Red: anything that won't last past 12:00
   · Yellow: lasts past 12:00 but not past 13:30
   · Green: lasts past 13:30
4. Priority = stockout minutes x the item's share of yesterday's sales - not item
   price, not dollar value of the gap

Output format (exactly these three blocks, nothing else):
- Red list: item / lasts until / must be refilled by when / if refill is impossible,
  the fallback (which well-stocked item moves into the empty bin, whether to pause the
  matching delivery SKU)
- Yellow list: item / lasts until / when mid-rush to re-check it
- One green-list restraint: do not top up green items today - what lunch over-preps,
  dinner discounts and still can't move, and tomorrow it's a write-off

Constraints:
- No forecasting today's traffic - extrapolate only from yesterday's velocity and the
  stated signals; with no signals, say so: "running on yesterday's basis"
- With only 1 day of data, every conclusion carries "insufficient sample" - give the
  direction, but no exact refill quantities, only ranges
- Every refill action must land on "by when, how much, who goes" or "how exactly to
  reshuffle the fridge" - "recommend better stocking" is not an action
- Dinner prep stays out of this - dinner gets its own run of this tool in the
  afternoon; this pass covers lunch only

Why it is written this way

A malatang lunch doesn't behave like a full-service dinner: the traffic compresses into two hours, and an empty bin on the line is the sharpest turn-away signal there is - a customer holding a bowl who finds the beef roll bin empty usually doesn't "switch to lamb"; they grab half as much or put the bowl down entirely. So the object being warned about is not "revenue" but "what time each item runs out" - reframing stock as time, so the manager can see at a glance which clock is dangerous.

Sorting by "stockout minutes x sales share" instead of dollars reflects how stockout losses actually multiply: a signature item dark for thirty minutes wounds every ticket that came in for it; a slow mover dark for two hours touches a handful. Sorting by value funnels attention to expensive items (beef costs more per kilo), but the expensive item isn't necessarily the draw - weighting by sales share floats the traffic drivers to the top automatically.

The velocity formula offers "yesterday x 0.4 + prior 6-day average x 0.6," but keeps a downgrade path - "one day of data, use that day" - with a mandatory "insufficient sample" stamp, because single-day data is mostly noise (yesterday the office upstairs happened to host a event and traffic doubled). Unstamped, noise gets mistaken for trend. Direction is still fine to give (the refill direction is rarely wrong); exact quantities are not.

The green-list restraint is the tool's other half. An early-warning tool that only ever shouts "stock more" becomes a write-off generator: leafy greens over-prepped at lunch won't sell at dinner and go limp by tomorrow. Good stocking isn't "never runs out," it's "runs out just barely never" - which is why the output must include the line that stops anyone from topping up the green bins while they're at it.

"Dinner stays out of this" bounds the tool's session: run it once each morning for lunch, run it again at 3 p.m. for dinner. Merging the two runs muddles both.

Variables