Saltar a contenido

ADR-027 · Compartibilidad de planes y conversaciones cross-user CIS

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

Contexto

CIS opera con dos co-founders trabajando el mismo workspace (Martín illanes00 y Sopapo). El plan v2 (decisión §C.7-C) explicita que el contexto del CIS es compartido por default; lo personal es excepción. Hoy lo que ya está compartido funciona vía permisos UNIX (infra group + setgid en /srv/projects/):

  • /srv/projects/cis/{CONSTITUTION,GLOSSARY,STATUS,STRUCTURE,CHANNEL,CONTRACTS}.md — ambos pueden read/write.
  • /srv/projects/cds/cis/cis-plan/*.md — mismo grupo.
  • DBs cis_* con cuentas compartidas.
  • Vault namespaces cis-*, vps-cis accesibles a ambos.

Lo que está roto: los archivos de planes (~/.claude/plans/*.md) son per-user. El plan que Martín está ejecutando hoy (antes-hab-a-estado-a-silly-valley.md) Sopapo no lo ve. Si Sopapo abre Claude Code, ve sus propios planes pero no los de Martín, y viceversa. Esto rompe el flujo "el plan del CIS es uno solo".

Adicionalmente, Claudia v2 (ADR-015) introduce threads, drafts, agent tasks, notas. Sin un modelo de visibility explícito, cada conversación queda private al owner — duplicando la fricción.

Alternativas consideradas

  1. (a) Todo compartido por default, sin opt-out
  2. Pro: máxima coordinación.

  3. Contra: notas personales con Claudia ("recordame comprar regalo") no deberían filtrarse al co-founder. Privacy mínima necesaria.

  4. (b) Visibility model private | shared | readonly:rol con default según contexto ← propuesta

  5. Pro: contenido del CIS default shared. Personal default private. Pueden coexistir. Migración clara de paths personales a shared.

  6. Contra: cada thread/plan/task tiene un toggle. UI debe exponerlo claramente.

  7. (c) Sin visibility, dos workspaces independientes con sync manual

  8. Pro: simple.
  9. Contra: contradice "el contexto del CIS es uno solo". Estado actual con paths personales = no escalable.

Decisión

Visibility model:

visibility ∈ { 'private', 'shared', 'readonly:<rol>' }
  • private: solo el owner ve. Default para notas personales.
  • shared: todos los cis-staff (incluye cis-superadmin) ven. Default para contenido del CIS (planes, decisiones de planning, drafts de servicios).
  • readonly:<rol>: visible para members del Authentik group del rol. Ej. readonly:cis-readonly-contable permite a contadores externos ver un thread específico de "consultas contables abiertas" sin que vean el resto.

Defaults por tipo de contenido:

Tipo Default visibility Notas
Plan files (/srv/projects/cis/plans/*.md) shared Canon del workspace
Threads Claudia (chat_threads) private Personal por defecto; toggle a shared en UI
Drafts de servicios / docs en repos CIS shared Workspace shared
Agent tasks (background) shared Trazabilidad cross-co-founder
Notas personales (Claudia "recordame X") private Privacy default
Conversación con claudia@innovacionsantiago.cl private per user Cada user con su propio thread email

Authentik groups (existentes + nuevos):

  • cis-superadmin (existente): Martín + Sopapo. Acceso completo. Ven todo shared y todo lo propio.
  • cis-staff (nuevo, deliverable C.7-B): empleados internos futuros. Ven shared. No ven private de otros. Sin acceso a /sudo ni vault sensible.
  • cis-readonly (nuevo): contadores externos, auditores. Ven shared filtrado a contable/tributario + threads readonly:cis-readonly-contable.
  • cis-superadmin-only (existente policy): emergencias.

Migración paths personales → shared:

  • Plan files: hoy en ~/.claude/plans/<slug>.md per-user. Migrar a /srv/projects/cis/plans/<slug>.md (shared, owned by infra group, mode 2775). Cada user mantiene un symlink ~/.claude/plans/ → /srv/projects/cis/plans/ para que Claude Code los encuentre. Bloque T.4 ejecuta esta migración.
  • Auto-memory por proyecto (~/.claude/projects/-srv-projects/memory/MEMORY.md): se mantiene per-user (preferencias personales, contraseñas que el user dejó en chat, lessons personales). No se comparte.
  • Memoria curada compartida: opcional /srv/projects/cis/SHARED-MEMORY.md con feedback/lessons que ambos quieren preservar. Curado, no auto. Documentación viva del workspace.

Surface-aware permissions:

  • Email Claudia: cada user tiene su propio thread/buzón (per-user claudia+<usuario>@innovacionsantiago.cl). Default private. Botón "compartir este hilo con Sopapo" → cambia a shared y dispara mensaje de invitación.
  • Web /chat: lista threads filtrada por visibility (mis privados + shared del workspace).
  • WhatsApp: solo own threads (privacy mobile).
  • /sudo: gateado por cis-superadmin group + log con owner del thread origen.
  • /vault: gateado por cis-superadmin + FES en sets (ADR-026).
  • /plans: shared default (canon del workspace) + privados se ven a quien creó.

Toggle desde UI: cada thread/plan/task tiene un selector de visibility. Cambio queda registrado en audit log con actor_user_id + from_visibility + to_visibility.

Regla "default shared": cuando un agente Claude crea contenido (plan, ADR draft, doc) por instrucción de un co-founder, el default es shared salvo que el prompt explícitamente pida private. Mensajes ambiguos resuelven a shared (regla "el CIS es compartido"). Notas verdaderamente personales requieren prompt explícito.

Consecuencias

  • Positivo: el plan del CIS lo ven los dos co-founders sin migración manual. Conversaciones de planning estratégico (mismo plan, mismo CHANNEL, mismas decisiones) sin duplicar contexto. Privacy mínima conservada para notas personales.
  • Negativo: la migración paths personales a shared requiere cuidado (symlinks, no perder historial). Bloque T.4 ejecuta con backup previo. Si algún plan personal queda accidentalmente shared, es reversible (visibility toggle).
  • Riesgo: contenido sensible posteado a un thread shared por error queda visible al co-founder. Mitigación: warning UI cuando el toggle pasa de private a shared ("este contenido será visible para [list]"). Audit log permite revertir.
  • Migración:
  • T.4 mueve ~/.claude/plans/ → /srv/projects/cis/plans/ con symlinks (~30 min coordinación).
  • Threads Claudia v2 arrancan con el modelo (sin migración legacy — v1 no tiene threads persistentes equivalentes).
  • Audit table chat_visibility_changes para reconstruir.
  • Compatibilidad: usuarios actuales (martin, sopapo) son cis-superadmin. Ven todo shared por inclusión jerárquica. Roles futuros (cis-staff, cis-readonly, etc.) se crean con el flujo C.7-B + ADR-028.
  • Authentik: requires que cada JWT incluya claim groups (ya hace, ADR-014). El servicio consumidor filtra contenido por intersection visibility ∩ groups.
  • Dependencia de C.7-B (ADR-028): roles canónicos definen qué cis-staff, cis-readonly-contable, etc. pueden ver. Sin esos roles formalizados, este ADR opera con solo cis-superadmin activo (caso real al 2026-04-29).
  • Surface email: la primary surface de Claudia es email (Bloque A.4-mail). Default private por convención secretarial — un mail entre tú y tu secretaria es 1:1 salvo pedido explícito.