Correcciones y Mejoras — Piloto Trento

Reporte generado desde correcciones-y-mejoras.md · FTL Trace

Correcciones y Mejoras — Piloto Trento

Fuente: Meet del 2026-05-15 — Revisión del workflow de trazabilidad FTL Trace Participantes: Franco Cedillo (arquitecto), Andrés Linares (dev), Dennis Vivas (negocio) Feedback escrito: Yemima (Trento) Deadline piloto: fin de mayo 2026 (~2 semanas desde el meet)

Resumen ejecutivo

  • 70% del pliego de Yemima implementado durante la demo (Andrés).
  • 15 correcciones pendientes identificadas (resueltas durante o antes del meet omitidas). Ninguna de severidad alta vigente; 2 bloqueantes (B1, B2), 11 medias, 2 bajas.
  • 13 mejoras / features nuevas propuestas, evaluadas por impacto/costo.
  • Estimación total con asistencia IA (Claude Code): ~6–8 h de desarrollo real (factor observado ~1/5 del estimado humano tradicional de ~35–45 h). Distribuido entre Franco (backend, asistido por IA) y Andrés (app móvil) en las 2 semanas restantes — con holgura amplia.
  • Convención de estimaciones: todas las cifras en este documento son tiempos con asistencia IA. Tareas que no son código (comunicaciones, reuniones, esperas físicas) se marcan con (†) y mantienen el tiempo humano original.

Decisiones cerradas en el meet

  1. Iteración semanal incremental, no megalanzamientos.
  2. CP1 final: solo 2 campos (peso_partida + peso_rechazado_partida). Eliminar campos por rollo cuando Trento monte balanza de plataforma.
  3. Etiquetas: rediseño para impresora 3" (antes 4"×2", ahora 3"×2"), estilo "Steam" horizontal — kg + partida grandes, QR pequeño a la derecha, OP visible, GS1 compliant.
  4. Conformidad CP3 (lavado externo): dropdown 2 opciones (Conforme / No conforme); si "No conforme" → campo texto libre.
  5. Energía CP5/CP6: 100% IoT, eliminar campo manual de UI.
  6. Producto multi-cliente: no construir features Trento-específicas sin toggle/config (WTS, Peter Millar, Habitat, San Ramón en pipeline).
  7. Validación de cantidades: candado backend (no más prendas que el total del lote) — ya implementado.
  8. Cobertura demo: ~70% del pliego de Yemima implementado.

Parte 1 — Correcciones pendientes (15)

Ordenadas por severidad de mayor a menor. Resueltas durante el meet o antes (C8, C11, C13–C16 del reporte original) omitidas.

blocker Bloqueantes — entran al piloto sí o sí

Nota sobre estimaciones: todas las estimaciones están ajustadas al factor ~1/5 observado al implementar con asistencia IA (Claude Code). Las que no son trabajo de código (comunicaciones, reuniones, esperas físicas) mantienen su tiempo original — marcadas con (†).

# Descripción Módulo Reportó Asignado a Estimación Status
B1 QLever (CP3) — sin integración, sin datos. Responder a Yemima aclarando que es dependencia externa. Definir qué data de QLever queremos a futuro (ver "Pendientes con Trento" abajo). Mientras: aceptar entrada manual en CP3. Backend CP3 + comunicación Trento Andrés / Franco — 1 h (†, comunicación) + decisión scope Todo
B2 Etiqueta para impresora 3" — rediseño completo (antes 4"×2", ahora 3"×2"). Estilo Steam horizontal. GS1 compliant. Bloqueado hasta que lleguen impresoras definitivas. App móvil — impresión Dennis Andrés 50 min – 1.2 h Todo

medium Severidad media

Nota: No hay items de severidad alta pendientes. Los problemas de OCR Gemini reportados (M10/M11) solo se reproducen en ambiente de prueba (fotos de balanzas); con la cámara directamente frente a una balanza real el algoritmo no falla. Por eso se reclasifican como media.

