Wiki del Sprint 2 del Proyecto Integrador 2. La estructura sigue el documento maestro del Sprint 2 (secciones: Desarrollo de código / MVP, Pruebas automáticas de software, Protocolo de pruebas de usabilidad, Casos de prueba, Backlog y ceremonias, Caso de negocio y Sustentación). Al final se añade una sección propia: Mejoras de la retroalimentación de sprints pasados.

Iterar y profundizar el desarrollo del MVP de Polygon, avanzando de forma substancial en el flujo productivo: consolidar las etapas de Pesaje, Mezcla, el envío a Extrusión y Control de Calidad (incluida la decisión de aprobación, ajuste o reproceso), manteniendo la trazabilidad de cada Orden de Producción (OP) entre etapas y respetando la regla de que una OP no avanza mientras falte información obligatoria de la etapa actual. En paralelo, se cierran las deudas de documentación y consistencia señaladas en la retroalimentación de los Sprints 0 y 1.

Durante el Sprint 2 se trabajó sobre el flujo de ejecución del proceso productivo (épicas EP-02, EP-03, EP-04 y EP-05), avanzando la cadena Mezcla → Extrusión → Control de Calidad. Las nueve historias de usuario comprometidas en el Sprint 2 (según el GitHub Project "Backlog Polygon", filtro sprint:"Sprint 2"), con su número de issue y su estado verificado en el repositorio, son:

Mejora adicional de interfaz: se implementó una leyenda de notación de colores de las OP para facilitar la identificación de las clasificaciones Proceso normal, Urgente y Acompañamiento de IP. Esta mejora está documentada en el PR #59 y cuenta con dos pruebas automáticas de componente. Su identificador en el backlog está pendiente de confirmación, ya que HU-03 corresponde a Recuperar contraseña.

En HU-21/HU-22/HU-23, el operario de Mezcla ve su cola, registra el alistamiento y los turnos de mezcla, y el supervisor envía la OP al siguiente proceso de su ruta (Extrusión o directo a Calidad) validando que el turno esté cerrado y el destino autorizado. En HU-24/HU-25, el operario de Extrusión registra el despeje de línea y los turnos (con carta de procesos) y el supervisor finaliza y envía a Control de Calidad. En HU-26/HU-27, el inspector de Calidad recibe la OP, registra el resultado de la inspección y la aprueba (pasa a Empaque), pide un ajuste o la envía a reproceso.

Regla de proceso: el sistema valida que la información obligatoria de cada etapa esté completa antes de permitir el avance de la OP. Por ejemplo, el envío de Mezcla a Extrusión exige el cierre de los turnos y un destino autorizado.

Las funcionalidades se encuentran implementadas en el repositorio y cuentan con pruebas automáticas asociadas. Los resultados de las pruebas y las evidencias de validación se documentan en las secciones correspondientes de esta Wiki.

• Control de versiones (Git): el trabajo se organizó en ramas por historia de usuario (feature/hu-XX-...), integradas a main mediante pull requests revisados. El historial del repositorio conserva los merges de cada HU del Sprint.

• Contenido del repositorio: el repositorio contiene el código del MVP (frontend en Vue 3 + Vite, backend en Django REST con PostgreSQL). El flujo entregado en este Sprint (Mezcla, Extrusión y Control de Calidad) está presente en las apps Backend/apps/mezcla, Backend/apps/extrusion y Backend/apps/calidad, y en Frontend/src/views/mezcla, Frontend/src/views/extrusion y Frontend/src/views/calidad.

• Convención de commits: se usa un estilo convencional (feat, fix, chore) con el identificador de la HU cuando corresponde, lo que facilita la trazabilidad entre commit e historia de usuario.

