pos() was eval'ing over the script's positional parameters from inside a
function, where $1 is the function's own argument. So `pos 3` printed "3" and
`pos 10` printed "100": every run this script has ever driven printed sample
numbers where positions should have been.
That rewrites an earlier conclusion rather than just fixing a bug. No enrolment
on this device had ever been guided, including the one that produced the best
template measured so far -- its spread came entirely from the config's overlap
band refusing near-duplicates, not from anything this script said. The
paired-test attribution drops a contributor, and the 30-sample run becomes
directly comparable to it because both were equally unguided.
Prompts are therefore opt-in now, behind FPENROL_GUIDE=1. The first run where
they actually fired steered the finger to edges, tips and hard rolls, needed 74
presses for 30 accepts, and produced a template that matched 0 of 10 taps.
Prompting a user toward positions they never use in a real tap builds a template
of positions they never use in a real tap. The default is the instruction that
worked: press as you would to unlock, and let the refusals move you.
The stage count comes from the daemon's num-enroll-stages property rather than a
second hardcoded 20.