N NoBullshit.wiki 中文

Butcher shop purchasing - have a coding agent build a hog-order sizing tool: back into the head count from the tightest cut's gap, not from gut feel

Works with:Claude / GPT-4 classCategories:Butcher ShopLevel:Intermediate Updated

Build me a single-file HTML hog-order sizing tool, used by a butcher shop
buyer on a phone. The scenario first: buying whole hogs is indivisible
purchasing - when ribs run short you cannot order half a hog's worth of
ribs - so gut-feel ordering oscillates forever between "hot cuts sold
out" and "slow cuts filling the cooler." This tool's job is to make
"how many for tomorrow" a computed number, with the mismatch laid out in
the open.

Core algorithm (this is the thesis - do not simplify it away):
1. Demand per cut = trailing N-day average sales x tomorrow's factor
   (weekday, holiday, weather - factors adjusted by hand; the tool
   remembers per-weekday defaults)
2. Gap per cut = demand - current cooler stock (floored at zero)
3. Head count = using the cut-out table, find the binding-constraint cut -
   whichever cut, divided by its yield per hog, requires the most hogs;
   that cut decides the order
4. At that head count, list how many pounds of every OTHER cut will be
  surplus - this surplus table is the other half of the decision

The cut-out table (the heart of the tool; rules locked):
- Pounds yielded per hog per cut. Ships completely empty
- First row carries this prompt: "Fill from your own recent breakdown
  records; update with every hog you break down - the table gets sharper
  with use"
- No prefilled yield numbers, ever - industry averages have nothing to do
  with my cutter or my supplier, and a prefilled "default" gets used as
  a default forever
- Rolling update: when a new hog's numbers are entered, show deviation
  from the running average and prompt me to adjust

Output page (readable in one glance after close, before placing the
order):
- One big line: order N hogs tomorrow (or N half-carcasses)
- Which cut is the binding constraint - the one that alone pushed the
  count to N
- Surplus table: at N hogs, how many pounds each cut overproduces;
  highlight anything past a threshold in yellow - that is tomorrow's
  markdown plan input, not tonight's problem
- Boxed-cut option: for shops that can buy individual cuts, show the
  combo "drop to N-1 hogs + add X lb of spare ribs" - shrinking gap and
  surplus at once
- One sensitivity line: one hog more, one hog less - how the surplus and
  gap tables each change

Data entry (lightness is life or death):
- One screen per day: pounds sold per cut, copied off the day-end sheet,
  under a minute
- Cooler stock auto-decrements (add on delivery, subtract on sale); true
  it up against a physical count at opening each day - log the variance
  but never block usage on it

Hard requirements:
- Single file, no build step, no CDN of any kind; works offline after
  close; data lives only in localStorage
- Cut-out table and surplus table exportable as plain text (I send them
  to the supplier and the manager)
- No accounts, no cloud sync; large type and large buttons - usable with
  tired eyes after closing

Why it is written this way

The thesis is the structural mismatch of whole-hog buying: cut demand and carcass output never line up, so "how many hogs" was never an averages question - it is a binding-constraint question. Ribs run tight, ribs push the head count up, and the surplus knuckles and bones are the inevitable byproduct of that decision, not a mistake. Showing "which cut is binding" lets the buyer understand why the number is what it is; showing the surplus table beside the order count admits the mismatch and reserves its place in tomorrow's markdown plan - surplus is not tonight's bad news, it is tomorrow's markdown input.

The cut-out table ships empty and prefills are banned - the single most important rule in the tool. Industry-average yields mean nothing here: fat cover, skin-on or skin-off, and how clean the cutter bones out a leg can swing one cut's yield by tens of percent. Prefill one plausible-looking number and it gets used as a default forever, and every order after that runs on somebody else's hogs. An empty table plus "update with every hog" turns the tool into something that learns this shop - which is the only thing that makes it worth more than a laminated conversion chart.

One screen of entry per day is the survival line. The ordering decision happens after close, at the most exhausted moment of the day, and any entry routine over a minute gets skipped - skip it three days and the tool is dead. Hence one screen copied off the day-end sheet, auto-decrementing stock, one physical true-up at opening that logs variance but never blocks the tool: better to run with drift than to halt waiting for perfect data.

The "whole hog + boxed cuts" combo is the exit reality needs: most shops can buy spare ribs and belly as boxed cuts. A tool that only counts whole hogs pushes the shop into "order one extra hog to cover ribs," while the combo (one fewer hog plus a boxed-cut top-up) often saves both ends - arithmetic no gut-feel shop has ever run.

Variables

Variable Notes
Cut-out table Fill from this shop's own breakdowns; enter the first hogs as recorded, average after ten; recheck whenever supplier or cutter changes
Tomorrow's factor Per weekday, holidays, weather; run two weeks at 1.0, then adjust from measured weekday-versus-weekend gaps
Boxed-cut channel Which cuts, minimums, from whom - no channel, no combo button; never ship a button the shop cannot press

order sizingcut-out tablecut gaps