---
type: CP
asset_id: CP-XX-BMF-OntologiaSoftware-v01
version: v01
status: Propuesta canónica — para ratificación (Victor · L3+)
owner: Victor Heredia
sherpa_owner: Jay
ratificador: Victor Heredia (L3+)
fecha_creacion: 2026-07-10
intellbank: IB-XX-Maestro
subbank: IPI-XX-IP-Infraestructura / IPI-XX-BMF-Engine
proposito: Ontología canónica de la CAPA DE SOFTWARE del WORX OS — cómo se nombran, tipifican, empaquetan, distribuyen y gobiernan marketplaces, plugins, skills y comandos. Hermano de la Nomenclatura de Invocación (handles) y de la Arquitectura de Skills (upgrade).
relacionados:
  - CP-XX-BMF-NomenclaturaInvocacion (handles de invocación · carriles /wx /sk /ux /sx /sh /z)
  - CP-XX-BMF-ArquitecturaSkills-UpgradePipeline (tiers + upgrade ≠ migración)
  - CP-XX-BMF-RegistroAgentico (el catálogo vivo)
  - CP-XX-BMF-OntologiaAgentica (las 4 columnas Shell×BrainCode×Harness×Gobernanza)
tags: [CP, canonical, BMF, ontologia, software, marketplace, plugin, skill, procedencia, supply-chain]
---

# Ontología de la Capa de Software — WORX OS
## Canonical · v01 · 2026-07-10

## 0. Resumen ejecutivo
El WORX OS ya tiene una ontología rigurosa para sus **documentos** (BMF: `TIPO-ENTIDAD-Proyecto-Nombre-vNN`)
y para la **invocación** de sus agentes (carriles `/wx /sk /ux /sx /sh /z`). Le faltaba la ontología de su
**capa de software**: las piezas ejecutables (marketplaces, plugins, skills, comandos) no tenían identidad de
catálogo, así que no eran gobernables como los docs. Este documento la define, tratando cada pieza como un
**XAsset** sobre la misma espina BMF, y modela su distribución como una **cadena de suministro** con
procedencia y sello de auditoría.

> **Principio rector:** todo lo que el OS ejecuta debe ser tan direccionable y gobernable como todo lo que el OS escribe.

---

## 1. El principio: dos ejes (como en los documentos)
Cada pieza de software tiene **dos identificadores ortogonales**, igual que un doc tiene `asset_id` (frontmatter) y nombre de archivo:

| Eje | Qué es | Para qué sirve | Ejemplo |
|---|---|---|---|
| **Identidad de catálogo** (`asset_id`) | Nombre BMF estable | Registry, gobernanza, versión, procedencia | `SKL-EL-Sys-IBHealth-v02` |
| **Handle de invocación** | Alias runtime con carril | Cómo lo llama el usuario | `/sk-ibhealth` |

La Nomenclatura de Invocación gobierna el segundo eje. **Este documento gobierna el primero** (que hoy no existía).

---

## 2. Los cuatro TIPOs de software (extensión de BMF)

| TIPO | Qué es | Asset ID | Ejemplo |
|---|---|---|---|
| `MKT` | Marketplace (repo git contenedor) | `MKT-EL-<Nombre>-vNN` | `MKT-EL-WORXOS-v01` |
| `PLG` | Plugin (bundle distribuible) | `PLG-EL-<Nombre>-vNN` | `PLG-EL-Governance-v02` |
| `SKL` | Skill (unidad auto-disparable) | `SKL-<ENT>-<Dom>-<Nombre>-vNN` | `SKL-EL-Sys-IBHealth-v02` |
| `CMD` | Comando (slash, invocación explícita) | `CMD-<ENT>-<Dom>-<Nombre>-vNN` | `CMD-EL-Ops-ArrancaRoom-v01` |

- La **ENTIDAD** sigue la regla BMF: `EL` = EmpowerLabs; `XX` = canónico cross-org; **`Z` = externo aún no forjado** (ver §5).
- `MKT` y `PLG` no llevan `<Dom>` (agrupan varios dominios); `SKL` y `CMD` sí.

---

## 3. Los dos atributos gobernados: `funcion` y `dominio`
Son los "tipo y especialidad" de cada skill. Viven en el **frontmatter** (como los metadatos de un doc), no baked en el nombre invocable.

