# MePB-EL-WORX-RallyQA-UsuarioCero-v01
## Sistema de validación del Rally de Inducción WORX mediante simulación de usuario nuevo ("Usuario Cero")

**Tipo:** MePB (Metodología) · **Entidad:** EL · **Proyecto:** WORX · **Versión:** v01 (propuesta, pendiente de ratificación)
**Autor:** Juan Carlos (con SherpaX) · **Fecha:** 2026-07-15
**Origen:** CASO 027 y CASO 028 del `CAS-EL-WORX-LabPraxis-BancoCasos-v01`
**Objeto validado:** `BRD-EL-RallyWORX-Onboarding-v01` (8 misiones) y sus versiones futuras

---

## 1. Propósito

Los casos 027 y 028 demostraron que las brechas del Rally **no son visibles desde el diseño** — solo aparecen al correrlo como operador real sin contexto tácito. Este sistema institucionaliza esa detección: un agente de IA (SherpaX en modo QA, o subagente dedicado) simula ser un usuario genuinamente nuevo, recorre el Rally de punta a punta, y produce un reporte de fricción reproducible **antes** de que cada versión del Rally llegue a un usuario humano.

El principio rector es el P023 emergente (Contexto Prerequisito Explícito): en cada paso, el Rally solo puede exigir conocimiento que ya entregó.

## 2. La persona: Usuario Cero

Un solo perfil, el caso más exigente. El agente simulador opera bajo un contrato de conocimiento estricto:

**Lo que SÍ sabe:**
- Usar una computadora a nivel básico (abrir carpetas, abrir archivos, copiar/pegar)
- Conversar con un asistente de IA (Cowork/Claude) a nivel principiante
- Únicamente lo que el Rally le ha entregado explícitamente **hasta el paso actual** (texto leído en misiones ya completadas)

**Lo que NO sabe (y tiene prohibido usar):**
- Qué es "el vault", dónde vive, o que la carpeta se llama `Intellibanks`
- Las 3 acepciones de "Intellibanks" (app / carpeta raíz / carpetas `IB-*`)
- El catálogo de Tipos (`TIPO-`), la convención de naming, o cualquier término WORX (SherpaX, XDoc, room, sello, tripleta, C1–C5) antes de que el Rally lo defina
- Cualquier contexto de EmpowerLabs, del equipo, o de conversaciones previas

**Regla de oro anti-fuga:** si el agente resuelve un paso usando conocimiento que el Rally no le entregó, eso NO cuenta como éxito — cuenta como hallazgo (el paso depende de contexto tácito). El agente debe declarar en cada paso *de dónde* obtuvo cada pieza de conocimiento que usó (trazabilidad de contexto).

## 3. La rúbrica: 4 compuertas por paso

En cada actividad de cada misión (M1–M8), el simulador evalúa cuatro compuertas, derivadas directamente de los patrones de los casos 027 y 028:

| Compuerta | Pregunta | Origen |
|---|---|---|
| **G1 — Contexto prerequisito** | ¿Todo lo que este paso exige saber ya fue entregado por el Rally en un paso anterior? | CASO 028 / P023 |
| **G2 — Señal inequívoca** | ¿Cada término, nombre y referencia apunta a una sola realidad sin ambigüedad? (ej. WikiX-EL-Hub vs WikiX-Hub; "Intellibanks" ×3) | CASO 027-2, 028-2 |
| **G3 — Mecanismo funcional** | ¿La herramienta/botón/comando funciona en TODOS los contextos donde el Rally puede correrse? (ej. "+ Compartir" fuera de Cowork) | CASO 027-1 |
| **G4 — Sello mide comprensión** | ¿La validación del sello puede pasarse sin haber entendido? ¿Mide comprensión real o solo clics? | CASO 014, 027, 028-3 |

Cada compuerta se califica: ✅ Pasa · 🟡 Fricción (se resuelve pero con esfuerzo/confusión innecesaria) · 🔴 Bloqueo (el Usuario Cero no puede continuar sin ayuda externa o contexto tácito).

## 4. Protocolo de simulación

**Paso 0 — Preparación (rol: operador del QA, no el simulador)**
1. Congelar la versión del Rally a validar (board + skills/comandos que invoca: `/arrancaroom`, `/mindia`, `/resumenroom`, etc.)
2. Verificar que los documentos que el Rally referencia existen en el vault
3. Instanciar el agente simulador con el contrato de conocimiento de la sección 2 como su único contexto inicial

