---
type: PLAN
asset_id: PLAN-XX-BMF-FLA-F0F1-Ejecutable-v01
version: v01
status: Draft · Listo para ejecución tras ratificación de F0
owner: Victor Heredia
sherpa_owner: Jay
ratificador: Victor Heredia (L3+)
fecha_creacion: 2026-06-20
fecha_ultima_actualizacion: 2026-06-20
intellbank: IB-XX-Maestro
subbank: IPI-XX-IP-Infraestructura / IPI-XX-BMF-Engine
tipo: PLAN — Plan ejecutable de fases
proposito: Plan operable de las fases F0 (fundación/canonización) y F1 (Registro Agéntico v1 + Despachador v1) de la Fuerza Laboral Agéntica.
deriva_de: PP-XX-BMF-FuerzaLaboralAgentica-Arquitectura-v01
relacionados:
  - PP-XX-BMF-FuerzaLaboralAgentica-Arquitectura-v01
  - CP-EL-SkillsRegistry-v01
  - SOP-EL-SkillsAlta-v01
  - PLAN-EL-UltraSherpaX-v01
  - DC-EL-LoopXSA-LoopContract-v01
tags: [plan, ejecutable, fuerza-laboral-agentica, F0, F1, registro, despachador, ontologia]
---

# FLA · Plan ejecutable F0 / F1

> **Alcance:** llevar la propuesta de papel a un sistema operable mínimo — la ontología ratificada (F0) y el primer Registro + Despachador funcionando, operados por alguien que no es Victor (F1). **No** cubre las factorías completas (F2), el despliegue en loop (F3) ni la exportación (F4): esos son planes propios.

---

## 0. Objetivo de las dos fases

| Fase | Pregunta que responde | Estado al cerrar |
|---|---|---|
| **F0 — Fundación** | "¿Cuál es la ontología canónica y el esquema del registro?" | Ontología ratificada · esquema aprobado · 4 decisiones L3+ tomadas |
| **F1 — Catálogo + Consejero** | "¿Puede el ecosistema recomendar la composición correcta para un problema, sin Victor?" | Registro v1 poblado · `/consejero` operando · validado contra eval set por un operador no-Victor |

**Criterio de éxito global F0+F1:** un colaborador del equipo (no Victor) plantea un problema real de **LoopXDG (Demand Gen)** y el `/consejero` recomienda la composición correcta (Shell × Brain Code × autonomía) contra el eval set, con la tripleta ratificando por excepción.

> **Nota de ratificación (2026-06-20):** loop piloto = **LoopXDG · Demand Gen** (ratificado). Titan×Hormozi se conserva como prueba F0; el eval y los shells de F1 se siembran con Demand Gen.

---

## 1. Gobernanza del plan

- **Tripleta del plan:** Owner = Victor · Sherpa = Jay · Ratificador = Victor (L3+).
- **Runner (operador ejecutor):** *a asignar* — candidato natural: implementation partner del equipo (rol de sistemas). Clave: que **no sea Victor**, para probar la independencia del héroe desde F1.
- **Gate G0 (Vault-First):** cada activo nuevo se verifica contra el Registry antes de crearse.
- **Naming BMF** en todo activo. Asset ID = Filename = WikiLink.
- **Autonomía:** la construcción del Registro/Despachador opera en **L1** (IA propone, humano ratifica por excepción). Las decisiones de ontología y nombres son **L3** (Victor decide).

---

## 2. FASE F0 — Fundación (canonización)

**Meta:** dejar el marco ratificado para que F1 construya sobre roca, no sobre arena.

### Workstream F0-A · Ratificación de la propuesta
- **F0-A1** — Revisión sección-por-sección de `PP-XX-BMF-FuerzaLaboralAgentica-v01` con Victor (ver §5 de la propuesta: 4 decisiones L3+). → *Sherpa: Jay · Decide: Victor*
- **F0-A2** — Aplicar correcciones y cambiar `status` de la propuesta a **Canonical**.
- **Salida:** propuesta ratificada.

### Workstream F0-B · Canonizar la ontología componible
- **F0-B1** — Crear **`CP-XX-BMF-OntologiaAgentica-v01`** (Canonical Paper). Contenido:
  - La columna: **Shell × Brain Code(s) × Harness × Gobernanza**.
  - Definición operativa: *skill = capacidad que el modelo carga (sin harness)* · *agente = loop que el modelo corre (con harness)*.
  - Tipos y campos de cada columna; reglas de composición (1 shell, N Brain Codes con territorio + orden de prioridad; chequeo de composabilidad/conflicto).
  - Mapa de niveles de autonomía L0–L3 ↔ HITL/HOTL/asistido.
- **F0-B2** — Reconciliar con EmpowerTeamX, BrainX y SVA: una tabla de equivalencias que deja claro que son vistas de la misma ontología.
- **Salida:** ontología canónica única (mata la brecha "skill/agente/motor difuso").

### Workstream F0-C · Esquema del Registro
- **F0-C1** — Crear **`TP-XX-BMF-RegistroAgentico-Schema-v01`** (template): el frontmatter tipado de las tres clases de entrada — **AgentCard (shell)**, **Manifiesto de Brain Code**, **Composición desplegada (Sherpa Especializado)**. Campos mínimos por clase (ver §6).
- **F0-C2** — Definir el formato del índice: `.md` por entrada + un índice navegable (y/o JSON exportable para routing futuro).
- **Salida:** esquema aprobado.

### Decisiones L3+ requeridas en F0 (Victor)
1. Ratificar la ontología `Shell × BrainCode × Harness × Gobernanza`.
2. Nombre de la fuerza laboral (recomendación: conservar **EmpowerTeamX**).
3. Loop piloto para F3 — ✅ **LoopXDG · Demand Gen** (ratificado; Victor afina el fin de semana).
4. ¿Factoría = producto vendible o capacidad interna?

