## Asset Header
- **Asset ID:** OUT-EL-RetiroCreativo-VaultReorg-2026-04-11-v01
- **Version:** v01
- **Status:** Final
- **Owner:** Victor Heredia
- **IntellBank:** IB-EL-EmpowerLabs
- **Tipo:** OUT — Output de sesión / Minuta de trabajo
- **Propósito:** Reporte completo para el equipo sobre la reorganización del vault Reinventaverse durante el retiro creativo del 11 de abril 2026. Documenta qué se hizo, cómo quedó el sistema y qué consideraciones se deben tener al continuar trabajando.
- **Última actualización:** 2026-04-11
---

# Retiro creativo 11 abr 2026 — minuta de vault

**Fecha:** 11 de abril 2026
**Participantes:** Victor Heredia + SherpaIA
**Duración:** Sesión extendida (retiro de 2 días: 11-12 abr)
**Sesión:** 1 de 2

---

## Resumen ejecutivo

El 11 de abril 2026 se realizó una reorganización completa del vault Reinventaverse. Se llevaron a cabo tres transformaciones mayores en paralelo:

1. **Cleanup del registry**: se eliminaron los dos archivos BMF Registry legacy y se creó un único registry maestro en IB-XX-Maestro.
2. **Estandarización masiva de Asset Headers**: se actualizaron 468 archivos .md en los 6 IntelliBanks activos con headers completos y consistentes.
3. **Construcción del LLM Wiki**: se diseñó e implementó desde cero la arquitectura LLM Wiki (metodología Karpathy), se ingresaron 153 fuentes en 3 rondas y se generaron 30 páginas de conocimiento sintetizado.

El vault pasó de un estado de documentos parcialmente etiquetados y registros duplicados, a un sistema con identificación consistente, un registry maestro único y una capa de conocimiento semántico operativa.

---

## 1. Cambios estructurales

### 1.1 Registry maestro — creado

**Archivo creado:**
```
IB-XX-Maestro/CP-XX-IntelliBanks-Registry-v01.md
```

**Archivos eliminados (legacy):**
```
IB-EL-EmpowerLabs/CP-EL-Control-Planes/CP-BMF-Registry-Activos-v01.md
IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-BMF-BigMetaFactory/CP-EL-BMF-Registry-Activos-v01.md
```

El nuevo registry es el documento de control único para todos los activos del ecosistema. Contiene el panel de control con totales por IntellBank, la tabla completa de 498 activos (Asset ID | IntellBank | Tipo | Versión | Status | Notas) y la convención de nomenclatura canónica.

**Regla:** Cuando se agrega un activo nuevo a cualquier IntellBank, se debe registrar en `CP-XX-IntelliBanks-Registry-v01.md`. No existen más registros locales por banco.

### 1.2 Asset Headers — estandarizados

Se procesaron **468 archivos .md** en los 6 IntelliBanks activos. Todos tienen ahora el header estándar completo:

```markdown
## Asset Header
- **Asset ID:** [nombre del archivo sin extensión]
- **Version:** vNN
- **Status:** Draft
- **Owner:** Victor Heredia
- **IntellBank:** IB-XX-[Nombre]
- **Tipo:** PREFIJO — Nombre completo del tipo
- **Propósito:** [descripción del propósito del documento]
- **Última actualización:** 2026-04-11
---
```

**Nota importante para el equipo:** Todos los Status están en `Draft`. Conforme se revise y valide cada documento, el Status debe actualizarse a `Active`, `Deprecated` o `Archived` según corresponda. Este es trabajo progresivo — no se espera que se haga de golpe.

### 1.3 LLM Wiki duplicado — eliminado

Se encontró y eliminó una carpeta vacía/duplicada:
```
IB-EL-EmpowerLabs/LW-EL-LLM-Wiki/   ← eliminada (vacía, duplicado)
LLM-Wiki/                              ← versión operativa, esta es la correcta
```

El LLM Wiki vive en el **root del vault**, separado de los IntelliBanks. Esto es intencional: es una capa de síntesis que extrae de múltiples IBs, no un banco en sí mismo.

---

## 2. Estado actual del vault

### IntelliBanks activos (6)

| IntellBank | Activos | Descripción |
|-----------|---------|-------------|
| IB-XX-Maestro | 83 | Capa canónica Clase C — todo el conocimiento fundacional |
| IB-EL-EmpowerLabs | 239 | Capa operativa Clase O — operación diaria EmpowerLabs |
| IB-MPX-MasterPlaybooks | 79 | Editorial MasterPlaybooks — CEO100X, demand gen |
| IB-BVH-Publications | 53 | Publicaciones Clase P — libros, papers, PBOs |
| IB-TriRH-TribusRRHH | 14 | Factoría Tribus RRHH |
| IB-REB-Rebelocity | 30 | Operación Rebelocity |
| **Total** | **498** | |

### LLM Wiki

| Elemento | Cantidad |
|----------|----------|
| Páginas en Wiki/ | 30 |
| Fuentes en Raw/ | 153 |
| Rondas de ingest | 3 |
| Links rotos | 0 |

