admin/gkachele-saas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
8ae00175339e4641e787c5e75e09740e54d00f09
gkachele-saas/codex/VERSIONADO_IA.md

17 KiB
Raw Blame History

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:

Educacion V2 + regla token

  • Commit: 8ac360b
  • Objetivo: mejorar template de Educacion (V2), corregir navegacion por anclas en menu/CTA y fijar regla operativa para sesiones con pocos tokens.
  • Revert:
    • git revert 8ac360b
    • 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
  1. El builder cargará esas arquitecturas base y luego se edita contenido.
  2. 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.

Reference in New Issue View Git Blame Copy Permalink