## Asset Header

- **Asset ID:** ARQ-XX-SX-MetaFactory-v01
- **Version:** v01
- **Status:** Draft
- **Owner:** Victor Heredia
- **IntellBank:** IB-XX-Maestro
- **Tipo:** ARQ — Architecture
- **Propósito:** MetaFactory Sherpa IA
- **Última actualización:** 2026-04-11

---

# MetaFactory Sherpa IA
## SHA-MetaFactory-v01

---


---

## Nota fundacional

> Esta MetaFactory existe porque Victor la construyó primero para sí mismo.
>
> **Principio de Dogfooding:** FI-SHA-VICTOR fue el Caso 0 — la primera Factory Instance de la MF-DIA. Todo lo que está en este documento proviene de esa experiencia real. Los patrones, los problemas técnicos, el pipeline, los criterios de calidad — todos son aprendizajes del primer cliente: el propio arquitecto del sistema.
>
> La fuerza de esta MetaFactory es que no es teoría. Es un sistema que ya funcionó.

---

## PARTE I — DEFINICIÓN DE LA METAFACTORY

---

### ¿Qué produce esta MetaFactory?

La **MF-DIA (MetaFactory Sherpa IA)** es el sistema de producción que convierte el perfil de un cliente en su **Sherpa IA operativo** — una extensión viva que conserva su identidad, criterio, memoria y estilo de operación.

**La distinción fundamental:**

| Chatbot genérico | Sherpa IA producido por MF-DIA |
|---|---|
| Responde preguntas genéricas | Responde desde el contexto y criterio del cliente |
| Empieza desde cero cada sesión | Tiene memoria persistente (BrainOS) |
| Tono inconsistente | Voz, criterio y límites del propio cliente |
| Atado a una plataforma | Portable entre LLMs (L1) + BrainOS (L2) |

**No es un producto de configuración rápida.** El Sherpa IA es el resultado de un proceso de captura, síntesis y configuración que puede tomar entre 6 y 10 horas de trabajo productivo.

---

### Lugar en el stack BMF

```
L0    Big MetaFactory Kernel               (governance y arquitectura)
L1    MetaFactory Builder                  (constructor de factories)
L2    SHA-MetaFactory-v01  ←  ESTE DOCUMENTO
L3    FI-SHA-[CLIENTE]                     (cada instancia personal)
L4    DIA-[CLIENTE]-Prompt/Ritual/Manual/Assessment/Memoria
```

La MF-SHA (L2) define el **template reusable**. Las Factory Instances (L3) son las ejecuciones específicas para cada cliente. Los activos DIA- (L4) son los entregables que cada instancia produce.

---

### Las 3 capas del Sherpa IA producido

| Capa | Nombre | Descripción | Estado en producción |
|---|---|---|---|
| **L1** | Sherpa Portable | Prompt que activa cualquier LLM como el Sherpa IA del cliente. Sin infraestructura. | ✅ Producible hoy |
| **L2** | Sherpa con BrainOS | L1 + memoria persistente vía Supabase + MCP. Sesiones con continuidad real. | ✅ Producible hoy |
| **L3** | Sherpa Soberano | L2 + proactividad programada (heartbeat, integraciones de calendario/email). | 🔄 Roadmap — no producible en Stage 1 |

**Producto mínimo viable:** L1 + L2 completos. L3 es un upgrade futuro.

---

## PARTE II — INPUTS Y OUTPUTS

---

### Inputs requeridos

| Input | Descripción | Fuente | Requerido para |
|---|---|---|---|
| **Documento de identidad** | Quién es el cliente: rol, orientación, CAM, voz, constraints. | PERSONAL_DNA.md o equivalente — construido en sesión de captura | L1 + L2 |
| **Memory Migration Source 1** | Contexto estratégico existente: notas, vault, proyectos activos, decisiones pasadas. | Archivos del cliente, vault digital | L2 (BrainOS) |
| **Memory Migration Source 2** | Historial de conversaciones con IA: decisiones, aprendizajes, frases canónicas. | Export de ChatGPT / Claude / otros | L2 (BrainOS) — opcional pero valioso |
| **Proyectos activos** | Estado actual de frentes de trabajo, compromisos, prioridades de 90 días. | Sesión de captura con el cliente | L1 + L2 |
| **Credenciales técnicas** | Supabase project URL + API keys para el BrainOS. | Creación de cuenta Supabase | L2 (BrainOS) |

**Nota:** El Sherpa IA de mayor calidad se produce cuando el cliente ya completó su CAM ([[Re100X-TP-CAM-v01]]). Con CAM disponible, el nivel de personalización del Prompt L1 es significativamente más alto. Sin CAM, se puede producir un Sherpa IA funcional con la captura directa de identidad.

