Snapshot: Runner fixed and plan approved for Customizer upgrade

GEMINI.md

@@ -0,0 +1,176 @@
+## Gemini Added Memories
+- El flujo principal del proyecto GKACHELE™ es:
+1. **Visita a la Landing Page (`/`):** Un visitante llega.
+2. **Solicitud de Plan:** El cliente selecciona un plan, lo que abre un menú desplegable con un formulario. Lo rellena.
+3. **Redirección al Registro (`/register`):** Al enviar el formulario, es redirigido a `/register` para completar su registro.
+4. **Creación del Sitio en Borrador (`/customizer`):** El cliente diseña su página en modo borrador.
+5. **Envío de Solicitud:** El cliente envía su sitio para aprobación.
+6. **Tu Dashboard de Administrador (`/dashboard`):** La solicitud aparece en tu panel de control.
+7. **Aprobación o Rechazo Manual:** Tú revisas la solicitud y decides si la apruebas o la rechazas.
+8. **Panel de Cliente (`/admin`):** Si apruebas, el sitio se publica y se crea el panel de gestión para el cliente.
+9. **Visualización Pública:** El sitio aprobado se hace visible al público.
+- El proyecto del usuario está desplegado en una Raspberry Pi (IP local 192.168.1.134) como un servicio systemd (`gkachele-saas.service`). La actualización de código se realiza desde su PC (WSL) copiando archivos vía scp y reiniciando el servicio en la Raspberry Pi.
+- Para levantar el entorno de prueba del proyecto en el directorio 'demo/', los pasos son: 1. Navegar a `cd demo`. 2. Instalar dependencias con `pip install -r requirements.txt`. 3. Ejecutar la aplicación con `python3 app.py`. La aplicación correrá localmente, generalmente en `http://127.0.0.1:5000`.
+- El proyecto se llama GKACHELE™ y es un SaaS (Software as a Service) para crear sitios web, al estilo de un WordPress auto-alojado.
+- El backend del proyecto GKACHELE™ es una aplicación monolítica en Python/Flask, con el código principal ubicado en el directorio `demo/`.
+- El proyecto GKACHELE™ utiliza un motor de plantillas propio (`demo/utils/theme_engine.py`) que imita la funcionalidad de WordPress y actualmente usa una base de datos SQLite (`demo/database/main.db`).
+- El despliegue actual del proyecto GKACHELE™ es un proceso manual en una Raspberry Pi, utilizando scripts `scp` y gestionando el servicio con `systemd`. El control de versiones se realiza con Gitea.
+- El objetivo principal con el proyecto GKACHELE™ es modernizarlo de forma incremental. El plan es:
+    1. **Contenerizar la aplicación con Docker.** (En progreso - Dockerfile creado).
+    2. **Automatizar los despliegues (CI/CD) usando Gitea Actions.** (LISTO - Runner configurado y funcionando).
+    3. **Configurar Secretos de Gitea.** (Pendiente por el usuario: Docker Hub y SSH keys).
+    4. **Migrar la base de datos a PostgreSQL.** (Pendiente).
+    5. **Mejorar el Customizer UI/UX.** (Próximo objetivo: Adaptar `saas-demo.html`).
+    6. **Migración final a VPS.** (Fácil después de validar Docker en la Pi. Considerar Starlink en Argentina: posible necesidad de VPN/Cloudflare Tunnel si no hay CGNAT compatible).
+- El archivo `.gitea/workflows/deploy.yml` define el workflow de CI/CD para la app GKACHELE™. Se activa con `push` a la rama `feature/docker-setup` o manualmente. Utiliza un runner `ubuntu-latest` (configurable a `self-hosted` en la Pi).
+- El workflow de despliegue requiere configurar Gitea Secrets: `SSH_HOST`, `SSH_USERNAME`, `SSH_PRIVATE_KEY`, `DOCKER_USERNAME`, `DOCKER_PASSWORD`. Estos deben ser configurados por el usuario en la UI de Gitea.
+- Los pasos del workflow de Gitea Actions incluyen: checkout de código, login a Docker Hub (o Gitea registry), build y push de la imagen Docker, y despliegue en Raspberry Pi vía SSH (docker login, pull, stop/rm, run).
+- El usuario debe commitear y hacer push del archivo `deploy.yml` a Gitea, y luego configurar los secretos necesarios en la interfaz de Gitea.
+- Un paso futuro clave es la creación de un archivo `docker-compose.yml` específico para la Raspberry Pi para gestionar el despliegue de la aplicación Flask y PostgreSQL de forma más robusta que el actual `docker run` manual.
+- El usuario de Gitea del proyecto es 'admin'. El usuario ha priorizado el funcionamiento sobre la seguridad del usuario 'admin' en este momento, con la intención de revisar la seguridad más adelante.
+- La Raspberry Pi del usuario usa el hostname `komkida.duckdns.org` para acceso SSH. La aplicación y Gitea usan `gk-saas.komkida.duckdns.org`. La URL para configurar secretos en Gitea es `http://git.gk-saas.komkida.duckdns.org/user/settings/actions/secrets`.
+- La Raspberry Pi del usuario utiliza el puerto SSH 2222. Esto debe reflejarse en la configuración de los secretos de Gitea (SSH_PORT) y en el workflow de Gitea Actions.
+- Estamos bloqueados porque Gitea Actions no está habilitado globalmente en la instancia de Gitea del usuario en la Raspberry Pi. Para habilitarlo, necesitamos editar el archivo `app.ini` en la Pi. La tarea pendiente es que el usuario me proporcione el contenido de su `app.ini` para que yo pueda analizarlo proactivamente y guiarlo en la edición. El usuario me ha pedido crear un script de diagnóstico para obtener esta información de la Pi.
+- El usuario se ha ausentado. La última acción solicitada (crear el script de diagnóstico `diagnose_gitea.sh`) fue cancelada por el usuario. El problema principal sigue siendo habilitar Gitea Actions en la instancia de Gitea de la Raspberry Pi editando el archivo `app.ini`. Se está a la espera de que el usuario regrese para retomar la tarea.
+- Contenido del archivo app.ini de Gitea en Raspberry Pi:
+--- Contenido de /home/pi/gkachele-saas/gitea/gitea_data/gitea/conf/app.ini ---
+APP_NAME = Gitea: Git with a cup of tea
+RUN_MODE = prod
+RUN_USER = git
+WORK_PATH = /data/gitea
+
+[repository]
+ROOT = /data/git/repositories
+
+[repository.local]
+LOCAL_COPY_PATH = /data/gitea/tmp/local-repo
+
+[repository.upload]
+TEMP_PATH = /data/gitea/uploads
+
+[server]
+APP_DATA_PATH = /data/gitea
+DOMAIN = git.gk-saas.komkida.duckdns.org
+SSH_DOMAIN = git.gk-saas.komkida.duckdns.org
+HTTP_PORT = 3000
+ROOT_URL = http://git.gk-saas.komkida.duckdns.org/
+DISABLE_SSH = false
+SSH_PORT = 22
+SSH_LISTEN_PORT = 22
+LFS_START_SERVER = true
+LFS_JWT_SECRET = e26UslhmO029LfMQbTLpU8Qn_MzP38Fks_snQRBjzF4
+OFFLINE_MODE = true
+
+[database]
+PATH = /data/gitea/gitea.db
+DB_TYPE = sqlite3
+HOST = localhost:3306
+NAME = gitea
+USER = root
+PASSWD =
+LOG_SQL = false
+SCHEMA =
+SSL_MODE = disable
+
+[indexer]
+ISSUE_INDEXER_PATH = /data/gitea/indexers/issues.bleve
+
+[session]
+PROVIDER_CONFIG = /data/gitea/sessions
+PROVIDER = file
+
+[picture]
+AVATAR_UPLOAD_PATH = /data/gitea/avatars
+REPOSITORY_AVATAR_UPLOAD_PATH = /data/gitea/repo-avatars
+
+[attachment]
+PATH = /data/gitea/attachments
+
+[log]
+MODE = console
+LEVEL = info
+ROOT_PATH = /data/gitea/log
+
+[security]
+INSTALL_LOCK = true
+SECRET_KEY =
+REVERSE_PROXY_LIMIT = 1
+REVERSE_PROXY_TRUSTED_PROXIES = *
+INTERNAL_TOKEN = eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYmYiOjE3Njg0OTYxMTB9.wVL_AGGU7rcilnQxINdf89bztzHr6SkFI2E3kUrR-LQ
+PASSWORD_HASH_ALGO = pbkdf2
+
+[service]
+DISABLE_REGISTRATION = false
+REQUIRE_SIGNIN_VIEW = false
+REGISTER_EMAIL_CONFIRM = false
+ENABLE_NOTIFY_MAIL = false
+ALLOW_ONLY_EXTERNAL_REGISTRATION = false
+ENABLE_CAPTCHA = false
+DEFAULT_KEEP_EMAIL_PRIVATE = false
+DEFAULT_ALLOW_CREATE_ORGANIZATION = true
+DEFAULT_ENABLE_TIMETRACKING = true
+NO_REPLY_ADDRESS = noreply.git.gk-saas.komkida.duckdns.org
+
+[lfs]
+PATH = /data/git/lfs
+
+[mailer]
+ENABLED = false
+
+[openid]
+ENABLE_OPENID_SIGNIN = true
+ENABLE_OPENID_SIGNUP = true
+
+[cron.update_checker]
+ENABLED = true
+
+[repository.pull-request]
+DEFAULT_MERGE_STYLE = merge
+
+[repository.signing]
+DEFAULT_TRUST_MODEL = committer
+
+[oauth2]
+JWT_SECRET = yHgPirRG4OmPueCt6KQqLEFM5L7ERrsIvRvxZnRY29Q
+
+[actions]
+ENABLED = true
+
+- **Gitea Runner Setup (Raspberry Pi):**
+    - **Status:** ACTIVO.
+    - **Nombre:** `rpi-runner-1`.
+    - **Etiquetas:** `linux`, `arm64`, `docker`.
+    - **Acceso:** Registrado con IP interna `http://192.168.1.134:3000` para evitar bucles NAT.
+    - **Configuración de Workflow:** Corregido para usar `runs-on: [linux, arm64]`.
+    - **Contenedor:** `rpi-gitea-runner-1` corriendo en modo daemon con reinicio automático.
+
+- **Plan de Mudanza (Argentina/Starlink):**
+    - **Contexto:** Starlink usa CGNAT, lo que dificulta abrir puertos tradicionales.
+    - **Solución Temporal:** Continuar desarrollo en local (Raspberry Pi/PC) y usar backups locales.
+    - **Solución Definitiva:** Migrar el despliegue al VPS. El flujo de CI/CD (Gitea Actions) permitirá subir el código a la nube sin depender de la IP de casa.
+    - **Backup:** Realizar hashing y copia de seguridad manual de `/home/pi/gkachele-saas` antes del traslado.
+- Los workflows de Gitea Actions del usuario se encuentran en estado 'en espera'.
+- Gitea se está ejecutando dentro de un contenedor Docker en la Raspberry Pi.
+- Estado actual de la tarea Gitea Actions:
+- **Objetivo:** Habilitar Gitea Actions que están en estado "en espera".
+- **Entorno Gitea:** Se ejecuta en un contenedor Docker en una Raspberry Pi.
+- **Versión de Gitea:** 1.25.3.
+- **Configuración app.ini:** La sección `[actions]` tiene `ENABLED = true`.
+- **Problema identificado:** Las Actions están "en espera" porque no hay ningún runner registrado o activo.
+- **Último paso intentado:** Registrar un runner usando `docker run` con la imagen `gitea/gitea-runner:latest`.
+- **Error actual:** `pull access denied` porque la imagen `gitea/gitea-runner:latest` no existe o no es la correcta.
+- **Acción pendiente:** Ejecutar el comando `docker run` corregido, utilizando la imagen correcta `gitea/act_runner:latest` para registrar el runner.
+- **Detalle del comando pendiente:**
+  ```bash
+  docker run --rm -it \
+    --name rpi-gitea-runner-1 \
+    -e GITEA_RUNNER_NAME="rpi-runner-1" \
+    -e GITEA_INSTANCE_URL="http://git.gk-saas.komkida.duckdns.org/" \
+    -e GITEA_RUNNER_TOKEN="c1izQkzx1FpmAnbMYkL8WRB9KKURyJ1vGqSjYDOe" \
+    -e GITEA_RUNNER_LABELS="linux:arm64,docker" \
+    -v /var/run/docker.sock:/var/run/docker.sock \
+    -v /opt/gitea-runner:/data \
+    gitea/act_runner:latest register
+  ```
+- **Próximo paso:** El usuario debe ejecutar el comando `docker run` corregido.
+- El usuario está frustrado por mis errores iniciales debidos a la falta de contexto (especialmente sobre Docker). Necesita que el flujo de CI/CD con Gitea Actions funcione para poder migrar el proyecto a un VPS. He prometido ser más preciso y proactivo ahora que tengo todo el contexto. La tarea pendiente es que el usuario ejecute el comando `docker run` con la imagen `gitea/act_runner` para registrar el runner.