---
asset_id: SOMA-XX-Method-v01
type: SOMA — Sistema Operativo Metodológico y Arquitectónico
layer: Method (universal · se actualiza con versiones de WORX)
version: v01
status: Activo
owner: Victor Heredia
sherpa_owner: Jay
fecha: 2026-06-03
intellbank: IB-XX-Maestro
subbank: IPI-XX-IP-Infraestructura/IPI-XX-SOMA
proposito: >
  Paquete de contexto metodológico. Universal — aplica a todo el modelo BMF.
  Cargarlo hace operativo a cualquier Sherpa en las reglas operativas del modelo WORX:
  naming, XDoc, disciplinas, anti-patterns y coherencia Vault-Room.
frecuencia_actualizacion: Media — sincronizado con versiones del MasterPlaybook WORX
fuente_de_verdad: WOI-EL-WORX-MasterPlaybook-v01.md
complementa_a: SOMA-XX-Core-v01.md
complementado_por: SOMA-[Engagement]-v01.md (uno por cliente/proyecto)
---

# SOMA-Method
## Metodología WORX · Paquete de contexto operativo

> *Este documento es la capa de reglas operativas de SOMA. Cárgalo junto con SOMA-Core para operar con conocimiento arquitectónico y metodológico completo. Si tienes uno sin el otro, tienes la mitad del sistema.*

---

## INSTRUCCIONES DE USO

**Qué es esto:** El paquete de contexto que te hace operativo en las reglas del modelo WORX — cómo se nombran los activos, cómo se estructura el trabajo, qué hábitos son obligatorios y qué errores destruyen el sistema.

**Cuándo cargarlo:** en cualquier room donde se vaya a crear activos, documentar trabajo, coordinar proyectos o hacer onboarding. Si solo vas a consultar arquitectura teórica, basta con SOMA-Core. Si vas a operar, necesitas este documento.

**Prueba de operatividad:** después de leer este documento debes poder responder sin dudar:
- ¿Cuál es el nombre correcto de este archivo? `PREFIJO-IB-Nombre-vNN`
- ¿Cuándo se abre un XDoc? Antes de empezar, no al terminar
- ¿Qué pasa si no está en el vault? No está en el Sherpa
- ¿Cuál es la carpeta espejo de este room? Su par exacto en el IntelliBank

---

## 1. WORX — QUÉ ES Y QUÉ ES UNA ORGSX

### Qué es WORX

WORX es la **metodología operativa** para implementar un WORX OS en una organización. No es software ni plataforma — es el modelo de trabajo que integra tres capas: Método, Infraestructura e Interfaz. Cuando los tres pilares operan juntos, la organización se transforma en una **OrgsX**.

WORX es agnóstico al tamaño, sector e industria. Lo que varía por cliente es el contenido — no la estructura. La estructura es siempre la misma.

### Qué es una OrgsX

Una **OrgsX** (Organización Hiperinteligente) es una organización donde la IA no es herramienta de asistencia individual sino una **capa operativa colectiva**. En una OrgsX:

- El conocimiento organizacional se acumula de forma estructurada — no se pierde cuando alguien sale
- Las dependencias entre personas y proyectos son explícitas y visibles, no implícitas y ocultas
- Los Sherpas operan en paralelo para cada persona, sin que el humano esté presente en cada tarea
- La documentación es producto de operar, no una tarea adicional
- El trabajo de bajo valor cognitivo (buscar, reportar, coordinar, documentar) lo hace el sistema

### La distinción fundamental

> *Una herramienta responde cuando se le pregunta. Una entidad opera aunque no se le pregunte.*

ChatGPT, Copilot, Gemini son herramientas — útiles, pero cada vez que se abren empiezan de cero. Un SherpaX en una OrgsX es una entidad: tiene nombre, memoria, gobernanza embebida, identidad. Opera en el contexto específico de su organización.

---

## 2. LOS 3 PILARES DE WORX

Los 3 pilares son necesarios y suficientes. Sin los tres, el sistema no funciona. Con los tres, la OrgsX opera.

---

### PILAR 1 — MÉTODO: las reglas del juego

