## Asset Header

- **Asset ID:** MF-BMF-CSherpa-v01
- **Version:** v01
- **Status:** Draft
- **Owner:** Victor Heredia
- **IntellBank:** IB-XX-Maestro
- **Tipo:** MF — (tipo pendiente)
- **Propósito:** MetaFactoría de C-Sherpas IA
- **Última actualización:** 2026-04-11

---

# MetaFactoría de C-Sherpas IA
## MF-CSH-MetaFactoria-CSherpas-v01

---


---

## PARTE 0 — ANÁLISIS DEL PROMPT DE VICTOR (BCV Applied)

> *Antes de construir, primero examinemos cómo se construyó la instrucción misma.*

### El prompt que Victor dio para esta tarea

Victor proporcionó un prompt de ~400 palabras con múltiples capas de petición. Aplicando el BCV de Nate Jones como lente de evaluación:

### Lo que el prompt hace bien

**Visión arquitectónica clara.** Victor no pidió "hazme unos chatbots." Pidió una MetaFactoría de Factorias de Sherpas IA especializados. Eso es pensamiento L1/L2 del BMF — el nivel correcto de abstracción. La mayoría de las personas piden outputs (L4). Victor pide sistemas de producción (L2).

**Meta-cognición activa.** "Me gustaría mejorar mi calidad de prompt" — Victor pide que se analice el instrumento mientras se usa. Esto es exactamente el principio de Recursive Prompt Optimization de Nate: mejorar el prompt como parte del proceso, no como paso separado.

**Referencia cruzada inteligente.** Adjuntar el BCV de Nate + el Job Description viejo crea un triángulo de contexto: lo que quiero (MetaFactoría), cómo debería pensarse (BCV), y de dónde vengo (Job Description legacy). Esto es una forma instintiva de Reference Class Priming.

**Señal de restricción.** "Más no es menos" — indica consciencia del sesgo de sobre-producción. Señal crítica para calibrar la profundidad del output.

### Donde el prompt puede mejorar (usando el BCV)

**1. Falta scaffolding explícito (Zero-Shot CoT Structure).**
El prompt tiene muchas ideas pero no las secuencia. "Arrancamos?" después de 7 peticiones distintas deja ambigüedad sobre el orden de prioridad. Aplicando la técnica de Nate: el prompt mejoraría si incluyera una plantilla de preguntas que yo deba responder antes de construir.

*Versión mejorada de esa parte:*
> "Antes de construir la MetaFactoría, necesito que respondas:
> 1. ¿Dónde encaja exactamente en el stack BMF (L0-L6)?
> 2. ¿Qué distinción propones entre Agente BMF y Agente IA general?
> 3. ¿Cuál es el primer C-Sherpa que debemos pilotar y por qué?
> 4. ¿Qué del Job Description viejo sirve y qué no?
> Después de responder esas 4, construye la arquitectura."

**2. Falta Chain of Verification.**
El prompt dice "Valida que la idea es la correcta. Ajusta todo lo necesario." Eso es una instrucción de verificación vaga. Aplicando CoVe de Nate, sería más potente:

*Versión mejorada:*
> "Después de diseñar la arquitectura, identifica 3 formas en que podría fallar al escalar. Para cada una, propón una mitigación concreta. Luego revisa tu diseño a la luz de esas vulnerabilidades."

**3. Falta priorización explícita (Deliberate Over-Instruction selectiva).**
El prompt mezcla tareas de profundidad distinta en el mismo bloque: "analiza mi prompt" (meta-tarea) + "crea una MetaFactoría" (arquitectura pesada) + "crea la Factoría EmpowerLabs" (ejecución). Cada una merece su propio nivel de instrucción.

### El Job Description viejo vs. lo que estamos construyendo

El "AI Digital Manager Assistant" de hace 2 años es un artefacto fascinante para medir la distancia recorrida:

