---
type: PG
asset_id: PG-MTX-CasosVivos-v01
version: v01.1
status: Reestructurada a plantilla canónica — 🔒 interna
owner: Juan Carlos Angeles Ramírez
verificado_por: JuanCarlosX
verificado_fecha: 2026-07-22
intellibank: IB-MTX-MatriX
nodo_map: "8.4"
exposicion: "🔒 interna (no pública)"
fuente_canonica: CAS-*-* del LabPraxis (casos operacionales vivos de EmpowerLabs)
nodo_grafo: "No tiene nodo propio (es ingeniería interna)"
base: PLAN-MTX-MatriX-MasterPlan-v01 §2.3 (anatomía canónica)
---
# Casos Vivos: Rebelocity · MTE
## 1 · Tarjeta resumen
> **¿Qué es en una frase?** La documentación de cómo el ecosistema se aplica en clientes y equipos reales: qué pasó, qué funcionó, qué se quebró y qué aprendimos.
> **Familia:** D8 · Ingeniería interna — el espejo de la realidad en MatriX
> **Metáfora:** la bitácora de vuelo, no el manual del avión: registra lo que de verdad pasó en el aire, incluidas las turbulencias.
## 2 · Nivel 1 · 🌱 Esencial
Los Casos Vivos documentan cómo MatriX y el ecosistema WORX se aplican en clientes y equipos reales. No son tutoriales — son espejos de lo que pasó: qué funcionó, qué se quebró, qué aprendimos.
Cada caso alimenta el LabPraxis (el banco de aprendizajes operativos), y el LabPraxis retroalimenta MatriX. Si un caso descubre un problema que la wiki no prevé, se agrega como issue y entra a la siguiente versión.
Ese ciclo es lo que mantiene a MatriX viva. Una wiki sin casos reales se vuelve teoría; una con casos se corrige sola.
El caso más maduro hoy es Rebelocity (instalación de WORX OS en su equipo de producto). Hay dos casos más en construcción y uno futuro (MTE).
Regla de oro: si pasó en producción y nos enseñó algo, se documenta como caso. Lo que no se captura, se pierde.
## 3 · Nivel 2 · 🛠 Implementador
**Estructura canónica de un caso (`CAS-XX-Nombre-vN`):**
- **Nombre & ID:** CAS-XX-Nombre-vN (ej: CAS-22-Rebelocity-Onboarding-v01)
- **Contexto:** quién (empresa/equipo), cuándo (fecha), qué intentaban (objetivo)
- **Configuración:** qué versión de WORX usaban, qué fases completaron (F0-F5), qué especialistas/skills activaron
- **Hallazgos:** qué pasó (bien y mal), métricas de entrada/salida
- **Bloqueadores:** dónde se atascaron (si se atascaron)
- **Mejoras:** qué cambios hicieron para desatascarse
- **Lecciones:** qué llevamos a MatriX de este caso
- **Replicabilidad:** ¿funciona solo para este cliente o es patrón?
**Ciclo de integración:** caso → LabPraxis → issue en MatriX → siguiente versión de la página afectada. La skill `sk-labpraxis` es la herramienta de captura.
## 4 · Nivel 3 · 🔬 Ingeniería — INTERNO
**CAS-22-Rebelocity-Onboarding-v01 (activo):**
- **Equipo:** Rebelocity (empresa de movilidad urbana, 45 personas). **Objetivo:** instalar WORX OS en equipo de producto (F0-F5 completo en 40 días).
- **Hallazgos:** Fase 2 (Kernel) tardó 3 semanas (vs. 2-4 esperadas). Razón: reconciliación de expectativas — cada subequipo creía que ya operaba "su versión" de WORX.
- **Bloqueador:** naming. Usaban nombres ad-hoc ("el frente de X", "el comité Y"); WORX exigía naming canónico (TIPO-ENTIDAD-Proyecto-vN). Costó retraining.
- **Mejora:** se creó `/ux-diseno` (especialista de dirección de arte) con ejemplos de naming en vivo. Aceleró la adopción.
- **Lección:** no basta documentar naming — hay que vivenciarlo. Los especialistas cognitivos aceleran adopción.
- **Replicabilidad:** SÍ. "F2 se extiende por reconciliación de expectativas" es patrón común: agregar 1 semana de buffer a F2 si el equipo ya tiene culturas locales.
**CAS-27-Rally-Inducción-vXX (EN CONSTRUCCIÓN):** cómo se entrena a operadores con WORX Way (Rally de 40 días). Owner: TBD — Victor por asignar. Bloquea la confirmación del Rally (Task #1).
**CAS-28-SOP-Soporte-Técnico-vXX (EN CONSTRUCCIÓN):** cómo opera el soporte a distancia. Owner: Juan Carlos. Fuente: `SOP-EL-JuanCarlos-SoporteTecnicoRemoto-v01` (v01.2, checklist ejecutado 22-jul).
**Caso futuro — MTE:** scope por definir (Victor + equipo).
## 5 · Casos de uso
1. **Un implementador prepara su segundo cliente.** Lee CAS-22 antes de arrancar: sabe que F2 puede extenderse por choque de culturas locales y presupuesta 1 semana de buffer desde el día uno.
2. **Un patrón de falla se repite en dos clientes.** Se documenta como caso, el LabPraxis lo eleva a principio (como P023), y la página de MatriX afectada se corrige en su siguiente versión.
3. **Un consultor evalúa si WORX es prometible.** Los casos vivos son la evidencia: no "confía en nosotros", sino "esto pasó en Rebelocity, así se resolvió, esto es patrón replicable".
## 6 · Verifica tu comprensión
1. **¿Qué diferencia a un Caso Vivo de un tutorial?**
Ver respuesta
El tutorial dice cómo debería hacerse; el caso documenta lo que de verdad pasó — incluidos bloqueos, errores y cómo se resolvieron. Es espejo, no receta.Ver respuesta
El naming: pasar de nombres ad-hoc al canónico costó retraining. Se resolvió creando /ux-diseno con ejemplos de naming en vivo — vivenciarlo aceleró la adopción más que documentarlo.Ver respuesta
Cada caso alimenta el LabPraxis; si descubre algo que la wiki no prevé, se vuelve issue y entra a la siguiente versión de la página afectada. Sin ese ciclo, MatriX sería teoría estática.