El Método define **cómo va a operar el trabajo**. Sin Método, el sistema es poderoso pero caótico.

#### Gobernanza por rol

Cada persona tiene reglas embebidas en la memoria de su Sherpa: qué puede ver, qué puede decidir, en qué ámbito opera. Se captura en la Sesión de Definición (Día 1): ~30 min/persona. Se articula en conversación, no en formulario — la gente no siempre sabe sus límites hasta que se los pregunta. Una vez cargada, el Sherpa la aplica sin intervención humana.

#### XDoc como unidad canónica de trabajo

Todo trabajo en el sistema vive en un XDoc. Sin excepción. Ver Sección 4 para estructura completa.

#### Naming convention canónica

Todo activo tiene nombre estructurado: `PREFIJO-IB-Nombre-vNN.md`. Sin nombre canónico, el sistema no puede encontrar ni relacionar el activo. Ver Sección 3 para reglas completas.

---

### PILAR 2 — INFRAESTRUCTURA: donde vive la memoria

La infraestructura es el **hardware del sistema nervioso**. Sin ella, la inteligencia no tiene dónde vivir.

**Stack estándar WORX:**

| Componente | Tecnología | Rol |
|---|---|---|
| GenniuxBase (Brain OS MCP) | Node.js 20 + PostgreSQL 16 + pgvector · EC2 t3.small | Memoria del cliente — corre en su infraestructura |
| IntelliBanks app | Apache + PHP 8.x · EC2 t3.micro · Electron + Angular 15 | Sync cada 15 min · macOS + Windows |
| API LLM | Anthropic Claude con whitelist de IPs | Cómputo externo · memoria local |
| Conectores (MCP) | SharePoint, Jira, Slack, Gmail, ServiceNow, etc. | Integración con herramientas existentes |

**Principio de soberanía del dato:** la memoria queda en infraestructura del cliente. El cómputo usa API externa con whitelist. El cliente controla su conocimiento.

---

### PILAR 3 — INTERFAZ: quién activa la inteligencia

La interfaz son los **SherpaX**. Sin interfaz, la infraestructura existe pero nadie la activa.

**Componentes de la Interfaz:**

| Componente | Rol |
|---|---|
| **Sherpa personal** | Nombre propio · Brain Code progresivo · memoria individual · gobernanza por rol |
| **Corp Sherpa** | Interfaz del conocimiento organizacional compartido — responde preguntas que cruzan personas y áreas |
| **Torre de Control** | Vista agregada del estado de todos los proyectos — visible sin junta |

---

## 3. NAMING CONVENTION — LA REGLA CORE

### La regla invariante

```
Asset ID = Filename (sin extensión) = Wiki Link
```

Cuando estos tres son idénticos, el registry es autocongruente y portátil. Cuando divergen, el sistema se rompe.

```
Filename:   TP-EL-POSTA-Raiz-v01.md
Asset ID:   TP-EL-POSTA-Raiz-v01
Wiki Link:  [[TP-EL-POSTA-Raiz-v01]]
```

### Patrón de nombre

```
[PREFIJO]-[IB]-[Nombre-Descriptivo]-vNN.md
```

Ejemplos:
```
TP-EL-BMF-Architecture-v01.md
SOMA-XX-Core-v01.md
XD-PO-POSTA-Lab-Metodo-v01.md
BC-VH-VictorHeredia-v01.md
MePB-EL-CorpBrainOS-BehaviorCapture-v01.md
```

### Registro de prefijos activos

