Asistente de piso

Asistente conversacional de una sola página para el personal de piso de una tienda: responde dudas de montaje y estándar de exhibición desde el celular, parado frente al mueble, sin instalar nada y sin cuenta.

De dónde salió: de un problema muy concreto: nadie abre un manual de 40 páginas frente al mueble, así que las dudas se resuelven preguntando o adivinando. Quise ver si una IA podía contestar con la página exacta del manual, declarar qué tan segura está y decir «no sé» cuando el manual no lo dice. Es un proyecto personal; más sobre mí en mi perfil.

Demo con conocimiento 100 % sintético. El cliente (Mercadep), las marcas (MarcaDemoA–MarcaDemoL, y las cinco de la lámina de logos del manual demo), los mundos, los porcentajes de piso y los números de manual son inventados. Ningún manual, medida ni dato operativo de un cliente real vive en este repositorio.

▶ Abrir el demo · sin API key funciona en modo manual; con tu propia key (Google AI Studio u OpenAI) activa el modo razonado.

Probado con 30 manuales reales

Lo probé con 30 manuales reales de campaña de una tienda departamental, cargados a la vez. Los PDF no están en este repositorio. Todo se midió en modo manual, sin API y sin red, con preguntas sacadas del texto de los propios manuales y la página de cada respuesta verificada a mano:

	Resultado
186 preguntas de piso: la lámina que contesta sale entre las 3 primeras	166/186 (89 %)
… y en primer lugar	137/186 (74 %)
Preguntas que se quedan sin ninguna respuesta	0
Las mismas 186, escritas con faltas de celular («donde ban las sandalas»): sin respuesta	6
118 preguntas hechas en un manual que no las contiene: dice «no está»	117/118
30 preguntas trampa que ningún manual contesta («¿qué hago si se va la luz?»): ninguna sale con tarjeta	30/30
Fragmentos o cifras sacados de otro manual	0

En primer lugar eran 128. Subió a 137 cuando los rótulos sueltos de los dibujos dejaron de ganar por cortos y las palabras que escribió el asesor empezaron a pesar más que sus sinónimos. Los «no está», las trampas y los avisos quedaron igual.

El último renglón es el que más cuido. La misma pregunta tiene cifras distintas según la sección, y un dato de otra sección suena cierto aunque esté mal.

Y el modo razonado, con los mismos manuales

El modo con API key también está medido, con eval/modo-ia.mjs dentro de la app real: 110 preguntas de esos 30 manuales (60 de dato, dos por manual; 20 que su manual no contesta y 30 trampas). A Google solo salen los fragmentos que la búsqueda elige para cada pregunta. Esos números son del motor clásico; el agente lector (abajo) está sin medir.

	Resultado
Trae el dato y cita una página donde está	55/60
Dice «no está» en las que no están y en las trampas	49/50
Respuestas con aviso de «no pude verificar»	3 (las tres, falsas alarmas: «definir», «típicos», «smartwatch»)
Primer texto en pantalla, mediana / 95 %	2.0 s / 19.5 s

Durante toda la prueba Google tuvo gemini-3.5-flash saturado, así que 109 de 110 las contestó el respaldo automático, gemini-3.5-flash-lite. Es lo que habría visto un asesor ese día. La trampa que falló es la de siempre: «¿qué hago si se va la luz?» contestó con la luz como elemento de equilibrio de una exhibición. Con el manual demo (eval/preguntas-demo.json, 36 preguntas) sale 22/24 y 12/12.

También probé quitarle las seis etapas para que la respuesta saliera mientras se escribe. El primer texto bajó a 0.9 s, pero acertó 51/60 en vez de 55: dos veces dijo «no está» cuando sí estaba. La regla era no perder más de un acierto a cambio de velocidad, así que no entró.

Los números de los 30 manuales son de antes de cambiar el orden de las láminas (arriba) y de los dos arreglos de la búsqueda de abajo. Falta volver a medirlos con esos manuales.

El modo con API key, con el corpus público (11-oct)

Los números de arriba son de manuales reales que no están en el repo. Para que cualquiera los pueda repetir, el modo con API también se midió con los 4 manuales ficticios y las 99 preguntas del gate (eval/corpus-publico/):

node eval/modo-ia.mjs --local eval/corpus-publico/manuales.json \
  --preguntas eval/corpus-publico/bateria.json --clave-en-pagina \
  --cdp http://127.0.0.1:9333 --pagina 9611 --motor clasico --etiqueta api-clasico

Con --cdp, la medición pregunta en una pestaña de Chrome ya abierta (con --remote-debugging-port) donde la persona pegó su key en Ajustes. La key se queda en el sessionStorage de esa pestaña: el script no la lee ni la escribe en ningún lado.

3.5 Flash-Lite, razonado	Motor clásico	Agente lector
Trae el dato y cita su página	78/84 (92.9 %)	67/73 (cuota agotada en la 74)
Dice «no está» en las que no están	14/15	sin medir todavía
Con el dato en el contexto, lo dio bien	78/78	—
Primer texto, mediana / 95 %	1.5 s / 1.9 s	0.9 s / 4.1 s

• Las 6 fallas del clásico son de búsqueda: el dato no le llegó al modelo. El techo gratis del corpus, medido sin API (el dato llega al contexto), es 77/84.
• El agente empata con el clásico en las mismas 73 preguntas (67 y 67). Gana dos en las que el clásico no encontró la lámina y pierde dos por citar otra página. Gasta ~2,900 tokens por pregunta. El clásico sigue siendo el de fábrica.

Los básicos, con manuales reales (11-oct, noche)

Lo que más se pregunta en el piso son los básicos: qué marcas van en qué mundo, cómo se clasifica la sección y cuál es la fórmula de exhibición. Probando la app salían dos fallas: el modelo no llegaba a las marcas y, en clasificación, explicaba cómo se clasificaba sin decir cuáles eran las categorías. Se armó una batería de 61 preguntas de básicos, con un manual nuevo de Básicos de Display y los 14 manuales reales. Son 42 de desarrollo y 19 de confirmación, con hash y corridas una sola vez. Todo queda fuera del repo.

3.5 Flash-Lite, razonado	antes (ap-v1.21)	ahora
Desarrollo (42): dato con su página	26/42 (61.9 %)	40/42 (95.2 %)
— «¿en qué mundo va X?»	3/8	8/8
— marcas de un mundo	6/12	11/12
Confirmación (19), una sola corrida	—	17/19 (89.5 %)
Modo manual, desarrollo (sin API)	21/42	35/42

Tres arreglos lo explican:

• Las tablas «MUNDO | Marca» se leen fila por fila (tablasDeRotulos en src/motor/layout.js). Antes el rótulo del mundo le caía a la lista de la fila de abajo, y el contexto ponía en PREMIUM una marca de otro mundo.
• La lámina que es una imagen va como imagen (src/ia/laminas.js). Si en el contexto llega una página con casi todo dibujado, como «Clasificación de Departamentos», el modelo recibe también su imagen. Lo mismo pasa con la lámina de MARCAS en una pregunta de marcas, porque ahí muchas marcas son logos. Es una imagen por pregunta y sube la espera ~0.5 s.
• Listas completas (regla 11 del prompt). Si preguntan cuáles son, se nombran todas, cada una con su mundo y su página. Además, la lámina ya no se esconde por un «no especifica» a media respuesta, y la cabecera de la tarjeta enseña los mundos que la respuesta nombra.

Las tres que fallaban se arreglaron en la lectura y la búsqueda (ap-v1.24), sin tocar el prompt:

