# LRU · Catálogo del Anillo 2 — destilados vigentes

**Documento vivo del anillo 1.B.2 · sin sufijo de sesión · accesible vía MCP filesystem · sincronizado al cierre de s246** (entrada de la referencia operativa del rescate s246 añadida al inicio de §1.2.1 · anterior s245 · deuda documental conocida: los destilados s239-s242 — diseño RpcClient s239 · cliente RPC completado s240 · estudio memoria/pines s241 · dormidos s242 — están en índice/ESTADO/git pero sin entrada aquí todavía · cuerpo del catálogo última sincronización masiva s162 · deuda s168-s229 conocida · patrón de actualización periódica vigente)

Externalizado desde §1.2 del MAPA en s129 (palanca N · etapa 2). Cualquier nuevo destilado se cataloga aquí · no en el MAPA. Cuando un destilado cambia de estatus funcional se actualiza la entrada aquí.

Estado al cierre s162: 60+ ítems en 8 sub-categorías. 11 aplicaciones disciplina alfiler s125 acumuladas (s125 realms · s128 externalización · s134 director · s145 registry · s151 nomenclatura · s152 dataplane viewer · s155+s156+s157 observatorio · s157 facetas multi-vista · s158 destilado API consultora · s159 consumidor inaugural · **s162 enlaces sustrato**). **Camino Y firme con 4 aplicaciones limpias** (s159 consumidor inaugural + s160 API consultora materializada con audit empírico previo + s161 articulación Cat.6 con audit empírico previo al strawman + **s162 materialización Cat.6 con audit empírico que refina contrato del destilado**) · candidato muy firme a formalización en `LRU_METODO`. **s162 añade 2ª aplicación operativa de P13 candidato** (la 1ª fue API consultora materializada s160 · sumadas 2 aplicaciones operativas + 2 articulatorias s158+s161). **Sub-patrón emergente s162 · 1ª instancia**: "audit empírico previo refina contrato del destilado".

---


#### 1.2.1 · Canónicos acumulativos

* `lru_rescate_referencia_operativa_s246.md` — **destilado anillo 2 s246 · rescate y actualización de la S3: referencia operativa (firmware 0.246.3) · el CÓMO del plano de rescate tal como está construido** · complementa al diseño s245 (el porqué): mapa de decisión por síntoma · piezas (portal AP + clave derivada + cautivo/QRs + panel de operación + OTA local con `rescue_pending` y salud broker-O-portal + vigilante-péndulo + otalog v2 con origen/hora) · operación paso a paso desde el móvil (asociarse · cambiar WiFi · pantalla remota · flashear · confirmar · rollback automático) · el vigilante en la práctica con perillas `rescueN/T/M/H` · ciclo de actualización normal referenciado · **procedimiento de banco P1-P6** con logs esperados y criterios ✔ (PENDIENTE de ejecutar · TD-s246-1) · tabla de perillas/valores 0.246.3 · límites de seguridad asumidos · regla de disputa: gana el banco y se corrige aquí · hermano del diseño s245, dormidos s242 y `LRU_FIRMWARE_PUBLICACION_VIVO.md`.

* `lru_diseno_portal_rescate_s245.md` — **destilado anillo 2 s245 · portal AP de rescate: plano de rescate completo de la S3 · DISEÑO con regla de disputa · rebanada B1 MATERIALIZADA y validada en banco (0.245.1→0.245.4)** · el anillo 2 de actualización (D-s242) crece a plano de rescate: cuando la placa no llega a su mundo, ella se convierte en el mundo (softAP + página de operación) · decisiones arbitradas: **D-s245-A** salud de la OTA local = broker O portal confirmado (+ flag NVS `rescue_pending`) · **D-s245-B** user_off inhibe al vigilante · **D-s245-C** orden B1→B2→B3 · activación redundante (manual APSTA · Ap.On/Ap.Off por dispatcher · vigilante-péndulo NORMAL→RESCATE→REINTENTO con histéresis y TTL congelable, perillas N/T/M/H) · clave WPA2 **por dispositivo** derivada del id (HMAC truncado · espejo en PWA · límite del secreto horneado nombrado) · página embebida = panel (config WiFi s234 + OTA local + captura + táctil) · enmienda en sesión: portal cautivo SÍ en B1 (DNS+DHCP 114/capport; techo móvil-dependiente documentado TD-s245-2; QRs como cura universal) · B1 en placa: esp_ap_port + panel /wifi + /touch + lru_bar como cadena de comunicaciones + QRs · hermano de `lru_dormidos_memoria_s242.md` y `lru_eje_plano_mando_unificado_s237.md`.

* `lru_eje_plano_mando_unificado_s237.md` — **destilado anillo 2 · eje s237 · plano de mando unificado: dispatcher común, RPC por BLE y observabilidad · VIGENTE (código validado en placa, no regla de disputa)** · cristaliza el eje construido en s237 y **validado en banco en s238**: el firmware S3 pasó de tener canales de mando (MQTT único) a un **plano de mando** — un dispatcher `lru_cmd_dispatch(via,method,args,…)` donde la lógica vive UNA vez y MQTT, BLE/GATT, la UI local y el loopback son transportes finos · secciones: dispatcher común (composición separada de publicación · contrato MQTT intacto) · vocabulario **espejo LRU** (D-s237-A: Status.Get/Cfg.Set/Act/ActState.Get/Sys.Reboot/Ota.Cmd/OtaLog.Get/Ui.* + alias Sys.GetInfo · los built-ins mgos dan 404) · transporte BLE `esp_ble_rpc_port` (UUIDs mOS + framing BE32 byte a byte del clásico · sobre `{v:2,src,dst?,id,result|error}`) · **saga DRAM interna** (NimBLE host a PSRAM · controller 34K no movible · recaída de la cámara en s238 · P11 LVGL /16) · observabilidad (tiles BLE/RPC · `cmd_note` lengua franca · self-test loopback = germen del twin) · captura remota `esp_shot_port` (lv_snapshot de pantalla · lección EAGAIN/power-save) · **validación banco s238** (8 métodos GATT ok · DRAM reposo ~19-20K) con **dos lecciones portables al Candidato D**: serializar operaciones GATT (el firmware notifica antes del write-response) + hablar espejo, no clásico · forks abiertos: sobre LRU-RPC fino · cliente RPC PWA · optimización cámara↔BLE (TD-s238-1) · hermano de `lru_eje_realimentacion_actuacion_s216.md` y `lru_puerto_s3_espidf_s224.md`.

* `lru_analisis_ble_pwa_s236.md` — **destilado anillo 2 s236 · análisis de conectividad BLE PWA↔placa como canal de resiliencia + adopción del patrón RPC como pieza transversal de la plataforma** · hallazgo central verificado contra el build real 0.235.1: **el clásico YA habla RPC por BLE** (rpc-gatts + bt-common/NimBLE desplegados en toda la flota · el prefijo `ble_` ES el advertising) · matiz `bt.keep_enabled=false`: el canal de rescate existe exactamente cuando más se necesita (placa huérfana) · protocolo mOS-RPC-over-GATT documentado (§3: UUIDs + framing BE32) · vías A-D con recomendación (cliente mOS-RPC en la PWA · el BleAdapter UART-style no sirve tal cual) · modelo §5: *«BLE es canal de mando y rescate, no de transferencia masiva — la placa huérfana se repara la WiFi por BLE y se OTAa sola por HTTP»* · capas de adopción 0-4 con gates · **D-s236-C**: paridad S3 como frente firme (§7bis · mismo servicio sobre NimBLE como transporte fino hacia los handlers MQTT existentes) · **D-s236-D**: el patrón RPC = pieza transversal abierta y reutilizable (§7ter · 8 aprovechamientos: RpcClient genérico · twin por loopback · Caps.Get · tap Analyzer · ver+ACL · paginación · Web Serial · encarnaciones) con guardarraíl incremental · riesgos nombrados (Chromium/HTTPS · iOS no · frame 4096 · sec_level 0 = 7º motivo hilo seguridad · coexistencia radio TDM) · acompañado por la PoC de banco `lru_poc_ble_rpc_s236.html` (cliente Web Bluetooth standalone del protocolo completo · picker ble_*/s3_* · pendiente de banco TD-s236-1).

* `lru_plan_migracion_broker_s231.md` — **destilado anillo 2 s231 · plan operativo de migración del broker MQTT a la máquina `.102` · materializa la rebanada R2 del alfiler de resiliencia s230** · estado al cierre s231: **preparación COMPLETA Y ENSAYADA, cutover pendiente de sesión dedicada** · foto real de máquinas y NAT (el vivo es la `.200` = RabbitMQ 3.13.3 nativo solo-broker; el router traduce WAN 8080→LAN 21883 — primario y respaldo de la flota son el mismo listener) · gates superados: definitions.json con 6 usuarios hasheados + espejo `21883:1883` en compose + gemelo wss vía Caddy catch-all `:15676` TLS → web-mqtt · ensayos T1-T6 verdes en 1883 y 21883 + wss OK (scripts `test-broker-nuevo.mjs` / `test-wss-local.mjs` / `sonda-broker-viejo.mjs` en `pwa6/scripts/`, semilla de R6) · sonda S2 desactivó D-abierta-6 (el broker viejo tampoco entrega retained a `#`) · **§3bis checklist ejecutable del día D**: 3 cambios de IP en reglas NAT + empujón a la flota (no-failback H1/H2) + prueba OTA + la `.200` queda de respaldo (L1/L2 separadas) + rollback en minutos.

* `lru_alfiler_resiliencia_comunicaciones_s230.md` — **REVISADO en s231 (R0 ejecutada · §1bis con hallazgos H1-H6)**: no-failback en ambas clases · GATT del clásico compilado pero apagado PERSISTENTE (`bt.keep_enabled=false` + `save_cfg` al primer IP — L3 muerta en toda la flota provisionada) · PWA reintento 1 s a endpoint único y publish que descarta · foto real de brokers (H5) · retained+wildcard (H6, degradado a teórico por sonda) · R2 abierta y casi consumada · D-abierta-6 nueva→teórica · **alfiler de estudio y estadificación s230 · resiliencia y tolerancia a fallos de comunicaciones · documento VIVO por diseño (se completa en sesiones futuras)** · nace tras validar en placa el criterio de salud + rollback automático en ambas clases (el precedente que demuestra el patrón: contemplar el fallo, ensayarlo a propósito, ver al sistema defenderse solo) · postulado destilado (Patrón 3, verbatim Manuel): «ningún fallo único de comunicaciones debe suponer una situación crítica» · inventario del sustrato existente (doble broker en ambas clases · BLE GATT clásico · AP emergencia · salud OTA multi-broker) con el hallazgo de que el hueco gordo es la PWA sin failover · taxonomía de fallos F1-F5 (simple/TLS/sin-internet/catastrófico/junto-al-hardware) × escalera de capas L0-L4 (broker principal→alternativo→local→BLE→AP+USB) con matriz de supervivencia · rebanadas R0-R6 todas con trigger y ninguna abierta (P11) · 6 invariantes («cada capa degrada capacidad, nunca la miente» · «toda degradación es observable» · «la vuelta al cable siempre existe» P12) · 5 D-abiertas · tensión umbrella T-S230-RESILIENCIA-COMS · hilo hermano seguridad/autenticación anotado sin abrir.

* `lru_destilado_paso3_override_modo_s167.md` — **destilado anillo 2 s167 · paso 3 del hilo de unificación del arbitraje (override ↔ modo per-sensor)** · refina el paso 3 del alfiler s165 con hallazgo empírico (D-s111-1) tras auditoría de `SimService.ts`/`MixerPanel.tsx`/`registryMqttHandlers.ts` · **hallazgo central**: el override del Mixer (botones ❄ Freeze / ↻ Release → `startOverride`/`setOverride`) es **inyección manual *dentro* de Gen** (sale como `'sim1'`), NO un switch Real↔Gen · corrige el resumen §7.5 de la referencia s165 (sub-patrón "resumen documental sobrevive al cableado real") · fija el **modelo de dos slots** (sim vs hw · Modo A/B de la aguja) y **Gen como familia** (sub-generadores motor/manual/random/SignalLab aguas arriba en `valuesRef`; Real↔Gen = dimensión enlace) · articula la **rebanada vertical** como primera materialización de Lectura B sin tocar IB_04 (enlazar→Real + enforcement local, leyendo por el Modo B existente) · valora la **idea del dropdown per-sensor del Mixer** (Manuel s167) como paso 5 y productor de modos human-facing que absorbe el botón override · deja la decisión §8.3 (un slot vs dos) sobre la mesa con **recomendación híbrida** (mantener canales hw crudos como telemetría + enrutar el hardware enlazado al slot de señal → evita la colisión `_sensorIdToIndex`, de-riesga el paso 4) · **regla de disputa**: hilo activo del paso 3 hasta que la rebanada se materialice · **VALIDADO sobre hardware real A92418 en s167** (parpadeo capturado, cuantificado y curado con gate selectivo) · acompañado por `lru_handoff_s167_s168.md` + `LRU_TECH_DEBT_s167.md`.