| Prefijo | Tipo de activo | Notas |
|---|---|---|
| `SOMA-` | Sistema Operativo Metodológico y Arquitectónico | Nuevo — este sistema |
| `TP-` | Transfer Pack | Contexto frozen · no editar después de publicar |
| `WOI-` | Work In Progress | Documento vivo · se actualiza |
| `MPB-` | MasterPlaybook | Libro o producto editorial completo |
| `MePB-` | MetaPlaybook | Procedimiento canónico de cualquier capa |
| `MiPB-` | MiniPlaybook | Guía corta operativa (1-5 páginas) |
| `PLB-` | Playbook | Playbook genérico de proceso |
| `XD-` | XDoc | Unidad canónica de trabajo activo |
| `BC-` | Brain Code | Criterio mental personal codificado |
| `BCV-` | Brain Code de Mentor | Criterio de mentor invocado |
| `HDC-` | Human Design Code | Perfil de Diseño Humano |
| `OUT-` | Entregable externo | Para cliente o uso público |
| `SIM-` | Simulación / demo | No producción |
| `PLAN-` | Plan interno | Roadmap o plan de trabajo |
| `ARQ-` | Arquitectura | Documento de diseño arquitectónico |
| `CP-` | Control Plane | Dashboard operativo |
| `IB-` | IntelliBank | El banco de inteligencia mismo |
| `SOP-` | Standard Operating Procedure | Protocolo operativo paso a paso |
| `GOB-` | Gobernanza | Documento de reglas de gobernanza |
| `MAP-` | Mapa | Visualización de arquitectura o activos |
| `DC-` | Documento Canónico | Referencia canónica de concepto |
| `PP-` | Paper | Documento de investigación o posicionamiento |
| `MIN-` | Minuta | Registro de sesión o reunión |
| `GLO-` | Glosario | Vocabulario canónico |
| `RFI-` | Request for Implementation | Orden de trabajo asíncrona con contexto completo — reemplaza la reunión de arranque. Ver Sección 8. |

### Versiones

| Versión | Significado |
|---|---|
| `v00` | Working — documento de trabajo, no gobernado |
| `v01` | Draft / Skeleton — en uso operativo, puede actualizarse |
| `v10` | Operational — ha pasado Build Exit gate |
| `v11` | Minor update desde v1.0 |
| `v20` | Major revision — cambio estructural o de alcance |

### Campo Descripción — reglas

- CamelCase o Title-Case con hyphens como separadores de palabras
- Debe comunicar la función del activo sin leer el documento
- Sin palabras genéricas: no "Document", "File", "Notes"
- Sin referencias temporales: no "March-Notes", "New-Version"

**Bueno:** `TP-EL-POSTA-Raiz-v01` · `SOMA-XX-Core-v01` · `XD-PO-Lab-Metodo-v01`
**Malo:** `Document1` · `NewPlaybook` · `VictorNotes-March` · `ThingToReview`

---

## 4. XDOC — LA UNIDAD CANÓNICA DE TRABAJO

El XDoc es el espacio donde el trabajo sucede — no la documentación de lo que ya terminó.

### Las 7 secciones del XDoc

**1. Cabecera**
- **Owner:** quien tiene el registro formal de propiedad del proyecto
- **Sponsor:** quien respalda y tiene autoridad sobre el proyecto
- **Runner:** quien tiene el balón ahora mismo — responsable de mover el proyecto en este momento

> *Owner ≠ Runner. Esta es la distinción más importante del XDoc. El Owner tiene el registro formal. El Runner tiene el balón. Esta separación elimina la ambigüedad que paraliza la mayoría de los proyectos.*

**2. Contexto**
Para qué existe este proyecto y qué resultado concreto se espera. Sin ambigüedad en el outcome.

**3. Estado**
- Salud: 🟢 (avanzando) / 🟡 (en riesgo) / 🔴 (bloqueado)
- Hito activo: qué milestone está en curso ahora
- Última decisión: qué se decidió más recientemente

**4. Dependencias**
Cada dependencia con tipo explícito y responsable:
- `INPUT` — necesita información o material de alguien
- `APROBACIÓN` — necesita sign-off para continuar
- `DECISIÓN` — necesita que alguien decida algo
- `DOC` — necesita un documento específico

**5. Protocolo**
SOP de referencia + diferencias entre lo que debe pasar y lo que pasa en la práctica.

**6. NEXTs**
- Máximo 7 acciones activas
- Cada una con: responsable + fecha
- No listas de tareas abiertas — solo acciones que se van a ejecutar

**7. Changelog**
Bitácora de cambios: qué cambió, qué se decidió, qué quedó pendiente. Esta es la memoria del proyecto — no la memoria de la persona.

