3a3563f2a0
Cambios aplicados desde epsylon/oasis 3d46340 (0.7.6):
NUEVO MÓDULO Graphos (mapa interactivo de la red):
- src/views/graphos_view.js (nuevo)
LÓGICA:
- src/backend/nameCache.js (nuevo) — NameAuthor resolver
- src/models/chats_model.js — encriptación E2E
- src/models/calendars_model.js — E2E + calendar invites con códigos
- src/models/maps_model.js — E2E + CLOSED enforcement
- src/models/tribes_model.js — sub-tribe access control (PRESERVA nuestro inviteLog)
- src/models/tribe_crypto.js — soporte E2E
- src/models/main_models.js — refactor (PRESERVA nuestro pub-invite SSB msg)
- src/models/{activity,banking,pads,search,stats,tags,tribes_content}_model.js
- src/backend/backend.js — searchModel constructor + new helpers (errorView, safeRefererRedirect)
- src/backend/blobHandler.js, renderTextWithStyles.js
- src/views/main_views.js — añadido userLink/userLinkLabel + nameCache import (mantiene nuestro hamburger menu)
VISUAL:
- 31 views actualizadas con refactor a userLink helper
- src/views/peers_view.js — tabla con keys clicables
- src/views/stats_view.js — dashboard avanzado
- src/client/assets/styles/style.css — merge (preserva nuestras adiciones QR/mobile)
- Temas desktop: Clear, Dark, Matrix, Purple
- Translations 11 idiomas (ar, de, en, es, eu, fr, hi, it, pt, ru, zh)
- src/configs/{config-manager,oasis-config}, server/SSB_server.js, oasis_client.js
SKIPS (intencionalmente):
- OasisMobile.css del upstream (mantenemos NUESTRO mobile.css y theme)
- main_views.js menu reorganization (mantenemos hamburger nav)
- @xenova/transformers (LLM, no viable mobile)
- node-llama-cpp (build nativo no soportado en arm64 mobile)
- pdfjs-dist (pendiente probar luego)
- AI/embedder.js + AI/routes_index.js (dependen de las libs LLM)
server/package.json: version 0.7.5 → 0.7.6
AUTOMATIZACIÓN:
- Nueva carpeta AUTOMATIZACION/ con 10 archivos:
- 4 opciones (cron simple, multi-agente, GitHub Actions, webhook)
- Setup Debian completo paso a paso
- Scripts bash listos: scout, merger, builder, notify-telegram
- Prompts listos para los agentes
- Sección /testing-app para 0asis.net
- Human-in-the-loop: archivos prohibidos para auto-merge
PENDIENTE: build APK (el bash tool tuvo timeouts; usar comandos
de CONTEXT/cambio_apk_repack.txt manualmente).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
102 lines
3.1 KiB
Text
102 lines
3.1 KiB
Text
===============================================================
|
|
OPCIONES DE AUTOMATIZACIÓN — Comparativa
|
|
===============================================================
|
|
|
|
OPCIÓN A — CRON + CLAUDE HEADLESS (SIMPLE)
|
|
==========================================
|
|
Un cron semanal en Debian. Un único script que invoca claude
|
|
con un prompt grande pidiendo que lo haga todo de cabo a rabo.
|
|
|
|
PROS:
|
|
- Setup en 30 minutos
|
|
- Sin infra extra (solo cron)
|
|
- Cero costes adicionales
|
|
|
|
CONTRAS:
|
|
- Un único punto de fallo
|
|
- Si claude se atasca en un conflicto, todo se queda colgado
|
|
- Sin recuperación parcial
|
|
- Difícil debuggear cuándo va mal
|
|
|
|
CUÁNDO USARLA:
|
|
- Cuando solo se quiere probar el concepto
|
|
- Cuando los cambios upstream son pequeños y predecibles
|
|
|
|
|
|
OPCIÓN B — MULTI-AGENTE (RECOMENDADA)
|
|
=====================================
|
|
Tres agentes especializados en cron. Cada uno con su prompt
|
|
corto, su contexto, y su responsabilidad clara.
|
|
|
|
scout | Lun 03:00 | git fetch + analiza diff + reporta
|
|
merger | Lun 04:00 | aplica cambios safe + abre PR
|
|
builder | Lun 05:00 | build APK + sube + notifica
|
|
|
|
PROS:
|
|
- Fallo aislado (si scout falla, merger no se ejecuta)
|
|
- Prompts cortos = menos tokens = más barato y fiable
|
|
- Logs separados por agente
|
|
- Recuperable: puedes re-ejecutar solo el que falló
|
|
- Auditable: cada agente deja su reporte en disco
|
|
|
|
CONTRAS:
|
|
- Más setup inicial (3 crons, 3 prompts)
|
|
- Hay que orquestar dependencias (merger depende de scout)
|
|
|
|
CUÁNDO USARLA:
|
|
- Cuando los cambios upstream son frecuentes y variados
|
|
- Cuando quieres ver QUÉ va a aplicar antes de aplicarlo
|
|
|
|
|
|
OPCIÓN C — GITHUB ACTIONS
|
|
=========================
|
|
Workflow en .github/workflows/weekly-merge.yml del repo
|
|
oasis_mobile. Trigger en cron + manual dispatch.
|
|
|
|
PROS:
|
|
- Gratis (2000 min/mes en repo público o privado básico)
|
|
- Histórico completo de runs visible
|
|
- Artifacts descargables (la APK)
|
|
- Logs públicos si lo quieres
|
|
- Cero infraestructura propia
|
|
|
|
CONTRAS:
|
|
- Timeout máximo 6h por job
|
|
- Build APK consume bastante (10-15 min)
|
|
- El repo debe estar en GitHub (no en Gitea code.03c8.net)
|
|
- Secrets: ANTHROPIC_API_KEY visible para todos los maintainers
|
|
|
|
CUÁNDO USARLA:
|
|
- Si planeas mover el repo a GitHub
|
|
- Si no tienes VPS o no quieres gestionarlo
|
|
|
|
|
|
OPCIÓN D — WEBHOOK REACTIVO
|
|
===========================
|
|
Webhook de GitHub apuntando a un endpoint en tu VPS. Cuando
|
|
epsylon publica un release, dispara inmediatamente el pipeline.
|
|
|
|
PROS:
|
|
- Reacción casi en tiempo real (segundos)
|
|
- No esperas al cron del lunes
|
|
- El pipeline puede ser tan complejo como quieras
|
|
|
|
CONTRAS:
|
|
- Requiere VPS público con dominio + HTTPS
|
|
- Hay que mantener el endpoint
|
|
- Si el webhook falla, hay que tener un cron de respaldo
|
|
|
|
CUÁNDO USARLA:
|
|
- Cuando quieres lo más rápido posible
|
|
- Cuando tienes ya un VPS funcionando
|
|
|
|
|
|
COMBINACIÓN RECOMENDADA: B + D
|
|
==============================
|
|
- Webhook (D) dispara scout (de B)
|
|
- Cron de seguridad cada lunes 03:00 también ejecuta scout
|
|
(por si el webhook falla)
|
|
- Resto del pipeline (merger + builder) es B
|
|
|
|
Mejor de los dos mundos: rápido pero con respaldo, modular,
|
|
auditable, recuperable.
|