An Operator message carried the uid of the PREVIOUS card tapped - "-" right
after a reboot - because the branch published before last_uid_str was
updated. The server checks that uid against the Card Type List, so the
first operator tap after every power-on came back "Card not found", and the
operator scan log (which the QC pages use as a fallback to turn a card into
an employee) linked each operator to whatever product card went before,
never to their own card. The message now carries the operator card's own
uid, like every other scan.
Consequence to know about: an operator card that was never registered on
the Card Type page used to be accepted by accident (the check looked at the
product card before it) and is now refused with "Card not found" until it
is registered. Every card issued through that page is already in the list.
Second fix, exposed by the first: the box added one to the product count
on ANY accepted reply, an accepted operator tap included. It was half
hidden while the first operator tap always failed. start_ack_wait() now
remembers the type of the scan being answered (pending_scan_type) and only
a Product acknowledgement counts; Operator and Reset replies just release
the wait and show the server's message. A reply arriving after the 10 s
timeout is still applied, as before.
Simulation updated: 67 checks pass, including "accepted operator tap does
not count" and "accepted RESET reply does not count".
version.txt is NOT bumped - nothing reaches a box until it is.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
m.faisal
e98eb11359