An item can spoil simply because it is not consumed quickly enough, separate from chains that spoil a product on purpose (#19). Actual dwell time depends on the physical layout and cannot be computed exactly, but the risk can be flagged and optionally budgeted for.
First pass, no input required: wherever a block uses or produces an item with a finite spoilTicks, show a small "spoils in ~Xs" marker, both in the coherence audit (#11) and inline on the block row. Items the block runs at a surplus are the most likely to sit long enough to rot, so call those out specifically.
Second pass, opt-in: let the user set an expected spoil rate on an item (for example, 20 flora per minute lost) and feed it to the solver as extra demand, so production is sized to cover the loss and the buffer is sized accordingly.
Both build on the spoilage data already in the schema (spoilTicks, spoilResult).
Related: #11, #19.
An item can spoil simply because it is not consumed quickly enough, separate from chains that spoil a product on purpose (#19). Actual dwell time depends on the physical layout and cannot be computed exactly, but the risk can be flagged and optionally budgeted for.
First pass, no input required: wherever a block uses or produces an item with a finite
spoilTicks, show a small "spoils in ~Xs" marker, both in the coherence audit (#11) and inline on the block row. Items the block runs at a surplus are the most likely to sit long enough to rot, so call those out specifically.Second pass, opt-in: let the user set an expected spoil rate on an item (for example, 20 flora per minute lost) and feed it to the solver as extra demand, so production is sized to cover the loss and the buffer is sized accordingly.
Both build on the spoilage data already in the schema (
spoilTicks,spoilResult).Related: #11, #19.