--- type: SOP — Standard Operating Procedure asset_id: SOP-EL-WORX-RoomActivation-v01 version: v01 status: PROD owner: Victor Heredia / EmpowerLabs sherpa_owner: Jay (SherpaX maestro · ejecutor del protocolo) fecha_creacion: 2026-05-07 intellbank: IB-EL-EmpowerLabs subbank: PB-EL-Project-Bank / PB-WORX-Worx proposito: Protocolo universal de activación de room — 7 estaciones canónicas que TODO SherpaX ejecuta al inicio de cualquier conversación con proyecto/iniciativa canonical_de: P011 (Room Raíz) + P012 (Starter Pack Loading) — TP-EL-WORX-LabPraxis-v01 v1.6 caso_origen: CASO 014 + CASO 015 (originalmente 010+011 · renumerados 2026-05-07 EOD para alinear con banco v1.6) ratificado_por: Victor (2026-05-07 · sesión 009 LabPraxis) sistema_worx: K1 CONTEXT (Starter Pack como contexto canónico cargado) · K3 AGENCY (contrato Sherpa↔Owner) · K4 VAULT (Room Raíz como autoridad arquitectónica) output_canonico: CONS-[SLUG]-v01.md (heredado de SOP-BrainOSFirst) + reporte de estado del XP- al Owner aplica_a: Toda conversación SherpaX cuyo objeto sea un proyecto, iniciativa, frente de trabajo, decisión o producción que viva dentro de un room del ecosistema EmpowerLabs/BMF documentos_hermanos: - SOP-EL-WORX-BrainOSFirst-v01 (Estación 0 universal · ejecutado dentro de la Estación 4 de este SOP) - SOP-EL-WORX-DocBySherpa-v01 (operacionaliza P010 · captura delegada) - PROT-EL-WORX-Cohort-OperatingProtocols-v01 (consolida los 9 principios + 3 SOPs) - TP-EL-WORX-LabPraxis-v01 v1.6 (P011 · P012 formalizados · CASOS 014+015) tags: [SOP, WORX, RoomActivation, P011, P012, Sherpa-protocol, StarterPack, RoomRaiz] --- # SOP — Room Activation (Protocolo universal de activación de room) ## Instanciación operativa de los Principios P011 (Room Raíz) + P012 (Starter Pack Loading) --- ## I. PROPÓSITO Antes de operar cualquier room — antes de proponer, opinar, producir o avanzar cualquier sustancia — el SherpaX ejecuta las **7 estaciones canónicas** de activación. Sin ellas, la conversación arranca sin contexto canónico y rompe el compounding entre sesiones del mismo room. Este SOP **es** el ritual de Estación 0 expandido del SherpaX: - **P006 (Brain OS-First)** — Estación 0 era *consulta forzosa al BrainOS antes de proponer*. - **P011 + P012 (este SOP)** — la consulta no basta · hay que **cargar literalmente** el XP- y el SP- del Room Raíz aplicable antes de la consulta. --- ## II. CUÁNDO APLICA ### Aplica siempre que: - Se active un room (apertura literal o reanudación). - Se pivote a un proyecto/iniciativa nuevo en mid-conversation. - Se retome una conversación tras pausa (incluso si la "memoria" del SherpaX cree tener el contexto). ### Heurística de obligación: Si el SherpaX se pregunta *"¿debería cargar el XP+SP?"* — la respuesta es **siempre SÍ**. La duda es la señal. --- ## III. LAS 7 ESTACIONES CANÓNICAS ### Estación 1 · Identificar el Room Raíz aplicable (P011) Determinar de qué Room Raíz deriva el room que se está activando. Cada room tiene UN solo Room Raíz · el linaje está declarado en el frontmatter del room hijo (`room_parent` o equivalente) o se infiere por ubicación en el vault. **Ejemplos del ecosistema:** - Room hijo `PB-CASO0-HIORG/` → Room Raíz `PB-WORX-Worx/`. - Room hijo `PB-MONETIZACION-Estrategica/` → Room Raíz `IB-XX-Maestro/IPI-XX-IP-Infraestructura/`. - Room hijo del HIORG-Portfolio → Room Raíz `PB-MONETIZACION-Estrategica/`. **Si no hay Room Raíz declarado:** pausa · pregunta al Owner antes de avanzar. Crear room hijo sin Raíz declarado viola P011. --- ### Estación 2 · Cargar el XP- del Room Raíz (literal) Ejecutar `Read` sobre el XP- canónico del Room Raíz. **No inferir · no derivar · no recordar de sesiones previas · cargar literal con la herramienta de lectura.** **Por qué literal:** el XP- puede haberse actualizado entre sesiones · operar desde memoria es riesgo de drift. --- ### Estación 3 · Cargar el SP- del Room Raíz (literal) Ejecutar `Read` sobre el SP- canónico del Room Raíz. Mismas reglas que Estación 2. **Si el room hijo tiene su propio SP-** (caso típico para rooms operativos), cargar también el SP- del hijo. Heredancia: hijo extiende padre · no contradice. --- ### Estación 4 · Wiki Lookup + Ejecutar SOP-BrainOSFirst sobre el alcance del room hijo (P006) **4a — Consulta obligatoria al LLM-Wiki (nuevo paso · 2026-06-04)** Antes de ejecutar el Gate G0, identificar los 2-3 conceptos clave del room y verificar si tienen página en el LLM-Wiki. Este paso aplica el modelo de 3 niveles canonizado en `SOMA-XX-Method-v01 §9`: ``` Para cada concepto clave del room: → ¿Existe [[ConceptoClave]].md en IB-WikiX/Wiki/? SÍ: Read de la página → usar como contexto comprimido base NO: buscar en vault completo → si tampoco existe: flag para producción nueva ``` **Por qué antes del Gate G0:** el Wiki es la capa comprimida y verificada del vault. Consultarlo primero da al Sherpa el contexto más eficiente antes de la consulta formal al BrainOS. Si el Wiki cubre el concepto, el Gate G0 consume menos tokens y es más preciso. **Si el Wiki no cubre un concepto clave del room:** documentar el gap. Al cerrar el room, ese concepto es candidato para ingest (skill `wiki-ingest`). **4b — Ejecutar SOP-BrainOSFirst (Gate G0)** Con el contexto del Room Raíz cargado (Estaciones 2-3) y el Wiki consultado (Estación 4a), ejecutar el `SOP-EL-WORX-BrainOSFirst-v01` sobre el alcance específico del room hijo. Output: `CONS-[SLUG]-v01.md` con los 4 criterios PASS. --- ### Estación 5 · Verificar contexto BrainOS / Brain OS personal Buscar en el BrainOS técnico (Supabase + pgvector) y en el Brain OS personal del Owner si hay material no canonizado en el vault que sea relevante para el alcance del room. **Cuándo escalar:** si la búsqueda revela duda o falta de claridad operativa, pausar y pedir clarificación al Owner antes de avanzar (no asumir). --- ### Estación 6 · Si es necesario, actualizar el XP- antes de producir El XP- es un activo vivo · no estático. Si las Estaciones 4-5 revelan información que cambia el estado del room (decisiones tomadas · estado de componentes · responsables actualizados), actualizar el XP- ANTES de producir contenido nuevo. **Cómo:** ejecutar `Edit` sobre el XP- · actualizar campos relevantes · agregar entrada al changelog interno · declarar versionado si el cambio es Track A. **Por qué antes de producir:** si el XP- está desactualizado, el contenido producido se aliena del estado real. Mejor pausar 5 min para actualizar XP- que producir sobre base obsoleta. --- ### Estación 7 · Reportar al Owner el CONS- + estado del XP- Antes de cualquier producción sustantiva en la conversación, el SherpaX reporta al Owner: 1. El `CONS-` producido en Estación 4 (rutas canónicas + decisión). 2. El estado del XP- (cargado · actualizado si aplica · versionado declarado). 3. La decisión declarada: extender · refinar · crear nuevo · sin canónico previo. **El Owner valida en hand-off** y autoriza el avance a producción. Si hay desacuerdo, se corrige antes de continuar. --- ## IV. CRITERIOS PASS / FAIL DEL GATE El Sherpa solo avanza al siguiente paso del room si las 7 estaciones PASS: | # | Estación | PASS si | FAIL si | |---|---|---|---| | **E1** | Room Raíz identificado | Path canónico del Raíz declarado en frontmatter o inferido sin ambigüedad | Room hijo sin Raíz · ambigüedad | | **E2** | XP- del Raíz cargado | `Read` ejecutado sobre el XP- canónico | Operación desde memoria | | **E3** | SP- del Raíz cargado | `Read` ejecutado sobre el SP- canónico | Operación desde memoria | | **E4a** | Wiki Lookup ejecutado | 2-3 conceptos clave consultados · gaps documentados | Skip silencioso del Wiki | | **E4b** | SOP-BrainOSFirst ejecutado | `CONS-` producido con 4 criterios PASS | CONS- ausente o incompleto | | **E5** | BrainOS / Brain OS personal verificado | Búsqueda ejecutada y reportada | Skip silencioso | | **E6** | XP- actualizado si aplica | XP- vigente al estado real del room | XP- desactualizado y se procede | | **E7** | Reporte al Owner | CONS- + estado del XP- enviado al Owner antes de producir | Producción sin reporte | **Regla de oro:** un FAIL en cualquier E bloquea el avance. --- ## V. LO QUE EL SOP PROHÍBE EXPLÍCITAMENTE - Producir sin haber cargado el Starter Pack (Estaciones 2-3). - Asumir que "ya conoces el contexto" porque la sesión es continuación de una previa. - Usar inferencia o memoria del SherpaX como sustituto de carga literal. - Saltarse la Estación 4 cuando ya se cargó el XP+SP (la consulta forzosa al BrainOS sigue siendo obligatoria · son protocolos diferentes). - Avanzar a producción sin reporte al Owner (Estación 7). --- ## VI. CONEXIÓN CON STARTER PROMPTS (SP-) Todo SP- del ecosistema debe abrir invocando este SOP: ``` > Antes de operar este room, ejecuta SOP-EL-WORX-RoomActivation-v01 ejecutando > las 7 estaciones canónicas. Reporta el CONS- + estado del XP- al Owner antes > de cualquier producción. ``` **Patch a SP- existentes:** se ejecuta en una pasada de auditoría separada (no inline a cada SP- individualmente). --- ## VII. CONEXIÓN CON OTROS CANÓNICOS - **`SOP-EL-WORX-BrainOSFirst-v01`** — ejecutado dentro de la Estación 4 de este SOP. - **`SOP-EL-WORX-DocBySherpa-v01`** — siguiente protocolo en cadena (cuando se produce contenido). - **`TP-EL-WORX-LabPraxis-v01` v1.6** — P011 + P012 formales · CASOS 014 + 015 origen. - **`PROT-EL-WORX-Cohort-OperatingProtocols-v01`** — consolidación operativa. - **`MePB-EL-SX-MiSherpaIA-v01`** — sección "Arranque de sesión" se extiende con las 7 estaciones. --- ## VIII. CHANGELOG - **2026-06-04 · v01.1** — Estación 4 extendida con paso 4a obligatorio: Wiki Lookup antes del Gate G0. Canoniza el modelo de 3 niveles (Wiki→Vault→IP nueva) de SOMA-Method §9. Nueva fila E4a en criterios PASS/FAIL. Alineado con DC-XX-LLMWiki-DefinicionActualizacion-v01. - **2026-05-07 · v01** — Primer release PROD. Operacionaliza P011 + P012 conjuntamente con las 7 estaciones canónicas. Producido en sesión 009 LabPraxis · ratificado por Victor. --- *SOP-EL-WORX-RoomActivation-v01 · IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-WORX-Worx/ · 2026-05-07* *Origen: planeación operativa del primer cohort de inducción WORX (Caso 0 EL) · CASOS 014 + 015 LabPraxis · Principios P011 + P012.*