admin/gkachele-saas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore(versioning): profesionalizar VERSIONADO_IA y limpiar protocolo

Browse Source
This commit is contained in:
komkida91
2026-02-19 23:54:18 +01:00
parent 8ae0017533
commit e3a1c9d17f
1 changed files with 79 additions and 344 deletions
Download Patch File Download Diff File Expand all files Collapse all files

419
codex/VERSIONADO_IA.md
View File

@@ -1,373 +1,108 @@
# Versionado IA - UB24 / Elementor # Versionado IA - UB24 / Elementor
## Rama de trabajo ## 1) Objetivo
- `ai/ub24-builder-v1` Definir un proceso de versionado auditable, reproducible y estable para el desarrollo del builder UB24.
## Estado de sincronizacion (14 Febrero 2026) ## 2) Estado actual verificado
- Local: `ai/ub24-builder-v1` - Fecha de verificacion: `2026-02-19`
- Remoto: `origin/ai/ub24-builder-v1` - Rama activa: `ai/ub24-builder-v1`
- Divergencia verificada: `0/0` (sin commits pendientes entre local y remoto) - Upstream: `origin/ai/ub24-builder-v1`
- Divergencia local/remoto: `0 0`
- Comando usado:
- `git rev-list --left-right --count ai/ub24-builder-v1...origin/ai/ub24-builder-v1`
## Regla de trabajo ## 3) Politica de versionado
1. Cada cambio funcional se guarda en un commit separado. 1. Commits atomicos por cambio funcional.
2. Cada commit se registra con su hash. 2. Mensajes bajo convencion semantica.
3. Cada commit debe incluir comando de reversion rapida. 3. Reversion siempre definida por commit.
4. La rama debe quedar sincronizada con remoto al cerrar bloque de trabajo. 4. Cada bloque validado se empuja a remoto.
5. No mezclar cambios de infraestructura con cambios de UX en el mismo commit.
## Convencion de mensaje ## 4) Convencion de commits
- `feat(builder): ...` - `feat(builder): ...`
- `fix(builder): ...` - `fix(builder): ...`
- `refactor(builder): ...` - `refactor(builder): ...`
- `chore(versioning): ...` - `chore(versioning): ...`
- `docs(builder): ...`
## Flujo con Gitea ## 5) Flujo obligatorio por sesion
1. Trabajo local en `ai/ub24-builder-v1`. 1. Verificar rama activa:
2. Push continuo a `origin/ai/ub24-builder-v1`. - `git branch --show-current`
3. Merge cuando validemos en local y Raspberry. 2. Actualizar referencias remotas:
- `git fetch origin --prune`
## Protocolo fijo de sincronizacion (siempre) 3. Verificar divergencia:
1. Verificar rama activa: `git branch --show-current` - `git rev-list --left-right --count ai/ub24-builder-v1...origin/ai/ub24-builder-v1`
2. Actualizar referencias remotas: `git fetch origin --prune` 4. Si no es `0 0`, sincronizar antes de editar.
3. Medir divergencia: `git rev-list --left-right --count ai/ub24-builder-v1...origin/ai/ub24-builder-v1` 5. Al cerrar lote validado:
4. Si el resultado no es `0 0`, sincronizar antes de continuar.
5. Despues de cada lote validado:
- `git add <archivos>` - `git add <archivos>`
- `git commit -m "tipo(scope): mensaje"` - `git commit -m "tipo(scope): mensaje"`
- `git push origin ai/ub24-builder-v1` - `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) ## 6) Protocolo de arranque local
1. Levantar entorno al iniciar cada sesion, sin esperar pedido del usuario. - Comando canonico:
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` - `python -m demo.app`
2. Abrir: - URL canonica:
- `http://127.0.0.1:5001`
- Builder:
- `http://127.0.0.1:5001/elementor/1` - `http://127.0.0.1:5001/elementor/1`
3. Verificacion rapida: - Verificacion rapida:
- `Invoke-WebRequest http://127.0.0.1:5001/elementor/1 -UseBasicParsing` - `Invoke-WebRequest http://127.0.0.1:5001/elementor/1 -UseBasicParsing`
Notas: ## 7) Criterios de estabilidad (no negociables)
- En el primer arranque puede tardar unos segundos adicionales por inicializacion de DB. 1. No tocar funcionalidades estables sin requerimiento explicito.
- Logs: 2. Mantener una sola estrategia de layout y DnD por flujo.
- `c:\word\logs_demo_app.txt` 3. Mantener una sola ruta de guardado activa:
- `c:\word\logs_demo_app.err` - `/api/elementor/save`
4. Validar guardado/publicacion antes de cerrar lote.
5. Evitar cambios amplios si un fix local resuelve el problema.
## Control de rama (local/remoto) ## 8) Registro de commits relevantes
- Rama local activa: `ai/ub24-builder-v1` | Fecha | Commit | Tipo | Objetivo | Revert recomendado |
- Upstream remoto: `origin/ai/ub24-builder-v1` |---|---|---|---|---|
- Estado al registrar: `en sync (0/0)` al 14 Febrero 2026 | 2026-02-14 | `cb99f26` | chore | Crear rama y politica inicial de versionado IA | `git revert cb99f26` |
- Politica: commits atomicos + push por lote validado + verificacion de divergencia al inicio y al cierre. | 2026-02-14 | `fe8657e` | fix | Revertir commit no deseado y limpiar historial | `git revert fe8657e` |
| 2026-02-14 | `22e564e` | fix | Robustecer arranque local/theme load en Windows | `git revert 22e564e` |
| 2026-02-14 | `1c04f04` | feat | Mejora visual base (hero/features/cards/contact) | `git revert 1c04f04` |
| 2026-02-14 | `7c5f671` | fix | Limpieza preview/menu y ajustes de ancho | `git revert 7c5f671` |
| 2026-02-14 | `dd98e9d` | fix | Preview limpio y menu por modos | `git revert dd98e9d` |
| 2026-02-15 | `1a5778b` | refactor | Runtime unificado `python -m demo.app` + blueprint Elementor | `git revert 1a5778b` |
| 2026-02-15 | `8ac360b` | feat | Educacion V2 + correccion de anclas | `git revert 8ac360b` |
| 2026-02-15 | `f6d8ab1` | fix | Corregir wrapper SQLite para evitar fallo de arranque | `git revert f6d8ab1` |
| 2026-02-15 | `b6fb4da` | feat | API dedicada `/api/elementor/save` con opcion publicar | `git revert b6fb4da` |
| 2026-02-15 | `c2ee81d` | fix | Persistencia de bloques + feedback de publish | `git revert c2ee81d` |
| 2026-02-15 | `e20f086` | fix | Preview full-page y layout estable por secciones | `git revert e20f086` |
| 2026-02-15 | `e5df6de` | feat | Full width + soporte real de 2 columnas | `git revert e5df6de` |
| 2026-02-15 | `a6089ee` | feat | Drag inteligente por drop + preview en nueva pestana | `git revert a6089ee` |
| 2026-02-15 | `f9f7d23` | fix | Quitar layout global y forzar preview completo | `git revert f9f7d23` |
| 2026-02-15 | `f363eef` | fix | Correccion de texto/UI + modo libre + `?full=1` | `git revert f363eef` |
| 2026-02-16 | `6f14308` | fix | Unificar layout y estabilizar redimension en canvas | `git revert 6f14308` |
## Fases memorizadas (builder) ## 9) Decisiones funcionales vigentes
1. Fase 1 (UI Pro base): navbar premium, hero premium, sistema de espaciado/grid, pulido visual consistente. - Rubros oficiales permitidos:
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` - `restaurante`
- `danza` - `danza`
- `cosmeticos` - `cosmeticos`
- `despachos` - `despachos`
- `gimnasios` - `gimnasios`
- `educacion` - `educacion`
- `base_otro` (`Base (Otro)`) - `base_otro`
- Preview final separada habilitada:
- TAG: `PREVIEW_FINAL_SEPARADA`
- Se agrega flujo dedicado de preview final real separado del hash del editor:
- `GET /elementor/<site_id>/preview-final` - `GET /elementor/<site_id>/preview-final`
- `GET /ub24/<site_id>/preview-final` - `GET /ub24/<site_id>/preview-final`
- En preview final: - Motor de reordenamiento seleccionado para DnD:
- se fuerza `preview-mode` desde servidor (`preview_only=true`), - `SortableJS` (estrategia unica)
- boton `Atras` vuelve al builder base.
- TAG: `UNIFICACION_TOPBAR_Y_DRAWER_FIX` ## 10) Pendientes priorizados
- Ajustes aplicados: 1. Footer global obligatorio con autoria del proyecto.
- se elimina duplicidad operativa de preview en topbar y se deja `Pagina real` como flujo principal, 2. Watermark de autoria en codigo bajo convencion unica.
- selector de plantillas migra a `Plantillas por rubro` (catalogo oficial), 3. Flujo dual estable de preview (editor/pagina real).
- `Drawer Pro` se mueve a capa global para evitar render roto dentro del bloque/canvas, 4. Correccion de menu superior en modo acordeon.
- etiqueta de pagina `Servicios` se neutraliza a `Seccion 2` para no mezclar paginas con rubros. 5. Mejora de interaccion touch/capacitiva del builder.
## Registro infraestructura Raspberry (17 Febrero 2026) ## 11) Referencias cruzadas
- TAG: `KOMKIDA_WEB_ACCESS_RECOVERY` - Historial funcional detallado: `codex/HISTORIAL_CAMBIOS.md`
- Objetivo: recuperar `komkida.duckdns.org` como acceso web remoto a Raspberry con login (estilo Motion), sin romper: - Arranque rapido local: `codex/ARRANQUE_RAPIDO_UB24.md`
- `gk-saas.komkida.duckdns.org` - Flujo general del proyecto: `codex/FLUJO_PROYECTO.md`
- `git.gk-saas.komkida.duckdns.org`
- `motion.komkida.duckdns.org`
### Diagnostico real ## 12) Nota operativa
1. El `502 Bad Gateway` en subdominios (`gk-saas`, `git`, `motion`) venia por `proxy_pass http://localhost:PUERTO`: Este archivo define el estandar de trabajo. Cualquier cambio de proceso debe registrarse en un commit `chore(versioning)` y quedar reflejado aqui.
- 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.