### `funcion` — qué HACE la pieza (vocab cerrado de 6)
| Función | Qué hace | Ejemplos |
|---|---|---|
| `Forge` | Produce activos (BCs, SVAs, skills) | sk-bcdistiller · sk-svagen · **wx-crea-skill** |
| `Gov` | Mantiene el sistema / el vault | sk-ibhealth · sk-bmfregistry · sk-vaultorphan |
| `Flow` | Ritmo / operación diaria | wx-arrancaroom · wx-mindia · wx-buzon |
| `Lens` | Analiza / diagnostica (solo lectura) | sk-ana · sk-next |
| `Mind` | Carga contexto / cognición | worx-core · worx-empowerlabs |
| `Ultra` | Súper asistente compuesto (board de BCs) | ux-midas · ux-tlaloc |

### `dominio` — a qué ÁREA sirve (vocab cerrado, reusa Nomenclatura + `sys`/`doc`)
`dgen · sales · prod · ops · kz · pub · gov · sys · doc · hr` (extensible con ratificación L3).

---

## 4. Portafolio de marketplaces (taxonomía por rol)
Múltiples marketplaces, cada uno un **estado de confianza**, no solo un contenedor.

| Marketplace | Rol | Contenido | Carril | ¿Cliente? |
|---|---|---|---|---|
| `MKT-EL-WORXOS` | **Producto** | plugins canónicos, shippables | `/wx-` | ✅ |
| `MKT-EL-Interno` | **Plomería** del equipo | utilidades internas | `/sk-` | ❌ |
| `MKT-EL-Biblioteca` | **Externos curados** | skills de repos abiertos, auditados y aprobados | `/z-` (→ `/sh-`) | según licencia |
| *(Cuarentena)* | **Staging** — no es marketplace instalable | externos crudos sin auditar | — | ❌ |

- **Cuarentena** es la banda de entrada (una rama/carpeta), **no se instala**. Solo lo auditado sube a Biblioteca.
- **Regla dura:** el equipo nunca instala directo de un repo público — solo de la Biblioteca curada (patrón *golden repo* / pull-through cache, estilo Artifactory/Nexus).
- Todos los marketplaces viven **FUERA** del vault Intellibanks (la sync corrompe dotfolders).

---

## 5. Ciclo de procedencia y madurez
La ENTIDAD del asset ID codifica la madurez — el destete es **legible en el nombre**.

```
Repo externo → Cuarentena → [AUDITORÍA · gate §6] → Biblioteca (SKL-Z-…, /z-, validado)
                                                          ↓ (opcional · upgrade)
                                        forjar con cognición + harness + gobernanza
                                                          ↓
                                        SVA-EL-… / SKL-EL-… (/sh- o /ux-) → Interno / Producto
```

| Madurez | ENTIDAD | Carril | Significado |
|---|---|---|---|
| `crudo` | (upstream) | — | recién bajado, en Cuarentena, sin auditar |
| `curado` | `Z` | `/z-` | auditado y aprobado; usable, pero "no es nuestro todavía" |
| `forjado` | `EL` | `/sh-` `/ux-` `/sk-` `/wx-` | reconstruido con cognición + gobernanza WORX |

> Consistente con `CP-XX-BMF-ArquitecturaSkills-UpgradePipeline`: **upgrade ≠ migración**. Pasar de `Z` a `EL` es upgrade (creación de valor), no re-aliasar.

---

## 6. El sello de auditoría (procedencia como dato, no promesa)
Todo `SKL`/`PLG` lleva en frontmatter su **hoja de procedencia** (mini-SBOM, estilo SLSA):

```yaml
origen:   externo-curado        # propio | externo-curado | externo-crudo
fuente:   github.com/org/repo    # de dónde vino (vacío si propio)
licencia: MIT                    # de su THIRD_PARTY_NOTICES
madurez:  curado                 # crudo | curado | forjado
estado:   activo                 # activo | deprecated | yanked
permisos:                        # manifiesto de menor privilegio (§7.2)
  escribe: [IB-EL-EmpowerLabs]
  red:     no
  borra:   nunca
auditoria:
  fecha:   2026-07-10
  por:     "@Alex"
  veredicto: aprobado
  version_auditada: v1.3.0
```

### La compuerta de auditoría (qué pasa un externo para subir a Biblioteca)
La corre `sk-skillaudit` (o `sk-ibhealth` extendido). Criterios:
1. Estructura válida (1 `SKILL.md`, frontmatter completo, plugin bien formado).
2. **Seguridad:** sin código malicioso, sin llamadas de red no declaradas, sin exfiltración.
3. Sin rutas muertas ni hardcode de sesión (guardrail de vault).
4. **Licencia** compatible, registrada.
5. Reclasificado a `/z-` con asset ID `SKL-Z-<Dom>-<Nombre>` + hoja de procedencia completa.
> Sin los 5, no sube. La aprobación queda **sellada y fechada** en `auditoria:`.

