Auditoría y Simplificación de Servicios Auxiliares · plan multi-fase

Apodo canónico del plan

“Plan Servicios” (registrado s66 · 16-05-2026 tarde). Cualquier referencia en futuras sesiones a “Plan Servicios” debe resolverse a este ADR + catálogo asociado.

Contexto

Tras 6+ meses de desarrollo intensivo del SaaS CreaRack Pro + plataforma Workspace + método claude-method, el sistema ha crecido en alcance y dependencias externas a una velocidad superior a la capacidad de cualquier humano del equipo (de 3 personas) para mantener el mapa mental completo.

Preocupación operativa explícita del CEO (Edu · 16-05-2026):

“Hemos creado innumerables sistemas de automatización para disparar crons, o enlazar servicios (Resend, Cloudflare, GitHub, servidores en Hetzner, etc.). Soy incapaz de recordar todo este enjambre de servicios auxiliares de los que depende el SaaS CreaRack y nuestra plataforma Workspace, incluso nuestro claude-method. Me pregunto qué podemos hacer para unificar y poner en orden, es decir simplificar todo esto.”

Síntomas observables:

• No existe inventario centralizado de servicios externos (cuentas, costes, owners, criticidad).
• Credenciales dispersas (Dokploy panel · CF Pages env · GitHub secrets/vars · Hetzner SSH keys · .env locales · settings.local.json · MEMORY personal de Claude).
• Crons distribuidos entre GitHub Actions, servidor STAGE Hetzner, cron del PC personal de Edu (residual, ya migrado en s39 según Regla 17), y Cloudflare Workers.
• Servicios SaaS contratados (algunos free, otros paid) sin auditoría reciente: ¿pago algo que no uso? ¿hay duplicidades?
• Sensación de “perder el control” a medida que se delega cada vez más en SaaS externos.

Decisión

Ejecutar plan en 3 fases independientes. Cada fase entrega valor por sí sola sin depender de las siguientes — punto de parada/evaluación tras cada una.

Fase A · Auditoría y Catálogo (prioridad ALTA · estimado 1-2 sesiones)

Objetivo: tener un mapa completo y vivo de TODOS los servicios externos del proyecto.

Entregables:

1. Wiki page tech entity--ops--catalogo-servicios-externos (workspace-tech) con tabla completa:
   • Nombre del servicio · función · proveedor
   • Cuenta (Edu / CreaRackSL / Esferic Labs / personal) · email asociado
   • Coste mensual estimado · plan contratado
   • Criticidad (alta = PROD caería · media = degradación · baja = nice-to-have)
   • Dónde viven las credenciales (sitio canónico)
   • Owner funcional (Edu / Dani / Txell)
   • Qué hace si cae · ¿hay fallback?
   • Última verificación / revisión
2. Dashboard visual en el workspace (/services o panel en /dashboard) → DESCARTADO 16-05-2026 tarde: refinamiento UX directo de la wiki page del catálogo en lugar de página nueva. Valor entregado equivalente sin código adicional (sección “Si esto cae, cae el negocio” + tabla “Para Txell · qué facturamos” agrupada por cuenta pagadora + columna Panel billing en tabla resumen).
3. Memoria personal Claude actualizada con referencias.

Criterio de éxito:

• Si Edu/Dani/Txell preguntan “qué servicios usamos para X” se puede contestar en <30 seg con doc en mano.
• Total coste mensual aproximado conocido (suma de los planes contratados).

Fase B · Limpieza (prioridad MEDIA · estimado 1 sesión)

Objetivo: eliminar redundancias y desorden detectados en Fase A.

Acciones esperadas (priorizadas tras auditoría):

• Cerrar cuentas abiertas y no usadas (servicios probados y abandonados).
• Consolidar servicios duplicados (típico: ¿UptimeRobot + CF Healthcheck + Prometheus = todos miran lo mismo?).
• Matar crons huérfanos (Task Scheduler personal residual, Workers Cloudflare obsoletos).
• Centralizar credenciales en un sitio canónico (probablemente página wiki cifrada o gestor estilo Bitwarden personal del equipo).
• Documentar cada eliminación con razón.