---

### Outputs canónicos (los activos DIA-)

| Asset ID | Tipo | Función | Capa |
|---|---|---|---|
| **DIA-[CLIENTE]-Prompt-v01** | DIA/AS | Prompt L1 portable que activa cualquier LLM como el Sherpa IA del cliente | L1 |
| **DIA-[CLIENTE]-Manual-v01** | DIA/SOP | SOP de comportamiento: 4 modos, reglas de respuesta, autonomía calibrada | L1+L2 |
| **DIA-[CLIENTE]-Ritual-v01** | DIA/AS | Protocolo de mantenimiento semanal/mensual/mayor | L1+L2 |
| **DIA-[CLIENTE]-Assessment-v01** | DIA/ANAL | Snapshot del estado del sistema al momento de entrega | L1+L2 |
| **DIA-[CLIENTE]-Memoria-v01** | DIA/DOC | Documento de memoria estructurada + reporte del BrainOS cargado | L2 |

**Entrega mínima:** Prompt + Manual + Ritual + Assessment (4 activos). La Memoria se produce cuando el BrainOS está cargado con suficientes thoughts (~30+).

---

## PARTE III — PIPELINE DE PRODUCCIÓN

---

### Pipeline v0.1

```
FASE 0 — CAPTURA DE IDENTIDAD (2-3 hrs)
  Input:  Sesión de captura con el cliente
  Proceso: Construir PERSONAL_DNA.md o equivalente
           Capturar CAM, voz, constraints, proyectos activos
  Output: Documento de identidad listo para síntesis
  Gate:   Cliente se reconoce en el documento

          ↓

FASE 1 — PROMPT L1 PORTABLE (1 hr)
  Input:  Documento de identidad
  Proceso: Sintetizar en DIA-[CLIENTE]-Prompt-v01
           Incluir: identidad, metas 90 días, criterios de decisión,
           voz/estilo, proyectos activos, 4 modos, glosario, frase de confirmación
  Output: DIA-[CLIENTE]-Prompt-v01
  Gate:   Cliente activa el Prompt en cualquier LLM y obtiene respuesta
          que suena "como él" y cubre sus proyectos reales

          ↓

FASE 2 — FRAMEWORK CONDUCTUAL (1-2 hrs)
  Input:  Documento de identidad + Prompt L1
  Proceso: Generar DIA-[CLIENTE]-Manual-v01 (4 modos, reglas, autonomía)
           Generar DIA-[CLIENTE]-Ritual-v01 (3 niveles, 8 categorías)
  Output: Manual + Ritual
  Gate:   Las reglas del Manual reflejan el criterio real del cliente

          ↓

FASE 3 — SETUP OPEN BRAIN (2-3 hrs)
  Input:  Credenciales Supabase del cliente
  Proceso: Crear proyecto Supabase
           Ejecutar setup-thoughts-table.sql
           Desplegar Edge Function BrainOS-mcp (con npm: imports)
           Configurar secretos MCP_ACCESS_KEY + OPENROUTER_API_KEY
           Activar conector en Claude Desktop
           Ejecutar Memory Migration Source 1 (vault/notas del cliente)
           Ejecutar Memory Migration Source 2 (ChatGPT export, cuando disponible)
  Output: BrainOS operativo con 20+ thoughts cargados
  Gate:   search_thoughts devuelve resultados relevantes para una consulta
          estratégica real del cliente

          ↓

FASE 4 — VALIDACIÓN Y ENTREGA (1 hr)
  Input:  Todo lo anterior
  Proceso: Primera sesión de uso real L2 (cliente con BrainOS activo)
           Generar DIA-[CLIENTE]-Assessment-v01 (snapshot del estado)
  Output: Assessment + sistema validado en uso real
  Gate:   Primera sesión produce valor sin fricción operativa
          Cliente puede iniciar sesión L2 sin ayuda

          ↓

FASE 5 — PRIMERA ITERACIÓN (ongoing)
  Trigger: Primera Weekly Review (7 días post-entrega)
  Proceso: Ejecutar DIA-[CLIENTE]-Ritual-v01 por primera vez
           Refinar Prompt basado en uso real
           Continuar Memory Migration Source 2 si aplica
  Output: Versión refinada del Prompt (v01 → v01.1 o v02)
```

---

### Issues técnicos conocidos y resoluciones

Aprendidos durante FI-SHA-VICTOR (Caso 0). Documentar aquí para acelerar futuras instancias.

