---
type: ARQ
asset_id: ARQ-EL-WORXOS-CapaCoordinacion-v01
version: v01
tipo: ARQ — Arquitectura de la Capa de Coordinación Inteligente del WORX OS (to-be)
status: Draft · Fase 3 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: F3 de 5 (Diseño de la capa)
tp_madre: TP-EL-WORXOS-CapaCoordinacion-Fable-v03
insumos:
  - MAP-EL-WORXOS-CoordinacionEstadoActual-v01 (F1 · ratificado — 8 primitivas, 5 gaps, 5 insumos)
  - MI-EL-WORXOS-Coordinacion-Benchmark-v01 (F2 — 18 prácticas copiar/adaptar/evitar)
decisiones_ratificadas:
  - "Unifiquemos (Victor 2026-07-08): un solo vocabulario de autonomía + una sola arquitectura que mapee PS↔TP"
  - "Generate-on-write generalizado como default de tableros (respuesta F2 a pregunta abierta TP §5)"
gobernanza: L2 (diseño) · todo cambio a fuente de verdad o arquitectura BMF escala L3+
proposito: >
  Diseño to-be de la Capa de Coordinación Inteligente: un solo sistema en 3 planos
  (Inteligencia · Lógica · Interfaz) sobre BMF, que convierte las 8 primitivas existentes
  en una capa integrada — sin duplicar la verdad, con el humano en el mando, y con el
  Buzón como módulo. Insumo directo de F4 (SPECs por módulo + blueprint edge-first).
fecha_creacion: 2026-07-08
tags: [ARQ, worx-os, capa-coordinacion, to-be, tres-planos, autonomia-unificada, torre-de-control, conciencia-org, bmf, buzon, F3]
---

# ARQ · Capa de Coordinación Inteligente del WORX OS
## Un solo sistema en 3 planos, sobre las 8 primitivas que ya existen

> **Tesis de diseño.** No se construye un sistema nuevo — se construye la capa que las 8 primitivas de F1 no tienen: un **modelo de verdad único** (Lógica), un **servicio que ve el todo** (Inteligencia) y una **superficie de mando** (Interfaz). El 80% del material ya existe; el diseño es ensamblaje gobernado, fiel al canon: *"Una herramienta se usa. Un actor se gobierna."* — y las personas nunca salen del mando.

---

## §0 · Las 7 leyes de la capa (restricciones de diseño, no aspiraciones)