• Cada celda va con su encabezado. En una tabla «MUNDO | EXHIBICIÓN | MARCA», la fila sale como «EXHIBICIÓN: Por color» y luego «MARCA: …». Suelto entre las marcas, «Por color» no decía que es como se exhibe el mundo.
• Rejillas en minúsculas (tablaDeCeldas). La clasificación de una sección suele ser una rejilla —«Botones | Material | Tamaño»— sin rótulos en mayúsculas. Se reconoce por la forma: cuatro o más filas de celdas cortas y alineadas, rótulos que no se repiten y valores que sí.
• El nombre de la lámina no se pierde. En una lámina de solo listas (un «Básicos de Vitrina» con dos listas tituladas debajo), el nombre va delante de cada título. Y dentro de un manual, «¿cuáles son los básicos?», en el manual que se llama así, ya no se queda buscando «cuáles» a secas. En un manual de dos familias («Hilos y Botones»), nombrar la segunda sí distingue.

Modo manual: desarrollo 35 → 36/42, confirmación 16 → 17/19; dato en contexto, desarrollo 38 → 39/42. Golden de 667: arregla 1, rompe 0.

Con la API, otra vez, después de esos arreglos (ap-v1.25, 11-oct, noche). Mismos 15 manuales, misma batería de desarrollo, tres corridas:

3.5 Flash-Lite, razonado	ap-v1.25.0	ap-v1.25.2
Dato con su página (40)	38/40 + 2 esperas cortadas (al repetirlas, bien)	39/40
Página correcta	38/40	40/40
«No está» bien dicho	2/2	2/2
Respuestas correctas con un aviso falso	7	0
Primer texto, mediana / 95 %	2.1 s / 21.9 s	1.9 s / 2.8 s

• Las dos que fallaban con la API en ap-v1.23 ya salen, y las fallas que quedan son del modelo, no de la búsqueda: con el mismo contexto, a veces transcribe la lámina entera y a veces no.
• El aviso falso era un logo. Lo que el modelo lee en una lámina que es imagen (una marca que solo está como logo, una categoría dibujada) no está en ningún texto, y la verificación lo marcaba como «no pude verificar» y bajaba la certeza. Ahora, si la respuesta cita la página que vio como imagen, esos nombres van en una nota aparte —«Leído en la imagen de la pág. 16… compáralo con la lámina»— justo encima de la lámina, y la certeza no baja. Sin imagen citada, el aviso sigue igual. Tampoco se marca el número que cuenta la propia lista («se divide en 5 mundos» con los cinco debajo).

Dos modos de respuesta, y el modelo de fábrica

Desde el 26-sep, en Ajustes → Modo de respuesta hay dos:

• Razonado (el de fábrica): las seis etapas de arriba. Es el medido con los 30 manuales.
• Rápido: un solo paso de lectura —la página y el rótulo donde está el dato, o «no está»— y la respuesta. Mientras escribe, la tarjeta dice «Leyendo pág. 6 · SENSORES».

Con el manual demo (eval/preguntas-demo.json, 36 preguntas), el 26-sep, con node eval/modo-ia.mjs --modo razonado|rapido:

	Razonado	Rápido
Trae el dato y cita su página	24/24	23/24
Dice «no está» en las que no están y en las trampas	12/12	12/12
Avisos de «no pude verificar»	0	0
Primer texto en pantalla, mediana / 95 %	2.0 s / 6.7 s	0.9 s / 2.2 s

La que se le escapa al rápido es «la barra se ve muy llena»: la búsqueda trae SATURACIÓN en primer lugar, pero Flash-Lite a veces contesta con la lámina de alineación. En la corrida anterior del rápido salió bien (24/24), y en el razonado ya había fallado por la mañana. Es la pregunta más inestable del demo.

El rápido no es el de fábrica todavía: el #26, que también quitaba las etapas, empataba con el demo y perdió aciertos justo con los manuales reales (51/60 contra 55). Hasta medirlo con esos 30, queda como opción.

El modelo de fábrica ahora es 3.5 Flash-Lite. Era el que contestaba de verdad: en todas las mediciones 3.5 Flash salió saturado y respondió su respaldo, que es Flash-Lite. Ponerlo primero quita los reintentos de la primera pregunta. 3.8 Flash sigue en la lista, pero en el demo no contestó mejor: 23/24, ~6 s de mediana, se saturó a media prueba y dos de sus respuestas llegaron cortadas (el razonamiento sin la contestación).

Tres arreglos salieron de estas mediciones:

• «¿Qué reviso antes de que llegue la regional?» no traía ningún fragmento: el CHECK LIST nunca escribe «revisar». El diccionario lleva «reviso» hasta él, y de las 36 preguntas del demo es la única cuyo contexto cambia. «La barra se ve muy llena», en cambio, sí traía SATURACIÓN en primer lugar: esa falla había sido del modelo.
• Una respuesta que llega cortada se pide otra vez, una sola, antes de enseñarle al asesor el aviso.
• Las marcas con errata ya no se cuelan en la respuesta. Flash-Lite escribió dos veces «[RESPTESTA FINAL AL ASESOR]» y envolvió la contestación entre los corchetes de la plantilla; el asesor veía la marca y el verificador la tomaba por un nombre sin respaldo.

Cómo funciona, en 15 segundos

Lee tu manual → lo parte en láminas → preguntas como hablas → responde con la página y la lámina. Grabado en la app publicada, a doble resolución, con el manual de ejemplo: la pregunta, la lámina que gana, el texto y la medición salen del motor real. Probarlo tú.

Qué resuelve

El manual de montaje de una campaña son decenas de páginas en PDF. Nadie las carga al piso, así que las dudas se resuelven preguntando —si hay a quién— o adivinando. Este asistente pone ese conocimiento a un toque de distancia, en el lenguaje con el que realmente se pregunta: "¿a qué altura va el sensor?", no "criterios de colocación de dispositivo EAS".

Son dos herramientas en la misma app:

• Preguntar. El manual contesta con su página y su lámina, y dice «no está» cuando no hay evidencia. Debajo, «Sigue en el manual» propone la lámina que completa la respuesta (la clasificación de una sección lleva a sus estilos) y el siguiente básico del piso (marcas → clasificación → liquidación → etiquetas…). Solo propone lo que el manual trae, comprobado con la búsqueda local.
• Revisar con foto. Le tomas foto a la exhibición y el código mide colorización, surtido, triangulación y alturas, y prueba de dónde salió la foto. Todo en el teléfono, sin red.

Dos modos, y el de abajo es el interesante

	Modo manual (sin API key)	Modo razonado (con API key)
Qué hace	Busca en el manual y entrega los fragmentos que coinciden, tal cual, con su página y su lámina	Dos motores, a elegir en Ajustes. Agente lector: la IA lee el manual con herramientas —páginas, láminas, búsqueda— y contesta citando lo que leyó. Clásico: la búsqueda local elige los fragmentos y el modelo responde en 6 etapas o, en modo rápido, con un solo paso de lectura
Dónde corre	Entero en tu dispositivo, incluida la lectura del PDF y el recorte de figuras	Las herramientas corren en tu dispositivo; la lectura y la respuesta, en el proveedor que elijas
Sale a la red	No. Ni una petición	Sí. Al preparar un manual para el modo IA, cada página (texto e imagen) va una vez al proveedor, 6 páginas por petición. En cada pregunta van el mapa del manual y las páginas que se leen (agente) o los fragmentos que eligió la búsqueda (clásico)
Qué cuesta	Nada	Tu propia key y tus propios tokens. Preparar un manual de 25 láminas con Gemini Flash-Lite: unos 5 centavos de dólar, una vez

El modo manual existe porque un demo que primero te pide una API key no es un demo. Pero sobre todo existe porque declara su límite en vez de disimularlo: dice "sin modelo conectado, nadie interpretó esto" y entrega la fuente. Y si nada del manual coincide con la pregunta, lo dice — no rellena con la sección más cercana.

El agente lector: la IA lee el manual, el código la vigila

