# Postulado 12 · El hardware físico es sustrato del sistema

> Fichero: `lru_postulado_12_hardware_fisico_sustrato_s117.md` · destilado fundacional anillo 2
> Ubicación canónica destino: `public/docs-app/v1/doc/lru_postulado_12_hardware_fisico_sustrato_s117.md`
> Origen: sesión s117 · 2026-05-03 · Manuel & Claude Opus 4.7
> Naturaleza: **séptima cristalización fundacional del proyecto LRU Platform** · emergente de cruce arqueológico de once sitios distintos del corpus durante validación del experimento RAG con corpus ampliado (opción §3.A del handoff s116→s117)
> Regla de disputa: **activa hasta integración al núcleo** (T-S117-F1) · ver §11
> Documentos hermanos del proyecto: `LRU_MISION`, `LRU_FUNDAMENTOS`, `LRU_ARQUITECTURA`, `LRU_MAPA`, `LRU_METODO`, `CLAUDE_ARRANQUE`
> Postulados previos integrados: P1-P5 cristalizados s67 integrados s68 · P6-P9 cristalizados s69 integrados s70 · pluralidad de inteligencias §11bis cristalizada s71+s74 integrada s76 · pluralidad de realms §11ter cristalizada s85 integrada s89 · estructura sectorial §11quinquies cristalizada s97 integrada s99 · P10 diseño como innovación cristalizado s84 integrado s91 · P11 anti-anticipación cristalizado y consolidado en METODO

---

## 0 · Resumen ejecutivo

Este destilado articula el **Postulado 12** del proyecto LRU Platform: **el hardware físico es sustrato del sistema**.

Lo que cristaliza no es novedad arquitectural reciente · es articulación unitaria de algo que el proyecto ha sostenido distribuidamente desde s53 sin haberlo nombrado como pieza estructural propia. La sesión s117 detectó la dispersión: once sitios distintos del corpus articulan dimensiones correctas y necesarias del hardware físico, ningún sitio articula la pieza completa.

El postulado afirma que **el sistema LRU se construye sobre tres encarnaciones físicas concretas con propiedades estructurales propias** — microcontroladores con firmware, teléfonos con sensores, banco de pruebas con motor real — y que **estas tres son sustrato del sistema, no aplicación del sistema sobre hardware externo**. El sustrato existe operativamente · sostiene la primitiva Actor del núcleo · materializa el concepto twin · habilita las cinco configuraciones operativas de la orquesta distribuida · demuestra activamente la agnosticidad de dominio del proyecto cada vez que un voltaje genérico alimenta un instrumento aeronáutico.

**Cinco hallazgos mayores articulados** (§3-§9):

- Las tres encarnaciones físicas son **piezas separadas con propiedades estructurales radicalmente distintas**, no variantes del mismo concepto.
- La distinción canónica `puerto ≠ canal` es la propiedad arquitectural que permite que **el mismo hardware alimente cualquier realm** sin saber a cuál.
- Los cuatro modos del RouterService (`Loc/Rnd/HwSim/HwReal`) hacen el sistema **un laboratorio real/virtual de señales** donde las cuatro encarnaciones son ontológicamente equivalentes para el cockpit consumidor.
- El sustrato físico **demuestra empíricamente la universalidad** que los Postulados 5 y 11ter declaran conceptualmente.
- El frente **"hwObj productor de señales"** (`HardwareProfile` · `BindingContract` · BleAdapter · app de teléfono · UI multi-teléfono) es trabajo arquitectural que P12 orienta sin materializar.

**Tres citas gold de Manuel preservadas verbatim** (más ocho citas verbatim adicionales del corpus que también se preservan): la cita fundacional s53 sobre dispositivos intercambiables · la cita s53 sobre el concepto twin · la cita s69 sobre FPGA como instanciación de hardware desde software.

**Lo que este destilado NO hace** · no rediseña el schema Realm v3 (eso vive en T-S67-A1) · no materializa código (trabajo de sesiones posteriores) · no reabre cuestiones sobre los 11 postulados existentes (los refina sin invalidarlos) · no formaliza la app de teléfono ni el `HardwareProfile` · solo los nombra como horizontes que P12 orienta.

**Frente operativo orientado** · *hwObj productor de señales* — entendido como dispositivo (físico o virtual) que escribe valores al DataPlane desde el lado físico, alimentando canales que los swObj consumen vía `channelMap`. El destilado articula §10 con peso propio para guiar este frente sin precipitar materialización.

---

## 1 · Por qué existe este destilado

### 1.1 · La emergencia en s117

s117 arrancó como ejecución del experimento §3.A del handoff s116→s117 — validación del RAG del Project con corpus ampliado mediante 5-10 búsquedas semánticas estructuradas. El experimento adoptó forma orgánica: en lugar de búsquedas formales aisladas, Manuel hizo una pregunta de fondo (*"dame una idea o resumen sobre el realm"*) y la sesión cruzó once fuentes distintas para producir una síntesis que hasta entonces no existía consolidada.

Durante ese cruce emergió un patrón. Cuando se preguntó por el hardware físico, las respuestas necesitaron tocar simultáneamente: la primitiva Actor (`LRU_FUNDAMENTOS §2.3`), el postulado 5 sobre el aeronáutico como primer realm (`LRU_MISION`), la pluralidad de realms (`LRU_FUNDAMENTOS §11ter`), la orquesta distribuida (`LRU_FUNDAMENTOS §12`), las cuatro capas del modelo de señales (`lru_fase4_signal_model.html`), las cuatro fronteras de comunicación (`LRU_ARQUITECTURA §2`), los siete adaptadores del CommsManager (`LRU_ARQUITECTURA §3.1`), el concepto twin (cita gold s53), el horizonte LRM con FPGA (destilado s69), la cita fundacional sobre dispositivos intercambiables (memoir s53), y los conteos empíricos refinados por la auditoría s73.

Once sitios. Cada uno articula una dimensión correcta. **Ninguno articula la pieza completa.**

Lo que la sesión s117 detectó es que el hardware físico es **pieza estructural del proyecto distribuida arqueológicamente sin consolidación canónica**. No es ausencia de articulación — es articulación dispersa que se ha mantenido funcional 117 sesiones sin necesitar consolidación. La sesión que finalmente la cruza es esta.

### 1.2 · Por qué consolidación ahora y no antes

Cuatro razones convergen en s117:

**Primera · maduración del corpus**. Las cinco cristalizaciones fundacionales previas (P1-P5 en s68 · P6-P9 en s70 · pluralidad de inteligencias en s76 · pluralidad de realms en s89 · estructura sectorial en s99) consolidaron piezas conceptuales. El hardware físico siempre estuvo presente operativamente pero las piezas conceptuales tenían prioridad. Con cinco cristalizaciones cerradas, queda espacio para articular el sustrato material.

**Segunda · desarrollo del schema aeronáutico**. La materialización de `src/realm/aviation/` entre s84 y s100 (19 colecciones · 41 superRefines · 19 tipos materializados) consolidó la capa específica del primer realm. La capa base agnóstica (`src/realm/`) tiene contornos más nítidos por contraste. El hardware físico — que es sustrato común de todos los realms posibles — gana visibilidad como pieza propia.

**Tercera · el frente hwObj productor de señales empieza a presionar**. Las tensiones T-S62-A4 (`HardwareCapability`/`BindingContract` sin tipar), T-AU73-3 (`puertoHwObj` sin instancias), la propuesta `HardwareProfile extends RealmProfile` del destilado s63, la planificación del BleAdapter · todas son piezas que requieren un marco fundacional articulado para abordarse coherentemente. P12 es ese marco.

**Cuarta · el experimento RAG produjo trabajo de cristalización potencial**. La sesión s117 ejercitó empíricamente que el corpus ampliado permite cruzar fuentes distantes y producir articulación nueva. La pieza emergió por uso del método, no por planificación previa. Esto es coherente con el patrón documentado del proyecto: *"el instinto produce; la disciplina articula"*.

### 1.3 · Naturaleza del destilado

Este es **destilado fundacional anillo 2** análogo estructuralmente a:

- `lru_postulados_fundacionales_s67.md` (P1-P5 · cinco postulados unitarios)
- `lru_postulados_6_7_8_9_s69.md` (P6-P9 · cuatro postulados unitarios con addendum)
- `lru_postulado_10_diseno_como_innovacion_s84.md` (P10 · postulado unitario)

P12 sigue el patrón de **postulado unitario con sub-secciones** que el formato §11ter (pluralidad de realms) y §11bis (pluralidad de inteligencias) cristalizaron en el núcleo. La estructura mental "N sobre sustrato común" — N realms sobre base agnóstica · N inteligencias sobre sustratos cognitivos — se aplica aquí a un eje nuevo: **N encarnaciones físicas sobre sustrato semántico común**.

La regla de disputa permanece **activa hasta integración al núcleo** (T-S117-F1). Mientras esa integración no se ejecute, este destilado es la fuente autoritativa sobre P12 con las citas gold preservadas. Tras integración, la regla de disputa se retira y este destilado pasa a referencia histórica.

---

## 2 · El postulado articulado

### 2.1 · Texto canónico (provisional · sujeto a revisión en integración)

> **Postulado 12 · El hardware físico es sustrato del sistema**
>
> El sistema LRU se construye sobre encarnaciones físicas concretas que son sustrato suyo, no aplicación suya sobre hardware externo. Las encarnaciones existen operativamente desde el origen del proyecto · sostienen la primitiva Actor del núcleo · materializan el concepto twin físico-virtual · habilitan las cinco configuraciones operativas de la orquesta distribuida · y demuestran activamente la agnosticidad de dominio del proyecto cada vez que un sensor genérico alimenta un instrumento específico. El sustrato físico está articulado en tres encarnaciones con propiedades estructurales propias — microcontroladores con firmware, teléfonos con sensores, banco de pruebas con motor real — coexistiendo bajo una arquitectura común (la distinción `puerto ≠ canal`, los modos del RouterService, la cadena F4→F1) que las hace operacionalmente intercambiables sin que el resto del sistema sepa cuál está activa.