---

## 7. Patrones adoptados (de cadenas de suministro maduras)
Precedentes: Debian/Ubuntu (repos por confianza + canales de madurez), Artifactory/Nexus (golden repo),
CNCF (Sandbox→Incubating→Graduated), npm/crates.io (scopes, SemVer, yank), SLSA/Sigstore/SBOM (procedencia
firmada), App Stores / VS Code Marketplace (gate de revisión + catálogo empresarial).

### 7.1 Yank / deprecate  *(npm, crates.io)*
Estado formal para **retirar una versión mala** sin depender de desinstalación manual. `estado: yanked` +
auto-update → la quita sola. **Resuelve la clase entera de bugs "skill vieja que revive"** (caso Reinventaverse).

### 7.2 Manifiesto de permisos por skill  *(extensiones de browser, VS Code)*
Cada skill declara qué puede tocar (`escribe`, `red`, `borra`). Menor privilegio por defecto; la auditoría lo
verifica. **Cierra el tema de control de acceso cliente vs interno** que quedaba pendiente.

### 7.3 Canales de madurez opt-in  *(Debian stable vs edge)*
El equipo elige su canal: `stable` (solo forjado) o `edge` (incluye curado reciente). Un junior corre stable; un core corre edge.

### 7.4 Firma + log de transparencia  *(Sigstore/cosign)*
Cada plugin firmado; registro a prueba de manipulación de quién publicó qué. Da **verificación de integridad**
(alerta si la sync mutila un archivo).

### 7.5 CODEOWNERS por dominio  *(GitHub)*
Cada `dominio` tiene dueño que aprueba cambios a sus skills — la **tripleta** (Owner+Sherpa+Ratificador)
aplicada al código y automatizada en el gate.

---

## 8. Cómo se ata al ecosistema
- **Nomenclatura de Invocación** — provee el eje 2 (handles `/wx /sk /ux /sh /z`). Este doc provee el eje 1 (asset IDs).
- **Arquitectura de Skills / UpgradePipeline** — provee el motor `Z → EL` (upgrade). Este doc provee la identidad que ese motor transforma.
- **Registro Agéntico** — el catálogo vivo; cada `SKL/PLG/MKT` se registra ahí con su hoja de procedencia.
- **`/wx-crea-skill` (Forge)** — el creador estampa `asset_id + clase + funcion + dominio + procedencia`, valida contra el Registro, y coloca la skill en el plugin/marketplace correcto. **Este doc es su especificación de salida.**

---

## 9. Decisiones pendientes (Victor · L3)
1. Ratificar los **6 tipos de `funcion`** y el **vocab de `dominio`** (¿falta alguno? p. ej. `viz` para dashboards).
2. Confirmar **ENTIDAD `Z`** para externos (vs mantener upstream namespace).
3. Confirmar el set inicial de marketplaces (¿arrancamos con los 3 + Cuarentena, o WORXOS + Interno primero?).
4. Decidir si `sk-skillaudit` es skill nueva o módulo de `sk-ibhealth`.
5. Prioridad de adopción de los 5 patrones (recomiendo **yank** y **permisos** primero).

## Próximo paso
Con esto ratificado: (a) llevar `CP-XX-BMF-NomenclaturaInvocacion` a v02 citando este doc, y (b) construir
`/wx-crea-skill` que aplique esta ontología al crear cada skill.

---

**Ficha** · Tipo: CP (control plane) · Entidad: XX (canónico) · v01 · 2026-07-10 · Owner: Victor Heredia · Estado: Propuesta para ratificación L3
**Domain:** Agentic Architecture / Software Supply Chain / Governance
**Fuentes:** CP-XX-BMF-NomenclaturaInvocacion-v01 ◈ · CP-XX-BMF-ArquitecturaSkills-UpgradePipeline-v01 ◈ · CP-XX-BMF-OntologiaAgentica-v01 ◈
**Referencias externas:** Debian/Ubuntu repos · Artifactory/Nexus (golden repo) · CNCF maturity tiers · npm/crates.io (scopes·yank) · SLSA/Sigstore/SBOM · VS Code Marketplace

## CHANGELOG
| Versión | Fecha | Cambio |
|---|---|---|
| v01 | 2026-07-10 | Creación. Ontología de software: 4 TIPOs (MKT/PLG/SKL/CMD), ejes funcion+dominio, portafolio de marketplaces, ciclo de procedencia Z→EL, sello de auditoría, 5 patrones adoptados. |