After recording six good units and two defects, how much inventory should increase? Reading production logs and inventory movement in the actual service led me to distinguish what the visible totals represent.
Activity and available inventory differ
The source records good and defective output separately, maintains separate cumulative totals and moves good units into inventory. Performing production and obtaining stock available for delivery are different events. That business meaning explains why two input fields matter.
The synthetic state contains target, good, defect, delivered and inventory. Good is cumulative; inventory is remaining good stock. Delivery reduces inventory without reducing historical good output. Reusing a quantity label across screens requires stating whether it is a cumulative event total or a current balance.
Do not turn six plus two into stock eight
With target ten, six good and two defective units produce good six, defect two and inventory six. Delivering three gives delivered three and inventory three. Tests preserve this distinction using synthetic data rather than actual company production or item details.
Quantities are bounded nonnegative integers. Fractions, strings and booleans are not silently coerced. A real process measured by weight or length needs another unit and rounding contract; this integer example should not be adopted merely by renaming the field.
Choose a defect-reason policy explicitly
The source can record a default other reason when none is supplied. The new example instead requires a nonempty reason for defects. This is stated as a deliberate independent difference: filling a default is not evidence that a person selected a cause.
That policy is not universal. Unknown causes may need a pending-investigation state, and another factory may need managed categories. The example only bounds synthetic text; it does not establish cause or complete quality analysis merely by requiring a field.
Preserve the old state after a failed action
Apply copies state before constructing a result. Over-target good output, empty production and delivery beyond stock fail. Tests confirm the caller’s previous state is unchanged, including an invalid delivery through actual inline handlers with DOM stubs.
That is a memory-return boundary, not a database transaction implementation. A real service must coordinate logs, inventory moves, company scope and duplicate requests. An existing atomic-workflow module addresses that separate layer; it is not implied by this small quantity example.
Make excess policy another explicit choice
The independent module rejects good output above target. It does not transfer every rework or excess-production rule from the original workflow. A factory may need approved allowances; the shared experiment uses a narrower target relationship for a clear counterexample.
Its event array is trusted memory, not authenticated change history. No server or account prevents arbitrary state construction. Checking invariants cannot prove that an input represents physical production; reconciling actual work and recorded output needs separate evidence.
Give the representative meaningful totals
The twenty-five package tests include good and defect totals, delivery and stock, preserved failures and the other contracts. Extraction passed, without reading or changing an operational database. The live page changes document memory only and does not restore real business records on reload.
A representative should understand a number’s meaning from its name instead of recalculating it each time. Separating cumulative good, remaining stock, defects and deliveries connects employee entry with management review. Simplicity can mean preventing confusion among different facts, not merely displaying fewer numbers.