### 2.2 · Tres implicaciones primarias

**Implicación 1 · Sustrato, no aplicación.** El hardware físico no es algo a lo que el sistema se conecta como cliente externo · es parte del sistema. Esto es coherente con la lectura `LRU_ARQUITECTURA §2.1` que sitúa el hardware como **Capa 0** (la capa más baja) sobre la que se apoyan las capas 1-3 (DataPlane · servicios · Realm). La capa 0 es externa al código (ningún fichero del repo vive ahí), pero es **interna al sistema** como pieza arquitectural.

**Implicación 2 · Tres encarnaciones, no una.** El sustrato no es homogéneo. Las tres encarnaciones tienen propiedades estructurales **radicalmente distintas** que merecen articulación separada (firmware fijo vs app dinámica vs pieza profesional · presencia permanente vs efímera vs ocasional · sensores genéricos pre-declarados vs heterogéneos por modelo vs específicos del aparato). Tratarlas como una sola pieza homogénea sería pérdida de información estructural.

**Implicación 3 · Indistinguibilidad operativa para el resto del sistema.** Pese a las diferencias estructurales, las tres encarnaciones operan bajo una arquitectura común que las hace **funcionalmente equivalentes** para el cockpit consumidor. La distinción `puerto ≠ canal` (propiedad canónica de §8.2 de FUNDAMENTOS) garantiza que el instrumento del cockpit lee del mismo slot Float64 sin saber si el productor es un ESP32 con BME280, un teléfono con su acelerómetro, o un motor real en banco de pruebas. Esta indistinguibilidad es operativa, no metafórica.

### 2.3 · Articulación literal de Manuel · cita gold fundacional

Durante la sesión s53, en debate sobre cómo modelar la decisión BLE (si los 3 ESP32 iban en `a320.realm` o en `a320-hw.realm` separado), Manuel articuló:

> *"Los dispositivos hardware se pueden utilizar en cualquier simulación — en un A320, B737, una casa, una fábrica. Los sensores también pueden proceder de otros dispositivos: un teléfono, un motor."*
>
> — Manuel, s53

Esta articulación es **gold del proyecto** (Patrón 3 de `LRU_METODO`). Se preserva literalmente en este destilado y debe cruzar al núcleo en la integración con voz reconocible. Es la cita que forzó el rediseño del schema Realm v1→v2 al hacer evidente que `a320-hw.realm` separado violaba la universalidad. Es, arqueológicamente, **el momento donde el principio de universalidad del hardware se concreta con ejemplos**.

### 2.4 · Regla de disputa activa

Mientras la integración al núcleo no se ejecute (T-S117-F1), si algún canónico del núcleo entra en conflicto con este destilado sobre el material articulado aquí, **gana este destilado** — es la fuente original de P12 con las citas gold de Manuel. Tras integración al núcleo, la regla de disputa se retira y P12 vivirá donde corresponda según decisión de la sesión de integración.

---

## 3 · Las tres encarnaciones · arquitectura común

Las tres encarnaciones físicas (microcontrolador · teléfono · banco motor) tienen propiedades estructurales propias que las distinguen radicalmente entre sí (§§4-6). Pero comparten una arquitectura común que las hace operacionalmente intercambiables. Esta sección articula esa arquitectura común.

### 3.1 · La distinción canónica `puerto ≠ canal`

Articulada formalmente en `LRU_FUNDAMENTOS §8.2` y consolidada en `LRU_ARQUITECTURA §3.2`:

- `puerto` es un nombre **físico** del hardware: `adc1`, `sd2`, `gpio17`, `temp1`, `ax`.
- `canal` es un nombre **lógico** asignado por el instrumento: `aguja_altitud`, `led_alerta`, `slider_throttle`, `cas_capt`.
- `ChannelMap = Record<canal, puerto>` es el **cableado** entre ambos, viviendo en el ORC (`ObjectRegistryContext.tsx`).

Esta distinción es la propiedad arquitectural que permite que **el mismo hardware alimente distintos instrumentos sin conocerse entre sí**, y que el mismo instrumento se conecte a distintos hardware sin cambiar su definición. Es la **bisagra estructural del sustrato**.

Mecanismo concreto: la constante `INACTIVE_PORT` con valor `"----"` marca canales que no deben recibir datos de un hwObj específico. **Exclusividad atómica**: un canal de un swObj solo puede recibir datos de un hwObj a la vez. *"Un violín solo puede recibir la señal de un micrófono a la vez"* (consolidated s53 patrón 4).

### 3.2 · El formato canónico `sensorId = {fuente}/{puerto}`

`LRU_FUNDAMENTOS §2.1` articula que toda señal del sistema tiene identidad en formato `{fuente}/{puerto}`. Para las tres encarnaciones:

- Microcontrolador: `ble_A92418/adc1` · `ble_A92418/temp1` · `ble_A92418/ax`
- Teléfono: pendiente de definir convención al implementar app dedicada · plausible `phone_<deviceId>/imu_x` · `phone_<deviceId>/gps_lat`
- Banco motor: pendiente de definir convención · plausible `bench_<motorId>/n1` · `bench_<motorId>/egt`

Las tres encarnaciones comparten que el `sensorId` es **string opaco para el DataPlane** — la capa 1 no conoce semántica, solo almacena un número con identificador. La semántica vive en la capa 3 (Realm), no en la identificación.

### 3.3 · La cadena F4→F1 como flujo canónico de un hwObj productor

`LRU_ARQUITECTURA §2` articula las cuatro fronteras de comunicación (F1 in-memory · F2 inter-tab · F3 red · F4 hardware) como ortogonales a las cuatro capas. El flujo de un hwObj productor cruza típicamente las cuatro:

```
mundo físico (voltaje en pin del sensor)
↓
F4 hardware · transducción ADC / I²C / SPI / GPIO en el aparato
↓
F3 red · MQTT / BLE GATT / WebSocket al broker o al navegador
↓ (RabbitMQ traduce entre 5 protocolos en 5 puertos)
↓
F2 inter-tab · BroadcastChannel si hay múltiples pestañas PWA
↓
F1 in-memory · DataPlane Float64Array dentro de la PWA
↓
slot N escrito → IB_04 lee → instrumento del cockpit muestra valor
```

Las tres encarnaciones siguen esta cadena. Lo que cambia entre ellas es solamente el contenido de F4 (qué hardware está en el otro extremo) y a veces el adaptador de transporte de F3 (MQTT vía broker vs BLE directo vs WebSocket vía Node-RED). Las capas 1 y 2 son agnósticas a la encarnación.

### 3.4 · Los cuatro modos del RouterService aplicables al productor

`LRU_ARQUITECTURA §3.2` articula la tabla de permisos del ControlBus (consolidación s28):

| `routerMode` | slider | mqtt-hw | mqtt-sim | registry |
|---|---|---|---|---|
| `Loc` | ✅ | ❌ | ❌ | ❌ |
| `Rnd` | ❌ | ❌ | ❌ | ✅ |
| `HwReal` | ❌ | ✅ | ❌ | ✅ |
| `HwSim` | ❌ | ❌ | ✅ | ✅ |

Para un hwObj productor, la lectura es:

- `Loc` · slider humano del usuario · **no es modo de productor físico** estrictamente · es input de la UI que reemplaza al productor.
- `Rnd` · random walk generado internamente · es productor virtual (el SimService genera).
- `HwSim` · firmware del aparato en modo demo · **productor físico simulado** · el aparato genera sus propios datos.
- `HwReal` · firmware del aparato midiendo real · **productor físico real** · el aparato lee voltajes/datos del mundo.

La distinción **real/virtual** del Postulado 12 vive aquí: los cuatro modos son encarnaciones legítimas de la misma señal lógica · las cuatro alimentan el mismo slot Float64 · el cockpit consumidor no las distingue. Esto es la materialización operativa del concepto twin.

Los countdowns automáticos del RouterService (paternidad s26 · `Rnd→HwReal` 30s · `Loc→HwReal` 10s) reflejan una preferencia estructural del proyecto: si el usuario dejó algo en modo manual o aleatorio, el sistema **vuelve solo al hardware real** tras un tiempo prudencial. La preferencia es por la realidad física cuando está disponible.

### 3.5 · Los siete adaptadores de transporte como bus común

`LRU_ARQUITECTURA §3.1` enumera los siete adaptadores del CommsManager:

| Adaptador | Frontera | Estado | Uso típico para hwObj productor |
|---|---|---|---|
| MqttAdapter | F3 | **Activo** | ESP32 ↔ RabbitMQ ↔ PWA · canónico hoy |
| WebSocketAdapter | F3 | **Activo** | Node-RED como gateway intermedio |
| LoopbackAdapter | F1 | **Activo** | Testing sin hardware |
| StompAdapter | F3 | Pendiente | RabbitMQ STOMP puerto 15674 |
| BleAdapter | F3+F4 | **Planificado** | ESP32 directo sin broker · pieza pendiente |
| SerialAdapter | F3+F4 | Planificado | Dispositivos USB/UART |
| SimulationCommsAdapter | F1→F3 | Pendiente | Bridge a simulación externa |

Cada adaptador implementa la misma interfaz mínima — `connect / disconnect / subscribe / publish`. La PWA ignora cuál está activo. Un mensaje puede llegar por MQTT o por WebSocket; el código que lo recibe es el mismo. Esto es la **uniformidad estructural de transporte** que las tres encarnaciones físicas comparten.

Asimetría preservada del consolidated s53 patrón 4: *"Todos los adaptadores respetan la misma interfaz, pero la naturaleza de los datos que transportan varía. MQTT transporta valores de sensores. WebSocket transporta comandos de instructor. BLE transporta ráfagas binarias. El contrato de transporte es uniforme; el significado de lo transportado no."*