| Issue | Síntoma | Causa | Resolución |
|---|---|---|---|
| **#1 — Imports Deno** | `Relative import path not prefixed with / or ./` al hacer deploy | Deno requiere `npm:` prefix para paquetes npm | Cambiar `import from "@supabase/supabase-js"` a `import from "npm:@supabase/supabase-js"` en todos los imports |
| **#2 — Secreto con guiones** | MCP conecta pero retorna 401 / "Couldn't reach the server" | Secret guardado como `MCP-ACCESS-KEY` (guiones) pero el código lee `MCP_ACCESS_KEY` (guiones bajos) | Verificar en Supabase Dashboard → Settings → Secrets que el nombre sea exactamente `MCP_ACCESS_KEY` |
| **#3 — Tabla no creada** | `Could not find the table 'public.thoughts'` | El SQL de setup nunca fue ejecutado | Ejecutar `setup-thoughts-table.sql` en Supabase SQL Editor antes de probar el conector |
| **#4 — OAuth 401** | Error en los logs del MCP: `OAuth discovery 401` | El endpoint de OAuth no está configurado para ser público | No es un error real — el MCP usa key-based auth. Ignorar este log específico. |
| **#5 — CodeMirror mangling SQL** | Caracteres especiales corruptos al escribir SQL directamente en el editor | El editor de Supabase en el navegador interfiere con caracteres especiales (quotes, comentarios) | Escribir el SQL en un archivo local → copiar al clipboard vía `pbcopy` → pegar en el editor con Cmd+V |

**Tiempo total de resolución de issues en Caso 0:** ~4 horas de las ~10 horas totales de build. Con esta tabla, el tiempo esperado en futuras instancias es < 30 minutos.

---

## PARTE IV — CRITERIOS DE CALIDAD

---

### Gates de aceptación por fase

| Gate | Criterio | Método de verificación |
|---|---|---|
| **G1 — Identidad** | El cliente se reconoce en el Prompt L1 | El cliente lee el Prompt y dice "esto soy yo" sin correcciones mayores |
| **G2 — Portabilidad L1** | El Prompt activa el Sherpa IA en cualquier LLM | Probar en ChatGPT + Claude: el Sherpa IA responde en la voz correcta y conoce los proyectos activos |
| **G3 — BrainOS** | El sistema recupera contexto relevante | Hacer 3 búsquedas semánticas sobre temas del cliente y obtener resultados con similarity > 0.5 |
| **G4 — Uso real** | Primera sesión L2 produce valor sin fricción | El cliente completa una tarea real en la primera sesión sin ayuda técnica |
| **G5 — Entrega** | Cliente puede operar el sistema de forma autónoma | El cliente ejecuta el protocolo de inicio de sesión L2 sin instrucción |

### Indicadores de salud post-entrega (30 días)

Un Sherpa IA está funcionando bien cuando:

- ✅ El cliente reporta más paz, claridad y menos fricción operativa
- ✅ El BrainOS tiene al menos 50 thoughts después del primer mes
- ✅ El Ritual semanal se ejecutó al menos 2 veces en los primeros 30 días
- ✅ El Prompt fue refinado al menos 1 vez basado en uso real
- ✅ El cliente puede delegar tareas específicas sin micro-gestionar al Sherpa IA

---

## PARTE V — FACTORY INSTANCES REGISTRADAS

---

| # | Factory Instance | Cliente | Fecha de inicio | Estado | Assets producidos | BrainOS |
|---|---|---|---|---|---|---|
| 1 | **FI-SHA-VICTOR** | Victor Heredia (EmpowerLabs) | 2026-03-20 | ✅ Operativo | Prompt (v1.2) + Ritual + Manual + Assessment + Roadmap + CasosDeUso (6/5+) | ✅ 67+ thoughts activos. Source 2 pendiente. |

---

## PARTE VI — CASO DE ÉXITO: FI-SHA-VICTOR

*El primer cliente de la MetaFactory fue su propio arquitecto.*

---

### Contexto

**Fecha:** 2026-03-20 / 2026-03-21 (2 días de build intensivo)
**Cliente:** Victor Heredia — CEO/Fundador EmpowerLabs
**Principio:** Dogfooding Architecture — Victor construyó su propio Sherpa IA simultáneamente para uso personal y para generar los templates de productización.
**Modelo de entrega utilizado:** Co-construcción con Cowork (Claude + Victor en sesiones de trabajo)

---

### Estado ANTES

