feat(builder): educacion v2 + navegacion por anclas y regla token

2026-02-18 07:15:30 +01:00
parent 6f143089b4
commit 8ac360b69d
2 changed files with 673 additions and 87 deletions
--- a/codex/VERSIONADO_IA.md
+++ b/codex/VERSIONADO_IA.md
@@ -1,4 +1,4 @@
-# Versionado IA - UB24/Elementor
+# Versionado IA - UB24/Elementor

 ## Rama de trabajo
 - `ai/ub24-builder-v1`
@@ -36,6 +36,16 @@
   - `git push origin ai/ub24-builder-v1`
 6. Registrar hash y objetivo en este archivo y en `codex/HISTORIAL_CAMBIOS.md`.

+## Protocolo de inicio de sesion (obligatorio)
+1. Levantar entorno al iniciar cada sesion, sin esperar pedido del usuario.
+2. Verificar que servicios locales de trabajo esten activos (app/builder segun tarea).
+3. Si la tarea requiere validacion remota, conectarse a Raspberry y comprobar estado antes de editar.
+
+## Regla operativa de contexto/token
+1. Trabajar por iteraciones cortas y versionar rapido para no perder avance cuando el presupuesto de tokens sea bajo.
+2. Priorizar cambios de alto impacto visual/funcional antes de detalles menores.
+3. Si el usuario avisa limite de tokens, cerrar cada bloque con commit y registro en este archivo.
+
 ## Registro de hashes
 ### Baseline
 - Commit: `cb99f26`
@@ -157,3 +167,201 @@ Notas:
 1. Fase 1 (UI Pro base): navbar premium, hero premium, sistema de espaciado/grid, pulido visual consistente.
 2. Fase 2 (estructura): separar renderers por bloque y reducir inline styles para automatizacion.
 3. Fase 3 (presets): presets por rubro + reglas responsive + variantes exportables.