### 3.6 · La primitiva Actor del núcleo · cómo se acopla el sustrato físico

`LRU_FUNDAMENTOS §2.3` articula que un actor es cualquier entidad que participa en el sistema aportando o consumiendo señales, con cuatro tipos posibles:

- **Humano con dispositivo** — alumno con teléfono, instructor en pantalla grande, fabricante con pieza real, técnico diagnosticando.
- **Dispositivo físico autónomo** — ESP32 con firmware, LRU real, ADIRU, PLC industrial, **wearable**.
- **Proceso de software** — `SimService` generando datos, `SimSequencePlayer` reproduciendo, futuro bridge MSFS/X-Plane.
- **Observador pasivo** — grabadora FDR, monitor remoto, viewer de Debug1.

Las tres encarnaciones del Postulado 12 se acoplan a esta primitiva así:

- **Microcontrolador** → siempre actor *dispositivo físico autónomo*.
- **Teléfono** → puede ocupar **dos tipos distintos según el rol activo**: actor *humano-con-dispositivo* (alumno tocando sliders en sesión formativa) o actor *dispositivo-físico-autónomo* (publicando IMU/GPS al MQTT mientras el humano hace otra cosa). Incluso simultáneamente con dos roles superpuestos.
- **Banco de pruebas** → actor *humano-con-dispositivo* (fabricante operando) cuando hay operador, o actor *dispositivo-físico-autónomo* (motor en banco publicando parámetros) cuando opera autónomamente.

Las propiedades del actor (identidad · capacidades · presencia · autoría) se materializan de forma distinta para cada encarnación. Detalle en §§4-6.

---

## 4 · Encarnación 1 · Microcontrolador

### 4.1 · Material operativo al cierre de s117

Tres dispositivos ESP32 con firmware **`rpc1cl` v2.1.0** identificados por su MAC address: `ble_A92418`, `ble_0BC4BC`, `ble_A931D4`. Conexión **dual** — BLE (GATT, 7 tipos de mensaje) o MQTT (broker RabbitMQ) — según configuración.

`LRU_ARQUITECTURA §1` cita la configuración de infraestructura: *"Tres ESP32 con firmware rpc1cl v2.1.0 conectados por BLE y/o MQTT"*. RabbitMQ 4.2.5 corriendo en Docker Desktop traduce simultáneamente entre cinco protocolos en cinco puertos: 1883 MQTT 5.0 · 5672 AMQP 0-9-1 · 15674 STOMP/WebSocket · 5552 Streams · 15672 Management HTTP. Esto convierte a RabbitMQ en **gateway multi-protocolo operativo** (hallazgo 14 de la síntesis s55) — pieza arquitectural fuerte.

### 4.2 · Los 25 sensores genéricos · inventario empírico

El helper `buildHwSensors` (líneas 137-172 de `sim-catalog.ts`, leído empíricamente en la auditoría s73) genera **25 sensores por dispositivo** con identificadores que **no contienen ninguna referencia aeronáutica**. Inventario por componente físico:

**4 sensores ambientales** del módulo combinado **BME280 + MAX44009** (pieza estándar IoT):
- `temp1` — temperatura ambiente
- `pres1` — presión barométrica
- `hum1` — humedad relativa
- `lux1` — luz ambiente

**5 ADC genéricos** (`adc1` .. `adc5`): canales analógicos sin asignación específica · candidatos a conectar potenciómetros, NTC, divisores resistivos, pulsadores con resistencia, fotodiodos, etc.

**3 acelerómetros** (`ax`, `ay`, `az`): los tres ejes de un IMU MPU6050 / MPU9250.

**3 giróscopos** (`gx`, `gy`, `gz`): los tres ejes del mismo IMU.

**3 magnetómetros** (`mx`, `my`, `mz`): los tres ejes del HMC5883 / AK8963 (el AK8963 viene integrado en el MPU9250).

**7 entradas FPGA** — el detalle más singular del setup:
- `sw1` · switch digital
- `cnt1` · contador
- `trk1h`, `trk1v` · tracker horizontal/vertical
- `mag1ls`, `mag1ms` · magnitud LSB/MSB de algún canal multibyte
- `swid2` · switch ID secundario

**Total: 25 sensores × 3 dispositivos = 75 sensores HW reales en producción.**

(Nota empírica: el destilado original `lru_sim_catalog_inventory_s63.md` afirmaba 26/dispositivo · 78 totales. La auditoría s73 §2.2 verificó empíricamente con grep+awk+view sobre `buildHwSensors` y corrigió a 25/75 · cierre formal en T-AU73-1. Los conteos vigentes son 25 · 75 · 202 totales catálogo.)

### 4.3 · La FPGA como ventana al horizonte LRM · cita gold s69

Las 7 entradas FPGA del firmware `rpc1cl` no son sensores cualquiera — son la **ventana operativa actual al horizonte LRM** (Line Replacement Module · aviónica reconfigurable con FPGA), articulado fundacionalmente por Manuel en s69:

> *"Las FPGA son desde mi punto de vista lo más potente porque es la instanciación de hardware desde el software. Hay mucho que decir y desarrollar en esta plataforma sobre esa tecnología que todavía no está verbalizado."*
>
> — Manuel, s69

Esta cita es **gold del proyecto** preservada en `lru_postulados_6_7_8_9_s69.md §1.4` y cristalizada en `LRU_FUNDAMENTOS §6.4` como elemento del Postulado 6:

> *"Las FPGA rompen la última frontera: el hardware mismo se reconfigura desde software. La realimentación puede operar a nivel de la propia arquitectura del bucle, no solo dentro del bucle. Si el patrón de operación cambia, la propia topología del circuito se reescribe. Es la instanciación de hardware desde software — la frontera hardware/software, que la informática clásica trataba como categoría dura, se vuelve gradual."*

El horizonte LRM está hoy registrado como semilla en `LRU_MAPA §5` con estatus *"preservado en destilado s69 como referencia histórica · mantiene estatus de semilla · no contamina el proyecto presente"*. P12 lo nombra como dirección fértil sin elevarlo a frente activo.

### 4.4 · Propiedades estructurales del microcontrolador

| Propiedad | Valor para microcontrolador |
|---|---|
| Tipo de actor canónico | Dispositivo físico autónomo |
| Firmware | Fijo · `rpc1cl` v2.1.0 |
| Presencia | Permanente (mientras alimentación) |
| Catálogo de puertos | 25 genéricos pre-declarados · idénticos en los 3 dispositivos |
| Reconfiguración | Limitada · FPGA es ventana parcial |
| Operador humano | No directo · usuario opera vía PWA |
| Identidad | MAC address (`ble_A92418` etc.) |
| Capacidades declaradas | 25 puertos pre-conocidos · invariantes |
| Adaptadores transporte | MQTT activo · BLE planificado · Serial planificado |
| Encarnación canónica | Sustrato físico genérico del proyecto |

### 4.5 · El microcontrolador como hwObj productor de señales

Hoy operativo. Los tres ESP32 son los hwObj productores físicos canónicos del proyecto. La cadena F4→F1 (§3.3) está implementada y funcionando:

```
ESP32 lee ADC/I²C/SPI/FPGA → 
firmware rpc1cl encapsula en frame MQTT → 
publica a RabbitMQ topic <red>/<id>/<direccion>/<canal> → 
PWA suscribe vía MqttAdapter → 
DataPlane.write(slot, valor) tras ControlBus.allows() → 
IB_04 lee slot resuelto vía channelMap → 
instrumento aeronáutico muestra valor
```

Esto es operativo desde s24-s28 según `lru_arqueologia_simil_orquesta_modelo_multipista_s104 §2.4`. La paternidad técnica del hwObj físico está bien establecida.

**Lo que falta materializar para el frente hwObj productor**:

- **BleAdapter** · el firmware del ESP32 ya soporta BLE GATT con 7 tipos de mensaje · el lado del navegador todavía no consume directamente · todo pasa hoy por MQTT y RabbitMQ. La dualidad declarada del firmware es asimétrica con la implementación del navegador.
- **`puertoHwObj?: string`** · campo declarado en `SensorDef` pero con **0 instancias en catálogo** (T-AU73-3) · es el embrión real del `BindingContract` · cuando v3 introduzca la formalización, los 75 sensores HW deberían poblar el campo.
- **`HardwareProfile` extends `RealmProfile`** · propuesto en `lru_realm_v2_dirigido_s63 §3.7` con esquema concreto:
  ```typescript
  interface HardwareProfile extends RealmProfile {
    firmware: string;      // 'rpc1cl-v2.1.0'
    chip: string;          // 'ESP32-WROOM-32'
    sensors: { [portId: string]: string };
    capabilities?: HardwareCapability[];
    bindings?: BindingContract[];
  }
  ```
  Los 3 ESP32 se modelarían como tres instancias de `HardwareProfile` sobre el `RealmManifest` de dispositivo genérico.

---

## 5 · Encarnación 2 · Teléfonos

### 5.1 · La cita gold fundacional · paternidad arqueológica resuelta

La frase original es de Manuel en s53 — preservada como cita gold en el memoir de la sesión:

> *"Los dispositivos hardware se pueden utilizar en cualquier simulación — en un A320, B737, una casa, una fábrica. Los sensores también pueden proceder de otros dispositivos: un teléfono, un motor."*
>
> — Manuel, s53

Es la cita citada en §2.3 como articulación canónica de P12. Se preserva una segunda vez aquí porque su mención explícita del **teléfono** como fuente intercambiable es la articulación fundacional de esta encarnación.

