--- tipo: TP entidad: EL proyecto: WORX nombre: Dev version: v01 ultima_actualizacion: 2026-04-22 owner: Victor Heredia sponsor: Victor Heredia runners: - Jay (orquestación) room: WORX-Dev tipo_doc: Transfer Pack — activación de room genera_xpack: XP-EL-WORX-Dev-v01 (a construir dentro del room como primer NEXT) --- # TP — WORX-Dev Transfer Pack para activar el room **WORX-Dev**: espacio dedicado a diseñar, construir y operar la propia arquitectura del modelo WORX (tipos, taxonomía, gobernanza, mecanismos de freshness). --- ## 1. Propósito del room **WORX-Dev** es el room donde se diseña y construye la metodología WORX misma. No es un room de aplicación (Posta, Marcovich, Tecnogen) — es el room donde se resuelven las decisiones arquitectónicas que gobiernan todos los demás rooms. Sub-rooms futuros esperados (numeración/especificación): - `WORX-Dev-Taxonomia` — familia de tipos (XDoc · XPack · TP · XD nuevo) - `WORX-Dev-Freshness` — mecanismo BrainOS validador de XPacks - `WORX-Dev-Governance` — protocolo de actualización XPack por room - `WORX-Dev-...` (otros a definir) --- ## 2. Contexto de arranque ### 2.1 El gap detectado hoy (2026-04-22) Victor abrió el tema en el TP-MultiFrente-21abr: > "El problema que estoy viendo es que de un room a otro y de un proyecto a otro ya hay olvido. Nuestro punto principal de que se recuerda el asunto ya no se recuerda. El XP- XPack en otro room no se hizo correctamente porque la gobernanza no es real." **Diagnóstico preliminar:** - El XPack (XP-) se canonizó el 2026-04-21 como "documento vivo del proyecto". - En la práctica, los rooms no están actualizando sus XPacks de manera consistente. - Resultado: la continuidad cognitiva — **promesa de valor #1 de SherpaX** — no se está cumpliendo estructuralmente. ### 2.2 Arquitectura operativa clarificada - **Room** = espacio para uso específico (diseñar, construir, operar). - **XPack (XP-)** = paquete que rige el room/proyecto. Trae información reciente del proyecto sin tener que consultar toda la gobernanza global. Es el shortcut de contexto localizado. - **TP (TP-)** = snapshot de transferencia generado desde el XPack (o para activar rooms nuevos). - **Regla de oro:** el XPack es la fuente, el TP es la vista derivada. ### 2.3 Hallazgo secundario — confusión de tipos XD-/XP- Hoy 2026-04-22 Jay creó `XD-EL-WORX-RedaccionMPBModeloOperativo-v01.md` que debería haber sido `XP-EL-WORX-RedaccionMPBModeloOperativo-v01.md`. El error reveló una ambigüedad: existe el **XDoc** (átomo conceptual — plantilla de 7 secciones) pero también se nombró archivos `XD-` como si fuera una familia de tipos. Pregunta abierta: ¿XD- es una familia nueva, un alias de XP-, o no existe como tipo de archivo? --- ## 3. Agenda inicial del room ### Tema 1 — Gobernanza real del XPack (urgente) - ¿Por qué los XPacks no se están actualizando en los rooms? - ¿Qué disparador fuerza la actualización? (cierre de sesión, NEXT ejecutado, milestone) - ¿Quién es el owner del ciclo de actualización — humano, agente, protocolo? ### Tema 2 — Familia de tipos (Taxonomía X-) - XDoc = átomo/plantilla (7 secciones) — ¿queda solo como concepto, sin prefijo de archivo? - XPack (XP-) = doc vivo de proyecto/room — ya canonizado. - TP (TP-) = snapshot transferencia — ya canonizado. - XD- = ¿nuevo tipo o no existe? - Otros candidatos que puedan aparecer. ### Tema 3 — BrainOS como validador de freshness (propuesta de Victor) BrainOS/WORX OS verifica recurrentemente que cada XPack activo esté al día. Mecanismo a diseñar: - Detectar thoughts de un proyecto sin reflejo en su XPack. - Alertar cuando un XPack lleva N días sin cambios pero hay señal capturada. - Protocolo de auto-sync o prompt de actualización. ### Tema 4 — Primer caso meta-recursivo Este mismo room WORX-Dev debe tener su propio XPack (`XP-EL-WORX-Dev-v01`) y operarlo bajo las reglas que está diseñando. Es el primer caso de "XPack gobernando su propia gobernanza" — candidato a caso LabPraxis al cierre. --- ## 4. Señales previas relevantes (desde BrainOS) - `[gap crítico | 2026-04-22]` — "Gobernanza XPack no es real en la práctica" (thought capturado hoy por Jay a petición de Victor). - `[diseño | 2026-04-22]` — "BrainOS como validador de FRESHNESS del XPack" (idea de Victor, capturada hoy). - `[milestone | 2026-04-21]` — XPack canonizado como nuevo tipo de documento; primer caso: `XP-REB-Sponsorship5150-2026-v01` creado y cerrado el mismo día. - `[naming | 2026-04-19]` — Rename WERK → WORX aplicado globalmente. ## 5. Documentos ancla - `MePB-XX-XPack-Schema-v01.md` — esquema canónico del XPack (Clase C, registry #605). - `MPB-EL-WORX-ModeloOperativo-v01.md` §4 — definición del átomo XDoc. - `PLB-EL-WORX-FlujoKanban-v01.md` — primer Playbook WORX (lado Sprint pendiente). - `MIN-VH-20Abril2026-v01.md` §21-abr-1 — canonización del XPack. - `XD-EL-WORX-RedaccionMPBModeloOperativo-v01.md` — doc mal tipificado (a corregir como primer NEXT). ## 6. NEXT al arrancar el room - [ ] Generar `XP-EL-WORX-Dev-v01.md` como doc vivo del room (primer NEXT obligatorio). - [ ] Renombrar y reestructurar `XD-EL-WORX-RedaccionMPBModeloOperativo-v01.md` → `XP-EL-WORX-RedaccionMPBModeloOperativo-v01.md` (secciones al schema XPack: BRIEF · ESTADO · ASSETS · NEXT · DISCUSSION · CHANGELOG · CIERRE). - [ ] Abrir Tema 1 (Gobernanza XPack) en primera sesión. - [ ] Decidir si XD- es familia, alias o no existe. - [ ] Spawnear sub-rooms si los temas lo ameritan (WORX-Dev-Taxonomia primero). ## 7. Ubicación y registro - **Ubicación física:** `IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-WORX-Worx/` - **Registry:** registrar en `CP-XX-IntelliBanks-Registry-v01.md` al cierre de la primera sesión del room. - **LLM-Wiki:** crear página `XPack.md` y actualizar `WORX.md` cuando se canonicen decisiones. --- *TP generado 2026-04-22 desde TP-VH-MultiFrente-21abr2026-v01 para spawnear room WORX-Dev.*