A small entry action can be repeated throughout a production day. Reading the tablet-work code’s keypad and defect reason led me to build an independent example with an explicit target for each entered digit.
The target comes before the digit
Good and defect quantities share numeric keys but have different business meaning. The source screen’s target and reason flow helps that distinction. The independent demo separates target selection from good and defect buffers, showing which buffer changes before converting them on submission.
A buffer remains editable text, allowing empty and completed zero to differ. It is not the same value as the final integer in production state. This is a code-level separation of editing and business meaning, not physical verification of tablet button dimensions.
Clear and backspace have different consequences
Clear empties the selected buffer; backspace removes one digit. A digit after zero removes unnecessary leading zero, and a six-digit bound ignores further digits. That limit belongs to the synthetic screen rather than a universal production maximum.
Clearing input does not reverse previously applied output. Reversing a real log would be a separate business event. The demo’s reset explicitly restarts the synthetic experiment, preventing input deletion from masquerading as operational cancellation.
Ask for the explanation required by a defect
A defect quantity requires reason text in the new apply function, a narrower policy than the source service’s default other value. Quantity and reason are validated together; failure preserves prior stock and totals. A visible field alone cannot establish enforcement during storage.
The demo contains no company defect taxonomy and does not judge the truth of a reason. Another factory needs approved categories, unknown-cause states and required conditions. Wording and calculation must explain the same rule.
Execute the actual event sequence
Stub tests press six for good, switch to defect, press two and apply production. They check inventory six and defects two, deliver one, then attempt excessive delivery and verify unchanged stock after failure. The same sequence runs through the actual bilingual inline scripts.
Core tests cover clear, backspace, leading zero, digit bounds and invalid keys. They do not evaluate gloves, touch error, occlusion or focus movement. Physical integration requires those checks separately; code behavior and field usability are different evidence.
Do not hide meaning behind a simple screen
Large keys and few fields can still confuse users if the active target and failure reason are unclear. The demo shows both buffers and JSON output as an inspectable learning screen, not a finished factory design. A real interface still needs appropriate error wording and recovery paths.
Weight, time and other fractional measurements may require another editor. A six-digit integer keypad cannot solve every unit. Reuse means checking which input contract survives, rather than copying the same screen into every factory.
Connect entry to management review
The manufacturing package passed twenty-five tests and fresh extraction. Output exposes which total and inventory balance each quantity changes. There is no database persistence, concurrent-user protocol or duplicate-request handling, and no actual worker or production record.
Fast employee entry and clear representative review require shared quantity meaning. I describe the keypad as a connection among target, validation and resulting state. Existing workflow storage can be integrated separately, without presenting these memory tests as verification of that real storage.
Make target switching inspectable
Keeping the selected target visible before digit entry helps reconstruct an unexpected result. A real interface still needs a rendered review of selected styling and error feedback; the synthetic buffers make that decision inspectable without claiming that usability review.