Resolución arqueológica registrada en `lru_arqueologia_simil_orquesta_s103 §6`: el doc histórico s53 atribuyó a s51 la articulación del *"SignalSource model · Orquesta de simulación con múltiples teléfonos"*. La resolución correcta:
- En **s51** se produjeron *"primeros apuntes sobre orquesta distribuida con múltiples teléfonos"* (cronología preservada en `LRU_FUNDAMENTOS §15` línea 1165).
- En **s53** Manuel articuló la frase fundacional sobre dispositivos como fuentes intercambiables.

Las dos cosas son verdaderas. La síntesis del doc histórico mezcló cronologías sin perder verdad esencial. La articulación dispersa quedó preservada en el corpus.

### 5.2 · Cinco configuraciones operativas de la orquesta distribuida

`LRU_FUNDAMENTOS §12.2` articula canónicamente las cinco configuraciones que el sistema soporta simultáneamente:

> *"Instructor en pantalla grande — ve toda la orquesta, interviene a voluntad, inyecta fallos, cambia escenario."*
>
> *"Alumnos en teléfonos — cada uno con una parte de señales asignada, cada uno aporta valores mediante sliders y switches a la señal que le toca."*
>
> *"Hardware real intercalado — un ESP32 aporta valores reales de un sensor que sustituyen lo que un alumno tocaría. Un motor físico en un banco de pruebas aporta sus parámetros al Realm en lugar de la pieza simulada."*
>
> *"Viewer remoto — un experto en otro continente observa la sesión en tiempo real sin intervenir, pudiendo grabar y recuperar sesiones anteriores para comparar."*
>
> *"Actor-proceso — un SimService externo aporta las partes que ningún humano está tocando, completando la coherencia del mundo."*

Estas cinco configuraciones son **gold del proyecto** preservadas verbatim. El teléfono ocupa la segunda directamente · puede aparecer transversalmente en otras configuraciones (un viewer remoto puede ser un teléfono · un instructor puede usar un teléfono como pantalla complementaria).

Cita correlativa del consolidated s53 preservada en `lru_arqueologia_simil_orquesta_modelo_multipista_s104 §5.3`:

> *"Un instructor de simulación de vuelo usa múltiples teléfonos como dispositivos de entrada, cada uno alimentando una parte del cockpit (modelo 'orquesta de simulación' de s51)."*

Es la única referencia preservada como cita escrita en el corpus disponible que atribuye explícitamente la idea a s51. Cierra arqueológicamente la pregunta sobre paternidad del símil orquesta.

### 5.3 · El doble rol del teléfono · actor humano-con-dispositivo + dispositivo-físico-autónomo

Articulación nueva producida en s117. `LRU_FUNDAMENTOS §2.3` enumera cuatro tipos de actor. El teléfono puede ocupar **dos de los cuatro tipos** según el rol que desempeñe en cada momento:

- Como **humano con dispositivo** — *"alumno con teléfono, instructor en pantalla grande"* (cita literal del núcleo). El humano es el actor primario; el teléfono es su instrumento de interacción. El humano ve, decide, manipula sliders, toca switches. La identidad del actor es del humano (`userId`), no del aparato.
- Como **dispositivo físico autónomo** — *"ESP32 con firmware, LRU real, ADIRU, PLC industrial, **wearable**"* (cita literal del núcleo · el wearable es la extensión natural al teléfono). Aquí el dispositivo opera por sí mismo aportando datos de sus sensores sin mediación humana inmediata. Un teléfono en un bolsillo midiendo movimiento corporal, o en un soporte midiendo orientación, entra aquí.

La distinción no es del aparato sino del rol activo. El mismo iPhone puede ser **humano-con-dispositivo** (alumno tocando sliders en sesión formativa) y **dispositivo-físico-autónomo** (publicando IMU/GPS al MQTT mientras el humano hace otra cosa) en momentos distintos · incluso simultáneamente con dos roles superpuestos.

Las **propiedades del actor** (§2.3 FUNDAMENTOS) mapean al teléfono así:

- **Identidad** · `deviceId` (UUID del aparato) · `sessionId` (sesión vinculada) · `userId` (humano asignado).
- **Capacidades** · *"Este teléfono tiene IMU pero no GPS"*. La cita literal de FUNDAMENTOS usa el teléfono como **ejemplo paradigmático de capacidades heterogéneas** — es exactamente el tipo de actor donde la enumeración explícita de capacidades importa, porque varían por modelo y por permisos del sistema operativo.
- **Presencia** · efímera por naturaleza (un alumno entra y sale de la sesión), a diferencia de un ESP32 montado en banco que tiende a presencia permanente.
- **Autoría** · *"un valor que llega de un hardware real queda marcado como proveniente de ese hardware concreto"*. Un slider movido por un alumno queda marcado con su `userId`; el IMU del mismo teléfono publicando movimiento queda marcado con el `deviceId`. La autoría dual cuando ambos roles operan simultáneamente es trazable.

### 5.4 · Propiedades estructurales del teléfono

| Propiedad | Valor para teléfono |
|---|---|
| Tipo de actor canónico | Dual · humano-con-dispositivo + dispositivo-físico-autónomo |
| Firmware | App dinámica (PWA o nativa) |
| Presencia | Efímera · entra y sale con el alumno |
| Catálogo de puertos | Heterogéneo por modelo (IMU sí, GPS variable, magnetómetro variable, micrófono, cámara) |
| Reconfiguración | Total · app actualizable |
| Operador humano | Directo · interacción UI continua |
| Identidad | `deviceId` UUID + `userId` del humano asignado |
| Capacidades declaradas | Variables · enumeración explícita necesaria |
| Adaptadores transporte | Plausible MQTT (PWA via WebSocket Bridge) o nativo BLE |
| Encarnación canónica | Sustrato físico distribuido para orquesta multi-actor |

### 5.5 · El cruce de los cuatro ejes ortogonales sobre un teléfono

Articulación preservada de `lru_arqueologia_simil_orquesta_s103 §5.5`. El sistema cruza simultáneamente cuatro ejes ortogonales (capa · frontera · tiempo · actor). Una pista grabada de un vuelo real reproduciéndose para un alumno **usando una vista personal en su teléfono** ejercita simultáneamente:

- Eje 1 capa · semántica (EGT en °C) → protocolo (label ARINC) → transducción (ADC) → física (señal eléctrica)
- Eje 2 frontera · F1 in-memory (DataPlane local del teléfono) ← F3 red (MQTT desde RabbitMQ) ← F5 sesión↔sesión (replay desde grabación previa)
- Eje 3 tiempo · grabado (la pista del vuelo real) reproduciéndose en tiempo presente
- Eje 4 actor · alumno humano + teléfono dispositivo + sesión runtime + realm A320 + perfil específico

Cita verbatim de la síntesis `lru_arqueologia_simil_orquesta_s103 §5.5`:

> *"Esta es la articulación operativa de las dimensiones multidimensionales que se cruzan. No es decoración conceptual — es la operación cotidiana del sistema cuando funciona completo."*

El teléfono no es un caso particular del hardware genérico — es **la encarnación más completa del cruce porque combina las cuatro dimensiones simultáneamente** en un aparato pequeño que el usuario lleva encima.

### 5.6 · El teléfono como hwObj productor de señales · estado al cierre de s117

Resumen del estado vigente:

> *"Aún sin implementación dedicada para teléfono específicamente, pero la arquitectura las soporta — mismo modelo que ESP32 vía MQTT/BLE."*
>
> — `lru_arqueologia_simil_orquesta_s103 §5`

Esto significa: si Manuel coge un teléfono mañana, instala una app PWA que publique acelerómetro al broker RabbitMQ con un topic estandarizado, y se registra como hwObj en el ORC, **la infraestructura existente lo absorbe sin cambios**. Ya hay 3 dispositivos BLE registrados con el mismo patrón; un cuarto teléfono entraría limpio.

**Lo que NO existe todavía**:

- **App dedicada de teléfono como hwObj productor**. Tendría que ser una PWA o app nativa que publique sensores estandarizados (IMU, GPS, magnetómetro, ambient light, micrófono, cámara). **Pieza pendiente principal del frente "hwObj productor de señales"**.
- **UI de teléfono como consumidor de señales** — la articulación s51 *"alumnos en teléfonos cada uno con una parte de señales asignada"*. Hoy la PWA principal funciona en teléfono pero no está optimizada para múltiples teléfonos coordinados con vistas parciales del cockpit. Pieza pendiente.
- **Mecanismo de descubrimiento** — cómo un teléfono que llega a la sesión se anuncia, declara sus capacidades, y obtiene su asignación de canales en la orquesta. Pieza pendiente.
- **Convención de naming** para `sensorId` de teléfono — análoga a `ble_<MAC>/<puerto>` del ESP32. Pendiente de definir.

### 5.7 · Cita gold complementaria s53 · señales como base universal

Manuel articuló en s53 una afirmación más amplia que las señales como ladrillo del sistema:

> *"Nos podemos quedar con las señales. En electrónica es una de las bases. En comunicaciones también. En redes. En pantallas. El mundo que nos rodea lo percibimos mediante señales con nuestros sentidos que podemos extender gracias a los sensores."*
>
> — Manuel, s53

Esta cita conecta el principio de universalidad de los dispositivos con **el principio de universalidad de las señales como vocabulario común**. El teléfono — que tiene sensores que extienden los sentidos del humano — es la encarnación más cercana al espíritu de esta cita. Un alumno con el teléfono en el bolsillo durante una sesión formativa es literalmente *"sentidos extendidos"* aportando datos al sistema mientras él mismo decide y opera.

Cita complementaria sobre los protocolos como acuerdo hardware-software, también de s53:

> *"Los protocolos no cambian y ponen de acuerdo al hardware con el software, están constituidos efectivamente por señales."*
>
> — Manuel, s53

Esta articulación cierra la conexión: **los protocolos son el contrato estable entre las dos encarnaciones del sustrato físico** (hardware) **y el resto del sistema** (software). Cuando un teléfono publica su acelerómetro vía MQTT, está respetando un contrato que el ESP32 también respeta · esa es la razón por la que ambos pueden ser hwObj productores intercambiables.