En el motor clásico la búsqueda local decide qué fragmentos ve el modelo, y le da órdenes según lo que encontró. Cuando la búsqueda falla —«contemporáneo» no llega a una lámina que dice «Contempo», «Trevsik» no llega a «Tresvik», las marcas vienen en logos que el PDF no trae como texto—, el modelo nunca ve la respuesta y contesta «no está». Eso pasó en una conversación real del piso.

El agente invierte los papeles:

1. Al preparar el manual, la IA lee cada página una sola vez (texto e imagen) y escribe su ficha: de qué trata, qué marcas y mundos nombra, lo que se lee en la imagen y no está en el texto, abreviaturas («Contempo = contemporáneo») y cómo lo preguntaría el piso. Se guarda en el teléfono. La ficha ubica, no contesta: en la búsqueda, un acierto en la ficha se cambia por los fragmentos reales de esa página. Lo único de la ficha que puede sostener un dato es lo que la IA copió literal de la imagen, y va rotulado como tal. Cuidando la cuota:
   • lee 6 páginas por petición, así un manual de 26 páginas gasta unas 5 y no 26;
   • sola, solo lee la sección activa;
   • la lectura automática se pausa al llegar a un tope diario (12 peticiones por omisión, se cambia en Ajustes), para que el resto de la cuota gratis quede para preguntar.
2. En cada pregunta, el modelo recibe el mapa del manual (una línea por página, de la ficha), el glosario de la sección y dos páginas que la búsqueda local le adelanta. Con herramientas que corren en el teléfono decide qué leer: leer_paginas, ver_lamina (la imagen de la página), buscar y, con varios manuales, buscar_en_otras_secciones, que solo dice dónde está algo y nunca devuelve su contenido.
3. Contesta con lo que entendió, lo que corrigió de lo escrito y la evidencia literal con su página. En pantalla sale «Entendí Tresvik (escribiste «Trevsik»)», qué páginas leyó y qué lámina miró, y botones para seguir: «¿Quisiste decir…?», o las preguntas que sí contestan las láminas que leyó.

El código es el guardián, no el que decide. Pone tope a las vueltas (4, la última sin herramientas), a las páginas (8), a las láminas (2) y a las llamadas por vuelta (6). Valida cada argumento: una página que no existe o una herramienta inventada vuelven al modelo como error, nunca como excepción. Comprueba que cada cita esté literal en una página que el agente leyó; si no, la certeza baja de ALTA a MEDIA y lo dice. Y si el ciclo falla por lo que sea —error del proveedor, respuesta vacía—, la misma pregunta la contesta el motor clásico. Con Gemini 3, las firmas de pensamiento que acompañan cada llamada a herramienta se devuelven intactas en la siguiente vuelta, como exige la API.

Estado: probado de punta a punta contra un Gemini y un OpenAI simulados (eval/agente-simulado.mjs, que también corre en el CI: protocolo, topes, citas inventadas, imagen rechazada, caída al clásico) y con 37 pruebas nuevas en el arnés. Sin medir contra un modelo real: por eso el motor de fábrica sigue siendo el clásico. Para medirlo con el manual demo, que ahora trae una lámina con las marcas solo como imagen:

node eval/modo-ia.mjs --motor clasico --etiqueta clasico
node eval/modo-ia.mjs --motor agente  --etiqueta agente
node eval/modo-ia.mjs --resumen

El set del demo suma ocho preguntas de las que fallaban en el piso: listas («¿qué marcas van en el mundo contemporáneo?»), abreviaturas, marcas con errata, datos que solo están en una imagen, un diagrama y dos conversaciones de varios turnos.

Con muchos manuales, la sección la elige la pregunta

Con varios manuales cargados y el selector en «Todos», cada pregunta se buscaba en todos a la vez. El agente no corría (lee una sola sección), el modo manual mezclaba tarjetas de varias secciones y hasta del manual interno de demostración, y el clásico le mandaba al modelo fragmentos de tres secciones con un aviso. Ahora la app elige la sección para esa pregunta, sin tocar el selector:

1. la que eligió el asesor arriba, si eligió;
2. la que la pregunta nombra («¿qué va en el POS de muebles?»);
3. la de la conversación, si es un seguimiento («¿y sandalias?») o si esa sección responde con evidencia sólida;
4. la única que responde con evidencia clara;
5. si dos o más responden igual de bien («¿cuánto pasillo dejo?» sale igual en tres manuales), no adivina: pregunta «¿en cuál estás?» con un botón por sección, sin gastar una llamada.

La respuesta dice de dónde salió y por qué («📕 Busqué en … (por tu pregunta)»), con un botón a la otra sección si también tenía con qué responder.

Medido con 5 manuales reales cargados a la vez y 102 preguntas de piso (fuera del repo), haciendo las preguntas de cada sección en orden y sin elegir sección:

	Antes	Ahora
Sección elegida bien	— (buscaba en todas)	83/86 · 2 toques de botón en 102 preguntas
Clásico: preguntas con fragmentos de otra sección	64	3
Modo manual: tarjetas de otra sección	41	3
Modo manual: tarjetas del manual interno de demostración	9	0
Modo manual: la página correcta entre las 3 tarjetas	64/86	70/86
Agente: el dato está en lo que lee	no corría	80/86

La cifra tiene que ir pegada a lo que dice el manual

La verificación comprobaba que cada cifra de la respuesta existiera en lo consultado, no a qué iba pegada. En la tabla de participación de una sección de calzado cada columna trae su porcentaje, y una respuesta que le daba a SNEAKERS el de la columna TENIS CASUAL pasaba limpia, porque esa cifra sí estaba en lo consultado. Ahora cada cifra dicha se compara, por su vecindad (el título de su fragmento y su tramo de renglón), con las demás cifras de la misma unidad. Solo se marca con evidencia de estructura: otra cifra pegada por título o rótulo que explica todo lo que explica la dicha y algo más. Con manuales reales: 0 de 21 respuestas correctas marcadas, 60 de 77 con la cifra cambiada marcadas.

Y la certeza ya no puede quedar en ALTA con un dato que la app no pudo comprobar (una cifra, un nombre o una página sin respaldo, o una cifra mal atada): baja a MEDIA, el aviso lo dice y se enseña la lámina —o la página entera— donde está la cifra.

El caso de esa tabla tenía además un error de lectura: el encabezado «TENIS / CASUAL» venía en dos renglones y su porcentaje quedaba titulado «CASUAL», igual que la columna vecina. La lectura del PDF une ahora los títulos de tabla apilados. Un manual guardado con la lectura anterior se marca en la lista («↻ vuelve a elegir el PDF») y se relee al volver a elegirlo, sin perder su ficha ni las descripciones de láminas.

Medir con tus manuales, sin compartir la key

Los manuales reales no pueden estar en el repositorio y la key es de quien la usa, así que la medición corre en la propia app. En Manuales → «🧪 Medir el modo IA con un examen» se elige un examen (un JSON con preguntas de piso, la sección de cada una, lo que debe traer la respuesta y su página). La app prepara la ficha de las secciones que falten, pregunta con el motor clásico y con el agente como lo haría el asesor, califica con la misma regla que eval/modo-ia.mjs y al final comparte o descarga un archivo de resultados, que no incluye la key. Guarda el avance: si se acaba la cuota del día, al volver a abrir el mismo examen sigue donde se quedó. Las preguntas del examen no entran al tablero del equipo.

{"examen": "mis manuales", "preguntas": [
  {"seccion": "140 CASUAL HOMBRE", "q": "¿a qué altura va el sensor?", "tipo": "dato", "k": ["15 cm"], "p": [6]},
  {"seccion": "140 CASUAL HOMBRE", "q": "¿qué hago si se va la luz?", "tipo": "trampa"},
  {"seccion": "140 CASUAL HOMBRE", "q": "¿y en el clásico?", "turnos": ["¿qué marcas van en el mundo contemporáneo?"], "tipo": "dato", "k": ["Brastow", "Ondera"], "minK": 2}
]}