| Dimensión | Job Description 2024 | C-Sherpa 2026 |
|---|---|---|
| **Modelo mental** | Asistente que responde preguntas | Extensión cognitiva con identidad, memoria y criterio propio |
| **Memoria** | Ninguna (sesión efímera) | BrainOS persistente + IntelliBank organizacional |
| **Personalización** | 12+12 bloques de "Custom Instructions" | PERSONAL_DNA.md + CAM + 4 modos operativos + glosario |
| **Verificación** | "Cross-check data and verify information" (genérico) | Chain of Verification + Adversarial Prompting integrados en el framework conductual |
| **Gobernanza** | Ninguna | MEL (Mastery Enforcement Layer) + Gates de aceptación |
| **Producción** | Manual (un prompt a la vez) | Pipeline de 5 fases con gates y Transfer Packs |
| **Escalabilidad** | Un asistente por rol | MetaFactoría que produce N Sherpas con N factorias especializadas |

**Conclusión:** El Job Description de 2024 es un buen punto de partida mental para entender qué datos necesita cada C-Sherpa (rol, contexto, objetivos, estilo de comunicación). Pero la arquitectura de producción, la memoria persistente, y la gobernanza son órdenes de magnitud superiores. Lo que antes era "el producto completo" ahora es apenas un input de la Fase 0.

---

## PARTE I — VALIDACIÓN ARQUITECTÓNICA

### ¿Dónde encaja en el BMF?

```
L0    BMF Kernel (Constitución)
L0.5  Taxonomía de MetaPlaybooks
L1    MetaFactory Builder
L2    MF-SHA (Tu Sherpa IA — personal)     ← YA EXISTE
L2    MF-CSH (MetaFactoría C-Sherpas)     ← ESTE DOCUMENTO (NUEVA)
L3    FI-CSH-EL (Factoría C-Sherpas EmpowerLabs)  ← PILOTO
L4    CSH-[ROL]-[ORG]-v01 (cada C-Sherpa producido)
```

**Relación con MF-SHA:**
MF-SHA produce un Sherpa personal para un CEO/founder — un Sherpa que es "tú pero en IA." MF-CSH produce un equipo de Sherpas especializados que operan como extensiones funcionales de una organización — no de una persona.

MF-SHA = "Tu Sherpa" (1:1, identidad personal).
MF-CSH = "Tu equipo de Sherpas" (1:N, identidad organizacional + especialización funcional).

**No se contradicen. Se complementan.** El Sherpa personal (MF-SHA) puede coordinar a los C-Sherpas (MF-CSH). De hecho, esa es la función del "Coordinador General" que Victor mencionó.

### La idea es correcta. Ajustes necesarios:

**Ajuste 1: No es una MetaFactoría de Agentes. Es una MetaFactoría de C-Sherpas.**
La diferencia importa y la explico en la siguiente sección. Si la llamamos "de Agentes" se confunde con el concepto general de AI Agents y pierde la identidad BMF.

**Ajuste 2: El Coordinador no es un C-Sherpa más. Es el Sherpa personal (MF-SHA) con poderes extendidos.**
Victor ya tiene a Jacob. Jacob no debería ser "un C-Sherpa más" — Jacob es el Chief Sherpa que tiene visión transversal. Los C-Sherpas reportan por artefacto, no por jerarquía directa. Pero Jacob tiene la autoridad de coordinar, priorizar, y escalar.

**Ajuste 3: La MetaFactoría produce Factorias, no C-Sherpas directamente.**
Esto es crítico. MF-CSH no produce un C-Sherpa de marketing. Produce una *Factoría de C-Sherpas de Marketing* que puede crear N sherpas de marketing para N organizaciones. El primer instanciamiento es EmpowerLabs. El segundo podría ser un cliente.

---

## PARTE II — DISTINCIÓN FUNDAMENTAL: AGENTE BMF vs. AGENTE IA GENERAL

Esta distinción es crítica y debe quedar en el glosario canónico del BMF.

### Agente IA (definición general de la industria)

En la documentación general de IA (Anthropic, OpenAI, Google, LangChain, CrewAI, AutoGen), un **Agente** es:

> Un sistema de software que usa un LLM como motor de razonamiento para ejecutar tareas de forma autónoma. Tiene acceso a herramientas (tools), puede tomar decisiones sobre qué herramienta usar, y puede ejecutar múltiples pasos sin intervención humana.