| Dimensión | Estado pre-build |
|---|---|
| Identidad sistematizada | PERSONAL_DNA.md existía — identidad canónica disponible |
| Prompt portable | No existía — dependía del contexto de conversación de cada sesión |
| Memoria persistente | No existía — cada sesión de IA empezaba de cero |
| Infraestructura BrainOS | No existía — solo arquitectura en papel |
| Protocolo de mantenimiento | No existía |
| Reglas de comportamiento del Sherpa IA | No existían — comportamiento ad hoc |

---

### Estado DESPUÉS

| Dimensión | Estado post-build |
|---|---|
| Identidad sistematizada | PERSONAL_DNA.md v1.0.0 + SHA-VICTOR-Prompt-v01 operativo |
| Prompt portable | SHA-VICTOR-Prompt-v01 — activa cualquier LLM como el Sherpa IA de Victor |
| Memoria persistente | BrainOS con 44 thoughts — semántica, búsqueda vectorial |
| Infraestructura BrainOS | Supabase + OpenRouter + MCP + Claude Desktop connector activo |
| Protocolo de mantenimiento | SHA-VICTOR-Ritual-v01 — 3 niveles, 8 categorías |
| Reglas de comportamiento del Sherpa IA | SHA-VICTOR-Manual-v01 — 4 modos, autonomía calibrada |

---

### Métricas del build

| Métrica | Valor |
|---|---|
| Duración total | ~2 días (sesiones de trabajo en Cowork) |
| Issues técnicos resueltos | 5 (documentados en Parte III) |
| Horas en resolución de issues | ~4 hrs de las ~10 hrs totales |
| Horas en producción de activos | ~6 hrs |
| Assets DIA- producidos | 4 de 5 (Prompt, Ritual, Manual, Assessment) |
| Thoughts en BrainOS (Source 1) | 44 thoughts / 10 categorías / 3 tipos |
| Cobertura semántica inicial | Identidad, proyectos, arquitectura, productos, metodologías, decisiones, metas, constraints, Sherpa IA, BrainOS |
| BMF Alignment completado | Sí — análisis formal, 3 alertas cerradas, 2 abiertas |
| Prefijo SHA- formalizado en BMF | Sí — registrado en BMF-Launch-Glosario-v01 |

---

### Aprendizajes de productización extraídos

Estos aprendizajes mejoran directamente la MetaFactory para futuros clientes:

**0. Onboarding Capture Template creado** *(2026-03-22)*
El template `SHA-OnboardingCapture-Template-v01` existe y está operativo. 8 secciones, 45-60 min de llenado. Cubre: identidad core, hiperpoder/CAM, criterios de decisión, voz/estilo, contexto activo, ecosistema, código de vida, pregunta libre. Incluye checklist Gate G0 para el facilitador. Output alimenta directamente el Prompt L1 del cliente.
→ **Acción completada.** Fase 0 del pipeline ahora tiene estructura formal.

**1. El setup técnico del BrainOS tiene más fricción de lo esperado**
El cliente no puede configurar Supabase + Deno + MCP sin guía paso a paso detallada. Los 5 issues técnicos identificados son predecibles y repetibles. Una guía de instalación con los issues conocidos reduce el tiempo de setup de 4 horas a menos de 30 minutos.
→ **Acción de MetaFactory:** Crear `SHA-GuiaInstalacion-v01` con troubleshooting de los 5 issues documentados.

**2. La distinción Manual vs. Companion Playbook es crítica para la entrega al cliente**
El Manual (DIA-) es el SOP del Sherpa IA. El Companion Playbook (MPB-) gobierna todo el sistema. El cliente necesita recibir el MPB como su documento maestro — el Manual es un componente interno que vive dentro del Playbook, no el documento principal.
→ **Acción de MetaFactory:** El entregable principal al cliente es el `MPB-[CLIENTE]-MiSherpaIA-v01`. Los DIA- son sus activos de soporte.

**3. El Prompt L1 gana calidad cuando el cliente tiene CAM documentado**
Victor tenía PERSONAL_DNA.md — un documento de identidad maduro. Sin ese input, el Prompt L1 es más genérico. La calidad del Sherpa IA es directamente proporcional a la calidad del input de identidad.
→ **Acción de MetaFactory:** Diseñar un `SHA-OnboardingCapture-Template-v01` — cuestionario de captura de identidad para clientes que no tienen PERSONAL_DNA. Integrar con CAM cuando disponible.

**4. La Memory Migration en 2 fuentes (vault + ChatGPT) es la carga inicial óptima**
Source 1 (vault/notas) captura el pensamiento estructurado del cliente. Source 2 (ChatGPT export) captura el pensamiento conversacional — frases reales, heurísticas expresadas naturalmente, criterios de decisión en contexto. La combinación de ambas da el BrainOS más rico.
→ **Acción de MetaFactory:** El protocolo de Memory Migration con 2 fuentes es el estándar canónico. Source 2 puede tardar días en llegar — documentar como tarea asíncrona post-entrega.