+
+## Verificacion tecnica (15 Febrero 2026)
+- Rama activa verificada: `ai/ub24-builder-v1`
+- Divergencia local/remoto: `0 0` (sin diferencias con `origin/ai/ub24-builder-v1`)
+- DB local: tabla `sites` operativa con registros de prueba (`id=1`, `id=2`)
+- Smoke test builder:
+  - `GET /elementor/1` -> `200 OK`
+  - `POST /api/elementor/save` con `site_id=1` -> `200 OK`, `{"success": true, "published": false}`
+
+## Requisitos minimos para operar Elementor (base SaaS)
+1. Arrancar con `python -m demo.app` desde `c:\word`.
+2. Mantener URL canonica local en `http://127.0.0.1:5001` (no `localhost`).
+3. Confirmar que exista un `site_id` valido en DB (ejemplo activo: `1`).
+4. Mantener una sola ruta de guardado activa: `/api/elementor/save`.
+5. Validar guardado/publicacion con prueba rapida antes de cada lote.
+
+## Regla memorizada de preview (15 Febrero 2026)
+- La preview del builder debe usar un solo flujo en `Bloques` con acomodo estable.
+- No mantener ni mezclar modos paralelos de preview.
+
+## Ajuste operativo UX (15 Febrero 2026)
+- Se elimina `Completo` del builder.
+- Se elimina `Modo libre` como toggle separado.
+- El layout operativo queda unico en bloques:
+  - cada bloque puede ir en `50%` (dos columnas) o `100%` (ancho completo),
+  - controlado por `Ancho completo` en inspector o por drop lateral/centro.
+
+## Regla de estabilidad (15 Febrero 2026)
+- Lo que ya funciona no se toca sin requerimiento explicito.
+- Los bloques del panel izquierdo no deben ocultarse al usarse.
+- Cada tipo de bloque debe poder agregarse cantidad ilimitada de veces.
+- Debe existir boton de `Vista previa` funcional en el builder.
+- El ancho completo/parcial se controla solo con `Ancho bloque (%)` del mismo bloque (sin checkbox separado).
+- La vista previa se abre en modo push/pop (`preview=1`) y muestra boton `Atras`.
+
+## Estado real de cierre (15 Febrero 2026)
+- Tema bloqueante: drag & drop de bloques sigue inestable en el flujo actual.
+- Sintoma reportado por usuario: mover con mouse no queda consistente para alinear y ubicar bloques como espera.
+- Decision acordada: pausar cambios hoy para no seguir consumiendo tiempo/tokens.
+- Proximo reinicio: rehacer DnD con enfoque estable desde base limpia (una sola estrategia de movimiento), validar con pruebas manuales guiadas y recien despues tocar extras.
+- Regla reforzada: no tocar lo que ya funciona mientras se corrige solo el DnD.
+
+## Regla operativa de sesion (15 Febrero 2026)
+- Al iniciar cada sesion de trabajo, levantar primero el entorno local del builder:
+  - `python -m demo.app`
+- Verificar puerto antes de editar:
+  - `http://127.0.0.1:5001`
+
+## Acuerdo definitivo DnD (15 Febrero 2026)
+- Decision: implementar una solucion definitiva de drag & drop con una sola estrategia, sin mezclar motores.
+- Motor elegido: `SortableJS` para reordenamiento estable (desktop + touch).
+- Alcance de la correccion:
+  - reemplazar reordenamiento actual por `SortableJS` en el canvas de bloques,
+  - usar `handle` de arrastre para no interferir con edicion inline,
+  - configurar fallback estable (`forceFallback` + umbrales de toque/movimiento),
+  - eliminar handlers duplicados de drag que hoy se pisan entre si.
+- Regla de seguridad: no tocar guardado, preview ni bloques que ya funcionan.
+- Proxima sesion: implementar, hacer smoke test completo en `/elementor/1`, y recien despues validar cierre para lanzamiento SaaS.
+
+## Cierre de sesion (16 Febrero 2026)
+- Rama de trabajo usada: `ai/ub24-builder-v1`
+- Entorno validado en sesion: `GET /elementor/1 -> 200 OK`
+- Commit de cierre funcional del dia:
+  - Hash: `6f14308`
+  - Mensaje: `fix(builder): unificar layout y estabilizar redimension en canvas`
+  - Alcance: `elementor/templates/elementor_builder.html`
+
+### Resultado operativo del dia
+- Se recupero el flujo de insercion de bloques desde panel izquierdo al canvas.
+- Se estabilizo el modelo de layout del canvas para evitar mezcla de estrategias.
+- Se dejo redimension por ancho de bloque en flujo normal y control desde inspector.
+- Se corrigio comportamiento por defecto para que bloques nuevos entren apilados (ancho completo) y no en paralelo automatico.
+- Se mantuvo `SortableJS` para reordenamiento de bloques en canvas.
+
+### Decisiones memorizadas para siguiente sesion
+- Mantener una sola estrategia de layout y reordenamiento (sin volver a mezclar motores/flows).
+- No reabrir cambios globales cuando un fix local sea suficiente.
+- Si algo ya funciona, no rehacerlo completo: tocar solo el bloque minimo necesario.
+
+### Pendientes acordados (proxima sesion)
+1. Footer obligatorio global en todas las paginas:
+   - marca registrada del usuario + empresa desarrolladora.
+2. Watermark de autoria en codigo (convencion consistente del proyecto).
+3. Preview dual:
+   - modo bloques (editor),
+   - modo pagina completa real (resultado final).
+4. Mejorar landing base para nivel visual profesional.
+5. Redes sociales con posicion libre (ubicacion configurable).
+6. Menu superior: corregir modo acordeon (hoy no queda operativo como se espera).
+7. Mejorar interaccion touch/capacitiva del builder.
+
+## Registro operativo (17 Febrero 2026)
+- TAG: `RUBROS_OFICIALES_BLOQUEADOS`
+- Regla fija: no usar rubros inventados; solo los oficiales definidos por usuario.
+- Rubros oficiales memorizados:
+  - `restaurante`
+  - `danza`
+  - `cosmeticos`
+  - `despachos`
+  - `gimnasios`
+  - `educacion`
+  - `base_otro` (`Base (Otro)`)
+
+- TAG: `PREVIEW_FINAL_SEPARADA`
+- Se agrega flujo dedicado de preview final real separado del hash del editor:
+  - `GET /elementor/<site_id>/preview-final`
+  - `GET /ub24/<site_id>/preview-final`
+- En preview final:
+  - se fuerza `preview-mode` desde servidor (`preview_only=true`),
+  - boton `Atras` vuelve al builder base.
+
+- TAG: `UNIFICACION_TOPBAR_Y_DRAWER_FIX`
+- Ajustes aplicados:
+  - se elimina duplicidad operativa de preview en topbar y se deja `Pagina real` como flujo principal,
+  - selector de plantillas migra a `Plantillas por rubro` (catalogo oficial),
+  - `Drawer Pro` se mueve a capa global para evitar render roto dentro del bloque/canvas,
+  - etiqueta de pagina `Servicios` se neutraliza a `Seccion 2` para no mezclar paginas con rubros.
+
+## Registro infraestructura Raspberry (17 Febrero 2026)
+- TAG: `KOMKIDA_WEB_ACCESS_RECOVERY`
+- Objetivo: recuperar `komkida.duckdns.org` como acceso web remoto a Raspberry con login (estilo Motion), sin romper:
+  - `gk-saas.komkida.duckdns.org`
+  - `git.gk-saas.komkida.duckdns.org`
+  - `motion.komkida.duckdns.org`
+
+### Diagnostico real
+1. El `502 Bad Gateway` en subdominios (`gk-saas`, `git`, `motion`) venia por `proxy_pass http://localhost:PUERTO`:
+   - Nginx resolvia `localhost` a IPv6 (`[::1]`) en varios casos.
+   - servicios escuchando en IPv4 (`127.0.0.1` / `0.0.0.0`) devolvian `connection refused`.
+2. `komkida.duckdns.org` quedo mezclado con proxy a metricas (`192.168.1.133:5000`) y luego con rutas no validas (`Not Found`).
+3. Hubo drift de configuracion:
+   - archivo suelto viejo en `/etc/nginx/sites-enabled/komkida.duckdns.org` (no symlink) con reglas desactualizadas.
+4. El navegador intentaba `https://komkida.duckdns.org` y no habia listener en `443`:
+   - error visible: `ERR_CONNECTION_REFUSED`.
+
+### Cambios aplicados en Raspberry
+1. Normalizacion de upstreams Nginx a IPv4:
+   - `proxy_pass http://127.0.0.1:<puerto>;` en vhosts activos.
+2. Limpieza de duplicados/conflictos:
+   - quitar backups cargados en `sites-enabled`.
+   - asegurar `sites-enabled/komkida.duckdns.org` como symlink al archivo de `sites-available`.
+3. Definicion final de `komkida.duckdns.org`:
+   - auth_basic con `.htpasswd`.
+   - `/` proxyeado a `https://127.0.0.1:4200` (ShellInABox).
+   - `/api/` mantiene proxy a `127.0.0.1:9999` (no bloquea resto del sistema).
+4. Habilitacion HTTPS para `komkida`:
+   - servidor Nginx en `443 ssl`.
+   - certificado local en:
+     - `/etc/nginx/ssl/komkida.crt`
+     - `/etc/nginx/ssl/komkida.key`
+5. Verificacion final:
+   - Nginx escuchando en `80` y `443`.
+   - `http://komkida.duckdns.org` -> `401` (esperado: login).
+   - `https://komkida.duckdns.org` -> `401` (esperado: login).
+   - `gk-saas` y `git` siguen en `200`.
+
+### Bots (estado para no cargar la Pi)
+- `clawdbot`: deshabilitado por OOM recurrente (`JavaScript heap out of memory`).
+- `moltobot`: deshabilitado temporalmente.
+- Decision: priorizar estabilidad de infraestructura y SaaS.
+
+### Archivos clave tocados en la Pi
+- `/etc/nginx/sites-available/komkida.duckdns.org`
+- `/etc/nginx/sites-enabled/komkida.duckdns.org`
+- `/etc/nginx/ssl/komkida.crt`
+- `/etc/nginx/ssl/komkida.key`
+
+### Checklist rapido de recuperacion futura
+1. `sudo nginx -t`
+2. `sudo systemctl restart nginx`
+3. `ss -tulpen | egrep ':80 |:443 '`
+4. `curl -I http://komkida.duckdns.org/` (debe pedir auth)
+5. `curl -k -I https://komkida.duckdns.org/` (debe pedir auth)
+6. `curl -I http://gk-saas.komkida.duckdns.org/` (debe responder `200`)
+
+A ESTO SE TIENEN QUE PARECER:
+Correcto. Busqué referencias reales y modernas; vamos a dejar de “inventar” estilos internos.
+
+Referencias que sí sirven para copiar estructura profesional:
+1. Webflow Education Templates (catálogo): https://webflow.com/templates/category/education-websites  
+2. Hopedu (estructura académica limpia + CMS): https://webflow.com/templates/html/hopedu-school-website-template  
+3. Eduvolv (hero + admissions + secciones institucionales): https://webflow.com/templates/html/eduvolv-website-template  
+4. Thema (variantes de layout + menú fullscreen): https://webflow.com/made-in-webflow/website/thema-education-template-showcase  
+5. Campus (layout simple usable): https://webflow.com/templates/html/campus-education-website-template  
+6. ThemeForest Elementor kit (referencia de páginas mínimas): https://themeforest.net/item/educita-education-elementor-template-kit/37245135  
+
+Plan profesional (sin clones):
+1. Rehacer templates por rubro con 3 arquitecturas distintas, no solo cambiar color.
+2. Cada rubro tendrá:
+- header propio
+- hero propio
+- grid propio
+- CTA propio
+- footer propio
+3. El builder cargará esas arquitecturas base y luego se edita contenido.
+4. Eliminaré el estilo único actual que hace que todo se vea igual.
+
+Si quieres, empiezo ya con `Educación` copiando patrón `Eduvolv/Hopedu` y luego replico la metodología al resto de rubros.