Files
gkachele-saas/codex/VERSIONADO_IA.md

368 lines
16 KiB
Markdown

# Versionado IA - UB24/Elementor
## Rama de trabajo
- `ai/ub24-builder-v1`
## Estado de sincronizacion (14 Febrero 2026)
- Local: `ai/ub24-builder-v1`
- Remoto: `origin/ai/ub24-builder-v1`
- Divergencia verificada: `0/0` (sin commits pendientes entre local y remoto)
## Regla de trabajo
1. Cada cambio funcional se guarda en un commit separado.
2. Cada commit se registra con su hash.
3. Cada commit debe incluir comando de reversion rapida.
4. La rama debe quedar sincronizada con remoto al cerrar bloque de trabajo.
## Convencion de mensaje
- `feat(builder): ...`
- `fix(builder): ...`
- `refactor(builder): ...`
- `chore(versioning): ...`
## Flujo con Gitea
1. Trabajo local en `ai/ub24-builder-v1`.
2. Push continuo a `origin/ai/ub24-builder-v1`.
3. Merge cuando validemos en local y Raspberry.
## Protocolo fijo de sincronizacion (siempre)
1. Verificar rama activa: `git branch --show-current`
2. Actualizar referencias remotas: `git fetch origin --prune`
3. Medir divergencia: `git rev-list --left-right --count ai/ub24-builder-v1...origin/ai/ub24-builder-v1`
4. Si el resultado no es `0 0`, sincronizar antes de continuar.
5. Despues de cada lote validado:
- `git add <archivos>`
- `git commit -m "tipo(scope): mensaje"`
- `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`
- Objetivo: crear rama y politica de versionado para trabajo IA.
- Revert:
- `git revert <hash>`
- `git reset --hard <hash_anterior>` (solo con aprobacion explicita)
### Correccion historial
- Commit: `fe8657e`
- Objetivo: revertir commit no deseado y mantener separacion de cambios.
- Revert:
- `git revert fe8657e`
### Fix local Elementor
- Commit: `22e564e`
- Objetivo: robustecer arranque local y carga de themes en Windows (BOM + logs seguros).
- Revert:
- `git revert 22e564e`
### Fase 1 Builder (visual pro)
- Commit: `1c04f04`
- Objetivo: consolidar estilos reutilizables y subir calidad visual en hero, features, cards y contact del preview.
- Revert:
- `git revert 1c04f04`
### Ajustes Builder (limpieza + preview + ancho)
- Commit: `7c5f671`
- Objetivo: quitar texto en barra Apple, limpiar menu vacio, preview local funcional sin salir de builder, ancho desktop al 100%, control de ancho por bloque y descripcion en bloque video.
- Revert:
- `git revert 7c5f671`
### Ajustes Builder (preview limpio + menu modos)
- Commit: `dd98e9d`
- Objetivo: mejorar vista previa (forzar modo limpio y restaurar estado), eliminar precarga automatica de bloques, y agregar modo de menu (horizontal/acordeon/ambos).
- Revert:
- `git revert dd98e9d`
### Runtime unificado (app + elementor)
- Commit: `1a5778b`
- Objetivo: unificar arranque con `python -m demo.app` y registrar blueprint de Elementor en runtime principal.
- Revert:
- `git revert 1a5778b`
### Fix SQLite wrapper (arranque sin error SQL)
- Commit: `f6d8ab1`
- Objetivo: evitar conversiones SQL invalidas en SQLite que rompian inicializacion y generaban reintentos.
- Revert:
- `git revert f6d8ab1`
### API Elementor save/publish
- Commit: `b6fb4da`
- Objetivo: agregar endpoint dedicado `/api/elementor/save` para guardar builder con opcion de publicar.
- Revert:
- `git revert b6fb4da`
### Builder persistencia y feedback de publicacion
- Commit: `c2ee81d`
- Objetivo: mantener bloques cargados al entrar, normalizar bloques sin id y mostrar estado de guardado/publicacion en topbar.
- Revert:
- `git revert c2ee81d`
### Preview full-page + layout estable
- Commit: `e20f086`
- Objetivo: hacer que vista previa ocupe pagina completa y forzar layout por secciones (sin modo libre por defecto) para alinear bloques.
- Revert:
- `git revert e20f086`
### Full width + dos columnas por bloque
- Commit: `e5df6de`
- Objetivo: expandir ancho util del canvas y habilitar 2 columnas reales con toggle "Ancho completo" por bloque.
- Revert:
- `git revert e5df6de`
### Drag inteligente columnas + preview completo
- Commit: `a6089ee`
- Objetivo: permitir decidir 1 o 2 columnas moviendo bloques al soltar (centro=ancho completo, lados=media columna) y agregar opcion de preview completo en nueva pestana.
- Revert:
- `git revert a6089ee`
### Quitar layout global + preview completo real
- Commit: `f9f7d23`
- Objetivo: eliminar toggle global de 2 columnas; mantener decision 1/2 columnas solo por movimiento de bloques; y forzar preview completo sin margenes.
- Revert:
- `git revert f9f7d23`
### Fix final dia: texto, modo libre y full preview
- Commit: `f363eef`
- Objetivo: reparar caracteres mojibake en UI, habilitar modo libre real para mover bloques completos y forzar modo completo con `?full=1`.
- Revert:
- `git revert f363eef`
## URL local canonica (unificada)
- Base local: `http://127.0.0.1:5001`
- Builder local: `http://127.0.0.1:5001/elementor/1`
- Regla: usar siempre `127.0.0.1` (no `localhost`) en scripts, pruebas y documentacion local.
## Arranque rapido local (Windows)
1. Desde `c:\word`, ejecutar:
- `python -m demo.app`
2. Abrir:
- `http://127.0.0.1:5001/elementor/1`
3. Verificacion rapida:
- `Invoke-WebRequest http://127.0.0.1:5001/elementor/1 -UseBasicParsing`
Notas:
- En el primer arranque puede tardar unos segundos adicionales por inicializacion de DB.
- Logs:
- `c:\word\logs_demo_app.txt`
- `c:\word\logs_demo_app.err`
## Control de rama (local/remoto)
- Rama local activa: `ai/ub24-builder-v1`
- Upstream remoto: `origin/ai/ub24-builder-v1`
- Estado al registrar: `en sync (0/0)` al 14 Febrero 2026
- Politica: commits atomicos + push por lote validado + verificacion de divergencia al inicio y al cierre.
## Fases memorizadas (builder)
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.