**5. El primer uso real del Sherpa IA valida todo lo anterior**
La primera sesión real con el Sherpa IA activo (L2, BrainOS, tarea concreta) es el momento de verdad. Si esa sesión produce valor sin fricción, el sistema está bien configurado. Si genera confusión o el cliente tiene que re-explicar cosas que deberían estar en memoria, hay un gap de calidad.
→ **Acción de MetaFactory:** Gate G4 (primera sesión real) no es opcional. No se cierra la entrega hasta que el cliente complete una tarea real con el sistema.

---

### Próximos pasos para FI-SHA-VICTOR

| # | Tarea | Prioridad | Trigger |
|---|---|---|---|
| 1 | Memory Migration Source 2 (ChatGPT export) | 🟡 Media | Llegada del .zip por email |
| 2 | Primera sesión de uso real (L2 en trabajo cotidiano) | 🔴 Alta | Esta semana |
| 3 | Primera ejecución del Ritual semanal | 🔴 Alta | Esta semana |
| 4 | Actualizar Prompt L1 basado en uso real | 🟡 Media | Después de primera semana de uso |
| 5 | SHA-VICTOR-Memoria-v01 formal | 🟢 Baja | Cuando Source 2 esté cargada |

---

## PARTE VII — DECISIONES DE PRODUCTIZACIÓN PENDIENTES

*Heredadas de [[Re100X-TP-SherpaIA-v01]] — Requieren validación de Victor.*

| ID | Decisión | Impacto | Estado |
|---|---|---|---|
| **D1** | Modelo de entrega: ¿servicio gestionado, self-serve guiado o co-construcción? | Alto — define cómo se produce el Sherpa IA para futuros clientes | ✅ RESUELTA (2026-03-22) — **Co-construcción con Cowork**: 3 sesiones (identidad+L1 / BrainOS / validación). Victor como arquitecto-guía. Escalable a self-serve en v1.0. |
| **D2** | Precio y empaque: ¿bundle único, módulos separados, suscripción anual? | Alto — el Sherpa IA necesita mantenimiento, sugiere modelo recurrente | ✅ RESUELTA (2026-03-22) — **Setup $2,500 USD + $300 USD/mes**. Año 1 ~$5,800. Recurrencia alinea incentivos de evolución del sistema. |
| **D3** | ¿Cuál es la versión mínima viable para el primer cliente externo? | Alto — ¿L1 solo (más rápido) o L1+L2 (más valor)? | ✅ RESUELTA — L1+L2 es el estándar. L3 como upgrade futuro. |
| **D6** | Portabilidad ligera vs. arquitectura profunda | Alto — afecta el diseño técnico de todos los activos | ✅ RESUELTA — L1+L2 como estándar. L3 como upgrade premium. |
| **D7** | ✅ RESUELTA — ¿Se construye el Sherpa IA de Victor primero como prototipo? | — | ✅ Completado. FI-SHA-VICTOR es el Caso 0 validado. |

---

## PARTE VIII — ROADMAP DE EVOLUCIÓN

| Versión | Trigger | Cambio |
|---|---|---|
| **v0.1** | Ahora (Stage 1 Solo/Lean) | Fundacional. Pipeline documentado. 1 case study (Victor). Issues técnicos conocidos. |
| **v0.2** | Primer cliente externo | Refinar pipeline con learnings del primer cliente. Crear SHA-OnboardingCapture-Template. |
| **v0.3** | 3+ clientes completados | Documentar variaciones por perfil de cliente. Estimar tiempo real de producción por perfil. |
| **v1.0** | 5+ casos de éxito | MetaFactory estabilizada. Templates pulidos. Self-serve parcialmente viable. |

---

## Historial de versiones

| Versión | Fecha | Cambio |
|---|---|---|
| v0.1 | 2026-03-21 | Creación inicial. Pipeline v0.1 definido. 5 issues técnicos documentados. FI-SHA-VICTOR como Caso 0 con métricas reales. Criterios de calidad establecidos. Decisiones D1-D7 heredadas del TP. |

---

*[[SHA-MetaFactory-v01]] v0.1 — EmpowerLabs / Victor Heredia — 2026-03-21*
*Stage 1 MEL activo. Actualizar con cada nueva Factory Instance.*
*Fuente canónica: [[Re100X-TP-SherpaIA-v01]] + [[MPB-MiSherpaIA-Victor-v01]]*