# Descripción Módulo Reportó Asignado a Estimación Status
M1 Header no fijo durante scroll. Hacer fixed o colapsable, fusionando header "FTL Trace" al colapsar. App móvil — UI global Franco Andrés 12–25 min Todo
M2 Identificación de CP en pantalla. En screenshots del cliente no se ve en qué CP estaba. Mostrar CP activo de forma persistente. App móvil — todos los CPs Franco Andrés 12 min (atado a E2 abajo) Todo
M3 Renombrar campo "peso total recibido en kilos" → peso total de la partida recibido en kilos (ambigüedad). Backend + UI CP1 Dennis Franco 6 min Done
M4 Eliminar campos por rollo en CP1 (rollo_defectuoso, peso por rollo) — desplegar cuando Trento confirme balanza. Backend dinámico para Andrés. Backend CP1 Dennis Franco 12–25 min (†, desbloqueo depende de Trento) Todo
M5 CP2 — texto "peso de la tela consumida" ambiguo. Decisión confirmada: es valor real medido en balanza durante el cierre del CP en la app móvil, no viene del ERP. Label aclarado en backend para evitar confusión futura. Backend CP2 Yemima Franco 6 min Done
M6 Dropdown conformidad CP3 (lavado externo). Reemplazar texto libre por dropdown 2 opciones; si "No conforme" → campo texto. Backend ya expone enum: [Conforme, No conforme] + atributo declarativo requerido_si en observaciones_calidad; enum interno recortado de 3→2 valores. Falta integración en app móvil. Backend + App móvil CP3 Yemima Franco (backend) / Andrés (móvil) 25 min Done backend / Todo móvil
M7 CP4 — bolsas vs rumas. Trento pide "rumas". Decidir: reemplazar, coexistir, o configurable por cliente. Impacta generación GS1. Recomendación: configurable vía admin panel (E7) pero por ahora reemplazo simple. Backend + App CP4 Yemima / Andrés Franco (backend) / Andrés (móvil) 25–35 min (config básica) o 1.2–1.5 h (admin panel) Todo
M8 Eliminar campo "energía habilitado" / energía manual de UI en CP5/CP6 (todo IoT). Backend + App CP5/CP6 Dennis Franco 12 min Done (backend; móvil deja de pintarlo automáticamente)
M9 Tipo de dato number_scan en backend — permitir a backend marcar qué campos numéricos son escaneables (mostrar icono cámara). Habilita escenarios sin balanza electrónica (avíos, otras fábricas). Backend marca 10 campos de balanza (peso en kg) con tipo: "number_scan". App móvil debe distinguirlo de "number" para mostrar/ocultar cámara. Retrocompat: si la app aún no lo soporta, lo trata como "number". Backend (modelo campos dinámicos) Andrés Franco (backend) / Andrés (móvil) 6 min (backend) + 12–25 min (móvil) Done backend / Todo móvil
M10 Gemini OCR lee mal balanza con fotos de prueba — reflejos + lee números decorativos (no del display 7 segmentos). Solo se reproduce con fotos de prueba; con cámara directa frente a balanza real no falla. Mitigación: máscara visual + mejora de prompt (ver E4/E5). App móvil — visión CP1 Andrés Andrés 12–25 min Todo
M11 Gemini pareo erróneo en fotos de prueba — lee 28.5 / 2.65 y lo asigna al campo equivocado (peso_rechazado). Mismo contexto que M10 — solo ambiente de prueba. Validar pareo lectura→campo destino. App móvil — CP1 OCR Andrés / Franco Andrés 12–25 min (atado a M10) Todo

low Severidad baja

# Descripción Módulo Reportó Asignado a Estimación Status
L1 Botón "SC" arriba duplica botón "perfil" abajo. Ocultar/reusar espacio. App móvil — header Franco Andrés 6 min Todo
L2 Código de barras COD 128 se ve "feo" / desbordado — interfaz no preparada para anchos grandes. Aceptable para piloto si Data Matrix queda por defecto. App móvil — render Andrés Andrés 12 min o postergar Todo

Parte 2 — Mejoras / Features nuevas (13)