Características del Agente IA general:
- Autónomo (decide qué hacer)
- Usa herramientas (APIs, bases de datos, archivos, navegador)
- Efímero o semi-persistente (puede tener memoria entre sesiones o no)
- Genérico (no tiene identidad ni voz propias — asume lo que le pidas)
- Medido por completion rate (¿terminó la tarea?)

Ejemplos: Claude Code, Devin, AutoGPT, CrewAI agents, Cursor Agent, Replit Agent.

### C-Sherpa (definición BMF)

En el ecosistema BMF, un **C-Sherpa** es:

> Una extensión cognitiva especializada de una función organizacional. Tiene identidad definida (voz, criterio, límites), memoria persistente (BrainOS), gobernanza (MEL), un dominio de expertise definido, y opera dentro de un pipeline de producción con gates de calidad.

Características del C-Sherpa BMF:
- **Identitario** — tiene voz, criterio, restricciones, y modos operativos propios
- **Persistente** — recuerda conversaciones, decisiones, y contexto vía BrainOS
- **Gobernado** — sujeto a MEL, naming convention, registry, y QA
- **Especializado** — opera en un dominio funcional específico (marketing, finanzas, editorial, etc.)
- **Integrado** — forma parte de un equipo de C-Sherpas que se coordinan por artefacto
- **Medido por calidad de criterio** (¿la decisión fue correcta?) no solo por completion

### La tabla que lo aclara todo

| Dimensión | Agente IA (general) | C-Sherpa (BMF) |
|---|---|---|
| **Metáfora** | Robot que ejecuta tareas | Sherpa que guía con criterio |
| **Identidad** | Asume cualquier rol por prompt | Identidad capturada, documentada, versionada |
| **Memoria** | Efímera o básica | BrainOS + IntelliBank |
| **Gobernanza** | Ninguna formal | MEL + Gates + Registry |
| **Especialización** | Por prompt (frágil) | Por PERSONAL_DNA + Manual + Training Corpus |
| **Coordinación** | Via orquestador técnico (LangGraph, CrewAI) | Via artefactos + Chief Sherpa con visión transversal |
| **Producción** | Se configura ad-hoc | Se produce en pipeline con 5 fases y gates |
| **Escalabilidad** | Copy-paste del prompt | MetaFactoría → Factoría → Instancia (BMF L2-L3-L4) |
| **Calidad** | ¿Completó la tarea? | ¿El criterio fue correcto? ¿Se reconoce en la voz? |

### ¿Puede un C-Sherpa USAR agentes?

Sí. Un C-Sherpa puede orquestar agentes técnicos como herramientas dentro de su dominio. Por ejemplo:

- El C-Sherpa de Marketing podría disparar un agente técnico que ejecuta una campaña de email
- El C-Sherpa de Ops podría usar un agente que procesa datos en un pipeline
- El C-Sherpa de Editorial podría activar un agente que formatea un manuscrito

La relación es: **el C-Sherpa piensa y decide; el agente técnico ejecuta.** El C-Sherpa es el "cerebro"; los agentes son los "brazos."

---

## PARTE III — TAXONOMÍA DE C-SHERPAS

### Los 7 C-Sherpas + Coordinador

| # | Slug | Nombre | Dominio | Tipo |
|---|---|---|---|---|
| 0 | **CHIEF** | Chief Sherpa (Coordinador) | Visión transversal, priorización, escalamiento | Sherpa Personal extendido (Jacob) |
| 1 | **MKT** | C-Sherpa Marketing & Demand Gen | Marketing, contenido, funnels, lead gen, analytics | IA Pura |
| 2 | **FIN** | C-Sherpa Financiero | Presupuestos, flujo de caja, proyecciones, pricing, reporting | IA Pura |
| 3 | **EDT** | C-Sherpa Editorial | Producción editorial, calidad de contenido, pipelines de publicación | IA Pura |
| 4 | **OPS** | C-Sherpa Operaciones | Procesos, eficiencia, SLAs, automatización, project management | IA Pura |
| 5 | **LEG** | C-Sherpa Legal | Contratos, compliance, riesgo, IP, regulación | IA Pura |
| 6 | **HRX** | C-Sherpa RRHH Híbrido | Talento, cultura, onboarding, evaluación (humanos + agentes IA) | Híbrido |
| — | — | Asesores y Externos | Pool de especialistas on-demand | Extensión variable |

