Ingeniería
Aplicada
Resultados
samuel-torres.com
Rol
Desarrollo backend, arquitectura de plugins WordPress y un pipeline de verificación con IA para un evento en vivo a nivel nacional.
Stack principal
WordPress · 2 plugins PHP personalizados · MySQL · Tesseract OCR · Groq API (LLaMA 3.3 70B) · Cron · VPS AlmaLinux
Contexto
Panini organizó un evento de intercambio de estampas en tiendas de todo México, Panini Fan Zone FWC 2026, que incluía un intento de Récord Guinness al intercambio más grande del mundo. El evento necesitaba un sistema de folios y premios capaz de emitir y controlar un pool fijo de 80,000 folios, verificar los comprobantes de compra enviados sin que una persona los revisara uno por uno, y registrar participantes para el intento de récord sin permitir que el mismo correo se contara dos veces bajo actividades distintas.
Lo que hice
Construí un plugin propio de WordPress (panini-registro) que emite y controla un pool fijo de 80,000 folios, con generación de código QR por cada registro, corriendo en vivo sobre un VPS AlmaLinux.
En lugar de revisión manual, los comprobantes enviados pasan primero por Tesseract OCR y después por un modelo LLaMA 3.3 70B alojado en Groq, que lee y valida el texto extraído contra las reglas de la promoción. El pipeline corre solo, vía cron cada 2 minutos, en producción.
El registro para el intento de récord necesitaba su propia regla de unicidad — una persona, un registro, acotado a esa actividad específica — así que le di su propio esquema de base de datos en vez de reusar la validación del plugin de folios. La primera versión del índice de unicidad validaba el correo de forma global en vez de por actividad, lo que permitía que el mismo correo se registrara dos veces bajo actividades distintas. Migré el esquema a un índice único compuesto acotado a la actividad, agregué una validación que revisa el esquema existente antes de alterarlo, y subí el plugin de v1.1.0 a v1.1.1.
Escribí un script verificador independiente y una suite de 15 pruebas, incluyendo una prueba de concurrencia con 50 workers simultáneos golpeando la misma ruta de registro, para confirmar que exactamente un registro tiene éxito por cupo y cero errores de servidor antes de dar algo por terminado.
Resultado
El sistema de folios y QR corrió en vivo en producción gestionando el pool completo de 80,000 folios, con el pipeline OCR → LLM procesando envíos sin supervisión. El módulo de Récord Guinness pasó su verificador completo (24/24 checks) y su suite de pruebas (15/15) con la migración de esquema ya en su lugar. [POR CONFIRMAR: si las fases de rollout que quedaban pendientes en el último estatus que tengo —confirmación por correo, endpoints del escáner de staff, panel de administración definitivo y hardening final— se completaron después.]
Evidencia del sitio en producción
Capturas reales del sitio en producción y de las herramientas de administración.
Login exclusivo de staff para el módulo de registro del intento de récord.
Estatus de implementación: migración de esquema, bugs encontrados y corregidos, suite 15/15 — puntos 3 y 4.
Página pública de registro para el intento de Récord Guinness.
Nota: la landing pública y la página de registro se capturaron desde una sesión de admin ya iniciada, así que se ve una franja delgada de la barra de WordPress en el borde superior de esas dos imágenes.
Versión corta (card del portafolio)
2 plugins WordPress personalizados, pool de 80,000 folios, generación de QR y un pipeline de verificación con IA (Tesseract OCR → Groq LLaMA 3.3 70B) corriendo vía cron cada 2 minutos — más un módulo aparte de registro para un Récord Guinness, migrado para corregir un bug de registros duplicados y verificado con una prueba de concurrencia de 50 workers. En producción real.
Bullets para CV / LinkedIn
- Construí y entregué un sistema de folios y QR para 80,000 unidades con un pipeline de verificación con IA (OCR + LLM) corriendo sin supervisión cada 2 minutos en producción.
- Diagnostiqué un bug de unicidad global-vs-por-actividad que dejaba pasar registros duplicados en un módulo de Récord Guinness; lo corregí con un índice único compuesto y una migración de esquema con validación (v1.1.0 → v1.1.1).
- Verifiqué seguridad ante concurrencia con una prueba de carga de 50 workers sobre la misma ruta de registro antes de firmar el cierre, confirmando cero registros duplicados o fallidos.