--- type: SP asset_id: SP-EL-IntelliBanks-PlanAccionFable5-20260707-v01 version: v01 tipo: SP — Starter Prompt / Room Kit (plan de acción ejecutable) status: 🟢 listo para ejecutar HOY (último día de Fable 5 incluido) owner: Alex sherpa: SherpaX Alex ratificador: Victor Heredia (L3 · arquitectura) intellibank: IB-EL-EmpowerLabs subbank: EQ-EL-Equipo fecha_creacion: 2026-07-07 proposito: > Plan de acción autocontenido para ejecutar en rooms nuevos los dos frentes Fable 5 del 7-jul-2026: (1) ARQ Multi-Empresa + Zero-Trust de IntelliBanks y (2) Wargame ConnectorX (Órbita 3). Integra el contexto del sistema ya levantado (DC-EL-IntelliBanks-DescripcionProducto-v01), pre-llena la Sección 2 del TP y deja los briefs listos para pegar. relacionado: - TP-EL-IntelliBanks-MultiEmpresa-ZeroTrust-FableBrief-v01 (fuente Frente 1) - SP-EL-SOO-Wargame-ConnectorX-Fable5-v01 (fuente Frente 2) - DC-EL-IntelliBanks-DescripcionProducto-v01 (contexto del sistema) - DC-EL-IntelliBanks-AnalisisMultiEmpresa-v01 (base multi-tenant ya trabajada) - RFI-XX-IntelliBanks-BlindajeGobernanzaSync-v01 (Capas 0–5) gate_g0: PASS · deriva del TP, del SP wargame y del DC de producto; vault consultado tags: [SP, plan-accion, intellibanks, multiempresa, zero-trust, wargame, connectorx, fable5, alex] --- # SP · Plan de Acción Fable 5 — 7-jul-2026 ## Dos frentes, dos rooms, un día. Room kit autocontenido para Alex. > **Cómo usar:** abre un room nuevo, corre `/arrancaroom`, pega/adjunta este SP. Todo lo necesario está aquí o referenciado con ruta exacta del vault. No dependas de la memoria de ningún room anterior. --- ## 0. Situación - **Hoy es el último día de Fable 5 incluido.** Los dos frentes usan a Fable para el heavy-lift generativo; la validación adversarial con otro modelo (Opus) queda para después — regla: *el que diseña no es el único que valida*. - **Frente 1 (Alex ejecuta):** arquitectura Multi-Empresa + Zero-Trust de IntelliBanks → entregable `ARQ-EL-IntelliBanks-MultiEmpresa-ZeroTrust-v01`. - **Frente 2 (Victor o quien designe; confirmar antes de correr):** Wargame ConnectorX (Órbita 3 del MAP SOO) → entregable `OUT-EL-SOO-Wargame-ConnectorX-Resultados-v01`. - **Ventaja ya ganada:** la Sección 2 del TP (contexto del sistema que Fable necesita) quedó **pre-llenada** en §2 de este plan a partir de `DC-EL-IntelliBanks-DescripcionProducto-v01` y `DC-EL-IntelliBanks-AnalisisMultiEmpresa-v01` (el análisis multi-tenant ya trabajado — cierra por completo el punto E). Solo restan los gaps marcados 🔴. --- ## 1. Secuencia del día | # | Acción | Quién | Tiempo | Sale | |---|---|---|---|---| | 1 | Cerrar los 🔴 gaps de §2 (abajo) | Alex | ~20 min | Contexto completo | | 2 | Room nuevo + `/arrancaroom` + pegar brief §3 + adjuntos §4 | Alex | ~5 min | Room Frente 1 listo | | 3 | Correr Fable 5 hasta producir el `ARQ-` completo (incisos a–h) | Alex + Fable | sesión | `ARQ-EL-IntelliBanks-MultiEmpresa-ZeroTrust-v01` | | 4 | Guardar `ARQ-` en el vault → avisar a Victor para ratificación | Alex | — | NEXT del TP cerrado | | 5 | Room aparte para el wargame ConnectorX (§5) | Victor/designado | sesión | `OUT-EL-SOO-Wargame-ConnectorX-Resultados-v01` | | 6 | **Después, sin Fable:** wargames de ataque con Opus (§6) | Jay/equipo | otro día | Huecos priorizados | --- ## 2. Contexto del sistema — Sección 2 del TP **pre-llenada** > Fuente: `DC-EL-IntelliBanks-DescripcionProducto-v01` (julio 2026, refleja código y operaciones en producción). ✅ = ya respondido, adjunta el DC y listo. 🔴 = gap que Alex llena antes de correr. **A · App (Electron / cliente)** - ✅ Stack: Angular 15 + TS strict + RxJS (`BehaviorSubjects`); Cordova + Electron (macOS y Windows desde una base). Daemon `intellibanks-sync.js` vía `utilityProcess.fork` + `chokidar`. Layout 3 paneles, pestañas tipo Obsidian, editor MD (marked + DOMPurify + turndown), import DOCX, HTML en iframe `srcdoc` con intercepción de clics en fase de captura. - ✅ Vault único hoy: `~/Documents/Intellibanks/`, espejado contra backend. Esquema `intellibanks://` registrado (`setAsDefaultProtocolClient`, `open-url`/`second-instance`/`argv`, patch de `Info.plist` en macOS). - ✅ Versión actual: 1.0.0 (dmg de mayo 2026). - ✅ Árbol del repo (verificado 7-jul-2026; proyecto Cordova+Electron+Angular en un solo repo): ``` genniuxgit/ ├── intellibanks-sync.js ← daemon de sync (raíz del repo) ├── src/app/ ← Angular │ ├── components/ (explorer, header, loader, skill-list, skill-preview) │ ├── pages/ (home, login, editor, admin) │ ├── services/ (auth, skill, sync, cordova-file, loader) │ ├── guards/ (auth.guard) · models/ (skill.models) ├── backend-patch/ ← PHP del server versionado aquí (admin_api, admin_cleanup, │ │ db, folders, get_skill_content, get_sync_map, list_skills, │ │ search, update_skill, upload + .bak y BACKUP-original-*) ├── platforms/electron/platform_www/cdv-electron-main.js ← main de Electron (generado Cordova) ├── hooks/ (after_build, after_prepare — patch Info.plist p/ intellibanks://) ├── www/ · res/ · config.xml · cdv-electron-settings.json └── ANALISIS-*.md, ESPECIFICACIONES.md, PROPUESTA-Integracion-Auth.md (docs en raíz) ``` Scripts de operación en raíz: `cleanup-phantoms.js`, `diag-mismatches.js`, `recover-zerobyte.js`, `verify-remote-map.js`, `test-sync-guards.js`. - ✅ Config del vault: **hard-coded** — `WATCH_DIR = argv[2] || ~/Documents/Intellibanks` (línea 37 del daemon). No hay UI ni archivo de config para elegir carpeta: punto de intervención directo para el conmutador de empresa. En la raíz del vault viven `.intellibanks_sync_map.json`, `.user_session.json` y `.intellibanks_upload_lock.json`. - ✅ Auto-update: **no existe** (sin electron-updater; distribución manual por `.dmg`/instalador). Relevante para la Capa 3 del RFI (gating de versión): hoy no hay forma de forzar upgrade de clientes viejos. **B · Backend / sync (genniux.net)** - ✅ Stack: PHP **5.6** (restricción dura: sin `??` ni arrow functions), Apache, MySQL (PDO), Git como storage versionado. Base: `https://genniux.net/skills-api/api/`. GETs cacheados por CDN (usar parámetro anti-caché para verificar escrituras). - ✅ Endpoints: `get_sync_map.php` (mapa completo en 1 petición, caché `true_map.json` TTL 4 min, fallback a `sys_get_temp_dir()`), `get_skill_content.php` (on-demand, base64 para binarios), `list_skills.php` (solo metadatos), `search.php` (nombre/descripción, no contenido), `update_skill.php`, `upload.php`, `folders.php` (CRUD), `delete_skill.php` (BD + storage + Git), `restaurar.php`, `log_sync.php`, `admin_api.php`, `admin_cleanup.php`. - ✅ Validación de escrituras hoy (confirma el supuesto del RFI: **casi a ciegas**): solo rechaza (a) subidas vacías/0 bytes (`UPLOAD_ERR_OK` + `trim()`), (b) carpetas sin autor resoluble (HTTP 400). **No** valida gobernanza de ruta/naming, **no** valida tenant. Filtro de dotfiles es *client-side* (4 capas) — el servidor no lo enforcea. - ✅ Auth actual: identificación por campo `usuario` en el request (el daemon manda `desktop_daemon` como mínimo); admin hard-coded a `JoseRojas`; candado de subidas por bandera `.intellibanks_upload_lock.json` (solo ese usuario). CORS con lista blanca de orígenes (fix `HTTP_ORIGIN`). - ✅ Sesión (verificado en `auth.service.ts`): **no hay sesión server-side ni token**. El login guarda la respuesta completa en `localStorage['ai_skill_store_session']` y escribe `~/Documents/Intellibanks/.user_session.json` con `{usuario, timestamp}` para que el daemon sepa quién es. Cada request manda `usuario` como parámetro en claro — **cualquier cliente puede suplantar a otro usuario**. Confirma en duro el supuesto del RFI y hace obligatorio el punto 7a del brief (endurecimiento de identidad como parte del keystone). **C · Modelo de datos / sync map** - ✅ Mapa remoto: `{ skill_id, name, folder_path[], version, hash, content_ext }`; hash espeja el cálculo del cliente (bytes crudos en disco); `cleanFileName` del cliente = **única fuente de verdad** de nombres/rutas. Mapa local: `.intellibanks_sync_map.json`. - ✅ Tablas: `skills` (id, name, description, status, current_version, folder_id, created_by, updated_by), `skill_versions` (is_current, file_path, created_by), `skill_folders` (árbol parent_id), `skill_activity_logs`, `user_sync_history`. - ⚠️ **Estabilidad de `skill_id`: NO garantizada** — bug abierto: `upload.php` crea skill nuevo en vez de actualizar para archivos que cambian seguido (`.json`), causa raíz de los 2,154 duplicados ya limpiados (tabla quedó en 2,788 filas reales; los duplicados **regresan** solos, +40 en minutos). Dato crítico para el diseño. - ✅ Esquema real del `.intellibanks_sync_map.json` (verificado 7-jul-2026, 2,809 entradas): objeto plano keyado por **ruta relativa del vault** → metadatos. Ejemplo real: ```json "IB-Clientes/IB-AR-DemoVault/CP-AR-IntelliBanks-Registry-v01.md": { "skill_id": "skill_6a4750230a5393.62316560", "hash": "ce564017ef4200e413398d36c139543324065791d358b92334a1f8e4d34bd11a", "last_sync": "2026-07-03T06:01:08.289Z", "mtime": 1782165887000 } ``` Observaciones para el diseño: la **clave es la ruta** (hoy sin dimensión de empresa — con multi-empresa se prefija `/`); `skill_id` formato `skill_`; `hash` SHA-256 de bytes crudos; `mtime` epoch-ms. Nota: el mapa local ya contiene rutas de **múltiples bancos/clientes** (`IB-Clientes/IB-PO-Posta`, `IB-TG-Tecnogen`, `IB-BVH-Publications`…) bajo un solo tenant — evidencia de que hoy la separación por cliente es solo por carpetas, sin aislamiento. **D · Gobernanza / versionado** - ✅ Historial de versiones: sí, real — Git en backend + `skill_versions` con `is_current`; restauración 1-clic (`restaurar.php`). - ✅ Exclusiones: dotfiles/dotfolders en 4 capas **solo en cliente** (`pathHasDotSegment` en chokidar, guarda temprana, guardas en upload con log `DOTFILE-SKIP`). No hay allowlist de extensiones. - ✅ Atribución: `created_by`/`updated_by` + `skill_activity_logs` (usuario, acción, entidad, archivo, IP, timestamp) + `user_sync_history` (origen DESKTOP/WEB, conteos, bitácora JSON). - ✅ Guardas anti-pérdida: cliente nunca escribe/sube vacío; servidor rechaza vacíos (capa definitiva). **E · Multi-empresa — ✅ resuelto por `DC-EL-IntelliBanks-AnalisisMultiEmpresa-v01` (análisis ya trabajado; adjuntarlo)** - ✅ Modelo: **separación lógica** por una sola dimensión `company_id` (BD: tabla `companies` con `slug`, columna en `users`/`skills`/`skill_folders`, backfill a EmpowerLabs id=1). **Storage/Git intocado** (`skill_id` único global) — clave de la baja fricción. - ✅ Nube: **una sola instancia multi-tenant** (columna + filtros `WHERE company_id`), no instancia por empresa. - ✅ Cliente: un vault local con carpeta por empresa `Intellibanks//` como **proyección** del scoping; login (`signup.php`) devuelve `company_id`/`slug` → `.user_session.json` → el sync prefija rutas. - ✅ Usuario↔empresa: 1 usuario = 1 empresa (`users.company_id`); varias empresas en una máquina queda para Fase 3 (mapa de sync dentro de cada carpeta de empresa). - ✅ Regla de oro: `company_id` se resuelve **siempre en servidor** desde el usuario autenticado; el cliente jamás lo elige. Fases 0–3 definidas, cada una compatible hacia atrás. - 🔴 Decisiones de negocio abiertas (§7 del análisis — llevarlas al room como preguntas, no inventar): ¿compartir cross-empresa? (default no) · ¿`company_id` "global" para assets comunes tipo `IB-XX-Maestro`? · unicidad de nombres pasa a ser por empresa. **F · Escala** - ✅ Referencia del RFI: 6 → 100+ usuarios. Vault actual ~2,500+ skills; el crawl viejo ya no aguantaba (por eso `get_sync_map.php`). - 🔴 Números reales hoy (usuarios activos) y restricciones conocidas (costo servidor, límites Apache/PHP 5.6, CDN). --- ## 3. Brief para el room de Fable 5 (Frente 1 — pegar tal cual) > **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 adjunto (DC de producto + Sección 2 pre-llenada del SP) — 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. > - **Base multi-empresa ya analizada** (`DC-EL-IntelliBanks-AnalisisMultiEmpresa-v01`, adjunto — constrúyele encima, no la re-derives): una sola dimensión `company_id` resuelta **siempre server-side** desde el usuario autenticado (el cliente jamás la elige — es la misma regla Zero-Trust); storage/Git intocado, separación lógica en BD (tabla `companies` + columna en `users`/`skills`/`skill_folders`, backfill a EmpowerLabs); nube única multi-tenant; carpeta local `Intellibanks//` como proyección; helper único `require_company()` al inicio de cada endpoint; despliegue en Fases 0–3 compatibles hacia atrás. No propongas instancia-por-empresa ni reorganización del repo Git. > > **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 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. > 6. **(Agregado por contexto real)** El diseño debe absorber el bug de dedup de `upload.php` (skill_id inestable por ruta → duplicados que se regeneran): la identidad archivo↔ID por tenant tiene que quedar resuelta por diseño, no por limpiezas periódicas. Nota: con multi-empresa la unicidad pasa a `UNIQUE(company_id, name)` conceptual y las claves de sync por ruta quedan prefijadas por `/` — el dedup debe diseñarse sobre esa clave, no sobre la global actual. > 7. **Reconciliar el análisis multi-empresa con el Zero-Trust** (donde el análisis se queda corto, el RFI manda): (a) el camino "corto plazo" de auth (derivar `company_id` por JOIN al parámetro `usuario` del request) es falsificable — decide si la Capa 1 keystone exige el **endurecimiento de sesión desde Fase 1**, no como mejora futura; (b) resuelve las decisiones abiertas del §7 del análisis: compartir cross-empresa (default: no), `company_id` "global" para assets comunes (`IB-XX-Maestro`), unicidad por empresa; (c) plan de **migración local** bajo `/` con candado de subidas — hoy el candado (`.intellibanks_upload_lock.json`) existe solo para `JoseRojas`: generalízalo como mecanismo de migración segura; (d) los shares "sintéticos locales" actuales (sin FK real) deben renacer tenant-aware. > > **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. > > **Restricciones inviolables del proyecto:** backend en producción es PHP **5.6** (nada de sintaxis 7+; si propones migración, que sea fase explícita del plan); `cleanFileName` del cliente es la única fuente de verdad de nombres; respaldar antes de tocar backend; rama de trabajo `alex`. > > **Formato:** naming BMF, listo para el vault. Marca claramente cada supuesto que hiciste por falta de contexto, para que Alex lo confirme. --- ## 4. Adjuntos del room Frente 1 (rutas exactas en el vault) 1. `IB-EL-EmpowerLabs/EQ-EL-Equipo/DC-EL-IntelliBanks-DescripcionProducto-v01.md` — contexto del sistema (obligatorio). 2. Este SP (la §2 con los 🔴 ya llenados). 3. `IB-EL-EmpowerLabs/EQ-EL-Equipo/DC-EL-IntelliBanks-AnalisisMultiEmpresa-v01.md` — el análisis multi-tenant ya trabajado (obligatorio: es la base del punto E y de las decisiones tomadas). 4. `IB-EL-EmpowerLabs/EQ-EL-Equipo/TP-EL-IntelliBanks-MultiEmpresa-ZeroTrust-FableBrief-v01.md` — el TP fuente. 5. `IB-XX-Maestro/RFI-XX-IntelliBanks-BlindajeGobernanzaSync-v01.md` — detalle de las Capas 0–5 (verificado en vault; ahí mismo está `RFI-XX-IntelliBanks-NavInternaDashboards-v01.md` si Fable pide el detalle del punto 5). 6. Código/config real de los 🔴 que pegaste (vale más que describirlo). **Al terminar:** guardar el `ARQ-` en el vault (destino de ratificación: `IB-XX-Maestro` — escritura solo Victor/Alex/Jay), avisar a Victor (L3). --- ## 5. Frente 2 — Wargame ConnectorX (room aparte, mismo día) > **Quién:** Victor o quien él designe (confirmar antes de correr — NEXT del SP fuente). Si te toca a ti, Alex: 1. Room nuevo + `/arrancaroom`. 2. Adjuntar: `IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-SOO-SistemaOperativoOrganizacional/SP-EL-SOO-Wargame-ConnectorX-Fable5-v01.md` (el proceso completo: tablero, 5 células Rojas, rondas, salidas) + `IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-SOO-SistemaOperativoOrganizacional/MAP-EL-SOO-EcosistemaProyectado-v01.md` (§4 y §9). Existe también `SP-EL-SOO-Wargame-ConnectorX-StarterPrompt-Fable5-v01.md` en la misma carpeta — úsalo como prompt de arranque del room. 3. **Condición sin la cual alucina:** pedir a Fable búsqueda web fresca del estado MCP/AAIF, Agentforce/Copilot e incidentes de seguridad de conectores 2026 antes de la ronda R0. 4. Fable actúa como BLANCO (Scenario Master), corre R0 + las 5 células (R1 estándar, R2 comoditización, R3 seguridad, R4 hueco vertical/Posta, R5 BYO/economía) con shocks Verdes. 5. Entregable: `OUT-EL-SOO-Wargame-ConnectorX-Resultados-v01` (matriz de resiliencia + huecos priorizados + 3 reglas de decisión) → ratificación Victor → alimenta el SPEC del ConnectorX Registry. 6. **Regla EL:** nunca el nombre real del cliente con codename — siempre "Posta". --- ## 6. Después (sin Fable · validación adversarial con Opus) - **Sobre el `ARQ-`:** correr el wargame del Anexo §4 del TP (actor rojo 1 cliente hostil, rojo 2 fuga cross-empresa, rojo 3 caos a escala). Salida: huecos → correcciones al `ARQ-` antes de Fase 1. - **Sobre el `OUT-` del wargame:** segunda pasada atacando las celdas ✅ *Cubierta* (buscar auto-complacencia). Los desacuerdos entre modelos señalan dónde mirar. - Solo entonces arranca implementación (Fase 0 → Fase 1 keystone del RFI §8). --- ## 7. Tripleta + NEXTs - **Owner del plan:** Alex · **Sherpa:** SherpaX Alex · **Ratificador:** Victor (L3 arquitectura) **NEXTs** - [x] ~~Llenar los 🔴 de §2~~ — **cerrados el 7-jul** (repo, config vault, auto-update, sesión, sync map). Solo queda F: números reales de usuarios/costos (llevarlo como dato suelto al room). - [ ] **Alex** — correr Frente 1 con Fable 5 **HOY** → `ARQ-EL-IntelliBanks-MultiEmpresa-ZeroTrust-v01` al vault → Victor. - [ ] **Victor/designado** — correr Frente 2 (wargame ConnectorX) **HOY** → `OUT-EL-SOO-Wargame-ConnectorX-Resultados-v01`. - [ ] **Jay/equipo** — validación adversarial con Opus sobre ambos entregables (§6), otro día. - [ ] **Alex** — el fix de dedup en `upload.php` NO se parcha aislado: queda absorbido en el diseño del `ARQ-` (punto 6 del brief). Si el `ARQ-` se retrasa, evaluar parche puente. --- ## CHANGELOG | Versión | Fecha | Cambio | |---|---|---| | v01 | 2026-07-07 | Creación. Plan de acción autocontenido que integra TP MultiEmpresa-ZeroTrust + SP Wargame ConnectorX + DC de producto. Sección 2 del TP pre-llenada desde el DC (gaps 🔴 marcados), brief Fable enriquecido con restricciones reales (PHP 5.6, cleanFileName, bug dedup upload.php como requisito de diseño), secuencia del día y ruta post-Fable con Opus. | | v01 (cotejo) | 2026-07-07 | Cotejo con `ANALISIS-MultiEmpresa.md` (canonizado como `DC-EL-IntelliBanks-AnalisisMultiEmpresa-v01`). Punto E de §2 pasa de 🔴 a ✅ (company_id server-side, storage/Git intocado, nube única multi-tenant, carpeta `/` como proyección, Fases 0–3). Brief: nueva decisión tomada (base multi-empresa) + punto 7 con las tensiones a reconciliar (endurecimiento de sesión vs camino corto, decisiones abiertas §7, migración con candado generalizado, shares tenant-aware) y dedup sobre clave por empresa. |