---
type: CP
asset_id: CP-XX-BMF-MarketplaceGovernance-v01
version: v01
status: Activo — implementado (pieza del WORX OS)
owner: Victor Heredia
sherpa_owner: Jay
ratificador: Victor Heredia (L3+)
fecha_creacion: 2026-07-16
intellibank: IB-XX-Maestro
subbank: IPI-XX-IP-Infraestructura / IPI-XX-BMF-Engine
proposito: Sistema que gobierna y regula el marketplace de plugins/skills — registry (fuente de verdad) + gate (revisión automática) + proceso de release (build disciplinado). Elimina drift, duplicados y basura de raíz.
relacionados:
  - CP-XX-BMF-OntologiaSoftware-v01 (identidad de catálogo MKT/PLG/SKL/CMD)
  - PLAN-XX-IntelliBanks-GobernanzaIntegral-v01 (Pilar 2 — gobernanza de skills)
  - SPEC-EL-WORX-GitMarketplace-AutoUpdate-v01 (distribución git)
  - CP-EL-SkillsRegistry-v01 (registro humano de skills)
tags: [CP, canonical, BMF, marketplace, governance, registry, gate, release, supply-chain]
---

# Gobernanza del Marketplace — WORX OS
## Canonical · v01 · 2026-07-16 · IMPLEMENTADO

## 0. Por qué existe
Cada cambio hecho **a mano** al marketplace derivó en el mismo desorden: versiones desalineadas
(0.2.0 vs 0.2.2), plugins duplicados, zips de scratch regados, rutas muertas. **No es descuido de
una persona — es la ausencia de un proceso que lo impida.** Este sistema hace que el desorden sea
*imposible por construcción*: el marketplace se gobierna solo, con tres piezas que se validan entre sí.

> **Regla dura:** nada entra al marketplace sin (a) estar en el **registry**, (b) pasar el **gate**, (c) salir por el **proceso de release**. Aplica a todos — Victor, Alex, Jay, o cualquier operador.

---

## 1. Las tres piezas

### Pieza 1 — El Registry (la fuente de verdad)
`.claude-plugin/registry.json` en el repo del marketplace (**fuera del vault**). Para cada plugin:
versión, carril, si es cliente, comandos, y skills (con `asset_id`, `funcion`, `dominio`, `origen`,
`estado`). **Si algo no está en el registry, no existe para el marketplace.** El registry **manda**
sobre la versión — se acabó el "¿cuál tengo instalada?".

### Pieza 2 — El Gate (`sk-marketplace-audit`)
Skill en `worx-governance`. Contrasta **registry ↔ repo ↔ instalado** y verifica higiene. Corre en
**CI** (bloquea el push) y **on-demand**. Detecta: versión desalineada, plugin sin registrar, skill
duplicada, artefacto de sync, ruta de vault como destino, ruta personal hardcodeada, y **drift**
(instalado ≠ registry). Exit 1 = **no se publica**. Es solo lectura.

### Pieza 3 — El Proceso de Release (`scripts/release.sh`)
Un solo comando: **limpia → ensambla limpio (slim, sin evals, sin basura) → regenera el registry
desde el árbol limpio → corre el Gate → produce UN artefacto versionado → actualiza el registry.**
Usa un directorio temporal con auto-limpieza: **no deja scratch**. Si el Gate falla, no hay artefacto.

```
registry.json ──(verdad)──►  Gate  ◄──(compara)── repo + instalado
      ▲                        │
      └──(regenera)── release.sh ──► 1 artefacto (empowerlabs-plugins.zip)
```

---

## 2. Cómo previene cada falla que ya vivimos
| Falla histórica | Qué la impide ahora |
|---|---|
| "¿Tengo la 0.2.0 o la 0.2.2?" | Gate `--installed` reporta **drift** vs registry |
| 10 copias de un plugin en outputs | `release.sh` usa tmp con auto-limpieza → **1 artefacto** |
| Mismo plugin entregado suelto + en marketplace | Regla: **un solo artefacto** (el marketplace) |
| `sk-wikivalidator` apuntando a `LLM-Wiki/` muerto | Gate: **ruta de vault como destino** = violación |
| Version sin bump → no propaga | Gate: versión repo debe **= registry** (y el bump es explícito) |
| Skill metida a mano en el vault | Registry vive fuera del vault; skill sin registrar = **rechazada** |

---

## 3. Dónde vive cada cosa (regla de ubicación)
- **Registry, Gate-script, release.sh, CI** → en el **repo git del marketplace** (fuera del vault). Se versiona con los plugins.
- **Este spec (CP)** y el registro humano (`CP-EL-SkillsRegistry`) → en el **vault** (son documentos de gobernanza, no código).
- **Plugins/skills** → nunca en el vault. Siempre en el repo/outputs.

---

## 4. El flujo del día a día
1. Editas una skill/plugin en el **repo** (nunca el caché, nunca el vault).
2. Subes `version` en el `plugin.json` que cambió.
3. `bash scripts/release.sh . ./dist` → regenera registry, corre el Gate, produce el zip.
4. `git commit && git push`. El **CI corre el Gate** otra vez y bloquea si algo está mal.
5. El equipo recibe el update (auto-update). El Gate `--installed` confirma que nadie quedó en drift.

---

## 5. Gobernanza y roles
- **Gate y release**: automáticos, solo lectura / build. Nadie los salta.
- **Bump de versión y registro**: quien edita (con la tripleta Owner+Sherpa+Ratificador del dominio).
- **Levantar un bloqueo del Gate**: decisión humana del owner de dominio (no se fuerza el push).
- **Cadencia**: Gate en **cada** release (obligatorio) + **semanal** (drift del equipo, vía `sk-ibhealth`/`sk-marketplace-audit`).

---

## 6. Integración con el WORX OS
- Es la implementación operativa del **Pilar 2** del `PLAN-XX-IntelliBanks-GobernanzaIntegral` (regular la capacidad, no solo el contenido).
- Consume la **identidad de catálogo** de `CP-XX-BMF-OntologiaSoftware` (TIPOs, funcion, dominio, procedencia).
- Se apoya en `sk-skillvalidator` (valida UNA skill a fondo) — el Gate es el nivel **conjunto** (marketplace).
- Distribución por el repo git de `SPEC-EL-WORX-GitMarketplace-AutoUpdate`.

## 7. Estado de implementación (2026-07-16)
- [x] `registry.json` generado (5 plugins, poblado con estado real).
- [x] `sk-marketplace-audit` (Gate) construido y probado — detecta drift, duplicados, basura, rutas de vault.
- [x] `release.sh` + `gen_registry.py` — pipeline que no deja scratch, probado end-to-end.
- [x] CI `Marketplace Gate` (GitHub Action) que corre el Gate en cada push.
- [x] Empaquetado en `worx-governance` v0.4.0.
- [ ] **Pendiente Victor/Alex:** subir el repo con estos scripts + activar el CI en `EmpowerlabsLLC/empowerlabs-plugins`.

---

**Ficha** · Tipo: CP · Entidad: XX (canónico) · v01 · 2026-07-16 · Owner: Victor · Estado: Activo/implementado
**Domain:** Software Supply Chain / Governance · **Fuentes:** CP-XX-BMF-OntologiaSoftware-v01 ◈ · PLAN-XX-IntelliBanks-GobernanzaIntegral-v01 ◈

## CHANGELOG
| Versión | Fecha | Cambio |
|---|---|---|
| v01 | 2026-07-16 | Creación + implementación: registry.json, sk-marketplace-audit (Gate), release.sh, CI. Sistema que gobierna el marketplace de raíz. |