---

## 6 · Encarnación 3 · Banco de pruebas con motor real

### 6.1 · Material operativo al cierre de s117

`LRU_ARQUITECTURA §2.1` cita: *"Banco de pruebas con motor real (ocasional, fabricante de motores) cuando se prueba integración con Realm A320 híbrido"*.

Es la **encarnación menos articulada** de las tres en el corpus. Razón estructural: aparece operativamente solo en uso ocasional vinculado a contextos profesionales específicos (un fabricante de motores que valida su producto contra un Realm A320 híbrido). No tiene presencia continua en el desarrollo cotidiano del proyecto.

### 6.2 · La cita gold s53 · banco motor en la orquesta distribuida

Su mención canónica está dentro de la articulación de las cinco configuraciones operativas (`LRU_FUNDAMENTOS §12.2`):

> *"Hardware real intercalado — un ESP32 aporta valores reales de un sensor que sustituyen lo que un alumno tocaría. **Un motor físico en un banco de pruebas aporta sus parámetros al Realm en lugar de la pieza simulada.**"*

Esta articulación (que ya se preservó completa en §5.2) sitúa al banco motor como pieza estructural del sistema · no como caso particular ocasional · porque la posibilidad de **sustituir una pieza simulada por una real** es propiedad arquitectural fundamental que requiere infraestructura preparada.

### 6.3 · Cita complementaria s53 · cimientos robustos y flexibles

Manuel articuló en s53, en el contexto del rediseño Realm v1→v2:

> *"Estamos creando los cimientos y deben ser robustos y flexibles. Hay múltiples dimensiones que todavía no son evidentes, irán emergiendo."*
>
> — Manuel, s53

El banco motor es ejemplo de **dimensión emergente** que la cita anticipa. Cuando la articulación se hizo en s53, el banco motor era horizonte · al cierre de s117 sigue siendo presencia ocasional pero la arquitectura ha demostrado robustez al absorberlo cuando aparece.

### 6.4 · Propiedades estructurales del banco motor

| Propiedad | Valor para banco de pruebas |
|---|---|
| Tipo de actor canónico | Dual · humano-con-dispositivo (operador) + dispositivo-físico-autónomo (motor publicando) |
| Firmware | Específico del aparato real · no estandarizado en el proyecto |
| Presencia | Ocasional · vinculada a contexto profesional concreto |
| Catálogo de puertos | Específico del motor concreto (N1 · N2 · EGT · FF · OilP · OilT · Vibr · etc.) |
| Reconfiguración | Limitada · pieza profesional terminada |
| Operador humano | Fabricante experto · operador profesional |
| Identidad | `bench_<motorId>` o convención análoga |
| Capacidades declaradas | Específicas del motor · plausible mapeo directo a sensores ATA del Realm A320 |
| Adaptadores transporte | Plausible MQTT vía gateway industrial · WebSocket vía Node-RED · Serial RS-485 |
| Encarnación canónica | Sustrato físico profesional para validación cruzada Realm-real |

### 6.5 · El banco motor como hwObj productor de señales

Su rol como hwObj productor es **el más conceptualmente directo** de las tres encarnaciones. El motor genera realmente los parámetros que el Realm A320 simula sintéticamente. Cuando el banco está activo, sus sensores (N1, EGT, etc.) pueden mapearse directamente a los sensores virtuales del Realm A320 mediante `channelMap`, y el cockpit lee del DataPlane sin saber si los valores vienen del motor real o de la simulación.

Esta es la materialización más **directa y profunda** del concepto twin (cita s53 sobre hermanos gemelos físico-virtual). Cuando un fabricante valida su motor contra un Realm A320, no está conectando dos sistemas distintos — está usando el sistema LRU como **plataforma de twin operativa**.

**Lo que falta materializar**:

- **Convención de gateway industrial** · cómo un banco de pruebas con sus protocolos profesionales (Modbus, OPC UA, CAN, ARINC 429 si lo lleva) se conecta al CommsManager.
- **Mapping canónico motor-real → sensor-Realm-A320** · cómo los `sensorId` del banco se reescriben (o se mantienen) para alimentar los canales correctos del Realm.
- **Modo de operación de validación** · presumiblemente un modo donde tanto la simulación como el motor real corren en paralelo y se comparan (twin testing).

### 6.6 · El banco motor como puente entre dimensión pedagógica y dimensión industrial

Las tres encarnaciones del Postulado 12 cubren conjuntamente dos dimensiones operativas del proyecto:

- **Dimensión pedagógica** · microcontrolador y teléfono son sustrato del laboratorio formativo (alumnos · instructor · sesiones de aprendizaje).
- **Dimensión industrial/profesional** · banco motor es sustrato de la validación cruzada profesional (fabricante · motor real · Realm híbrido).

Esta dualidad es coherente con la articulación más amplia del proyecto en `LRU_MISION` sobre múltiples casos de uso (formación · simulación · mantenimiento · investigación · fabricación · certificación). El banco motor es **la encarnación que extiende el sustrato físico hacia la dimensión profesional**, demostrando que P12 no es solo sustrato pedagógico.

Cita complementaria de `lru_fase4_signal_model.html` sobre la dimensión formativa, gold del proyecto:

> *"Los instrumentos de medida son los ojos virtuales que extienden nuestros sentidos y nos ayudan a percibir dimensiones desconocidas."*
>
> — articulación canónica preservada en `lru_fase4_signal_model.html`

Esta cita, originalmente sobre la dimensión formativa de los instrumentos, aplica también al banco motor: el motor real visto a través del Realm A320 con el cockpit virtual es exactamente *"sentidos extendidos para percibir dimensiones desconocidas"* del comportamiento del motor.

---

## 7 · El concepto twin como propiedad emergente

### 7.1 · La cita gold s53 · concepto twin

Articulada por Manuel durante la sesión s53 en el contexto del rediseño Realm v1→v2:

> *"El hardware representa el mundo físico. Son uno de los dos lados, el físico. El otro puede ser el virtual. Uno vive en el mundo físico y otro vive en el mundo virtual. Son hermanos gemelos. El concepto twin."*
>
> — Manuel, s53

Esta cita es **gold del proyecto** preservada en `lru_session_s53_memoir.md`. Es la base conceptual del cuádruple modo del RouterService y de la indistinguibilidad operativa que define al sustrato físico.

### 7.2 · Las cuatro encarnaciones de cada señal como hermanos gemelos

`LRU_ARQUITECTURA §3.2` (tabla preservada en §3.4 de este destilado) articula los cuatro modos del RouterService como mutuamente excluyentes pero ontológicamente equivalentes para el resto del sistema:

- `Loc` · slider humano controla el valor de la señal.
- `Rnd` · random walk lo controla.
- `HwSim` · firmware en modo demo lo simula.
- `HwReal` · sensor físico real lo mide.

Los cuatro son *"hermanos gemelos"* de la misma señal lógica. El instrumento del cockpit (`AirSpeed1`, `Throttle1`, etc.) **no sabe qué modo está activo** — lee del slot Float64 del DataPlane sin distinguir origen. Esta indistinguibilidad ontológica es la **materialización operativa del concepto twin** dentro del sistema.

### 7.3 · La indiferencia ontológica del cockpit

El instrumento del cockpit consume valores del DataPlane sin metadata sobre su origen. La cadena de consumo:

```
IB_04 → DataPlane.readBySensorId(slot) → número Float64 → instrumento muestra
```

El instrumento no recibe `{ value: 67.5, source: 'mqtt-hw' }` · solo recibe `67.5`. La metadata de origen vive en el ControlBus (que arbitra escritura) pero **no viaja con el valor consumido**. Esto es decisión arquitectural deliberada: la equivalencia operativa de las cuatro encarnaciones requiere que el consumidor no las distinga.

Consecuencia profunda: **un alumno que aprende en `Rnd`, practica en `Loc`, valida contra el firmware demo en `HwSim`, y ejecuta con sensor real en `HwReal`** está usando el mismo instrumento, la misma app, la misma vista, los mismos procedimientos. La indistinguibilidad físico-virtual que la cita gold articula es lo que hace este aprendizaje gradual y transferible.

### 7.4 · El laboratorio real/virtual de señales

Esta es la articulación que Manuel produjo en s117 cuando se discutió cómo nombrar el valor estructural de las tres encarnaciones físicas. La formulación canónica:

> **El sistema LRU es un laboratorio real/virtual de señales** — un espacio operativo donde las señales pueden venir indistintamente de fuentes reales o virtuales, en cualquier combinación, sin que el resto del sistema (cockpit · instrumentos · evaluación · grabación · replay) las distinga.

Esta formulación es más fiel al espíritu del proyecto que articulaciones más abstractas (*"laboratorio empírico de la universalidad"*). Habla de **lo que el sistema literalmente hace cuando funciona**, no de un principio que se demuestra. Las cuatro encarnaciones del RouterService son las cuatro plataformas del laboratorio · las tres encarnaciones físicas del P12 son los tres tipos de aparatos disponibles para experimentar · los protocolos son los lenguajes comunes que permiten que cualquier combinación funcione.

### 7.5 · Conexión con el Postulado 9 · continuidad simulación↔control real

El Postulado 9 (continuidad simulación↔control real) integrado al núcleo en s70 desde el destilado s69 articula formalmente lo que el laboratorio practica. `LRU_FUNDAMENTOS §5.3` materializa P9 en el modo **REPLAY_MIXED**:

> *"REPLAY_MIXED — mezcla grabación con simulación en vivo. Los motores vienen de un FDR real grabado; la navegación la aporta SimService. Uso: entrenamiento con datos reales, contexto histórico."*

El laboratorio real/virtual no es excepción exótica del sistema · es **propiedad estructural** soportada por una arquitectura diseñada para que las cuatro encarnaciones (sim/replay/hwsim/hwreal) sean equivalentes. P12 articula el sustrato físico que hace operativa esta propiedad · P9 articula la continuidad temporal que hace operativa la transición.

