--- type: SOP — Standard Operating Procedure asset_id: SOP-EL-WORX-BrainOSFirst-v01 version: v01 status: PROD owner: Victor Heredia / EmpowerLabs sherpa_owner: Jacob (SherpaX maestro · ejecutor del protocolo) fecha_creacion: 2026-04-26 ultima_actualizacion: 2026-04-26 (v01.1 · prefijo CONS- canonizado en Registry v0.12) intellbank: IB-EL-EmpowerLabs subbank: PB-EL-Project-Bank / PB-WORX-Worx proposito: Protocolo universal Brain OS-First — Estación 0 obligatoria de toda conversación Sherpa con proyecto o iniciativa nueva canonical_de: P006 (TP-EL-WORX-LabPraxis-v01) — instanciación operativa universal del principio caso_origen: CASO 008 (CAS-EL-WORX-LabPraxis-BancoCasos-v01) — Agente sin consultar el vault antes de proponer ratificado_por: Victor (D-P-36 · 2026-04-26) sistema_worx: K4 VAULT (sustrato) · K3 AGENCY (interfaz) · K1 CONTEXT (output) · K5 GOVERNANCE (gobernanza del cumplimiento) output_canonico: CONS-[SLUG]-v01.md (Vault Consultation Pack) prefijo_canonizado: "CP-XX-IntelliBanks-Registry-v01 v0.12 — prefijo CONS- registrado oficialmente como TIPO BMF el 2026-04-26 (precedente: TOOL- en v0.2 · LAB/KB/AUD/QA/RES/PLAN en v0.6)" aplica_a: Toda conversación Sherpa cuyo objeto sea un proyecto, iniciativa, frente de trabajo, decisión o producción que genere activos en el ecosistema EmpowerLabs/BMF documentos_hermanos: - TP-EL-WORX-LabPraxis-v01.md (P006 · principio formal) - CAS-EL-WORX-LabPraxis-BancoCasos-v01.md (CASO 008 · origen) - MF-BMF-Publishing-v01.md v02 (Estación I0 + Gate G0 + PUB-04 · instanciación dentro de Publishing Factory) - feedback_brain_os_first.md (memoria persistente del Sherpa) tags: [SOP, WORX, BrainOS, Vault-First, P006, Estación-0, Sherpa-protocol, antídoto, governance] --- ## 📋 CHANGELOG | Fecha | Cambio | Por | |-------|--------|-----| | 2026-04-26 | Creación · v01 PROD · ratificado por Victor (D-P-36 · séptima pasada Día 100X) · operacionaliza P006 con alcance universal (Estación 0 de toda conversación Sherpa con proyecto/iniciativa) | @Jacob | | 2026-04-26 (EOD+6) | **v01 → v01.1 · canonización del prefijo `CONS-` en CP-XX-IntelliBanks-Registry-v01 v0.12.** Cambios: (1) frontmatter `prefijo_canonizado` agregado · (2) §IV nota de canonicidad oficial · (3) §IX Caso E agregado documentando segunda ejecución in-vivo (TP-HIORGS-ModeloNegocio-Pricing-v01 · capa monetaria) · (4) §X Conexión con Registry agregada. Detonante: pregunta Victor *"Por qué usas el prefijo CONS-"* + ratificación *"OK. Mantenemos a)"* — registro formal en Registry como prefijo BMF oficial junto a TOOL- (v0.2) y LAB/KB/AUD/QA/RES/PLAN (v0.6). Total Registry: 616 → 619 activos (+SOP-BrainOSFirst #617 · +CONS-PLAN-HIORGS-DemandGen #618 · +CONS-TP-HIORGS-ModeloNegocio-Pricing #619). | @Jacob | --- # SOP — Brain OS-First (Protocolo universal Estación 0) ## Instanciación operativa del Principio P006 del LabPraxis --- ## I. PROPÓSITO Antes de proponer, opinar, producir o avanzar cualquier sustancia en una conversación Sherpa con un proyecto o iniciativa, el agente ejecuta consulta forzosa al Brain OS (vault Reinventaverse) para verificar si el activo, concepto o canónico relacionado **ya existe**. Inventar primero, sin consultar, viola el principio P002 (Vault-First) extendido a la capa agente por P006 — y degrada la conversación al nivel de un chat sin memoria. Este SOP **es** la Estación 0 obligatoria. No es una recomendación, no es una buena práctica, no es opcional: es la condición de existencia de la colaboración con compounding. > *"Esto es lo que genera compounding collaboration. Sino estamos en una sesión individual en ChatGPT como hace 3 años."* — Victor Heredia · 2026-04-26 · CASO 008 --- ## II. CUÁNDO APLICA — Las 6 señales que activan obligatoriamente el SOP ### Señal 0 (universal · primaria · siempre aplica): **Al inicio de cualquier conversación nueva con un proyecto, iniciativa o frente de trabajo.** Si el turno abre o pivota a un proyecto/iniciativa, este SOP es Estación 0 antes de cualquier producción, opinión o propuesta. Aplica tanto a la apertura literal de un room (activación de un Starter Prompt) como al **descubrimiento mid-conversation** de que el turno ha entrado a alcance de un proyecto/iniciativa nuevo. ### Señales 1-5 (situacionales · refuerzan #0): 1. Mención de cualquier modelo, framework, sistema o metodología (Publishing Factory, MePB, MF-, MPB-, pipeline, etc.) 2. Propuesta propia del agente de "innovación", "capa nueva" o "arquitectura nueva" 3. Antes de crear cualquier activo nuevo de tipo: TP-, WOI-, MePB-, MPB-, MF-, CP-, SOP-, BC-, PLAN-, INV- 4. Cuando el Owner pregunta "¿está documentado?" / "¿existe en el vault?" / "¿buscaste?" 5. Antes de producir un entregable mayor (Plan Estratégico, Onboarding Doc, Battle Plan, Sales Playbook, etc.) **Heurística de duda:** si el agente se pregunta "¿debería buscar primero?", la respuesta es siempre SÍ. La duda es la señal. --- ## III. CÓMO SE EJECUTA — Las 4 acciones canónicas ### 1. Grep Buscar el nombre del concepto, modelo o término en el vault completo: ``` ruta: /Users/victorheredia/Documents/Intellibanks incluye: IB-WikiX/, IB-*, PB-*, todos los .md ``` Variantes a buscar: el nombre exacto, sinónimos, acrónimos, traducción ES↔EN cuando aplique. ### 2. Glob Buscar por patrones de naming canónico BMF que pudieran albergar el concepto: ``` **/MePB-*.md → meta-playbooks **/MF-*.md → metafactorías **/TP-EL-*.md → transfer packs EmpowerLabs **/MPB-*.md → master playbooks **/CP-*.md → control planes **/SOP-*.md → standard operating procedures **/SP-*.md → starter prompts **/CAS-*.md → casos LabPraxis ``` ### 3. LLM-Wiki Consultar el índice de conceptos: ``` ruta: /Users/victorheredia/Vault/Intellibanks/IB-WikiX/Wiki/ ``` La Wiki es la capa de navegación semántica del Brain OS — debe consultarse explícitamente, no derivarse de Grep. ### 4. Decisión declarada Con los hallazgos en mano, el agente declara explícitamente una de tres opciones: - **Extender** un canónico existente (cita ruta · justifica el delta) - **Refinar** un canónico existente (cita ruta · justifica el cambio) - **Crear nuevo** (justifica por qué los canónicos encontrados no aplican · justifica nombre + tipo + ubicación) **Si no hay hallazgos relevantes:** declarar explícitamente *"búsqueda ejecutada · sin canónico previo encontrado · creación nueva justificada"*. --- ## IV. OUTPUT CANÓNICO — `CONS-[SLUG]-v01.md` (Vault Consultation Pack) Cada paso del SOP genera un documento de evidencia auditable. ### Naming ``` CONS-[SLUG]-v01.md ``` donde `[SLUG]` es un identificador corto del proyecto/iniciativa/decisión que disparó la consulta. Ejemplos: - `CONS-PLAN-HIORGS-DemandGen-v01.md` (consulta previa al Plan Estratégico Demand Gen) - `CONS-TP-HIORGS-ModeloNegocio-Pricing-v01.md` (consulta previa al TP financiero del portafolio HIORG) - `CONS-MePB-CreacionContenidos-v01.md` (consulta previa al MePB Creación Contenidos) - `CONS-Onboarding-Anahi-v01.md` (consulta previa al Onboarding Doc de Anahí) > **Canonicidad del prefijo `CONS-`:** registrado oficialmente como TIPO BMF en `CP-XX-IntelliBanks-Registry-v01` v0.12 (2026-04-26 · §Convención de Naming Global + §Historial de Versiones). El prefijo significa **Vault CONSultation Pack** y es exclusivo de este SOP — todo `CONS-*.md` debe ser output de Brain OS-First. Precedentes de prefijos canonizados en el Registry: TOOL- (v0.2) · LAB/KB/AUD/QA/RES/PLAN (v0.6) · CONS- (v0.12). ### Ubicación Junto al activo que se está produciendo (mismo subbank). Si el SOP se ejecuta sin producir activo (consulta exploratoria del Owner), el CONS- vive en la minuta del día como sección embebida. ### Plantilla del CONS- ```markdown --- type: CONS — Vault Consultation Pack asset_id: CONS-[SLUG]-v01 version: v01 status: COMPLETED sop_origen: SOP-EL-WORX-BrainOSFirst-v01 disparado_por: [proyecto/iniciativa/turno] señal_activadora: [Señal 0 universal | Señal N situacional] fecha: AAAA-MM-DD sherpa: [nombre] owner: [@Owner] --- # Vault Consultation Pack — [Slug del proyecto/iniciativa] ## 1. ALCANCE DE LA CONSULTA [Qué proyecto/iniciativa/decisión activó este SOP. 2-3 líneas máximo.] ## 2. EJECUCIÓN ### 2.1 Grep [Términos buscados · resultados relevantes] ### 2.2 Glob [Patrones aplicados · resultados relevantes] ### 2.3 LLM-Wiki [Conceptos consultados · entradas encontradas] ## 3. HALLAZGOS [Lista de canónicos encontrados con ruta absoluta + brief extraído (no inventado) de cada uno.] ## 4. DECISIÓN DECLARADA [Extender | Refinar | Crear nuevo | Sin canónico previo] **Justificación:** [por qué esta decisión es la correcta dado lo encontrado] ## 5. SIGUIENTES PASOS [Qué se va a producir, dónde se ubicará, cómo se conecta con los canónicos encontrados.] ``` --- ## V. CRITERIOS PASS / FAIL DEL GATE El Sherpa solo avanza al siguiente paso del proyecto/iniciativa si los 4 criterios pasan: | # | Criterio | PASS si | FAIL si | |---|----------|---------|---------| | **C1** | Búsqueda ejecutada con las 4 acciones | Grep + Glob + Wiki + Decisión documentadas | Falta cualquiera de las 4 | | **C2** | Hallazgos auditables | Rutas absolutas + brief extraído (no inventado) de cada canónico relevante | Hallazgos genéricos sin ruta o briefs imaginados | | **C3** | Decisión explícita | "Extender / Refinar / Crear nuevo / Sin canónico previo" declarada con justificación | Decisión implícita o "nos lanzamos a producir" | | **C4** | CONS-[SLUG] producido | Documento existe en la ruta correcta o embebido en minuta | No hay evidencia escrita de la consulta | **Regla de oro:** un FAIL en cualquier C bloquea el avance. El Sherpa repite la consulta hasta que los 4 pasen, o eleva al Owner si la consulta encuentra ambigüedad real. --- ## VI. CONTRATO CON LOS STARTER PROMPTS (SP-) Todo SP- (Starter Prompt) que active un room/conversación con proyecto debe incluir, **antes** de la activación temática del room, una invocación explícita de este SOP: ``` > Antes de operar este room, ejecuta SOP-EL-WORX-BrainOSFirst-v01 sobre el > alcance del proyecto/iniciativa que estamos activando. Reporta el > CONS-[SLUG] al Owner antes de empezar producción. ``` **Patch a SP- existentes:** se ejecuta en una pasada de auditoría separada (no inline a cada SP- individualmente). Lista priorizada en el momento del patch: 1. SP-EL-SX-HIOrg-ContentRoom-v01 (carril activo HIORG Demand Gen) 2. SP-EL-WORX-MethodologyRoom-v01 (frecuencia alta · sesiones de diseño) 3. SP-EL-WORX-LabPraxis-v01 (este SOP nace ahí · cierra el loop) 4. Resto del catálogo SP- en orden de uso **SP- nuevos creados después de 2026-04-26:** deben incluir la invocación desde su versión v01 — no es retroactivo, es contractual hacia adelante. --- ## VII. CONEXIÓN CON LA METODOLOGÍA WORX | WORX Key | Rol del SOP en este Key | |---------|------------------------| | **K4 VAULT** | El SOP es la operacionalización del principio "la documentación coordina, no almacena" — fuerza al agente a usar el vault como fuente de verdad antes de inventar | | **K3 AGENCY** | Define el contrato Sherpa↔Owner: el Sherpa no propone ni produce sin haber consultado · el Owner puede exigir el CONS- como evidencia | | **K1 CONTEXT** | El CONS- producido **es** un artefacto de Context Transfer — alimenta P001 (todo proceso debe poder reanudarse sin depender de quien lo inició) | | **K5 GOVERNANCE** | Los CONS- producidos quedan auditables · permiten al LabPraxis trackear cuántas conversaciones pasaron por G0 vs cuántas no · base de evidencia para gobernanza emergente (P004) | | **K6 CADENCE** | El SOP es la primera estación rítmica de cualquier conversación Sherpa · establece el "compás 0" antes de entrar al ritmo del room | --- ## VIII. LO QUE EL SOP PROHÍBE EXPLÍCITAMENTE - Decir "no tengo documentado X, dame brief de 10 líneas" sin haber buscado primero - Proponer "innovación" como si no existiera precedente sin verificar - Producir Plan Estratégico re-describiendo modelos en lugar de referenciar canónicos - Avanzar a producción cuando un C1-C4 está en FAIL - Consultar parcialmente (solo Grep, sin Glob ni Wiki) y declarar consulta completa - Inventar briefs cuando los canónicos existen pero no fueron leídos a profundidad - Saltarse el SOP "porque la conversación es informal" — el alcance del proyecto/iniciativa define la obligación, no el tono --- ## IX. CASOS DE USO ILUSTRATIVOS ### Caso A — Apertura de room nuevo Owner activa `SP-EL-WORX-MethodologyRoom-v01` con la pregunta *"¿cómo diseñamos el ritmo operativo de EL?"*. **SOP-Brain-OS-First ejecuta:** Grep "ritmo operativo" · Glob `**/MePB-*Cadence*.md` + `**/SOP-*Ritmo*.md` · consulta Wiki sobre K6 CADENCE. **Output:** `CONS-MethodologyRoom-RitmoOperativo-v01.md` · decisión declarada · luego se entra a la conversación. ### Caso B — Pivot mid-conversation Conversación arranca técnica sobre un bug. Mid-turn, Owner dice *"esto debería ser un sistema..."* — pivot a iniciativa nueva. **SOP-Brain-OS-First detecta Señal 1 + 0:** ejecuta consulta antes de proponer arquitectura. Pausa la respuesta técnica, busca primero, retoma con CONS-. ### Caso C — Producción de entregable mayor (caso típico hoy) Owner pide *"genera el Plan Estratégico Demand Gen"*. **SOP-Brain-OS-First detecta Señal 5 + 0:** ejecuta `CONS-PLAN-HIORGS-DemandGen-v01.md` antes de redactar una palabra del PLAN-. Identifica canónicos a citar (no a re-describir). ### Caso D — Auto-aplicación (validación in-vivo del SOP · 2026-04-26) Sherpa intenta crear `BC-EL-BrainOSFirst-v01`. Aplica G0 a sí mismo · descubre que `BC-EL-BrainCodes/` contiene Cognitive Stacks de figuras (no protocolos operativos) · **evita crear el activo en tipo incorrecto** · presenta 3 opciones al Owner · recibe Opción A · resultado: P006 en TP-LabPraxis (no BC-). **Lección:** el SOP funciona también cuando el agente se aplica a sí mismo. El gate captura errores de tipo, no solo de contenido. ### Caso E — Segunda ejecución in-vivo · capa monetaria (2026-04-26 · novena/décima pasada Día 100X) Owner pide *"genera el Transfer Pack del Modelo de Negocio + Pricing del portafolio HiORG"*. **SOP-Brain-OS-First detecta Señal 5 + 0:** ejecuta `CONS-TP-HIORGS-ModeloNegocio-Pricing-v01.md` antes de redactar el TP. Gate G0 PASS 4/4 con C2 PASS PARCIAL (40-45% del scope requería IP nueva — modelo financiero, unit economics, P&L, ratios, riesgos). Decisión declarada: **híbrido REFERENCIAR + GENERAR IP NUEVA EN ÁREAS GAP**, con distribución 35% canonizado / 35% extendido / 30% IP nueva. TP producido en 13 secciones honrando D-P-15, D-P-21, D-P-22, D-P-24 y D-P-36. **Lección:** el SOP escala más allá de PLANs hacia capas de IP nueva (financiera, monetaria, estratégica) sin perder el sustrato canónico. El CONS- híbrido (referencia + IP nueva con áreas gap explícitas) es un patrón replicable cuando el alcance del entregable supera lo canonizado. ### Caso F — Canonización del propio prefijo (2026-04-26 EOD+6 · undécima pasada) Owner pregunta *"Por qué usas el prefijo CONS-"* tras dos instancias en producción. Sherpa explica provenance, alternativas evaluadas (OUT- / AUD- / CONS-) y status (canonizado solo en SOP). Owner ratifica *"OK. Mantenemos a)"*. Sherpa registra formalmente el prefijo en `CP-XX-IntelliBanks-Registry-v01` v0.12 (Convención de Naming Global + Historial + Panel de Control + Registro de Activos #617-619). **Lección:** los prefijos BMF se canonizan dos veces — primero en su SOP-origen (donde nacen funcionalmente) y después en el Registry (donde se vuelven oficiales del ecosistema). El segundo paso requiere tracción operativa demostrada: ≥2 instancias en producción + pregunta del Owner sobre la lógica + ratificación explícita. Patrón replicable para futuros prefijos emergentes. --- ## X. GOBERNANZA Y EVOLUCIÓN ### Owner del SOP @Victor (Owner) · @Jacob (Sherpa ejecutor) ### Cómo se reporta cumplimiento Cada CONS- producido queda en el vault. La cadencia de auditoría del LabPraxis (cierre de semana) puede contar: - Cuántos proyectos/iniciativas activos arrancaron con CONS- - Cuántos no (gaps de cumplimiento) - Cuántas decisiones "Extender" vs "Crear nuevo" — métrica de re-uso del Brain OS ### Cuándo se actualiza este SOP - Aparición de nuevo tipo de activo BMF que deba listarse en la Sección II Glob - Aprendizaje del LabPraxis (nuevo CASO) que extienda el alcance - Cambio en la arquitectura del vault que afecte rutas de búsqueda ### Conexión con otros canónicos - **TP-EL-WORX-LabPraxis-v01** (P006) — el principio que este SOP operacionaliza - **CAS-EL-WORX-LabPraxis-BancoCasos-v01** (CASO 008) — el caso que originó el principio - **MF-BMF-Publishing-v01 v02** — instancia de este SOP dentro del pipeline editorial (con I0 + G0 + PUB-04) - **CP-XX-IntelliBanks-Registry-v01** v0.12 — registro oficial del prefijo `CONS-` como TIPO BMF + tracking de cuántos CONS- viven en el ecosistema - **feedback_brain_os_first.md** — memoria persistente del Sherpa cross-session - **feedback_cons_prefix.md** — memoria persistente del prefijo y sus reglas de aplicación --- ## XI. ESTADO **Status:** v01 PROD · ratificado por Victor el 2026-04-26 (D-P-36 · séptima pasada Día 100X) **Validación in-vivo:** caso D documentado en §IX — el SOP capturó error de tipo en su primera aplicación operativa antes incluso de existir como SOP formal. --- *SOP-EL-WORX-BrainOSFirst-v01 · IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-WORX-Worx/ · 2026-04-26* *Origen: experimento HIORG Día 100X · CASO 008 LabPraxis · Principio P006 · Codificación universal del antídoto Brain OS-First.*