1. **Ley de la verdad única.** Todo estado tiene UN canónico. Las proyecciones (dashboards, briefs, OrgState) se **regeneran** desde canónicos; nunca se editan a mano. Una proyección corrupta se reconstruye, no se repara. *(F2 #12 · previene G2.)*
2. **Ley del actor gobernado.** Todo agente que actúa tiene identidad registrada, nivel de autonomía asignado, tripleta y kill switch. *"El agente actúa. El humano responde. Esa línea no se borra nunca."*
3. **Ley del humano sobre el loop.** Los humanos diseñan el marco en el que los agentes deciden solos, e intervienen solo cuando importa. HITL arquitectónico: el sistema sabe cuándo interrumpir (por nivel de autonomía), no el humano vigilando todo.
4. **Ley del deep work.** Nada interrumpe por evento. Digest-first: solo interrumpe lo que requiere juicio humano ahora; todo lo demás espera al brief del `arrancaroom`. *(F2 #9, #15.)*
5. **Ley del mensaje efímero.** El mensaje avisa; el trabajo durable vive en XDocs (espina NEXT) y el pipeline en LoopX. La capa coordina, no almacena trabajo.
6. **Ley del sustrato.** La capa vive sobre el vault y BMF. Ningún framework externo es el centro; los frameworks son implementación puntual de módulos. *(F2 #14.)*
7. **Ley del edge.** La capa se instala frente por frente (Cap 18), nunca big bang. Cada módulo debe poder ganar en un solo frente antes de contagiarse.

---

## §1 · Arquitectura unificada — el mapeo PS ↔ TP (decisión "unifiquemos")

Las dos arquitecturas conceptuales del vault se funden en UNA. Nombres canónicos de componentes a partir de este ARQ:

| Componente canónico (nuevo) | Era en el Problem Statement (abr-26) | Es en el modelo 3 planos (TP jul-26) | Qué es |
|---|---|---|---|
| **OrgPulse** | Activity Pulse Layer (APL) | Plano Inteligencia · conciencia del sistema `[R1]` | El scanner org-level: agrega frentes+NEXTs+MSG+LoopX+actividad de agentes en un snapshot canónico agent-readable (`OrgState`) |
| **Motor de Síntesis** | Synthesis Engine (SE) | Plano Inteligencia · triage/ruteo/alertas `[R2]` | La inteligencia sobre el OrgPulse: síntesis en lenguaje natural, detección de frentes estancados, siguiente-mejor-acción, ruteo |
| **O-IB** | Organizational IntelliBank | Ya existe: IntelliBanks + Registry | Sin construcción nueva — es el vault gobernado actual |
| **Puente de Gobernanza** | Governance Bridge (GB) | Encaje BMF `[R8]` | Herencia directa: naming, Registry, tripleta, INV-01…07, MEL. Se materializa en el **Registro Agéntico** (§3) |
| **OrgX** | Org-Sherpa | Plano Interfaz · el agente de la Torre `[R6]` | El SherpaX cuya "persona" es la organización: responde preguntas transversales sobre el OrgState, nunca sobre BrainOS individuales |
| **Torre de Control** | (implícita: interlocución CEO) | Plano Interfaz `[R6][R7]` | La superficie única: BRD- hub sobre la constelación, con OrgX embebido |
| **Buzón** | (no existía) | Módulo de mensajería `[R9–R13]` | El bus MSG- actual + el salto de nivel del TP Buzón, como módulo de esta capa |
| **Publication Protocol** | Reto 1 · dos carriles (D1) | Plano Lógica · frontera privado/org | Se conserva intacto: carril automático (decisiones, compromisos, estados) + carril propuesto (SherpaX propone, humano aprueba). El BrainOS personal jamás fluye crudo |

**Regla de nombres:** los términos del PS quedan como linaje histórico; los documentos nuevos usan los nombres canónicos de esta tabla.

---

## §2 · Vocabulario de autonomía unificado (decisión "unifiquemos")

**Un solo eje de autonomía** — el del canon (Cap 19, verbatim), que ya es el de WORX:

| Nivel | Canon | Operación en la capa |
|---|---|---|
| **L0** | Sugiere | El agente solo propone. Toda salida es borrador/sugerencia. |
| **L1** | Ejecuta con aprobación | Interrupt ANTES de actuar. El humano responde con el vocabulario tipado: `aprobar / rechazar+razón / editar / responder`. *(F2 #7.)* |
| **L2** | Ejecuta y reporta | Actúa solo; deja rastro en el log y aparece en el digest. Ventana de reversión. |
| **L3** | Ejecuta y solo escala la excepción | Actúa solo; solo interrumpe ante excepción definida. Reservado a patrones probados en wargame/piloto. |

**Mapeo de los otros dos vocabularios (quedan absorbidos):**

- **LoopX (autónomo / opt-out / decisión humana)** → L2 / L1 con ventana de objeción (variante L1-opt-out: ejecuta si nadie objeta en el plazo) / L1 estricto. El gravity×valor de LoopX se conserva como **función de asignación de nivel** — es la regla que decide qué L le toca a cada acción, no otra escala.
- **Permisos del PS (L1–L3 Operativo/Directivo/Estratégico)** → se renombran a **vistas de acceso**: `V-OP` (operativo: mis frentes/proyectos) · `V-DIR` (directivo: mi área + cruces) · `V-EST` (estratégico: todo — CEO/Victor). El prefijo V- elimina la colisión con los L de autonomía.

**Asignaciones iniciales de la capa** (heredan el TP base §9 y quedan por confirmar en F4): informar = L2 · delegar en frente propio = L2 · delegar a frente ajeno = L1 (NEXT nace `propuesto`) · pasar-balón = L1 con ratificación senior · SherpaX↔SherpaX = **L1 estricto (HITL)** hasta pasar wargame · asesoría UltraSherpaX = L0 SIEMPRE (el consejo jamás ejecuta) · reconciliación de canónicos = escala a Victor (L3+ de gobernanza documental, distinto eje).

---

## §3 · Plano LÓGICA — el modelo de verdad `[R4][R5]`

### 3.1 Los canónicos y sus proyecciones (contrato explícito)

| Dominio | Canónico (se escribe aquí PRIMERO) | Proyecciones (se regeneran, jamás se editan) |
|---|---|---|
| Portafolio de frentes | `CP-EL-FrentesTablero` | BRD-Frentes · Torre · OrgState |
| Trabajo durable | XDocs (espina `→ NEXT[@X]`) | Pestaña NEXTs · Week · Torre · OrgState |
| Mensajería | Archivos `MSG-` en BZ-EL-Buzon | BRD-Buzón · digest arrancaroom · OrgState |
| Pipeline | LoopDocs + XDocs `XD-EL-Loop-*` | LoopX dashboards · Torre · OrgState |
| Identidades y autonomía | **Registro Agéntico** (nuevo: `CP-EL-RegistroAgentico-v01`) | Torre (panel admin) · validación de frontera externa |
| Cadencia | Minutas TeamSync | WeekDashboards |
| Activos | IntelliBanks Registry | — |

**Relación entre canónicos: hermanas con contrato, no derivadas.** Frentes, XDocs, MSG y LoopX son 4 verdades de dominios distintos; el contrato de sync entre ellas es el **conjunto de puentes automáticos** (3.3). El `OrgState` NO es una quinta verdad: es la proyección agregada de las cuatro.

### 3.2 El Registro Agéntico (nuevo canónico — cierra F1 §6.5 y F2 #1)

Un solo documento versionado con **toda identidad que actúa en el sistema**: humanos (roster único: los 8+ alias del buzón + estado WORX del Frentes tablero, reconciliados), SherpaX personales, UltraSherpaX, OrgX, scanners/skills con escritura, e identidades externas fase-2 (WhatsApp/Telegram registradas contra una identidad interna). Por agente: clases de decisión que puede tomar · nivel L por clase · tripleta · estado (activo/suspendido = **kill switch documental**: un agente suspendido no pasa validación de ningún scanner). Es la materialización del Puente de Gobernanza y del "agent inventory" que el mercado reconoce como pieza núcleo.

### 3.3 Los puentes automáticos (generalización del patrón P8)

El único puente que existe (MSG aceptar→NEXT) se generaliza a una familia, todos con el mismo patrón *evento en canónico A → escritura gobernada en canónico B → regeneración de proyecciones*:

1. **MSG→NEXT** (existe): aceptar delegar/revisar escribe el NEXT; cerrar lo tacha.
2. **NEXT→Frente**: cerrar un NEXT crítico listado en el bloque del frente lo actualiza en `CP-EL-FrentesTablero` (con entrada de changelog). Alta de NEXT crítico = L1 (propuesto al owner del frente).
3. **Frente→OrgState**: todo cambio en el CP- dispara regeneración del OrgState y del BRD-Frentes. **La edición manual del BRD- queda prohibida por SOP** (la causa raíz de G2).
4. **LoopX→OrgState**: cambios de estado en LoopDocs/XDocs de loop entran al snapshot.
5. **Minuta→Frente** (cierre semanal): el sync que hoy hace Jay a mano se vuelve checklist asistida del ritual `weekly-sync`, con diff propuesto (L1) en lugar de edición libre.

**Trazabilidad end-to-end `[R5]`:** cada eslabón lleva el ID del anterior: el NEXT creado por un MSG- anota `(vía MSG-EL-…)`; la entrada de changelog del frente anota el NEXT; el OrgState referencia todo por Asset ID. La cadena mensaje→NEXT→frente→decisión se reconstruye con grep — auditable sin base de datos.

### 3.4 El OrgState (la proyección maestra)

`OUT-EL-OrgState-vLIVE.md` — snapshot agent-readable (YAML) regenerado por OrgPulse: frentes con estado/prioridad/NEXTs vivos · NEXTs por persona con antigüedad · mensajes activos por estado · pipeline LoopX resumido · actividad de agentes (últimas N acciones del log) · divergencias detectadas (¿proyección más nueva que su canónico? ¿NEXT huérfano? ¿MSG sin responder > umbral?). Es **lo que cualquier SherpaX carga en `arrancaroom`** para tener conciencia org-level — el fin de las 6 islas con un solo archivo.

---

## §4 · Plano INTELIGENCIA `[R1][R2][R3]`

### 4.1 OrgPulse (el servicio de conciencia)

Generalización del scanner del Buzón (la implementación de referencia según F1/F2): un runner vault-native que lee los 4 canónicos + el log agéntico y regenera OrgState + proyecciones. Corre **on-write** (tras cada puente automático) y **on-open** (en `arrancaroom`). No es demonio permanente — es la misma economía de sesiones del sistema actual, y es suficiente: la frescura del sistema es la frescura de su último evento.

### 4.2 Motor de Síntesis (lo que lo hace inteligente, no solo visible)

Sobre el OrgState, cuatro capacidades — las cuatro del PS Reto 4, ahora con mecánica:

- **Brief del operador** (evolución Cora del digest `arrancaroom`): estado priorizado + mensajes con **borradores de respuesta staged** + siguiente-mejor-acción sugerida (L0). `[R1][R2]`
- **Detección de anomalías:** frente sin movimiento > umbral, NEXT vencido, divergencia canónico/proyección, patrón cruzado ("3 frentes mencionan al mismo bloqueador"). Salen en el digest, no como push. 
- **Triage y ruteo** (L0→L1): un mensaje/insumo nuevo se rutea al frente correcto usando el Frentes tablero + estado LoopX; la asignación es sugerencia hasta que el patrón pruebe precisión.
- **Consulta transversal vía OrgX:** "¿qué está pasando esta semana?" respondido desde OrgState + canónicos — el reporte de status que nadie redacta. Acceso según vista (V-OP/V-DIR/V-EST).

### 4.3 Agente-a-agente gobernado `[R3]`

- **SherpaX↔SherpaX:** sobre el bus MSG- existente con semántica A2A adaptada *(F2 #4)*: el Registro Agéntico hace de "agent card" (qué sabe hacer cada agente, qué nivel L tiene); un SherpaX puede *proponerle* trabajo a otro con MSG- `de.sherpa` sin humano remitente → **siempre L1**: el humano del destinatario ve la propuesta en su brief y responde con el vocabulario tipado. Sin loops posibles: un MSG- generado por agente no puede generar otro MSG- de agente sin interrupt humano intermedio (regla anti-enjambre, a estresar en F5).
- **Humano→UltraSherpaX (asesoría hilada):** nuevo tipo de mensaje `asesoria` — la consulta y la respuesta del UltraSherpaX viajan como MSG- hilados, **marcados L0 estructuralmente**: el frontmatter lleva `caracter: consejo-no-orden` y ningún puente automático acepta un MSG- `asesoria` como origen de NEXT ejecutable; convertir consejo en trabajo exige que un humano cree el delegar. *(Barandal directo contra la célula R1 del wargame.)*
- **SherpaTeamsX:** entra como *equipo con una sola identidad en el Registro Agéntico* y un humano responsable (EmpowerTeamX). Su orquestación interna es caja del equipo; su frontera con la capa es la misma que la de cualquier agente: MSG-, niveles L, log. La capa no orquesta adentro del team — gobierna su borde.

---

## §5 · Plano INTERFAZ `[R6][R7]`

### 5.1 Torre de Control (`BRD-EL-Torre-v01`)

El hub de la constelación, construido sobre el kit `EL-DashboardStandard-v01` (la semilla ya existente): panel de frentes (drill-down frente→NEXTs→mensajes→refs, cruzando canónicos vía OrgState) · bandeja de interrupts pendientes (todo lo que espera un humano, con los 4 botones tipados) · pulso de agentes (últimas acciones del log + estado del Registro Agéntico + kill switch visible) · anomalías del Motor de Síntesis · acceso por vista V-OP/V-DIR/V-EST. **OrgX embebido** vía `sendPrompt()` (patrón ya probado en el dashboard Buzón): la Torre no solo muestra — conversa.

### 5.2 Estándar de tableros: generate-on-write generalizado

Decisión cerrada por F2: todos los BRD- migran al patrón scanner (datos entre markers, regeneración por evento, `sendPrompt()` para acciones que persisten vía SherpaX). El BRD-Frentes es el primero a migrar (es el que se bifurcó). Live-data queda como excepción justificada caso por caso. Los tres sellos de frescura se unifican en uno solo: el timestamp del scanner.

---

## §6 · Módulo Buzón (absorbe `[R9]–[R13]`)

El Buzón conserva su diseño (bus MSG-, 4 tipos, ciclo, gobernanza) y gana del salto de nivel: tipo `asesoria` (§4.3) · estado `propuesto` como interrupt durable *(F2 #8)* · hilos/comentarios como MSG- encadenados por `ref` (sin chat: cada comentario es un archivo gobernado) · editar/borrar auditado: todo cambio a un MSG- deja línea en su propio changelog embebido `[R13]` · notificaciones digest-first `[R9]` · **Dispatch móvil y Telegram/WhatsApp (fase 2)**: espejo del bus en la frontera — el mensaje externo se valida contra el Registro Agéntico y se convierte en MSG- gobernado; jamás escritura directa al vault `[R10][R11]` · panel admin con log = sección de la Torre `[R12]`.

---

## §7 · Encaje BMF `[R8]`

- **Dónde vive:** la capa es **L3 (Factory Operations) del stack BMF** — es operación transversal, no gobernanza constitucional ni línea de producción. Sus documentos canónicos: reglas y registro en `EQ-EL-Equipo` (donde ya viven Frentes/Buzón) · diseño y SPECs en `PB-WORX-Worx` · scanners/skills como infraestructura (`.claude/skills`, no activos de IB, precedente vox-distiller).
- **Qué gobierna MEL (L6):** los invariantes aplican directo — INV-02 (toda acción de agente auditable → el log), INV-05 (límites WIP → umbral de NEXTs abiertos por persona, visible en Torre), INV-06 (toda identidad con ID+owner+status → Registro Agéntico), INV-07/Track A-B (cambios de significado en canónicos = Track A → ratificación según nivel).
- **Naming nuevo requerido:** `CP-EL-RegistroAgentico-v01` · `OUT-EL-OrgState-vLIVE` · `BRD-EL-Torre-v01` · tipo de MSG `asesoria` (extiende TEMPLATE-MSG). Alta en Registry al crearse.
- **Fidelidad 100X `[R14]`:** el test de cada módulo en F4/F5: ¿libera tiempo humano de reconciliar estado, o añade vigilancia? Todo módulo que no pase el test se corta. *"Las personas no son el costo que la inteligencia reduce. Son el motor que la inteligencia multiplica."*

---

## §8 · Qué se construye (mapa de módulos → SPECs de F4)

| Módulo | Base existente | Construcción neta | SPEC F4 |
|---|---|---|---|
| M1 · Registro Agéntico | Roster Frentes + alias Buzón + tripletas | Documento canónico + validación en scanners | SPEC madre §identidad |
| M2 · OrgPulse + OrgState | next-scanner · buzon-scanner · weekly-sync | Scanner agregador + formato OrgState | SPEC §conciencia |
| M3 · Puentes automáticos 2–5 | Puente P8 (patrón probado) | 4 puentes + SOP anti-edición-manual | SPEC §lógica |
| M4 · Brief inteligente | Digest arrancaroom | Priorización + borradores staged + anomalías | SPEC §síntesis |
| M5 · Agente-a-agente + asesoría | Bus MSG- + gobernanza L | Tipo `asesoria` + reglas anti-enjambre + vocabulario tipado | SPEC §a2a (con kill switch) |
| M6 · Torre de Control | Kit EL-DashboardStandard + patrón Buzón | BRD-Torre + migración BRD-Frentes a scanner | SPEC §torre |
| M7 · Frontera externa (fase 2) | — | Dispatch + espejo Telegram/WhatsApp | SPEC §frontera |

**Secuencia edge-first (adelanto del blueprint F4):** el primer borde es **M1+M3.3 (Registro + puente Frente→proyección)** sobre el frente F3 (EmpowerLabs core) — porque ataca G2, que ya duele hoy, y su victoria es visible en una semana: el BRD-Frentes deja de divergir para siempre. Desde ahí: M2 (OrgState) → M4 (brief) → M6 (Torre) → M5 (a2a) → M7.

---

## §9 · Esquema agent-readable

```yaml
arq: ARQ-EL-WORXOS-CapaCoordinacion-v01
fase: F3
leyes: [verdad_unica, actor_gobernado, humano_sobre_loop, deep_work, mensaje_efimero, sustrato_vault, edge_first]
mapeo_unificado:  # decisión Victor "unifiquemos"
  OrgPulse: {era_ps: APL, plano: inteligencia, es: scanner_org_level}
  MotorSintesis: {era_ps: SynthesisEngine, plano: inteligencia}
  O_IB: {era_ps: OrganizationalIntelliBank, es: vault_actual, construccion: ninguna}
  PuenteGobernanza: {era_ps: GovernanceBridge, materializa_en: RegistroAgentico}
  OrgX: {era_ps: OrgSherpa, plano: interfaz, acceso: [OrgState, canonicos], nunca: BrainOS_individuales}
  Torre: {plano: interfaz, activo: BRD-EL-Torre-v01, sobre: kit_EL-DashboardStandard}
  Buzon: {rol: modulo, absorbe: [R9, R10, R11, R12, R13]}
  PublicationProtocol: {se_conserva: dos_carriles_D1}
autonomia_unificada:
  eje_canonico: {L0: sugiere, L1: ejecuta_con_aprobacion, L2: ejecuta_y_reporta, L3: ejecuta_y_escala_excepcion}
  absorbe:
    loopx: {autonomo: L2, opt_out: L1_ventana_objecion, decision_humana: L1, gravity_x_valor: funcion_de_asignacion_de_nivel}
    permisos_ps: {renombrados: vistas_de_acceso, valores: [V-OP, V-DIR, V-EST]}
  asignaciones_clave: {asesoria_ultrasherpax: L0_siempre, sherpax_a_sherpax: L1_HITL_hasta_wargame, delegar_frente_ajeno: L1}
plano_logica:
  canonicos: [CP-EL-FrentesTablero, XDocs_espina_NEXT, MSG_buzon, LoopDocs, CP-EL-RegistroAgentico(nuevo), minutas, Registry]
  relacion: hermanas_con_contrato_de_puentes
  proyeccion_maestra: OUT-EL-OrgState-vLIVE
  ley: "write-canónico → puente → regenerar proyecciones; editar proyección a mano PROHIBIDO"
  puentes: [MSG→NEXT(existe), NEXT→Frente(L1), Frente→OrgState, LoopX→OrgState, Minuta→Frente(diff_L1)]
  trazabilidad: "IDs encadenados por eslabón; cadena reconstruible con grep"
plano_inteligencia:
  orgpulse: {corre: [on_write, on_open], patron: scanner_buzon_generalizado, no_demonio: true}
  motor_sintesis: [brief_con_borradores, anomalias_en_digest, triage_ruteo_L0, consulta_via_OrgX]
  a2a:
    sherpax_sherpax: {via: bus_MSG, semantica: A2A_adaptada, nivel: L1, regla_anti_enjambre: "MSG de agente no genera MSG de agente sin interrupt humano"}
    asesoria: {tipo_msg: asesoria, caracter: consejo-no-orden, estructural: "ningún puente acepta asesoria como origen de NEXT"}
    sherpateamsx: {identidad: una_por_equipo, gobierno: en_el_borde_no_adentro}
plano_interfaz:
  torre: {paneles: [frentes_drilldown, interrupts_pendientes, pulso_agentes_killswitch, anomalias], orgx_embebido: sendPrompt, vistas: [V-OP, V-DIR, V-EST]}
  estandar_tableros: generate_on_write_generalizado
encaje_bmf: {capa_vive_en: L3_ops, mel_gobierna: [INV-02_log, INV-05_wip, INV-06_registro, INV-07_track_ab], activos_nuevos: [CP-EL-RegistroAgentico-v01, OUT-EL-OrgState-vLIVE, BRD-EL-Torre-v01]}
modulos: {M1: registro_agentico, M2: orgpulse_orgstate, M3: puentes, M4: brief, M5: a2a_asesoria, M6: torre, M7: frontera_externa_fase2}
edge_first: {primer_borde: "M1+M3.3 sobre frente F3", victoria: "BRD-Frentes deja de divergir", secuencia: [M1, M3, M2, M4, M6, M5, M7]}
para_wargame_f5:
  - regla_anti_enjambre (célula R2)
  - asesoria_L0_estructural (célula R1)
  - validacion_frontera_vs_registro (célula R4)
  - ley_verdad_unica + puentes (célula R3)
  - digest_first + escala (célula R5)
```

---

## §10 · NEXTs

- [ ] **NEXT[@Victor]:** ratificar este ARQ (F3) — en particular: nombres canónicos (§1), vocabulario unificado L/V (§2), Registro Agéntico como nuevo canónico (§3.2) y primer borde edge-first (§8).
- [ ] **NEXT[@Jay]:** correr F4 (SPECs por módulo + blueprint de instalación + gobernanza operativa) sobre este ARQ ratificado.
- [ ] **NEXT[@Jay]:** registrar este activo en el IntelliBanks Registry al cierre de fase.

## §11 · Changelog

| Versión | Fecha | Cambio |
|---|---|---|
| v01 | 2026-07-08 | Creación. Fase 3 del TP madre: 7 leyes de diseño, arquitectura unificada PS↔TP con nombres canónicos (OrgPulse · Motor de Síntesis · OrgX · Torre · Registro Agéntico), vocabulario de autonomía único L0–L3 + vistas V- (decisión "unifiquemos"), plano Lógica (canónicos hermanas + 5 puentes + OrgState + trazabilidad por IDs), plano Inteligencia (OrgPulse on-write/on-open, brief con borradores, a2a gobernado con regla anti-enjambre y asesoría L0 estructural), plano Interfaz (Torre sobre kit estándar, generate-on-write generalizado), encaje BMF (capa en L3, MEL vía invariantes), 7 módulos → SPECs F4 y primer borde edge-first (M1+M3.3 sobre F3/G2). Doble registro. |