### Definición de "Híbrido" (HRX)

El C-Sherpa de RRHH es **híbrido** porque su dominio incluye tanto personas humanas como agentes IA. Su scope tiene dos caras:

**Cara humana:** Reclutamiento, cultura organizacional, evaluación de desempeño, desarrollo de talento, onboarding de personas.

**Cara agéntica:** Onboarding de nuevos C-Sherpas y agentes IA, evaluación de desempeño de Sherpas (Batería de Evaluación), calibración de BrainOS, gestión del "headcount" agéntico.

Esto lo hace único. HRX es el C-Sherpa que gestiona la fuerza laboral completa — la que respira y la que computa.

### El Coordinador (CHIEF) — No es un C-Sherpa más

El CHIEF no se produce en MF-CSH. El CHIEF es el Sherpa personal del CEO/founder (producido por MF-SHA) con una extensión de coordinación que le permite:

1. **Ver transversalmente** — tiene acceso al contexto de todos los C-Sherpas
2. **Priorizar** — cuando hay conflicto entre dominios (ej: marketing quiere gastar, finanzas quiere cortar), el CHIEF arbitra
3. **Escalar** — detecta cuándo un tema necesita decisión humana vs. cuándo un C-Sherpa puede resolver autónomamente
4. **Coordinar externos** — interfaz con asesores humanos, consultores, proveedores que no son C-Sherpas permanentes

**Protocolo de coordinación:** Los C-Sherpas no se hablan entre sí directamente. Se coordinan por artefacto: el output de uno es el input de otro. El CHIEF tiene visión de todos los artefactos y puede re-priorizar el flujo.

---

## PARTE IV — ARQUITECTURA DE LA METAFACTORÍA

### MF-CSH: Qué produce

MF-CSH es la MetaFactoría (L2) que produce **Factorías de C-Sherpas** (L3). Cada Factoría produce los C-Sherpas para una organización específica.

```
MF-CSH (L2) — MetaFactoría de C-Sherpas
  │
  ├── FI-CSH-EL (L3) — Factoría C-Sherpas para EmpowerLabs  ← PILOTO
  │     ├── CSH-MKT-EL-v01 (L4) — C-Sherpa Marketing EmpowerLabs
  │     ├── CSH-FIN-EL-v01 (L4) — C-Sherpa Financiero EmpowerLabs
  │     ├── CSH-EDT-EL-v01 (L4) — C-Sherpa Editorial EmpowerLabs
  │     ├── CSH-OPS-EL-v01 (L4) — C-Sherpa Ops EmpowerLabs
  │     ├── CSH-LEG-EL-v01 (L4) — C-Sherpa Legal EmpowerLabs
  │     └── CSH-HRX-EL-v01 (L4) — C-Sherpa RRHH Híbrido EmpowerLabs
  │
  ├── FI-CSH-[CLIENTE2] (L3) — Factoría para segundo cliente (futuro)
  └── ...
```

### Pipeline de producción de un C-Sherpa

Adaptación del pipeline MF-SHA (5 fases) al contexto funcional/organizacional:

