Deploy

Superficies

• Cuatro paquetes publicos se publican en GitHub Packages en orden de dependencia: Brand Contract, UI, Brand Runtime y Brand Studio.
• ui.le-mn.com sirve Docs.
• portal.ui.le-mn.com sirve Catalogo publico y Admin protegido por Access desde el Worker lemn-ui-portal.
• schemas.ui.le-mn.com sirve el contrato de schemas desde el mismo Worker.

La identidad del paquete, commit, provenance/notices/SBOM y deploy deben referir al mismo release aprobado.

Gates

pnpm validate
pnpm check
pnpm test
pnpm build
pnpm audit --prod
pnpm changeset status

Ademas se prueba registry exacto, una implementacion activa por capacidad, installs limpios, conformance aplicable, dry-runs de Cloudflare, credenciales least-privilege, rutas publicas/protegidas, assets Admin protegidos, identidad del build y recovery. No se reutiliza evidencia de otro commit.

GitHub Actions publica paquetes con su job token. Las credenciales Cloudflare se resuelven solo dentro del Environment protegido de produccion, usan nombres UI_PORTAL y tienen scope exacto para Worker, dominios, Access y acciones requeridas. Tokens, account keys, headers y secretos nunca entran en archivos, args, artifacts, logs ni documentacion.

Los inputs exactos del Environment protegido son PRODUCTION_CLOUDFLARE_API_TOKEN, PRODUCTION_UI_PORTAL_ACCESS_CLIENT_ID y PRODUCTION_UI_PORTAL_ACCESS_CLIENT_SECRET como secrets, mas las variables protegidas PRODUCTION_CLOUDFLARE_ACCOUNT_ID, PRODUCTION_UI_PORTAL_ACCESS_AUDIENCE y PRODUCTION_UI_PORTAL_HEALTH_ACCESS_AUDIENCE. El account ID es un valor hexadecimal exacto de 32 caracteres en minusculas. Cada audience es un valor hexadecimal exacto de 64 caracteres en minusculas, ambos valores deben ser distintos y el release los inyecta en la candidata sin registrarlos en logs ni guardarlos en Wrangler. El token Cloudflare necesita solo Account Lemn DEV / Workers Scripts: Edit y Zone le-mn.com / Zone: Read mas Workers Routes: Edit. El par Access pertenece a la service identity nueva de health y el smoke lo envia solo a /health/deep; nunca se usa para una capacidad de negocio Admin.

Catalogo, /health minimo y el recibo no-cacheable /release.json son publicos y read-only. El recibo expone solo el package publico y la identidad inmutable del build necesaria para verificar una candidata; no contiene diagnosticos operacionales. Cloudflare Access protege /admin, /admin/*, /api/admin/* y assets exclusivos de Admin; el Worker verifica criptograficamente la assertion en origin. Una service identity least-privilege solo puede consultar /health/deep.

El smoke de release lee el manifest Zero Trust del proyecto como autoridad de postura. Con Access activo exige la assertion de health y un 200 de /health/deep. Con Access desactivado por ese manifest exige origin 401/403 en Admin y deep health, incluso con headers de service token, y verifica la candidata exacta mediante /release.json. Nunca abre una ruta protegida solo para completar un deploy.

Secuencia

1. Prepara o reanuda el commit inmutable de release, verifica ese SHA exacto, hace un install frozen y vuelve a ejecutar pnpm validate, pnpm check, pnpm test y pnpm build sobre el.
2. Publica Brand Contract, UI, Brand Runtime y Brand Studio; una version existente debe tener integridad inmutable identica.
3. Instala paquetes exactos en consumidores externos limpios.
4. Sube una candidata inactiva del UI Portal y hace smoke de Catalogo, endpoints publicos, denial de Admin sin auth, comportamiento autenticado, assets protegidos, System branding, schema v1, blocks, registry e identidad.
5. Activa esa candidata exacta de forma transaccional, repite smokes publicos y protegidos, y ante un fallo restaura y verifica el baseline capturado.
6. Despliega Docs al final con la misma identidad inmutable de release.
7. Registra el receipt solo cuando pasan todos los gates.

Un fallo de identidad, integridad, concurrencia o smoke detiene el rollout. Se captura el baseline con wrangler deployments list --json, se verifica health protegido con la service identity de Access y solo entonces se activa la version exacta. Un fallo posterior ejecuta wrangler rollback <captured-version-id> --yes y vuelve a verificar el baseline. Solo existe un Worker de produccion; no hay Worker desplegado de development o staging.

Si el deploy final de Docs falla despues de activar el Portal, se reejecuta el mismo workflow de main protegido en lugar de crear otro release. La preparacion reanuda el commit de release ya pusheado, se repiten el install frozen y todos los gates sobre su SHA exacto, los paquetes publicados solo se aceptan si conservan su integridad inmutable y el rollout vuelve a validar el release del Portal antes de desplegar Docs otra vez. La reejecucion no hace rollback del Portal solo porque fallo la ultima mutacion de Docs ni publica una version hermana para el mismo trigger SHA.

Si un primer bootstrap interrumpido deja una candidata predecesora en el Worker objetivo, el siguiente release protegido de main la termina antes de iniciar su propio upgrade. La recuperacion automatica acepta un unico predecesor autoconsistente: una version activa exacta al 100% o una candidata huerfana mientras el Worker no tiene deployment. Deben coincidir su mensaje de deployment cuando existe, metadata, tag, release ID, hash de audiences Access, fingerprints del Wrangler historico y ancestro Git. Reutiliza las credenciales del Environment protegido, no reconstruye ni vuelve a subir el predecesor, reanuda una transicion exacta por hostname propiedad del release y rechaza ausencias ambiguas o drift concurrente. Cuando el predecesor pasa los smokes de candidata y activa, la misma ejecucion continua con el release actual.

Dominios y rutas retirados no reciben redirects ni tombstone Workers. La verificacion negativa debe demostrar que ya no sirven un deployment Lemn UI.

La evidencia final incluye nombres/versiones/integridad de paquetes, commit y deploy IDs, dominios/Access, smokes, y respuesta SSR sin JavaScript con CSS de scope, projectionHash y mode identity antes de hydration.