---
asset_id: TP-EL-WORX-WikiMaintenance-v01
version: v01
tipo: TP — Transfer Pack
room: WikiMaintenance · LLM Wiki Maintenance Room
status: Active
owner: Victor Heredia
sherpa_owner: Jay (SherpaX maestro)
intellibank: IB-EL-EmpowerLabs
subbank: PB-EL-Project-Bank / PB-WORX-Worx
fecha_creacion: 2026-05-07 EOD
fecha_ultima_actualizacion: 2026-05-07 EOD
proposito: |
  Transfer Pack canónico del room de mantenimiento periódico del LLM Wiki.
  Define cadencia · roles · 3 opciones de refresh · pipeline de ingest · health metrics.
  Aplicable a EmpowerLabs (Wiki interno) y replicable a clientes B2B (cada cliente tiene su propio Wiki).
room_raiz: PB-WORX-Worx/ (P011 · linaje protocolos universales del cohort SherpaX)
protocolos_heredados:
  - PROT-EL-WORX-Cohort-OperatingProtocols-v01 (9 principios + 3 SOPs + Skill Pack)
  - SOP-EL-WORX-RoomActivation-v01 (P011+P012 · 7 estaciones de activación)
  - SOP-EL-WORX-BrainOSFirst-v01 (P006 · output CONS-)
  - SOP-EL-WORX-DocBySherpa-v01 (P010 · captura delegada)
  - MePB-EL-CorpBrainOS-BehaviorCapture-v01 (qué cruza al colectivo · 3 capas)
deriva_de:
  - llm-wiki-validator (skill canónica · pre-ingest validation + post-ingest health check)
  - IB-WikiX/Wiki/LLM-Wiki-Playbook.md (playbook existente)
  - IB-WikiX/Wiki/README.md (README del Wiki)
  - IB-WikiX/Raw/README.md (README del Raw)
referenciado_por:
  - MePB-EL-OrganizationalKernel-v01 (frame organizacional)
  - SOP-EL-WORX-ManualOperativo-v01 v02 (manual operativo replicable)
  - XP-EL-HIORG-Caso0-EmpowerLabs-v02 (Caso 0 referencia este room para mantenimiento del Wiki interno)
tags: [TP, LLM-Wiki, WikiMaintenance, refresh, ingest, P010, P011, healthcheck]
total_sesiones: 0 (room en creación · sesión 0 = este TP)
---

# Transfer Pack — WikiMaintenance Room
## LLM Wiki Maintenance · cadencia operativa periódica

---

## I. ESTADO ACTUAL — Sesión 0 (creación · 2026-05-07 EOD)

### I.1 Detonante

Victor identifica que el LLM Wiki está **desactualizado**. La última ingest masiva data de 2026-04-11 (era pre-LabPraxis · pre-WORX MPB v0.6 · pre-MePBs canónicos · pre-Caso 0). El Wiki vive en una era arquitectónica anterior.

Necesidad: **room dedicado** con cadencia periódica que mantenga el Wiki sincronizado con el vault · porque sin Wiki actualizado:
1. El SherpaX consume contexto canónico desactualizado (degrada compounding · viola P006).
2. El método replicable a clientes B2B se vuelve frágil (cada cliente reproduce el Wiki desactualizado).
3. Decisiones nuevas no se citan correctamente (ej. CASO 016 Diana Hu YC · concepto Company Aquarium · sin Wiki page).
4. Coverage gaps de conceptos críticos generan re-explicación cada vez (anti-patrón Hero-Operator).

### I.2 Health Report al 2026-05-07 EOD (output `llm-wiki-validator`)

| Métrica | Valor | Veredicto |
|---|---|---|
| Páginas Wiki/ | 37 | OK · pero faltan ~15 críticas |
| Archivos Raw/ | 281 | Mayormente IB-XX-Maestro · poca cobertura del resto |
| Broken WikiLinks | 7 (4 placeholders del Playbook · no críticos) | 🟢 Mínimo |
| Páginas huérfanas | 3 (GPTBank · PLAN-DocumentType · WORX) | 🟡 Bajo |
| Activos sesión 009/009b sin ingest | 11/11 | 🔴 Pendiente |
| Coverage gaps críticos | 15 conceptos | 🔴 Wiki en era pre-LabPraxis |

### I.3 Coverage gaps críticos identificados

**Conceptos sin Wiki page · 218 archivos del vault los mencionan pero no hay página dedicada:**

