--- type: TP asset_id: TP-EL-IntelliBanks-MultiEmpresa-ZeroTrust-FableBrief-v01 version: v01 status: Draft · listo para entregar a Alex owner: Victor Heredia sherpa: Jay ratificador: Victor Heredia implementa: Alex (backend/app) intellibank: IB-EL-EmpowerLabs subbank: EQ-EL-Equipo fecha_creacion: 2026-07-07 proposito: > Transfer Pack para que Alex corra el diseño de la arquitectura Multi-Empresa + Zero-Trust de IntelliBanks con Fable 5, en su último día de modo incluido. Define el camino (Fable genera → otro modelo wargamea), pide a Alex el contexto completo del sistema ANTES de correr Fable, y trae el brief listo para pegar. relacionado: - RFI-XX-IntelliBanks-BlindajeGobernanzaSync-v01 - RFI-XX-IntelliBanks-NavInternaDashboards-v01 - RFI-XX-IntelliBanks-ManejoRutasDotfolders-v01 - OUT-EL-BarridoFrentes-ProyectosFable-20260707-v01 (P1) gate_g0: PASS · deriva del RFI de blindaje (Capa 0–5) y de los RFI de navegación/rutas tags: [TP, intellibanks, multiempresa, zero-trust, fable, brief, alex, wargame] --- # TP — Multi-Empresa + Zero-Trust IntelliBanks ## Brief para correr con Fable 5 · lo ejecuta Alex · 7-jul-2026 > **Qué es esto:** tu starter prompt, Alex. Diseñar de una sentada la arquitectura que junta dos cosas que van juntas: **(A)** cambiar entre empresas dentro de la app (tu propuesta de multi-empresa) y **(B)** el blindaje Zero-Trust del `RFI-XX-IntelliBanks-BlindajeGobernanzaSync-v01`. No son dos proyectos: son la misma disciplina multi-tenant en dos capas. --- ## 0. Cómo usar este TP (3 pasos) 1. **Llena la Sección 2** — el contexto real del sistema. **Sin esto, Fable diseña a ciegas.** Es lo único que te toca preparar antes de arrancar. 2. **Pega la Sección 3** (el brief) en un room nuevo con **Fable 5**, HOY. Adjunta lo de la Sección 2. 3. **Después** (no hoy, no con Fable): corre el **wargame de la Sección 4** con otro modelo (Opus) para atacar el diseño antes de construir. --- ## 1. El camino recomendado (por qué Fable ahora y wargame después) **No es "wargame o Fable" — se secuencian.** | Etapa | Modelo | Qué hace | Por qué ese modelo | |---|---|---|---| | **Generar** (hoy) | **Fable 5** | Produce la arquitectura completa multi-empresa + zero-trust | Es síntesis de gran contexto: hay que sostener app + backend + gobernanza + escala sin contradecirse. El fuerte de un modelo grande. | | **Atacar** (después) | Otro (Opus) | Wargamea el diseño: busca dónde se rompe | Validación adversarial. **Regla:** el modelo que diseñó no debe ser el único que valida — se auto-aprueba. | | **Construir** | Equipo | Implementa por fases (RFI §8) | Fase 0 → Fase 1 keystone → resto | Aprovechamos el último día de Fable incluido para el heavy-lift generativo. El wargame no necesita Fable — puede correr cualquier otro día. --- ## 2. ⛏️ Contexto que Alex debe aportar ANTES de correr Fable > Fable ya tiene el *qué* y el *por qué* (este TP + el RFI). Le falta el *cómo está construido hoy* — y eso solo lo tienes tú. Contesta lo que sepas; donde no haya nada aún, escribe "no existe" (también es información). Pega código/config real cuando lo tengas; vale más que describirlo. **A · App (Electron / cliente)** - [ ] Estructura del proyecto de la app (árbol de carpetas del repo de `Intellibanks.app`). - [ ] Proceso main de Electron: cómo monta la carpeta del vault, cómo sirve archivos (hoy `registerFileProtocol` → `/a/skill_`). - [ ] Cómo se conecta hoy **una sola** carpeta/vault: dónde se configura, dónde se guarda esa config. - [ ] Versión actual y cómo se distribuye/actualiza la app (auto-update sí/no, canal). **B · Backend / sync (genniux.net)** - [ ] Stack real del servidor (vimos Apache 2.4.52/Ubuntu — ¿qué corre detrás: PHP, Node, otro?). - [ ] Endpoints de sync actuales: subir, bajar, listar, resolver ID→archivo. - [ ] Cómo decide el servidor **aceptar** una escritura hoy (¿valida algo, o acepta a ciegas? — el RFI asume lo segundo, confírmalo). - [ ] Modelo de auth actual: cómo se identifica un usuario/cliente en cada request. **C · Modelo de datos / sync map** - [ ] Esquema real de `.intellibanks_sync_map.json` (1 ejemplo de entrada completo). - [ ] Qué son y cómo se generan los `skill_id` opacos; ¿son estables por archivo? - [ ] Cómo se guarda hoy la relación ruta-de-vault ↔ ID en servidor y en cliente. **D · Gobernanza / versionado (lo que el RFI da por verificar)** - [ ] ¿El app **realmente** guarda historial de versiones por archivo? ¿Dónde, cómo se recupera? - [ ] ¿Existe hoy alguna lista de exclusión (dotfolders) o allowlist de extensiones? ¿Dónde vive? - [ ] ¿Hay alguna noción de "usuario origen" por archivo subido (para atribución)? **E · Multi-empresa (lo nuevo)** - [ ] Tu idea concreta: ¿varias empresas = varios vaults separados, o un vault con partición interna? - [ ] ¿Un mismo usuario pertenece a >1 empresa? ¿Cambia de empresa en caliente o re-login? - [ ] ¿La nube es una sola instancia multi-tenant, o una instancia por empresa? **F · Escala** - [ ] Nº de usuarios hoy y meta (el RFI habla de 6 → 100+). - [ ] Restricciones que ya conoces (costo servidor, límites de Apache, etc.). --- ## 3. 📋 Brief para Fable 5 (pegar tal cual en el room) > **Rol:** Eres arquitecto de sistemas multi-tenant y harness/governance engineering. Vas a diseñar la arquitectura de IntelliBanks para dos capacidades acopladas: cambiar entre empresas dentro de la app, y blindaje Zero-Trust del cliente. Trabaja sobre el CONTEXTO REAL que se adjunta (Sección 2 del TP) — no inventes internals; si algo no está, decláralo como supuesto explícito. > > **Decisiones ya tomadas (no las re-abras, constrúyelas):** > - Principio rector **Zero-Trust del cliente**: el cliente propone, el servidor dispone. Toda escritura se valida contra la gobernanza antes de persistir; lo que no cumple se **rechaza o cuarentena**, nunca contamina el espacio canónico. > - Arquitectura de blindaje en **6 capas** (Capa 0 Gobernanza-as-Code = una fuente de verdad, tres consumidores: write-time SherpaX, sync-time backend, consulta humana; Capa 1 enforcement server-side = keystone; Capa 2 versionado/rollback; Capa 3 gating de versión + import validado de respaldos; Capa 4 SherpaX write-time; Capa 5 observabilidad/atribución). Detalle en `RFI-XX-IntelliBanks-BlindajeGobernanzaSync-v01`. > - **Política de sync híbrida por tipo** (Anexo A del RFI): documentos + `.csv` + `.py` sincronizan; skills/plugins van por marketplace; código pesado por git. La frontera debe ser **explícita y enforceada**, no silenciosa. > > **El problema nuevo a resolver (multi-empresa), acoplado al zero-trust:** > 1. Modelo de datos y de identidad para **N empresas** en la app (aislamiento entre empresas = multi-tenant duro; ninguna escritura de empresa A puede aterrizar en el vault de B). > 2. **Conmutador de empresa** en la app (Electron): cómo cambia el contexto activo, qué pasa con el sync en vuelo, cómo se evita que un cambio de contexto escriba en la empresa equivocada. > 3. Cómo el **enforcement server-side** (Capa 1) valida ahora dos dimensiones: gobernanza de ruta/naming **y** pertenencia a la empresa correcta. > 4. Cómo la **Capa 0** (gobernanza-as-code) se extiende para expresar reglas por empresa sin fragmentar la fuente de verdad. > 5. Resolver de paso el **serving por ID opaco** (`/a/skill_`) que hoy rompe la navegación entre dashboards (`RFI-XX-...-NavInternaDashboards-v01`) y el esquema `intellibanks://` — encajarlos en el nuevo modelo de rutas/tenant. > > **Entregable:** un documento `ARQ-EL-IntelliBanks-MultiEmpresa-ZeroTrust-v01` con: (a) diagrama de componentes y de datos; (b) modelo de identidad/tenant; (c) contrato de la Capa 0 (esquema del ruleset por empresa); (d) especificación del enforcement server-side (qué valida, qué rechaza, qué cuarentena, cómo atribuye); (e) diseño del conmutador de empresa en el cliente; (f) plan de migración desde el estado actual (un solo vault) sin pérdida; (g) criterios de aceptación probables a escala (≥20 clientes concurrentes, incluido 1 "malo" y 1 cruzando de empresa); (h) riesgos abiertos y supuestos. > > **Formato:** naming BMF, listo para el vault. Marca claramente cada supuesto que hiciste por falta de contexto, para que Alex lo confirme. --- ## 4. Anexo — Wargame space (para otro modelo, después) **Objetivo del wargame:** romper el diseño de la Sección 3 antes de construirlo. - **Actor rojo 1 — cliente hostil / mal configurado:** versión vieja, carpeta respaldada conectada, SherpaX que escribe fuera de `IB-`. ¿El enforcement server-side aguanta? *Victoria azul:* ninguna escritura fuera de gobernanza llega al canónico sin cuarentena + atribución. - **Actor rojo 2 — fuga cross-empresa:** usuario de empresa A que (por bug de conmutador, token, o request forjado) intenta escribir/leer en empresa B. *Victoria azul:* cero fuga cross-tenant, en sync y en serving. - **Actor rojo 3 — el día del caos a escala:** 20+ clientes concurrentes, uno malo, uno cambiando de empresa en caliente durante un sync. *Victoria azul:* la raíz de cada empresa queda solo con `IB-*`; ningún sync malo es irreversible (rollback). - **Movimientos:** cada ronda el rojo elige un vector; el azul responde con la capa del diseño que lo detiene; el juez marca si el diseño **ya** lo cubre o si es un hueco. - **Salida:** lista de huecos priorizada → vuelve al `ARQ-` como correcciones antes de Fase 1. Cuando digas, genero el TP semilla del wargame como archivo aparte para pasárselo directo a Opus. --- ## 5. Tripleta + NEXTs - **Owner:** Victor · **Sherpa:** Jay · **Implementa:** Alex · **Ratifica arquitectura:** Victor (L3) **NEXTs** - [ ] **Alex** — llenar Sección 2 (contexto del sistema) y correr el brief de la Sección 3 con Fable 5 **hoy**. - [ ] **Alex** — entregar `ARQ-EL-IntelliBanks-MultiEmpresa-ZeroTrust-v01` al vault (`IB-XX-Maestro`) para ratificación de Victor. - [ ] **Equipo/Jay** — correr el wargame (Sección 4) con otro modelo sobre el `ARQ-` antes de arrancar Fase 1. - [ ] Cerrar de paso, dentro del nuevo modelo de rutas, los RFI de navegación (`intellibanks://`) y manejo de dotfolders — el RFI de blindaje los absorbe como sub-casos. --- ## CHANGELOG | Versión | Fecha | Cambio | |---|---|---| | v01 | 2026-07-07 | Creación. Camino Fable-genera → otro-modelo-wargamea. Checklist de contexto obligatorio para Alex. Brief listo para Fable 5. Anexo de wargame. Deriva del RFI de blindaje Zero-Trust. |