tipo es dato (debe traer alguna de k —o minK de ellas— y citar una página de p), no-esta o trampa (debe decir que el manual no lo especifica) u otra (debe decir en qué sección, otra, está).

En el panel se eligen los motores —clásico, agente y modo manual, que se mide sin key— y si se mide «como el asesor: sin elegir sección». En ese modo la app elige la sección de cada pregunta y se califica también si la eligió bien; si hay empate, se toca la sección del examen y se cuenta el toque. El resumen dice además cuántas veces avisó de una cifra mal atada y cuántas de esas en respuestas que estaban bien (las falsas alarmas), y cuántas veces bajó la certeza.

Medido así el modo manual, con los 5 manuales reales y las 102 preguntas: 56/86 datos con la sección elegida y 52/86 sin elegirla, preguntando cada una suelta (sección bien 92/102, con 20 toques).

Las preguntas de verdad hacen mejor examen que las escritas leyendo el manual, que usan sus palabras. En el Tablero → «⬇ Preguntas para examen» se exportan las dudas del equipo con el formato del examen, sin repetir, con lo que la app encontró y la nota de cada 👎 como pista. Falta anotar en cada una el dato y la página esperados.

Un instrumento que no se rompe a media medición. Antes de medir, «🩺 Chequeo antes de medir» revisa las secciones, la lectura de los PDF y las fichas, hace una sola llamada para saber si la key sirve y si queda cuota, y estima el costo de la tanda. Durante la medición:

• el límite por minuto del plan gratis se espera lo que dice el proveedor, con el mismo modelo;
• la cuota del día para la tanda sin guardar errores como resultados, y al día siguiente sigue donde se quedó;
• midiendo nunca se cambia de modelo: si el elegido está saturado, la fila es un error y no la respuesta de otro;
• una respuesta del agente cortada por tokens se repite una vez con más margen;
• cada fila guarda el modelo que de verdad contestó, la versión de la app y la de lectura;
• cada falla se clasifica por capa: sección, búsqueda (el dato no llegó), modelo (llegó y contestó otra cosa), página citada, error del proveedor.

Medir sin teléfono: el banco y el comparador

El mismo examen, la misma calificación y el mismo archivo de resultados, corriendo en un Chromium sin ventana. Los manuales se leen de una carpeta fuera del repo y la key de GEMINI_API_KEY (el modo manual no la necesita):

node eval/banco.mjs --manuales ~/manuales --examen ~/examen.json --motores manual
GEMINI_API_KEY=… node eval/banco.mjs --manuales ~/manuales --examen ~/examen.json \
    --motores clasico,agente --etiqueta base
node eval/comparar.mjs eval/resultados/base__….json eval/resultados/cambio__….json

--libre mide «como el asesor» y --continuar <resultado> retoma una tanda que cortó la cuota. comparar.mjs dice, pregunta por pregunta, qué se arregló, qué se rompió (y sale con error si algo se rompió) y en qué capa siguen las fallas. Con el modo manual y los 5 manuales reales, el banco reproduce la medición de la app: 56/86 con sección elegida, 52/86 sin elegirla.

La app aprende del piso: caminos, nunca respuestas

El piso no habla como el manual. Dice «burros» donde la lámina dice «percheros», o pregunta por algo que está en la pág. 7 con palabras que la pág. 7 no usa. La app aprende esos caminos: una palabra del piso que lleva a una palabra del manual, y una forma de preguntar que lleva a una página. El dato sigue saliendo siempre del manual, con su página. No se aprende una sola respuesta.

Aprende de cuatro cosas que el asesor ya hace:

• El 👎 pide la lámina. «¿En qué página estaba?», con las páginas más probables como botones y un número para escribir la que sea. Un toque deja un atajo y abre esa lámina. Si la pregunta traía palabras que ese manual no usa, quedan emparejadas, por confirmar, con el título de esa página. En modo manual, un «nada coincide» también ofrece decir dónde estaba. Y «No está en el manual» lo anota como hueco real en el Tablero.
• «✓ Sí, eso». Cuando la app dice «lo encontré como…» o el agente dice «Entendí…», un toque lo confirma.
• La reformulación. Una pregunta que no llegó, seguida en menos de 3 minutos por otra parecida que sí llegó. Lo que cambió entre una y otra es cómo lo dice el manual.
• La IA propone (con key). Mira las palabras del piso que siguen sin resolver y los títulos del manual, y propone equivalencias. Se hace al terminar de preparar un manual o con «✨ Que la IA proponga» en el Tablero. Lo propuesto no se usa hasta que alguien lo confirma.

Con candados, porque aprender mal empeora lo que ya funcionaba:

• cada palabra es de una sección;
• se activa con dos confirmaciones de consultas distintas, así que una errata aislada o un toque equivocado no se aprende;
• nunca cifras;
• la palabra del manual tiene que existir en ese manual;
• lo que ya dice el diccionario no se duplica;
• hay un tope por sección.

Lo aprendido entra a la búsqueda como una palabra más del diccionario: pesa igual y ayuda a llegar, pero no cuenta como palabra escrita. El atajo solo reordena lo que ya llegó por sus palabras; no mete una página sin evidencia. Cada respuesta dice qué usó: «📚 Usé lo que aprendió el piso: «burros» = «percheros»».

En el Tablero, «Lo que aprendió del piso» enseña las palabras activas, las que están por confirmar y las propuestas de la IA, con ✓ para confirmar y 🗑 para borrar. Desde ahí se saca todo con «⬇ Vocabulario del piso»: palabras y páginas, sin preguntas. El archivo sirve para revisarlo y, si el banco dice que mejora, subirlo al diccionario del código para todos los teléfonos. «⬆ Cargar vocabulario» lo pasa a otro teléfono con los mismos candados. «Aprender del piso» se apaga en Ajustes.

Midiendo no se aprende nada, y por defecto tampoco se usa lo aprendido. La medición es del código, no de la memoria de un teléfono. Para medir el efecto está la casilla «Con lo aprendido del piso» en la app, o --aprendido vocabulario.json en el banco; el resultado lo dice y comparar.mjs lo marca. Así, «¿sirvió aprender?» se contesta con el mismo examen, sin y con.

Esto reemplaza a la vieja «memoria de aprendizaje» de 👍/👎, que pegaba al prompt las preguntas que salieron mal. No movía nada medible y se colaba en la medición. Se borró, y sus datos se borran del teléfono al abrir la versión nueva. Las notas del 👎 ya viajaban en el Tablero.

Qué sigue: la hoja de ruta dice cómo trabajamos (nada mejora sin número), dónde estamos por capa y el orden de lo que viene: la línea base con modelo real y, con ella, medir cuánto suma lo aprendido del piso.

Revisar con foto: el mini Veristack en el teléfono

La pestaña Revisar apunta la cámara a una tringla, un anaquel o un focal y en un segundo regresa la foto marcada, con un veredicto por básico y su porqué. Una foto de área se revisa por zonas: con «＋ Zona» se encierra la mesa, la tringla y el focal de la misma foto, y cada zona trae sus básicos y un resultado general. Todo corre en el teléfono: sin red, sin costo, sin subir la foto a nadie y sin IA que juzgue la foto. El código mide y cada resultado lleva sus números (fuente: CÓDIGO). Si la foto no da para calificar (oscura, movida o sin suficientes elementos), sale NO_CALIFICA: nunca se inventa un CUMPLE. El diseño y los criterios de éxito, fijados antes de medir, están en el ADR 0007.

