---
type: MI
asset_id: MI-EL-WORXOS-Coordinacion-Benchmark-v01
version: v01
tipo: MI — Market Intelligence (benchmark 2026 de la capa de coordinación)
status: Draft · Fase 2 del TP-EL-WORXOS-CapaCoordinacion-Fable-v03 · pendiente ratificación Victor (L3+)
owner: Victor Heredia
sherpa: Jay/Fable
ratificador: Victor Heredia
intellibank: IB-EL-EmpowerLabs
subbank: PB-EL-Project-Bank/PB-WORX-Worx
fase: F2 de 5 (Investigación de mercado 2026)
tp_madre: TP-EL-WORXOS-CapaCoordinacion-Fable-v03
insumo: MAP-EL-WORXOS-CoordinacionEstadoActual-v01 (F1 · ratificado)
metodo: >
  Búsqueda web fresca (2026-07-08) en 7 categorías: (1) orquestación multi-agente / agent OS
  organizacional, (2) torres de control y gobernanza de agentes a escala, (3) protocolos
  A2A/MCP/ACP, (4) inbox AI-native y async estructurado, (5) notificación sin interrupción,
  (6) canales externos gobernados (Telegram/WhatsApp), (7) arquitectura de datos SSOT +
  proyecciones (categoría añadida por hallazgo G2 del F1). Fuentes enlazadas por claim.
fecha_creacion: 2026-07-08
tags: [MI, benchmark, worx-os, capa-coordinacion, multi-agente, control-tower, a2a, mcp, inbox, notificaciones, event-sourcing, 2026, F2]
---

# MI · Benchmark 2026 — Capa de Coordinación WORX OS
## Qué hace el mercado, qué copiamos, qué adaptamos, qué evitamos — mapeado a R1–R14

> **Regla de lectura.** Cada categoría cierra con veredicto copiar/adaptar/evitar. La matriz consolidada (§8) mapea todo a los requerimientos `[R#]` del TP madre §4. La tesis del benchmark está en §9: el mercado 2026 valida cada pieza del diseño WORX por separado — nadie las tiene juntas sobre un sustrato de archivos gobernado por método.

---

## §1 · Orquestación multi-agente / "organizational agent OS"

**Estado del mercado.** La categoría maduró de pilotos a plataforma: Google Gemini Enterprise Agent Platform ofrece desarrollo+orquestación+gobernanza end-to-end con **gestión de identidad por agente y simulación pre-despliegue**; IBM presentó en Think 2026 su "AI Operating Model" (watsonx Orchestrate multi-agente + Concert + Sovereign Core). Los frameworks dominantes: LangGraph (grafos deterministas), Microsoft Agent Framework (AutoGen+Semantic Kernel convergidos), CrewAI (agentes por rol), Google ADK (árboles jerárquicos con A2A).

**El dato que importa:** solo una fracción pequeña de organizaciones reporta gobernanza de agentes madura; la falta de auditabilidad ya es **deployment blocker** en industrias reguladas. El mercado vende orquestación; la brecha reconocida es gobernanza — exactamente donde WORX ya es fuerte (tripleta, L0–L3, INV-02).

**Veredicto:** ADAPTAR el patrón "identidad por agente + simulación antes de producción" (mapea directo al Cap 19 y al wargame F5). EVITAR adoptar un framework de orquestación pesado como centro — el sustrato WORX es el vault, no un runtime de grafos; los frameworks son implementación posible de módulos, no la arquitectura. → `[R3][R8][R14]`

## §2 · Torres de control y gobernanza de agentes a escala

**Estado del mercado.** "AI Control Tower" ya es categoría con producto: ServiceNow integró observabilidad profunda (adquisición de Traceloop, mar-2026) con monitoreo runtime continuo, detección de instrucciones maliciosas y **kill switch por agente**; Covasant vende Agent Control Tower como AgentOps. En open source, la figura "mission control" está estandarizada: tablero único con task boards, aprobaciones HITL enrutadas, audit log completo, trust scores por agente. El **agent inventory/register** se consolida como pieza núcleo: documento versionado con cada clase de decisión del agente, su tier de autonomía, racional y criterios — la referencia autoritativa para auditorías. Regulación empuja: EU AI Act (Art. 14) y NIST AI RMF exigen supervisión humana demostrable y medible. El patrón HITL maduro es **arquitectónico, no reactivo**: el sistema sabe cuándo interrumpir (≈95% rutina autónoma / 5% interrupt de alto riesgo), no el humano revisando todo.