### Cuándo abrir un XDoc

Antes de empezar a trabajar. No al final. Regla: **si hay Runner asignado y deadline, hay XDoc**. Sin XDoc, no hay proyecto visible para el sistema.

---

## 5. DISCIPLINAS FUNDAMENTALES

Las disciplinas son hábitos operativos que deben volverse automáticos. Sin disciplina, el sistema se degrada.

### D01 — Naming antes de guardar

Antes de guardar cualquier archivo: asignar nombre canónico con prefijo, IntelliBank y versión. **No hay activos sin nombre. No hay activos sin prefijo.** Un activo sin nombre canónico no existe para el sistema.

**Regla:** si no sabes qué prefijo usar, pregunta al Sherpa antes de guardar.

### D02 — El XDoc como primer paso

Antes de empezar cualquier proyecto, iniciativa o decisión: abrir un XDoc. El XDoc no es documentación del trabajo terminado — es el espacio donde el trabajo sucede.

**Regla:** si hay Runner y deadline, hay XDoc. Sin XDoc, no hay proyecto visible para el sistema.

### D03 — Dependencias explícitas

Cuando un trabajo necesita algo de otra persona, la dependencia se declara en el XDoc con tipo explícito y responsable. No se supone, no se infiere — se declara.

**Regla:** una dependencia no declarada es un bloqueo invisible. Los bloqueos invisibles son el costo más silencioso de cualquier organización.

### D04 — Changelog como hábito de cierre

Al terminar cada sesión de trabajo sobre un proyecto: actualizar el Changelog del XDoc. Qué cambió, qué se decidió, qué quedó pendiente. Esta es la memoria del proyecto — no la memoria del individuo.

**Regla:** si el Sherpa no sabe qué pasó en la última sesión, el Changelog no fue actualizado.

### D05 — Registry siempre actualizado

Cada activo nuevo que entra al vault se registra en el Control Plane del IntelliBank. El Registry es el CMDB del conocimiento — si un activo no está registrado, no existe para el sistema.

**Regla:** crear activo → registrar en Control Plane. Son dos pasos inseparables.

### D06 — Auto-documentación progresiva

El trabajo no se documenta al final — se documenta mientras ocurre. La documentación es producto de operar, no una tarea adicional. El Sherpa genera documentación como consecuencia de trabajar.

**Regla práctica:** si hay que hacer un esfuerzo especial para documentar algo, es señal de que el proceso de trabajo no está bien configurado todavía.

---

## 6. REGLA VAULT-ROOM — COHERENCIA DE ESPEJO

Esta es una regla fundacional derivada del caso Posta (2026-06-03).

### La regla

**Cada room en Cowork tiene su carpeta espejo en el vault. Todo activo generado en un room va en su carpeta correspondiente. Sin excepción.**

```
Cowork Project: POSTA
├── Room: POSTA-Cuenta          →  IB-PO-Posta/POSTA-Cuenta/
├── Room: POSTA-Caso            →  IB-PO-Posta/POSTA-Caso/
├── Room: POSTA-Lab-Metodo      →  IB-PO-Posta/POSTA-Lab-Metodo/
├── Room: POSTA-Lab-Infra       →  IB-PO-Posta/POSTA-Lab-Infra/
└── Room: POSTA-Lab-Interfaz    →  IB-PO-Posta/POSTA-Lab-Interfaz/

TP Raíz: IB-PO-Posta/TP-PO-POSTA-Raiz-v01.md  ← raíz del IB, no en subcarpeta
```

### El IntelliBank del cliente

Cada cliente tiene su IntelliBank en `IB-Clientes/`:
- Formato: `IB-[XX]-[Codename]/`
- El XX es el código del cliente (2 letras del codename)
- Ejemplo: `IB-PO-Posta/` para el cliente Posta

### El TP Raíz

El TP Raíz vive en la **raíz del IntelliBank del cliente** — no dentro de ninguna subcarpeta. Es el contexto base que alimenta todos los rooms. Formato: `TP-[XX]-[CODENAME]-Raiz-v01.md`.

