Contribución individual
Eduardo Javier García López
Cliente de interacción: presencia local, texto y voz, estados del avatar, consulta con evidencia admitida y abstención, recuperación, limpieza al cerrar, pruebas y documentación del módulo.
Proyecto PAP · ITESO · Otoño 2026
Tótem DESI:
cliente de
interacción.
Una visita anónima, con texto o voz en español, evidencia admitida y limpieza al cerrar.
Eduardo desarrolló su interacción y estados visibles.
Alcance
Este sitio presenta el desarrollo académico de Eduardo. El cliente del tótem es un prototipo: no hubo usuarios reales, despliegue institucional, caso base ni impacto medido.
01 / Explicación técnica
El proyecto, en menos de tres minutos.
Del inicio de una visita a la respuesta con evidencia y al cierre de la pantalla.
Descargar video MP4 También disponible con subtítulos en español.
Leer la transcripción del video
1. El problema y el objetivo
Eduardo Javier García López desarrolló el cliente de interacción del tótem DESI para orientar sobre dudas del PAP. El reto fue recibir preguntas en un espacio compartido, responder con respaldo y evitar que la siguiente persona vea la conversación anterior.
2. La arquitectura
El sistema se divide en dos módulos. El cliente de interacción de Eduardo controla la visita y la interacción. Fernando Ramos desarrolló el módulo de conocimiento: documentos, permisos, APIs y consola de administración. El navegador se conecta a un servicio local en la Mac; las credenciales permanecen en ese servicio.
3. Presencia, voz y avatar
La detección local de rostros indica presencia, sin identificar a la persona. El cliente recibe texto o voz en español y muestra estados mediante un avatar. El reconocimiento de voz depende de las APIs del navegador y puede usar servicios externos. Al perder presencia, cancela; aplica limpieza al cerrar cada visita.
4. Evidencia admitida, abstención y auditoría
Antes de generar, consulta el módulo de conocimiento. Solo incorpora evidencia admitida. Si falta, responde con abstención sin llamar al modelo. Después valida el formato y las citas mediante reglas en código, y vincula el resultado con la auditoría. Una salida inválida es un fallo, no una respuesta exitosa. También conserva un registro local para recuperar operaciones interrumpidas sin repetir una generación cuyo resultado todavía es incierto. La limpieza de pantalla no borra esa auditoría.
5. Verificación y límites
Pasaron 135 de 135 pruebas en Node.js 22.16.0 y 26.13.0, en la misma Mac M4: dos ejecuciones del mismo conjunto, no 270 casos. Se usaron componentes simulados para generación y dispositivos, además de archivos reales y servidores locales. El ensayo real tuvo tres llamadas a OpenAI con información sintética; una terminó en abstención por causa desconocida. El costo estimado fue USD 0.0003436, sin facturación conciliada. La prueba física fue parcial, con un solo rostro. Estos niveles de evidencia no se suman ni prueban desempeño general.
6. Cierre
El resultado es un cliente que integra presencia, voz y avatar con evidencia admitida, abstención, auditoría y limpieza al cerrar. No hubo usuarios reales, despliegue, caso base ni impacto medido. El siguiente paso es verificar la integración conjunta y después evaluar el sistema con personas en su entorno de uso.
02 / Una visita, de principio a fin
Las reglas críticas permanecen en código.
El modelo redacta a partir de un contexto acotado. La presencia, la admisión de evidencia y la validación de la salida se comprueban de forma determinista.
- 01
Detectar presencia
Un detector local de rostros indica que hay alguien frente a la Mac. No identifica a la persona ni garantiza un conteo completo.
- 02
Escuchar o leer
Texto o voz en español y un avatar con estados de escucha y habla. Las APIs del navegador pueden utilizar servicios externos.
- 03
Admitir evidencia
El cliente consulta el módulo de conocimiento de Fernando y selecciona los fragmentos admitidos antes de generar.
- 04
Validar y cotejar
Comprueba el formato y las citas, y coteja la respuesta con la auditoría antes de mostrarla. Una salida inválida se registra como fallo.
- 05
Limpiar al cerrar
Cancela el trabajo pendiente y retira pregunta, respuesta, conversación, borradores y consentimientos. La auditoría remota se conserva.
Una condición explícita
Sin evidencia admitida,
abstención sin llamar al modelo.
03 / Arquitectura documentada
Dos módulos. Responsabilidades claras.
El navegador y el servicio local de Eduardo dependen del módulo de conocimiento de Fernando. La integración se ensayó en local con un backend temporal.
Cómo leer el diagrama
- Implementado en el cliente
Presencia, interacción, consulta, cotejo de auditoría y recuperación.
- Dependencia de Fernando
Conocimiento, documentos, permisos, persistencia, auditoría, APIs y consola.
- Piloto o ensayo parcial
Proveedor de lenguaje y Solicitudes con datos sintéticos.
- Propuesto, no implementado
Avisos, purga programada, autenticación y acceso alojado.
Las credenciales permanecen en el servicio local, fuera de la interfaz de la persona visitante.
Módulo de conocimiento
Fernando Ramos
Documentos, permisos, persistencia, auditoría, APIs y consola de administración. Sus pruebas, despliegues y resultados no se atribuyen al trabajo individual de Eduardo.
04 / Evidencia de funcionamiento
Qué se verificó.
Y hasta dónde llega.
Ensayos documentados del 11 de noviembre de 2026. Cuatro niveles distintos que no se suman entre sí.
01 / Pruebas automatizadas
135 de 135
La misma suite en dos versiones de Node.js.
Pruebas y compilación en Node.js 22.16.0 y 26.13.0, en la misma Mac M4. Son dos ejecuciones del mismo conjunto, no 270 casos. Generación y dispositivos simulados.
02 / Archivos y servidores locales
Entorno local
Archivos y servicios reales; backend temporal.
Se comprobaron cinco grupos de casos con el módulo de Fernando usando servicios temporales. Presencia y generación estaban interceptadas. Este conjunto no se suma a las 135 pruebas.
03 / Proveedor real de lenguaje
3 llamadas
OpenAI real, información sintética.
Una llamada terminó en abstención por causa desconocida. El costo estimado fue de USD 0.0003436, sin facturación conciliada. No es una tasa de fiabilidad ni un costo de operación validado.
04 / Observación física
1 rostro
Una prueba parcial en Chrome.
Se observó detección, síntesis de voz audible e interrupción al cerrar. No se midieron exactitud ni latencia; faltan varias personas y distintas condiciones de luz, distancia y ruido.
Límites del prototipo
El siguiente paso es validar la integración y el uso.
No hubo usuarios reales, despliegue institucional, caso base, impacto medido ni aceptación institucional. La publicación de esta página no cambia el estado del cliente.
Las citas de evidencia admitida no prueban por sí solas la calidad semántica general de las respuestas.
Quedan pendientes el acceso alojado, pruebas físicas más amplias, el destino y la entrega de avisos, la retención programada y la autenticación de estudiantes.
Más sobre voz, recuperación y cancelación
La voz depende de las APIs del navegador y puede requerir un proveedor externo: no es una solución completamente local. La recuperación necesita conservar el identificador de la operación, que la interfaz pierde al recargar. Una escritura remota puede persistir aunque el cliente cancele; dos cancelaciones reportadas por Fernando no se reprodujeron y no se dan por resueltas.
05 / Material técnico
Para revisar el trabajo con más detalle.
Póster y láminas de la explicación técnica. El reporte individual completo no se publica en este sitio.