**Paso 1 — Recorrido misión por misión (rol: Usuario Cero)**
Para cada misión M1–M8, el simulador:
1. Lee ÚNICAMENTE la instrucción de la misión tal como la ve un usuario nuevo
2. Narra en primera persona qué entiende, qué intenta hacer, y dónde duda
3. Ejecuta las actividades usando solo conocimiento entregado (con trazabilidad: "esto lo sé porque M2 me lo dijo")
4. Califica las 4 compuertas
5. Registra tiempo/esfuerzo relativo y toda pregunta que tuvo que hacerse a sí mismo

**Paso 2 — Verificación de comprensión (anti-"sello de clics")**
Al sellar cada misión, un segundo rol (el SherpaX evaluador, no el simulador) hace 2–3 preguntas de comprensión sobre el fundamento que la misión debía instalar. Si el simulador selló pero no puede responder, G4 = 🔴 para esa misión. Esto separa "completó el mecanismo" de "entendió el fundamento".

**Paso 3 — Reporte**
El simulador produce `QA-EL-RallyWORX-UsuarioCero-AAAAMMDD-vNN` con:
- Matriz 8 misiones × 4 compuertas con calificación
- Lista de hallazgos, cada uno con: misión, actividad, compuerta, severidad, evidencia (cita textual de la instrucción problemática), y propuesta de corrección
- Veredicto global: ¿un usuario nuevo real termina el Rally entendiendo los fundamentos de WORX sin ayuda externa? SÍ / SÍ CON FRICCIÓN / NO

**Paso 4 — Cierre al LabPraxis**
Los hallazgos 🔴 nuevos (no duplicados de casos abiertos) se documentan como casos CAS- vía `sk-labpraxis`. Los 🟡 se acumulan como candidatos a la siguiente versión del Rally.

## 5. Criterio de aceptación de una versión del Rally

Una versión del Rally (ej. v02) se considera lista para usuarios reales cuando la simulación arroja: cero compuertas 🔴, y G4 = ✅ en las 8 misiones (todo sello refleja comprensión verificada). Las 🟡 se toleran documentadas, con owner y destino de versión.

## 6. Cuándo se corre

- **Obligatorio:** antes de liberar cualquier versión nueva del Rally (v02 en adelante) — es el gate de salida
- **Recomendado:** después de cualquier cambio a las skills que el Rally invoca (`/arrancaroom`, `/mindia`, `/resumenroom`, `wx-arrancaworx`), porque el Rally hereda sus brechas
- **Complemento, no sustituto:** la simulación no reemplaza la corrida humana ocasional (como la de JC del 2026-07-14); la simulación detecta secuenciación, ambigüedad y mecanismo, pero un humano detecta fricción emocional y de motivación que el agente no siente

## 7. Implementación técnica (fase siguiente, si se ratifica)

- Empaquetar como skill del plugin worx-governance (nombre propuesto: `sk-rallyqa`), invocable con "valida el rally", "corre el usuario cero", "QA del rally"
- La skill instancia un subagente con el contrato de Usuario Cero como único system context, le entrega el board misión por misión, y un segundo pase evalúa comprensión (Paso 2)
- Los botones/mecanismos HTML del board (sellos, "+ Compartir", "estoy trabajando") que el subagente no puede clickear se validan por inspección del código del board + prueba en contexto real (Cowork sí/no), y se reportan en G3 con esa salvedad

## 8. Límites conocidos

- El agente no puede clickear el board HTML como humano: G3 se valida por inspección de código y prueba contextual, no por interacción real de UI
- Un LLM simulando ignorancia puede "filtrar" conocimiento previo; la regla de trazabilidad (sección 2) mitiga pero no elimina el riesgo — por eso la corrida humana sigue siendo complemento
- La simulación valida comprensión de fundamentos, no formación de hábito (el reflejo `/arrancaroom` real solo se observa en operación posterior)

---

## THREAD

→ NEXT[@Victor]: Ratificar esta metodología (o ajustar rúbrica/criterio de aceptación) antes de construir `sk-rallyqa`.
→ NEXT[@Jay]: Revisar que las 4 compuertas cubran los hallazgos de CAS 027/028 y el patrón "sello mide clics" de CAS 014.
→ NEXT[@JuanCarlos]: Al ratificarse, correr la primera simulación contra el Rally v01 como línea base, y contra la v02 como gate de salida.

---

*MePB-EL-WORX-RallyQA-UsuarioCero-v01.md · EmpowerLabs / WORX · 2026-07-15*
*Propuesta derivada de CAS-027 y CAS-028 · Pendiente de ratificación*