--- type: OUT-MIN asset_id: OUT-MIN-REB-PlanSherpaXyAccesos-20260713-v01 version: v01 status: Borrador owner: Victor Heredia sherpa_owner: Jay ratificador: Victor Heredia fecha_creacion: 2026-07-13 intellibank: IB-REB-Rebelocity subbank: PB-REB-Rebelocity proposito: Minuta del plan para incorporar al equipo Rebelocity a la operación WORX — alta de correos, tanda de SherpaX (RodriX, TutiX, GiselleX, MateoX, RomiX), modelo de accesos segmentados a IntelliBanks por cuenta, modelo de OS central consultable sin descarga, y análisis de la Capa de Coordinación. Incluye asignaciones a Alex. relacionados: - ARQ-EL-WORXOS-CapaCoordinacion-v01 - TP-EL-WORXOS-CapaCoordinacion-Fable-v03 - ARQ-XX-SOOI-DisenoConceptual-v01 - SP-EL-WORX-SetupSherpaX-Guion-v01 - PLAN-REB-Angeles-RolTrabajo-v01 - PERFIL-REB-Giselle-RolesFunciones-v01 --- # Minuta del Plan — Arranque de SherpaX + Accesos · Equipo Rebelocity > **Borrador.** Captura los requerimientos para incorporar al equipo Rebelocity a la operación WORX: correos, SherpaX en tanda, accesos segmentados por cuenta a IntelliBanks, el modelo de OS central sin descarga (en diseño por Victor) y el análisis de la Capa de Coordinación. Cierra con las asignaciones a Alex. --- ## 1. Contexto Se incorpora el equipo Rebelocity a la operación. Esto obliga a **acelerar la fábrica de SherpaX** (pasar de crearlos uno a uno a producirlos en tanda) y a resolver, de una vez, **cómo damos acceso segmentado a IntelliBanks por persona**. En paralelo, Victor está diseñando el modelo para consultar el **Sistema Operativo Central sin descargar los archivos** a la computadora del usuario, y queda pendiente analizar la **Capa de Coordinación** como el conjunto de herramientas que hace que toda la operación funcione como organización. --- ## 2. Requerimientos ### R1 · Alta de correo — Giselle Manzoni - Correo institucional: **giselle@rebelocity.net**. - Es el primero de la tanda; el resto de correos del equipo Rebelocity los define Victor (pendientes). ### R2 · SherpaX del equipo Rebelocity (primera tanda) Arrancamos con 5 SherpaX, uno por colaborador: | Colaborador | SherpaX | Notas | |-------------|---------|-------| | Rodrigo | **RodriX** | — | | Tuti | **TutiX** | enlace de Triclubs (ver `PLAN-REB-Angeles-RolTrabajo-v01` F1) | | Giselle | **GiselleX** | prioridad — asistente de dirección, arrancó 13-jul | | Mateo | **MateoX** | — | | Romina | **RomiX** | — | - **Implicación:** aceleramos el método de creación de SherpaX → producción en tanda (fábrica), no artesanal. Base: `SP-EL-WORX-SetupSherpaX-Guion-v01` + `sx-fabricador-usherpax` + validación con `/wx-setupsherpax`. ### R3 · Accesos segmentados a IntelliBanks (por cuenta de correo) - Objetivo: que cada colaborador, **con su cuenta de correo**, tenga acceso **solo** a los IntelliBanks que le corresponden — por ejemplo **IB-XX** (compartido/Maestro) **+ IB-REB-Rebelocity**, y nada más. - Modelo de segmentación por usuario (multi-tenant / aislamiento por cuenta). - **Correos del equipo: pendientes** — Victor los entrega para poder configurar los accesos. ### R4 · Modelo de OS Central sin descarga (en diseño — Victor) - Victor está generando un modelo para **consultar el Sistema Operativo Central sin que los archivos se descarguen** en la computadora del usuario. - Idea: que al **arrancar un Room se cargue el contexto** (cargado en runtime o **codificado**) de forma que no quede persistido en la máquina del usuario. - Base conceptual: `ARQ-XX-SOOI-DisenoConceptual-v01` (Sistema Operativo Organizacional Inteligente). - **Estado:** Victor lidera el diseño; se necesitará apoyo de infraestructura/seguridad para el mecanismo de carga/codificación. ### R5 · Capa de Coordinación (análisis) - Analizar la **Capa de Coordinación** — el conjunto de herramientas para que la coordinación de toda la operación funcione como organización. - Documento de referencia: `ARQ-EL-WORXOS-CapaCoordinacion-v01` (arquitectura), `TP-EL-WORXOS-CapaCoordinacion-Fable-v03` (SPECs por módulo), `DC-EL-WORXOS-CapaCoordinacion-OnePager-v01`. *(Victor: dejaste el link en el resumen — lo anclo aquí a estos activos canónicos; si el link apunta a otro, lo ajusto.)* - Ligado a los **7 change requests** del método hacia la Capa (`MSG-EL-WORXWay-CRsCapaCoordinacion-v01`). --- ## 3. Cómo se conecta con el rol de Ángeles Ángeles ya tiene en su plan (`PLAN-REB-Angeles-RolTrabajo-v01` §4) el **apoyo técnico a Giselle**: crear GiselleX, correo, acceso restringido y acompañamiento. Este plan **generaliza eso a los 5 SherpaX** y define quién hace qué: - **Ángeles** — acompañamiento técnico y setup de los SherpaX del lado usuario (inducción, IntelliBank operando). - **Alex** — provisión de accesos segmentados y aislamiento por cuenta (parte de sistemas/seguridad). - **Victor** — ratifica correos, define el modelo de OS central, ratifica la Capa de Coordinación. --- ## 4. Asignaciones a Alex (propuesta) > Lo que propongo poner en la cancha de Alex (sistemas/seguridad/infra). Para ratificar. - [ ] **[NEXT][Alex] Modelo de accesos segmentados por cuenta a IntelliBanks** — diseñar y configurar el mecanismo para que cada correo tenga acceso solo a los IntelliBanks asignados (ej. IB-XX + IB-REB). Entregable: procedimiento replicable + prueba con la cuenta de Giselle. - [ ] **[NEXT][Alex] Aislamiento multi-tenant / por usuario** — atar esto a MT-01 (aislamiento multi-tenant, P0 de Platform Intelligence) para que la separación por usuario sea real y segura. - [ ] **[NEXT][Alex] Provisión de cuentas de correo `@rebelocity.net`** — dar de alta / validar giselle@rebelocity.net y las que siga entregando Victor (o confirmar quién administra el dominio). - [ ] **[NEXT][Alex] Validación técnica de los 5 SherpaX** — correr `/wx-setupsherpax` por colaborador (RodriX, TutiX, GiselleX, MateoX, RomiX): conexión MCP + IntelliBanks accesibles + luz verde. - [ ] **[NEXT][Alex] Soporte al modelo de OS central sin descarga** — apoyar a Victor en el mecanismo de carga/codificación de contexto en runtime para que los archivos no se persistan en la máquina del usuario (lado seguridad/infra). - [ ] **[NEXT][Alex] Write a Victor en `empowerlabs-plugins`** (carry-in) — habilita publicar la fábrica de SherpaX y la gobernanza en el marketplace. --- ## 5. NEXTs abiertos (consolidado) - [ ] [NEXT][Victor] Entregar los correos del equipo Rebelocity (Rodrigo, Tuti, Mateo, Romina) para configurar accesos - [ ] [NEXT][Victor] Cerrar el modelo de OS central sin descarga (diseño) + criterios de codificación de contexto - [ ] [NEXT][Victor] Ratificar la Capa de Coordinación (`ARQ-EL-WORXOS-CapaCoordinacion-v01`) para arrancar SPECs por módulo - [ ] [NEXT][Ángeles] Producir los 5 SherpaX en tanda (setup + inducción) con la fábrica acelerada - [ ] [NEXT][Ángeles] Crear GiselleX + acceso + correo giselle@rebelocity.net (prioridad, semana 1) - [ ] [NEXT][Alex] (ver §4 — bloque completo de accesos, aislamiento, correos, validación, OS central) - [ ] [NEXT][Jay/Victor] Acelerar la fábrica de SherpaX — definir el proceso en tanda (base `sx-fabricador-usherpax` + `SP-EL-WORX-SetupSherpaX-Guion-v01`) --- ## 6. Decisiones / por ratificar - Modelo de acceso: **segmentación por cuenta de correo** (cada quien ve solo sus IntelliBanks). ✅ dirección; falta implementación (Alex). - Fábrica de SherpaX **en tanda** (acelerada) como estándar para incorporar equipos. — por ratificar. - OS central **sin descarga** (contexto cargado/codificado al arrancar Room). — en diseño (Victor). --- ## 7. Nota completa — Estado de IntelliBanks + blindaje (para Alex) > El modelo de **accesos segmentados** (R3 / §4) no es un feature aislado: es la **capa de acceso del blindaje Zero-Trust de IntelliBanks**. Aquí va el panorama completo para que Alex lo vea junto y arranque con contexto. ### 7.1 El problema de fondo IntelliBanks **confía en el cliente**. Un solo usuario mal configurado (app vieja, carpeta respaldada conectada, o SherpaX mal configurado) ensucia el vault **compartido de todos**. Con 6 usuarios ya nos hacemos bolas; al sumar al equipo Rebelocity (5 SherpaX más) es inviable sin **enforcement central**. La integridad del vault **no puede depender de la config de cada usuario**. ### 7.2 RFIs abiertos (en `IB-XX-Maestro/`) 1. **`RFI-XX-IntelliBanks-BlindajeGobernanzaSync-v01`** (🔴 CRÍTICO) — Zero-Trust: enforcement server-side de "todo bajo `IB-`", **cuarentena + atribución** del usuario origen, **gating de versión** de cliente, **import validado** de respaldos, **versionado/rollback**, y gobernanza-as-code. Es el keystone. **El modelo de accesos segmentados (R3) es la capa de acceso de este mismo blindaje.** 2. **`RFI-XX-IntelliBanks-ManejoRutasDotfolders-v01`** — la app **aplana** archivos/carpetas a la raíz y **espeja dotfolders** (`archivo.claude/`, `archivo.obsidian/`) + **sube `.obsidian/`** (config personal) a la nube compartida. *Anexo 13-jul:* se confirmó que la fuente es la **maquinaria de plugins/skills dentro del vault** (marketplace empaquetado + caché `.claude`), re-materializada por **7 tareas programadas**. Detalle: `CAS-EL-WORX-MarketplaceEnVault-RaizJunk-v01`. 3. **`RFI-XX-IntelliBanks-NavInternaDashboards-v01`** — abrir un archivo **en la app** desde los dashboards: hoy **imposible** (la app no registra esquema de URL). Fix chico: `setAsDefaultProtocolClient('intellibanks')` + handler `open-url` + `CFBundleURLTypes`. Mensaje listo: `OUT-EL-MensajeAlex-EsquemaURL-v01`. ### 7.3 Checklist consolidado para Alex — IntelliBanks - [ ] **Enforcement server-side** "todo bajo `IB-`" (rechazo/cuarentena + atribución por usuario). - [ ] **Ignorar dotfolders** (`.claude`, `.obsidian`) — sin mirrors `archivo.*`, sin subir config personal a la nube. - [ ] **No aplanar** a la raíz — preservar la ruta completa del archivo. - [ ] **Rechazar paquetes de marketplace/plugins dentro del vault** (no son contenido de conocimiento). - [ ] **Esquema `intellibanks://`** para abrir archivos desde los dashboards. - [ ] **Allowlist de sync:** agregar `.csv` y `.py` (política híbrida — Anexo A del RFI-Blindaje). - [ ] **Gating de versión mínima** de cliente + **import validado** de respaldos. - [ ] **Versionado/rollback** de sync. - [ ] **Accesos segmentados por cuenta (R3 / §4)** — atados a **MT-01** (aislamiento multi-tenant, P0 de Platform Intelligence) para que la separación por usuario sea real y segura. ### 7.4 Regla de gobernanza (para todo el equipo, no solo Alex) El **marketplace empaquetado y la caché de skills viven SOLO en el repo git externo** (`~/dev/empowerlabs-plugins`), **nunca dentro del vault**. Las *fuentes* de skills (SKILL.md en `BOS-EL-WORX-OS`, `SX-MastersPack`) sí pueden vivir en el vault; el *paquete* no. Esto es consistente con la regla de oro de `sx-publicador`. --- *OUT-MIN-REB-PlanSherpaXyAccesos-20260713-v01 · Borrador · Owner: Victor · Sherpa: Jay · Ratificador: Victor · 2026-07-13*