---

## 3. El LLM Wiki — qué es y cómo funciona

### Arquitectura

El LLM Wiki implementa la metodología Karpathy para bases de conocimiento semántico. Tiene dos zonas:

```
LLM-Wiki/
├── Raw/              ← fuentes originales (inmutables, no editar aquí)
│   ├── IB-XX-Maestro/      (83 archivos — capa canónica)
│   ├── IB-BVH-Publications/ (31 archivos — capa narrativa/comercial)
│   └── PB-SX-SherpaX/      (38 archivos — capa operativa)
├── Wiki/             ← páginas de conocimiento sintetizado (30 páginas)
└── index.md          ← punto de entrada y navegación maestra
```

**Regla de las dos zonas:**
- `Raw/` = fuentes originales copiadas. **Nunca se editan directamente.** Si el original cambia, se reemplaza en Raw/.
- `Wiki/` = síntesis generada. Son páginas de conocimiento conectado, no documentos operativos.

### Las 30 páginas del Wiki (organizadas por categoría)

**Fundamentos del ecosistema:**
`BigMetaFactory` · `DOIX` · `HIOrgs` · `EmpowerLabs` · `Victor-Heredia`

**Inteligencia y arquitectura:**
`BrainOS` · `IntelliBanks` · `MetaPlaybooks` · `BrainCodes` · `AI-Agent-Memory`

**SherpaX (sistema completo):**
`SherpaX` · `SherpaX-Ignition` · `SherpaX-ICP` · `SherpaX-Value-Proposition` · `SherpaX-GTM` · `SherpaX-SOPs`

**Operaciones y metodología:**
`MetaFactories` · `EmpowerTeams-X` · `WERK` · `FactoryOS` · `MF-TRANSFORMATION`

**Medición y diagnóstico:**
`IQ-Organizacional` · `DOIX-Maturity-Index` · `Coordination-Tax` · `Empowernomics`

**Publicaciones y contenido:**
`MasterPlaybooks` · `Rebelocity`

**Sistema de conocimiento:**
`4-Clases-Documentos` · `Naming-Convention` · `CP-XX-IntelliBanks-Registry`

### Cómo usar el Wiki

El wiki **no es un repositorio de documentos**, es un grafo de conocimiento. Se navega por conceptos, no por carpetas. El flujo natural es:

1. Abrir `index.md` como punto de entrada
2. Identificar el concepto que te interesa
3. Seguir los `[[WikiLinks]]` para explorar conexiones
4. Usar Obsidian Graph View para ver el mapa visual

**Queries recomendadas para explorar:**
- *"¿Cómo se relaciona DOIX con HIOrgs?"* → navega DOIX → IQ-Organizacional → HIOrgs
- *"¿Cuál es el ICP de SherpaX Ignition?"* → SherpaX-ICP → SherpaX-Ignition
- *"¿Qué diferencia a SherpaX de ChatGPT?"* → SherpaX-Value-Proposition
- *"¿Cómo se instala SherpaX para un cliente nuevo?"* → SherpaX-SOPs → SherpaX-Ignition
- *"¿Cuáles son los costos ocultos de la coordinación?"* → Coordination-Tax → Empowernomics

---

## 4. Consideraciones para el equipo

### 4.1 Nomenclatura — regla crítica

La convención de nombres es la base de todo el sistema. Un archivo mal nombrado no aparece en el registry, no puede ser referenciado correctamente en WikiLinks y rompe el flujo de ingest del Wiki.

**Formato:** `TIPO-ENTIDAD-Proyecto-NombreDescriptivo-vNN.ext`

El **TIPO siempre va primero**. Ejemplos:
- `CP-XX-IntelliBanks-Registry-v01.md` ✅
- `IntelliBanks-Registry-CP-XX-v01.md` ❌

Los tipos canónicos más usados: `CP` (control plane), `SOP` (procedimiento), `TP` (technical protocol), `MKT` (marketing), `PBO` (playbook operativo), `PLB` (playbook), `OUT` (output de sesión), `MiPg` (minuta).

Para la lista completa, ver: `IB-XX-Maestro/CP-XX-Naming-Convention-v01.md`

### 4.2 Asset Headers — cómo mantenerlos

Cada nuevo archivo .md debe incluir el header completo al inicio. El campo **Status** es el más importante de mantener actualizado:

| Status | Significado |
|--------|-------------|
| Draft | Recién creado, no revisado |
| Active | Revisado y validado, en uso |
| Deprecated | Reemplazado por versión más nueva |
| Archived | Ya no vigente pero se conserva |

Al crear un documento nuevo, inicia con `Status: Draft`. Cuando lo revisas y validas, cambia a `Active`.

### 4.3 Registry — cuándo actualizarlo

El registry (`CP-XX-IntelliBanks-Registry-v01.md`) debe actualizarse cuando:
- Se crea un nuevo activo en cualquier IntellBank
- Se cambia la versión de un activo
- Se archiva o depreca un activo
- Se mueve un activo de IntellBank

No es necesario actualizarlo por cambios menores de contenido dentro de un documento existente.