Básico	Qué mide el código	Qué marca en la foto
Colorización	Una franja a la altura del pecho, por columna en CIELAB; la corta en tramos de color y los clasifica en cálido, frío o neutro (los cafés, beiges y el azul marino son neutros; la mezclilla es fría). Antes, un balance de blancos quita el tinte de la luz de tienda. Cada grupo va en un solo bloque.	Una barra por tramo y el tramo que rompe el orden («frío entre cálidos, tramo 4 de 12»)
Surtido	Celdas con bordes de Sobel contra el color del fondo del mueble; un hueco es vacío de arriba abajo, no el aire de encima de una pila, y deja ver el mueble (lo casi negro es sombra o producto negro, no hueco).	Los huecos rayados y el % vacío medido
Triangulación	Los puntos altos de cada elemento: una sola cima y desnivel suficiente. Vale el simétrico y el asimétrico (la cima a un lado, bajando por bases y bolsas). Toque inteligente: tocas cada elemento donde sea y su silueta (MediaPipe Magic Touch) da su punto más alto; la silueta se ve, y «Punto exacto» vuelve al toque a mano. Un detector (EfficientDet-Lite0) sugiere los puntos: busca en el recorte de la zona, quita el fondo y las bases, afina cada uno con la silueta y no pisa lo que ya tocaste. Medido con 5 focales de tienda: encuentra 11 de 17 cimas y 11 de 12 sugerencias caen en un elemento (antes, 8/17 y 8/11). Con «Punto exacto» sale una lupa, y cada punto se arrastra.	El triángulo, las bandas de cada altura y, si dos empatan arriba, «sube este»
Alturas y niveles	Con los mismos puntos: cuántas alturas distintas hay (alto, medio y bajo).	La cifra de alturas
Evidencia de la foto	No adivina si es IA: prueba de dónde salió. Tomada en la app (con huella SHA-256), de galería (EXIF: cámara, fecha, editor) o con su credencial de contenido (C2PA), que se lee y valida con el SDK oficial (c2pa-web) contra la lista de confianza oficial de C2PA (CC-BY-4.0, copia del 13-ago-2026): manifiesto activo, cadena de padres y firma. Una original firmada por una cámara de la lista (el Pixel 10 firma todas) y tomada en las últimas 24 h sale CUMPLE. Va aparte del veredicto del montaje: una foto reenviada por WhatsApp sale «sin datos». Cuando la app no puede probar el origen, un botón opcional manda la foto original a SynthID (Gemini en el teléfono, el portal en la computadora) para buscar la marca de agua de la IA de Google, y la persona anota lo que vio. Ningún detector de píxeles juzga la foto.	solo si la foto declara que con IA; retocada con IA o alterada después de firmar,

Lo que una foto no puede probar (planchado, limpieza, alineación, enganchado, sensores, entallado, el pasillo de 90 cm y, en el focal, composición, equilibrio y simetría) va en una lista para marcar a mano. La foto marcada y el resumen se comparten por WhatsApp con la Web Share API.

Medido hasta hoy, con honestidad:

• Imágenes sintéticas (node eval/revision.mjs --sinteticas, tres niveles de suciedad): triangulación 72/72, niveles 36/36, surtido 54/56 y colorización 52/56. Casi todos los fallos están en el nivel «duro», donde un naranja en sombra fuerte es café para la cámara. Prueban el método, no el criterio del ADR.
• Fotos reales (node eval/revision.mjs --fotos <carpeta>, fuera del repo):
  • 5 fotos de piso (15 básicos en 7 zonas): todos aciertan;
  • 20 fotos de exhibición de referencia (40 básicos): todos aciertan.
  • 30 fotos de tienda reenviadas por WhatsApp: el origen sale «sin datos» en todas, ninguna GRAVE. El mejor detector de IA abierto tampoco marcó ninguna (0/59 con las de ayer), pero pesa 780 MB y falla con ediciones locales: no entra a la app (ADR 0007).
  • Pero esas fotos se usaron para calibrar: son desarrollo, no evidencia. La confirmación es el siguiente lote de fotos, corrido una sola vez.
• La regla de colorización (orden de los grupos y dirección) sigue siendo un supuesto por confirmar, y se configura en REGLA_COLOR.

Sin cámara se puede probar con Ejemplo (una tringla, un anaquel y un focal dibujados por código, con y sin defecto) y con tres muestras de origen armadas en la app (foto de cámara, reenviada por WhatsApp y hecha con IA).

Cómo está hecho

• Archivos estáticos, sin build. Módulos ES nativos, sin bundler, sin backend propio, sin servidor que mantener. Se publica tal cual y se abre desde un link: cómo está partido el código.
• Conocimiento embebido y estructurado, con un diccionario de sinónimos y alias por término — la gente no pregunta con el vocabulario del manual. "Acomodar" tiene que encontrar "exhibir", "clasificar" y "mercadear".
• Retrieval léxico local con BM25: se extraen las palabras de la pregunta, se expanden con sus sinónimos —que pesan menos que la palabra que el usuario escribió de verdad— y se puntúan los fragmentos por relevancia, con peso extra para las reglas [MANDATORY], los conflictos documentados y, cuando la pregunta pide una cantidad, para los fragmentos que traen cifras.
• Conflictos documentados como feature. Cuando dos manuales se contradicen (el entallado lleva 4, 5 o 6 piezas según cuál leas), el sistema tiene prohibido responder "el manual no especifica": cita el conflicto y la regla general.
• Cuando la búsqueda no encuentra nada, se dice. El contexto llega encabezado por un aviso de que no hubo coincidencias y con la orden de contestar "el manual no especifica", en vez de entregar fragmentos sueltos bajo la instrucción de "responde solo con esto" — que es obedecer y componer una regla que nadie escribió. En ese caso tampoco se guarda evidencia: no puede salir una lámina debajo de una respuesta que el manual no sostiene. Son tres niveles, no dos, y eso salió de medir: a escala real «¿cómo acomodo las tallas?» —una pregunta central del piso— deja la misma huella que «¿a qué hora abre la tienda?». Con evidencia sólida se responde normal; con evidencia débil el contexto va igual pero avisando de que la coincidencia es floja, y decide el modelo, que sabe leer si esos fragmentos vienen al caso; sin ninguna coincidencia no se finge nada. Cortar en seco el caso intermedio contesta "no lo especifica" a preguntas que el manual sí contesta, y eso vacía la herramienta más rápido que un contexto de más.
• Una sección a la vez. El asesor elige con qué manual está trabajando y solo ese se consulta; queda un «todos» explícito para comparar. No es un lujo de interfaz: medido con cinco manuales reales de la misma plantilla, «¿cuánto pasillo dejo?» armaba la respuesta con fragmentos de los cinco y enseñaba tres láminas de tres manuales distintos. El dato salía bien y citado a la página de un manual que no era el suyo, que es peor que un dato inventado: el asesor va a esa página y no está.
• La identidad la pone el manual. El nombre de la sección se saca del propio documento —«271 CASUAL», «436 COLECCIONES BEBÉS»— y con él se presenta el asistente, se rotulan las respuestas y se generan accesos rápidos con los títulos de sus propias láminas. Antes se presentaba como especialista de Hombres delante de un manual de Bebés, y el filtro de tema —vocabulario de Hombres— dejaba fuera preguntas tan de piso como «¿qué se debe limpiar?».

Cómo está partido el código (sin bundler)

Hasta octubre de 2026 todo vivía en un index.html de 12,000 líneas, y fue a propósito: abre sin señal, se publica sin compilar y se puede revisar entero. Cuando el motor tuvo que usarse fuera del navegador (medir en Node, pruebas de propiedades, un servidor MCP), lo partí en módulos ES nativos, todavía sin bundler (ADR 0005). Lo de antes se mantiene:

• Abre sin señal. El service worker (sw.js) guarda la página, cada archivo de src/, las tres librerías del CDN y las fuentes. El código de src/ va primero a la red, igual que la página, para que el celular nunca junte un HTML nuevo con un JavaScript viejo. Si un archivo de src/ falta en la lista, el arnés falla.
• Se publica sin compilar. GitHub Pages sirve los archivos tal cual. No hay build que se rompa ni servidor que pagar.
• Se puede revisar entero. Todo lo que la app hace con la pregunta y con la key se lee en GitHub o en DevTools.
• El arnés prueba el código que corre. index.html?test=1 ejecuta las mismas funciones que usa el asesor.