**Regla:** primero el TP Raíz, luego los rooms. El TP es el contrato de contexto compartido. Rooms sin TP Raíz arrancan sin contexto común — el Sherpa de cada room reconstruye el mismo contexto de formas distintas. Las versiones divergen.

### Por qué importa

El Cowork project es la interfaz de trabajo. El IntelliBank es la memoria. Son dos sistemas distintos que deben estar perfectamente alineados. Si están desalineados, los activos se generan en la interfaz pero no persisten en la memoria — o persisten en el lugar equivocado.

---

## 7. ANTI-PATTERNS — LO QUE NO HACER

Los anti-patterns son los errores que degradan el sistema. Son más útiles que las reglas positivas — es más fácil evitar lo concreto.

### AP01 — Activos sin nombre canónico
**El error:** crear un archivo con nombre libre ("análisis posta.docx") sin prefijo BMF.
**Por qué ocurre:** la urgencia de guardar algo rápido.
**Consecuencia:** el sistema no puede clasificar, relacionar ni encontrar el activo.
**Regla:** si no hay tiempo para el nombre, hay tiempo para preguntarle al Sherpa cuál es. Eso toma 10 segundos.

### AP02 — XDoc creado al final del proyecto
**El error:** terminar un proyecto y entonces documentarlo en un XDoc.
**Por qué ocurre:** el XDoc se percibe como documentación, no como herramienta de trabajo.
**Consecuencia:** el Changelog está vacío, las dependencias no se rastrearon, el Runner cambió sin que nadie lo registrara.
**Regla:** el XDoc es el primer paso, no el último.

### AP03 — Dependencias implícitas
**El error:** asumir que "todos saben" quién depende de quién.
**Por qué ocurre:** en equipos pequeños las dependencias parecen obvias — hasta que alguien bloquea a dos personas en paralelo sin saberlo.
**Consecuencia:** bloqueos invisibles que solo se detectan en una reunión de status — que es exactamente lo que el sistema pretende eliminar.
**Regla:** si necesitas algo de alguien para avanzar, está declarado en las Dependencias del XDoc.

### AP04 — Usar el Sherpa como buscador genérico sin contexto
**El error:** preguntarle al Sherpa cosas que no están en su vault o contexto.
**Por qué ocurre:** el Sherpa parece omnisciente — si responde bien a preguntas generales, la tentación es usarlo para todo.
**Consecuencia:** el Sherpa responde desde entrenamiento genérico. Las respuestas son plausibles pero no confiables.
**Regla:** antes de hacer una pregunta crítica al Sherpa, verificar que la información relevante está en el vault.

### AP05 — No actualizar el Changelog
**El error:** trabajar en un proyecto durante semanas sin actualizar el Changelog del XDoc.
**Por qué ocurre:** el Changelog parece opcional cuando todo está en la cabeza del humano.
**Consecuencia:** en la siguiente sesión, ni el humano ni el Sherpa saben en qué estado quedó el proyecto.
**Regla:** al terminar cada bloque de trabajo, el Sherpa actualiza el Changelog.

### AP06 — Activos de un cliente en carpetas de metodología (y viceversa)
**El error:** guardar activos de cliente X en el banco de WORX o en el IB de otro cliente.
**Por qué ocurre:** el primer proyecto cliente se trabaja antes de tener la estructura del IB del cliente.
**Consecuencia:** activos dispersos · referencias rotas · Sherpas de rooms distintos que no se encuentran entre sí.
**Regla:** antes de generar el primer activo de un cliente, crear el IB del cliente y su estructura de rooms. El TP Raíz primero. *(Aprendizaje validado en Posta, 2026-06-03.)*

### AP07 — Rooms sin TP Raíz
**El error:** arrancar rooms de un proyecto sin haber creado el TP Raíz.
**Por qué ocurre:** la urgencia de empezar a trabajar.
**Consecuencia:** el Sherpa de cada room empieza sin contexto común. Las versiones del contexto divergen.
**Regla:** primero el TP Raíz, luego los rooms.

---

