N NoBullshit.wiki 中文

Braised-deli stocktaker - convert in-pot and in-brine product back to raw, single-file calculator

Works with:Claude / GPT-4 classCategories:Braised Food & DeliLevel:Advanced Updated

Build me a single-file HTML conversion calculator for a braised-deli stocktaker
to use at month-end count: convert everything that cannot be counted directly
as raw material back to a raw basis. Double-click to open, works offline.

Three classes of goods to convert:
1. Semi-finished in process (braising, brining, cooling): pick product, pick
   state, enter actual weighed weight; convert back to raw weight using that
   product's conversion factor for that state
2. Finished (cooked, unsold): enter actual weight and the product's standard
   yield; back-calculate raw input. Products weighed with broth need a
   "with broth" option that first subtracts a configurable broth share before
   inverting the yield
3. Thawed raw: enter thawed actual weight; back-calculate frozen weight using
   a thaw-loss factor

Functional requirements:
- Settings area: maintain product names and all factors (in-process conversion,
  standard yield, broth share, thaw loss), with JSON export/import so a new
  computer does not mean re-entry
- Entry area: one row per item, live raw-weight result as you type
- Summary area: per-product totals of "directly countable raw + converted raw",
  one-click copy as plain text with columns matching the count sheet
- Any product whose factors have not been maintained shows red and is excluded
  from totals - missing rather than wrong

Hard requirements:
- Single file, no external dependencies, no network requests of any kind
- No preset factors or "industry reference values" anywhere in the page; every
  factor is maintained by the user
- Every row shows the full arithmetic (actual weight x factor = raw weight) so
  anyone reviewing the count can see where each number came from
- No accounts, no autosave, refresh clears - deliberate, so last period's stale
  rows cannot leak into this period's sheet

Why it is written this way

A deli stocktake carries a layer of trouble generic retail does not: at any count moment there is intermediate goods - braising, brining, cooling - that is neither raw nor finished, while the count sheet speaks only raw. So every stocktaker ends up improvising on a pocket calculator: "30 jin with broth, yield 70 percent... minus how much broth again?" One slip, and this period's variance carries a fake number that can never be traced. Freezing the conversion rules into a tool leaves two on-site actions: pick the state, weigh.

The three classes are separate because they convert in different directions: semi-finished converts forward (it will lose more water), finished converts backward (how much raw went in), thawed converts back (add the thaw loss back). A generic converter that merges them guarantees wrong-field entries on the floor. Separated, each formula stays simple enough to verify by mental math - which is why the full arithmetic must be shown: count data has to survive review, and a black-box number nobody dares to book is worthless.

"No preset industry reference values" is the most important constraint in the prompt. The standard move for a coding agent building this tool is to ship a default yield reference table - helpful-looking, and the start of a disaster: nobody bothers to change defaults, the defaults quietly become "the company standard", and nobody can say where they came from. Forcing manual factor maintenance forces the store to settle what its yields actually are - and that maintenance act is where the real value of this tool lives.

Red-and-excluded beats guessed-and-included. The enemy of count numbers is never the effort; it is the plausible-looking wrong row.

Variables

This prompt has no blanks to fill in; per-product conversion factors are maintained by the user inside the tool's settings area.

stocktake toolconversioninventory