Archivo	Qué es
index.html	Estilos y pantallas
src/main.js	Arranque: carga los módulos y los publica para el resto de la app
src/motor/	El motor, sin DOM: se importa desde Node. texto.js (stopwords, sinónimos, tokenización), indice.js (BM25), erratas.js (erratas, fonética y vocabulario de cada manual), layout.js (de pdf.js a bloques con título), fragmentos.js, secciones.js (de qué sección es cada manual y cuál nombra la pregunta), solidez.js (cuándo una coincidencia cuenta), aprendido.js (lo que enseñó el piso), busqueda.js (retrieve y el empaquetado del contexto), puerta.js (palabras ausentes, la cifra que falta y el contrato de decisión: respaldada, parcial, aclarar o sin_evidencia, con su evidencia y sus razones), ruta.js (contra qué sección se responde), conversacion.js (si la pregunta es del tema, el seguimiento y la ruta, con el historial como parámetro) y respuesta.js (las tarjetas del modo manual y el contexto del modelo, cada uno con su contrato)
src/estado.js	El estado del corpus en un solo objeto (manuales, fragmentos, índice, lo que entró al contexto), el registro de cachés y conEstado, con el que el arnés monta un corpus de prueba y siempre vuelve al de antes
src/seguridad/	Saneado del HTML y defensa contra instrucciones escondidas (ADR 0004)
src/revision/	La revisión con foto (ADR 0007). Piezas puras sobre {width,height,data} que corren igual en Node: procedencia.js (EXIF, XMP/IPTC, C2PA y huella), color.js, surtido.js, triangulo.js, veredicto.js y demo.js (imágenes sintéticas). Solo ui.js (cámara, marcas y compartir) y detector.js (MediaPipe, carga perezosa) tocan el navegador
src/app.js	Lo que falta por partir, en bloques con rótulo /* ════ NOMBRE ════ */

El corte va por capas: estado, índice, búsqueda, puerta de evidencia, verificación, IA y UI. Cada paso tiene que dejar idéntico, campo por campo, lo que el motor hace con cientos de preguntas sobre manuales reales (golden master, lab/identico.mjs). Los tipos se revisan con tsc --checkJs sin compilar nada (npm run tipos), y las propiedades del motor se prueban con fast-check (lab/motor.test.mjs).

Una cuarta parte del JavaScript son comentarios. Casi todos explican por qué una regla es como es, con la pregunta que la hizo necesaria.

Gráficos: el logo, la aurora y el banner

El ícono es el monograma AP (icons/icono.svg): la A es la triangulación del display, con su punto focal arriba, y la P es una lámina con la esquina doblada. Los PNG del manifest (192 y 512 redondos, 512 maskable, 180 de Apple), icons/og.jpg y docs/banner.png salen del SVG y de capturas de la app real con el ejemplo sintético:

PLAYWRIGHT_CORE=<ruta a playwright-core/index.mjs> CANAL=chrome node design/iconos.mjs

El color vive en el fondo: una aurora de tres orbes (rojo de la marca, naranja y azul) detrás del vidrio, que se mueve despacio y se corre según la pestaña. Con «reducir movimiento» se queda quieta y con «reducir transparencia» desaparece. El rojo como estado sigue marcando solo la pestaña activa.

Cómo se mide

Abrir index.html?test=1 corre el arnés: preguntas de respuesta conocida sobre el manual interno —incluidas las que llegan por sinónimo, las escritas con errata, las de seguimiento y tres de ruido que deben quedar sin respuesta—, más las comprobaciones de verificación numérica, de láminas y de certeza. Reporta recall, cuánto ruido se atrapa y el margen del caso más ajustado sobre el corte relativo CTX_ALPHA, que es el número que hay que volver a mirar cada vez que se toca el vocabulario. Corre entero en el dispositivo, sin API y sin red, sobre las mismas funciones que usa el chat.

Corre solo en cada cambio. El CI (.github/workflows/arnes.yml) abre la app en un Chromium sin ventana con eval/arnes.mjs y marca en rojo el push o el pull request si alguna de las 320 filas falla. La app no se compila: el package.json es solo para las herramientas de desarrollo, y en el CI Playwright se instala solo. En local: npm run arnes (con CANAL=chrome si no tienes el Chromium de Playwright).

El mismo CI corre eval/despliegue-sw.mjs: un servidor que se porta como GitHub Pages (max-age=600) publica una versión nueva a media sesión y comprueba que llegue entera, a la página y a la caché sin señal. Antes el service worker pedía el código con la caché HTTP del navegador, y durante diez minutos podía arrancar con un app.js nuevo y un módulo viejo; ahora revalida con el servidor (cache:'no-cache').

Si hay manuales cargados corre además una segunda tanda contra ellos. No puede comprobar respuestas concretas —cada manual dice lo suyo—, así que mide lo que es igual en cualquier manual de piso: que las preguntas de siempre (pasillo, gancho, tallas, limpieza, surtido) encuentren algo, que el ruido no, que con una sección activa ni un fragmento ni una lámina salgan de otro manual, y que preguntar por una sección teniendo otra activa avise en vez de contestar. Esa última prueba se arma sola con el identificador que cada manual da de sí mismo, así que corre igual con manuales que el sistema no ha visto nunca. Medido sobre once manuales reales cargados a la vez —1.150 fragmentos, 706 figuras, 82 MB, 3 minutos de carga—: 33/33.

Lo que ese lote mide de verdad no es el acierto, es de dónde sale el dato. Con las once secciones cargadas y una activa, 88 preguntas de trabajo (ocho por sección) devolvieron cero fragmentos de otro manual y cero avisos indebidos; y nombrando otra sección, las once avisan con cero fragmentos y cero láminas, que es lo que hace imposible la cifra creíble y falsa. La contraprueba de por qué importa: «¿cómo circula el cliente en la sección?» la contestan diez secciones con siete cifras distintas, todas verdaderas en su manual.

El eval-gate: un corpus público para que el CI mida la búsqueda

El arnés comprueba comportamientos; no dice si un cambio al motor acierta más o menos. Eso se medía solo con los manuales reales, que no pueden entrar al repo, así que ningún número del motor era público ni corría en el CI. Para eso está eval/corpus-publico/:

• Cuatro manuales ficticios (el demo y tres más: boutique, cava y hogar), generados de HTML a PDF con generar.mjs. Están hechos para traer las trampas que encontró el benchmark con manuales de verdad: títulos de dos renglones, tablas, check lists que repiten reglas, rótulos sin frase, el mismo título en dos secciones con cifras distintas.
• Una batería de 99 preguntas: 68 de dato, 16 conversaciones de seguimiento y 15 «no está» o trampa, con el mismo formato y el mismo calificador que las privadas.
• lab/gate.mjs carga los cuatro PDF en la app real (lab/volcar.mjs --local, sin puente ni teléfono, 5 s), califica cada pregunta y la compara con eval/corpus-publico/linea-base.json. El PR no pasa si una sola pregunta que estaba bien pasa a mal, o si Hit@3 o MRR@10 bajan más de dos puntos. El informe —qué se rompió, qué se arregló, McNemar— queda en el resumen del job. Si el cambio arregla preguntas, npm run gate -- --actualizar sube la línea base y el diff del PR lo enseña.