Los dos postulados son **complementarios** · P9 sin P12 sería continuidad temporal sin sustrato físico real · P12 sin P9 sería sustrato físico sin continuidad operativa al control real. Juntos articulan el laboratorio completo.

---

## 8 · El laboratorio real/virtual de señales · articulación canónica

### 8.1 · Formulación

El sistema LRU **es** un laboratorio real/virtual de señales. No *"se comporta como"* un laboratorio · es uno literalmente, en el sentido operativo de que su función es operar señales que pueden venir indistintamente de fuentes reales o virtuales en cualquier combinación.

Tres componentes constituyen el laboratorio:

**Componente 1 · Las tres encarnaciones físicas (P12)** son los **tres tipos de aparatos disponibles** para experimentar con señales. El microcontrolador con sus 25 sensores genéricos es laboratorio universal. El teléfono con sus sensores variables es laboratorio distribuido. El banco motor es laboratorio profesional. Las tres son legítimas dentro del laboratorio.

**Componente 2 · Los cuatro modos del RouterService** son los **cuatro estados operativos** que cada señal puede ocupar dentro del laboratorio. La señal `cas_capt` puede estar en `Loc` (slider humano), `Rnd` (random walk), `HwSim` (firmware demo) o `HwReal` (sensor real) · las cuatro son legítimas y el cockpit las trata por igual.

**Componente 3 · La cadena de transducción de cuatro capas** (semántica · protocolo · transducción · física) es la **bisagra invisible** que conecta el lado físico con el lado virtual permitiendo que sean intercambiables. Cada capa solo conoce a su vecina · la semántica nunca menciona ADC · la física nunca menciona °C. Esta separación es lo que hace operativa la indistinguibilidad.

### 8.2 · La disciplina de agnosticidad · ejercicio empírico continuado

`LRU_FUNDAMENTOS §11ter.1` cristaliza una disciplina activa del proyecto:

> *"Es agnóstico por disciplina, no por casualidad — cualquier referencia específica a un dominio concreto en este nivel se considera deuda y se renombra. Ejemplo histórico: el campo `systemId?` de `FaultDefBase` y `ActuatorDef`, que llevaba comentario literal "ATA chapter" y violaba la agnosticidad, fue renombrado a `taxonomyRef?` en s86 al materializar T-S84-A9."*

Esta disciplina se ejercita continuadamente en el laboratorio. Cuando alguien (Claude o Manuel) deja un campo con nombre o comentario aeronáutico en `src/realm/` (la capa base agnóstica), la disciplina del proyecto lo trata como deuda y lo retira. No es ideal pasivo · es **mecanismo activo** de mantenimiento de la universalidad del laboratorio.

Los nombres de los 25 puertos del firmware `rpc1cl` son evidencia material de la disciplina aplicada al lado físico: `temp1`, `adc1`, `ax`, `sw1`, `cnt1` son nombres que **no contienen ninguna referencia aeronáutica**. Si en algún momento se hubiera filtrado un nombre del estilo `n1_left` o `egt` al firmware, eso sería deuda · señal de violación del principio. No ha ocurrido. El firmware vive en el dominio puro del hardware genérico, sin saber qué realm va a consumir sus datos.

### 8.3 · La transducción como bisagra del laboratorio

`lru_fase4_signal_model.html §5` articula las cuatro capas que evolucionan en escalas temporales radicalmente distintas:

| Capa | Contenido | Escala de evolución |
|---|---|---|
| Semántica (quantities) | Magnitudes, unidades, conversiones, rangos | ~nunca |
| Protocolo (contracts) | ARINC 429, 1553, AFDX, 4-20mA, ADC | décadas |
| Transducción (adapters) | Sensor → protocolo · Protocolo → actuador | años |
| Física (hardware) | ESP32, cables, firmware, BLE, MQTT | meses |

Cita verbatim del documento canónico:

> *"Cada capa solo conoce a su vecina. La semántica nunca menciona ADC. La física nunca menciona °C."*

El laboratorio funciona porque **la transducción media entre el ESP32 genérico y el A320 específico**. Cuando el slider real está conectado a un potenciómetro divisor sobre `adc1`, la cadena es:

```
mundo físico (voltaje 1.65V en pin del ESP32)
↓
transducción ADC 12 bit (valor 2048/4095 = 50%)
↓
MQTT / BLE (frame con valor crudo)
↓
DataPlane (slot N en Float64Array)
↓
channelMap (canal "throttle" → puerto "adc1")
↓
escalado por cfg1 del instrumento (0..4095 → 0..100%)
↓
aguja de Throttle1 mostrando 50%
↓
SimService consume el throttle al 50% para el modelo aerodinámico A320
↓
ALT_ind sube según modelo
```

El **mismo voltaje de 1.65V** podría haber sido el slider de "temperatura del horno" en un realm doméstico · "presión de inyección" en un realm industrial · "FiO₂" en un realm médico. La capa física no cambia · cambian solo los `channelMap` y el realm semántico activo.

Esto es lo que justifica llamar al laboratorio **real/virtual de señales**: cada vez que el sistema funciona, demuestra que la transducción es robusta y que las capas son verdaderamente independientes. La universalidad del sustrato físico no es promesa abstracta · es propiedad descriptiva del código existente.

### 8.4 · Las cinco configuraciones operativas como modos de laboratorio

Las cinco configuraciones de `LRU_FUNDAMENTOS §12.2` (preservadas verbatim en §5.2) son **cinco modos de uso del laboratorio**:

- **Instructor en pantalla grande** · modo *director del laboratorio* · ve todo · interviene a voluntad.
- **Alumnos en teléfonos** · modo *operadores distribuidos* · cada uno con una parte del experimento.
- **Hardware real intercalado** · modo *señales reales* · ESP32 o motor real reemplazan piezas simuladas.
- **Viewer remoto** · modo *observador externo* · experto en otro continente acompaña sin intervenir.
- **Actor-proceso** · modo *automatización* · SimService completa la coherencia del mundo.

Las cinco son legítimas y combinables. El laboratorio soporta cualquier mezcla de las cinco simultáneamente. Esta combinabilidad es lo que hace al sistema más que un simulador y más que un laboratorio físico tradicional · es un laboratorio donde las fronteras real/virtual son operativas pero no estructurales.

---

## 9 · Relación con los 11 postulados existentes

P12 es **postulado transversal**: refina varios postulados anteriores sin invalidarlos · les añade dimensión material que estaba implícita pero no articulada. Esta sección articula los acoplamientos.

### 9.1 · P1 · El bucle perceptor-inteligencia-efector

P1 articula la estructura operativa del sistema · perceptores → capa intermedia → efectores. P12 articula que **los perceptores físicos del bucle son las tres encarnaciones físicas**: sensores del microcontrolador, sensores del teléfono, sensores del banco motor. Sin sustrato físico, P1 sería bucle sin lado de percepción real · solo simulación.

P12 no añade nada conceptual a P1 · solo articula que los sensores que P1 menciona como primitiva son **operativamente las tres encarnaciones** · no sensores abstractos sin encarnación.

### 9.2 · P5 · El aeronáutico como primer realm · razones estratégicas

P5 articula que el aeronáutico es primer realm, no único · los dominios candidatos futuros son medicina, industria, nuclear, cocina, automoción, energía, agricultura, biotecnología, electromedicina. P12 articula que **las tres encarnaciones físicas son sustrato común de todos los realms posibles** · los 25 sensores del ESP32, los sensores del teléfono, los sensores del banco motor sirven igual a A320 que a hospital que a fábrica.

P12 refina P5 haciendo explícito que **el sustrato físico está hoy más maduro que la pluralidad de realms**: las tres encarnaciones existen y operan en producción · los realms candidatos siguen como horizonte estratégico. P12 desplaza el centro de gravedad de la universalidad desde el lado semántico (P5 · §11ter) hacia el lado material (sustrato común físico).

### 9.3 · P6 · La realimentación universal

P6 articula que la realimentación es estructura causal universal del sistema. P12 articula que **el bucle de realimentación se cierra en el mundo físico**: una intervención del cockpit (actuador virtual) puede mover un motor real (actuador físico vía banco motor) cuya respuesta vuelve al cockpit (sensor físico → DataPlane → instrumento). P12 es **el sustrato material donde P6 se cierra cuando el bucle cruza la frontera real/virtual**.

P12 también conecta con la cita gold s69 sobre FPGA · *"la instanciación de hardware desde software"* · que articula el límite extremo de P6: la realimentación operando a nivel de la propia arquitectura del hardware. Las 7 entradas FPGA del firmware `rpc1cl` son ventana parcial a esta dirección.

### 9.4 · P9 · Continuidad simulación↔control real

P9 es el postulado más cercano a P12. P9 articula la continuidad temporal · P12 articula el sustrato material que hace operativa esa continuidad. Articulación detallada en §7.5.

Los dos postulados son complementarios · ninguno reemplaza al otro · juntos articulan el laboratorio real/virtual completo.

### 9.5 · §2.3 Primitiva Actor

§2.3 enumera cuatro tipos de actor (humano-con-dispositivo · dispositivo-físico-autónomo · proceso-software · observador-pasivo). P12 articula que **dos de los cuatro tipos requieren sustrato físico**: humano-con-dispositivo necesita el dispositivo (teléfono, ESP32 portátil), y dispositivo-físico-autónomo es directamente sustrato físico operando autónomamente.

P12 no añade tipos nuevos · enfatiza que sin las tres encarnaciones, dos primitivas del núcleo serían ideas no encarnadas. La cita gold s53 sobre dispositivos intercambiables (§2.3 de este destilado) es operativa precisamente porque P12 articula los aparatos concretos.

### 9.6 · §11ter Pluralidad de realms

