test: measure the alphabet engine against real fingerspelling

[Endika]

HandshapeAlphabetClassifier era el único motor que el README anunciaba sin ninguna cifra: «geometric handshape rules, no training data needed», y nada más. LSE-FS-UVigo (CC BY 4.0) trae 456 secuencias de deletreo continuo real con signantes apartados. Aquí está la cifra.

El resultado

0 de 456 palabras deletreadas exactamente. 0,919 operaciones de edición por carácter. El total esconde la forma del fallo:

letras anotadas	4.321
las que escribió	742	17%
de esas, correctas	354	48% de lo escrito
nunca escritas	3.581	83%

No se equivoca tanto como calla. Cuando se moja acierta la mitad, que para una tabla escrita a mano contra ningún dato no está mal. Casi nunca se moja.

Por qué

• El 85,7% de los frames con mano no dan ni un candidato. La mejor plantilla en el frame mediano llega a 0,406 contra un suelo de 0,72; el p90 es 0,758. No es un umbral algo alto: el deletreo fluido es sobre todo transiciones, y el docstring del motor dice «letters are held, not travelled».
• La tabla cubre 14 letras de 27. Solo 24 de las 456 palabras no llevan ninguna letra ausente, así que la exactitud estaba topada al 5,3% antes de leer un frame — la misma aritmética que MIN_SIGN_MS imponía a los signos cortos. Y faltan las frecuentes: R toca el 53% de las palabras, N el 44%, T el 35%.
• k no está en ninguna de las dos listas, ni en LSE_ALPHABET ni en UNSUPPORTED_LETTERS, así que la UI no avisa de ella. No lo toco aquí.

El banco es TypeScript a propósito

Los demás bancos reimplementan la app en Python y luego tienen que demostrar el puerto fiel; esa demostración ha fallado dos veces, una con la lateralidad y otra con los umbrales en frames. Este ejecuta la tabla, la geometría y el estabilizador publicados, sin tocarlos, bajo un vitest.bench.config.ts aparte. npm test no lo recoge: necesita un corpus que no está en el repo.

Antes de creerme el 0% comprobé que la escala de z de LSE-FS es la que asume describeHandShape, que es 3D. Curls medianos en 3D 0.13 0.31 0.34 0.41 0.27, con z=0 0.13 0.34 0.35 0.38 0.22. El 0% es del motor, no del arnés.

Un cambio en el motor

HandshapeAlphabetClassifier gana lastScores, las puntuaciones antes del filtro. Es inerte para la app —RecognizeSignsUseCase solo lo lee de motores window, y este es frame— pero sin ello no hay forma de distinguir «la tabla está mal» de «la tabla es estricta», que es justo lo que decide si toca reentrenar.

Qué dice sobre reentrenar

Los fallos son borrados con puntuación máxima baja, no sustituciones ni umbral mal puesto. Aflojar el suelo compra ruido y editar la tabla no arregla un frame que está entre dos letras: las reglas geométricas no describen estas manos. Un clasificador aprendido está justificado, y tendría que cubrir el alfabeto y decir algo sobre los frames de transición. LSE-FS etiqueta la palabra, no las letras, así que la supervisión sale de alineamiento o CTC — spec aparte, con 2.158 + 430 secuencias intactas esperando.

Lint, typecheck y 179 tests en verde. El corpus no entra en git.