| name | upstream-pin |
| description | Revisar y adoptar el pull request que abre el vigilante semanal cuando el proyecto oficial clienteafirma publica un tag nuevo. Cubre lanzar los checks a mano (el PR nace sin ellos), verificar el sha256 y las constantes, detectar si la superficie de AutoScript cambió bajo el wrapper, y decidir versión y tag. Úsala ante cualquier PR de rama upstream/*. |
Skill: revisar el PR del vigilante upstream
.github/workflows/upstream.yml corre cada lunes, compara el tag mayor de ctt-gob-es/clienteafirma con autoscript.lock.json y, si difieren, abre un PR que actualiza el pin.
Ese PR nace sin comprobaciones ejecutadas. Es deliberado: se empuja con el GITHUB_TOKEN por defecto, que no dispara workflows, y se descartó introducir un token personal. Lanzarlas es el primer paso de esta revisión, no un descuido.
1. Lanzar los checks a mano
Desde la pestaña Actions, ejecuta el workflow CI sobre la rama del PR. Sin esto no hay ninguna señal automática sobre ese cambio.
2. Verificar que el pin es coherente consigo mismo
gh pr diff <N> -- autoscript.lock.json
Contrasta cada campo contra el origen real, sin fiarte del cuerpo del PR:
TAG=<tag nuevo>
curl -sL "https://raw.githubusercontent.com/ctt-gob-es/clienteafirma/${TAG}/afirma-ui-miniapplet-deploy/src/main/webapp/js/autoscript.js" -o /tmp/nuevo.js
shasum -a 256 /tmp/nuevo.js | cut -d' ' -f1
grep -m3 -E 'var VERSION = |var VERSION_CODE = |var PROTOCOL_VERSION = ' /tmp/nuevo.js
Las tres constantes deben coincidir con el bloque autoscript del lock. El script de empaquetado aborta si no, pero es mejor saberlo aquí.
3. Mirar qué cambió de verdad
El fichero pasa de 200 KB, así que no lo leas entero. Lo que importa es si la superficie pública cambió bajo nuestro wrapper:
api() { grep -oE "^\s+[A-Za-z_]+ : [A-Za-z_]+,?$" "$1" | tr -d ' ' | cut -d: -f1 | sort -u; }
api vendor/autoscript.js > /tmp/api-viejo.txt
api /tmp/nuevo.js > /tmp/api-nuevo.txt
comm -13 /tmp/api-viejo.txt /tmp/api-nuevo.txt
comm -23 /tmp/api-viejo.txt /tmp/api-nuevo.txt
Comprueba después que ninguna operación que usamos esté en la segunda lista:
grep -rhoE "autoScript\.[a-zA-Z]+" src/ | sort -u
Revisa también si cambió el valor de alguna constante que pasemos como parámetro (las CT_* de checkTime, por ejemplo) y si PROTOCOL_VERSION se movió, porque eso afecta a la compatibilidad con la aplicación instalada.
4. Decidir la versión
La regla es el espejo (ADR-0004): package.json debe valer exactamente lo que el campo tag del lock, sin la v. El PR del vigilante no toca package.json, así que si vas a publicar, actualízalo en el mismo PR. El workflow de release comprueba que tag, package.json y lock coinciden, y falla si no.
Ojo con una trampa real de este upstream: los tags no ordenan el contenido. v1.9.1 lleva AutoScript 1.10.1 y v1.9.2, posterior, lleva 1.9.0, porque cuelga de una línea divergente. Que el tag suba no garantiza que el AutoScript empaquetado sea más nuevo. Deja constancia en el PR de qué versión de AutoScript entra realmente.
5. Antes de mezclar
npm run vendor && npm test && npm run typecheck && npx prettier --check .
npm run vendor descargará el fichero nuevo y verificará su huella contra el lock actualizado.
Si la demo usa alguna operación afectada, pruébala a mano con AutoFirma instalada: es el único camino que ha detectado los fallos de contrato de este proyecto.
6. Después de mezclar
El tag lo crea una persona, nunca el agente. Si la adopción del pin va a publicarse, sigue la skill release.