## 8. QUÉ PUEDE Y NO PUEDE HACER UN SHERPA EN ESTE MODELO

### Puede hacer (siempre)

- Crear, nombrar y organizar activos con naming canónico
- Abrir XDocs y mantener su estructura al día
- Registrar activos en el Control Plane
- Ejecutar MetaPlaybooks canonizados
- Generar documentación como consecuencia del trabajo
- Actualizar Changelogs al cierre de cada sesión
- Declarar dependencias explícitas en XDocs
- Cargar y aplicar TPs y SOMAx al inicio de rooms

### Puede hacer (con ratificación según nivel L1-L2)

- Modificar activos TP- (frozen por definición — requiere nueva versión)
- Ejecutar acciones con consecuencias externas (enviar, publicar, comprometer)
- Tomar decisiones que afecten a más de un área o persona

### No puede hacer (requiere escalación L3+ o CEO)

- Decisiones estratégicas que comprometan la organización
- Modificar reglas de gobernanza del sistema
- Crear nuevos prefijos en la naming convention
- Publicar activos como "Canonical" sin QA humano

### Regla de oro del Sherpa

> *Si no está en el vault, no está en el Sherpa. Si no está en el Sherpa, no actúes sobre ello como si fuera verdad.*

---

## 8. RFI — REQUEST FOR IMPLEMENTATION

### Qué es

El **RFI** es la herramienta que reemplaza la reunión de arranque. Es una orden de trabajo asíncrona y autocontenida: incluye objetivo, contexto, especificación, links al vault, criterios de aceptación y preguntas abiertas. El implementador recibe el RFI y puede empezar sin necesidad de una sesión previa.

> *La reunión es el último recurso, no el primer paso.*

### Cuándo usar un RFI

- Cuando alguien del equipo debe ejecutar algo específico (desarrollo, diseño, investigación, producción)
- Cuando la tarea requiere contexto del vault que el implementador puede no conocer
- Cuando los criterios de aceptación son definibles de antemano

### Flujo operativo

```
Victor → notas / captura estratégica
       ↓
Jay genera el RFI (links al vault incluidos)
       ↓
RFI asignado → implementador trabaja de forma autónoma
       ↓
¿Dudas?  No → ejecuta · Sí → aclara en el RFI (sección Preguntas Abiertas)
       ↓
Reunión de 15 min SOLO si las dudas no se resuelven por escrito
       ↓
Entregable → RFI cerrado → activo registrado en vault
```

### Convención de naming

```
RFI-[ENTIDAD]-[Proyecto]-[NombreDescriptivo]-vNN.md
RFI-XX-WORX-GobernanzaNoModificable-v01.md   ← aplica a todo el BMF (XX)
RFI-EL-LoopX-PuenteMCPOneRocket-v01.md       ← aplica solo a EL
```

Usar `XX` como entidad cuando el RFI aplica a todos los clientes / todo el modelo BMF.

### Definición completa y plantilla

→ [[DC-XX-RFI-TipoActivo-Definicion-v01]] — definición canónica del tipo  
→ [[MiPg-XX-RFI-Plantilla-v01]] — plantilla lista para copiar y usar

---

## 9. LLM-WIKI COMO CAPA DE CONSULTA OBLIGATORIA

### El problema que resuelve

El vault tiene miles de activos. Buscar en él es lento y costoso en tokens. El LLM-Wiki es la capa comprimida y verificada del vault — 56 páginas que destilan el conocimiento canónico del ecosistema. Consultarlo primero es más eficiente, más rápido y más confiable que ir directo al vault completo.

> *El Wiki no reemplaza al vault. Es la primera línea de consulta antes del vault.*

### El modelo de tres niveles

Antes de actuar sobre cualquier concepto del ecosistema, el Sherpa sigue esta secuencia:

```
NIVEL 1 — LLM-Wiki
  ¿Tiene el Wiki una página para este concepto?
  → SÍ: cargar la página Wiki como contexto base → continuar
  → NO: ir a Nivel 2

NIVEL 2 — Vault completo
  ¿Existe un documento canónico en IB-*?
  → SÍ: cargar el documento → considerar si debe ingresarse al Wiki
  → NO: ir a Nivel 3

NIVEL 3 — Producir IP nueva
  No existe en Wiki ni en vault → producir
  OBLIGATORIO: ejecutar Gate G0 (CONS-) antes de producir
  OBLIGATORIO: ingestar el nuevo activo al Wiki si es Clase C
```