* `LRU_TECH_DEBT_s167.md` — **deuda técnica vigente al cierre de s167** (ancla activa). Sesión de código · paso 2 del hilo de unificación completo (sombra → default de arranque → gate selectivo) + rebanada vertical Lectura B validada sobre A92418. **T-S167-N1** nueva (diagnóstica: `'sim1'` de alta frecuencia sobre canales hw incluso sin Play · productor no localizado) + §8.3 (recomendación híbrida) + gate completo pendiente (tras más sombra) + productor de modos automático (enlazar→Real en ORC) como frente s168.

* `lru_alfiler_enlaces_sustrato_s162.md` — **alfiler arqueológico-arquitectural s162 · naturaleza dual de `enlaces` como sustrato vs estado de UI** · 14.55 KB · 10 secciones · disciplina alfiler s125 · **11ª aplicación operativa** · articulado en bloque previo a la materialización Cat.6 como respuesta arquitectural diferida a la pregunta D5 · captura la voz fundacional de Manuel s162 (cita verbatim de 5 articulaciones simultáneas: alcance global · cardinalidad mutación baja · función estructural · puente dos universos · persistencia transversal) en §0 · distingue **naturaleza** vs **localización** del objeto (sustrato vs Context no es de localización sino de natural) · 4 de 5 características de sustrato alinean con `enlaces` · frente NO abierto hoy · trigger empírico T1 (segundo lector síncrono externo) / T2 (lectura síncrona fuera React tree) articulados · promoción a singleton `getEnlacesPlane()` análogo a `getDataPlane()` diferida con refactor trivial A→B1 (1 línea en `facetEnlace.ts`) · hereda diálogo con T-S161-DOC-1 (si B1 se materializa, T-S161-DOC-1 reformulada de "doble representación redundante" a "tres representaciones con disciplina") · **regla de disputa pasiva** (NO gana sobre código · material conceptual de referencia) · T-S162-ENLACES-SUSTRATO candidata sembrada · NO bloqueante.

* `LRU_TECH_DEBT_s162.md` — **deuda técnica vigente al cierre de s162** (ancla activa). Sesión mixta articulatoria + materialización Cat.6 enlace.

* `lru_destilado_facetas_cat6_enlace_s161.md` — **destilado anillo 2 s161 · articulación 6ª catalogación Cat.6 enlace N:M aguja↔sensor · MATERIALIZADO EN s162** · 38.52 KB · 13 secciones · articula la 6ª catalogación con sujeto binario (swObj↔hwObj) frente a las 5 previas con sujeto unario sensor · audit empírico previo al strawman de 7 ficheros del repo (D-s111-1) con 5 hallazgos primarios + 2 descubrimientos articulatorios · **5 decisiones de diseño D-Q1..Q5 arbitradas una a una por Manuel** · átomo `EnlaceValue = {swObjId, hwObjId, channelMap, activeChannels}` (D-Q1=A) · id `'enlace'` label `'Enlace'` (D-Q2=A) · filtros planos `enlaceFrom`/`enlaceTo` AND implícito en query (D-Q3=A) · output uniforme `sensorId[]` siempre (D-Q3.bis=ii) · **D-Q4=B extensión del contrato `Facet` con `kind` discriminante** (`'sensor' | 'edge'`) = decisión arquitectural mayor · materialización lazy pura (D-Q5=A) · **MATERIALIZADO EN s162 según plan §11** (6 pasos ejecutados · contrato extendido + 3 firmes migradas a `kind:'sensor'` + `facetEnlace.ts` nuevo + `query()` extendido + 12 tests unit nuevos + factoría `createRegistryWithEnlaces` por inyección D5=A) · refinamientos del destilado emergentes en s162: D1=B `to(hwObjId): EnlaceValue[]` ergonómico sobre forma menor pendiente del destilado §6.4 · D5=A inyección sobre asunción implicit del strawman §6 de getter singleton inexistente · helper `expandEnlaceToSensorIds` materializado exportado desde `types.ts` (descomposición channelMap en sensorIds) · cierre operativo T-S160-CAT6-CAND por materialización (mismo patrón canónico que T-AU73-4 s81→s83 y T-S151-N2 s158→s160) · **regla de disputa sólo activa sobre lo no materializado** (consumidor inaugural Cat.6 diferido a sesión posterior según Camino Y estricto) · 0 cambios src/ s161 · 8 ficheros src/ s162.

* `LRU_TECH_DEBT_s161.md` — **ancla anterior · superada por s162**. Sesión articulatoria pura · 6ª catalogación Cat.6 articulada · destilado producido sin código · 5 decisiones D-Q1..Q5 arbitradas · contrato `Facet` extendido con `kind` discriminante = decisión arquitectural mayor · Camino Y 3ª aplicación limpia.

* `lru_destilado_api_consultora_materializada_s160.md` — **destilado anillo 2 s160 · cierre del consumidor previsto del destilado s158** · 22.5 KB · articula materialización efectiva de la API consultora multi-faceta en `src/realm/queryFacets/` con 3 facetas firmes (quantity · ata · hwObj v1) + 2 diferidas (protocol · tipoSensor) + 1 candidata sembrada (Cat.6 enlace) · **cierre operativo T-S151-N2 por absorción arquitectural** (5º modo de cierre articulado en s160) · **cita gold s160 preservada (Patrón 3)**: *"el panel enlaces es la llave para unir ambos mundos"* (Manuel s160) · **4 ajustes empíricos al strawman s158 documentados con rationale** (A `allSensors()` delega DataPlane · B Cat.4 protocol diferida por arrastre de imports `a320.realm.ts`+Zod+EASA · C Cat.5 tipoSensor diferida por dependencia ObjectRegistry · D Cat.1 ATA derivada iterando SIM_CATALOG no por declaración en ATA_CATALOG) · ajuste empírico adicional emergente al integrar consumidor inaugural: **elevación del filtrado al shell** (sub-patrón 1ª aplicación operativa) · **disciplina Camino Y honrada en 2ª aplicación limpia** (los 4 ajustes A-D solo emergieron por tener Observador1 v1 vivo desde s159) · **T-S160-CAT6-CAND firme sembrada · CERRADA OPERATIVAMENTE s162 por materialización** · **T-S160-CAT3-A menor sembrada** (Cat.3 v1 no proyecta Universo A con `puertoHwObj?`) · **regla de disputa activa**: en cualquier conflicto entre este destilado y el s158, este gana hasta que se integre al núcleo · 14 ficheros desplegados s160 (7 nuevos `queryFacets/*.ts` + 3 docs + 4 modificados Observador1) · build verde 2185 módulos + 25/25 tests unit + validación funcional confirmada por Manuel.

* `LRU_TECH_DEBT_s160.md` — **ancla anterior · superada por s161**. Sesión densa de implementación · materialización API consultora multi-faceta articulada como strawman en destilado s158. **14 ficheros desplegados** · build verde 2185 módulos + 25/25 tests unit + validación funcional confirmada por Manuel. **3 facetas firmes materializadas** + 2 diferidas + 1 candidata sembrada. **Disciplina Camino Y honrada en 2ª aplicación limpia**. **5º modo de cierre articulado** (cierre operativo por absorción arquitectural · T-S151-N2 cerrada). **Sub-patrón emergente 1ª aplicación** (elevación del filtrado al shell).

* `LRU_TECH_DEBT_s150.md` — **deuda técnica vigente al cierre de s150** (ancla activa). Sesión productiva con 2 frentes de código (drag-to-edge multi-grid · compactación automática tras drag insert) + 1 frente articulatorio (descubrimiento documental fuentes Enlaces vs Systems · cero código). **2 ficheros tocados** (`usePanelDrag.ts` 9 ediciones + `gridReducer.ts` 3 ediciones · 12 edits totales). **SIN aplicaciones nuevas del patrón canónico** "lego neutro + wrapper per-host" (sigue en 9). **SIN aplicaciones nuevas de la doctrina** "doble vida modal+grid" (sigue en 5). **SIN aplicaciones nuevas del contrato D-s140-G** `useAtlasPassthrough` (sigue en 10). Sesión de **bug-fixing estructural del PanelGrid · no de cristalización canónica**. **Frente 1 · drag-to-edge multi-grid cerrado con reclassificación T-S149-DRAG-EDGE**: audit empírico contra copia viva `pwa6_2005` demostró que NO era regresión sino **cobertura parcial original nunca completada** · `atlas.css` + `usePanelDrag.ts` byte-idénticos entre copia rota y copia funcional · solo conflicto (3) del diagnóstico s149 era real (`document.querySelector('.pg-grid')` global devolvía siempre el primer grid del DOM) · conflictos (1) y (2) eran narrativa sin auditar · D-s150-DRAG opción B: cachear `sourceGridEl` en `stateRef` + propagar a `findDropTarget`/`clearAllIndicators`/`setIndicator` · drag funciona en todas las celdas Atlas (Sim1+Sim4). **Frente 2 · compactación automática tras drag insert**: audit grep `compactGrid|removePanelFromSlots` reveló 3 cases drag-related desactivando explícitamente `shouldCompact:false` (INSERT_EDGE · INSERT_BETWEEN · FILL_CELL) generando filas/columnas fantasma · D-s150-COMPACT opción B aplicada: cambio `false→true` en los 3 cases con comentarios justificativos sobre por qué los cálculos posteriores siguen siendo correctos post-compact (slots viven en 1..N consecutivos tras compactar) · validación empírica Manuel: *"correctos compactan bien"*. **Frente 3 articulatorio · descubrimiento documental fuentes Enlaces vs Systems**: SystemsPanel consume `sim-catalog.ts` estático (IDs neutros `eng`/`bleed` + labels legibles) · EnlacesPanel consume `RegistryContext` runtime poblado por `SimServiceReact.ts` que llama a `SimService.ts:148` con constante `SIM_HWOBJ_PREFIX = 'sim1_'` aplicada en línea 437 `\`${SIM_HWOBJ_PREFIX}${systemId}\`` · hallazgo importante del comentario línea 1102: `// s28: solo registrar hwObjs virtuales sim1_* — los ble_* los registra el ORC` revela que `sim1_` **NO es deuda accidental sino namespace deliberado** para distinguir hwObjs de simulación de hwObjs reales bluetooth · lo que NO se hizo al llegar Sim4: crear namespace `sim4_*` paralelo o renombrar a `sim_*` genérico · abre **T-S150-N1 media** con 4 opciones articulatorias pendientes (renombrar neutro · renombrar semántico · capa label cosmética · migrador localStorage v1→v2) · acoplada con T-S149-SEMANTICA-SENALES · candidato a sesión articulatoria conjunta D-s15N-NAMING · cero código tocado · cita Manuel arbitral: *"cerremos s150 con este descubrimiento solo documentado para sesión futura"*. **Lección operativa s150 cristalizada · audit cruzado con referencia funcional vale más que análisis interno**: el handoff s149 demostró el caso negativo con su "diagnóstico empírico de 3 conflictos" que resultó tener 2 erróneos al auditar contra copia funcional · *"cuando exista una copia funcional, comparar byte-a-byte con la versión rota es el camino más rápido al diagnóstico real"* · candidato a formalización en LRU_METODO si emerge 2ª aplicación. **Sub-patrón candidato a catálogo · "feature percibida como regresión que era cobertura parcial original"**: 1ª instancia documentada (drag-to-edge multi-grid · A-1 sí funciona desde siempre · resto de celdas nunca cubierto) · si emerge 2ª instancia, candidato a catálogo formal. **Anti-anticipación P11 ejercitada limpiamente** · D-s150-COMPACT-MANUAL opción D (descartado tanto botón "Compactar" como compactar SHRINK_SLOT · Manuel arbitró: *"vale de momento no lo añadimos si en el futuro hace falta lo vemos"*). **Decisiones arbitrales**: D-s150-DRAG-1/2/3 + D-s150-COMPACT + D-s150-COMPACT-MANUAL + D-s150-NAMING. **1 tensión nueva** (T-S150-N1 media · prefijo sim1_) · **1 tensión cerrada con reclassificación** (T-S149-DRAG-EDGE). **Documentos de cierre**: `LRU_TECH_DEBT_s150.md` (este ancla) + `lru_handoff_s150_s151.md` (handoff con 5 frentes propuestos para s151) + actualización de los dos vivos `LRU_CATALOGO_ANILLO2_VIVO` + `LRU_TENSIONES_ABIERTAS_VIVO`.