Evaluación de impacto/costo. Costo en tiempo real con asistencia IA (factor ~1/5 sobre la convención humana 1 SP ≈ 1 h). Items con (†) son no-código y mantienen tiempo humano.

# Mejora Módulo Asignado a Impacto piloto Costo Decisión sugerida Status
E1 Feedback in-app — botón que envía sugerencia + screenshot + CP activo + último payload. App + Backend (endpoint nuevo) Franco (backend) / Andrés (móvil) Alto — recoger feedback estructurado de Trento y futuros pilotos. 50 min – 1.2 h Entra al piloto — multiplica la calidad del feedback recibido. Todo
E2 Cinta/banner inferior persistente con CP activo (verde, alineado con header). App móvil UX global Andrés Alto — soluciona M2 de forma estructural. 25 min Entra al piloto (atar con M2). Todo
E3 Tipo number_scan flexible (= corrección M9). Backend Franco Alto — multi-cliente sin recompilar. 6 min Entra al piloto (ya está como M9). Done (backend)
E4 Máscara visual / overlay sobre foto de balanza para guiar a Gemini al display 7 segmentos. App móvil — visión Andrés Medio — sube precisión OCR sin reentrenar (en ambiente de prueba). 6–12 min Entra al piloto (quick win, resuelve M10). Todo
E5 Mejora prompt Gemini — instruir lectura exclusiva de paneles 7 segmentos. Backend / config IA Franco Medio — refuerza E4. 6 min Entra al piloto (quick win, junto a E4). Todo
E6 Web Checkpoint — herramienta interna para probar flujo OCR sin APK / sin balanza física. Backend tooling Franco Medio — acelera debug del equipo. 50 min – 1.2 h Postergar post-piloto — productividad interna, no afecta cliente. Todo
E7 Admin panel — config nombres de campos por cliente (bolsas↔rumas, traducciones por cliente). Backend + Admin panel Franco Alto a futuro — habilita multi-cliente (Peter Millar, Habitat, San Ramón). 2.5–4 h Postergar post-piloto — versión mínima vía M7 por ahora. Todo
E8 Lectura IoT energía al cierre del lote con timestamps continuos. IoT + Backend Franco Alto para PEF — quita carga manual al operario. 1.5–3 h Estado actual: base lista al 2026-04-27 (PRs #361 + #347). Continuar tras correcciones críticas. Todo (parcial)
E9 Rediseño etiqueta Steam-style (= corrección B2). App móvil — impresión Andrés Bloqueante piloto. 50 min – 1.2 h Entra al piloto (ya está como B2). Todo
E10 Data Matrix + alternar con código de barras desde settings locales. App móvil — settings Andrés Medio — adapta a clientes con código barras industrial. 25–35 min Entra al piloto (Data Matrix por defecto ya acordado). Todo
E11 Validación configurable de rangos por campo numérico (ej. kilos entre 5 y 10). Backend (config por cliente) Franco Medio — robustez de datos. 1–1.5 h Postergar post-piloto — Franco lo marcó como futuro. Todo
E12 Pipeline Jenkins APK + levantar app local para test rápido. DevOps — Bajo-medio — productividad interna. 1–2 h Postergar post-piloto — no afecta cliente. Todo
E13 Roadmap producto multi-cliente (WTS, Peter Millar, Habitat, San Ramón) — separar Trento-específico de genérico textil. Estrategia producto Dennis / Franco Alto estratégico — no es trabajo de código. 2 h (†, reunión) Agendar antes del cierre del piloto — input para E7/E11. Todo

Avance de implementación (Done)

Cambios ya aplicados al backend en una única pasada sobre apps/backend/src/api/routers/checkpoints/cp_field_defs.py y archivos relacionados:

M3 — Label CP1 peso_total_recibido_kg

  • cp_field_defs.py CP1: label "Peso total recibido" → "Peso total de la partida recibido".
  • Columna DB (peso_total_recibido_kg) sin cambios — solo el texto expuesto a UI.

M6 backend — Dropdown conformidad CP3

  • cp_field_defs.py CP3: campo conformidad_visual cambia de tipo: "string" libre → tipo: "enum" con opciones: ["Conforme", "No conforme"].
  • Nuevo atributo declarativo requerido_si en observaciones_calidad: json { "campo": "observaciones_calidad", "tipo": "string", "requerido_si": {"conformidad_visual": "No conforme"} } La app móvil debe leer este atributo y exigir el campo dinámicamente cuando se cumpla la condición. Esto generaliza la lógica de "campos condicionales" para futuros checkpoints sin código nuevo en backend.
  • Enum ConformidadVisualEnum recortado de 3→2 valores. Se eliminó conforme_con_obs = "Conforme con observaciones" de src/domain/models/cp3_session.py.
  • Migración alembic 059 (p2q59e059_059_cortar_conformidad_visual.py) — UPDATE sobre cp3_session y lavados para mapear registros legacy "Conforme con observaciones" → "Conforme". Las observaciones permanecen intactas en observaciones_calidad.
  • Tests actualizados: test_cp3_session.py valida 2 valores en lugar de 3.

M8 — Eliminar campo energía manual CP5

  • cp_field_defs.py CP5: eliminada entrada visible energia_habilitado_kwh.
  • Columna DB conservada (la rellenará la integración IoT — ver E8).
  • CP6 no requirió cambios: energia_costura_kwh ya estaba marcado internal: True (no visible en app móvil).

M5 — Clarificar label CP2 peso_tela_consumida_kg

  • Decisión confirmada: el dato es medido en balanza al cierre del CP en la app móvil, no se jala del ERP.
  • Label actualizado a "Peso tela consumida (medido en balanza al cierre del CP)" para evitar confusión futura.
  • Punto 3 de "Pendientes con Trento" eliminado — ya no requiere decisión externa.

M9 — Tipo number_scan (backend)

  • Nuevo tipo: "number_scan" aplicado a 10 campos numéricos medidos en balanza:
  • CP1: peso_total_recibido_kg, peso_rechazado_kg
  • CP2: peso_tela_consumida_kg, peso_panos_cortados_kg, peso_merma_kg
  • CP3: peso_retorno_kg
  • CP4: peso_merma_corte_piezas_kg
  • CP5: merma_avios_kg
  • CP9: peso_total_kg, peso_neto_kg
  • Contrato documentado en docstring de cp_field_defs.py. La app móvil cuando esté actualizada distingue:
  • tipo: "number" → input numérico sin cámara
  • tipo: "number_scan" → input numérico + botón cámara OCR
  • Retrocompat: la app móvil actual puede tratar "number_scan" como "number" sin romperse; falta cambio en móvil para activar el ícono cámara.
  • Campos NO marcados (intencionalmente): conteos (rollos, piezas, bultos, cajas), porcentajes (%), kWh (energía IoT), unidades de operaciones.

Verificación

  • 32 tests CP1/CP3/CP5 + tests cp_field_defs pasan (✓).
  • Diff total: 1 archivo backend modificado (cp_field_defs.py), 1 modelo (cp3_session.py), 1 test (test_cp3_session.py), 1 migración alembic (059).

Parte 3 — Pendientes con Trento / Yemima (para correo de cierre)

Decisiones que faltan resolver con el cliente. Andrés y Dennis acordaron enviar correo.

  1. QLever (CP3) — ¿qué data queremos integrar? Confirmar campos críticos: - Receta de lavado (suavizante, enzimas, temperatura, tiempo) - Peso entrada / peso salida - Batch ID o número de proceso QLever - Fecha/hora de inicio y fin - Operario / responsable - Resultado conformidad (atar con M6) - Sugerencia FTL: pedir export Excel/CSV con esos campos como solución temporal mientras se evalúa integración API.

  2. CP4 bolsas vs rumas — confirmar si Trento acepta "ruma" como reemplazo global o requiere coexistencia con otros clientes.

  3. ~~CP2 peso de tela consumida~~ — Resuelto: dato es manual desde balanza en app móvil, no ERP. Ver M5 en sección "Avance de implementación".

  4. Fecha real de llegada de balanza de plataforma — determina cuándo desplegar M4.

  5. Fecha real de llegada de impresoras 3" — determina cuándo desplegar B2.

Parte 4 — Sprint propuesto para las 2 semanas del piloto

Estimaciones con asistencia IA (factor ~1/5). Items (†) son no-código (comunicación, espera física) y mantienen tiempo humano.

Sprint 1 (semana 18-22 mayo) — Quick wins + bloqueantes blandos

  • ✅ M3 (renombrar campo) — 6 min · Franco — Done
  • ✅ M5 (texto CP2) — 6 min · Franco — Done
  • ✅ M6 backend (dropdown conformidad CP3) — 25 min · Franco — Done
  • ✅ M8 (eliminar energía manual) — 12 min · Franco — Done
  • ✅ M9 backend (tipo number_scan) — 6 min · Franco — Done
  • ⏳ L1 (botón duplicado) — 6 min · Andrés
  • ⏳ E4 + E5 (máscara OCR + prompt) — 12–18 min · Franco + Andrés
  • ⏳ M10 + M11 (Gemini OCR fix) — 25–50 min · Andrés
  • ⏳ E2 + M2 (cinta CP activo) — 25–35 min · Andrés
  • ⏳ M6 móvil (UI dropdown) — 12–25 min · Andrés
  • ⏳ B1 (correo QLever) — 1 h (†) · Andrés / Dennis

Total semana 1 con IA: ~3–4 h (vs ~13 h humano).

Sprint 2 (semana 25-29 mayo) — Estructurales del piloto

  • M9 móvil (icono cámara según number_scan) — 12–25 min · Andrés
  • M1 (header fijo) — 12–25 min · Andrés
  • M7 (bolsas → rumas, versión básica) — 25–35 min · Franco + Andrés
  • E1 (feedback in-app) — 50 min – 1.2 h · Andrés + Franco
  • E10 (Data Matrix toggle) — 25–35 min · Andrés
  • M4 (eliminar campos por rollo) — atado (†) a llegada de balanza · Franco
  • B2 (etiqueta 3") — atado (†) a llegada de impresora · Andrés
  • L2 (COD 128) — 12 min o postergar

Total semana 2 con IA: ~2.5–4 h (vs ~18 h humano) + dependencias externas.

Total piloto con IA: ~6–8 h código + dependencias externas (†). Holgura amplia para iteración con Trento durante el piloto.

Comparativa estimación humana vs realidad con IA: el equipo estimó originalmente ~41 h de desarrollo. Las tareas backend ya implementadas en este sprint (M3, M5, M6 backend, M8, M9 backend) confirman el factor ~1/5, dejando holgura significativa para iteración, debugging en campo, feedback rápido del piloto.

Parte 5 — Verificación end-to-end

Por cada corrección crítica:

  1. B1 (QLever): confirmar email enviado a Yemima; respuesta documentada en docs/.
  2. B2 (etiqueta 3"): imprimir muestra física, validar lectura QR + barcode con scanner real.
  3. M10+M11+E4+E5 (OCR): probar Gemini con 10 fotos reales de balanza Trento, medir precisión antes/después.
  4. M6 (dropdown CP3): flujo end-to-end de operario marcando "No conforme" + texto, verificar persistencia en backend y visibilidad en dashboard.
  5. M9 / E3 (number_scan): verificar que campo number_scan: false no muestre cámara en app, y true sí.
  6. E1 (feedback in-app): Dennis o piloto Trento envían un feedback de prueba; llega con screenshot + CP + payload al endpoint.

Notas operativas (no-código)

  • Coordinar reunión Andrés + Rosa María.
  • Reset password Kenneth (Rosa María).
  • Cargar datos de prueba en Dolibarr (equipo Fintech Lab).
  • Considerar abrir un OpenSpec change si el bloque E7 (admin panel multi-cliente) escala — alcance grande, merece especificación formal.