**Tier 1 · Críticos (canonizados pre-2026-04 · deberían existir desde hace tiempo):**
- `Re100X` · programa fundacional de Victor · 4 capas · CAM · Hiperpoder · MONEX
- `CAM` · Centro de Apalancamiento Masivo · DC-EL-R100X-CAM-Metodo-v02
- `MONEX` · Monetiza tu Expertise · escalera R100X
- `MasterFormulas` · MFR- · L2 del Cognitive Asset Stack · CITE
- `MEL` · Mastery Enforcement Layer · L6 BMF Governance
- `WORX OS` · arquitectura conectiva
- `Cognitive-Asset-Stack` · 6 capas (MiPB → MFR → MPB → MePB → MPI → BC)
- `MasterSuite` · DO IT 2004-era · linaje pre-DOIX

**Tier 2 · Operativos (canonizados pre-2026-05-07):**
- `LabPraxis` · banco de casos + principios canonizados (P001-P012)
- `HDC` · Human Design Code · banco PB-HDC-HumanDesignCode · Anahí owner
- `TribusRRHH` · vertical RRHH · iniciativa operativa
- `Posta` · cliente B2B · proyecto demo

**Tier 3 · Canonizados hoy (sesión 009/009b · 2026-05-07):**
- `Company-Aquarium` · concepto post-Diana Hu YC validation (CASO 016)
- `Room-Raiz` · P011 · arquitectura de Room Raíz
- `WORX-Capacities` · 5 capacidades del trabajador WORX (§8 MPB-WORX)

### I.4 11 activos producidos hoy sin ingest a Raw/

| Asset | IntellBank · SubBank |
|---|---|
| PROT-EL-WORX-Cohort-OperatingProtocols-v01 | IB-EL / PB-WORX-Worx |
| SOP-EL-WORX-RoomActivation-v01 | IB-EL / PB-WORX-Worx |
| SOP-EL-WORX-DocBySherpa-v01 | IB-EL / PB-WORX-Worx |
| MAP-EL-RoomRaiz-Linaje-v01 | IB-EL / PB-WORX-Worx |
| MePB-EL-OrganizationalKernel-v01 | IB-EL / CP-EL-Control-Planes |
| MePB-EL-CorpBrainOS-BehaviorCapture-v01 | IB-EL / PB-WORX-Worx |
| PLB-EL-Caso0-PreIgnitionWorkbook-v01 | IB-EL / PB-CASO0-HIORG |
| PLB-EL-Caso0-Etapa1Workbook-v01 | IB-EL / PB-CASO0-HIORG |
| XP-EL-HIORG-Caso0-EmpowerLabs-v02 | IB-EL / PB-CASO0-HIORG |
| SP-EL-HIORG-Caso0-EmpowerLabs-StarterPrompt-v02 | IB-EL / PB-CASO0-HIORG |
| MAP-EL-Rooms-Monetizacion-Domino-v01 v01.2 | IB-EL / PB-MONETIZACION-Estrategica |

---

## II. PROPÓSITO Y ALCANCE DEL ROOM

### II.1 Misión

Mantener el LLM Wiki sincronizado con el vault y con la realidad operativa del ecosistema EmpowerLabs · con cadencia periódica · sin overengineering.

### II.2 In scope

- Ingest selectivo de nuevos activos a `Raw/` (siguiendo reglas pre-ingest validation de la skill `llm-wiki-validator`).
- Creación de páginas Wiki nuevas para cubrir GAPS de coverage.
- Update de páginas Wiki desactualizadas (estados · counts · referencias).
- Reconstrucción de WikiLinks (cross-referencing canónico).
- Health checks periódicos (`llm-wiki-validator` · post-ingest).
- Mantenimiento del `index.md` y README.

### II.3 Out of scope

- Producción de activos canónicos del vault (eso vive en sus rooms operativos correspondientes).
- Decisiones arquitectónicas del BMF / WORX (eso vive en LabPraxis · Methodology Room · etc.).
- Distribución del Wiki a clientes B2B (eso vive en HIORGS Portfolio · línea comercial).

---

## III. LAS 3 OPCIONES DE REFRESH (decisión pendiente Victor)

Estas son las 3 opciones canónicas de refresh · este room ejecuta una de ellas en cada ciclo según prioridad y bandwidth disponible.

### OPCIÓN A · Refresh masivo (8-15 hrs · 1-2 sesiones dedicadas)

