---
type: DC
asset_id: DC-EL-Req-TipoXDoc-Definicion-v01
version: v01
status: Active · definición canónica · Pendiente Ratificación Victor
owner: Victor Heredia
sherpa: Jay
fecha_creacion: 2026-06-25
intellbank: IB-EL-EmpowerLabs
subbank: EQ-EL-Equipo
proposito: Define el tipo de XDoc `Req-` (Request) — una solicitud formal uno-a-muchos. Es un documento durable que se ENGANCHA al sistema de buzón existente (no lo duplica): notifica vía MSG- y registra/da seguimiento vía → NEXT[@Persona].
referencia_canonica:
  - TP-EL-WORX-ComunicacionAsincrona-SherpaX-v01 (protocolo del buzón · MSG- + NEXT)
  - BZ-EL-Buzon/ (carpeta de mensajes) · BRD-EL-Buzon-Dashboard-v01 (dashboard)
  - DC-XX-WORX-TaxonomiaXDoc-v01 (registrar Req- como tipo)
tags: [dc, req, request, xdoc, buzon, msg, next, uno-a-muchos, worx]
---

# Tipo `Req-` · XDoc de Solicitud formal

## Qué es y cómo encaja (sin duplicar el buzón)

Un `Req-` es una **solicitud formal de una persona a una o varias** (uno-a-muchos), lo bastante grande como para merecer su propio documento durable (varios entregables, varios responsables, seguimiento).

**No es un sistema nuevo de mensajería.** Se monta sobre lo que ya existe:

| Capa | Mecanismo canónico | Rol del `Req-` |
|---|---|---|
| **Notificación** (efímera) | `MSG-` en `BZ-EL-Buzon/` (tipo `delegar`/`informar`) | El `Req-` genera un `MSG-` que avisa a los `para: [@handles]`. |
| **Registro/seguimiento** (durable) | `→ NEXT[@Persona]` en el XDoc · lo cosecha `next-scanner` | El `Req-` incluye un `NEXT[@responsable]` por entregable. |
| **El documento de la solicitud** | — | El `Req-` mismo: descripción, entregables, reparto, bitácora. |

> Regla: un NEXT suelto o un MSG- bastan para pedir algo pequeño. El `Req-` es para solicitudes formales con varios entregables/responsables que conviene documentar.

## Naming + Folio

- **Naming:** `Req-[ENTIDAD]-[Slug]-vNN`.
- **Folio:** letra de empresa + 3 dígitos. **E** EmpowerLabs · **R** Rebelocity · **C** Clientes · **X** Metodología. Ej. `R001`.

## Campos canónicos

| Campo | Qué es |
|---|---|
| **folio** | Letra de empresa + 3 dígitos (ej. `R001`). |
| **solicitante** | `{ humano, sherpa }` — quién pide. |
| **asignados** | `[@handles]` — uno o varios destinatarios. |
| **fecha_solicitud / fecha_objetivo** | Cuándo se pidió / para cuándo. |
| **prioridad** | ⚪ / 🟡 / 🔴 / ★★. |
| **estatus** | 📥 Solicitada · 🔄 En progreso · ⏸️ En espera · ✅ Resuelta · ❌ Cancelada. |
| **buzon_msg** | El `MSG-` que notifica este Req-. |
| **NEXTs** | Un `→ NEXT[@Persona]` por entregable (registro durable). |
| **Seguimiento** | Bitácora de respuestas (fecha · @autor). |

## Flujo

1. Se crea el `Req-` (documento durable) con sus entregables y un `→ NEXT[@Persona]` por responsable.
2. Se genera un `MSG-` tipo `delegar` en `BZ-EL-Buzon/` dirigido a los `@handles` → aparece en el **dashboard del buzón**.
3. Cada responsable lo ve al abrir su room (`arrancaroom`), responde en **Seguimiento**, y su NEXT aparece en la pestaña "NEXTs del equipo" del Semanal.
4. Al entregar: estatus ✅ y se cierra el `MSG-` (se archiva); el rastro durable queda en el `Req-` y sus NEXTs.

---

## CHANGELOG

| Versión | Fecha | Cambio |
|---|---|---|
| v01 | 2026-06-25 | Creación en Intellibanks. `Req-` definido como solicitud formal que se **engancha** al buzón existente (MSG- para notificar, NEXT para registrar) en vez de duplicarlo. Folio E/R/C/X. |