Criterio de éxito: ≥3 cuentas/servicios eliminados o consolidados. Credenciales con sitio canónico documentado.

Fase C · Migración selectiva a Hetzner (prioridad BAJA · multi-sesión · OPCIONAL)

Objetivo: migrar a infraestructura propia SOLO los servicios donde el cálculo de “control + ahorro” supera al de “mantenimiento + complejidad”.

Lista probable a migrar (revisar tras Fase A):

• ✅ GitHub Actions self-hosted runner: minutos ilimitados sin cap. 1 runner en STAGE Hetzner cubre ambos repos.
• ✅ Uptime monitoring: Uptime Kuma self-host (Docker) reemplaza UptimeRobot · más checks + status page propia.
• ✅ Crons Bibliotecario (Curator/Lint/Catalog/Utility/Weekly-Report): mover a cron del host Hetzner · sin Actions ni cap.
• ⚠️ Status page / alertas centralizadas: candidato menor, evaluar.

Lista explícita de NO migrar (decisión consciente · refractaria a “second-system effect”):

Criterio de éxito: solo se aborda si Fase A+B revelan dolor real persistente. Cada migración individual debe pasar test “¿da más control neto o más mantenimiento?”.

Alternativas consideradas y descartadas

Alternativa 1 · Self-host everything en un Hetzner dedicado

Rechazada — el cálculo no sale:

• Cloudflare edge no es replicable a esta escala.
• Email reputation requiere IPs con historial limpio (meses-años de “warm-up”).
• Code hosting + CI propio = más mantenimiento que valor añadido.
• Tiempo del equipo (3 personas) es 10x más caro que los $30-50/mes en SaaS.

Alternativa 2 · No hacer nada

Rechazada — el problema crece. Cada nuevo servicio añade peso al “enjambre” sin documentar el anterior.

Alternativa 3 · Solo auditoría y documentación (sin Fase B/C)

Válida y conservadora. Plan elegido incluye Fase B (limpieza) porque tras documentar suelen aparecer obvios. Fase C queda explícitamente opcional.

Consecuencias

Esperadas positivas

• Mapa mental claro para los 3 miembros del equipo (igualdad de accesos · Regla 24).
• Ahorro tiempo búsqueda de info (“¿dónde está la API key de Resend?” → 1 click).
• Reducción de la angustia operativa del CEO.
• Ahorro €/mes marginal (cuentas no usadas · planes sobre-dimensionados).
• Posibilidad de recuperar control real sobre componentes específicos (Fase C).

Esperadas negativas / riesgos

• Tiempo invertido en auditoría (estimado 3-5h totales · A+B).
• Si Fase C avanza demasiado, riesgo de “second-system effect”: querer migrar más de lo razonable.
• Documentación que requiere mantenimiento (drift como cualquier doc).

Mitigaciones

• Fases independientes con puntos de parada explícitos.
• Lifecycle de la wiki page del catálogo: refresh-30d (el Bibliotecario marcará verification_pending para forzar revisión mensual).
• Tras cada fase, revisar valor entregado vs coste y decidir si continuar.

Criterios de éxito globales (medibles a 3 meses)