**Veredicto:** COPIAR el agent inventory como documento versionado (WORX ya lo tiene a medias: tripleta + Registry; falta el registro por-agente con clases de decisión y tiers — conecta con el hallazgo F1 del roster no-canónico). COPIAR kill switch por agente como requisito de la SPEC F4. ADAPTAR el HITL arquitectónico al vocabulario L0–L3 unificado que pidió Victor. → `[R3][R5][R6][R12][R14]`

## §3 · Protocolos agente-a-agente: A2A / MCP / ACP

**Estado del mercado.** El stack se consolidó en un modelo de dos capas que ya es arquitectura de referencia: **MCP para agente↔herramienta, A2A para agente↔agente**. ACP (IBM) se fusionó dentro de A2A (sept-2025); los tres viven bajo el Linux Foundation — el hecho estructural más importante de 2026: ya no hay guerra de protocolos. Google ADK, Agentforce y ServiceNow implementan ambos.

**Veredicto:** COPIAR la apuesta MCP-native (ya ratificada en el MAP SOO: curar conectores, no fabricarlos). ADAPTAR A2A como *referencia semántica* para el protocolo SherpaX↔SherpaX de F4 (agent cards, descubrimiento, tareas con estado) — pero la transport layer de EmpowerLabs sigue siendo el vault (bus MSG-): A2A-sobre-archivos, gobernado, no A2A-sobre-HTTP entre demonios que no existen. EVITAR inventar un protocolo propietario incompatible con la semántica A2A: cuando el WorX OS producto necesite interoperar, la traducción debe ser directa. → `[R3][R5][R8]`

## §4 · Inbox AI-native y async estructurado

**Estado del mercado.** El giro 2026 es de asistente pasivo a **agente activo**: el inbox lee, clasifica, redacta y enruta, y deja todo **staged para revisión humana antes de enviar**. Cora (salió de beta feb-2026, lista de espera de ~10K) es el patrón más limpio: triage autónomo que comprime el inbox en **briefs dos veces al día** con respuestas pre-redactadas — no un cliente más rápido (Superhuman) sino menos sesiones de inbox. Shortwave representa el AI-native sobre Gmail (resúmenes de hilo, búsqueda, voz aprendida).

**El patrón complementario:** LangChain **Agent Inbox** — interfaz tipo Gmail donde el humano revisa interrupts de agentes con 4 respuestas tipadas (`approve / reject+mensaje / edit / respond`), sobre checkpoints durables: el agente queda pausado días sin consumir cómputo y resume donde quedó; umbrales auto-aprueban lo menor y enrutan lo mayor.

**Veredicto:** COPIAR el brief-digest estilo Cora como el modo de entrega del buzón (el `arrancaroom` ya es un digest natural — formalizarlo: resumen priorizado + borradores, no lista de mensajes). COPIAR las 4 respuestas tipadas del Agent Inbox como el vocabulario de acciones del humano ante acciones de agentes (hoy el buzón tiene leído/aceptar/responder/cerrar para mensajes humanos; falta el equivalente para *acciones propuestas por agentes*). ADAPTAR el interrupt durable: el vault ya ES un checkpoint durable — un MSG- `estado: propuesto` es un interrupt pausado sin infraestructura nueva. EVITAR el chat en tiempo real y el inbox como lugar donde vive el trabajo (principio WORX: mensaje efímero, trabajo durable en XDoc). → `[R1][R2][R7][R9]`

## §5 · Notificación sin interrupción

**Estado del mercado.** La crisis es cuantificada: el empleado enterprise promedio ya recibe ~146 notificaciones/día y los agentes amenazan con sumar 30–50 más; interrupciones cada ~2 minutos (Microsoft) y ~23 minutos para recuperar foco profundo (UC Irvine). Las respuestas que funcionan: **digest/batching agresivo** (una secuencia de acciones de agente = un resumen, no play-by-play; Braze reporta +35% engagement y −28% opt-out con digests) y el principio 2026: *"act on what matters, alert on what requires judgment"*.

