368 lines
16 KiB
Markdown
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.
|