• A: 0 servicios externos sin documentar en el catálogo. ✅ 22 servicios catalogados (16-05-2026).
• B: ≥3 cuentas eliminadas o consolidadas + credenciales centralizadas. 2/3 + pendiente (DeepSeek + GroupDocs revocadas · credenciales centralizadas pendiente decisión equipo task #33).
• C (si se aborda): ≥1 servicio migrado con éxito a Hetzner sin regresiones. No iniciada (declarada OPCIONAL).
• Subjetivo CEO: Edu reporta menos angustia operativa al pensar en “todo lo que depende el proyecto”. Pendiente evaluar a 3 meses.

Estado

• 16-05-2026 (s66 mañana): ADR firmado por Edu. Inicio Fase A.
• 16-05-2026 (s66 tarde): Fase A cerrada al 90% — audit completo (22 servicios catalogados · 5 descubrimientos resueltos: DeepSeek ⛔ inactivo, groupdocs ⛔ inactivo, Zoho solo Mail, CF Workers AI crítico, Spinetix no-SaaS). Fase B parcialmente avanzada como bonus — 2 cleanups quirúrgicos ejecutados (PR #36 DeepSeek bcebf38b -36 LOC · PR #37 groupdocs 465782c0 -94 LOC) + 1 security fix bonus detectado por audit crons (PR #38 python-multipart 66a4e753 CVE GHSA-pp6c-gr5w-3c5g resuelto, Agent v2.0.20). 3 acciones manuales completadas por Edu (revocación API keys DeepSeek + GroupDocs + rebuild Agent + distribución).
• 16-05-2026 (s66 noche · CIERRE OPERATIVO 95%): Plan Servicios declarado cerrado operativamente al 95% (decisión Edu). Fase A 95% (refinamiento UX wiki commit ee33e8bf cierra dashboard descartado). Fase B 50% (cleanups + audit crons + security bonus + Agent .exe subido a release). Fase C OPCIONAL, postponed. Los 2 pendientes restantes (#31 costes reales · #33 decisión credenciales) quedan vivos en MCP tasks workspace con due_date — no bloquean nada técnico y se irán resolviendo asíncronamente. ADR queda como referencia viva del estado; cualquier reapertura futura (ej. iniciar Fase C) crea nueva entrada de estado fechada.

Pendientes vivos (delegados a tasks MCP workspace)

Los 2 pendientes que quedan abiertos tras cierre operativo, ambos con due_date y owner:

1. Costes mensuales reales (task MCP #31 · Edu · due 23-05-2026) — Anthropic Plan Max × 3 + Google AI Studio Paid + Holded + Zoho Mail + Tailscale. Requiere acceso de Edu a paneles externos. Estimado 30min total. Actualizar tabla “Coste mensual aproximado” del catálogo wiki al recopilar.
2. Decisión credenciales centralizadas (task MCP #33 · Equipo · due 30-05-2026) — Bitwarden Free/Premium Families vs 1Password Teams vs KeePass self-host vs status quo. Requiere reunión Edu+Dani+Txell. ADR resultante decision--202605XX--credenciales-centralizadas. Estimado 30min reunión + escritura ADR.

Los pendientes originales #32 (dashboard /services) y “crons huérfanos” están resueltos (refinamiento wiki + audit 0 huérfanos respectivamente).

Reapertura futura

Reabierta el 10-09-2026 (s320) como decisión nueva: plan public/supercontext/stack-servicios/PLAN_STACK_SERVICIOS.md (task #298), en tres tiempos: mapa vivo (hecho ese día: catálogo refrescado + inventario automático semanal en OPS con aviso a infra@), estrategia de hospedaje propio (storm → roast → ADR nuevo), migraciones una a una. De la lista “probable a migrar” de la fase C ya están hechas de facto: runners self-hosted y crons del Bibliotecario en OPS (julio 2026); Uptime Kuma sigue como candidato. La lista de “NO migrar” se mantiene como principio, salvo GitHub, que con Forgejo en espejo (F1) pasa a deliberación.

Fase C (migración Hetzner) puede iniciarse en cualquier momento futuro como sub-iniciativa independiente. Crear nueva ADR decision--202607XX--fase-c-migracion-hetzner si se decide proceder (no reabrir este ADR — cada fase con su trazabilidad).

Catálogo de servicios (entity--ops--catalogo-servicios-externos): mantenimiento continuo vía lifecycle: refresh-30d. El Bibliotecario marca verification_pending cada 30 días. Owner del refresh: Edu.

Véase también

• [[ia-tech—automatismos—metodo—github-actions-presupuesto]]
• [[ia-tech—inventario-automatismos]]
• [[decision—20260514—saneamiento-docs-periodico]]