• Trazabilidad del backlog: cada HU se asocia a su issue del GitHub Project "Backlog Polygon" (#16, #22, #29–#35) y a sus pull requests

El proyecto adopta una estrategia de pruebas automáticas en dos capas. En el frontend, con Vitest + @vue/test-utils (estándar del ecosistema Vite/Vue 3 ya usado en el repositorio), ejecutadas en modo de una sola corrida (npm run test, equivalente a vitest --run). En el backend, con las pruebas de Django/DRF (APITestCase), ejecutadas con python manage.py test. Ambas son aptas para integración continua y se corren en el workflow de CI (sección 2.4). La estrategia complementa las pruebas manuales (casos de prueba de la sección 4): las automáticas protegen la lógica, los permisos y el render de las funcionalidades, y las manuales se enfocan en la usabilidad y el recorrido humano.

Nota de alcance: en este Sprint se implementaron las dos pruebas automáticas de la leyenda de colores en el frontend (ver 2.2) y, en el backend, las pruebas de Django/DRF que cubren el flujo de Mezcla, Extrusión y Control de Calidad (HU-21 a HU-27), además de las suites previas de Pesaje y Producción. El inventario estático de métodos de prueba del backend se detalla en 2.3.

La funcionalidad de software entregada en este Sprint que es un componente de interfaz (la leyenda de colores de las OP) está cubierta por dos pruebas automáticas, cumpliendo la regla del documento maestro (happy path + flujo alternativo):

1. Happy path — "renderiza las tres clasificaciones con su etiqueta y su color de Badge": monta el componente y verifica que aparecen las tres clasificaciones (Proceso normal, Urgente, Acompañamiento de IP), cada una con su color (gris, ámbar, azul).
2. Flujo alternativo — "deriva colores y textos de la fuente de verdad y describe la hoja normal sin entrada en HOJA_OP": verifica que los colores provienen de las constantes compartidas y que la hoja blanca se describe aunque no tenga franja, sin romper el render.

Resultado registrado de la ejecución de las pruebas automatizadas (Vitest):

 ✓ src/components/produccion/__tests__/LeyendaColoresOP.spec.js (2 tests)
   ✓ renderiza las tres clasificaciones con su etiqueta y su color de Badge
   ✓ deriva colores y textos de la fuente de verdad y describe la hoja normal sin entrada en HOJA_OP

 Test Files  1 passed (1)
      Tests  2 passed (2)

Archivo de la prueba: Frontend/src/components/produccion/__tests__/LeyendaColoresOP.spec.js.

Evidencia de integración continua: GitHub Actions - CI.

Esta sección consolida el inventario de pruebas automáticas del backend Django/DRF y la tabla maestra Funcionalidad | Tipo de Prueba | Justificación, identificando las funcionalidades cubiertas y los escenarios de Happy Path y Flujo Alternativo.

Este documento inventaría, aplicación por aplicación del backend Django/DRF, el estado de las pruebas automáticas del proyecto Polygon y consolida, en una tabla de tres columnas (Funcionalidad, Tipo de Prueba, Justificación), qué funcionalidades están cubiertas y cuáles quedan pendiente de completar.

Fecha de la auditoría: 2026-10-14.

El estado aquí registrado proviene de la revisión directa del repositorio: cada afirmación sobre el estado de pruebas de una aplicación se respalda con la ruta relativa del archivo que la sustenta. El conteo de métodos se obtuvo contando las definiciones def test_ por archivo. Esta cifra corresponde al inventario estático del código y no equivale al resultado de una ejecución de la suite; los resultados de ejecución y la cobertura se documentan por separado y únicamente con evidencia verificable.

Se auditan las aplicaciones del backend presentes en Backend/apps/. Cada entrada indica si cuenta con pruebas automáticas, el número de métodos test_ identificados y la ruta que lo respalda.

Resumen de la auditoría:

• Total de aplicaciones auditadas: 11.
• Métodos test_ identificados en el backend (inventario estático): 183.
• Pruebas automatizadas de componente en el frontend: 2 (LeyendaColoresOP.spec.js).
• Las aplicaciones empaque, picking, picky y reportes cuentan únicamente con pruebas estructurales (3 métodos cada una), que no acreditan por sí solas cobertura funcional de Happy Path y Flujo Alternativo.

• La columna Tipo de Prueba toma los valores Happy Path o Flujo Alternativo. Las funcionalidades sin alguno de los dos caminos se marcan como pendiente de completar.
• La columna Justificación relaciona cada prueba con la Historia de Usuario o el Caso de Prueba correspondiente y cita el archivo y método que la respalda.
• El inventario estático identifica 183 métodos test_ en el backend.
• La cobertura porcentual del código queda pendiente de confirmación mediante un reporte verificable de coverage.

Las siguientes aplicaciones no cuentan con pruebas funcionales identificadas durante la auditoría. Su inclusión en el inventario permite reconocer las áreas pendientes de cobertura y diferenciarlas de las funcionalidades implementadas durante el Sprint 2.

Nota: las aplicaciones extrusion, hoja_azul y picky no se incluyen en esta tabla porque cuentan con pruebas automatizadas identificadas en el repositorio. En el caso de picky, las pruebas existentes son estructurales y no acreditan por sí solas cobertura funcional de Happy Path y Flujo Alternativo.

Esta sección registra los resultados de las pruebas automatizadas del backend Django/DRF, diferenciando las ejecuciones documentadas del inventario actual de métodos de prueba.

Ejecución registrada en la documentación:

• Comando: python manage.py test en Backend/ (utilizando el intérprete del entorno virtual del repositorio).
• Fecha registrada: 2026-10-13.
• Resultado documentado:

Found 137 test(s).
Creating test database for alias 'default'...
System check identified no issues (0 silenced).
----------------------------------------------------------------------
Ran 137 tests in 8.799s

OK

Destroying test database for alias 'default'...

• Código de salida registrado: 0.

El resultado anterior corresponde a una ejecución documentada de 137 pruebas, finalizada con el veredicto OK. Se conserva como antecedente, pero su salida original debe respaldarse con la evidencia de ejecución correspondiente.

Estado actual del inventario:

La auditoría del repositorio realizada el 2026-10-13 identificó 162 métodos de prueba en el backend, incluyendo pruebas en aplicaciones que no estaban correctamente representadas en la documentación anterior.

Esta cifra corresponde al inventario estático de métodos y no constituye, por sí sola, evidencia de que los 162 métodos hayan sido descubiertos y ejecutados exitosamente por Django.

Evidencias:

• Integración continua: GitHub Actions - CI.

La integración continua permite comprobar el estado de los controles automatizados configurados en el repositorio. Las cifras de pruebas ejecutadas y de cobertura porcentual se reportarán únicamente cuando se disponga de sus resultados verificables.

Se añadió un workflow de GitHub Actions en .github/workflows/ci.yml (nombre CI) que se dispara en cada pull request hacia main y ejecuta dos jobs en paralelo:

Ningún paso usa continue-on-error: cualquier paso con código de salida distinto de cero marca la ejecución como fallida. El workflow tiene configurados los siguientes parámetros:

• Umbral mínimo de cobertura: 0 % (--fail-under=0).
• Nivel de severidad de npm audit: high.
• Tiempo máximo por job: 15 minutos.

Estos controles permiten identificar errores automáticamente durante la integración continua.

Protección de rama: actualmente, la rama main no tiene configuradas verificaciones de estado obligatorias para permitir el merge. Aunque GitHub Actions ejecuta las validaciones automáticas, estas no bloquean por sí solas la integración de cambios. Queda pendiente configurar la protección de rama para exigir que los jobs backend y frontend finalicen correctamente antes de aprobar un merge.

Evidencia del CI: Ejecución exitosa en GitHub Actions.

Evidencia visual:

• Backend: ruff check . termina sin hallazgos (All checks passed!). Se corrigieron 51 hallazgos previos (líneas largas, imports desordenados, if/with anidados, un import duplicado) en apps/mezcla y apps/produccion.
• Frontend: eslint . termina sin hallazgos. Se resolvieron los hallazgos preexistentes que quedaban pendientes en src/router/index.js (claves duplicadas por un conflicto de merge) y en src/views/mezcla/RegistroMezcla.vue.
• Seguridad: bandit -r apps termina con 0 hallazgos; el único positivo (una credencial de prueba en apps/usuarios/tests.py) se justificó y suprimió con # nosec B105 por ser un valor exclusivo de pruebas. En el frontend, npm audit se ejecuta como parte del job frontend.
• Dependencias de desarrollo: se añadió Backend/requirements-dev.txt con coverage y bandit (versiones fijadas), separadas de las dependencias de ejecución.

El documento maestro indica que en el Sprint 2 solo se planean las pruebas de usabilidad; su ejecución es en el Sprint 3. Esta sección queda completamente planeada.

Evaluar la usabilidad del prototipo de Polygon con usuarios finales (operarios y personal de planeación de Sumicolor), para verificar que la aplicación es eficaz, eficiente y satisfactoria en el registro del proceso productivo y en la lectura del estado de las OP.

Este objetivo responde a los requisitos no funcionales definidos en el Sprint 0 (docs/context/SprintsWiki/Sprint0_Proyecto2_Sumicolor.md): RNF-06 Usabilidad (interfaz minimalista, pocos clics, botones grandes, colores distinguibles, navegación simple), RNF-07 Accesibilidad (tipografía grande, alto contraste, iconografía clara, mensajes sencillos, formularios simples) y RNF-08 Compatibilidad (computadores de escritorio, tabletas Android, Chrome y Edge).

El sistema está diseñado para operarios de planta con distintos niveles de experiencia tecnológica y para personal de planeación. El Sprint 0 justifica las decisiones de diseño (SPA, interfaz intuitiva, RNF-06/07) por este perfil: trabajadores que antes registraban el proceso en papel y cuya curva de aprendizaje debe minimizarse (docs/context/SprintsWiki/Sprint0_Proyecto2_Sumicolor.md, Planteamiento del problema y justificación del Frontend SPA).

Criterios de reclutamiento del participante objetivo:

El Sprint 0 describe el perfil como "operarios de planta con distintos niveles de experiencia tecnológica" y motiva RNF-06/07 con ese perfil; el rango de edad concreto (mayores de 50 años) es la interpretación del equipo para efectos de reclutamiento. Confirmar la distribución real de edades y experiencia por rol con el Product Owner.

• Lugar: instalaciones de Sumicolor S.A. (estación con computador/tablet de planta).
• Fecha prevista: Sprint 3.
• Duración estimada: 30-45 minutos por participante.
• Flujo de la sesión: (1) adecuación del equipo, (2) contextualización del usuario, (3) ejecución de tareas con preguntas, (4) agradecimiento y cierre.

Alcance de la ejecución en el Sprint 3: las tareas probables se limitan a las etapas con funcionalidad entregada (Pesaje, Mezcla y envío a Extrusión) más la lectura del estado y la leyenda de colores de las OP (sección 1.1). Las etapas aún no entregadas (Picking, Calidad, Empaque) se incorporarán al protocolo cuando su funcionalidad esté disponible, siguiendo este mismo formato.

• Computador portátil o tablet Android con la aplicación Polygon abierta en navegador (Chrome/Edge).
• Herramienta de grabación de pantalla y de voz (previa autorización del participante).
• Formato de observación impreso o digital para registrar tiempos y errores.

Cada hipótesis parte de una decisión de diseño (RNF del Sprint 0 o regla de negocio del flujo entregado) y tiene una tarea observable alineada con un objetivo real del rol, al menos una pregunta y criterios medibles (tiempo, tasa de éxito, número de errores, satisfacción 1-5). Las tareas se limitan a las etapas con funcionalidad entregada en el Sprint 2 (ver 3.4).

Hipótesis 1 — El usuario distingue sin ayuda las OP normales, urgentes y de acompañamiento por el color de su hoja.

• Decisión de diseño: leyenda de colores con colores fácilmente distinguibles (RNF-06) y la mejora de notación de colores entregada en el Sprint 2 (sección 9.3).
• Rol/objetivo real: cualquier operario que consulta el listado necesita priorizar las OP según su clasificación.
• Tarea: identificar en el listado una OP urgente, una normal y una de acompañamiento de IP.
• Pregunta (después): ¿qué significa cada color y dónde consultó la notación?
• Criterios: tasa de éxito >= 90 %; sin ayuda del facilitador; satisfacción >= 4/5.

Hipótesis 2 — El operario encuentra y registra el proceso de Mezcla sin ayuda externa.

• Decisión de diseño: navegación simple y formularios sencillos (RNF-06/07) para el registro de la etapa de Mezcla (HU-22).
• Rol/objetivo real: el operario de mezcla consulta la orden y registra el proceso de mezclado (Sprint 0, "Personal de Mezcla").
• Tarea: registrar un turno de mezcla con datos válidos y confirmar que la información queda guardada correctamente.
• Pregunta (antes): ¿dónde cree que debe registrar el proceso de Mezcla?
• Criterios: completa la tarea en < 5 min; <= 1 error de navegación.

Hipótesis 3 — El usuario comprende el estado y la etapa de una OP con solo mirar la pantalla.

• Decisión de diseño: interfaz minimalista con información de estado clara (RNF-06) y trazabilidad visible de la OP (RNF-05).
• Rol/objetivo real: cualquier rol necesita saber en qué etapa está la OP y qué sigue, para dar continuidad al proceso.
• Tarea: dado el detalle de una OP, explicar en qué etapa está y cuál es el siguiente paso.
• Pregunta (después): ¿la información en pantalla fue suficiente? ¿Qué faltó?
• Criterios: explica correctamente etapa y siguiente paso en >= 80 % de los casos.

Hipótesis 4 — El operario de Pesaje completa el registro y envía la OP a supervisión sin bloqueos inesperados.

• Decisión de diseño: validación de campos obligatorios que impide avanzar con datos incompletos, con mensajes sencillos (RNF-07); flujo de pesaje y envío a supervisión (HU-19, HU-20).
• Rol/objetivo real: el operario de pesaje registra las condiciones del proceso y el avance de las materias primas; el sistema no permite enviar la OP si falta información obligatoria (Sprint 0, "Personal de Pesaje").
• Tarea: confirmar la recepción de la OP, completar el formulario correspondiente, marcar las materias primas como Pendiente, Pesando o Pesado y enviar el registro a supervisión.
• Pregunta (después): ¿el sistema le indicó con claridad qué faltaba cuando intentó avanzar?
• Criterios: completa la tarea en < 6 min; comprende los mensajes de validación.

Hipótesis 5 — Los mensajes de error al ingresar datos inválidos son claros y accionables.

• Decisión de diseño: mensajes sencillos y accionables (RNF-07) sobre las validaciones de los formularios.
• Rol/objetivo real: cualquier operario que diligencia un formulario necesita corregir datos sin ayuda cuando el sistema los rechaza.
• Tarea: intentar enviar un registro con un campo obligatorio vacío o un valor fuera de rango.
• Pregunta (después): ¿el mensaje le dijo qué salió mal y cómo corregirlo?
• Criterios: identifica la causa del error sin ayuda en >= 80 % de los casos.

Hipótesis 6 — El usuario recorre el flujo entre etapas (Pesaje -> Supervisión -> Mezcla -> Extrusión/Calidad) sin perderse.

• Decisión de diseño: navegación simple entre etapas (RNF-06) y la regla de que una OP solo avanza al completar la información obligatoria y recibir las autorizaciones correspondientes (HU-20, HU-23).
• Rol/objetivo real: la OP recorre las etapas y cada rol debe continuar el proceso sin confundir su etapa con otra.
• Tarea: seguir una OP a través de las etapas disponibles, incluyendo la aprobación de supervisión y el destino autorizado después de Mezcla.
• Pregunta (después): ¿en algún punto dudó sobre a dónde ir? ¿En cuál?
• Criterios: completa el recorrido sin retrocesos innecesarios; satisfacción >= 4/5.

Las mismas cuatro métricas se registran en todas las tareas para poder comparar resultados entre hipótesis:

Los umbrales por hipótesis están propuestos arriba; el equipo y el Product Owner los confirman antes del Sprint 3.

Cada caso de prueba (CP) se deriva de los criterios de aceptación de su HU o de una mejora funcional entregada. La columna Resultado registra el estado de la ejecución manual. Los casos se marcarán como Aprobado/Fallido una vez ejecutados y documentados con su respectiva evidencia.

Para la evidencia visual de cada CP, el equipo adjunta la captura correspondiente en el ítem del CP dentro de la herramienta de gestión:

Durante la ejecución de los casos de prueba del Sprint 2 no se registraron bugs bloqueantes sobre el flujo entregado (Pesaje, Mezcla y envío a Extrusión). Los ajustes menores detectados durante el desarrollo se resolvieron dentro de las mismas ramas de las HU antes del merge (por ejemplo, el fix de validación de cierre de mezcla y destino autorizado en HU-23).

Para los bugs que se encuentren a futuro, el equipo abre un issue en GitHub con el siguiente formato, de modo que cada hallazgo quede como issue y no como captura suelta:

### Título
Descripción breve y clara del bug.

### Descripción
Contexto del problema y módulo afectado.

### Pasos para reproducir
1. ...
2. ...
3. ...

### Resultado esperado
Comportamiento correcto esperado.

### Resultado obtenido
Comportamiento real observado.

### Severidad
Crítica / Alta / Media / Baja

### Evidencia
Captura o enlace al issue / PR relacionado.

El backlog del producto se gestiona en el GitHub Project "Backlog Polygon" (board creado desde el Sprint 0). Para el Sprint 2 se trabajaron nueve HU del flujo de ejecución y de administración/planeación. Las columnas del board (Title, Assignees, Status, Linked pull requests) permiten rastrear cada HU hasta su PR.

Estado de las HU del alcance del Sprint 2 al cierre, según el board (filtro sprint:"Sprint 2") y verificado contra el código el 2026-10-14:

Evidencia del backlog:

Durante el Sprint 2, el equipo Polygon realizó una reunión interna de seguimiento para revisar los avances del proyecto, compartir retroalimentación y discutir actualizaciones relacionadas con el flujo del sistema.

• Fecha: 13 de octubre de 2026.
• Horario: 3:02 p. m. – 4:05 p. m.
• Duración: 1 hora, 3 minutos y 40 segundos.
• Modalidad: Virtual, mediante Microsoft Teams.
• Participantes: Integrantes del equipo Polygon.

• Revisión de los avances del desarrollo del proyecto.
• Retroalimentación interna entre los integrantes del equipo.
• Discusión de actualizaciones y ajustes en el flujo del sistema.
• Seguimiento del estado general del Sprint 2.

La reunión permitió revisar el progreso del Sprint 2, compartir observaciones sobre las funcionalidades desarrolladas e identificar aspectos del flujo del sistema que requerían seguimiento o ajustes.

Este espacio de trabajo facilitó la comunicación entre los integrantes y la coordinación de las actividades relacionadas con el desarrollo del MVP.

Se cuenta con el registro de la reunión realizada mediante Microsoft Teams, incluyendo su fecha, duración y disponibilidad de grabación y transcripción.

Resumen de la actualización del caso de negocio para el Sprint 2:

• Problema: el seguimiento de las OP en papel dificulta la trazabilidad y el flujo de información entre áreas de Sumicolor.
• Solución (incremento del Sprint 2): digitalización de las etapas de Pesaje y Mezcla, con control de avance entre etapas y notación visual de prioridad de las OP (colores de hoja). Esto permite reducir el riesgo de errores de traspaso manual y da visibilidad del estado de cada orden.
• Valor aportado en este Sprint: menor riesgo de pérdida de información en las etapas intermedias del proceso y lectura más rápida de la prioridad de una OP (urgente / normal / acompañamiento).
• Actualización respecto a la versión anterior: se confirma PostgreSQL como única base de datos del sistema (ver sección 9.1), corrigiendo la inconsistencia tecnológica identificada en la documentación de sprints previos.

• Para el cliente: review tipo pitch con el sprint goal, los avances (flujo Pesaje/Supervisión/Mezcla/Extrusión o Calidad, leyenda de colores) y las deudas (pruebas de usabilidad para el Sprint 3 y protección de la rama principal).
• Para el profesor: demo del MVP (flujo entre etapas), resumen del caso de negocio actualizado, resumen del protocolo de usabilidad planeado y demo técnica de las pruebas automáticas.
• Logística: fecha: 14/10/2026 hora: 2:30 pm
  asistentes de la sustentación: Profesora Liliana - Equipo SUMICOLOR X EAFIT - PO SUMICOLOR

NOTA: Pendiente por confirmar nueva fecha de sustentación debido a problemas de fuerza mayor.

Esta sección recoge el cierre de las deudas señaladas por los profesores en la retroalimentación de los Sprints 0 y 1.

La retroalimentación detectó una inconsistencia: parte de la documentación mencionaba "SQL Server" mientras que el sistema usa PostgreSQL (verificado en el código: settings.py con el motor django.db.backends.postgresql y psycopg2-binary en las dependencias).

• Se identificaron las menciones a SQL Server que deben actualizarse a PostgreSQL conservando el sentido del texto (glosario, tabla de participantes y requisito funcional RF-08 de la wiki del Sprint 0; descripción de la inconsistencia en el resumen del proyecto).
• Verificación: el código y la configuración del sistema utilizan PostgreSQL.

La retroalimentación pedía criterios de aceptación más completos. El backlog del proyecto documenta las HU con criterios de aceptación que contemplan el flujo principal, los errores de la aplicación y los caminos alternativos, junto con las tareas técnicas correspondientes, agrupadas por épica (EP-01 a EP-08) y gestionadas mediante GitHub Project.

La retroalimentación del Product Owner señaló que la notación de colores de las órdenes no era clara para el usuario. Se incorporó una leyenda visible en la vista de Órdenes de Producción que explica las tres clasificaciones (hoja blanca/normal, amarilla/urgente, azul/acompañamiento de IP), reutilizando la misma fuente de verdad que las cards para que nunca se contradigan. Está cubierta por dos pruebas automáticas (sección 2.2).

Para atender la observación de que las ceremonias y pruebas quedaban documentadas de forma muy resumida, se adoptaron formatos individuales y trazables:

• Actas por ceremonia (sección 6), una por Planning, Daily, Review y Retrospectiva.
• Bitácora de casos de prueba que relaciona cada CP con su HU y su resultado (sección 4.1).
• Reporte de bug como issue de GitHub, no como captura suelta (sección 4.2).
• Protocolo de pruebas de usabilidad completamente planeado (sección 3).

La retroalimentación pedía una estrategia de pruebas automáticas. Se incorporó el runner Vitest + @vue/test-utils al frontend, con la regla de mínimo 2 pruebas por funcionalidad (happy path + flujo alternativo), y se dejó documentada la estrategia por funcionalidad (sección 2).

En este Sprint se amplió el alcance para cerrar también la deuda de aseguramiento de calidad:

• Backend con pruebas Django/DRF: se auditaron las diez aplicaciones y se completaron los archivos de prueba faltantes; la suite cuenta con pruebas funcionales y verificaciones estructurales por aplicación. Los resultados de ejecución se documentan en la sección 2.3.
• Integración Continua: .github/workflows/ci.yml ejecuta pruebas, análisis estático (ruff, eslint), cobertura y seguridad (bandit, npm audit) en cada PR (sección 2.4).
• Análisis estático sin hallazgos: se corrigieron los hallazgos preexistentes de ruff (backend) y eslint (frontend), incluidos los que la propia wiki señalaba como pendientes en src/router/index.js y src/views/mezcla/RegistroMezcla.vue (sección 2.5).
• Protección de rama pendiente: el workflow de CI está configurado y cuenta con una ejecución exitosa. Queda pendiente activar la protección de main para impedir el merge cuando las verificaciones obligatorias no se hayan completado correctamente.