### Cuándo la consulta Wiki es OBLIGATORIA (no opcional)

El Sherpa DEBE consultar el Wiki antes de actuar en estos tres momentos:

**1. Antes de proponer un framework, concepto o metodología nueva**
Si el concepto podría existir ya en el ecosistema, la consulta Wiki es el mecanismo que previene reinvención. Si `[[ConceptoPropuesto]]` ya tiene página Wiki → extender o supersede. Si no → producir con CONS-.

**2. Al activar un room o iniciar una sesión de trabajo**
Como parte de la Estación 4 del SOP-EL-WORX-RoomActivation, el Sherpa consulta el Wiki por los 2-3 conceptos centrales del room antes de ejecutar el Gate G0. El Wiki da el contexto comprimido; el vault completa lo que el Wiki no cubre.

**3. Al hacer onboarding de un colaborador nuevo**
El colaborador DEBE leer las páginas Wiki de su dominio antes de su primera sesión de trabajo. No como referencia opcional — como prerequisito. El Wiki es el manual de arranque del ecosistema.

### Cómo ejecutar una consulta Wiki

```
1. Identificar el concepto clave del tema (1-3 palabras)
2. Verificar si existe en Wiki/: ¿hay un archivo [[ConceptoClave]].md?
3. Si existe: Read del archivo → usar como contexto
4. Si no existe: buscar en vault → si tampoco → producir + flag para ingest
5. Al cerrar la sesión: si se identificó un gap → ejecutar wiki-ingest
```

### Nuevo anti-pattern: AP08 — Saltar el Wiki

**El error:** buscar en el vault completo o pedirle al Sherpa que explique un concepto del ecosistema sin haber consultado el Wiki primero.

**Por qué ocurre:** el Wiki no estaba integrado en ningún flujo obligatorio — era un activo opcional que pocos usaban.

**Consecuencia:** se consume contexto innecesario (tokens), se produce contenido inconsistente con el canon establecido, y los gaps del Wiki nunca se descubren porque nadie lo consulta.

**Regla:** Wiki primero. Siempre. Para conceptos del ecosistema BMF/WORX/SherpaX, el Wiki es la fuente de verdad operativa — no el vault crudo.

### Criterios de cuándo el Wiki está actualizado

→ Ver [[DC-XX-LLMWiki-DefinicionActualizacion-v01]] — 5 criterios medibles con score global.

---

## CHANGELOG

| Fecha | Versión | Cambio |
|---|---|---|
| 2026-06-03 | v01 | Documento creado. WORX completo: 3 pilares, naming convention, XDoc (7 secciones), disciplinas D01-D06, anti-patterns AP01-AP07, regla Vault-Room, tabla de autonomía del Sherpa. |
| 2026-06-03 | v01.1 | Agregado Sección 8: RFI — Request for Implementation. Prefijo `RFI-` registrado en tabla de naming. Canonizado en [[DC-XX-RFI-TipoActivo-Definicion-v01]]. |
| 2026-06-04 | v01.2 | Agregado Sección 9: LLM-Wiki como capa de consulta obligatoria. Modelo de 3 niveles (Wiki→Vault→IP nueva). 3 momentos obligatorios de consulta. Anti-pattern AP08. Referencia a [[DC-XX-LLMWiki-DefinicionActualizacion-v01]]. |

---

*SOMA-XX-Method-v01 · IB-XX-Maestro/IPI-XX-IP-Infraestructura/IPI-XX-SOMA/*
*Generado por Jay · EmpowerLabs Brain OS · 2026-06-03*
*Universal — aplica a todo el modelo BMF sin importar el engagement*
*Fuente de verdad: WOI-EL-WORX-MasterPlaybook-v01.md · Actualizar al versionar el MasterPlaybook*