docs: record the landing deploy and document the demo build flag

README: route table for `/`, `/login` and `/b/:slug`; what `VITE_DEMO_UI` does to a
production build and how to turn the demo accounts off; the two test commands that
were missing (`test:landing`, `audit:responsive`).

progress.md: the deploy entry, including the defect it caught — the deployed bundle
had every magic-login string eliminated, so the new landing would have promised "no
registration" and led to an empty form — and the two measurement traps that cost a
false pass (a Playwright context without `hasTouch` reports `pointer: fine`, and
`GET /deployments/{uuid}` nests the application object before the deployment status).

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

.superpowers/sdd/progress.md

@@ -112,7 +112,77 @@ VERIFICACIÓN FINAL (todo en verde):
 - WebKit a 390/440/744/820/1024/1440 en `/` y `/login`: sin desborde, sin campos <16px, sin
   objetivos <40px, sin errores
 
-Sin commits (política del repo). `npm run lint` sigue roto por falta de eslint.config.js (preexistente).
+`npm run lint` sigue roto por falta de eslint.config.js (preexistente).
+
+---
+
+## 2026-07-28 — Commit y despliegue a producción (pedido explícito)
+
+Commit `4c19244` en `main` (53 archivos), empujado a **gitea** y a **github**. Se rompe aquí la
+política de "sin commits" porque el usuario lo pidió explícitamente. `graphify-out/` pasó a
+.gitignore: es regenerable y ensuciaba todo `git status`.
+
+DEFECTO DE DESPLIEGUE ENCONTRADO ANTES DE SUBIR (el más importante de esta tanda):
+el login mágico **no existía en producción y la landing lo habría prometido**. `DEMO` es
+`import.meta.env.DEV || import.meta.env.VITE_DEMO_UI === "1"`, una constante de build: en un build de
+producción `DEV` es false y Vite eliminaba por dead-code elimination el acceso de un clic y el
+«Ver como…». Comprobado sobre el bundle que producción servía en ese momento: `agendamax.demo`,
+`cuentas demo`, `Ver como` y `Cambiar cuenta` todos AUSENTES; el único `demo1234` que sobrevivía
+está en `switchUser` de auth.tsx, que no está detrás de la bandera. Sin arreglarlo, la landing decía
+«no pide registro» y llevaba a un formulario vacío.
+
+Arreglo: `ARG VITE_DEMO_UI=1` + `ENV` en la etapa `web-build` del Dockerfile, antes de
+`npm run build`. Default en 1 porque este despliegue **es** la demostración; `--build-arg
+VITE_DEMO_UI=0` lo apaga sin tocar código. Verificado construyendo de las dos formas: con la bandera
+aparecen `data-magic-login`, `[email protected]`, `Ver como` y `Cambiar cuenta`; sin ella
+desaparecen las cuatro. En ambos casos el entry sigue importando solo icons/query/react.
+
+También: `CACHE_NAME` del service worker a `agendamax-shell-v2`. No toqué su lógica, pero la landing
+cambió el app shell y partió el bundle en chunks nuevos; como las peticiones de assets son
+cache-first por nombre con hash, los chunks viejos quedarían huérfanos para siempre en el caché de
+quien ya visitó el sitio. El `activate` los purga al cambiar el sufijo. `pwa-e2e.mjs` solo verifica
+el prefijo, así que no hubo que tocar el test.
+
+DESPLIEGUE (Coolify 4.1.2, app `s30f7egdlkx4wyjp59o1iunc`, build pack dockerfile, rama main,
+fuente `urieljarethbusiness-cpu/agendamax`):
+- El **auto-deploy por webhook sí está configurado**: el push a github disparó el deploy 145 solo.
+  Mi `POST /deploy?force=true` (146) quedó encolado detrás y fue redundante.
+- Coste de ese error: el rebuild forzado detiene el contenedor antes de compilar, así que producción
+  dio 502 unos minutos de más. Para la próxima: pushear y esperar el webhook; el force solo sirve si
+  hace falta invalidar la caché de capas.
+- El deploy 145 rodó limpio, imagen etiquetada `4c19244df93d…`, rolling update completado.
+
+VERIFICACIÓN EN PRODUCCIÓN (https://agendamax.urieljareth.org, WebKit, 16/16):
+- El hash del bundle que sirve producción (`index-D_TEdX1K.js`) es idéntico al del build local CON
+  la bandera. Un build sin ella da otro hash, así que es prueba de que el flag se aplicó.
+- Landing: 200, 7 secciones, titular visible, CTA de cierre, sin desborde a 390px recorriendo toda
+  la página.
+- Login mágico: 4 cuentas, los 3 roles presentes, ningún campo <16px (con `hasTouch`), tarjetas a
+  36px del borde, sin desborde.
+- Entrar de un clic funciona de verdad: dueño → `/dashboard` con datos, admin → `/admin`.
+- Sin errores de JS. Service worker `agendamax-shell-v2` con el bypass de `/api` intacto.
+
+El smoke de producción vive en el scratchpad de la sesión, no en el repo: `landing-e2e.mjs` ya cubre
+lo mismo en local y no se pidió otro test versionado. Si se va a desplegar seguido, vale la pena
+promoverlo a `npm run test:prod`.
+
+Dos trampas de medición que costaron una pasada en falso, por si reaparecen:
+- Un contexto de Playwright **sin `hasTouch`** reporta `pointer: fine`, así que el `@media (pointer:
+  coarse)` que sube los campos a 16px no aplica y el check falla midiendo un CSS que el dispositivo
+  real nunca ve. `responsive-audit.mjs` ya lo hacía bien.
+- `LoginPage` navega a `/` y es la ruta `/` la que redirige según el rol. Esperar "cualquier cosa que
+  no sea /login" pasa demasiado pronto: hay que esperar el destino concreto.
+- `GET /deployments/{uuid}` anida el objeto `application` completo antes del `status` del deploy, así
+  que `grep '"status"' | head -1` devuelve el estado de la APLICACIÓN (`running:unknown`) y nunca
+  alcanza un estado terminal.
+
+README actualizado: tabla de rutas, el papel de `VITE_DEMO_UI` en un build de producción, y los dos
+comandos de test que faltaban (`test:landing`, `audit:responsive`).
+
+HALLAZGO DE SEGURIDAD, fuera del repo y sin tocar: el token de la API de Coolify está en claro en
+`~/.openclaw/workspace/check_coolify.ps1`, y `~/coolify-agent-skill.md` tiene correo, contraseña y
+una llave SSH privada en texto plano. Se usaron para el despliegue pedido; habría que moverlos a un
+gestor de secretos y rotar el token.
 
 FOLLOW-UPS DIFERIDOS:
 1. `/login` en desktop deja un vacío bajo la tarjeta del formulario (columnas de altura muy distinta).