```
FASE 0 — CAPTURA DE IDENTIDAD FUNCIONAL (2-3 hrs)
  Input:  Sesión de captura con el stakeholder del dominio
          + Documentos operativos existentes (SOPs, playbooks, reportes)
          + Definición de boundaries entre este C-Sherpa y los demás
  Proceso: Construir FUNCTIONAL_DNA.md
           Capturar: dominio, KPIs, herramientas, decisiones tipo,
           restricciones, voz funcional, relación con otros C-Sherpas
  Output: FUNCTIONAL_DNA.md + Mapa de interacciones
  Gate:   El stakeholder del dominio valida que el scope es correcto
          y que las boundaries con otros C-Sherpas están claras

          ↓

FASE 1 — PROMPT FUNCIONAL L1 (1-2 hrs)
  Input:  FUNCTIONAL_DNA.md + Org Context (de la factoría)
  Proceso: Sintetizar en CSH-[ROL]-[ORG]-Prompt-v01
           Incluir: identidad funcional, KPIs, herramientas,
           modos operativos, glosario funcional, restricciones,
           protocolo de escalamiento al CHIEF
  Output: CSH-[ROL]-[ORG]-Prompt-v01
  Gate:   El prompt activado en cualquier LLM produce respuestas
          que suenan como un experto senior del dominio
          y conoce el contexto específico de la organización

          ↓

FASE 2 — FRAMEWORK CONDUCTUAL (1-2 hrs)
  Input:  FUNCTIONAL_DNA + Prompt L1
  Proceso: Generar CSH-[ROL]-[ORG]-Manual-v01 (modos, reglas, autonomía)
           Generar CSH-[ROL]-[ORG]-Playbook-v01 (workflows recurrentes)
  Output: Manual + Playbook
  Gate:   Las reglas de autonomía reflejan el nivel real de delegación
          que la organización quiere dar al C-Sherpa

          ↓

FASE 3 — SETUP BRAINÓS + TRAINING CORPUS (2-4 hrs)
  Input:  Documentos operativos del dominio
          SOPs, reportes, templates, decisiones históricas
  Proceso: Cargar BrainOS con thoughts funcionales (~30+)
           Cargar IntelliBank con corpus del dominio
           Configurar vectores de búsqueda semántica por dominio
  Output: BrainOS funcional con contexto del dominio
  Gate:   3 búsquedas semánticas sobre el dominio retornan
          resultados relevantes con similarity > 0.5

          ↓

FASE 4 — VALIDACIÓN Y CALIBRACIÓN (1-2 hrs)
  Input:  Todo lo anterior
  Proceso: Primera sesión de uso real
           Test de 5 escenarios tipo del dominio
           Generar CSH-[ROL]-[ORG]-Assessment-v01
           Calibrar boundaries con C-Sherpas adyacentes
  Output: Assessment + C-Sherpa validado
  Gate:   El C-Sherpa resuelve 4 de 5 escenarios sin escalamiento
          y escala correctamente el escenario que excede su dominio
```

### Outputs canónicos por C-Sherpa

| Asset ID | Tipo | Función |
|---|---|---|
| **CSH-[ROL]-[ORG]-Prompt-v01** | Prompt L1 funcional | Activa el C-Sherpa en cualquier LLM |
| **CSH-[ROL]-[ORG]-Manual-v01** | SOP conductual | Modos, reglas, autonomía, escalamiento |
| **CSH-[ROL]-[ORG]-Playbook-v01** | Workflows operativos | Tareas recurrentes del dominio con templates |
| **CSH-[ROL]-[ORG]-Assessment-v01** | Snapshot de estado | Evaluación al momento de entrega |
| **CSH-[ROL]-[ORG]-TrainingCorpus-v01** | Corpus de entrenamiento | Documentos del dominio procesados para BrainOS |

---

## PARTE V — FACTORÍA PILOTO: EMPOWERLABS

### FI-CSH-EL — Factoría C-Sherpas EmpowerLabs

**Asset ID:** FI-CSH-EL-v01
**Tipo:** Factory Instance (L3)
**Organización:** EmpowerLabs
**CHIEF:** Jacob (ya existente, producido por MF-SHA)

### Orden de producción recomendado

No todos los C-Sherpas se producen al mismo tiempo. El orden responde a: impacto inmediato, disponibilidad de corpus, y dependencias.