**Cuándo aplicar:** Wiki ha vivido en era arquitectónica anterior · gaps críticos acumulados · próximo cliente B2B inminente.

**Acciones:**
1. **Ingest a `Raw/`** · 11 nuevos activos del 2026-05-07 + ~25 más de últimas semanas (BMF · WORX · LabPraxis · CASO 0).
2. **Crear ~15 páginas Wiki nuevas** de los GAPS críticos:
   - Tier 1 (8): Re100X · CAM · MONEX · MasterFormulas · MEL · WORX OS · Cognitive-Asset-Stack · MasterSuite
   - Tier 2 (4): LabPraxis · HDC · TribusRRHH · Posta
   - Tier 3 (3): Company-Aquarium · Room-Raiz · WORX-Capacities
3. **Update páginas Wiki existentes** desactualizadas (CP-XX-IntelliBanks-Registry · IntelliBanks · MetaPlaybooks · BrainCodes).
4. **Reconstruir links cross-referencing** canónico entre páginas (mínimo 5 inbound links por página clave).
5. **Update `index.md` + `README.md`** con nueva estructura.

**Output:** Wiki al día con 2026-05-07 EOD · listo para uso interno + replicación B2B.

### OPCIÓN B · Refresh focalizado (3-5 hrs · 1 sesión)

**Cuándo aplicar:** sólo lo crítico para no bloquear operación + clientes B2B inminentes en pipeline.

**Acciones:**
1. **Ingest de los 11 activos nuevos** del 2026-05-07 a `Raw/`.
2. **Crear 6 páginas Wiki más críticas** (priorización):
   - LabPraxis (banco de casos + principios)
   - WORX OS (arquitectura conectiva)
   - Cognitive-Asset-Stack (6 capas)
   - Company-Aquarium (concepto post-Diana Hu)
   - Room-Raiz (P011)
   - MEL (L6 governance)
3. **Update CP-XX-IntelliBanks-Registry** Wiki page (count 619 → 630).
4. Update **IntelliBanks** Wiki page con nuevos activos.

**Output:** Wiki usable para cohort + cliente B2B · gaps Tier 1 y 3 cubiertos · gaps Tier 2 diferidos.

### OPCIÓN C · Solo plan + nada más hoy (30 min)

**Cuándo aplicar:** día intenso · capacidad bloqueada · necesidad de delegar ejecución a alguien más.

**Acciones:**
1. Producir activo canónico `PLAN-EL-WikiRefresh-Roadmap-v01` con priorización completa + lista de páginas a crear.
2. Asignar NEXTs por persona y plazo.
3. **No se hace update real** del Wiki en esta sesión.

**Output:** Plan ejecutable · siguiente sesión del room ejecuta el plan.

### Selector de opción

| Si... | Elige |
|---|---|
| Próximo cliente B2B en <7 días | **A** |
| Próximo cliente B2B en 1-3 semanas + cohort interno corriendo | **B** |
| Día/semana saturada · sin bandwidth | **C** |
| Wiki ha pasado >30 días sin refresh | **A o B** (no C) |
| Wiki ha pasado <30 días sin refresh + sin gaps Tier 1 | **C** |

---

## IV. CADENCIA OPERATIVA DEL ROOM

### IV.1 Cadencia recomendada · MVP de gobernanza (P009 candidato banco)

**Empezar con cadencia mínima · escalar solo si el MVP se queda corto.**

| Cadencia | Frecuencia | Output |
|---|---|---|
| **Sesión periódica de mantenimiento** | Mensual (1° viernes del mes · 60-90 min) | Health Report + ingest del mes + update páginas afectadas |
| **Health check rápido** | Quincenal (15 min · async vía skill `llm-wiki-validator`) | Health metrics actualizados · alertas si gaps Tier 1 emergen |
| **Refresh masivo (Opción A)** | Trimestral (cierre de quarter · 1 día dedicado) | Wiki al día con últimos 90 días de evolución |
| **Refresh focalizado (Opción B)** | Ad-hoc · cuando viene cliente B2B inminente o canonización mayor | Wiki listo para uso comercial específico |
| **Refresh emergencia (Opción C → A)** | Cuando gaps Tier 1 acumulados >5 | Plan canónico → ejecución masiva siguiente sesión |

### IV.2 Triggers de escalación

