--- type: PLAN asset_id: PLAN-XX-IntelliBanks-GobernanzaIntegral-v01 version: v01 status: Activo owner: Victor Heredia sherpa_owner: Jay ratificador: Victor Heredia (L3+) responsables: Alex (app/backend) · Victor+Jay (gobernanza/OSO) · Equipo (operación) intellibank: IB-XX-Maestro subbank: — fecha_creacion: 2026-07-16 proposito: Plan para atacar de raíz el desorden recurrente de IntelliBanks — que la app no sincronice lo no autorizado, que se regule la creación de skills, y que haya diagnóstico continuo y protocolos claros para operar en equipo sin caos. relacionados: - RFI-XX-IntelliBanks-BlindajeGobernanzaSync-v01 - RFI-XX-IntelliBanks-ManejoRutasDotfolders-v01 - RFI-XX-IntelliBanks-NavInternaDashboards-v01 - CAS-EL-WORX-MarketplaceEnVault-RaizJunk-v01 - ARQ-XX-SOOI-DisenoConceptual-v01 - TP-EL-Governance-TeamCleanup-v01 - CP-XX-BMF-MarketplaceGovernance-v01 (Pilar 2 — IMPLEMENTADO: registry + gate + release) - CP-XX-BMF-OntologiaSoftware-v01 (identidad de catálogo de la capa de software) --- > **Actualización 2026-07-16:** el **Pilar 2 (gobernanza de skills)** ya tiene mecanismo construido y probado — ver `CP-XX-BMF-MarketplaceGovernance-v01`: **registry** (fuente de verdad) + **gate** (`sk-marketplace-audit`, corre en CI) + **release.sh** (build que no deja basura) + `sk-skillvalidator` (valida cada skill). Empaquetado en `worx-governance` v0.4.0. Falta solo que Alex lo suba al repo y active el CI. # PLAN · Gobernanza Integral de IntelliBanks — atacar el desorden de raíz **Owner:** Victor · **Sherpa:** Jay · **Ratifica:** Victor (L3+) · **Fecha:** 2026-07-16 **Responsables:** Alex (app/backend) · Victor+Jay (gobernanza/OSO) · Equipo (operación) --- ## 1. El problema, bien nombrado El desorden (carpetas `skills/`, `plantillas`, archivos en ubicaciones incorrectas que se regeneran solas y se sincronizan a todo el equipo) **no es un bug puntual** — es un síntoma de un principio faltante: **el sistema confía en el cliente para DOS cosas que no debería:** 1. **Qué contenido entra al vault** (archivos/carpetas). → hoy cualquier usuario mal configurado ensucia a todos. 2. **Qué capacidades se crean** (skills). → como dijo Alex, "se ponen a crear skills sin la menor idea de lo que están creando", y esas skills generan el desorden. > **Principio rector (el que resuelve el OSO):** *Zero-Trust del cliente para contenido Y capacidad.* La app y el Sistema Operativo Organizacional deben **regular tanto los archivos como los skills** — no asumir que el usuario lo hará bien. Con 6 usuarios ya es caos; con 100 es inviable. Subir un update limpio y resincronizar (propuesta de Alex) es **necesario pero insuficiente**: limpia el síntoma de hoy, no evita el de mañana. Este plan cubre ambos. --- ## 2. Los 4 pilares ### Pilar 1 — Enforcement en la app (el portero) · **Alex** La app **no puede sincronizar lo no autorizado.** Debe, del lado servidor: - **Validar cada escritura** contra la gobernanza (todo bajo `IB-*`, naming BMF, sin dotfolders, sin paquetes de marketplace). Lo que no cumple **NO se sincroniza** — se **rechaza o se pone en cuarentena**. - **Alertar al administrador** en cada violación: *qué* se intentó y **qué usuario** lo generó (atribución automática — hoy Alex lo hace a mano). - Ignorar dotfolders (`.claude`, `.obsidian`), no aplanar a la raíz, no espejar `archivo.*`. - *(Consolida `RFI-BlindajeGobernanzaSync` + `RFI-ManejoRutasDotfolders`, con el requisito de ALERTA + ATRIBUCIÓN ahora explícito.)* ### Pilar 2 — Gobernanza de skills (regular la capacidad) · **Victor+Jay / OSO** Igual que se regula cómo se crean archivos, hay que **regular cómo se generan skills**: - **Fuente única:** los skills solo se distribuyen desde el **marketplace git sancionado**, nunca hechos a mano dentro del vault. El marketplace empaquetado **vive fuera del vault** (regla de `sx-publicador`). - **Gate de creación:** todo skill nuevo pasa por **validación** (`sk-skillvalidator`) + **ratificación** (triada) antes de publicarse. Nadie corre en producción skills sin revisar. ✅ **Construido** — más el **gate del marketplace** (`sk-marketplace-audit`) que valida el conjunto (registry↔repo↔instalado) en CI. - **Un usuario no puede crear skills que escriban al vault por su cuenta.** El OSO media la creación (fábrica de skills gobernada), igual que media la creación de archivos. ### Pilar 3 — Diagnóstico continuo (monitoreo siempre-activo) · **Ops** - **Health + governance check automático**, por usuario y **central**: detecta cualquier cosa fuera de `IB-`, la **atribuye** y **alerta**. Extiende `sk-ibhealth` + `intellibanks-healthcheck`. - **Tablero central de salud del vault** del equipo: violaciones abiertas, por usuario, tendencia. (No esperar a que alguien note el desorden.) - Corre **programado + on-demand**. ### Pilar 4 — Protocolos (playbooks para que todos sepan qué hacer) · **Victor+Jay** - **Protocolo de actualización (update):** cómo subir un update limpio + resync del equipo de forma segura — versionado, validado, con respaldo y **rollout escalonado** (no todos a la vez a ciegas). - **Protocolo de incidente:** qué hace cada quien cuando salta una alerta (detectar → atribuir → contener → limpiar → causa-raíz → prevenir). - **Protocolo de onboarding:** cómo entra un usuario/equipo **sin ensuciar** desde el arranque — accesos segmentados + setup validado (`/wx-setupsherpax`). *(Se conecta con `OUT-MIN-REB-PlanSherpaXyAccesos`.)* --- ## 3. Fases y secuencia ### FASE 0 — HOY (contención + arranque limpio) - [ ] **Victor:** preparar el **paquete limpio** del vault para subir (estado canónico, raíz solo `IB-*`). - [ ] **Victor+Jay:** enviar **instrucciones al equipo** (ver `OUT-EL-InstruccionesEquipo-LimpiezaSync-20260716-v01`): desinstalar skills viejas, correr `TP-EL-Governance-TeamCleanup`, y **sincronizar mañana**. - [ ] **Alex:** subir el update limpio en la tarde/noche. - [ ] **Equipo:** mañana sincroniza desde el estado limpio. ### FASE 1 — SEMANA (visibilidad + protocolos) - [ ] **Ops:** dejar el **diagnóstico continuo** corriendo (health+governance por usuario, con alerta). - [ ] **Victor+Jay:** documentar el **protocolo de update** y el **protocolo de incidente** (playbooks de una página cada uno). ### FASE 2 — ESTRUCTURAL (el fix de raíz) · **Alex + OSO** - [ ] **Alex:** implementar el **enforcement server-side** (Pilar 1): rechazo/cuarentena + **alerta con atribución** + ignorar dotfolders + no aplanar. - [x] **Victor+Jay:** **gobernanza de skills** (Pilar 2) — mecanismo construido: registry + gate (`sk-marketplace-audit`) + release.sh + `sk-skillvalidator`, en `worx-governance` v0.4.0 (`CP-XX-BMF-MarketplaceGovernance-v01`). ⬜ Pendiente: Alex lo sube al repo + activa el CI. --- ## 4. Criterios de aceptación (probar a escala, no con 6) - [ ] La app **no sincroniza** archivos/carpetas fuera de `IB-*`; los rechaza/cuarentena. - [ ] Toda violación dispara **alerta al admin** con el **usuario origen** identificado. - [ ] Las carpetas `skills/`, `plantillas`, `archivo.*` **dejan de reaparecer** tras un sync. - [ ] Ningún usuario puede **crear/correr un skill** que escriba al vault sin pasar por el gate de gobernanza. - [ ] El diagnóstico continuo reporta el estado del vault **sin intervención manual**. - [ ] Existe y se conoce el **protocolo de update** y el **de incidente** (todo el equipo sabe qué hacer). - [ ] Simulación con ≥20 clientes (incluyendo 1 "malo") **no** contamina el espacio canónico. --- ## 5. Por qué no basta el "update limpio + resync" Es el paliativo correcto para hoy, pero sin los Pilares 1–2 **el desorden vuelve** en el próximo ciclo (lo hemos visto reincidir el 1, 13 y 16 de julio). El fix de raíz es que el **sistema regule contenido y capacidad desde el arranque** — no que limpiemos a mano cada semana. Eso es, textualmente, lo que debe resolver el Sistema Operativo Organizacional. --- *PLAN · Owner Victor · Sherpa Jay · Ratifica Victor (L3+) · 2026-07-16. Consolida los 3 RFIs + el CAS forense en un solo plan de ataque.*