**Veredicto:** COPIAR digest-first como política canónica de notificación de la capa (valida el diseño original del buzón: la notificación al abrir room ES un digest batch — el mercado llegó a donde WORX empezó). COPIAR la regla de mérito: solo interrumpe lo que requiere juicio humano según nivel de autonomía; todo lo demás espera al digest. EVITAR push por evento — traiciona C1 (Deep Work) y es la política que el propio mercado está desmontando. → `[R9][R10][R14]`

## §6 · Canales externos gobernados (Telegram / WhatsApp / móvil)

**Estado del mercado.** Meta restringió en 2026 los chatbots de propósito general en WhatsApp; los bots de **tarea específica y estructurada** (servicio, pedidos, citas) siguen permitidos — un bot de dispatch WORX (recibir/aceptar/cerrar mensajes tipados) cae del lado permitido. El problema técnico reconocido: los agentes proliferan sin inventario central ni identidades claras; la respuesta emergente es el **identity control plane unificado** — humanos, service accounts, bots, tokens y agentes bajo una sola capa de identidad con RBAC, auditoría y DPA. Requisitos estándar: encriptación, logs de conversación auditados, restricción de dominio, proceso de borrado.

**Veredicto:** ADAPTAR: el canal externo entra en fase 2 (como ya dice el TP) y solo como *espejo del bus MSG-* — el mensaje externo se convierte en MSG- gobernado en la frontera, con identidad verificada contra el roster canónico; nunca escritura directa al vault. COPIAR el principio de identity plane único: el roster canónico de operadores+agentes (hallazgo F1) es la semilla; cada identidad externa (número de WhatsApp, chat_id de Telegram) se registra contra una identidad del roster. EVITAR bots de propósito general en el canal (además de riesgo, viola política Meta 2026). → `[R9][R10][R11][R12]`

## §7 · Arquitectura de datos: SSOT + proyecciones (categoría añadida por G2)

**Estado del arte (estable, no moda 2026).** El problema "la verdad se bifurcó entre el canónico y sus vistas" tiene solución de manual: **event sourcing + projections/materialized views**. El log de eventos es la única fuente de verdad; las vistas son estado **derivado y efímero** que se puede borrar y reconstruir re-jugando los eventos. La disciplina clave: las vistas NUNCA se editan directamente — se regeneran.

**Traducción al vault (la lección para F3):** no hace falta un event store en base de datos; hace falta la **disciplina del patrón** sobre archivos: (a) todo cambio de estado de un frente/NEXT/mensaje se escribe primero en su canónico (el "evento"); (b) los dashboards se regeneran SIEMPRE desde canónicos por scanner (patrón Buzón, generalizado); (c) editar un dashboard a mano queda prohibido por SOP — es exactamente como se bifurcó Frentes (G2: el HTML se editó a mano hasta rebasar al CP-). El changelog que ya llevan los CP- es un event log embrionario.

**Veredicto:** COPIAR la disciplina write-canónico→regenerar-proyección como ley de la capa (la "Regla #1" del TP madre, ahora con mecánica). COPIAR "proyección corrupta se reconstruye, no se repara". ADAPTAR: el scanner generate-on-write del Buzón es la implementación de referencia a generalizar a Frentes/Week/HOY/Torre. EVITAR live-data como default: regeneración por evento de escritura da frescura suficiente con complejidad mínima (la decisión live vs generate-on-write del TP §5 se responde: **generate-on-write generalizado, live solo donde un caso lo justifique**). → `[R4][R5][R6][R7]`

---

## §8 · Matriz consolidada copiar / adaptar / evitar → R#