§11ter articula la arquitectura "base agnóstico + realms específicos coexistiendo". P12 articula que **el sustrato físico es parte del base agnóstico**, no de los realms específicos. Esto es importante:

- `src/realm/` · base agnóstico · contiene tipos transversales **incluido el sustrato físico genérico** (sensores `temp1`, `adc1`, `ax`, etc.).
- `src/realm/aviation/` · realm específico · contiene tipos aeronáuticos pero **no contiene los puertos físicos** (esos viven genéricamente en el base).
- Un eventual `src/realm/industrial/` o `src/realm/domotics/` · realms hermanos · usarían los **mismos sensores físicos genéricos** del base mediante `channelMap` distintos.

P12 articula la **dimensión vertical** que §11ter no nombra explícitamente: la pluralidad de realms (horizontal) opera sobre un sustrato físico común (vertical) cuya universalidad es lo que hace posible la pluralidad horizontal.

### 9.7 · §11bis Pluralidad de inteligencias

§11bis articula 7-8 tipos de inteligencias coexistiendo en el sistema. P12 conecta con §11bis vía la **inteligencia física** que §6.7 del núcleo articula como "sustrato epistémico" · las leyes físicas que el sistema modela.

Las tres encarnaciones de P12 son **donde la inteligencia física se encarna empíricamente**: el motor real del banco mide leyes físicas reales · el ESP32 con su BME280 mide presión/temperatura/humedad reales · el teléfono con su IMU mide fuerzas reales. P12 es el sustrato material donde la inteligencia física inamovible (a diferencia de las inteligencias cognitivas evolutivas) opera en el sistema.

### 9.8 · §12 La orquesta distribuida

§12 articula las cinco configuraciones operativas. Tres de las cinco requieren sustrato físico (teléfonos · hardware real intercalado · viewer remoto si es móvil). P12 es el sustrato material que hace operativas tres de las cinco encarnaciones de la orquesta.

Sin P12, §12 sería metáfora con cinco configuraciones de las cuales solo dos serían operativas (instructor en pantalla y actor-proceso). Con P12, las cinco son legítimas y materializables.

### 9.9 · Resumen del acoplamiento

P12 **refina sin invalidar** los postulados anteriores. Su contribución estructural es articular el sustrato material que múltiples postulados conceptuales presuponen sin haberlo nombrado unitariamente. La pieza estaba presente en el corpus distribuidamente · P12 la consolida como ciudadano de primera clase.

Paralelo estructural con cristalizaciones anteriores:

- §11bis · pluralidad de inteligencias · *"N inteligencias sobre sustratos cognitivos"*
- §11ter · pluralidad de realms · *"N realms sobre base agnóstico común"*
- §11quinquies · estructura sectorial · *"sector + N modelos coexistiendo"*
- **P12 · sustrato físico** · *"N encarnaciones físicas sobre arquitectura común"*

El patrón mental "N sobre sustrato común" se aplica aquí a un eje nuevo del proyecto: la dimensión material concreta.

---

## 10 · Implicaciones operativas · frente "hwObj productor de señales"

Este destilado orienta — sin materializar — el frente de código *"hwObj productor de señales"* que Manuel articuló como guía operativa de P12 durante la sesión s117. La sección agrupa los frentes pendientes con punteros concretos · cada uno es trabajo de sesión posterior, no de esta.

### 10.1 · `puertoHwObj` como embrión de `BindingContract`

**Estado vigente** · campo `puertoHwObj?: string` declarado en `SensorDef` con **0 instancias en catálogo** (T-AU73-3). La auditoría s73 §7.2 articula: *"el campo `puertoHwObj?: string` ya en `SensorDef` es el embrión real del vínculo que estos stubs prometían formalizar"*.

**Pieza pendiente** · cuando T-S67-A1 (rediseño Realm v3) materialice el Bloque 4, los 75 sensores HW (25 × 3) deberían poblar el campo. Sería **primer ejercicio concreto del tipo** · actualmente la pieza tiene articulación sin ejercicio (patrón documentado del proyecto).

**Tensión secundaria registrable** · T-S117-N1 (candidato firme) · *"materialización de `puertoHwObj` en los 75 sensores HW como primer ejercicio del tipo"* · prioridad media · subordinada a T-S67-A1.

### 10.2 · `HardwareProfile` extends `RealmProfile`

**Propuesta vigente** · `lru_realm_v2_dirigido_s63 §3.7` articula esquema concreto:

```typescript
interface HardwareProfile extends RealmProfile {
  firmware: string;       // 'rpc1cl-v2.1.0'
  chip: string;           // 'ESP32-WROOM-32'
  sensors: { [portId: string]: string };
  capabilities?: HardwareCapability[];
  bindings?: BindingContract[];
}
```

**Pieza pendiente** · los 3 ESP32 se modelarían como tres instancias de `HardwareProfile` · los teléfonos y banco motor seguirían el patrón con sus propios firmware/chip/sensors/capabilities.

**Coherencia con el destilado** · `HardwareProfile` materializa estructuralmente las tres encarnaciones de P12 · cada encarnación es una instancia de `HardwareProfile` con propiedades distintas. Esto es la **materialización canónica del Postulado 12** en el schema Realm v3.

**Tensión secundaria registrable** · T-S117-N2 · *"materialización de `HardwareProfile` como subclase de `RealmProfile` con las tres encarnaciones de P12"* · prioridad media-alta · subordinada a T-S67-A1.

### 10.3 · BleAdapter · pieza pendiente del transporte

**Estado vigente** · `LRU_ARQUITECTURA §3.1` cita BleAdapter con estado **"Planificado"**. El firmware `rpc1cl` v2.1.0 ya soporta BLE GATT con 7 tipos de mensaje · el lado del navegador todavía no consume directamente · todo pasa hoy por MQTT y RabbitMQ. La dualidad declarada del firmware es asimétrica con la implementación del navegador.

**Pieza pendiente** · materializar BleAdapter en el CommsManager con la misma interfaz `connect / disconnect / subscribe / publish` que los demás adaptadores. Esto desbloquea conexión directa ESP32 ↔ navegador sin broker intermedio · útil cuando RabbitMQ no está disponible o cuando se quiere evitar latencia de red.

**Tensión secundaria registrable** · T-S117-N3 · *"materialización de BleAdapter para conexión directa ESP32 ↔ navegador"* · prioridad media · independiente de T-S67-A1.

### 10.4 · App de teléfono como hwObj productor

**Estado vigente** · `lru_arqueologia_simil_orquesta_s103 §5` articula: *"Aún sin implementación dedicada para teléfono específicamente, pero la arquitectura las soporta — mismo modelo que ESP32 vía MQTT/BLE"*.

**Pieza pendiente principal del frente** · app PWA o nativa que:
- Publique sensores estandarizados (IMU, GPS, magnetómetro, ambient light, micrófono, cámara) al broker RabbitMQ.
- Use convención de naming `phone_<deviceId>/<puerto>` análoga a `ble_<MAC>/<puerto>`.
- Se anuncie al ORC al conectarse · declare sus capacidades · obtenga asignación de canales.
- Soporte el doble rol del teléfono (humano-con-dispositivo + dispositivo-físico-autónomo) simultáneamente cuando aplique.

**Tensión secundaria registrable** · T-S117-N4 · *"app de teléfono como hwObj productor con publicación estandarizada de sensores"* · prioridad media-alta · pieza independiente de T-S67-A1 · puede materializarse en paralelo.

### 10.5 · UI de teléfono como consumidor multi-pantalla

**Estado vigente** · la PWA principal funciona en teléfono pero no está optimizada para múltiples teléfonos coordinados con vistas parciales del cockpit. Hoy el sistema soporta un usuario único delante de la PWA · multi-teléfono distribuido es horizonte.

**Pieza pendiente** · materializar la articulación s51 *"alumnos en teléfonos cada uno con una parte de señales asignada"*. Implica:
- Mecanismo de descubrimiento · cómo un teléfono que llega a la sesión se anuncia.
- Mecanismo de asignación · instructor (o sistema) decide qué parte del cockpit ve cada alumno.
- UI responsive con vistas parciales pre-configuradas (ECAM solo, PFD solo, sistema hidráulico solo, etc.).
- Sincronización de tiempo · todos los teléfonos viven el mismo presente del DataPlane.

**Tensión secundaria registrable** · T-S117-N5 · *"UI multi-teléfono con vistas parciales coordinadas"* · prioridad baja-media · pieza compleja · subordinada a T-S117-N4 (la app debe existir antes de optimizar UI).

### 10.6 · Convención de gateway industrial para banco motor

**Estado vigente** · banco motor con motor real es presencia ocasional · sin convención canónica de cómo se conecta al CommsManager.

**Pieza pendiente** · articular convención (probablemente en sesión futura cuando aparezca caso real) sobre:
- Gateway industrial (Modbus TCP, OPC UA, CAN gateway) que traduce al CommsManager.
- Mapping canónico `bench_<motorId>/<sensor-real> → <sensorId-Realm-A320>`.
- Modo de validación cruzada (simulación + motor real corriendo en paralelo · comparación · twin testing).

**Tensión secundaria registrable** · T-S117-N6 · *"convención de gateway industrial para banco motor con mapping a Realm aviation"* · prioridad baja · esperando caso real · independiente de demás frentes.

### 10.7 · Prioridades sugeridas del frente · 6 piezas

Sin arbitrar todavía por Manuel · ofrezco lectura ordenada:

| Tensión | Pieza | Prioridad propuesta | Bloqueada por |
|---|---|---|---|
| T-S117-N4 | App teléfono productor | Media-alta | Independiente |
| T-S117-N2 | `HardwareProfile` extends `RealmProfile` | Media-alta | Subordinada a T-S67-A1 |
| T-S117-N3 | BleAdapter | Media | Independiente |
| T-S117-N1 | `puertoHwObj` poblado | Media | Subordinada a T-S67-A1 |
| T-S117-N5 | UI multi-teléfono | Baja-media | Subordinada a T-S117-N4 |
| T-S117-N6 | Gateway industrial banco motor | Baja | Independiente · espera caso real |

