Saltar a contenido

ADR-023 · Política de migración illanes00 → CIS (transferencia de artefactos vps-dev → vps-cis)

Fecha: 2026-05-04 Source: /srv/projects/cis/cis-plan/DECISIONS.md (do not edit here — re-split desde la fuente)

Contexto

La auditoría agent-V-vpsdev-audit (2026-05-03, docs AUDIT-VPSDEV-2026-04.md + TRANSFER-PLAN-VPSDEV-CIS.md) inventarió vps-dev (74.208.113.138, host personal de Martín) y detectó que ~120 services systemd y ~80 sites Caddy conviven en 5 divisiones: core/, illanes00/, cds/, cds/cis/, cochid/, foresight/. El subset cds/cis/* contiene 24 sub-repos cuyos artefactos pertenecen — por contenido funcional y misión — a CIS SpA, pero residen en un VPS arrendado por Martín como persona natural. Cuatro servicios CIS productivos corren dual-running ahí mismo: cis-platform (:8176, caddy cis.circulodesantiago.cl), cis-claudia-backend (:8172, caddy claudia.circulodesantiago.cl), cis-librospa (:8148, caddy libro.circulodesantiago.cl), cis-usaia (:8109, caddy usaia.cl).

Hasta hoy no existe política canónica para clasificar qué se queda personal vs qué migra a CIS, ni cómo se documenta legalmente la transferencia. Esto produce tres problemas:

  1. Continuidad operativa CIS depende de infra personal: si Martín pierde acceso a vps-dev, CIS queda offline parcialmente. Bloqueante para legalmente independizar la SpA (ver CONSTITUTION.md §riesgos).
  2. Titularidad ambigua de IP: repos cds/cis/cis-* viven en un sub-dir cuyo dueño legal es Martín (alquila el VPS), pero el contenido funcional es propiedad CIS. Sin contrato de cesión, hay riesgo de disputa futura (especialmente si entra capital externo).
  3. Drift de secretos: vps-dev usa .env files, vps-cis usa CLI vault. Cada migración requiere re-sync manual de credenciales y, si no se hace, se rompen integraciones (ver caso cis-claudia ANTHROPIC_API_KEY reportado en CHANNEL 04-29 08:23, destrabado por la auditoría).

Alternativas consideradas

  1. (a) Migración Big-Bang en una ventana única
  2. Pro: corte limpio, claridad legal inmediata.

  3. Contra: 4 servicios productivos + 4+ duales en transición = downtime medible. DNS cutover masivo CF en una sola noche es alto riesgo.

  4. (b) Política de waves con criterios de clasificación + plan de transferencia ejecutable ← propuesta

  5. Pro: matchea la realidad (cada artefacto tiene status distinto: dual-running, ya cortado, sólo vps-dev). Permite Wave 1 corto (servicios duales más críticos), Waves 2-4 limpieza y migración plana de clusters (periodismo2, situacion). Vault/DNS sync staged con TTL bajo previo.

  6. Contra: requiere disciplina de tracking — qué wave está pendiente, qué se cortó. Mitigado por la matriz en TRANSFER-PLAN-VPSDEV-CIS.md.

  7. (c) Status quo (no migrar, contrato de licencia per-artefacto)

  8. Pro: cero esfuerzo técnico.
  9. Contra: no resuelve continuidad ni titularidad. Cualquier ronda de capital o adquisición CIS encuentra IP fuera del balance. Inviable a 12 meses.

Decisión: (b) — política canónica de clasificación + waves de migración.

1. Criterios de clasificación

Cada artefacto en vps-dev se clasifica vía decisión humana en una de cinco categorías:

Categoría Símbolo Criterio Destino Implicación legal
Personal canónico ✳️ Producto Martín (illanes00., foresight., lepp., dev-, democracia., kiosk.). Sin equivalente CIS. Queda en vps-dev. Activo personal. Sin transfer.
CIS migra (canónico vps-cis ya) ✅ Existe init bulk en vps-cis y ya no corre service en vps-dev (o corre sólo legacy). Borrar de vps-dev tras verificar git history en vps-cis. Activo CIS. Cesión implícita por residencia.
CIS dual-running 🔁 Service activo en AMBOS hosts. Caddy en vps-dev sigue apuntando a localhost. Drift de código o env. Cortar vps-dev tras vault-sync + DNS cutover. Activo CIS. Cesión formal en este ADR.
CDS holding 🟡 cds-www, cds-admin, cds-sopapo, cds-{agenda,cultura,estarbien,negocios}, cds-api, cds-docs. Queda en vps-dev (CDS = matriz, distinto SpA). Decisión separada para hosting CDS futuro. Activo CDS, no CIS. Fuera de alcance ADR-023.
Drift / merge-required 🔶 Repo con histórico canónico en vps-dev y init bulk en vps-cis (caso illanes00-server ↔ cis-core con apps.yaml refactor). Cherrypick / rebase + decisión humana sobre cuál es canónico. Fork legítimo: el origen queda personal, el fork CIS-only.

Regla de decisión: el criterio "es operacional para CIS" lo aplica el operador (Martín o agente Claude con FES) caso por caso, no automáticamente. Si un artefacto pasa el criterio, se evalúa migration; si no, queda en vps-dev como activo personal.

Cuando un artefacto migra de vps-dev (Martín persona natural) a vps-cis (CIS SpA, RUT 78.024.330-7), se asume cesión gratuita de propiedad intelectual de Martín a CIS, materializada por:

  • Acto material: rsync con .git completo + arranque de service en vps-cis + cutover de Caddy + DNS A record CF apuntando a 108.175.4.190. La residencia en infra CIS es el acto de cesión.
  • Soporte documental: entry en CHANNEL.md con tag [migration] <artefacto> · vps-dev → vps-cis · wave <N> · receipt <fes_id>. CHANNEL queda como bitácora legal de cesión (ver ADR-027 sobre CHANNEL como contexto compartido).
  • Cap-table: la cesión gratuita NO genera dilución ni obliga a reasignación de equity. Se asume como aporte tácito de Martín a CIS pre-funding (CONSTITUTION.md §3 cláusula "founder contribution"). Si entra capital externo y un auditor objeta, se firma un contrato simbólico retroactivo (CLP $1) cubriendo el batch de artefactos migrados.
  • Licencia intra-company alternativa: para artefactos donde Martín prefiere conservar titularidad personal mientras CIS los usa (caso ambiguo: core-server / illanes00-server ↔ cis-core fork), se firma licencia perpetua, gratuita, no-exclusiva, sin obligación de fuente. Cláusula de salida: si Martín deja de operar CIS, la licencia sigue vigente para los assets ya entregados.

Trigger de evaluación: ningún artefacto migra sin que el operador haya validado los cinco criterios de clasificación. Default cuando ambiguo: licencia intra-company (no cesión gratuita) — proteje al CEO de ceder más de lo necesario.

3. Proceso técnico canónico (per artefacto migrado)

Secuencia obligatoria en orden, con audit a cada paso:

  1. Pre-flight checks:
  2. Diff git log entre vps-dev y vps-cis. Identificar histórico canónico (vps-dev casi siempre lo es, salvo init bulk vs init bulk).
  3. Listar .env keys en vps-dev → mapear a vault namespace target (cis-<svc> típico).

  4. Verificar A record CF actual del dominio (74.208.113.138 vs 108.175.4.190).

  5. Vault sync: replicar secrets a vault vps-cis con vault_set(project="cis-<svc>", key=K, value=V). FES-gated según ADR-026 si el namespace es sensible (cualquier *_KEY / *_TOKEN / *_PASSWORD).

  6. Git remote sync: si el repo tiene remote GitHub canónico (caso periodismo2, situacion), git fetch desde GitHub a vps-cis. Si no, rsync .git directorio completo desde vps-dev (rsync -avz cds/cis/<repo>/.git/).

  7. services.yaml seed: añadir entry en /srv/projects/cis/services.yaml con slug, port, type, marketplace_status='internal' (default ADR-022). Promotion sigue lifecycle ADR-022.

  8. systemd unit: copiar/regenerar <svc>.service desde template (ver ADR-025 topology). EnvironmentFile apunta a /srv/secrets/<svc>.env generado vía vault_dump.

  9. DNS cutover: bajar TTL del record a 5 min ≥1 h antes; cambiar A record CF a 108.175.4.190; subir TTL a 1 h una vez estable. FES-gated (DNS edit en zone apex circulodesantiago.cl o *.cl).

  10. Caddy cutover: apagar bloque del site en /etc/caddy/sites.d/<svc>.caddy en vps-dev; verificar que vps-cis ya tenga bloque equivalente sirviendo. Recordar gotcha de EnvironmentFile: usar systemctl stop caddy && systemctl start caddy, NO reload (/srv/projects/CLAUDE.md §convenciones).

  11. CHANNEL log: append con [migration] <artefacto> · wave <N> · vps-dev→vps-cis · DNS cutover OK · receipt <fes_id>.

  12. Cleanup vps-dev: detener service (systemctl stop && disable); remover bloque Caddy; mantener directorio repo durante 30 días como backup; tras período, rm -rf.

4. Casos en curso (4 dual-running de Wave 1)

Documentación canónica de los 4 servicios CIS dual-running detectados por la auditoría. Decisiones específicas para cada uno (TRANSFER-PLAN-VPSDEV-CIS.md filas A.1-A.4):

Servicio Canónico Pre-cutover Riesgo
cis-platform vps-cis (ya tiene git init + integración cis-pagos: FLOW_API_KEY/FLOW_SECRET_KEY/PAGOS_INTERNAL_HMAC_KEY) Verificar A record CF cis.circulodesantiago.cl ya en 108.175.4.190. Replicar 3 keys FLOW a vault cis-platform. Bajo — vps-cis ya canónico.
cis-claudia-backend vps-dev (5 commits encima del init vps-cis) rsync .git completo + replicar ANTHROPIC_API_KEY, OPENAI_API_KEY, WHATSAPP_*, OIDC_*, SECRET_KEY a vault cis-claudia. Esto destraba A.1 design (key faltante reportada en CHANNEL 04-29). Medio — sin sync de keys, Claudia v2 no levanta.
cis-librospa vps-dev (build .next/ 117M live) Reproducir npm run build en vps-cis. Activar service vps-cis (hoy inactive). Bajo — no hay DB ni env complejo.
cis-usaia vps-dev (3 commits Phase 1/2/3 platform) rsync .git. Replicar OPENAI_API_KEY (Whisper) a vault cis-usaia. Medio — usaia.cl es dominio público, cutover visible.

5. Orden recomendado (Waves)

Wave 0 (preparación · 1d): inventario A records CF · vault sync pendiente · ADR-024 decision.
Wave 1 (corte de duales · 2-3d): cis-platform, cis-librospa, cis-usaia, cis-claudia-backend.
Wave 2 (limpieza · 1d): cis-core, cis-sign, cis-sii-gateway, cis-sii-monitor, cis-ui, cis-www, cis-plan (rm vps-dev).
Wave 3 (periodismo2 cluster · 1-2d): 4 repos juntos + workers Celery + Redis broker.
Wave 4 (situacion · 1d): rsync, debug service activating, cutover.
Wave 5 (Authentik separation): dependiente ADR-024.
Wave 6 (cochid finalización gradual · meses): dependiente ADR-030 (slot cochid).

Consecuencias

  • Positivo: política canónica clarifica titularidad (CIS vs personal vs CDS) sin forzar cesión universal. Permite a Martín conservar activos personales (illanes00.*, foresight.*, cochid hasta cesión explícita) mientras CIS independiza su patrimonio.
  • Positivo: Wave 1 elimina la dependencia operacional CIS → vps-dev en 2-3 días. Bloqueante de continuidad SpA destrabado. Si Martín pierde vps-dev post-Wave-1, CIS sigue corriendo.
  • Positivo: el proceso de 9 pasos (pre-flight → cleanup) es reproducible, auditable, y reduce drift de secretos a cero (vault sync explícito).
  • Negativo: el plan asume disponibilidad de operador (Martín o Claude con FES) por ~10 días hábiles para ejecutar Waves 1-4. CHANNEL tracking obligatorio.
  • Riesgo · DNS cutover en producción: A record changes en circulodesantiago.cl afectan tráfico real. Mitigación: TTL bajo previo + FES-gated (ADR-026 lista DNS apex como crítico).
  • Riesgo · drift de secretos durante Wave: si vault sync se hace post-cutover en vez de pre, services arrancan en vps-cis sin keys. Mitigación: paso 2 del proceso es bloqueante.
  • Compatibilidad con ADR-024 (SSO): si se decide opción A (Authentik propio CIS), Wave 5 debe ejecutarse antes de retirar auth.illanes00.cl como IdP de productos CIS.
  • Compatibilidad con ADR-022 (marketplace lifecycle): cada artefacto migrado entra como marketplace_status='internal' en services.yaml. Promoción a preview/beta/public sigue checklist canónico ADR-022.
  • Dependencia de CONSTITUTION.md: la cesión gratuita asume cláusula founder-contribution; si esa cláusula no existe formalmente, ejecutar Wave 1-4 igual pero documentar la cesión per-artefacto en CHANNEL para retrofit posterior.

TODOs internos

  1. Pre-Wave 0: redactar contrato simbólico de cesión (CLP $1) que cubra Wave 1-4 en batch, archivado en cis-admin documentos legales. Acción humana (Martín + abogado).
  2. Pre-Wave 1: ejecutar vault_set en cis-platform, cis-claudia, cis-usaia para keys faltantes. FES-gated (ADR-026).
  3. Mid-Wave: monitor de continuidad: durante DNS cutover, smoke test cada 60 s contra el endpoint público hasta que A record propague.
  4. Post-Wave: después de cada wave, entry en CHANNEL con la lista de artefactos cerrados y los fes_receipt_id correspondientes.
  5. Drift illanes00-server ↔ cis-core: cherrypick commits f7feae1, 0058821, a1afc90, 860ce84 (apps.yaml refactor por divisiones, ballerina port fix, shell nav endpoint) desde vps-dev a vps-cis. Decidir si apps.yaml en vps-cis registra sólo apps CIS o también personales (recomendación: sólo CIS).
  6. CDS hosting: ADR separado para decidir si CDS migra a vps-cis, levanta vps-cds dedicado, o queda en vps-dev. Fuera de alcance ADR-023 pero entrada en BACKLOG.

Referencias

  • /srv/projects/cds/cis/cis-plan/AUDIT-VPSDEV-2026-04.md (inventario completo + drift detectado).
  • /srv/projects/cds/cis/cis-plan/TRANSFER-PLAN-VPSDEV-CIS.md (matriz artefacto × decisión, 28 filas).
  • ADR-024 (Authentik separation, dependencia para Wave 5).
  • ADR-030 (slot cochid, dependencia para Wave 6).
  • ADR-022 (marketplace lifecycle, default internal post-migración).
  • ADR-026 versión 2026-04-29 (operations permission model: vault_set y DNS apex son FES-gated).
  • ADR-008 (FES legal: cobertura para los actos críticos del proceso).
  • CONSTITUTION.md §3 (founder contribution, cláusula tácita).
  • /srv/projects/CLAUDE.md (gotcha Caddy reload + EnvironmentFile).