| # | Práctica de mercado | Veredicto | R# | Nota de implementación |
|---|---|---|---|---|
| 1 | Agent inventory/register versionado (clases de decisión + tier + racional) | ✅ COPIAR | R3 R5 R12 | Nuevo activo F4: registro canónico de operadores+agentes; resuelve roster no-canónico (F1 §6.5) |
| 2 | Kill switch por agente + monitoreo runtime (ServiceNow/Traceloop) | ✅ COPIAR | R3 R12 | Requisito duro de la SPEC agente-a-agente; ya anticipado en wargame F5 |
| 3 | HITL arquitectónico (el sistema sabe cuándo interrumpir; ~95/5) | 🔄 ADAPTAR | R3 R9 R14 | Expresarlo en el vocabulario de autonomía unificado (decisión Victor: "unifiquemos") |
| 4 | Stack dos capas MCP (herramientas) + A2A (agentes) · Linux Foundation | 🔄 ADAPTAR | R3 R8 | Semántica A2A sobre transporte vault (bus MSG-); MCP-native ya ratificado (MAP SOO) |
| 5 | Simulación/pre-deployment testing de agentes (Gemini Enterprise) | 🔄 ADAPTAR | R3 R14 | El wargame F5 es la versión metodológica; formalizar como gate de la SPEC |
| 6 | Brief-digest de triage 2×/día con borradores (Cora) | ✅ COPIAR | R1 R2 R9 | El digest de `arrancaroom` evoluciona a brief priorizado con borradores staged |
| 7 | 4 respuestas tipadas a interrupts: approve/reject/edit/respond (Agent Inbox) | ✅ COPIAR | R3 R7 | Vocabulario del humano ante propuestas de agentes; extiende el ciclo MSG- actual |
| 8 | Interrupt durable sobre checkpoint (pausa de días sin cómputo) | 🔄 ADAPTAR | R3 R4 | MSG- `estado: propuesto` en el vault = interrupt durable nativo; sin infra nueva |
| 9 | Digest/batching como política de notificación (+35% engagement) | ✅ COPIAR | R9 | Canoniza el diseño original del buzón; política por nivel de autonomía |
| 10 | Identity control plane unificado (humanos+bots+agentes+tokens) | ✅ COPIAR | R11 R12 | Roster canónico único con identidades externas registradas contra él |
| 11 | Bot externo de tarea específica (permitido por Meta 2026) como espejo del bus | 🔄 ADAPTAR | R10 R11 | Fase 2; conversión en frontera a MSG- gobernado; nunca escritura directa |
| 12 | Event sourcing: SSOT + proyecciones derivadas regenerables | ✅ COPIAR | R4 R5 R7 | Ley de la capa: write-canónico→regenerar; scanner Buzón = referencia a generalizar |
| 13 | Mission control open-source (task boards + aprobaciones + audit + trust scores) | 🔄 ADAPTAR | R6 R12 | Referencia de UX para la Torre; construir sobre kit EL-DashboardStandard, no adoptar plataforma |
| 14 | Framework pesado de orquestación como centro del sistema (LangGraph/CrewAI como núcleo) | ❌ EVITAR | R8 R14 | El centro es el vault + método; frameworks solo como implementación puntual de módulos |
| 15 | Push por evento / chat tiempo real como canal de coordinación | ❌ EVITAR | R9 R14 | Traiciona C1/deep work; el mercado mismo migra a digest |
| 16 | Live-data como default de tableros | ❌ EVITAR | R7 | Generate-on-write generalizado; live solo con caso justificado |
| 17 | Protocolo propietario incompatible con semántica A2A | ❌ EVITAR | R3 R8 | Costo de interop futuro del producto WorX OS |
| 18 | Bot de propósito general en WhatsApp | ❌ EVITAR | R11 | Violación de política Meta 2026 + superficie de ataque |

**Cobertura R#:** R1(6) · R2(6) · R3(1,2,3,4,5,7,8,17) · R4(8,12) · R5(1,2,12) · R6(13, y vía 12) · R7(7,12,13,16) · R8(4,14,17) · R9(3,6,9,15) · R10(11) · R11(10,11,18) · R12(1,2,10,13) · R13(sin práctica de mercado directa — editar/borrar auditado se hereda del patrón event-log #12) · R14(3,5,14,15).

---

## §9 · Tesis del benchmark (síntesis para F3)

1. **El mercado valida el diseño WORX pieza por pieza — y llega tarde a donde WORX empezó.** Async-first, digest sobre push, HITL, trabajo durable fuera del chat: cada principio del buzón/TP base es hoy best practice reconocida. La asimetría de EmpowerLabs no es tecnológica: es que la gobernanza (tripleta, L0–L3, Gate G0) ya está *instalada como método* mientras el mercado la vende como feature.
2. **La brecha #1 del mercado es la misma que la de EmpowerLabs: la capa integradora.** Todos venden piezas (orquestador, tower, inbox, protocolo); la gobernanza madura es escasa y bloquea despliegues. La Torre de Control WORX no compite con ServiceNow — compite con el caos, y llega con la gobernanza resuelta de origen.
3. **No hay que construir casi nada exótico.** Las 5 decisiones de arquitectura que el mercado ya tomó por nosotros: MCP+A2A como semántica estándar · agent inventory versionado · kill switch+HITL arquitectónico · digest-first · SSOT+proyecciones regenerables. F3 es ensamblarlas sobre el vault, no inventarlas.
4. **La respuesta a la pregunta abierta del TP §5 (live vs generate-on-write):** generate-on-write generalizado con el scanner del Buzón como patrón de referencia. Es la implementación vault-native del patrón proyecciones/materialized views — y previene estructuralmente la recurrencia del G2.