Comprobado con una mutación: pedirle al filtro de solidez una palabra más rompe 7 preguntas y el gate las lista y falla (p = 0.016). La línea base empezó en 68/78 datos y 14/15 «no está», y las 10 que fallaban eran las mismas familias de falla que con los manuales reales: el filtro de solidez que deja sin tarjetas una pregunta con una sola palabra en común, las conversaciones de seguimiento, los rótulos en mayúsculas que se pierden al leer el PDF y un aviso falso por errata. La coincidencia floja de la Fase 3 la subió a 74/78, y el seguimiento que cambia el objeto («¿y las sábanas?») a 81/84 con 6 conversaciones más; quedan dos rótulos en mayúsculas y la errata. El corpus es inventado: protege contra regresiones, no dice cuánto acierta la app en el piso. Eso se mide fuera del repo, con tres baterías separadas (desarrollo, prueba y confirmación, esta última corrida una sola vez), y ahí el modo manual da 58–70 % con preguntas que no vio al afinarse.

La batería con respuesta conocida

El arnés de arriba comprueba que una pregunta encuentre algo. Eso no es lo mismo que encontrar la lámina que contesta, así que hay una segunda medida, hecha al revés: se vuelca el contenido de los once manuales, se escriben 88 preguntas en las palabras del asesor —un quinto de ellas sin compartir ni una palabra con la lámina que las responde— y cada una lleva anotada su página y su rótulo. Más 14 preguntas cuya respuesta no está en la sección activa, sin las cuales subir el recall es trivial y falso: basta con aflojar los cortes.

	antes	después
la página que contesta llega al contexto	94% (82/88)	100% (88/88)
escritas en palabras del asesor, no del manual	87%	100% (16/16)
se ofrece la lámina de esa página	79%	100% (71/71)
dos temas en una frase, los dos contestados	5/6	6/6
preguntas sobre el propio manual	0/12	12/12
negativas que no se entregan como evidencia sólida	10/14	13/14
fragmentos de otro manual	0	0

Los cuatro fallos de recall que quedaban eran una sola causa: el asesor escribe el verbo y el manual titula el sustantivo. «Doblo» no llegaba a DOBLADO, «cuelgo» no llegaba a COLGADO —la raíz cambia al conjugar—, «colorizo» no llegaba a COLORIZACIÓN. No era vocabulario: la lámina estaba ahí y se llamaba casi igual.

La batería vive en el repositorio del proyecto, no en la app: son 104 preguntas escritas a mano contra manuales concretos. Lo que sí queda dentro son las pruebas de las funciones que salieron de ella —morfología, preguntas de estado, palabra ausente, nombres sin respaldo, búsqueda en todas las secciones—, que corren en ?test=1 con y sin manuales.

Dos de esas preguntas no las escribí yo. Salieron del piso, con la API conectada y 101 MUEBLES abierto, y sus respuestas venían marcadas con 👎:

«¿cuál es la marca propia?» → «‹marca X› es la marca propia de ‹la cadena›» «¿cuál es marca preferencial?» → «‹marca X› es la marca preferencial»

Comprobado contra los manuales: «preferencial» no aparece en ninguno de los once, la marca solo en otra sección, y el texto crudo del PDF de MUEBLES —38 páginas— no contiene ninguna de las dos palabras. Ninguna de las dos respuestas salió de un fragmento: salieron de que el modelo reconoce la cadena real de la que son estos manuales y completó con lo que sabe de ella. Es la última vía de invención que quedaba abierta, y la que ninguna comprobación tocaba: se verificaban cifras y páginas, y un nombre de marca pasaba limpio.

El motor de lectura de manuales

Un manual de campaña no es un documento de texto corrido: es una presentación. En una misma lámina conviven dos reglas distintas, una en cada columna, a la misma altura. Eso condiciona todo lo demás:

• Reconstrucción por columnas. El texto se rearma en tres pasos —fragmentos → líneas, cortadas donde hay hueco horizontal → bloques, agrupados por cercanía— y solo al final se ordena, por bandas y de izquierda a derecha. Agrupar por coordenada vertical, que es lo que hace casi cualquier extractor, fusiona las dos columnas y produce una regla que no existe.
• Cada fragmento sabe de dónde salió. Documento, página y sección viajan pegados al texto hasta el prompt, y la sección se asigna por posición —el título que está encima y en la misma columna—, no por orden de lectura. Citar mal la sección es peor que no citarla: por eso el título vigente se reinicia en cada página y, cuando la lámina no lleva ninguno en mayúsculas, se usa su propio nombre —el rótulo corto de la franja superior, "Rotación", "Perímetros de Básicos"—, que es lo que el asesor tiene delante en la hoja.
• Figuras. Los planogramas de estos manuales son dibujos vectoriales, no fotos: extraer las imágenes incrustadas devuelve íconos de leyenda de 36×18 px y se deja justo lo que más se consulta. Así que se hace lo que hacen los parsers serios (Marker, MinerU): renderizar la página y recortar la región, encontrándola por geometría —dónde hay tinta que no es texto— como en PDFFigures 2.0, sin ningún modelo. Para las fotos, además, se le pregunta al PDF dónde coloca cada imagen. Cada figura hereda el texto que la rodea, así que ya es buscable sin ninguna IA.
• Verificación de lo verificable. Con API key, cada cifra de la respuesta se comprueba contra los fragmentos que realmente se enviaron, cada página citada contra las que existen, y cada nombre propio contra los que el manual usa. Lo que no cuadra sale marcado. No detecta un razonamiento equivocado; detecta el dato traído de fuera del manual, que es el que llega al piso.
• Los nombres se reconocen por lo que sabe el corpus, no por las mayúsculas. La respuesta que falló decía la marca al principio de la frase y el nombre de la cadena en minúscula, así que fiarse de la capitalización de la respuesta no habría servido para ninguna de las dos. Lo que sí sirve es cómo escribe el manual: un nombre propio aparece en mayúscula a mitad de frase —«la marca ‹X› Kids», «el sistema de ‹Nombre› de la cadena»— y no aparece nunca en minúscula. Las palabras corrientes fallan la segunda condición, así que no entran. Con eso, un nombre que está en otra sección —o en ninguna— y no en los fragmentos consultados sale marcado.
• La lámina que acompaña sale de lo que la respuesta citó, no de lo que el buscador trajo: las páginas citadas se cruzan con los fragmentos enviados para saber de qué manual son, y si la respuesta no cita ninguna página no se muestra ninguna imagen. Los recortes repetidos se reconocen por una firma visual del propio recorte, no por su posición en la lámina.

Dependencias y datos — lo que sí sale y lo que sí se guarda

Nada de esto es un problema, pero prefiero decirlo a que se descubra abriendo DevTools:

• Carga tres librerías desde CDN (cdnjs): pdf.js para leer PDFs de temporada que el usuario arrastre, marked para el markdown y DOMPurify para sanitizar lo que se renderiza. Más las tipografías de Google Fonts.
• Con API key, la pregunta sale del dispositivo hacia el proveedor que el usuario configuró. Es una llamada directa del navegador a su API, sin intermediarios míos.
• Guarda en el navegador: la API key en sessionStorage (se borra al cerrar la pestaña, nunca en localStorage); el historial de chat, lo aprendido del piso y los accesos rápidos en localStorage.
• Guarda los manuales procesados en IndexedDB, indexados por el hash del archivo, para no volver a procesar 28 láminas cada vez que se abre la página desde el celular. Incluye los recortes de las figuras. Vive en el dispositivo y no sale a la red, y hay un botón visible para borrarlo en la pestaña de manuales.
• Si —y solo si— se pulsa "describir figuras", los recortes salen hacia el proveedor configurado. Es la única vez que una imagen del manual deja el dispositivo, y hace falta pedirlo a propósito.
• Un PDF no puede darle órdenes al modelo. El texto del manual llega marcado como dato, con un sello aleatorio por sesión (spotlighting). Lo que tiene forma de instrucción para una IA («ignora tus instrucciones», «system:», las etiquetas de control de la app) se quita antes de mandarlo, y al cargar un manual así se avisa con la página. En las respuestas, las imágenes no se pintan y los enlaces que llevan datos en la URL salen como texto. Detalle y límites en docs/adr/0004.
• Las fotos de «Revisar» no salen del teléfono. Se miden ahí mismo y solo se comparten si la persona toca «Compartir». La primera vez que se pide una sugerencia en el focal, la app baja el detector (MediaPipe 0.10.21 desde jsDelivr y el modelo desde Google Storage, ~14 MB). Se guarda aparte y después funciona sin señal. La CSP solo abre esas dos rutas.
• Sin telemetría, sin analítica, sin cuentas. Nada se envía a ningún servidor mío, porque no hay servidor mío.