- **>5 gaps Tier 1** (canónicos arquitectónicos sin Wiki page) → escalar de Opción C a Opción A en próxima sesión.
- **>15 archivos producidos sin ingest a Raw/** → activar Opción B (ingest selectivo) en sesión periódica mensual.
- **Próximo cliente B2B inminente** → activar Opción A o B según gap real con cliente.
- **>3 ciclos mensuales sin refresh** → activar Opción A obligatoria (deuda técnica acumulada).

### IV.3 Quién participa por sesión

- **Owner (Victor)** · valida ingest selection · ratifica páginas nuevas · prioriza GAPs.
- **Sherpa Owner (Jay)** · ejecuta health check (skill `llm-wiki-validator`) · produce páginas · actualiza index · documenta CAS si emerge aprendizaje.
- **Anahí (DG · MasterPlaybooks)** · revisa coverage de canónicos editoriales (Papers · MPB · MFR) · sugiere páginas para cascade content.
- **Alex (Tech Lead)** · revisa coverage de canónicos arquitectónicos (WORX OS · Supabase · MEL · BMF Engine).

---

## V. PIPELINE DE INGEST · operacionalizado vía `llm-wiki-validator`

### V.1 Pre-ingest validation (Mode 1 de la skill)

Cuando un nuevo activo nace en el vault · evaluar si califica para `Raw/`:

| Tipo | ¿Califica? |
|---|---|
| Class C canónicos (IB-XX-Maestro) | ✅ Siempre |
| MePB-, MPB-, ARQ-, DC-, GLO- | ✅ Siempre |
| PROT-, SOP-, TP-, PLB-, CP- | ✅ Sí · si tiene contenido sustantivo |
| PA-, WP-, PP- (papers) | ✅ Sí · si transferible |
| OUT-, MIN-, MiPg- | ❌ No · coyuntural |
| Trackers (.xlsx) | ❌ No |
| Drafts vacíos | ❌ No |

### V.2 Post-ingest health check (Mode 2 de la skill)

Después de cada ingest · ejecutar 5 checks:
1. **Broken WikiLinks** · scan `[[X]]` patterns en Wiki/.
2. **Páginas huérfanas** · sin inbound links.
3. **Coverage gaps** · archivos Raw/ sin Wiki page correspondiente.
4. **Asset Header completeness** · 8 campos canónicos por página.
5. **Index consistency** · `index.md` sincronizado con file count.

### V.3 Output canónico de cada sesión

- **Health Report** (formato canónico de la skill) · queda en este TP como Anexo de cada sesión.
- **Lista de archivos ingestados** a Raw/ con timestamps.
- **Lista de páginas creadas / actualizadas** en Wiki/.
- **CAS LabPraxis** si emerge aprendizaje operativo del ciclo.

---

## VI. ROLES Y RESPONSABILIDADES

| Rol | Persona | Responsabilidad |
|---|---|---|
| **Owner** | Victor Heredia | Decisor de Opción A/B/C por ciclo · ratificador de páginas críticas |
| **Runner / Sherpa Owner** | Jay (SherpaX maestro) | Ejecutor del health check · productor de páginas · update index · documentación CAS |
| **DG Reviewer** | Anahí | Revisora de coverage editorial (Papers · MPB · MFR) |
| **Tech Reviewer** | Alex | Revisor de coverage arquitectónica (WORX OS · BMF Engine · MEL) |
| **Cliente facing reviewer** (futuro · cuando línea B2B activa) | Ángeles + JC | Validar que páginas críticas están listas para uso comercial |

---

## VII. DECISIONES TOMADAS — NO REABRIR

- Wiki vive en `IB-WikiX/Wiki/` · Raw en `IB-WikiX/Raw/` (heredado · canonizado pre-2026-04).
- Skill `llm-wiki-validator` es la herramienta canónica · no se reemplaza · se evoluciona.
- Cadencia mínima viable: mensual + emergencia. NO overengineering (P009 candidato banco · MVP de gobernanza).
- Inheritance del Room Raíz `PB-WORX-Worx/` (P011) · NO se duplica protocolos.

---

## VIII. REGLAS DEL ROOM

1. **SOP-RoomActivation forzoso** al inicio de cada sesión (P011+P012 · 7 estaciones).
2. **SOP-BrainOSFirst** antes de proponer cualquier nueva categoría de página o cambio estructural (P006 · output CONS-).
3. **SOP-DocBySherpa** en cada producción de página nueva (P010 · naming canónico + ruta canónica + frontmatter).
4. **Curaduría humana** antes de ingestar cualquier activo a Raw/ (P010 + Cap 5 §8 MPB-WORX · ver MePB-EL-CorpBrainOS-BehaviorCapture-v01 §3).
5. **No producir páginas Wiki sin coverage gap declarado** · cada página nueva debe responder a un gap real (no proactive bloat).
6. **Cada sesión cierra con CAS LabPraxis** si emerge aprendizaje operativo del ciclo.
7. **Skill `llm-wiki-validator` ejecutada** al inicio (pre) y al cierre (post) de cada sesión.

---

## IX. NEXTs

### Inmediatos (esta semana)

- [NEXT][Victor] Decidir cuál opción (A · B · C) ejecutar primero · respuesta antes de Sesión 1 del room.
- [NEXT][Jay] Producir `SP-EL-WORX-WikiMaintenance-StarterPrompt-v01` (Starter Prompt acompañante de este TP · regla del room cohort).
- [NEXT][Jay] Producir `XP-EL-WORX-WikiMaintenance-v01` (XPack del room · panorama operativo + KPIs).

### Próxima sesión periódica (mensual)

- [NEXT][Jay] Ejecutar skill `llm-wiki-validator` · health check completo.
- [NEXT][Jay] Revisar 11 activos sesión 009/009b sin ingest · proponer cuáles ingestar.
- [NEXT][Victor] Ratificar páginas Wiki nuevas a crear (Tier priorizado).
- [NEXT][Anahí + Alex] Validar coverage editorial + arquitectónico respectivamente.

### Trimestrales

- [NEXT][Jay] Refresh masivo (Opción A) cierre de quarter · agendar Q2 2026 cierre.
- [NEXT][Jay] Producir `SOP-EL-WORX-WikiMaintenance-Cadence-v01` formal después de 3 ciclos mensuales (validación del MVP de gobernanza · P009 candidato banco).

### Pendientes estructurales

- [NEXT][Victor] Decidir si Wiki tiene capa cliente-facing (versión sanitizada para clientes B2B · estilo Demo Vault Alain) o solo interna.
- [NEXT][Jay] Si se aprueba capa cliente-facing · producir `MePB-EL-WikiClientFacing-v01` con reglas de sanitización.

---

## X. CONEXIONES CANÓNICAS

| Documento | Relación |
|---|---|
| `IB-WikiX/Wiki/LLM-Wiki-Playbook.md` | Playbook existente del Wiki · lo extiende |
| `IB-WikiX/Wiki/README.md` | README del Wiki · sincronizable con cada sesión |
| skill `llm-wiki-validator` | Herramienta canónica · ejecutada cada sesión |
| `MePB-EL-CorpBrainOS-BehaviorCapture-v01` | Reglas de qué cruza al colectivo · aplican al ingest del Wiki |
| `PROT-EL-WORX-Cohort-OperatingProtocols-v01` | 9 principios + 3 SOPs forzosos heredados |
| `MAP-EL-RoomRaiz-Linaje-v01` | Este room hereda de PB-WORX-Worx (Raíz 1) |
| `TP-EL-WORX-LabPraxis-v01` v1.6 | Cada CAS de aprendizaje del Wiki se documenta en LabPraxis |
| `CP-XX-IntelliBanks-Registry-v01` | Registry · se sincroniza con cada ingest de Raw/ |
| `MePB-EL-OrganizationalKernel-v01` | Frame organizacional · este room es L3 Operations |

---

## XI. CHANGELOG

- **2026-05-07 EOD · v01** — Primer release. Sesión 0 (creación del room). Health Report inicial documentado · 3 opciones de refresh (A masivo · B focalizado · C plan-only) canonizadas · cadencia mensual MVP propuesta · roles asignados · pipeline de ingest operacionalizado vía skill `llm-wiki-validator`. Producido en sesión 009b LabPraxis (post-rename masivo · post-MePBs canónicos). Hereda del Room Raíz PB-WORX-Worx (P011) · aplica los 3 SOPs forzosos del cohort. NEXT inmediato: Victor decide A/B/C · Jay produce SP- + XP- acompañantes.

---

*TP-EL-WORX-WikiMaintenance-v01 · IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-WORX-Worx/ · 7 de mayo de 2026 EOD*
*Owner: Victor Heredia · Sherpa Owner: Jay (SherpaX maestro) · Room Raíz: PB-WORX-Worx*
*"Wiki vivo es Wiki útil. Wiki desactualizado degrada el compounding · viola P006 silenciosamente."*