Encargo (2026-08-03). Se ha adquirido paladio.io en GoDaddy y sustituirá a los
dos dominios actuales. Este documento es el censo + el plan de ejecución:
dónde está clavado el dominio hoy, qué se rompe si se cambia sin orden, las
decisiones ya tomadas (§3), y las tandas de trabajo (§4).

⚠️ La pieza peligrosa es Clerk, no Vercel. Cambiar el dominio de la app es un
registro DNS; cambiar el de Clerk cambia el emisor de los JWT, invalida las
sesiones y deja fuera a todo lo que verifica ese emisor. Va con su propio orden
y su propio rollback (§4, Tanda 4).

⚠️ El comodín *.nodeworkspace.com NO sirve share links. Existe en Vercel por
un diseño anterior —subdominio por workspace— que nunca se llegó a implementar.
Los share links son rutas: url.ts:44 construye
https://www.<dominio>/w/<slug>, y no hay una sola línea en el repo que fabrique
un host <slug>.. El docstring de slug.ts:12
está rancio y lo documenta como si estuviera vivo. El comodín no se replica
(decisión ②, §3).

🔴 Corrección (2026-08-04). Se dijo que esta variable «es un host de Railway y
nunca llevó nuestro dominio». Falso: valía jupyter.nodeworkspace.com, y ese
nombre no resuelve — no existe el registro DNS, ni en la zona vieja. Síntoma:
Network error talking to Hub … fetch failed al crear un notebook.