### 4.4 LLM Wiki — qué entra y qué no

**Entra al Wiki:**
- Documentos Clase C (canónicos) — todos los de IB-XX-Maestro
- Papers, PBOs, PLBs con conocimiento transferible
- SOPs y protocolos de entrega (capa operativa)
- Frameworks y metodologías

**No entra al Wiki:**
- Outputs de sesiones (OUT-, MiPg-) — son registros, no conocimiento
- Documentos de datos coyunturales (estados de cuenta, tracker de eventos)
- Borradores sin revisar
- Información confidencial específica de clientes

**Cuándo hacer un nuevo ingest:**
Cuando se acumule un conjunto coherente de documentos nuevos que cubra un tema o capa que aún no está representada. No hace falta ingestar uno por uno — se hace por "capas temáticas".

---

## 5. Próximas rondas de ingest identificadas

| Fuente | Archivos aprox. | Qué aporta |
|--------|-----------------|------------|
| IB-EL/PB-BMF-BigMetaFactory | ~54 | Factorías en operación — el "cómo se construye" |
| IB-MPX-MasterPlaybooks | ~43 | Editorial CEO100X, demand gen, estructura de playbooks |
| IB-EL/BC-EL-BrainCodes | Por definir | Brain Codes del equipo (solo conceptos generales — es confidencial) |

---

## 6. Skills — auditoría y actualizaciones

Durante la sesión se realizó una auditoría completa de todos los skills instalados. Resultado:

### Skills genéricos — sin cambios requeridos
`schedule` · `xlsx` · `pdf` · `pptx` · `docx` · `skill-creator` · `setup-cowork` · `cowork-plugin-management`
No tienen referencias al vault — están bien tal como están.

### Skills del ecosistema — actualizados

| Skill | Acción | Problema resuelto |
|-------|--------|------------------|
| `bmf-registry-updater` | ✅ Reescrito | Apuntaba a `BMF-Registry-Activos-v01.md` (eliminado) y a `/BigMetaFactory/` (ya no existe). Ahora apunta a `CP-XX-IntelliBanks-Registry-v01.md` y escanea los 6 IntelliBanks. |
| `bmf-file-renamer` | ✅ Reescrito | Usaba patrón `PREFIX-Description-vNN` y prefijos legacy (`SHA-`, `BMF-`, `MPB-`). Ahora usa el patrón canónico `TIPO-ENTIDAD-Proyecto-Nombre-vNN` con la tabla completa de TIPOs actuales. |
| `llm-wiki-validator` | ✅ Creado nuevo | Skill nuevo — valida qué archivos califican para entrar al Raw/ del Wiki, audita links rotos, detecta páginas huérfanas y genera reporte de salud. |

### Consideración para el equipo
Los tres skills están empaquetados como `.skill` en la raíz del vault para su instalación. Instalar vía "Save skill" en Cowork. El `bmf-registry-updater` y `bmf-file-renamer` reemplazan las versiones anteriores al instalarse.

---

## 7. Pending de esta sesión

- [ ] **Status de Asset Headers**: Los 468 archivos tienen Status=Draft. Se requiere revisión progresiva para promover los documentos validados a `Active`.
- [ ] **Vault root**: Hay archivos sueltos en la raíz del vault (daily notes, .md sin clasificar) que no se tocaron en esta sesión.
- [ ] **Registry sync automatizado**: Tarea programada para sincronizar el registry periódicamente — pendiente de crear.
- [x] **Playbook del LLM Wiki**: Creado → `LLM-Wiki/Wiki/LLM-Wiki-Playbook.md`
- [x] **Skill de validación del Wiki**: Creado → `llm-wiki-validator.skill` (instalar desde raíz del vault)
- [x] **Proceso de construcción de IBs**: Creado → `IB-XX-Maestro/SOP-XX-IntellBank-Build-Process-v01.md`
- [x] **Skills auditados y actualizados**: `bmf-registry-updater` y `bmf-file-renamer` reescritos; `llm-wiki-validator` creado

---

## 8. Lo que se construyó en perspectiva

Antes de esta sesión, el vault era un repositorio de documentos con identificación parcial y sin capa semántica. Después de esta sesión:

- **Cada documento tiene identidad**: Asset ID, versión, tipo, propósito, banco de pertenencia.
- **Existe un punto de verdad único**: El registry maestro en IB-XX-Maestro.
- **Existe una capa de conocimiento**: 30 páginas interconectadas que sintetizan 153 fuentes — consultable como un agente que conoce el ecosistema completo.
- **La arquitectura escala**: La metodología está documentada. Agregar un nuevo cliente al sistema (IB-DM-DemoEmpresa o un IB de cliente real) sigue el mismo proceso.

El LLM Wiki es la primera vez que el ecosistema puede "hablarse a sí mismo" — una IA consultando el wiki puede dar respuestas informadas sobre BigMetaFactory, SherpaX, DOIX y todos sus componentes, con contexto real del ecosistema, no genérico.

---

*Minuta generada por SherpaIA · Retiro creativo 11-abr-2026 · Sesión 1*