81 lines
3.6 KiB
Markdown
81 lines
3.6 KiB
Markdown
# Memoria Codex - GKACHELE
|
|
|
|
**Fecha de corte:** 24 Febrero 2026
|
|
|
|
## Fuente de verdad
|
|
- `codex/VERSIONADO_IA.md`
|
|
- `codex/MEMORIA_CODEX.md`
|
|
- `STATE.md` (raiz del workspace, memoria operativa Docker/SaaS desde 2026-02-28)
|
|
|
|
## Estado acordado (retomar desde aqui)
|
|
- Rama activa: `ai/ub24-builder-v1`
|
|
- Checkpoint actual: `208dca9`
|
|
- Tag local de checkpoint: `builder-social-blockfx-20260224-v1`
|
|
- Base funcional estable previa: `e83e915` (tag local: `builder-stable-e83e915`)
|
|
|
|
## Estado funcional verificado
|
|
- Builder operativo en `/elementor/<site_id>`.
|
|
- Customizer unificado en una sola ruta:
|
|
- `/customizer/<id>` activo
|
|
- `/customizer2/<id>` y `/customizer3/<id>` fuera (`404`)
|
|
- Mejoras ya hechas en builder:
|
|
- menu manual con mejor mapeo a bloques reales
|
|
- drop en modo libre mas preciso
|
|
- bloque `Redes` con mas controles visuales
|
|
- controles de fondo/transicion por bloque (version inicial)
|
|
|
|
## Feedback del usuario memorizado (obligatorio)
|
|
- Hay cosas buenas en lo hecho.
|
|
- El resultado visual actual todavia se percibe "cutre".
|
|
- Las animaciones actuales no alcanzan nivel pro.
|
|
- Los fondos (sobre todo imagen de fondo) no se ven profesionales.
|
|
- Lo de `Redes` debe escalarse y aplicarse mejor a cada bloque.
|
|
- No perder este contexto ni volver a "no saber en que quedamos".
|
|
- Estandar visual confirmado por usuario: nivel premium como landing `campos-misiones`
|
|
- Hero con fondo potente y composicion pro.
|
|
- Bloques de contacto/redes con look comercial real.
|
|
- Mapas embebidos y galerias con acabado profesional.
|
|
- Botones con micro-movimiento y sombra consistente.
|
|
- Este nivel debe replicarse en plantillas y en el customizer de `word`.
|
|
|
|
## Siguiente lote acordado
|
|
1. Subir calidad visual global (no solo `Redes`) con sistema consistente por bloque.
|
|
2. Rehacer fondos animados a nivel pro (capas, movimiento elegante, control fino).
|
|
3. Rehacer transiciones/hover con calidad premium y coherencia global.
|
|
4. Mantener flujo: `1 archivo + 1 cambio + 1 prueba` por iteracion.
|
|
|
|
## Metodo operativo
|
|
- Misma rama + control por hash/revert.
|
|
- Sin push/tag sin orden explicita del usuario.
|
|
- Validacion inmediata por URL canonica:
|
|
- `http://127.0.0.1:5001/elementor/1`
|
|
- Arranque:
|
|
- `python -m demo.app` desde `c:\word`
|
|
|
|
## Memoria integrada desde STATE.md (raiz)
|
|
- Objetivo paralelo vigente: automatizacion Docker estable en `C:\word` con flujo reproducible.
|
|
- Regla activa: un solo flujo oficial de automatizacion, cambios pequenos y verificables, registro de fallo+fix.
|
|
- Flujo Docker objetivo:
|
|
1. `docker compose build`
|
|
2. `docker compose up -d`
|
|
3. `docker compose ps`
|
|
4. `docker compose logs --tail=200`
|
|
5. `docker compose restart <service>` cuando aplique
|
|
- Proximo paso operativo en esa linea: definir compose canonico unico y retirar variantes no usadas.
|
|
- Estandar visual SaaS validado (2026-02-28): referencia `Campos Misiones` como base premium replicable.
|
|
|
|
## Pendientes criticos memorizados (24 Febrero 2026)
|
|
1. Paridad real entre editor y preview final:
|
|
- lo que se ve mientras se edita debe verse igual en `/elementor/<id>/preview-final`.
|
|
2. Movimiento libre real de objetos:
|
|
- drag/reordenamiento debe funcionar estable y predecible.
|
|
3. Cache:
|
|
- revisar y corregir cache agresiva que oculta cambios recientes.
|
|
4. Ancho de bloques:
|
|
- no forzar 100% por defecto.
|
|
- permitir control real de ancho (mas angosto/mas ancho) sin romper layout.
|
|
5. Hero izquierda/derecha:
|
|
- swap de contenido debe reflejarse claramente en editor y preview final.
|
|
6. Modularizacion tecnica:
|
|
- dividir `elementor_builder.html` en archivos mas pequenos (CSS/JS por responsabilidades) para evitar regressiones y acelerar fixes.
|