Cookie allowance and enrollment: implementation differs from the presentation

ID 1 = admin, 6 counters, next enrollment uses fingerCount+1
what stops ID 7 indexing past the array? also reboot + weekday reset need checking together

The actual firmware allocates int numOfCookies[6], int numOfTries[6] and int btWaitList[10] (lines 318–322). It uses fingerprint IDs as one-based indices into the six-element counters. ID 1 acts as the administrator: matching it enrolls the next template using fingerCount+1 (lines 254–256); when no templates exist, the main loop enrolls ID 1 (lines 338–342).

The active allowance check is numOfCookies[fingerID-1] < 1 (line 262). Successful dispensing rotates forward by 5.3*stepsPerRevolution, waits 2,000 ms, rotates backward by the same amount and increments the counter (lines 264–268). A later presentation describes a different limit; keep that as a revision difference rather than changing the verified code quote.

Reset logic reads now(), compares weekday(t) to oldDay and zeroes the six counters when the weekday changes (lines 325–337). A daily policy depends on a correct time base; this snippet by itself is not proof of a reliable real-world midnight reset. No persistent counter storage is shown in this firmware snapshot.

Review questions before another hardware run: prevent enrollment beyond the counter-array capacity, reject out-of-range sensor IDs before indexing, define power-loss behavior for the allowance, and document time initialization/synchronization. These are source-review observations, not claims that a fault was demonstrated on the device.

Enrollment, cookie allowance and app control flow.