* `LRU_TECH_DEBT_s149.md` — **ancla anterior · superada por s150**. Sesión densa con 5 frentes (borde slider override SystemsPanel · scroll horizontal presetbar PanelGrid · lego SignalTreePanel completo con 3 caras funcionales · 2 bugs TechModal minimizar · cambio cosmético Explorador→Sensores). **23 ficheros tocados** (12 modificados · 11 nuevos · 2 zombi marcados). **9ª aplicación del patrón canónico "lego neutro + wrapper per-host"** (Mixer s120 · Chart s121 · Transport s124 · Signals s130 · SignalLab s131 · Systems s146 · Scenarios s146 · Fallos s147 · SignalTree s149). **5ª aplicación formal de la doctrina "doble vida modal+grid"** (Scenarios s146 · Fallos s147 · Systems s147 · Displays s147 · SignalTree s149) · con esta T-S146-N3 acumula 5 instancias formales · destilado canónico Anillo 2 cada vez más justificado. **10ª aplicación del contrato D-s140-G `useAtlasPassthrough`** tras añadir PanelGridPresetBar + SignalTreePanel · regla operativa firme derivada: *"Los legos compartidos en `components/panels/*` que tengan `overflow` propio (vertical u horizontal) DEBEN llevar `useAtlasPassthrough()` por contrato canónico"*. **Decisión arbitral D-s149-MODAL** · SignalTreeModal usa TechModal canónico tras debate exhaustivo en 4 iteraciones · PRIMER modal del Anillo 2 que usa TechModal · los 4 hermanos siguen con backdrop+panel por inercia histórica (s146-147) · cita arbitral Manuel: *"TechModal es mucho mas completo y versatil"* · abre T-S149-MODAL-CANONICO para migrar hermanos en sesión articulatoria futura. **Frente extra: diagnóstico empírico T-S149-DRAG-EDGE** (3 conflictos identificados · drag-to-create-column no funciona · sesión dedicada s150 · **cerrada en s150 con reclassificación: NO era regresión sino cobertura parcial original demostrada por audit cruzado contra `pwa6_2005`**). **Cambio cosmético "Explorador"→"Sensores"** en 5 sitios visibles · abre T-S149-SEMANTICA-SENALES con taxonomía emergente sensores/actuadores/señales (cita Manuel preservada) · **acoplada con T-S150-N1 en s150**. **Ejercicio ejemplar de honestidad técnica**: cuando Manuel desafió el análisis inicial sobre TechModal vs backdrop+panel, Claude auditó empíricamente y reconoció 4 errores en su análisis · lección operativa firme: *"Cuando Manuel desafía un análisis, Claude debe auditar empíricamente el código antes de defender la hipótesis original"*. **`useLongPress` promovido a `panels/shared/`** (sitio neutro común tras debate filosófico Manuel sobre acoplamiento vs duplicación). **Bugs TechModal minimizar** corregidos: snap durante drag con altura real DOM vía `panelRef.current.offsetHeight` (opción B preferida sobre hardcoded) + reposicionamiento al restaurar con clamp pre-restore. **Cita de validación Manuel s149**: *"funciona"* (Frente 4 cierre) · *"funciona bien"* (Frente 3 + 4 cierre completo). **Documentos de cierre**: `LRU_TECH_DEBT_s149.md` (este ancla) + `lru_handoff_s149_s150.md` (handoff con 6 frentes propuestos para s150) + actualización de los dos vivos `LRU_CATALOGO_ANILLO2_VIVO` + `LRU_TENSIONES_ABIERTAS_VIVO`.