**Lectura del frente como bloque**: las dos piezas independientes (T-S117-N4 app teléfono · T-S117-N3 BleAdapter) podrían materializarse antes que el rediseño Realm v3. Las dos subordinadas (T-S117-N1 · T-S117-N2) esperan a T-S67-A1. La UI multi-teléfono es horizonte. El gateway motor es horizonte profesional ocasional.

Esto es **propuesta de lectura · no compromiso** · Manuel arbitra cuando proceda.

---

## 11 · Tensiones articuladas en s117

### 11.1 · T-S117-F1 · siembra de la 7ª cristalización fundacional

**Tensión arquitectural mayor** · análoga a T-S67-A1 (siembra P1-P5) · T-S69-F (siembra P6-P9) · T-S74-F (siembra voz fundacional + pluralidad de inteligencias) · T-S84-F1 (siembra P10) · T-S85-F1 (siembra pluralidad de realms) · T-S97-F1 (siembra estructura sectorial).

**Articulación** · `lru_postulado_12_hardware_fisico_sustrato_s117.md` (este destilado) sembrado en s117 · pendiente de integración al núcleo en sesión posterior siguiendo el patrón "destilado fundacional → integración al núcleo" (8ª aplicación tras s68, s70, s76, s89, s91, s99 y la potencial integración de P11 si se cristaliza formalmente).

**Lectura preferente para integración** · P12 vivirá probablemente como `LRU_FUNDAMENTOS §12bis` o `§14` (numeración a decidir en la sesión de integración). El §11ter (pluralidad de realms) y §11bis (pluralidad de inteligencias) son los precedentes estructurales más cercanos.

**Regla de disputa** · activa hasta integración al núcleo (T-S117-F1 abierta).

**Estimación de complejidad de integración** · sesión densa · ~3-4 horas · paralelo a las integraciones anteriores. Comparable a la integración s89 de §11ter (que tomó sesión densa con preservación de 2 citas gold y 4 subsecciones).

### 11.2 · Tensiones secundarias del frente hwObj productor (registradas en §10)

Cinco tensiones nuevas articuladas en s117 que orientan el frente operativo:

- **T-S117-N1** · materialización de `puertoHwObj` en los 75 sensores HW · prioridad media · subordinada a T-S67-A1.
- **T-S117-N2** · materialización de `HardwareProfile` como subclase de `RealmProfile` · prioridad media-alta · subordinada a T-S67-A1.
- **T-S117-N3** · materialización de BleAdapter para conexión directa ESP32 ↔ navegador · prioridad media · independiente.
- **T-S117-N4** · app de teléfono como hwObj productor · prioridad media-alta · independiente.
- **T-S117-N5** · UI multi-teléfono con vistas parciales coordinadas · prioridad baja-media · subordinada a T-S117-N4.
- **T-S117-N6** · convención de gateway industrial para banco motor · prioridad baja · independiente · espera caso real.

Las seis tensiones merecen registro formal en `LRU_TECH_DEBT_s117.md` al cierre de sesión.

### 11.3 · Hallazgo meta · once sitios articulando una pieza estructural sin consolidación

Hallazgo meta de la sesión s117 que merece registrarse como observación metodológica:

**El proyecto puede sostener piezas estructurales distribuidas sin consolidación canónica durante muchas sesiones**. P12 estuvo presente operativamente desde s53 y articulado en once sitios distintos al cierre de s117 (12 sesiones después tras 117 sesiones totales) sin haber sido cristalizado unitariamente. La consolidación llegó cuando (a) el corpus alcanzó madurez suficiente · (b) un frente operativo concreto (hwObj productor) empezó a presionar · (c) la metodología (RAG + cruce arqueológico) permitió detectar la dispersión.

Implicación metodológica preservable · *"La cristalización fundacional emerge cuando converge presión operativa + madurez del corpus + capacidad de cruce arqueológico"*. Esto es ejercitación del patrón documentado del proyecto · *"el instinto produce; la disciplina articula"*.

**Tensión meta registrable** · T-S117-M1 · *"patrón de cristalización tardía detectado · documentar como observación metodológica en LRU_METODO si emerge segunda instancia clara"* · prioridad mínima · candidato a sub-patrón si emerge segunda ejercitación.

---

## 12 · Pie del destilado

### 12.1 · Métricas

| Métrica | Valor |
|---|---|
| Líneas estimadas del destilado | ~600 (sin meta de líneas · la pieza pidió esto) |
| Citas verbatim preservadas | 11 totales · 7 de Manuel + 4 articulaciones canónicas del corpus |
| Sesiones referenciadas | 53 · 56 · 60 · 63 · 65 · 67 · 69 · 71 · 73 · 74 · 76 · 79 · 84 · 85 · 86 · 89 · 90 · 91 · 95 · 96 · 97 · 99 · 100 · 101 · 102 · 103 · 104 · 116 · 117 |
| Documentos del corpus cruzados | 11 sitios principales (5 canónicos + 6 destilados) |
| Encarnaciones físicas articuladas | 3 · microcontrolador + teléfono + banco motor |
| Tensiones nuevas registradas | 7 (T-S117-F1 + 6 secundarias en §10/§11) |
| Postulados existentes refinados | 7 (P1, P5, P6, P9, §2.3, §11ter, §11bis, §12) |
| Código tocado | 0 (destilado conceptual · materialización en sesiones posteriores) |

### 12.2 · Sesiones referenciadas con material material directo

- **s53** · cita gold fundacional sobre dispositivos intercambiables · cita gold concepto twin · cita complementaria cimientos robustos y flexibles · cita complementaria protocolos como acuerdo · cita complementaria señales como base universal.
- **s56** · deploy schema Realm v2 con 18 entities + 4 derivados + 4 taxonomy + 2 scenarios + 4 faults + 2 profiles.
- **s63** · destilado `lru_realm_v2_dirigido_s63.md §3.7` propone `HardwareProfile extends RealmProfile`.
- **s67** · postulados fundacionales P1-P5.
- **s69** · cita gold FPGA · destilado `lru_postulados_6_7_8_9_s69.md §1.4`.
- **s73** · auditoría empírica · T-AU73-1 corrige conteos a 25/75/202.
- **s84** · postulado 10 · diseño como innovación.
- **s85** · pluralidad de realms cristalizada.
- **s89** · pluralidad de realms integrada al núcleo como §11ter.
- **s116** · plan provisional sesión cruzada Realm · semilla de la sesión s117.
- **s117** · esta sesión · cristalización P12.

### 12.3 · Paternidad arqueológica del Postulado 12

P12 **no tiene paternidad puntual** en una sesión específica · su paternidad está distribuida arqueológicamente:

- **Paternidad conceptual fundacional** · s53 · cita gold de Manuel sobre dispositivos intercambiables.
- **Paternidad técnica del microcontrolador** · paternidad técnica desplegada s24-s28 (CommsManager + RouterService + ControlBus operativos).
- **Paternidad técnica del teléfono** · s51 (primeros apuntes orquesta distribuida) + s53 (frase fundacional) · sin implementación dedicada todavía.
- **Paternidad técnica del banco motor** · presencia ocasional sin sesión específica de cristalización.
- **Paternidad de la articulación canónica** · s117 · esta sesión.

Esta dispersión es **propiedad del postulado**, no defecto de su paternidad. P12 articula material que se ha mantenido funcional distribuidamente durante 64 sesiones desde s53 hasta s117 sin necesitar consolidación canónica. La cristalización en s117 es **articulación retrospectiva** del patrón ya operativo.

### 12.4 · Regla de disputa explícita

Mientras la integración al núcleo no se ejecute (T-S117-F1 abierta), si algún canónico del núcleo entra en conflicto con este destilado sobre el material articulado aquí, **gana este destilado** — es la fuente original de P12 con las 11 citas gold preservadas. Tras integración al núcleo, la regla de disputa se retira · las citas gold cruzan al núcleo con voz reconocible · este destilado pasa a referencia histórica post-materialización.

### 12.5 · Hermanos del destilado

- `lru_postulados_fundacionales_s67.md` (P1-P5) · referencia histórica post-integración s68
- `lru_postulados_6_7_8_9_s69.md` (P6-P9) · referencia histórica post-integración s70
- `lru_voz_fundacional_s74.md` (voz fundacional + pluralidad de inteligencias) · referencia histórica post-integración parcial s76
- `lru_atachapterdef_refactor_s85.md` (semilla pluralidad de realms) · referencia histórica post-integración s89
- `lru_postulado_10_diseno_como_innovacion_s84.md` (P10) · referencia histórica post-integración s91
- `lru_estructura_sectorial_s98.md` (estructura sectorial) · referencia histórica post-integración s99
- **`lru_postulado_12_hardware_fisico_sustrato_s117.md`** (P12 · este destilado) · **regla de disputa activa hasta integración**

### 12.6 · Cita final · calibración perpetua de la colaboración

Cita gold s53 que cierra el destilado como recordatorio del modo correcto de trabajar:

> *"Soy fiable cuando me cuestionan; soy peligroso cuando me siguen sin cuestionar."*
>
> — Manuel, s53

Esta cita es **calibración perpetua** del patrón de colaboración Manuel·Claude. Aplica a la lectura de este destilado: cuestionarlo activamente al integrar es disciplina necesaria · seguirlo sin cuestionar sería falta de cuidado.

---

*LRU Platform · Destilado fundacional anillo 2 · Postulado 12 · El hardware físico es sustrato del sistema · s117 · 2026-05-03 · Manuel & Claude Opus 4.7 · 7ª cristalización fundacional del proyecto · regla de disputa activa hasta integración al núcleo (T-S117-F1)*