No lo rompió la migración: llevaba roto y nadie lo había tocado. Se arregla
apuntando al dominio público del servicio en Railway
(jupyter-production-xxxx.up.railway.app, sin https://). Es NEXT_PUBLIC_ ⇒
exige redeploy.

La lección, otra vez la misma: que una variable exista no dice que su valor
resuelva. El censo la dio por buena porque nadie la había consultado nunca.

🔸 Decisión del owner (2026-08-04): las integraciones de Google/Microsoft y
los webhooks se consideran legacy y no bloquean la migración. Se quedan
apuntando al dominio viejo, que sigue sirviendo.

⚠️ Los webhooks ya registrados llevan el dominio viejo grabado.
getWebhookBaseUrl() compone la URL en el registro, así que cambiar la
variable sólo afecta a los nuevos. Y el 301 de la Tanda 5 no los salva: son
POST con cuerpo, y una redirección sobre POST no la siguen todos los clientes
con el body intacto. O el dominio viejo responde de verdad, o hay que
re-registrarlos.

🔴 Por qué es la pieza crítica. El dominio de Clerk es el emisor (iss) de
los JWT. Al cambiarlo: las sesiones vivas se invalidan, y todo lo que valida
el token tiene que aceptar el emisor nuevo antes de que empiece a emitirlo —
JupyterHub y la SDK incluidos. Si se cambia primero en Clerk y después en el
código, hay una ventana en la que nadie puede entrar.

🔴 Y su corolario, que ordena todo el plan: la app no puede servir una sesión
desde un host que Clerk no conoce. Hasta que app.paladio.io esté registrado en
Clerk, ese host sólo sirve contenido anónimo. Por eso APP_ORIGIN no se mueve
hasta la Tanda 4 — ver el gate de esa tanda.

⚠️ Clerk no son dos registros. Una instancia de producción pide además los de
correo —del tipo clkmail y dos claves DKIM— sin los cuales los emails de
invitación no salen (InviteModal.tsx
depende de eso). El número y los valores exactos los da su panel al crear el
dominio: cópialos de ahí, no de este documento, y créalos todos en la Tanda 3.

⚠️ Ningún valor de Vercel ni de Clerk se transcribe desde un runbook. Cambian
por proyecto y por antigüedad de cuenta. El runbook dice qué registros hacen
falta; el panel dice cuáles.

🔴 Dos trampas aquí. (a) AUTHORIZER_PRINCIPAL_DOMAIN decide quién puede
entrar en OM: la identidad del usuario deriva del dominio de su correo, así que
cambiarlo sin migrar los usuarios existentes los deja fuera. (b) Caddy pedirá un
certificado nuevo, y para eso necesita el puerto 80 abierto y el DNS ya
propagado — no al revés.

⚠️ Y hoy no hay acceso. Diagnosticado a fondo el 2026-08-04:

Comprobación	Resultado
10.138.0.2:22	❌ inalcanzable — es la IP privada de la VPC, no se enruta desde fuera
34.168.67.167:22	✅ abierto · banner SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.16
Clave de host	✅ COINCIDE con known_hosts:1 (SHA256:Ck6+hE5+adJEXy1RexoDx14r+wGcG0tbDh+lMV1jQfA)
Nuestra clave	✅ existe y se ofrece (SHA256:xt4s2sHK4aWaM/tcfjE2fVM3IXr1DIbkD3XwnZL2ZkY)
Autenticación	❌ Permission denied (publickey) · el servidor sólo admite publickey, sin contraseña

🔴 Corrección: la clave de host NO cambió. Este runbook decía «se reconstruyó,
cambió la clave de host y nuestra pública ya no está en authorized_keys». La
primera mitad es falsa —el host key valida contra known_hosts sin rechistar,
así que la VM no se reconstruyó—; la segunda es cierta: la clave se ofrece y
el servidor la rechaza.

⇒ El fallo está sólo en la autorización de la clave, no en la identidad de la
máquina. Eso lo hace mucho más fácil de arreglar de lo que este documento decía.

Pista sobre el origen: el comentario de nuestra clave pública es
carbon-openmetadata, que es justo la convención con la que GCE deriva el
usuario Linux de una clave puesta en metadatos. O sea, se aprovisionó por
metadatos y algo la retiró — o se activó OS Login, que hace que GCE ignore
authorized_keys y los metadatos por completo.

Cómo recuperarlo (gcloud NO está instalado en local):

1. GCP Console → Compute Engine → la VM → Edit → Metadata → ver si existe
   enable-oslogin. Ese dato decide el camino.
2. Si no está: Edit → SSH Keys → Add item y pegar la línea completa de
   ~/.ssh/id_ed25519.pub. GCE recrea el authorized_keys del usuario.
3. Si sí está: los metadatos no valen; hay que registrarla por OS Login, y
   entonces el usuario no será carbon-openmetadata sino el derivado del
   correo.
4. Alternativa que evita elegir: instalar gcloud y usar gcloud compute ssh,
   que aprovisiona la clave por el camino que corresponda.

✅ Pero frame-ancestors (Caddyfile:49) sí hay que tocarlo —y eso sí
requiere el SSH— porque si no, el enclave de OM deja de renderizar dentro de
app.paladio.io. Es lo único de OM que bloquea la Tanda 4.

🔴 El Hub llevaba roto por DOS motivos distintos a la vez (2026-08-04). En
Public Networking había dos dominios, y cada uno fallaba por su lado:

Dominio	Puerto	Fallo
node-production-c2a0.up.railway.app	8082	resolvía, pero nadie escuchaba en ese puerto
jupyter.nodeworkspace.com	8080	puerto correcto, pero el registro DNS nunca se creó

Quien montó el dominio personalizado acertó el puerto y no hizo el DNS; el
generado tenía el DNS y el puerto equivocado. Ninguno funcionó nunca.

Cómo se distinguió: el 404 traía server: railway-hikari con cuerpo vacío — es
el edge de Railway diciendo «no hay nadie en ese puerto», no un 404 de la
aplicación. Un Hub caído habría dado 502.

Arreglado poniendo el dominio generado en 8080. Verificado:
/hub/api → 200 {"version": "5.5.0"}.

La lección: «la variable apunta a un host que existe» y «ese host llega al
proceso» son dos afirmaciones distintas, y aquí fallaban las dos por separado.

Consecuencia útil: Keycloak, Lakekeeper y el resto del warehouse no se
enteran de este cambio. Toda la gobernanza que construimos hoy es indiferente
al dominio.

🔴 La SDK es la única huella con consumidores fuera de nuestro control. Un
kernel de Jupyter o un notebook de un cliente tiene NODE_API_BASE apuntando al
dominio viejo. El dominio viejo debe seguir respondiendo (redirección 301) al
menos un ciclo — o se rompen sus notebooks sin avisar.

✅ Pero la SDK NO valida dominios, y eso simplifica mucho.
auth.ts:82 verifica el kernel JWT contra
issuer: 'node-platform' — una cadena literal, no un host
(types.ts:41). El servidor no necesita ningún cambio:
sirve cualquier host que le llegue. La exposición real es sólo del lado cliente:
NODE_API_BASE es una variable de entorno inyectada en el kernel
(transforms.py:650).
Traducción: (a) JupyterHub debe inyectar el dominio nuevo en los kernels
nuevos (Tanda 4) y (b) el viejo debe seguir respondiendo para los kernels y
notebooks ya existentes (Tanda 5). Nada más.

📌 Enmienda (2026-08-03): el canónico es www, no el apex. El plan decía apex,
pero al configurar Vercel quedó paladio.io → 308 → www.paladio.io — y eso es lo
consistente: el dominio viejo ya hace exactamente lo mismo
(node-web.com → 308 → www.node-web.com, medido). Darle la vuelta ahora sería un
cambio sin beneficio en mitad de la migración. classifyHost trata los dos como
landing, así que funciona igual; lo que se fija aquí es cuál es el canónico
para el SEO y para el 301 de la Tanda 5.

Cada tanda es desplegable y reversible por sí sola. Sólo la Tanda 4 tiene una
ventana de indisponibilidad. Las tandas 1-3 son puramente aditivas: no quitan
ni un host viejo, así que producción no se entera.

⭐ Un 404 que confirma el diseño de la Tanda 2. Hoy
https://app.paladio.io/dashboard devuelve 404: el código desplegado aún
clasifica ese host como dev, así que auth.protect() corre sin que Clerk
reconozca el origen, y sin sesión responde 404 en vez de redirigir. Es
exactamente el fallo que evita el rol parked — medido, no teórico.

⚠️ El orden es Vercel → GoDaddy, no al revés. Los valores exactos del A del
apex y del CNAME los dicta Vercel al añadir el dominio y varían por proyecto
y por antigüedad de la cuenta. No se copian de un runbook: se copian del panel.

⭐ Dos cambios respecto a lo planeado, y por qué.

(a) El censo se centraliza. Estaba duplicado entre proxy.ts y Navbar.tsx
—dos listas de hosts y dos copias de APP_ORIGIN—, que es exactamente el fallo
que se paga caro en una migración: se añade el dominio en un sitio y se olvida en
el otro. Ahora el flip de la Tanda 4 se reduce a hosts.ts.

(b) app.paladio.io NO se clasifica como app, sino como parked (rol
nuevo: rebota todo a APP_ORIGIN conservando la ruta). El plan original decía
app, y estaba mal: con Clerk todavía sin conocer ese host, cualquiera que
entrase se quedaría sin sesión y sin poder iniciarla —auth.protect() lo
mandaría a un sign-in servido desde un origen que Clerk no reconoce—. Aparcado,
el host existe, tiene TLS y lleva a la app que funciona. En la Tanda 4 pasa de
parked a app en la misma línea en que se mueve APP_ORIGIN.

Ésta es la tanda que hace que la Tanda 4 sea un flip y no un salto al vacío.
Todo se AÑADE; no se quita nada.

🔴 Incidente

Añadir paladio.io en Clerk no añadió un dominio: cambió el primario, y con
él se retiró el certificado del anterior. Medido con dos stacks TLS
independientes (.NET y schannel/curl):

clerk.nodeworkspace.com  → handshake TLS RECHAZADO (alert fatal)
clerk.paladio.io         → 200, kid ins_3CP3SBUHAfirjtoxRhET96gznyt

El DNS seguía bien (CNAME → frontend-api.clerk.services): lo que faltaba era el
certificado. Y la clave que servía producción era
pk_live_Y2xlcmsubm9kZXdvcmtzcGFjZS5jb20k, que decodifica a
clerk.nodeworkspace.com$ ⇒ clerk-js no cargaba, nadie podía entrar.

La lección: en Clerk, "añadir un dominio" a una instancia de producción es
el paso destructivo. No hay fase aditiva que valga — el paso ④ empieza en el
momento en que se toca el panel, no cuando uno decide que empieza.

Por qué se fue hacia adelante y no hacia atrás: recuperar el host viejo exige
que Clerk re-emita un certificado, algo ni instantáneo ni bajo nuestro
control. El kid es idéntico en ambos hosts ⇒ misma instancia, mismas claves de
firma: sólo cambia la publicable. Y el argumento de "esperar a la ventana baja"
ya no aplicaba — la ventana era ya, porque estaba caído.

⭐ El dominio viejo no se apaga: se convierte en parked. Sigue resolviendo,
con TLS, y reenvía conservando la ruta. No puede servir la app —allí clerk-js
ya no carga—, pero un enlace viejo lleva a donde debe.

⭐ Con una excepción: /api/sdk/* se sirve DIRECTAMENTE en el host viejo. Un
kernel o el notebook de un cliente tiene NODE_API_BASE grabado apuntando ahí, y
esas llamadas son POST con cuerpo — una redirección no la sigue todo cliente
con el body intacto. Y no necesitan Clerk: auth.ts:82
valida un JWT de kernel cuyo emisor es la cadena literal 'node-platform', no
un host. Servirlas directamente es estrictamente más seguro que redirigirlas.

⚠️ main estaba sin compilar y lo tapaba este mismo despliegue. aa14f67
subió UnderDevelopmentBanner.tsx importando BRAND_NAME/BRAND_COLOR de
lib/brand/wordmark.ts, que se quedó sin commitear ⇒ cualquier build de
producción fallaba. Se detectó porque el commit se aisló y se typecheckeó el
árbol exacto a desplegar, no el árbol de trabajo. wordmark.ts entró en
8674e7e por obligación, no por criterio.

La lección: typecheckear el working tree no dice nada sobre lo que se
despliega. Sólo lo dice typecheckear lo que está en el índice.

🔴 CORRECCIÓN (2026-08-04). El 301 de Vercel sobre nodeworkspace.com NO se
hace — rompería la SDK. Un redirect a nivel de dominio en Vercel actúa en el
edge, antes del middleware, así que se aplicaría también a /api/sdk/* y
anularía la excepción verificada en la Tanda 4. El reenvío de nodeworkspace.com
ya está hecho y en el sitio correcto: en proxy.ts, que
distingue rutas. En Vercel no hay nada que añadir para ese dominio.

El mismo razonamiento vale para borrar el dominio: quitarlo de Vercel no
devuelve 404, deja de resolver al deploy ⇒ error de TLS y notebooks rotos sin
aviso. Eso es Tanda 7, y su condición no es el tiempo sino la medida: filtrar
los logs de Vercel por Host: *.nodeworkspace.com y comprobar que ya no entra
tráfico a /api/sdk/*. Mientras lo haya, hay un kernel o un notebook vivo ahí
fuera.

El gate que de verdad cierra la migración no es que la landing cargue: es que
un usuario ya logueado siga logueado, que un share link abra, y que un notebook
con el dominio viejo siga funcionando. Los tres fallan por motivos distintos y
ninguno se ve desde la portada.