* `LRU_TECH_DEBT_s148.md` — **deuda técnica vigente al cierre de s148** (ancla activa). Sesión densa de un solo frente ejecutado a fondo: **navegación horizontal cross-host de la matriz EnlacesPanel**. 6 iteraciones de diseño (wheel→scrollLeft descartado por Manuel · diseño A+D flechas+rail · materialización inicial en wrapper Sim4 · tematización+posición · migración al lego compartido · fix popup-placement con portal a body). **4 fixes mecánicos nombrados**: fix-A callback ref para sortear carrera de hidratación entre `hwObjs` y `swObjs` (`useRef+useEffect` con deps de estado no cubre el caso · el callback ref garantiza enganche en mount/unmount sin depender de qué state cambie) · fix-B smart placement contra ancestro recortador correcto (no asumir lego entero) · fix-portal popup a `document.body` con `position:fixed` + clamp manual al `.epc_root` (única forma de escapar `overflow: auto` ancestral) · fix-listas `flex column + gap` apelotona N grande → default `display: block + height fija + margin-bottom` (2 aplicaciones esta sesión · rail D + popup dropdown · candidato a 3ª aplicación para cristalizar como antipatrón firme). **Hook nuevo cristalizado** `useAtlasPassthrough` en `src/components/atlas/useAtlasPassthrough.ts` (50 líneas con doc exhaustivo · devuelve `{ 'data-atlas-passthrough': 'true' }` con tipos) **+ migración total de 8 sitios** (Sim4EnlacesPanel s148 · LruSeq s147 · FallosPanel s147 · ScenariosPanel s146 · SignalLab s140 · SystemsPanel s146 · Sim4DisplaysPanel s147 · SimBrowser overlay s142). **8ª aplicación acumulada del contrato D-s140-G** · patrón consolidado con punto único de evolución futura. **Padding-right 28px global** en `.atlas-cell` (D-s148-E) · margen cross-celda para que los dots del rail-Y no se superpongan con contenido interior · una línea CSS afecta a todos los hosts (Sim1+Sim2+Sim3+Sim4). **Tematización cromática naranja** completa del dropdown (botón + popup border + box-shadow halo + caret + item activo + outline highlight teclado) para coherencia visual con las flechas · **paleta funcional emergente** del proyecto: naranja=navegación horizontal · azul=datos linked · rosa=físico pulsante. **Atajos teclado** completos en dropdown (↑↓ navegación · Enter selección · Home/End extremos · Escape cierre · onMouseEnter sincronizado · scrollIntoView). **Badges V/R** estáticos en items del dropdown (calco cromático de la cabecera sin anillos pulsantes · arbitraje Manuel *"más discreto · menos distractor en el dropdown"*). **8 decisiones cristalizadas D-s148-A..H**. **Antipatrón reincidente "narrar antes de auditar"** con 2 instancias en una sola sesión (interpretación errónea de captura inventando una flecha que no existía · opacidad disabled como falsa causa de flechas invisibles cuando la causa real era state inconsistente por carrera de hidratación). **Regla operativa derivada provisional**: "ante síntoma visual · logs antes que hipótesis · inspección DOM antes que teoría CSS · preguntar al usuario `¿qué ves exactamente?` con opciones discriminantes". **Cita de aprobación final** Manuel: *"funciona muy bien"* + *"un diseño de pagina elegante"*. **0 regresiones introducidas · captura final aprobada visualmente**. **Sub-patrón nuevo articulado**: "honestidad técnica · reconocer cuándo una propuesta de refactor es por estética y articularlo antes de proceder por inercia" (Claude propuso hook por estética · autocorrigió articulando que P11 decía lo contrario · Manuel arbitró alcance reducido inicialmente y amplió a total tras validación empiríca). **Validación retroactiva §5 s147** ejecutada al arranque (compilación verde + cabecera 4 botones Sim4Header validada). **Documentos de cierre**: `LRU_TECH_DEBT_s148.md` (este ancla) + `lru_handoff_s148_s149.md` (handoff con 5 frentes propuestos para s149) + actualización de los dos vivos `LRU_CATALOGO_ANILLO2_VIVO` + `LRU_TENSIONES_ABIERTAS_VIVO`. **Ideas al cuaderno (anti-anticipación P11)**: indicador más-a-izq/dcha en flechas · búsqueda dentro del popup cuando hwObjIds > umbral.
* `LRU_TECH_DEBT_s144.md` — ancla anterior · superada por s148 (saltos s145-s147 sin actualización del catálogo · anotación meta consistente con el patrón histórico de actualización periódica del catálogo cada 4-7 sesiones). **Deuda técnica vigente al cierre de s144**. Sesión densa con 5 frentes pivotados sin scope creep: (1) **EnlacesPanel en Sim4 A-4** · 4ª aplicación T-S142-N1 (lego autocontenido) · 5 ediciones D-s144-A/B/C/D. (2) **Diagnóstico arqueológico Switches digitales** · sesión derivó de tarea cerrada a investigación histórica · lectura de `lru_session_s53_memoir.md` + `COLLABORATION_NOTES_v2_s54.md` + `lru_pfd01_change1_code_v2_s37.html` + `lru_ib04_migration_guide_s34.html` + captura visual del backup 12/04 con sliders+switches conviviendo en `BarraLruFlotante` Col4 + acceso MCP a `C:\react\pwa6_1204\` · auditoría empírica cruzada lado-a-lado del despacho polimórfico `sensor.tipo === 'sd'` → `<LruSwitch>` versus rama analógica `'adc'|'i2c'|'fpga'` → `<LruSlider*>` · descubrimiento que el sistema NO se perdió como código (intacto en `pwa6/src/datosLru01/ComponenteLru/index.tsx` línea 1087) sino solo como **superficie en Sim1+Sim4** + **datos** (sim-catalog actual sin puertos `'sd'`) · cristalización del sub-patrón **"rama de polimorfismo no migrada"** como variante de T-S139-N1 ("extracción a lego revela bugs latentes"). (3) **LruBar dual Sim1 A4 + Sim4 A-5** · **6ª aplicación T-S142-N1 firme · PRIMERA DUAL** · 12 ediciones D-s144-E/F/G/H · lego compartido nuevo `src/components/panels/LruBar/` envuelve `ComponenteLru` con `PanelProps` · wrappers minimalistas Sim1LruBar/Sim4LruBar sin rebrandeo CSS (el lego usa `--app-*` universal) · cero ampliación HostUIBridge · cero providers nuevos · validación retroactiva fuerte: el patrón escala a N hosts gratis si los contextos viven en App raíz. (4) **Fix imports zombie Sim1Switch.tsx** · D-s144-I conservar fichero · cabecera corregida + nota explicativa + import migrado a `'../../../components/SimBrowser'` (lego post-s142 D-s142-V) + eliminado import CSS legacy (lego nuevo lo carga internamente). (5) **LruSeq dual Sim1 A5 + Sim4 A-6** · **7ª aplicación T-S142-N1 firme · 2ª DUAL en la misma sesión** · 12 ediciones D-s144-J · lego compartido nuevo `src/components/panels/LruSeq/` envuelve `SeqPanel` del 12/04 (`src/datosLru01/BarraLruFlotante/SeqPanel.tsx`) · descubrimiento empírico que coexisten dos SeqPanel distintos en el árbol (Sim1 sequences global vs hwObj individual) · son complementarios · ambos viven · cero rebrandeo. **25 cambios aplicados** (24 ediciones nuevas + 1 fix zombie) · **build verde validado empíricamente** · LruBar visible en navegador Sim1 A4 y Sim4 A-5. **Cero regresión introducida**. **10 decisiones cristalizadas D-s144-A..J**. **Fenómeno preexistente documentado** (T-S144-N1 lag sistémico al cambiar simulación afecta a todo consumidor de RegistryContext · NO causado por s144 · sale a la luz al exponer LruBar en Sim1/Sim4 cuando antes solo Col4 lo consumía en superficie visible · sesión dedicada futura para auditar flujo IB_04 → registros → enlaces). **6ª aplicación de T-S139-N3** (auditoría empírica preventiva · 4 documentadas en sesión: EnlacesPanel · ComponenteLru lado-a-lado backup vs actual · MixerPanelData types antes de modificar · dos SeqPanel descubiertos antes de codear). **Coherencia mnemónica emergente**: ambos hosts tienen LruBar+LruSeq en celdas A4/A5 consecutivas · workspace A reserva fila 4 para configuración (Enlaces) y filas 5-6 para hardware (LruBar/LruSeq) · convención sin canonizar todavía. **Documentos de cierre**: `LRU_TECH_DEBT_s144.md` (este ancla) + `lru_handoff_s144_s145.md` (handoff con 5 frentes propuestos para s145) + actualización de los dos vivos `LRU_CATALOGO_ANILLO2_VIVO` + `LRU_TENSIONES_ABIERTAS_VIVO`.
* `LRU_TECH_DEBT_s142.md` — **deuda técnica vigente al cierre de s142** (ancla anterior · superada por s144 · saltos s143 sin actualización del catálogo · anotación meta: el catálogo §1.2.1 no se actualizó entre s142 y s144 a pesar de que `LRU_TECH_DEBT_s143.md` existe en `/mnt/project/`). Sesión densa de código articulado bajo **Camino V** (auditoría iterativa que reformuló el frente B del handoff s141→s142). 4 fases: (1) **Articulación iterativa** ~40% con 3 oleadas de auditoría empírica y 4 pivots redirigidos por pistas laterales de Manuel · descarta sucesivamente frente B genérico → TabLog → ScenariosPanel hasta emerger Camino V · disciplina patrón 6 (pushback constructivo) activada con cuestionamiento explícito del catálogo de frentes del handoff (T-S142-N3 sembrada como 1ª instancia de regla operativa candidata). (2) **Materialización Camino V** ~35%: 2 legos nuevos · `src/components/SimBrowser/` (promovido desde `Sim1/shared/` · 3 ficheros) + `src/components/panels/VisorPanel/` (creado desde cero · 4 ficheros · 1ª instancia formalizada de la familia **"lego autocontenido"** distinta de la familia **"lego con bridge"** de los 5 legos previos · consume Datos01 directamente sin wrapper per-host · T-S142-N1 sembrada). Sim1 retira `'instruments'` del registry · TabViewer mantenido intacto (decisión C2) · Sim4 incorpora VisorPanel en celda A-3 con preset propio `'visor'` (1ª materialización efectiva del lego en host distinto a Sim1). (3) **Validación + fix wheel** ~10%: `data-atlas-passthrough="true"` aplicado a `.simbrowser-arts-scroll` · **2ª aplicación del contrato D-s140-G** que cristaliza **T-S140-PASSTHROUGH a sub-patrón firme** (SignalLab s140 + SimBrowser s142). (4) **Frente H mini** ~15%: cierre T-S142-N4 en la misma sesión · `.visor-animate-ph-*` reubicadas a `components/Visores/visor-animate.css` nuevo (VisorAnimate importa su propio CSS) · `.sim1-viewer-toolbar-*` verificadas código muerto y descartadas · TabViewer retira import del CSS legacy · `Sim1/shared/simbrowser.css` queda inerte borrable. **8 ficheros nuevos + 7 editados + 3 inertes pendientes borrado físico manual** (InstrumentsPanel carpeta + SimBrowser.tsx legacy + simbrowser.css legacy · MCP filesystem no expone delete). **8 decisiones D-s142-V* firmes**. **3 tensiones nuevas vigentes** (T-S142-N1 sub-patrón "lego autocontenido vs lego con bridge" · 1ª instancia formalizada · pendiente 2ª aplicación para cristalizar · T-S142-N2 disciplina "auditoría empírica con lente equivocado produce falsos descartes" · 1ª instancia · regla candidata · T-S142-N3 "frente articulado en handoff puede estar agotado al auditar empíricamente" · 1ª instancia · regla candidata) **+ 1 cerrada en sesión** (T-S142-N4 CSS huérfano · cerrada por materialización Fase 4 · D-s142-V-FRENTE-H). **Sub-patrón "contrato `data-atlas-passthrough` cross-lego" cristalizado firme** (2 aplicaciones s140+s142 · candidato firme a destilado Anillo 2 en sesión Frente G). **4ª aplicación reforzada de T-S139-N3** (auditoría empírica preventiva · disciplina firme · no requiere cristalización adicional). **6ª aplicación parcial de la disciplina del alfiler s125** (forma auditoría iterativa en chat con Qs firmadas y decisiones D-s142-V* en vez de alfiler `.md` dedicado · ambas formas válidas). **Validación empírica Sim4 A-3 funcional · SimBrowser scroll sin secuestro Atlas tras passthrough**. 0 cambios al núcleo de 5 · 0 cristalizaciones fundacionales pendientes.
* `LRU_TECH_DEBT_s135.md` — **ancla anterior · superada por s142** (saltos s136-s141 sin actualización del catálogo · anotación meta: el catálogo §1.2.1 tampoco se actualizó entre s135 y s142 a pesar de que LRU_TECH_DEBT_s136 a s141 existen · sesiones de alta densidad arquitectural acumulada: s136-s137 alfiler Sim4 unificación atriles · s138 SP4 cristalizado · s139 Sim4 atlas + D-s139-CTX · s140 useEngineBridge + HostBridge candidato + D-s140-H opción 3 firme · s141 HostBridge canónico cross-host materializado 8 wrappers · s142 VisorPanel + SimBrowser extraídos al lego compartido). Sesión transformada de "materialización corta D-s134-D (~50 líneas · 6 pasos)" a "cristalización arquitectónica con tres vertientes A/B/C" tras emerger durante validación empírica: (1) bug latente del basename divergente (`vite.config.ts: base='/pwa6/'` vs `App.tsx: basename="pwa6"` hardcoded · `pushState` crudo NO conoce basename) resuelto en Bloque 2 con disciplina rectora articulada por Manuel *"no postergar trabajo inevitable"* (1ª aplicación formal · candidato a formalización si emerge 2ª) · (2) bug latente de reactividad URL→Atlas (`useMemo([])` con dep vacía no recalcula urlSeedCoord aunque searchParams cambie · initialCoord solo siembra en primer render) resuelto en Bloque 3 con triple barrera anti-loop validada · (3) articulación rectora de la **metáfora orquestal** por parte de Manuel (cita gold preservada) unificando P15+P16-cand+Director+URL+Federación bajo una sola formulación operativa · (4) horizonte conocido sobre federación de apps con timing real (futuro cercano sin fecha). **9 ficheros src/ tocados** (~280 líneas) + **1 fichero nuevo** `src/utils/basename.ts` (~120 líneas con doc exhaustivo). **1 deuda heredada CERRADA** (T-S134-DEUDA-1 · D-s134-D ejecutado 100%). **2 tensiones nuevas CERRADAS en la misma sesión** (T-S135-N1 basename + T-S135-N2 notistack). **4 deudas nuevas reconocidas con trigger natural anotado** (T-S135-DEUDA-1 `pathname.split` en 5+ sitios usar stripBasename · T-S135-DEUDA-2 `prefixBasename` evolucionará a `resolveAppPath` con registro de apps · T-S135-DEUDA-3 `authReturnUrl` migrará a URL absoluta cross-app · T-S135-DEUDA-4 materializar Nivel 1 paths relativos). **P-candidato s135 cristalizado** *"Partitura compartida, interpretación contextual"* con DOBLE materialización empírica validada (Vertiente A URL como notación + Vertiente B Federación inter-app con basename canónico) + tercera vertiente sembrada (Vertiente C Interpretación contextual con 3 niveles articulados · NO materializado). **NO cristaliza a P firme** hasta 2ª materialización en otra app del ecosistema (trigger natural: aparición pwa7/admin/docs). **Validación empírica cross-PWA por Manuel** con screenshot adjunto: URL `localhost:5173/pwa6/Sim3?atlas=4%2C2` + pantalla E-3 col=4 row=2 + notistack texto correcto · cita gold *"parece que ahora si navega"*. **2 patrones nuevos sembrados**: "No postergar trabajo inevitable" (disciplina rectora articulada por Manuel · 1ª aplicación) + "Cristalización colaborativa por iteración trifásica Manuel↔Claude" (meta-patrón observado en el ciclo de 6 turnos que produjo la formulación final del P-candidato). **4ª aplicación del patrón "hilo conductor con alfileres" s125** (s125→s128→s134→s135) · evidencia robusta para formalización en `LRU_METODO`. Items de ingeniería heredados sin movimiento.
* `LRU_TECH_DEBT_s127.md` — **ancla anterior · superada por s135** (saltos s128-s134 sin actualización del catálogo · anotación meta: el catálogo §1.2.1 no se actualizó entre s127 y s135 a pesar de que LRU_TECH_DEBT_s128 a s134 existen). 3 tensiones nuevas s127: T-S127-N1 (sticky highlight residual flechas atlas en móvil · defecto marginal · prioridad muy baja · plan B reservado) · T-S127-N2 (sub-patrón nuevo "tope CSS oculto en lego anidado descubierto sólo iterando empíricamente" · 1ª instancia · candidato a familia mayor con "errores documentales sobreviven a cableado real" si Manuel arbitra) · T-S127-N3 (¿extraer presets "dense" al lego sliders cuando emerja 2º panel denso? · prioridad baja · documental). **3 bugs latentes cerrados por materialización** en bloque emergente final: gesto direccional sliders (touch-action direccional huérfano del rename s122) · drift vertical Mixer (sensorSliderSize asigna 3 tamaños distintos) · desalineación slider/texto Mixer (height legacy mockup). 6 decisiones D-s127-A a F del paquete inicial materializadas + D-s127-E indicador X/N + D-s127-C atajos alcance reducido. **Beneficio cross-host del proyecto sin coste**: las fixes en legos benefician también a Sim1 sin tocar sim1.css. Items de ingeniería heredados sin movimiento.
* `LRU_TECH_DEBT_s126.md` — ancla anterior · superada por s127. 1 tensión nueva s126 (T-S126-N1 paridad sensors-bar Sim2↔Sim1 con 4 preguntas UX articuladas · absorbe parcialmente T-S125-N1) + 2 cerradas (T-S122-port-systems materialización efectiva en cierre de dos tiempos s125+s126 · T-S122-2 como sinónimo · 6º modo de cierre candidato).
* `LRU_TECH_DEBT_s125.md` — ancla anterior · superada por s126. 3 tensiones nuevas s125 (T-S125-N1 SystemsPanel rico aplazado · T-S125-N2 modelo plano composable como dirección estructural subordinada a T-S67-A1 · T-S125-N3 disciplina "hilo conductor con alfileres" pendiente formalización meta) + 2 cerradas (T-S124-2 por materialización + T-S122-port-systems por reformulación parcial). T-S122-X reformulada sin cierre formal.
* `LRU_TECH_DEBT_s124.md` — ancla anterior · superada por s125. 1 tensión nueva T-S124-1 abierta (annotations cross-host con 3 opciones) + 3 cerradas (T-S122-3 validación empírica · T-S122-CSS por rename · T-S122-port-transport por materialización). T-S124-2 anotada como prioridad muy baja (cerrada en s125 por materialización).
* `LRU_TECH_DEBT_s123.md` — ancla anterior · superada por s124. T-S117-F1 cerrada por integración al núcleo (séptima cristalización fundacional culminada · 8ª aplicación del patrón "destilado fundacional → integración al núcleo"). Cluster de tensiones del período de revisión articulatoria s101-s116 anotado.
* `LRU_TECH_DEBT_s122.md` — ancla anterior · superada por s123. 8 tensiones s122: 3 cerradas por materialización/asunción (T-S122-1 + T-S122-2 + T-S122-3) · 5 anotadas no urgentes (T-S122-OSC + T-S122-CSS + T-S122-densidad + T-S122-X + verificación empírica) · 2 pendientes de ejecución diferida (T-S122-port-transport con decisión de naming `TransportPanel` tomada · T-S122-port-systems con 4 opciones articuladas A/B/C/D pendiente decisión Manuel). **T-S117-F1 vigente con 5º aplazamiento consecutivo · territorio sin precedentes del proyecto** (cerrada finalmente en s123). Items de ingeniería heredados sin movimiento.
* `LRU_TECH_DEBT_s121.md` — ancla anterior · superada por s122. 3 tensiones s121: T-S121-1 osciloscopio (seed con 7 acepciones) · T-S121-2 paleta del grid afinable por tema · T-S121-3 patrón `as any` que oculta bugs · 4 cierres por materialización (los 4 bugs históricos) · T-S120-3 parcialmente cerrada (helpers neutros).
* `LRU_TECH_DEBT_s117.md` — ancla anterior · superada por s121. 8 tensiones s117 nuevas (1 fundacional T-S117-F1 + 6 frente operativo T-S117-N1..N6 + 1 meta T-S117-M1) + 0 cierres + items heredados.
* `LRU_TECH_DEBT_s80.md` — **deuda técnica vigente al cierre de s80** (ancla histórica). Total abiertos: **18** (22 heredados de s79 − 4 cerradas completas + 0 nuevas de ingeniería · T-S80-N1 prioridad baja registrada como monitor, no item activo). **5 tensiones cerradas en s80**: 4 completas (T-S65-N1, T-S65-N2, T-AU73-6, T-AU73-7) por materialización del dispatcher + 1 por materialización en callsite (T-S79-N4 hard-over clamping) + 1 refuerzo (T-S65-N4 wildcard resolver). 1 nueva candidata de prioridad baja: T-S80-N1 (`dropout` usa `Date.now()` · frágil NTP · mitigable con firma ampliada si emerge fricción).
* `LRU_TECH_DEBT_s79.md` — ancla anterior (s79) · superada por s80. Total abiertos al cierre de s79: **22**. 0 cerradas completas, 1 reclasificación positiva (T-S65-N4).
* `LRU_TECH_DEBT_s78.md`, `LRU_TECH_DEBT_s77.md`, `LRU_TECH_DEBT_s76.md`, `LRU_TECH_DEBT_s75.md`, `LRU_TECH_DEBT_s74.md`, `LRU_TECH_DEBT_s73.md`, `LRU_TECH_DEBT_s70.md`, `LRU_TECH_DEBT_s69.md`, `LRU_TECH_DEBT_s67.md`, `LRU_TECH_DEBT_s65.md`, `LRU_TECH_DEBT_s64.md`, `LRU_TECH_DEBT_s63.md`, `LRU_TECH_DEBT_s62.md`, `LRU_TECH_DEBT_s61.md`, `LRU_TECH_DEBT_s60.md` — anclas anteriores, superadas. `LRU_TECH_DEBT_s60.md` conserva valor como fuente del detalle original de O6 (cerrada en s65) y O7.
* `LRU_TECH_DEBT_s56.md` — tech debt de fondo para los 22 items heredados. Consultar para detalle de items previos a s60.

#### 1.2.2 · Piezas documentales permanentes del anillo 2

Material vivo con función propia, no candidato a integración al núcleo por diseño.

* `lru_atlas_proyecto_meta_s74.md` — **fundación del Atlas del Proyecto** · pieza documental nueva permanente del anillo 2 · 370 líneas · taxonomía inicial de 8 categorías (A conceptual trascendental, B postulados, C técnica plataforma, D actores/vistas, E Realm, F temporal/sesión, G documental/disciplina, H histórica/evolutiva) · arquitectura de colaboración de tres roles Manuel + Claude + Claude Design · primer diagrama A1-s74-v1 renderizado en s74 · el Atlas **no cruza al anillo 1 por diseño** · complementa el índice textual del MAPA con índice visual del proyecto · coordinación pendiente T-S74-B3.
* `lru_mapa_historia_s74.md` — **snapshot íntegro del MAPA al cierre de s74** · producido en s75 como trazabilidad de la limpieza estructural E.1 · permanente · contiene el contenido eliminado o condensado en la reestructuración.
* `lru_tensiones_resueltas_archivo_s128.md` — **archivo histórico de tensiones resueltas al cierre de s127** · producido en s128 al ejecutar palanca F del cierre operativo (poda del MAPA) · 48 KB · 30 filas íntegras de §4.3 del MAPA · 29 IDs únicos · cero compresión de contenido · cero reformulación · preservación de la voz documental original (Patrón 3). **Razón del archivado**: el MAPA mantenía estas 30 filas en sitio (45 KB · 14% del fichero) por disciplina canónica de preservar trazabilidad de cierres · al cerrar s127 con cuatro sesiones de deuda documental absorbidas el peso del MAPA llegó a 340.7 KB · Manuel arbitró palanca F para liberar espacio sin perder información. **Disciplina nueva inaugurada en s128**: §4.3 del MAPA queda con puntero al fichero externo · cierres posteriores a s128 se anotan en §4.2 (anotación de cierre en fila viva) sin migrarse de inmediato · próxima ronda de archivado cuando se acumulen suficientes nuevas cerradas (decisión Manuel en su momento). Permanente · pieza estructural del catálogo histórico.

* `lru_inventario_consumidores_s157.md` + `lru_ampliacion_signalengine_trinidad_s157.md` + `lru_geografia_desconexion_uso_real_s157.md` — **3 piezas arqueológicas del frente observatorio cerrado en s157** · ~107 KB total · **7ª aplicación disciplina alfiler s125** · censo empírico de 12 consumidores del DataPlane (Universo A `valuesRef` 7 consumidores + Universo B `hwObjs` 4 consumidores + trinidad universal IB_04+DataPlaneSpy+SignalEngine) + ampliación SignalEngine como 3er pilar trinidad (4 categorías procesadoras gen/filter/control/mod + 2 observatoriales analysis/detect) + traducción vocabulario operativo Manuel "mixer/chart no concuerdan con lrupanel/agujas/lruBar" al código. **Validación empírica runtime rectifica T-S151-N2**: NO son dos namespaces de sensorIds · es un mismo sensorId en dos contenedores `valuesRef` vs `hwObjs.hw1.puertoValor`. Patrón 3 aplicado con rectificaciones quirúrgicas.
* `lru_alfiler_facetas_multivista_s157.md` (48.5 KB · 9 secciones) — **alfiler s157 post-cierre · 8ª aplicación disciplina alfiler s125** · articula **modelo facetado / multi-vista** como dimensión organizativa unificadora del observatorio · 6 catalogaciones identificadas (4 materializadas + 1 articulada-no-materializada + 1 implicita: ATA + quantity + hwObj/puerto + protocolo + aguja + fallo) · T-S151-N2 reformulada en su 3ª iteración (v1 dos namespaces s151 → v2 mismo sensorId dos contenedores s157 runtime → v3 catalogaciones múltiples ortogonales) · candidato cristalización fundacional **P13 candidato** "Catalogación múltiple ortogonal" articulado sin cristalizar · **5 SVGs embebidos como anexo arqueológico**: tres planos aguja/sensor/puerto + sensores coinciden jerarquías no + facetas del sensor + UniversalQuantityDef/SignalDef separación + rectificación T-S151-N2 runtime. Cita gold Manuel preservada (Patrón 3): *"podria haber distintas formas de catalogar los sensores por ejemplo ata, temperatura, analogicos, se podria compatibilizar esto y unificar de alguna forma"*. **Reserva metodológica explícita**: no propone materialización concreta de API multi-faceta · no propone rename de tipos existentes · no cristaliza P13 · no toca código vivo · no sustituye destilado s81 ni material consolidado Realm v3. **Frente candidato s158-CANDIDATO-FACETAS** articulado en §8 · subordinado a finalización observatorio T-S155-N3. **T-S157-CAND-3 abierta**.
* `lru_alfiler_observatorio_reformulado_s156.md` (32.7 KB) + `lru_observatorio_mapa_fuentes_s156.md` (21.9 KB) — **alfileres s156 · 6ª aplicación disciplina alfiler s125** · reformulan radicalmente el observatorio de "lujo arquitectural" a **"herramienta diagnóstica preventiva de desconexión real y conocida"** · 4 acepciones complementarias articuladas · T-S155-N3 ampliada · T-S156-N1 sub-patrón meta-metodológico 2ª instancia · 3 caminos materialización sin arbitraje firme.
* `lru_alfiler_observatorio_senales_s155.md` (20.3 KB) — **alfiler s155 · 5ª aplicación disciplina alfiler s125** · articulación inicial del observatorio de señales como dualidad del microscopio (Analyzer1 §3.3) · cita gold Manuel: *"no sabemos si las fuentes que generan señales se ven unas a otras"*.
* `lru_alfiler_dataplane_viewer_s152.md` (~33 KB · 10 secciones) — **alfiler s152 · 3ª aplicación disciplina alfiler s125 · 5 fases acumuladas del DataPlane viewer dentro de Analyzer1** · inauguración parcial Debug1 viewer (T-S55-A2 cerrada parcial) · sub-patrón cristalizado **"vista hermana adaptativa por protocolo"** con 3 aplicaciones formales en sesión única.
* `lru_alfiler_dos_universos_nomenclatura_s151.md` (36 KB · 12 secciones) — **alfiler s151 · 1ª articulación profunda T-S151-N2** · cristalización candidata fundacional 8ª (reformulada por runtime empírico en s157).
* `lru_externalizacion_navegacional_s128.md` — **alfiler hilo conductor s128** · 24 KB · 279 líneas · pieza intermedia que articula el principio *"con MCP filesystem disponible como infraestructura estable, el MAPA puede comportarse como índice navegacional con punteros en lugar de repositorio acumulativo"*. **2ª aplicación de la disciplina del alfiler s125 sobre tema arquitectural-documental** (1ª fue sobre realms estructura plana). Inaugura categoría documental nueva propuesta: **"anillo 1.5"** · documentos vivos iterativos sin sufijo · cargados por Project al arrancar · accesibles vía MCP filesystem · referenciados desde MAPA con puntero. 6 propiedades canónicas + cascada de fallback de cuatro niveles articulada por Manuel con cita gold preservada (*"habitualmente esos ficheros estarán en el proyecto y puedes acceder a ellos internamente y contrastar si están al día · si no están al día puedes leerlos del filesistem o pedirlos · o en caso de no obtenerlos de alguna manera podrás continuar con lo que tengas y avisar"*). Inventario de 5 palancas (Q+O+M+N+P) en 3 etapas. **Etapa 1 ejecutada en s128** (Q+O materializados). 4 preguntas: 3 cerradas + 1 abierta (Q1 orden de ejecución de etapas restantes). Sub-patrón candidato emergente sembrado: *"capacidad operativa nueva habilita disciplina arquitectural nueva"*.

* `LRU_GUIA_ARRANQUE_VIVO.md` — **1ª aplicación operativa de la categoría documental "anillo 1.5" inaugurada en s128** · documento vivo iterativo · sin sufijo · 7 KB · contenido íntegro de §6 del MAPA al cierre s127 (sin compresión · sin reformulación · Patrón 3). Guía de arranque por tipo de sesión con 5 categorías · referencia operativa que Claude consulta al orientar arranque. Iterativo · se actualiza al emerger disciplinas o tipos nuevos (la última actualización del contenido fue en s94 al formalizar las 5 disciplinas D1-D5). **Externalizada en s128 mediante palanca Q etapa 1** de externalización navegacional articulada en alfiler s128. El MAPA conserva tabla mini de 5 tipos + puntero a este fichero.

* `LRU_PRINCIPIOS_OPERATIVOS_VIVO.md` — **2ª aplicación operativa de la categoría documental "anillo 1.5" inaugurada en s128** · documento vivo iterativo · sin sufijo · 22 KB · contenido íntegro de §3 del MAPA al cierre s127 con sus 4 subsecciones (3.1 fundacionales · 3.2 arquitecturales · 3.3 metodológicas · 3.4 voz y disciplina fundacional). Principios canónicos del proyecto que ya están integrados al núcleo (FUNDAMENTOS+METODO) pero se conservan como recordatorios operativos derivados consultables sin abrir múltiples canónicos. La fuente canónica de los principios sigue siendo `LRU_FUNDAMENTOS.md` y `LRU_METODO.md` · este fichero es derivado operativo. **Externalizada en s128 mediante palanca O etapa 1** de externalización navegacional articulada en alfiler s128. El MAPA conserva índice de 4 categorías + puntero a este fichero.
* `lru_hilo_realms_estructura_plana_s125.md` — **alfiler hilo conductor** · **categoría documental nueva del proyecto inaugurada en s125** (tag especial "hilo conductor" · disciplina "hilo conductor con alfileres" · candidata a formalización en `LRU_METODO §7` o `§8` cuando T-S125-N3 madure). ~480 líneas. Articula realms como **estructura plana composable** generalizando P11+P12 al conjunto del proyecto en el contexto del laboratorio real/virtual de señales. 4 citas literales de Manuel s125 preservadas como gold (Patrón 3). 5 preguntas Q1-Q5 con cierre disciplinado. **D-s125-E arbitrada explícitamente**: NO postulado nuevo · NO P13 candidato · NO integración al núcleo · pieza intermedia permanente que registra articulación emergente sin pretender resolverla. **Naturaleza diferenciada**: no es destilado anillo 2 con disciplina canónica de cristalización · no es anillo 3 desechable · no se integra al núcleo · pieza permanente del anillo 2 con función propia. **1ª aplicación operativa confirmada en s126** (Bloque C-1 cabecera Sim2 con 4 barras encadenadas materializado siguiendo el alfiler) · **2ª aplicación operativa confirmada en s127** (paquete completo de navegación Sim2 + bloque emergente sliders ejecutados sin refactor del closure imperativo legacy ni reapertura de T-S67-A1).

* `lru_hilo_director_panel_s134.md` — **hilo conductor firme con doble cristalización** · **3ª aplicación de la disciplina alfiler s125** (1ª realms s125 · 2ª externalización navegacional s128 · 3ª este). **~76 KB · 13 secciones (§0-§13) · 14 citas gold preservadas** literalmente (8 sobre P16 candidato en §8 + 6 sobre P17 candidato en §12.1). Articula **dos cristalizaciones complementarias** emergidas en s134:

  **A · P16 candidato** · *"Coreografía de actores sobre el Atlas"* · articulación inicial + descubrimiento de semilla preexistente en Debug1 (`useInstanceRegistry`+`useInstanceHistory`+`useDeviceInfo`+`TabNav`+`TabChat`+`DebugBusController` con 14+ comandos remotos + ACK protocol + bus WS Node-RED + 14 tipos de mensajes WS catalogados) + materialización de **dos ladrillos arquitecturales concretos validados empíricamente**: (a1) `AtlasHandle.goToCoord` con `AtlasNavResult` local validado por *"el boton goto funciona correctamente"*; (a2) `/nav atlas col,row` cross-PWA validado por *"si funciona el cambio de celda entre pwa"*. Tres caminos arquitecturales I/II/III de extracción DirectorPanel articulados con recomendación firme Camino III en fases.

  **B · P17 candidato refinado** · *"DataPlane multi-protocolo como espina dorsal"* · articulación emergente en turnos finales s134 con **6 citas gold de Manuel** sobre DataPlane multi-canal/multi-ancho-de-banda + RabbitMQ como espina dorsal con múltiples protocolos + WebRTC como horizonte futuro + plano partitura como escalada compuesta + **cita fundacional** *"nuestra materia prima son esos datos y esta es la forma de intercomunicar muchos mundos distantes matriales e inmateriales"* (comparable a citas s53/s67/s84/s98/s117 que cristalizaron postulados) + **regla operativa central** *"ya existe alguna infraestructura de comunicaciones y protocolos que no es necesario reinventar pero que se puede complementar y mejorar"*. Disciplina de la sección §12: NO proponer protocolos nuevos · reconocer y catalogar lo cableado · identificar complementos progresivos cuando emerja necesidad. Radiografía empírica completa: 5 piezas núcleo DataPlane (24 KB Float64Array zero-copy 512 slots + 15 KB RouterService + 13 KB ControlBus + 50 KB SignalEngine + 13 KB useDataPlane) + 7 adapters (MQTT/WS/Serial/BLE/HTTP/Loopback/Bridge · 61 KB total) + CommsManager 13 KB + 14 tipos mensajes WS Node-RED + 14 comandos remotos `/cmd` + RabbitMQ servidor con AMQP/MQTT/STOMP/HTTP/WS. **5 ejes ortogonales** del intercambio (granularidad/transporte/naturaleza/sentido/temporalidad) + **4 familias de protocolos coreográficos** (URL universal · partitura compuesta · comandos efímeros · mensajes conversacionales) + **5 complementos progresivos** identificados sin materializar (URL search params, feedback Atlas-coord, `/partitura`, WebRTC adapter, identidad por rol).

  **C · D-s134-D arbitrada** · §13 · URL universal canónica como protocolo coreográfico atómico (`/nav <ruta>?param=valor`) · reconoce el sub-comando `/nav atlas col,row` materializado en T-S134-N8 como **deuda técnica** (semántica torpe + parser custom innecesario + estado no-URL + no compartible) · plan de materialización aplazado a s135+ · 6 pasos detallados · ~50 líneas · 1 hora de sesión estimada.

  **Estatus explícitamente diferenciado**: más madurez que el alfiler emergente s125 (porque tiene 2 materializaciones empíricas validadas en la misma sesión · local + cross-PWA) pero NO destilado canónico todavía · le falta materialización D-s134-D + extracción DirectorPanel (T-S134-N7) + integración a `LRU_FUNDAMENTOS` planificada cuando Manuel arbitre. **Distinción nueva aportada** sobre los 2 precedentes documentos del patrón: s125 articuló visión sin código · s128 articuló con materialización parcial (palancas Q+O) · s134 articula **dos cristalizaciones complementarias** (P16+P17) con 2 ladrillos materializados validados + decisión arquitectural mayor (D-s134-D) arbitrada + 14 citas gold + 5 complementos progresivos sembrados · esto justifica el adjetivo *"firme con doble cristalización"* frente a *"emergente"*.

  **T-S134-DOC-1 abierta**: con la 3ª aplicación el patrón está firmemente asentado · candidato a formalización canónica en `LRU_METODO §7` o `§8` con regla operativa derivada propuesta. **T-S134-DOC-2 nueva**: candidato a regla operativa derivada de cita gold *"la aplicacion genera ideas y arquitectura que no son nuevas porque ya las hemos tratado anteriormente pero que van refinandose hacia lo concreto mediante el codigo"* (disciplina articulación↔código iterativo). **Patrón nuevo nombrado**: *"Reconocer lo cableado antes de proponer"* (1ª aplicación formal en §12 · candidato a formalización si emerge 2ª aplicación). Arbitraje pendiente Manuel.

  Complementario a `lru_debug1_analysis_s55.md` (destilado canónico Debug1 s55 · §1.2.7) que articula Debug1 como subsistema transversal · este alfiler lo extiende con dimensión coreográfica (P16) + dimensión protocolar (P17). Complementario también a `lru_postulado_12_hardware_fisico_sustrato_s117.md` (P12 integrado en `LRU_FUNDAMENTOS §11sexies`) · P17 candidato propone ser el **postulado del sustrato semántico complementario al sustrato material P12** · par fundacional sustratos cuando se canonice formalmente.

#### 1.2.3 · Destilados pendientes de integración al núcleo (regla de disputa activa)

**1 destilado activo al cierre de s158** (recuperando uso de la sub-categoría tras el "bloque vacío" del cierre s129):

* `lru_destilado_facetas_multivista_s158.md` — **destilado anillo 2 producido en sesión arquitectural dedicada Frente H s158** · 46.7 KB · 724 líneas · 9ª aplicación operativa disciplina alfiler s125 forma alfiler→destilado · regla de disputa activa hasta sesión de materialización futura. Articula **API consultora multi-faceta** sobre 5 catalogaciones del sistema (4 materializadas + 1 implícita TipoSensor · aguja y fallo fuera de scope por arbitraje Manuel s158 · disponibles como extensión futura via registry abierto). 5 decisiones de diseño D-Q1..Q5 arbitradas por Manuel s158 (unidad atómica `sensorId` · faceta nombrada por string identifier · query objeto plano con AND implícito + predicado funcional opcional · registry abierto desde inicio · lazy v1 sin index precomputado). Strawman articulado: `interface Facet` + `interface FacetRegistry` + función `query` + función `queryExpanded` + tipo `FacetPredicate`. 5 adaptadores ejemplo (uno por catalogación · honra asimetría de acceso sin forzar forma común) + 6 ejemplos canónicos de uso incluyendo cita gold Manuel s157 materializada. **Cierre arquitectural T-S151-N2 (4ª reformulación v4)** · pendiente cierre operativo por materialización (mismo patrón canónico que T-AU73-4 cerrada arquitecturalmente s81 + materializada s83). **T-S158-P13-CAND nominada** · candidato cristalización fundacional 8ª · formulación refinada respecto al alfiler s157 (sustrato = entidades funcionales · no DataPlane · confirmado por audit empírico s158). 5 hallazgos principales del audit empírico s158: (1) `SIM_CATALOG.allSensors()` ya emite registros enriquecidos · (2) `SensorDef.puertoHwObj?` es cruce declarativo Cat.1↔Cat.3 ya operativo · (3) `TipoSensor` es 5ª catalogación implícita no anticipada · (4) Cat.4 protocolos tiene cobertura empírica real declarativa (4 entidades a320 con ARINC 429) · (5) asimetría estructural de acceso confirmada (cada catalogación tiene API distinta). **0 cambios src/** · destilado opera en papel. Patrón canónico destilado→materialización (5ª-6ª instancia del ritual · precedentes s81→s83 · s79→s83 · s65→s78). Disciplinas honradas: Patrón 3 (2 citas Manuel literales) · Patrón 6 (pushback honesto sobre formulación P13 + 3 decisiones implícitas) · P11 anti-anticipación (§3.6 + §6 explícitos).

#### 1.2.4 · Destilados diferidos explícitamente por Manuel

* `lru_agnostico_especializado_y_roles_aeronauticos_s71.md` — **destilado secundario s71 · referencia histórica post-materialización + post-cristalización tardía · doble función documental (post-s98)**. **Estatus original** (s72): diferido explícitamente por Manuel con criterio *"el uso nos va a decir qué actores vamos a necesitar en el día a día"* · T-S71-A2 sobre cómo el schema Realm v3 maneja la tensión entre agnosticidad de dominio (Postulado 5) y especialización aeronáutica concreta + roles aeronáuticos como prerequisito · disponible para sesión futura cuando v3 esté operativo y emerjan demandas reales de roles/actores. **Estatus post-s98**: doble función documental — (a) **fuente histórica original** del material agnóstico/especializado articulado en 1ª vuelta del círculo incremental con 5 citas literales de Manuel s71 preservadas como gold + 3 caminos arquitecturales nominados (I/II/III) + recomendación firme Camino II+ + lista de personajes aeronáuticos · (b) **anclaje del recorrido del círculo** que culmina con el destilado s98. T-S71-A2 cerrada por **materialización tácita por absorción superpuesta s84-s97 + cristalización tardía s98** · 1ª aplicación del cuarto modo de cierre "cierre tardío con reconocimiento de continuidad" articulado en `lru_estructura_sectorial_s98.md §9`. Material agnóstico/especializado materializado tácitamente en T-S84-A8 Tandas 1-4 (s90/s95/s96/s97) sobre `src/realm/aviation/` ejecutando Camino II+ recomendado en s71 §3.3 sin nombrarlo. Material roles aeronáuticos absorbido en destilado arquitectural hermano `lru_roles_mantenimiento_formacion_s84.md` (s84) que extendió la lista s71 §2.2 con 18 tipos · materializados en código entre s90 y s97. Cristalización fundacional tardía ejecutada en s98 con T-S97-F1 articulando formalmente la **disposición evolutiva del diseño estructural del realm específico** (Postulado 11 candidato).

#### 1.2.5 · Destilados históricos post-integración (regla de disputa retirada)

Fuente fundacional con valor de referencia permanente. El núcleo es autoritativo sobre el contenido integrado. Las citas textuales de Manuel y la argumentación original se preservan aquí.

* `lru_postulados_fundacionales_s67.md` — **primera cristalización fundacional (integrada en s68)** · cristaliza los 5 postulados fundacionales · integrados al núcleo como P1→`LRU_FUNDAMENTOS §7`, P2→§8, P3→§9 (renumerados en s70 al insertar P6), P4 y P5 en `LRU_MISION`. Secciones del destilado sobre implicaciones arquitecturales (§6, rediseño Realm v3 con 9 tipos nuevos) siguen siendo referencia viva para el trabajo arquitectural pendiente.
* `lru_postulados_6_7_8_9_s69.md` — **segunda cristalización fundacional (integrada en s70)** · cristaliza 4 postulados adicionales · integrados como P6→`LRU_FUNDAMENTOS §6` (fundacional de primer orden, ubicado antes de §7), P7→§10, P8→§11 (plano fundacional) + `LRU_MISION` (plano de uso), P9→`LRU_MISION` · disciplina ética operativa en `LRU_METODO §6`. §5.1 (implicaciones arquitecturales Realm v3) y §5.2 (semilla FPGA) siguen siendo referencia viva.
* `lru_postulado_10_diseno_como_innovacion_s84.md` — **cuarta cristalización fundacional (integrada en s91)** · 323 líneas · 2 citas literales de Manuel s84 preservadas como gold. Articula el **Postulado 10 · El diseño del Realm como espacio de innovación dentro del respeto** sobre el acto de construir el Realm (distinto de P8 sobre el uso y de P9 sobre continuidad sim↔real). **Integrado al núcleo en s91** como `LRU_FUNDAMENTOS §11quater` con 7 subsecciones (texto canónico §11quater.0 + articulación literal de Manuel §11quater.1 + distinciones P10 vs P8/P9/P5 §11quater.2 + materializaciones concretas en el schema §11quater.3 + hilos transversales como ejercicio metodológico §11quater.4 + relación con principio 11 implícito §11quater.5 + implicaciones para sesiones futuras §11quater.6) preservando las 2 citas literales de Manuel literalmente. Regla operativa derivada en `LRU_METODO §6bis "Disciplina honesta sobre configuraciones simuladas"` con 6 subsecciones · paralelismo estructural directo con §6 sobre material de casos reales (P7). Anotación complementaria (no absorción) en `LRU_ARQUITECTURA §8` sobre el principio 11 implícito que sigue pendiente como dimensión arquitectural propia. MISION sin cambios por decisión explícita (replica disciplina s89). T-S84-F1 cerrada · regla de disputa retirada · **cuarta cristalización fundacional culminada · ninguna cristalización fundacional pendiente al cierre de s91**. Las dos materializaciones concretas articuladas en el destilado (`SimulatedContextDef.notEqualToReal: true` literal obligatorio + `OrganizationApprovalDef.notEqualToReal?` opcional) son piezas del schema pendientes de materialización en código vía Tanda 2 de T-S84-A8 (recomendación firme heredada para s92). Los 2 hilos transversales (aviónica T-S84-A5 + ATA T-S84-A9) preservan tratamiento independiente: T-S84-A9 cerrada por materialización en s86 · T-S84-A5 sigue abierta como sesión dedicada futura. **8ª aplicación del patrón "destilado fundacional → integración al núcleo"** tras s68/s70/s76/s89.
* `lru_estructura_sectorial_s98.md` — **sexta cristalización fundacional (integrada en s99)** · 507 líneas · 3 citas literales de Manuel s97 D1 preservadas como gold (pulidas tras corrección metodológica de Manuel articulando sub-principio del Patrón 3 sobre transcripción de voz literal) + 5 citas literales de Manuel s71 recuperadas del precedente diferido. Articula el **Postulado 11 · Disposición evolutiva del diseño estructural del realm específico** sobre el acto de construir la plataforma (segundo postulado del diseñador del Realm complementario a P10 · par fundacional libertad creadora sobre contenido + disciplina evolutiva sobre estructura). **Integrado al núcleo en s99** como `LRU_FUNDAMENTOS §11quinquies` con 7 subsecciones (texto canónico §11quinquies.0 + articulación literal de Manuel §11quinquies.1 con las 3 citas s97 preservadas + distinciones P11 vs §11ter/P10/P9/P5 §11quinquies.2 + materializaciones concretas en el schema §11quinquies.3 + hilos transversales como ejercicio metodológico §11quinquies.4 + relación con principio 11 implícito y con P10 §11quinquies.5 + implicaciones para sesiones futuras §11quinquies.6 con cuatro preguntas operativas + anti-anticipación) preservando voz reconocible. Regla operativa derivada en `LRU_METODO §6ter "Disciplina evolutiva del diseño estructural"` con 7 subsecciones · paralelismo estructural directo con §6bis sobre P10. **Cuatro modos de cierre de tensión formalizados en `LRU_METODO §8.1`** con el cuarto modo (cierre tardío con reconocimiento de continuidad) extraído del agujero metodológico expuesto al cerrar T-S71-A2 en s98 · `§8.2` anotación de continuidad de tres campos canónicos · `§8.3` disciplina activa para sesiones futuras. **Sub-principio del Patrón 3 sobre transcripción de voz literal** anotado en `LRU_METODO §7 Patrón 3` (forma superficial es instrumental · ideas son esenciales · coherente con principio s74 §5 sobre nombres como instrumentales). Anotación complementaria (no absorción) en `LRU_ARQUITECTURA §8` sobre P11 reforzando principio 1 agnosia al dominio en su dimensión estructural fina (cadena P5→§11ter→P11) · principio 11 implícito sigue pendiente como dimensión arquitectural propia. MISION sin cambios por decisión explícita (replica disciplina s89 + s91). T-S97-F1 cerrada · regla de disputa retirada · **sexta cristalización fundacional culminada · ninguna cristalización fundacional pendiente al cierre de s99** (estado restablecido tras pendiente abierta en s98). Materialización empíricamente verificada desde s97 (pattern singleton+plural en aviation: `AviationProfile?` singleton + `AircraftProfile[]` plurales como hermanos planos extendiendo `RealmProfile` base · sin abstracción `SectorProfile` · 11 colecciones aviation pobladas con 53 entries totales) — primera instancia material del principio P11. **9ª aplicación del patrón "destilado fundacional → integración al núcleo"** tras s68/s70/s76/s89/s91/s98. **1ª aplicación del cuarto modo de cierre** ejercitada en el cierre formal de T-S71-A2 al cierre de s98 · disciplina formalizada en s99 al integrar este destilado.
* `lru_postulado_12_hardware_fisico_sustrato_s117.md` — **séptima cristalización fundacional (integrada en s123 tras 5 aplazamientos consecutivos s118-s122)** · 913 líneas · 76 KB · 11 citas verbatim preservadas (7 de Manuel + 4 articulaciones canónicas del corpus) · sembrada en s117 mediante cruce arqueológico de 11 sitios distintos del corpus durante ejecución del experimento §3.A del handoff s116→s117 (validación RAG con corpus ampliado). Articula el **Postulado 12 · El hardware físico es sustrato del sistema** como pieza estructural unitaria con sub-secciones para 3 encarnaciones físicas con propiedades estructurales propias: (a) microcontrolador con firmware `rpc1cl` v2.1.0 (25 sensores genéricos por dispositivo · 3 dispositivos identificados por MAC · 75 sensores HW totales · 7 entradas FPGA como ventana al horizonte LRM s69) · (b) teléfono con sensores variables por modelo (doble rol simultáneo humano-con-dispositivo + dispositivo-físico-autónomo · presencia efímera · sin implementación dedicada todavía) · (c) banco de pruebas con motor real (pieza profesional · presencia ocasional · uso para validación cruzada Realm A320 híbrido). Articulación canónica nueva producida en s117: *"laboratorio real/virtual de señales"* (formulación de Manuel · refinó *"laboratorio empírico de la universalidad"* propuesta inicial de Claude). **Integrado al núcleo en s123** como `LRU_FUNDAMENTOS §11sexies` con 7 subsecciones modelo §11quater/§11quinquies (texto canónico §11sexies.0 + dos citas literales de Manuel s53 §11sexies.1 — cita fundacional sobre dispositivos intercambiables que forzó el rediseño Realm v1→v2 + cita gold sobre concepto twin físico-virtual — + tres encarnaciones físicas §11sexies.2 + arquitectura común puerto≠canal/RouterService/cadena de transducción §11sexies.3 + laboratorio real/virtual de señales como articulación canónica §11sexies.4 + refinamiento de 7 postulados existentes sin invalidación §11sexies.5 + implicaciones para sesiones futuras + frente hwObj productor §11sexies.6) preservando voz reconocible. **Anotación complementaria** (no absorción) en `LRU_ARQUITECTURA §8` sobre la Capa 0 formalizada como sustrato del sistema (cadena P10→P11→P12 completa). **Sin §6quater en METODO** por decisión explícita: P12 articula propiedad estructural del sustrato físico no disciplina sobre cómo se construye el Realm · replica patrón §11ter (pluralidad de realms) que tampoco generó sección METODO. MISION sin cambios por decisión explícita (replica disciplina s89 + s91 + s99). T-S117-F1 cerrada · regla de disputa retirada · T-S119-1 (herencia activa de T-S117-F1 anotada en s119) cerrada por integración al núcleo en mismo movimiento · **séptima cristalización fundacional culminada · 12 postulados fundacionales explícitos integrados al núcleo · ninguna cristalización fundacional pendiente al cierre de s123**. Cluster mental §11/§11bis/§11ter/§11quater/§11quinquies/§11sexies completo con 6 capas · deuda latente anotada: una séptima cristalización del cluster activaría refactor de nomenclatura latina. **8ª aplicación del patrón "destilado fundacional → integración al núcleo"** tras s68/s70/s76/s89/s91/s99. **6 tensiones secundarias T-S117-N1..N6 vivas** orientando el frente *hwObj productor de señales* sin precipitar materialización (T-S117-N3 BleAdapter independiente como buen candidato para sesiones futuras de código del lado físico). **1 tensión meta** T-S117-M1 (1ª instancia del patrón "cristalización fundacional tardía") sigue como observación pendiente de 2ª ejercitación. Material distribuido en 11 sitios del corpus consolidado en sesión densa de cristalización fundacional emergente · destilado preserva voz original con 11 citas verbatim · sirve de referencia permanente sobre el sustrato físico del sistema más allá del nombramiento canónico actual del núcleo.

**Reclasificados en s129 desde §1.2.3 ejecutando notas internas pendientes** (D-s129-M · auditoría empírica de coherencia interna del MAPA al ejecutar palanca N de externalización navegacional):

* `lru_roles_mantenimiento_formacion_s84.md` — **destilado arquitectural s84 · referencia histórica post-materialización (T-S84-A8 cerrada s97 con Tanda 4)** · reclasificado a §1.2.5 en s129 ejecutando la nota interna *"se reclasifica a §1.2.6 (referencia histórica post-materialización)"* anunciada en s97 pero no ejecutada hasta s129 (32 sesiones de demora · cluster con T-S90-A* archivadas en s129 con 38 sesiones · patrón coherente). 1231 líneas · complementario al fundacional hermano `lru_postulado_10_diseno_como_innovacion_s84.md` (integrado s91). 19 decisiones de política consolidadas en 6 tandas temáticas sobre 18 tipos nuevos del schema Realm v3 (scope reducido: Part-66 AMT + Part-145 MRO + Part-147 MTO + Part-CAMO + Part-CAO con gancho declarado para flight crew y ATC futuros). Shapes TypeScript consolidados para los 18 tipos. Disciplina emergente articulada: *"cuando el corpus articula distinción estructural con propiedades específicas, el schema la expresa como tipo propio · cuando mezcla individuo + organización + fecha, queda fuera del schema como instancia runtime"*. Patrón confirmado: **10 discriminated unions en el schema tras s84** (4 existentes + 6 nuevas). Familia de 4 tipos documentales hermanos tras reformulación de F.3 (TechnicalPublicationDef denso + ExpositionDocumentDef + AirworthinessDef + TrainingDocumentDef · OperationalRecordDef fuera del schema). 9 tensiones nuevas registradas + plan α de 4 tandas · **T-S84-A8 cerrada por materialización completa s97** (Tandas 1-4 ejecutadas s90/s95/s96/s97). Se preserva como historia arquitectural del primer scope reducido aviation y como fuente original de los shapes TypeScript materializados en `src/realm/aviation/`.

* `lru_voz_fundacional_s74.md` — **destilado de voz preservada de la tercera cristalización fundacional · fuente parcialmente integrada (post-s76)** · reclasificado a §1.2.5 en s129 reflejando estatus real (la nota interna ya declaraba §§1-4 integrados en s76). 482 líneas · 23 citas literales de Manuel. **Estatus post-s76**: §§1-3 integrados en `LRU_MISION "Por qué este proyecto, ahora"` (T-S74-A1 cerrada) · §4 integrado en `LRU_METODO §5bis` (T-S74-A2 cerrada) · §5 (nombres como instrumentales) preservado como T-S74-A3 abierta · §6 (horizonte LRM) preservado por diseño · §7 (entrenamiento de la expresión con propiedad) preservado como T-S74-A4 parcial · §3 subsección "dominios no nombrados" preservada como T-S74-A5 abierta. **Fuente autoritativa post-integración para las 3 tensiones aún abiertas (T-S74-A3/A4/A5)** · referencia histórica para las 2 cerradas. Caso especial dentro de §1.2.5: integración parcial · sigue siendo fuente activa para tensiones abiertas pero sin regla de disputa global.

* `lru_estructuras_subyacentes_s71.md` — **destilado principal s71 · referencia histórica post-integración (s76)** · reclasificado a §1.2.5 en s129 reflejando estatus real declarado en su nota interna desde s76. 482 líneas. **Estatus post-s76**: integrado al núcleo como `LRU_FUNDAMENTOS §6.7` (nivel 0 físico) y `LRU_FUNDAMENTOS §11bis` (pluralidad de inteligencias con §11bis.3 entidades funcionales/declarativas). T-S71-A1 cerrada. Fuente autoritativa original preservada como referencia histórica con citas textuales de Manuel y articulación densa para trabajo futuro sobre T-S67-A1 (rediseño Realm v3).

* `lru_postulados_6_7_8_9_addendum_s69.md` — **addendum del destilado s69 · fuente parcialmente integrada (post-s76)** · reclasificado a §1.2.5 en s129 reflejando estatus real declarado en su nota interna desde s76. **Estatus post-s76**: integración pieza-por-pieza ejecutada según decisión de T-S74-A8 · §5 (máquinas de estados como sintaxis del enlatado) integrada en `LRU_FUNDAMENTOS §8.5` · §6.7 (dos clases de inteligencia enlatada) integrada en `LRU_FUNDAMENTOS §11bis.5` · §6 (nivel 0 físico) convergió con destilado s71 en `LRU_FUNDAMENTOS §6.7` · jerarquía de 4 niveles de bucles ya integrada en s70 como `LRU_FUNDAMENTOS §6.3` · **piezas preservadas sin integrar por decisión**: cinco propiedades de la conserva (§4.1) · latas no neutras como semilla ética (§4.5) · linaje cultural (§7). T-S74-A8 cerrada. Caso especial dentro de §1.2.5: integración parcial selectiva · piezas preservadas como referencia disponible si emergen como necesarias.

#### 1.2.6 · Destilados técnicos y de auditoría

* `lru_dieta_documental_s93.md` — **referencia histórica post-materialización** (reclasificado s94 tras ejecución de las 4 propuestas aprobadas + formalización de 5 disciplinas en `LRU_METODO §3`). 277 líneas. Destilado anillo 2 propositivo articulado en s93 con 5 propuestas de dieta documental arbitradas punto por punto vía `ask_user_input_v0` · 4 aprobadas para materialización + P4 status quo confirmado firme. **Materializado en s94 como 8ª aplicación del ciclo destilado→código · 1ª sobre objeto documental** (no sobre código de producto · primera del ciclo en esta categoría · candidato a sub-patrón si emerge segunda instancia futura): P3 matizado (pies estáticos en MAPA+METODO+CLAUDE_ARRANQUE preservando traza en MISION+FUND+ARQ por desviación arbitrada) · P1 (retirada §8bis+§8ter · −24.7 KB) · P2(c) (compresión cabecera línea 5 · descripción densa solo para 3 sesiones recientes) · P5(b) (handoff intermedio §0+§3+§4+§5+§7 con números originales preservados). 5 disciplinas formalizadas en `LRU_METODO §3` D1+D2+D3+D4+D5 absorbiendo además la disciplina correctiva s89 super-firme tras 6ª ratificación. P4 (TECH_DEBT por sesión) confirmado status quo firme · convención `LRU_TECH_DEBT_sN.md` continúa vigente. **3ª instancia del sub-patrón "tensión articulada y cerrada por materialización con ganancia colateral"** tras T-S83-A1 (s83) + T-S92-T1 (s92) · **consolida el sub-patrón firme**. T-S93-DIETA cerrada por materialización · ver §4.3 para detalle. MAPA reducido de 200.3 KB a ~165 KB tras la sesión completa. Se preserva como historia documental del primer cleanup sistemático de peso del núcleo y como ejemplo del ciclo destilado→código aplicado a objeto documental.
* `lru_atachapterdef_refactor_s85.md` — **referencia histórica post-materialización (s86) + fuente histórica del cierre fundacional T-S85-F1 (s89)**. 756 líneas. Doble función documental: (a) reclasificado en s86 tras ejecución completa de T-S84-A9-mat en las 3 tandas del plan γ; (b) reanotado en s89 como fuente histórica del cierre fundacional al integrar §2 + §10 al núcleo como `LRU_FUNDAMENTOS §11ter "Pluralidad de realms coexistiendo sobre base común"`. Fuente autoritativa original del refactor transversal ATA con 12 decisiones de política en 5 tandas (A arquitectura de pluralidad de realms · B shape + catálogo canónico · C refactor 6 ubicaciones · D disposición fichero huérfano · E plan materialización γ). Shape completo de `ATAChapterDef` con 12 campos + validación Zod cruzada (`superRefine` 4 validaciones) + catálogo canónico alcance β de 18 chapters + plan γ de 3 tandas. **Materializado en código en s86** sobre (T1) `src/realm/aviation/ata.ts` 296 líneas + `src/realm/aviation/index.ts` 24 líneas · primer realm específico del proyecto · test smoke 16/16 verde · (T2) `src/realm/{types,validators}.ts` con renombre `systemId?` → `taxonomyRef?` en `FaultDefBase` y `ActuatorDef` + `src/realm/examples/a320.realm.ts` con 10 actuators remapeados al formato catálogo + `src/pages/Analyzer1/protocols/arinc429/labels.ts` interface + 97 labels migrados + `adapter.ts` con `getATAChapter` · test smoke 13/13 verde · (T3) `src/types/ata.ts` reducido 369→70 líneas retirando framework paralelo obsoleto + S1000D preservado · grep preventivo confirmó cero consumidores del bloque obsoleto (T-S85-A6 cerrada negativamente) · `npx tsc --noEmit` exit 0 en entorno real con Zod v4.3.6. **Sexta instancia consecutiva del ritual de reclasificación post-materialización** tras s77/s78/s80/s83-T2/s83-T4. **Arquitectura de pluralidad de realms emergida en §2 del destilado** (2 citas literales de Manuel preservadas como gold) **integrada al núcleo en s89** como `LRU_FUNDAMENTOS §11ter` con las 2 citas preservadas literalmente — quinta cristalización fundacional del proyecto culminada (T-S85-F1 cerrada). Decisión ASCII-only aplicada en materialización: confidence `'bronze'/'silver'/'gold'` y iconos lucide en lugar de símbolos Unicode del destilado (divergencia deliberada aprobada por Manuel al arranque de Tanda 1). Hallazgo colateral aplicado en Tanda 2: los 10 `systemId` vivos en `a320.realm.ts` actuators remapeados con formato canónico `'ata-XX'` (no enumerado explícitamente en el destilado · registrado como ampliación de scope). Se preserva como historia arquitectural y como fuente del cierre fundacional s89.
* `lru_quantities_decision_s81.md` — **referencia histórica post-materialización** (reclasificado s83 tras ejecución del Bloque 4 de T-S67-A1 · T2). 366 líneas. Fuente autoritativa original del cierre arquitectural del Bloque 3 del triaje s75 (T-AU73-4). Articula 3 decisiones con nombres canónicos propuestos: **D1** · dos tipos declarativos de primera clase en v3 — `UniversalQuantityDef` (catálogo de magnitudes físicas invariantes · estructura estable del darwinismo digital) + `SignalDef` (instancia por sensor con rango/umbrales · contenido evolutivo · referencia a `UniversalQuantityDef` por id). **D2** · módulo de presentación separado — `src/realm/presentation.ts` hereda `represent()`, `findQuantityForSensor` y utilidades de lookup. **D3** · alcance mínimo estructural. **Materializado en código en s83 T2** sobre `src/realm/presentation.ts` (654 líneas, 21 UNIVERSAL_QUANTITIES, 62 DEFAULT_SIGNAL_QUANTITY_MAP entries, 4 consumidores UI migrados) con test de smoke 12/12 verde. **Quinta instancia consecutiva del ritual de reclasificación post-materialización** tras s77 (scenario_event_extension_s64), s78 (faultdef_refactor_s65), s80 (applyfault_mapping_s79) y s83 T2 (este destilado). Divergencia empírica notable en materialización: las 6 funciones ISA que el destilado §3.2 daba por duplicadas con `units.ts` no lo estaban · se migraron a `units.ts` en lugar de eliminarse (regla s70 ejercitada por 6ª vez). Hallazgo H7 empírico detectado al validar: `UniversalQuantityDefSchema.primaryUnit` relajado de `z.string().min(1)` a `z.string()` porque `mach` e `ils_deviation` son adimensionales con `primaryUnit:''` por diseño semántico. Se preserva como historia arquitectural.
* `lru_actuator_model_s79.md` — **referencia histórica post-materialización** (reclasificado s83 tras ejecución del Bloque 4 de T-S67-A1 · T1+T3+T4). 460 líneas. Fuente autoritativa original del diseño de `ActuatorDef` como entidad primera clase en Realm v3 · iteración del motor con callsite dual sensors/actuators · acoplamiento bidireccional sensor↔actuator · mapping literal de los 6 `ActuatorFaultDef.kind` con params/defaults/expresión · taxonomía conjunta sensor+actuator como catálogo estructural de los 22 kinds · camino de migración en 4 pasos desde estado actual a v3. **Materializado en código en s83** sobre (T1) `src/realm/{types,validators,index}.ts` con 3 tipos nuevos + validación cruzada superRefine + 20/20 tests verde · (T3) `src/realm/examples/a320.realm.ts` regenerado al shape s78+s83 con 10 ActuatorDef declarados + 6 ActuatorFaultDef canónicos materializados desde los proxies sim-catalog · (T4) `src/realm/applyActuatorFault.ts` nuevo con 6 kinds dispatcher + `src/simulation/SimService.ts` ampliado con updateActuators/sendActuatorCommand/toggleActuatorFault/setActiveRealm + `src/simulation/ControlBus.ts` con sendActuatorCommand · 18/18 tests verde. **Cuarta instancia consecutiva del ritual de reclasificación post-materialización** tras s77, s78, s80 (la quinta en s83 es `lru_quantities_decision_s81.md`). Patrón "destilado paralelo de diseño futuro como alternativa a código sin callsite" confirmado completo: el destilado sobrevivió 4 sesiones como diseño articulado antes de materializarse. Se preserva como historia arquitectural y ejemplo vivo del patrón.
* `lru_applyfault_mapping_s79.md` — **referencia histórica post-materialización** (reclasificado s80 tras ejecución del Bloque B del triaje s75). 510 líneas. Fuente autoritativa original del mapping literal de los 16 `SensorFaultDef.kind` con params, defaults, expresión matemática, estado requerido (sí/no), riesgos · propuesta de contrato nuevo `applyFault(fault, value, elapsed, runtime) → number` · 6 decisiones de diseño cerradas en s79 aprobadas por Manuel (estado mutable Opción A · genéricos Opción C · erratic random walk · hard-over callsite · pink IIR 1-polo · delay buffer 240). **Materializado en código en s80** sobre `src/simulation/SimService.ts` con test de smoke 62/62 verde. **Tercera instancia consecutiva del ritual de reclasificación post-materialización** tras s77 (scenario_event_extension_s64) y s78 (faultdef_refactor_s65) — el patrón se confirma como disciplina canónica. Divergencia notable aplicada en s80: el destilado §4.2 proponía shim de compat con `GENERIC_FAULT_COMPAT` pero la promoción de los 3 genéricos al realm (catálogo s79) hizo el shim innecesario · el wildcard resolver en `toggleFault` lo sustituyó limpiamente. Se preserva como historia arquitectural y ejemplo vivo de cómo el destilado propone y la realidad del código dispone.
* `lru_triaje_tau_s75.md` — **triaje operativo de las 14 tensiones T-AU** (bloque E.3 de la Opción E en s75) · 209 líneas · consolida T-AU72-1..4 + T-AU73-1..10 en 4 decisiones estructurales + 2 plantillas empíricas + 1 resoluble simultáneamente + 7 cleanups triviales · organizado en 5 bloques de ejecución para T-S67-A1 · **entrada ordenada directa para el rediseño v3** · regla de disputa activa hasta que T-S67-A1 cierre · **Bloque 2 desdoblado retroactivamente en A (s79 ejecutado) + B (s80 pendiente)**.
* `lru_auditoria_tecnica_s73.md` — **Fase 0 Ejes 3+4+5 de auditoría técnica empírica** · 495 líneas · auditoría de `sim-catalog.ts`, `quantities.ts`, `units.ts`, `SimService.ts` con triangulación contra destilados s62/s63/s65 · **10 tensiones T-AU73-1..10** registradas con severidad explícita (4 alta absorbibles en T-S67-A1, 2 positivas como plantillas de refactor) · patrón "articulación sin ejercicio" consolidado con 4 instancias · cobertura real `applyFault` 3/33 (no 6/33 como afirmaba destilado s65 §1.2) · §8 consolida entrada verificada para T-S67-A1 junto con §8 del destilado s72.
* `lru_auditoria_schema_v2_s72.md` — **Fase 0 Ejes 1+2 de auditoría del schema Realm v2 escrito** · 381 líneas · coherencia types↔validators impecable (15 pares campo-a-campo) · integridad referencial `a320.realm.ts` impecable · **T-AU72-2 CERRADA COMPLETA en s78**: las decisiones s63-s65 (apply-profile en s77 + SensorFaultDef/ActuatorFaultDef + CruisePatternDef en s78) aplicadas al código del schema. Destilado conserva valor como trazabilidad del estado pre-materialización.
* `lru_faultdef_refactor_s65.md` — **referencia histórica post-materialización** (reclasificado s78 tras ejecución del Bloque 1 ítems 2 y 3). ~500 líneas. Fuente autoritativa original del diseño de separación `SensorFaultDef` (16 variantes) + `ActuatorFaultDef` (6 variantes) con `FaultDefBase` común · 22 kinds totales validados por literatura canónica. Materializado en código en s78 sobre `src/realm/{types,validators,index}.ts`. Se preserva como historia arquitectural y como contraste empírico.
* `lru_scenario_event_extension_s64.md` — **referencia histórica post-materialización** (reclasificado s77 tras ejecución del Bloque 1 ítem 1). 494 líneas. Fuente autoritativa del diseño de `apply-profile` como 5º kind de `ScenarioEvent` con unión discriminada estricta (cierre arquitectural de T-S63-8 en s64). Materializado en código en s77 sobre `src/realm/{types,validators,index}.ts` con las dos piezas diferidas (validación monotónica de `t` + `ScenarioDef.durSeconds?`) aprobadas explícitamente por Manuel e incluidas. Se preserva como historia arquitectural.
* `lru_realm_v2_dirigido_s63.md` — revisión dirigida del schema Realm v2 con foco en 8 preguntas abiertas del inventario s62-s63 · cierra 5 preguntas, deja 2 abiertas con ruta (O6 cerrada en s65), detecta T-S63-8 cerrada en s64.
* `lru_sim_catalog_inventory_s63.md` — inventario cuantitativo con juicio de `src/simulation/sim-catalog.ts` (89.75 KB · 1158 líneas · 5 displays · 25 systems · 205 sensores totales · 17 escenarios · 33 faults · 4 helpers). Resuelve T-S62-A1/A2/A3 con evidencia empírica. Detecta T-S63-1..T-S63-7. **Nota cruzada**: conteos refinados por auditoría empírica s73 — `buildHwSensors` devuelve 25/dispositivo no 26 (total HW: 75 no 78, catálogo: 202 no 205), ver T-AU73-1. **Nota cruzada s79**: el fichero `sim-catalog.ts` ha crecido tras la migración del Bloque A (1158 → 1224 líneas aprox · +66 por cambio de interface y migración de faults a kind + params tipados).
* `lru_pfd_catalog_inventory_s62.md` — inventario de `src/simulation/pfd-catalog.ts` · source s37 congelado tras integración a `sim-catalog.ts` (validado por s63).
* `lru_quantities_inventory_s62.md` — inventario de `src/simulation/quantities.ts` (36.65 KB · 21 quantities · 14 dimensiones · motor cross-dimension con 6 funciones ISA ejecutables). Cruces con `pfd-catalog.ts` originaron A1/A2/A3 cerradas en s63. **Nota cruzada**: motor cross-dimension sin consumidores en SimService — T-AU73-4.
* `lru_units_inventory_s62.md` — inventario de `src/simulation/units.ts` (7.2 KB · 10 constantes ISA · 14 conversiones · 3 funciones ISA · **6 funciones aerodinámicas aplicadas** candidatas a `namedFormulas` del motor). Validadas por `a320.realm.ts` en s63 y por `computeDerived` de SimService en s73 (T-AU73-9 positiva).
* `lru_realm_v2_analysis_s60.md` — destilado de lectura del código del Realm v2. Complementado por `lru_realm_v2_dirigido_s63.md`.

#### 1.2.7 · Destilados de síntesis amplia

* `lru_docs_synthesis_s55_bloques_a_b_c.md` — 18 hallazgos numerados de lectura de 10 documentos en s55. Evita releer los originales.
* `lru_session_s53_memoir.md` — memoria narrativa del rediseño arquitectural de s53.
* `lru_realm_v2_schema_s56.html` — documento arquitectural online del schema TypeScript/Zod implementado en `src/realm/`. Referencia viva del Realm v2.
* `lru_debug1_analysis_s55.md` — andamiaje para sesión dedicada Debug1 con código.

#### 1.2.8 · Operativos de uso frecuente

* `lru_docs_workflow.html` — flujo de edición markdown → HTML.
* `lru_design_system.html` — si existe (verificar al refundar index).


---

*LRU Platform · Catálogo del Anillo 2 · Documento vivo del anillo 1.B · 2026-05-24 · Manuel & Claude Opus 4.7 · sincronizado al cierre de s158 (entrada nueva s158: 1 destilado pendiente de materialización añadido a §1.2.3 saliendo del "bloque vacío" del cierre s129 · `lru_destilado_facetas_multivista_s158.md` · 9ª aplicación operativa disciplina alfiler s125 forma alfiler→destilado · regla de disputa activa hasta sesión de materialización futura · cierre arquitectural T-S151-N2 4ª reformulación + T-S158-P13-CAND nominada) · sincronizado al cierre de s150 (entrada nueva s150: 2 frentes productivos bug-fixing estructural PanelGrid + 1 articulatorio descubrimiento naming sim1_ · sin aplicaciones nuevas de patrón canónico/doctrina doble vida/contrato passthrough · 1 lección operativa cristalizada audit cruzado con referencia funcional · 1 sub-patrón candidato 1ª instancia "feature percibida como regresión que era cobertura parcial") · externalizado desde §1.2 del MAPA mediante palanca N etapa 2 de externalización navegacional · 8 sub-categorías por estatus funcional preservadas (Patrón 3 · D-s129-F) · 1.2.1 anclas tech debt acumulativas · 1.2.2 piezas permanentes · 1.2.3 regla de disputa activa · 1.2.4 diferidos por Manuel · 1.2.5 históricos post-integración · 1.2.6 técnicos y auditoría · 1.2.7 síntesis amplia · 1.2.8 operativos de uso frecuente*