---

## §10 · Fuentes

**C1 Orquestación:** [Viston · Enterprise AI Orchestration 2026](https://viston.tech/enterprise-ai-orchestration-solutions-in-2026-building-scalable-multi-agent-systems-for-business-operations/) · [IBM Think 2026 · AI Operating Model](https://newsroom.ibm.com/2026-05-05-think-2026-ibm-delivers-the-blueprint-for-the-ai-operating-model-as-the-ai-divide-widens) · [Coworker · AI Agent Orchestration Platforms 2026](https://coworker.ai/blog/ai-agent-orchestration-platform) · [Codebridge · Multi-Agent Orchestration 2026](https://www.codebridge.tech/articles/mastering-multi-agent-orchestration-coordination-is-the-new-scale-frontier)
**C2 Control towers/gobernanza:** [ServiceNow agent kill switches (The Register)](https://www.theregister.com/software/2026/05/05/servicenow-adds-agent-kill-switches-to-ai-control-tower/5228579) · [ServiceNow AI agent governance (CX Today)](https://www.cxtoday.com/security-privacy-compliance/servicenow-ai-agent-governance-knowledge-2026/) · [Covasant Agent Control Tower](https://www.covasant.com/blogs/enterprise-ai-governance-with-covasant-ai-agent-control-tower) · [Strata · HITL 2026](https://www.strata.io/blog/agentic-identity/practicing-the-human-in-the-loop/) · [AgixTech · HITL Enterprise Blueprint](https://agixtech.com/insights/how-to-design-human-in-the-loop-for-ai-agent-systems-the-enterprise-blueprint/) · [VDF · Enterprise AI Agent Vendor Landscape 2026](https://vdf.ai/blog/enterprise-ai-agent-vendor-landscape-2026/)
**C3 Protocolos:** [Zylos · Agent Interoperability Protocols 2026](https://zylos.ai/research/2026-03-26-agent-interoperability-protocols-mcp-a2a-acp-convergence/) · [Zuplo · MCP, A2A, and Where ACP Went](https://zuplo.com/blog/agent-protocol-stack-mcp-a2a-acp-2026) · [OneReach · A2A Explained 2026](https://onereach.ai/blog/what-is-a2a-agent-to-agent-protocol/)
**C4 Inbox AI-native:** [Missive · AI email assistants 2026](https://missiveapp.com/blog/ai-email-assistant) · [Cora (tooldirectory)](https://tooldirectory.ai/tools/cora) · [Carly · Cora alternatives 2026](https://www.usecarly.com/blog/cora-alternatives/) · [LangChain Agent Inbox (GitHub)](https://github.com/langchain-ai/agent-inbox) · [LangChain · Human-in-the-Loop docs](https://docs.langchain.com/oss/python/langchain/frontend/human-in-the-loop) · [Abstract Algorithms · LangGraph HITL](https://www.abstractalgorithms.dev/langgraph-human-in-the-loop)
**C5 Notificación:** [Courier · Notification Fatigue 10x Worse](https://courier-com.medium.com/notification-fatigue-is-about-to-get-10x-worse-60c151909440) · [Courier · 7 estrategias anti-fatiga](https://www.courier.com/blog/how-to-reduce-notification-fatigue-7-proven-product-strategies-for-saas) · [ProductivePatty · Batch digests](https://www.productivepatty.com/maximizing-productivity-batch-notification-digests-for-focus/)
**C6 Canales externos:** [Alibaba Cloud · WhatsApp AI policy 2026](https://www.alibabacloud.com/help/en/chatapp/use-cases/whatsapp-ai-policy-2026-guide) · [ServiceNow · Enterprise Identity Control Plane](https://www.servicenow.com/blogs/2026/enterprise-identity-control-plane-is-here) · [The Hacker News · AI agents inside the perimeter](https://thehackernews.com/2026/05/your-ai-agents-are-already-inside.html) · [FastBots · Chatbot security 2026](https://blog.fastbots.ai/ai-chatbot-security-and-data-privacy-what-businesses-need-to-know-before-you-deploy/)
**C7 SSOT/proyecciones:** [AWS · Event sourcing pattern](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/event-sourcing.html) · [Azure · Event Sourcing](https://learn.microsoft.com/en-us/azure/architecture/patterns/event-sourcing) · [Azure · Materialized View](https://learn.microsoft.com/en-us/azure/architecture/patterns/materialized-view) · [Event-Driven.io · Projections & read models](https://event-driven.io/en/projections_and_read_models_in_event_driven_architecture/)
**Mission control OSS:** [Builderz Mission Control](https://github.com/builderz-labs/mission-control) · [agent-fleet-o](https://github.com/escapeboy/agent-fleet-o)

---

## §11 · Esquema agent-readable

```yaml
mi: MI-EL-WORXOS-Coordinacion-Benchmark-v01
fase: F2
tp_madre: TP-EL-WORXOS-CapaCoordinacion-Fable-v03
insumo: MAP-EL-WORXOS-CoordinacionEstadoActual-v01
categorias_investigadas: 7  # 6 del TP + SSOT/proyecciones (añadida por G2)
copiar:
  - agent_inventory_versionado: {r: [R3, R5, R12], resuelve: roster_no_canonico_F1}
  - kill_switch_por_agente: {r: [R3, R12]}
  - brief_digest_triage_con_borradores: {r: [R1, R2, R9], referencia: Cora}
  - respuestas_tipadas_interrupt: {r: [R3, R7], vocabulario: [approve, reject, edit, respond]}
  - digest_batching_politica_notificacion: {r: [R9], evidencia: "+35% engagement / −28% opt-out"}
  - identity_plane_unificado: {r: [R11, R12]}
  - ssot_mas_proyecciones_regenerables: {r: [R4, R5, R7], ley: "write-canónico → regenerar; proyección no se edita, se reconstruye"}
adaptar:
  - hitl_arquitectonico_95_5: {r: [R3, R9, R14], al: vocabulario_autonomia_unificado}
  - a2a_semantica_sobre_transporte_vault: {r: [R3, R8], nota: "A2A-sobre-archivos vía bus MSG-"}
  - simulacion_pre_deployment: {r: [R3, R14], via: wargame_F5_como_gate}
  - interrupt_durable_como_msg_propuesto: {r: [R3, R4]}
  - bot_externo_espejo_del_bus: {r: [R10, R11], fase: 2, frontera: "conversión a MSG- gobernado"}
  - mission_control_ux: {r: [R6, R12], sobre: kit_EL-DashboardStandard}
evitar:
  - framework_orquestacion_como_centro
  - push_por_evento_y_chat_tiempo_real
  - live_data_como_default
  - protocolo_propietario_incompatible_a2a
  - bot_proposito_general_whatsapp
decisiones_que_este_mi_responde:
  live_vs_generate_on_write: "generate-on-write generalizado (patrón scanner Buzón); live solo con caso justificado"
tesis: >
  El mercado valida cada principio WORX por separado y reconoce como brecha #1 la
  gobernanza integrada — que EmpowerLabs ya tiene como método. F3 = ensamblar 5
  decisiones ya maduras del mercado sobre el vault, no inventar tecnología.
r13_nota: "editar/borrar auditado sin práctica de mercado directa; se hereda del patrón event-log (#12)"
```

---

## §12 · NEXTs

- [ ] **NEXT[@Victor]:** ratificar este MI (F2) para desbloquear F3.
- [ ] **NEXT[@Jay]:** registrar este activo en el IntelliBanks Registry al cierre de fase.

## §13 · Changelog

| Versión | Fecha | Cambio |
|---|---|---|
| v01 | 2026-07-08 | Creación. Fase 2 del TP madre: benchmark fresco 2026 en 7 categorías (6 del TP + SSOT/proyecciones añadida por el hallazgo G2 de F1), 18 prácticas en matriz copiar/adaptar/evitar mapeadas a R1–R14 con cobertura completa, respuesta a la pregunta live vs generate-on-write, tesis de asimetría competitiva y fuentes enlazadas por categoría. Doble registro (prosa + YAML). |