### Gate F0 → F1
✅ Propuesta Canonical · ✅ `CP-XX-BMF-OntologiaAgentica-v01` ratificado · ✅ esquema aprobado · ✅ 4 decisiones tomadas.

---

## 3. FASE F1 — Registro v1 + Despachador v1 (interno)

**Meta:** un catálogo mínimo machine-readable + un consejero que recomiende, validado por un operador no-Victor.

### Workstream F1-A · Registro Agéntico v1
- **F1-A1** — Crear **`CP-XX-BMF-RegistroAgentico-v01`** (el registro maestro + dashboard, espejo del SkillsRegistry pero para composiciones).
- **F1-A2** — Poblar **shells** (AgentCards) con descripciones ricas para recuperador (frases-gatillo + alcance negativo): los del Bloque A (propios) + los AI Specialists del Bloque B relevantes a **LoopXDG** (p. ej. linx, cara, celia, cody, sandra, sebo) + titan (de F0).
- **F1-A3** — Poblar **manifiestos de Brain Code** de los 33 existentes (ficha: dominio, lentes, territorio, guardas CAL, confidencialidad).
- **F1-A4** — Registrar la primera **composición desplegada**: `SVA-EL-Titan-BusinessOffer-v01` con su Harness, autonomía y estado de eval.
- **Salida:** Registro v1 consultable.

### Workstream F1-B · Despachador / Consejero v1
- **F1-B1** — Crear el skill **`/consejero`** (alias `/despacha`) en el plugin `worx-empowerlabs` (o nuevo `worx-fla`). MVP: consulta el índice del Registro y **razona** la recomendación (sin infra vectorial todavía) → devuelve `Shell × Brain Code(s) × autonomía + Loop Contract aplicable`; si falta cognición, **receta crear un Brain Code** y deriva a la (futura) factoría.
- **F1-B2** — Diseño documentado en **`DC-XX-BMF-Despachador-Diseno-v01`** (pipeline: front-door barato → match por tags/descn → refinamiento iterativo en ambigüedad → receta).
- **F1-B3** — Alta del skill por `SOP-EL-SkillsAlta` (7 pasos), editando SOURCE en el marketplace, no el cache.
- **Salida:** `/consejero` operando.

### Workstream F1-C · Eval set + validación no-Victor
- **F1-C1** — Construir **`EVAL-XX-BMF-Despachador-v01`**: 10–15 problemas reales de **LoopXDG (Demand Gen)** con la composición correcta esperada (ground truth).
- **F1-C2** — Correr el `/consejero` contra el eval set; juez = LLM-as-judge + revisión humana de bordes. Métrica: % de recomendaciones correctas.
- **F1-C3** — **Prueba de independencia del héroe:** el Runner (no-Victor) opera el `/consejero` end-to-end en una sesión real.
- **Salida:** reporte de validación.

### Gate F1 → F2
✅ Registro v1 poblado (shells + 33 BC + Titan) · ✅ `/consejero` recomienda ≥ **80%** del eval set correctamente · ✅ operado por no-Victor en sesión real · ✅ diseño documentado.

---

## 4. Secuencia y cadencia sugerida

| Semana | Foco | Hitos |
|---|---|---|
| **1** | F0-A + F0-B | Revisión/ratificación · `CP-OntologiaAgentica` borrador |
| **2** | F0-B + F0-C | Ontología ratificada · esquema aprobado → **Gate F0** |
| **3** | F1-A | Registro v1: shells + manifiestos BC + Titan |
| **4** | F1-B | `/consejero` v1 + diseño · alta por SOP |
| **5** | F1-C | Eval set · validación · prueba no-Victor → **Gate F1** |

*(Cadencia relativa; ajustar a sprints del equipo.)*

---

## 5. Riesgos y mitigaciones

- **Sobre-ingeniería temprana** → MVP del Despachador razona sobre el índice; nada de infra vectorial hasta F2/F3. *Default single-agent; escalar con evidencia.*
- **Descripciones pobres → mal routing** → invertir en metadata: frases-gatillo, sinónimos, alcance negativo (el campo confirma que la descripción ES la superficie de routing).
- **Dependencia del héroe se cuela** → la prueba no-Victor es gate, no opcional, desde F1.
- **Catálogo que envejece** → cada entrada nace con tripleta + estado de eval; sin eval, no entra (gate que puede dar FAIL).
- **Memoria/skills como superficie de riesgo** → diferir memoria compartida a fase posterior; firmar/versionar skills desde el alta.

---

## 6. Anexo · Campos mínimos del Registro (v1)

**AgentCard (shell)** — `id` · `nombre` · `descripción` (para recuperador) · `tags` · `examples` · `input/output` · `origen` (propio/tercero) · `clase` (Bloque A/B).

**Manifiesto de Brain Code** — `id` · `fuente` (persona/método) · `dominio` · `lentes/territorio` · `guardas CAL` · `confianza` · `confidencialidad` (interno/exportable) · `versión`.

**Composición desplegada (Sherpa Especializado)** — `asset_id` (SVA-…) · `shell × brain_code(s)` · `harness` (¿loop? tools/MCP) · `autonomía` (L0–L3) · `permiso/scope` · `estado_eval` · `tripleta` · `loop/proceso` · `versión` · `telemetría`.

---

**Ficha** · Tipo: PLAN · Entidad: XX · v01 · Creado 2026-06-20 · Owner: Victor Heredia · Sherpa: Jay · Ratificador: Victor Heredia (L3+) · Estado: Draft · listo para ejecución tras Gate F0

**Tags:** #plan #fuerza-laboral-agentica #F0 #F1 #registro #despachador