## Asset Header - **Asset ID:** CP-EL-R100X-Strategic-Path-SherpaIA-v01 - **Version:** v01 - **Status:** Draft - **Owner:** Victor Heredia - **IntellBank:** IB-EL-EmpowerLabs - **Tipo:** CP — Control Plane - **Propósito:** Strategic Path — Tu Sherpa IA: Implementación Personal + Productización BMF - **Última actualización:** 2026-04-11 --- # Strategic Path — Tu Sherpa IA: Implementación Personal + Productización BMF ## Re100X-Strategic-Path-SherpaIA-v01 --- --- ## 1. El problema de diseño Victor quiere dos cosas simultáneamente: **Track A — Personal:** Construir su propio Tu Sherpa IA completo (incluyendo BrainOS desde cero) como sistema operativo personal y caso de éxito documentable. **Track B — Producto:** Crear la versión productizada bajo el modelo Big MetaFactory para clientes reales, con Factory formal, governance, QA gates y capacidad de escala. La tentación natural es tratarlos como dos proyectos separados. **Eso sería un error.** Si se separan, se duplica trabajo, se genera drift entre la instancia personal y el template de producto, y se pierde la ventaja más poderosa: que el proceso de construir el Sherpa IA de Victor *sea* el proceso de validar la Factory. --- ## 2. La solución: Dogfooding Architecture El principio es simple: **Victor es el primer cliente de su propia Factory.** ``` ┌─────────────────────────────────────────────┐ │ BMF — BIG METAFACTORY │ │ │ │ L2: MF-DOBLE-IA (MetaFactory) │ │ Define: qué es un Sherpa IA, cómo se │ │ construye, qué templates existen, │ │ qué QA debe pasar │ │ │ │ │ ├── L3: F-SHA-VICTOR │ │ │ (Factory Instance — Victor) │ │ │ INPUT: Victor's DNA + CAM + OB │ │ │ OUTPUT: El Sherpa IA de Victor │ │ │ STATUS: ★ PRIMERA EJECUCIÓN ★ │ │ │ │ │ ├── L3: F-DIA-CLIENT-TEMPLATE │ │ │ (Factory Template — Clientes) │ │ │ Generado DESDE la experiencia │ │ │ de F-SHA-VICTOR │ │ │ │ │ └── L4: Production Assets │ │ ├── SHA-VICTOR-Prompt-v01 │ │ ├── SHA-VICTOR-Memoria-v01 │ │ ├── SHA-VICTOR-Manual-v01 │ │ └── SHA-VICTOR-Ritual-v01 │ └─────────────────────────────────────────────┘ ``` Cada activo que se produce para Victor genera dos outputs: 1. **La instancia personal** (el Sherpa IA de Victor, operativo) 2. **El template extraído** (la versión parametrizable para clientes) Esto es exactamente lo que el BMF Kernel prescribe en §3.2: "L3 produces L4 assets" y §7.1: "New MetaFactories require explicit entry criteria to prevent sprawl." --- ## 3. Posición dentro del BMF ### Nuevo prefijo de naming Siguiendo la convención de [[BMF-Registry-Activos-v01]]: ``` Prefijos existentes: BMF- → Big MetaFactory (L0-L6) MPB- → MetaPlaybook MFB- → MetaFactory Builder VPF- → Victor Publishing Factory Nuevos prefijos: MF-SHA- → MetaFactory Sherpa IA (L2 — Domain MetaFactory) F-DIA- → Factory Sherpa IA instances (L3 — Operations) DIA- → Production assets del Sherpa IA (L4 — Outputs) ``` ### Mapeo al Builder Hierarchy | Capa BMF | Entidad Tu Sherpa IA | Governing Document | |----------|---------------------|-------------------| | L0 | No modifica el Kernel. Hereda invariantes. | [[BMF-MPB-Kernel-v01]] | | L2 | **MF-DIA — MetaFactory Sherpa IA** | [[SHA-MetaFactory-v01]] (por crear) | | L3 | **F-SHA-VICTOR** (instancia Victor) | Factory Config (por crear) | | L3 | **F-DIA-CLIENT-TEMPLATE** (template clientes) | Factory Template (por crear) | | L4 | Instancias de Sherpa IA por cliente | Prompt + Memoria + Manual + Ritual | | L6 | Governance heredada del MEL Stage 1 | [[BMF-MEL-MasteryEnforcementLayer-v11]] | ### Relación con activos Re100X existentes Los activos definidos en el Transfer Pack ([[Re100X-TP-SherpaIA-v01]]) se mapean así: | Activo Re100X (Transfer Pack) | Función en BMF | Capa | |-------------------------------|---------------|------| | Re100X-Doble-Codigo-IA-Arquitectura-v01 | Se convierte en **SHA-MetaFactory-v01** — la arquitectura de la MetaFactory | L2 | | Re100X-Doble-IA-Blueprint-v01 | Se integra en el MetaFactory como **definición de producto** | L2 | | Re100X-Doble-IA-Memoria-v01 | **Template de captura** a nivel MetaFactory + **Instancia** a nivel Factory | L2 (template) + L4 (instancia) | | Re100X-Doble-IA-Manual-v01 | **Policy del Sherpa IA** a nivel MetaFactory + **Instancia calibrada** por cliente | L2 (template) + L4 (instancia) | | Re100X-Doble-IA-Prompt-Portable-v01 | **Template de Prompt** + **Instancia del Prompt** | L2 (template) + L4 (instancia) | | Re100X-Doble-IA-Ritual-v01 | **Protocolo de mantenimiento** a nivel MetaFactory | L2 | **Regla de naming dual:** Los activos conservan su ID Re100X para el ecosistema comercial, y reciben un alias BMF para el sistema de producción. El Registry BMF trackea ambos IDs. --- ## 4. Los dos tracks en paralelo — Secuencia integrada ### Filosofía de ejecución No son dos caminos separados que se ejecutan al mismo tiempo. Es **un solo camino con dos outputs por paso.** Cada acción produce resultado personal (Track A) y template productizable (Track B) simultáneamente. ``` TRACK A (Personal) STEP TRACK B (Producto) ───────────────── ────────────────────── ───────────────────── Victor tiene Open PASO 0: INFRAESTRUCTURA Guía de setup OB Brain operativo Setup BrainOS para clientes validada Victor DNA + PASO 1: METAFACTORY SHA-MetaFactory-v01 CAM + OB = specs Arquitectura del sistema Template de arquitectura Victor recibe su PASO 2: FACTORY RUN F-DIA-CLIENT-TEMPLATE Doble operativo Primera ejecución Pipeline documentado Victor usa su PASO 3: CALIBRACIÓN Protocolo de calibración Doble 2 semanas Testing + ajustes para clientes Victor documenta PASO 4: CASO DE ÉXITO Material de marketing before/after Documentación + proof of concept ``` --- ## 5. Secuencia detallada de ejecución ### PASO 0 — Infraestructura BrainOS (Día 1) **Objetivo:** BrainOS de Victor operativo y conectado. **Acciones concretas:** ``` 0.1 Crear proyecto Supabase "BrainOS" → Guardar Project ref + Database password en credential tracker 0.2 Configurar base de datos → Ejecutar 4 SQL queries (pgvector, thoughts table, match_thoughts, RLS) → Ejecutar GRANT de permisos para service_role 0.3 Guardar connection details → Project URL + Secret key en credential tracker 0.4 Crear cuenta OpenRouter + API key → $5 en créditos 0.5 Generar MCP Access Key → openssl rand -hex 32 0.6 Desplegar MCP Server → supabase init → supabase link → secrets set → deploy Edge Function 0.7 Conectar a Claude Desktop + ChatGPT → Claude: Settings → Connectors → Add custom connector → ChatGPT: Developer Mode → Apps & Connectors → Create 0.8 Test de validación → Capturar 3 thoughts de prueba → Buscar semánticamente → Verificar en Supabase Table Editor ``` **Output Track A:** BrainOS de Victor operativo. **Output Track B:** Guía de setup validada paso a paso con screenshots y troubleshooting real. **Tiempo estimado:** 45-60 minutos (incluye troubleshooting). --- ### PASO 1 — MetaFactory Sherpa IA: Arquitectura del Sistema (Días 2-5) **Objetivo:** Crear SHA-MetaFactory-v01 — el documento que define qué es un Sherpa IA, cómo se construye y qué debe contener. **Este paso integra y reemplaza los activos Re100X 28 y 29** (Arquitectura Tu Código IA + Blueprint del Sherpa IA) en un solo documento de nivel MetaFactory. **Contenido del SHA-MetaFactory-v01:** ``` SECCIÓN 1 — Definición de producto ├── Qué es Tu Sherpa IA (del Transfer Pack — lenguaje canónico) ├── La distinción Tu Código IA vs Tu Sherpa IA ├── Los 3 niveles de producto (L1 Portable / L2 BrainOS / L3 Soberano) └── Casos de uso operativos SECCIÓN 2 — Arquitectura técnica (4 capas) ├── Capa 0: Identidad (Personal DNA + CAM + Código Estratégico) │ → Schema: qué campos capturar, formato, protocolo de extracción │ → Basado en PERSONAL_DNA.md del Clone Copilot + extensiones CAM/CE │ ├── Capa 1: Memoria Persistente (BrainOS) │ → Stack: Supabase + OpenRouter + MCP │ → Schema extendido de tabla thoughts con metadata Re100X │ → 4 herramientas MCP (capture, search, list, stats) │ → Protocolo de Memory Migration y Second Brain Migration │ ├── Capa 2: Operación (reglas de comportamiento) │ → Routing rules (cuándo actúa solo, cuándo escala al humano) │ → Niveles de autonomía (0-4) │ → Modos: consultor vs ejecutor │ → Basado en SKILL_METAPLAYBOOK_OPS.md + SKILL_QA_VALIDATOR.md │ └── Capa 3: Proactividad (Heartbeat — solo L3 Soberano) → Ciclos programados de revisión → Alertas de drift y caducidad SECCIÓN 3 — Pipeline de producción (Factory) ├── Input: Cuestionario de captura + CAM + CE (opcionales) ├── Proceso: Síntesis → Configuración OB → Generación de prompt → Calibración ├── Output: 4 activos por cliente (Prompt + Memoria + Manual + Ritual) ├── QA Gate: 5 criterios de validación PASS/FAIL └── Tiempo estimado por cliente SECCIÓN 4 — Templates ├── Template de Personal DNA (parametrizable) ├── Template de Prompt Portable (L1, L2, L3) ├── Template de Manual de Actuación ├── Template de Ritual de Actualización └── Template de metadata Re100X para thoughts SECCIÓN 5 — Governance ├── Naming convention (DIA-[CLIENT]-[Asset]-vNN) ├── QA checklist por nivel (L1/L2/L3) ├── Protocolo de drift check └── Versionado de instancias ``` **Output Track A:** La especificación técnica completa del Sherpa IA de Victor — qué capturar, cómo estructurar su BrainOS, qué reglas de operación aplicar. **Output Track B:** El MetaFactory document que gobierna la producción de cualquier Sherpa IA para cualquier cliente. --- ### PASO 2 — Factory Run: Primera ejecución con Victor (Días 6-10) **Objetivo:** Ejecutar la Factory por primera vez usando a Victor como cliente. Producir los 4 activos de su Sherpa IA personal. **Secuencia de la Factory:** ``` 2.1 CAPTURA — Ejecutar cuestionario de Personal DNA sobre Victor → Usando el template definido en MF-DIA → Inputs existentes: PERSONAL_DNA.md + CAM de Victor + perfil HD/GK → Sesión de captura de estilo: muestras de comunicación, decisiones, priorización 2.2 SÍNTESIS — Generar los 4 activos de instancia ┌── SHA-VICTOR-Prompt-Portable-v01 │ Versiones L1, L2 y L3 del prompt de Victor │ L2 incluye instrucciones de conexión BrainOS MCP │ ├── SHA-VICTOR-Memoria-v01 │ Memoria inicial cargada al BrainOS │ Memory Migration ejecutada (traer lo que las IAs ya saben de Victor) │ ChatGPT Conversation Import (si Victor quiere importar historial) │ 20-50 thoughts iniciales capturados │ ├── SHA-VICTOR-Manual-v01 │ Reglas de actuación del Sherpa IA de Victor │ Niveles de autonomía calibrados para Victor │ Routing rules personalizadas │ └── SHA-VICTOR-Ritual-v01 Weekly Review adaptado para Victor Quick Capture Templates para el ecosistema Re100X Drift check mensual 2.3 QA GATE — Validar los 4 activos contra checklist → ¿El prompt carga correctamente en Claude Desktop? PASS/FAIL → ¿El prompt carga correctamente en ChatGPT? PASS/FAIL → ¿La búsqueda semántica recupera thoughts relevantes? PASS/FAIL → ¿El Sherpa IA responde en la voz y criterio de Victor? PASS/FAIL → ¿El Manual cubre los 5 escenarios de uso core? PASS/FAIL ``` **Output Track A:** El Sherpa IA de Victor, completamente operativo en L2 (BrainOS). **Output Track B:** El pipeline de producción validado con un caso real. Cada paso documentado como template replicable. --- ### PASO 3 — Calibración: Testing real (Días 11-25) **Objetivo:** Victor usa su Sherpa IA en operación real durante 2 semanas. Se documentan ajustes. **Protocolo de calibración:** ``` SEMANA 1 — Uso intensivo ├── Usar el Sherpa IA para 3+ tareas diarias reales │ (creación de contenido, decisiones, consultas estratégicas) ├── Capturar 5+ thoughts diarios al BrainOS ├── Documentar: ¿dónde respondió bien? ¿Dónde falló? ├── Ejecutar Weekly Review de OB al final de la semana └── Ajustar routing rules y niveles de autonomía según resultados SEMANA 2 — Refinamiento ├── Probar edge cases: solicitudes fuera de alcance, ambigüedades ├── Verificar que la memoria acumulada mejora las respuestas ├── Ejecutar drift check: ¿el Sherpa IA sigue alineado con la identidad? ├── Documentar métricas: tiempo ahorrado, calidad percibida, contexto retenido └── Producir versión v02 de los 4 activos con ajustes ``` **Output Track A:** Doble de Victor calibrado y en v02. Memoria con 50-100+ thoughts. **Output Track B:** Protocolo de calibración documentado + métricas reales para el caso de estudio. --- ### PASO 4 — Caso de éxito + Templates finales (Días 26-30) **Objetivo:** Documentar el caso de éxito de Victor y finalizar los templates para clientes. ``` 4.1 CASO DE ÉXITO ├── Before/After documentado con métricas reales ├── 3-5 ejemplos concretos de uso con resultados ├── Testimonio de Victor como primer usuario └── Screenshots / demos del Sherpa IA en acción 4.2 TEMPLATES FINALES PARA CLIENTES ├── Template de Personal DNA (parametrizable, campos en blanco) ├── Template de Prompt Portable L1 (copy-paste ready) ├── Template de Prompt L2 (con instrucciones BrainOS) ├── Template de Manual de Actuación (configurable) ├── Template de Ritual de Actualización (adaptable) ├── Cuestionario de onboarding (versión cliente) └── Guía de setup BrainOS (versión cliente, simplificada) 4.3 REGISTRO BMF → Registrar MF-DIA y F-SHA-VICTOR en BMF-Registry-Activos → Registrar los templates en el Control Plane → Verificar compliance con MEL Stage 1 ``` **Output Track A:** Victor tiene su Sherpa IA como herramienta diaria + caso de éxito publicable. **Output Track B:** Factory lista para recibir al primer cliente externo. --- ## 6. Activos a registrar en el BMF Registry Al completar este Strategic Path, el BMF-Registry-Activos deberá incluir: | # | Asset ID | Tipo | Capa BMF | Status target | |---|----------|------|----------|---------------| | 16 | SHA-MetaFactory-v01 | MPB | L2 | Operational | | 17 | F-SHA-VICTOR-Config-v01 | CONFIG | L3 | Operational | | 18 | F-DIA-CLIENT-TEMPLATE-v01 | TEMPLATE | L3 | Operational | | 19 | SHA-VICTOR-Prompt-v02 | ASSET | L4 | Production | | 20 | SHA-VICTOR-Memoria-v02 | ASSET | L4 | Production | | 21 | SHA-VICTOR-Manual-v02 | ASSET | L4 | Production | | 22 | SHA-VICTOR-Ritual-v02 | ASSET | L4 | Production | | 23 | DIA-CaseStudy-Victor-v01 | MARKETING | L4 | Production | Esto llevaría el Registry de 15 a 23 activos, y por primera vez poblaría L3 y L4 con activos operativos — resolviendo la observación del Assessment del Second Brain: "Blueprint for a factory that hasn't produced its first widget yet." --- ## 7. Invariantes BMF que aplican Del Kernel [[BMF-MPB-Kernel-v01]] §4.1: | Invariante | Cómo se cumple en Tu Sherpa IA | |-----------|-------------------------------| | "Every factory must have a named pipeline with stations" | Pipeline: Captura → Síntesis → QA Gate → Calibración → Activación | | "Every run must be auditable (Control Plane)" | Cada Factory Run se registra con input/output/decisiones/fecha | | "QA must be able to fail (PASS/FAIL)" | QA Gate con 5 criterios binarios explícitos | | "Authority discipline is mandatory for claims" | El Sherpa IA no inventa — opera desde memoria verificable | | "WIP limits are enforced" | Max 1 Factory Run simultáneo en F-SHA-VICTOR | Del Builder Hierarchy [[BMF-BuilderHierarchy-CanonicalMap-v00]] §3: | Regla | Cumplimiento | |-------|-------------| | "MetaFactory Builder never touches domains" | MF-DIA define arquitectura, no ejecuta producción | | "Factory Builder never defines domain laws" | F-SHA-VICTOR ejecuta el pipeline, no cambia las reglas | | "Any overlap is a design error" | Separación clara L2 (qué) / L3 (cómo) / L4 (outputs) | --- ## 8. Calendario propuesto | Bloque | Días | Entregables clave | |--------|------|-------------------| | **PASO 0 — Infraestructura** | Día 1 | BrainOS operativo + conectado a Claude Desktop y ChatGPT | | **PASO 1 — MetaFactory** | Días 2-5 | SHA-MetaFactory-v01 completo (arquitectura + templates + governance) | | **PASO 2 — Factory Run** | Días 6-10 | 4 activos del Sherpa IA de Victor v01 + QA Gate pasado | | **PASO 3 — Calibración** | Días 11-25 | 2 semanas de uso real + 4 activos v02 + métricas documentadas | | **PASO 4 — Cierre** | Días 26-30 | Caso de éxito + Templates finales + Registry BMF actualizado | **Total: 30 días para tener ambos tracks entregados.** El Sherpa IA de Victor operativo desde el día 10. La Factory productizada desde el día 30. --- ## 9. Primer paso inmediato El PASO 0 (infraestructura BrainOS) se puede ejecutar ahora mismo en esta sesión. No tiene dependencias. Son ~45 minutos de setup guiado. **¿Qué necesitas para arrancar?** 1. Una cuenta de Supabase (o crearla ahora — signup con GitHub es el más rápido) 2. Una cuenta de OpenRouter (o crearla ahora) 3. Terminal abierta (Mac Terminal o PowerShell) 4. Claude Desktop y/o ChatGPT para conectar al final Una vez que el BrainOS esté operativo, podemos ejecutar la Memory Migration (traer a tu BrainOS todo lo que tus IAs ya saben de ti) y arrancar inmediatamente con el PASO 1 — la MetaFactory. --- ## 10. Historial de versiones | Versión | Fecha | Cambio | |---------|-------|--------| | v1.0 | 2026-03-20 | Creación inicial. Strategic Path dual (personal + productizado). 4 pasos + calendario. Dogfooding Architecture. Mapeo BMF completo. 8 nuevos activos propuestos para Registry. | --- *[[Re100X-Strategic-Path-SherpaIA-v01]] v1.0 — EmpowerLabs — 2026-03-20* *Strategic Path para la implementación dual de Tu Sherpa IA bajo Big MetaFactory Architecture*