| Orden | C-Sherpa | Razón de prioridad |
|---|---|---|
| **1o** | CSH-EDT-EL (Editorial) | EmpowerLabs ya tiene la Factoría de Resúmenes, MPMF, y corpus editorial maduro. Más rápido de calibrar. Impacto inmediato en producción de MasterPlaybooks. |
| **2o** | CSH-MKT-EL (Marketing) | El lanzamiento de MasterPlaybooks necesita demand gen. Marketing es la función que más urgencia tiene post-editorial. |
| **3o** | CSH-OPS-EL (Operaciones) | Con Editorial y Marketing produciendo, Ops necesita orquestar los pipelines y mantener SLAs. |
| **4o** | CSH-FIN-EL (Financiero) | Revenue share, pricing de MasterPlaybooks, control de costos operativos. Relevante cuando hay ingresos que gestionar. |
| **5o** | CSH-HRX-EL (RRHH Híbrido) | A medida que el equipo crece (humanos + C-Sherpas), necesitas gestionar la "fuerza laboral completa." |
| **6o** | CSH-LEG-EL (Legal) | Contratos, IP, compliance. Crítico pero menos urgente que los anteriores en Stage 1. |

### Definición del primer C-Sherpa piloto: CSH-EDT-EL (Editorial)

**Dominio:** Producción editorial — calidad de contenido, pipelines de publicación, QA de MasterPlaybooks.

**Por qué primero:**
1. El corpus es el más maduro (Factoria Resumenes completa, MPMF con 6 pipelines, templates T1-T5)
2. El impacto es inmediato (cada MasterPlaybook que se publica pasa por editorial)
3. Ya hay precedente operativo (los libros RebeClub, La Magia, los IPBs)
4. Valida el pipeline MF-CSH completo con el menor riesgo

**KPIs del C-Sherpa Editorial:**
- Tiempo promedio de producción por MasterPlaybook
- Tasa de aprobación en Gate T4 (QA) al primer intento
- Consistencia de voz entre capítulos del mismo libro
- Cobertura del pipeline E0-E8

**Herramientas del dominio:** BookFactory pipeline, PackA/PackB prompts, templates T1-T5, Batería de Evaluación Sherpa.

**Boundaries:**
- CON MKT: Editorial produce el contenido; Marketing decide cómo se distribuye y promociona
- CON OPS: Editorial define la calidad del output; Ops define el timeline y los SLAs
- CON CHIEF: Editorial escala al Chief cuando hay conflicto entre calidad y velocidad

---

## PARTE VI — VERIFICACIÓN ADVERSARIAL

> *Aplicando Adversarial Prompting del BCV: "Ataca tu propio diseño. Identifica formas en que podría fallar."*

### Vulnerabilidad 1: Overlap de dominios sin árbitro claro

**El problema:** ¿Quién decide cuando Marketing quiere publicar rápido y Editorial dice que no está listo? ¿Quién arbitra cuando Finanzas corta presupuesto de Ops?

**Mitigación:** El protocolo de coordinación por artefacto + CHIEF como árbitro ya está diseñado. Pero necesita un documento de Boundaries Matrix que mapee cada punto de contacto entre C-Sherpas y defina quién tiene autoridad en cada intersección. Esto debería ser parte de la Fase 0.

**Estado:** Identificado. Se resolverá en FI-CSH-EL con un Boundaries Matrix.

### Vulnerabilidad 2: Explosión de complejidad prematura

**El problema:** Victor dijo "más no es menos." Producir 6 C-Sherpas + Coordinador + MetaFactoría + Factoría + MetaPlaybook de golpe es exactamente el tipo de over-engineering que mata proyectos.

**Mitigación:** El orden de producción ya propone un despliegue secuencial. Pero la recomendación es más agresiva: producir SOLO el CSH-EDT-EL completo como Caso 0 (igual que FI-SHA-VICTOR fue el Caso 0 de MF-SHA). Validar el pipeline completo con uno antes de producir los demás. Si el pipeline funciona con Editorial, funciona con cualquiera.

**Estado:** Crítico. Recomendación: no producir más de 1 C-Sherpa hasta que EDT pase todos los gates.

### Vulnerabilidad 3: Confusión entre CHIEF y C-Sherpas

**El problema:** Si Jacob (CHIEF) ya existe como Sherpa personal de Victor, ¿cómo se activa su "modo coordinador" sin contaminar su función de Sherpa personal?