Límites conocidos

• El retrieval no lematiza de verdad. Del lado de la pregunta prueba unas cuantas formas —plural en los dos sentidos ("pasillos" → "pasillo" y "maniquí" → "maniquíes"), género ("rebajado" → "rebajada") y, desde la batería, la derivación al sustantivo con la que estos manuales titulan: "doblo" → DOBLADO, "colorizo" → COLORIZACIÓN, y "cuelgo" → COLGADO cambiando la raíz, que es lo que hace el español al conjugar. Va en un solo sentido a propósito: al probar también el infinitivo, "cambio" alcanzaba "cambiar" y "¿cómo cambio la llanta del coche?" volvía a pasar por pregunta contestable. Sigue sin ser un lematizador y ningún salto de significado ocurre sin el diccionario de sinónimos, que se llena a mano y por lo tanto está incompleto. Lo que sí hay es dónde arreglarlo: las variantes se generan solo del lado de la pregunta, así que ampliarlas no obliga a reprocesar ningún manual ya guardado.
• Los manuales son de una cadena que existe, y el modelo la reconoce. Es la vía de invención más difícil de tapar, porque lo que sale suena cierto y a veces lo es: «‹marca X› es la marca propia de ‹la cadena›» es verdad en el mundo y es falso en ese manual, que no dice ni una de las dos palabras. Hay tres defensas y ninguna es total: una regla del prompt que prohíbe usar lo que sepa de la cadena, un aviso en el contexto cuando una palabra de la pregunta no está en el manual activo, y la verificación de nombres, que es la única que no depende de que el modelo obedezca. Un dato de la cadena que sí esté escrito en otra sección del mismo manual sigue siendo indistinguible de uno recordado.
• «Preferencial» no se puede separar de «preferencia» sin entender. El corrector de erratas las da por iguales —0.85 de parecido por trigramas— y «de preferencia, coloca…» sí está en el manual. Se le enseñó a no tratar como errata lo que comparte raíz, que es lo que distingue una falta de ortografía de una palabra distinta; pero una derivación con otro sentido sigue colándose. Ahí la red es la verificación de nombres, no la búsqueda.
• Una palabra que el manual no menciona no se puede detectar por semántica, solo por ausencia. Con once secciones cargadas, "¿cómo acomodo las sábanas?" estando en ZAPATOS engancha con "acomodar" —que sí es de ese manual— y devuelve fragmentos correctos para una pregunta que es de otra sección. Lo que se comprueba es literal: si una palabra de la pregunta no tiene ningún camino hasta el manual activo (ni forma, ni raíz, ni sinónimo) y sí es tema de otro cargado, se dice cuál. Funciona con sustantivos concretos —sábanas, tequila, motos— y no distingue matices: dos manuales que usen las mismas palabras para cosas distintas siguen siendo indistinguibles para esto.
• Las erratas se corrigen por parecido, no por diccionario. Cuando ni la palabra escrita ni ninguna de sus formas está en el índice, se busca la más parecida por trigramas y entra con el mismo descuento que un sinónimo. Alcanza para "entayado", "corvatas" o "maniquis"; no para una palabra mal partida ni para una que el manual sencillamente no usa.

Lo que encontré al prepararlo para publicar

Defectos que el uso normal no muestra. Los dejo escritos porque enseñar dónde falla un sistema dice más de él que la lista de lo que hace:

1. El hash de integridad de DOMPurify estaba mal. El navegador descargaba el archivo, la verificación SRI fallaba y el script no se ejecutaba nunca. El código tenía un fallback (escapeHtml) que funcionaba tan bien que nadie notó nada: llevaba meses renderizando todas las respuestas como texto plano escapado, y la protección que decía tener no estaba cargada. Un fallback silencioso convierte un bug en una feature invisible.

2. El retrieval no sabía decir "no sé". La función que puntúa las secciones suma puntos por ser [MANDATORY] o por documentar un conflicto, aunque no coincida ni una palabra de la pregunta. Resultado: preguntar por una receta de cocina devolvía la sección de entallado, con toda seriedad. Sirve cuando el resultado lo lee un modelo, que descarta lo que no viene al caso; en el modo manual era mentir. Ahora se exige al menos un acierto real de término.

3. El bloque de fuentes se desbordaba en celular. Justo en el único dispositivo donde esto se usa.

4. El asistente nunca había leído un manual cargado. Este es el grande, y tardé meses en verlo porque estaba buscándolo en el sitio equivocado. Cuando la respuesta sobre un PDF salía mal, yo culpaba al prompt o al modelo. El problema estaba mucho antes: la extracción agrupaba el texto solo por coordenada vertical, y en una lámina con dos reglas en paralelo —ALINEACIÓN a la izquierda, LIMPIEZA a la derecha, a la misma altura— las fusionaba en la misma línea. El "¿Qué es?" de una quedaba pegado al de la otra. Después, el troceado cortaba ese texto ya revuelto cada 700 caracteres. El modelo nunca recibió el manual; recibió el manual licuado, y ningún prompt arregla eso. Cuando un sistema con IA falla, el instinto es tocar el prompt, porque es la pieza que se ve.

5. Sin API key, el PDF recién cargado se ignoraba por completo. La búsqueda del modo manual solo recorría el conocimiento embebido. El usuario veía su manual en la lista, preguntaba, y recibía respuestas que no salían de él.

6. El filtro de honestidad tiraba justo las respuestas buenas. Salió probando con siete manuales de secciones distintas, y es el reverso del hallazgo 2. Para poder decir "no sé", el modo manual exigía que alguna palabra de la pregunta apareciera literalmente en el fragmento. Pero el manual de Caballero contesta "¿cuánto dejo de pasillo?" con una lámina titulada ALINEACIÓN que dice "dejando 80 cm" y nunca escribe la palabra pasillo. BM25 la encontraba igual, por el diccionario de sinónimos, y la ponía primera — y el filtro la descartaba por no tener coincidencias literales. El puente estaba construido y el filtro no dejaba cruzarlo. Se sumaba que cm, en un manual que es medidas de punta a punta, no era ni siquiera una palabra buscable: el tokenizador descartaba todo lo de dos letras. Las tres formas de preguntarlo fallaban; ahora las tres caen en la lámina correcta.

Relación con Veristack

Es la otra mitad del mismo problema. Veristack verifica con una foto que la exhibición esté bien montada; este asistente ayuda a montarla bien desde el principio. Los dos parten del mismo insumo —el estándar operativo escrito— y comparten el mismo principio: cuando no hay evidencia suficiente, el sistema lo declara en vez de inventarlo.

Desde la pestaña Revisar, una parte de Veristack ya vive aquí: el mismo principio y los mismos cuatro niveles, pero en el teléfono, sin red y con el % vacío medido de verdad (en Veristack era un dato de entrada).

Historia

Nació de una generación anterior del proyecto (2026), construida sobre conocimiento propietario de un cliente. Este repositorio se creó con historia nueva y limpia, deliberadamente: esa historia no debe existir en público. Lo que se publica aquí es la interfaz y la mecánica, con conocimiento de demostración.

Licencia

Código visible, no de uso libre para negocios: PolyForm Noncommercial 1.0.0. Estudiarlo, probarlo y usarlo sin fines comerciales está permitido; cualquier uso por o para una empresa necesita licencia comercial escrita. Detalle en LICENCIA-COMERCIAL.md. Hasta el 5 de octubre de 2026 se publicó con licencia MIT.