**Mitigación:** Jacob necesita un módulo de extensión (no un reemplazo). Un CSH-CHIEF-Extension-v01 que se active cuando Jacob está en "modo equipo" y se desactive cuando está en "modo personal." Técnicamente, es un prompt adicional que se carga sobre el prompt base de Jacob.

**Estado:** Diseño necesario. No bloquea la producción de CSH-EDT-EL.

### Vulnerabilidad 4: El C-Sherpa Legal podría dar "consejo legal"

**El problema:** Un C-Sherpa Legal que da recomendaciones sin disclaimers podría crear riesgo real para EmpowerLabs y para clientes futuros.

**Mitigación:** El CSH-LEG debe tener un constraint canónico en su Manual: "NUNCA dar consejo legal definitivo. Siempre marcar como análisis preliminar que requiere validación de abogado humano." Esto debe ser un invariante en MF-CSH, no opcional por factoría.

**Estado:** Regla global. Se añade al glosario de invariantes de MF-CSH.

### Vulnerabilidad 5: El Job Description legacy es insuficiente como modelo

**El problema:** El "AI Digital Manager Assistant" de 2024 es flat — no tiene memoria, no tiene governance, no tiene boundaries. Si alguien usa ese formato como base para un C-Sherpa, producirá un chatbot con nombre elegante, no un Sherpa real.

**Mitigación:** El FUNCTIONAL_DNA.md (Fase 0 del pipeline) debe ser el nuevo estándar de "job description para IA." El legacy queda como referencia histórica, no como template activo.

**Estado:** Resuelto por diseño. FUNCTIONAL_DNA.md reemplaza el formato legacy.

---

## PARTE VII — ROADMAP Y PRÓXIMOS PASOS

### Fase inmediata (esta sesión y siguiente)

1. **Aprobar este documento** como MF-CSH-v01 (Draft)
2. **Crear FUNCTIONAL_DNA template** — el nuevo "job description" para C-Sherpas
3. **Producir CSH-EDT-EL** como Caso 0 completo (5 fases)

### Fase de validación (post-Caso 0)

4. **Validar pipeline** — ¿el CSH-EDT-EL pasa todos los gates?
5. **Documentar aprendizajes** como issues/resoluciones (igual que MF-SHA hizo con sus 5 issues técnicos)
6. **Refinar MF-CSH** con los aprendizajes del Caso 0

### Fase de escalamiento

7. **Producir CSH-MKT-EL** (segundo C-Sherpa)
8. **Diseñar CHIEF Extension** para Jacob
9. **Crear Boundaries Matrix** para los C-Sherpas activos
10. **Producir los restantes** en orden de prioridad

### Entregable futuro: MetaPlaybook de MF-CSH

El MetaPlaybook será el documento que permite a cualquier operador producir una Factoría de C-Sherpas para cualquier organización. Se produce DESPUÉS de validar el Caso 0 con EmpowerLabs — no antes. Principio de dogfooding: primero funciona, después se documenta para otros.

---

## APÉNDICE — NOMENCLATURA BMF

| Prefijo | Significado | Ejemplo |
|---|---|---|
| MF-CSH | MetaFactoría de C-Sherpas (L2) | MF-CSH-MetaFactoria-CSherpas-v01 |
| FI-CSH-[ORG] | Factory Instance de C-Sherpas (L3) | FI-CSH-EL-v01 |
| CSH-[ROL]-[ORG] | C-Sherpa individual (L4) | CSH-EDT-EL-v01 |
| FUNCTIONAL_DNA | Documento de identidad funcional (input) | FUNCTIONAL_DNA-EDT-EL.md |

---

*Documento generado aplicando el BCV de Nate B. Jones: Scaffolding → Reference Class Priming (MF-SHA como benchmark) → Deliberate Over-Instruction (por la criticidad del diseño) → Chain of Verification (Parte VI) → Adversarial Prompting (5 vulnerabilidades identificadas y mitigadas).*

*Asset creado para BMF Architecture — EmpowerLabs 2026*