# LRU_MAPA > Fichero: `LRU_MAPA.md` · documento vivo sin sufijo de sesión > Ubicación canónica: `public/docs-app/v1/doc/LRU_MAPA.md` > Origen: sesión s58 · 2026-04-18 · sincronizado al cierre de s251 (2026-08-08) · esta línea dejó de ser log en s203 (D-s203-A): el detalle de cada cierre vive en `LRU_ESTADO.md` y en `LRU_HANDOFF_VIVO.md` · histórico de cierres en el git de este fichero > Propósito: índice y registro transversal del proyecto — catálogo documental, memoria activa, registro de tensiones, guía de arranque. > Documentos hermanos del núcleo: `LRU_MISION`, `LRU_FUNDAMENTOS`, `LRU_ARQUITECTURA`, `LRU_METODO`. --- ## Última sesión cerrada **Externalizado a `LRU_ESTADO.md`** (régimen s203/s204 · D-s203-A + D-s204-H): el snapshot de la última sesión cerrada vive en `LRU_ESTADO.md` (fuente primaria · regenerado en cada cierre) y el detalle en `LRU_HANDOFF_VIVO.md`. El MAPA dejó de duplicar este bloque — su histórico vive en el git de este fichero (el bloque quedó clavado en s200 durante s201-s203 · inercia retirada en s204). --- ## Sesiones previas **Externalizado a `LRU_BITACORA_SESIONES_VIVO.md`** (anillo 1.B.2 · histórico condensado s89→s198 + registro mecánico §B desde s204 · hueco declarado s199→s203 D-s204-A). El estado de la última cerrada vive en `LRU_ESTADO.md`. | Sesión | Fecha | Resumen 1 línea | |---|---|---| | **s199** | 2026-06-08 | Sesión de código · **Fase A del colapso de nomenclatura COMPLETA (A2+A3) + Fase B arrancada (B0)** · A2 (`62e54e87` SensorBrowser `groupByPrefix`→`groupByOrigin` + `0a985e31` `origin` por el payload de Analyzer1) · A3 (`cc3c38ae` PUNTO DE NO RETORNO: `_registerCatalog` aplana `name=sensor.id`, mundo sim/hw solo en `origin`, `PREFIX_*` fuera + `c79dcf22` `watchAll('*')`) · B0 (`dc2ddfe1` `facetDisplay` 6ª firme) · cierra T-S198-NAMESPACE-UNICO + T-S151-N2 (eje nombre) + U3 de T-S194 · 5 commits · build verde 2202 + 444/444 (+6) · 0 núcleo. | | **s198** | 2026-06-07 | Sesión mixta (articulatoria P7 + 1 rebanada de código) · **reencuadre del frente + Fase A del colapso de nomenclatura (eje NOMBRE)** · U2.5 de T-S194 era premisa falsa → objetivo = una sola lista común de NOMBRES, «después agrupar» · datos ya unificados (T-S190/T-S189) pero el nombre sigue partido (prefijo `sim/hw` en el `DataPlane`) · **A1** `3386faa` (`createOriginFacet` 5ª firme + `ChannelMeta.origin` de `displayId` · aditivo) · hoja de ruta de 3 fases cristalizada (`lru_alfiler_namespace_unico_s198.md`) · D-s198 · 1 commit · build verde 2201 + 438/438 (+5) · 0 núcleo. | | **s197** | 2026-06-07 | Sesión de código · **U2.4 (T-S194 · «agrupación como faceta» · umbrella T-S183): store de lente compartida + sync cross-lego** · U2.4.1 `8df79d3` (lensStore singleton vanilla + useSharedLens · canónico neutro `flat|system`) → … → U2.4.5 `c10a488` (LruBar a lente única panel-level · cabecera nueva sobre el grid · SUPERSEDE per-tarjeta de D-s195) · D-s197 · 5 commits · build verde 2200 + 433/433 (+8) · 0 núcleo. | | **s196** | 2026-06-07 | Sesión de código · **U2 (T-S194 · «agrupación como faceta» · umbrella T-S183): faceta `system` centralizada en `queryFacets` + lego `FacetLensBar`** · U2.1 `4ce735e`/`92449c3` (faceta funcional · sim→`systemId` / hw→cruce `signalForPort`) + U2.2 `b67ddd4` (lego toolbar host-neutral · LruBar botón `f`) + U2.3 `0442055` (1er reúso cross-lego: Mixer agrupa por `system`) · D-s196 · 4 commits · build verde 2198 + 425/425 (+11) · 0 núcleo. | **Para detalle**: leer `LRU_BITACORA_SESIONES_VIVO.md`. --- ## Qué es este documento `LRU_MAPA` es el único documento del núcleo que **no tiene dominio propio** — tiene **función propia**. Su dominio es el sistema entero. Los otros cuatro canónicos responden cada uno a una pregunta específica (para qué, de qué está hecho, cómo está construido, cómo se trabaja). El MAPA no añade contenido nuevo sobre ninguna de esas preguntas: las referencia. Su valor está en ofrecer **visión simultánea de lo que vive repartido en otros sitios**, y en ser el lugar único donde conviven cuatro funciones que el proyecto necesita agregadas: 1. **Catálogo temático** — dónde está la información sobre cada tema, con estado de cada documento. 2. **Memoria activa** — la lista "lo que no debes olvidar": ideas que se reinventarían si no se recuerdan. 3. **Registro de tensiones** — tensiones abiertas, articuladas y resueltas, con historial en una misma tabla. 4. **Guía de arranque por tipo de sesión** — qué adjuntar según qué trabajo vaya a hacer la sesión. Las cuatro funciones conviven sin separación formal. El MAPA opera en tres registros simultáneos — **historia** (qué se decidió y cuándo), **navegación** (puntero a dónde vive cada decisión), **gestión** (qué sigue abierto) — sin que haga falta etiquetar cada entrada con cuál de los tres cumple. **Regla esencial del MAPA:** cuando un item tiene contenido extenso, **el contenido vive en su canónico de autoridad** (MISION / FUNDAMENTOS / ARQUITECTURA / METODO / destilado). El MAPA registra la existencia del item con puntero — nunca duplica la explicación. Esto garantiza autoridad única por tema y evita contradicciones. **Regla de higiene del MAPA (articulada s75).** El MAPA no es núcleo paralelo. Cuando material del MAPA queda integrado en un canónico con autoridad plena, la entrada del MAPA pasa a ser puntero corto — nunca duplicado extenso. La purga de duplicación es parte del saneamiento periódico, no trabajo extraordinario. --- ## 0 · El núcleo vivo Cinco documentos canónicos sin sufijo de sesión. Cualquier persona o Claude que arranca en el proyecto empieza por aquí. | Documento | Responde a | |---|---| | `LRU_MISION.md` | ¿Para qué existe el proyecto? | | `LRU_FUNDAMENTOS.md` | ¿De qué está hecho el sistema? | | `LRU_ARQUITECTURA.md` | ¿Cómo está construido ahora mismo? | | `LRU_MAPA.md` *(este)* | ¿Dónde está cada cosa? ¿Qué tensiones hay abiertas? | | `LRU_METODO.md` | ¿Cómo se trabaja en este proyecto? | **Estado al cierre s157**: 12 postulados P1-P12 integrados al núcleo · 0 cristalizaciones fundacionales pendientes · 2 postulados candidatos articulados pendientes integración (P13 Primacía visual del nombrado · P15 Dos paradigmas complementarios) · Glosario Canónico Atlas integrado en `LRU_METODO §4bis`. **Regla de autoridad única por tema.** Si dos documentos se contradicen sobre misión, el canónico es `LRU_MISION`. Sobre arquitectura, `LRU_ARQUITECTURA`. Sobre método, `LRU_METODO`. El MAPA no tiene autoridad de contenido — tiene autoridad de índice y registro transversal. **Regla del núcleo** (de `LRU_METODO` §8): un Claude nuevo que arranca con solo los cinco documentos del núcleo más el handoff y el tech debt debe poder trabajar útilmente. Si no puede, el núcleo está incompleto o desactualizado. ### Sobre el anillo 0 (articulado en s60) El proyecto utiliza un **Proyecto de Claude** configurado con los ficheros que se adjuntan automáticamente al arrancar cualquier sesión: `CLAUDE_ARRANQUE.md` + los cinco canónicos + tech debt vigente + handoff activo. Funcionalmente es un **anillo 0** de memoria de arranque. Detalle en `LRU_METODO` §1 y §3. `CLAUDE_ARRANQUE.md` vive en `/doc/` como pieza **operativa complementaria** al núcleo — no es canónico número 6. --- ## 1 · Catálogo documental Inventario organizado por anillo. Los documentos cambian de anillo cuando cumplen los criterios de `LRU_METODO` §2. ### 1.1 · Anillo 1 — núcleo vivo Los 5 canónicos descritos en §0, desplegados en `public/docs-app/v1/doc/`. **`CLAUDE_ARRANQUE.md`** vive al raíz como pieza **operativa complementaria** al núcleo (no es canónico número 6 — es briefing para Claude al arrancar). **`LRU_FIRMWARE_PUBLICACION_VIVO.md`** (nace s227) — pieza operativa viva: ciclo completo de publicación de firmware de la flota (bump → build → publicar → commit → deploy · herramienta `scripts/gen-manifest-s227.ps1` · cerrojos de coherencia · convención `-.bin` y versión de flota `0..` · D-s227-A: bins dentro del repo en `public/firmware/`). ### 1.2 · Anillo 2 — destilados vigentes **Externalizado a `LRU_CATALOGO_ANILLO2_VIVO.md`** (anillo 1.B · pieza viva · 51+ ítems en 8 sub-categorías). Cualquier nuevo destilado se cataloga en el fichero vivo · no aquí. **Para el catálogo completo**: leer `LRU_CATALOGO_ANILLO2_VIVO.md`. #### 1.2.A · Subsección viva mínima Información operativa imprescindible al arrancar: * **Tech debt vigente (ancla activa)**: `LRU_TECH_DEBT_s200.md` — deuda técnica vigente al cierre s200. Detalle del tech debt anterior (s199) y previos en `LRU_CATALOGO_ANILLO2_VIVO.md §1.2.1`. * **Destilados pendientes de integración al núcleo (regla de disputa activa)**: * `lru_destilado_facetas_cat6_enlace_s161.md` — articulación 6ª catalogación Cat.6 enlace N:M aguja↔sensor · contrato `Facet` extendido con `kind` discriminante (`'sensor' | 'edge'`) · átomo `EnlaceValue` + `EdgeFacet` · 5 decisiones D-Q1..Q5 arbitradas · **materializado en s162** según plan §11 (6 pasos ejecutados · 3 firmes migradas a `kind:'sensor'` · `facetEnlace.ts` nuevo · `query()` extendido · 12 tests unit nuevos · factoría `createRegistryWithEnlaces` por inyección D5=A) · regla de disputa sólo activa sobre lo no materializado (consumidor inaugural Cat.6 diferido a sesión posterior según Camino Y estricto) · 2ª aplicación operativa de P13 candidato (la API consultora s160 fue 1ª aplicación operativa). * `lru_destilado_facetas_multivista_s158.md` — API consultora multi-faceta sobre 5 catalogaciones (ATA + quantity + hwObj/puerto + protocolo + TipoSensor) · cerrado arquitecturalmente T-S151-N2 (4ª reformulación v4) · **materializado en s160** (3 facetas firmes + 2 diferidas + 1 candidata sembrada) · regla de disputa sólo activa sobre lo no materializado (Cat.4 protocol diferida · Cat.5 tipoSensor diferida) · candidato T-S158-P13-CAND nominado. * **Alfileres pendientes de integración o materialización eventual**: * `lru_alfiler_enlaces_sustrato_s162.md` — **NUEVO s162** · naturaleza dual `enlaces` como sustrato vs estado de UI · 14.55 KB · 10 secciones · voz fundacional Manuel s162 preservada verbatim §0 · 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 `EnlacesPlane` diferida con refactor trivial A→B1 · hereda diálogo con T-S161-DOC-1. * `lru_alfiler_facetas_multivista_s157.md` — alfiler raíz del patrón catalogaciones múltiples ortogonales (precedente s157 · destilado s158). * `lru_alfiler_dos_universos_nomenclatura_s151.md` — alfiler raíz de la cadena T-S151-N2 (rectificado por runtime s157 · absorbido arquitecturalmente s158 · cerrado operativamente s160). #### 1.2.B · Tabla resumen Anillo 2 | Sub-categoría | Ítems | Naturaleza | |---|---|---| | 1.2.1 · Canónicos acumulativos | ~42 | Anclas tech debt históricas (s56→s160). El s161 vigente vive en §1.2.A. | | 1.2.2 · Piezas documentales permanentes | ~11 | Archivos vivos sin caducidad: atlas proyecto-meta s74 · arqueologías · destilado dieta · alfileres hilo conductor. | | 1.2.3 · Pendientes de integración | **2** | `lru_destilado_facetas_multivista_s158.md` (parcialmente materializado s160) + `lru_destilado_facetas_cat6_enlace_s161.md` (s161 · articulado · pendiente materialización). | | 1.2.5 · Históricos post-integración | 9 | 7 cristalizaciones fundacionales culminadas (P1-P12 + pluralidad realms + P10 + P11). | | 1.2.6 · Técnicos y de auditoría | 16 | Schemas + auditorías + inventarios + diseños + reglas operativas. | | 1.2.7 · Síntesis amplia | 4 | Síntesis cruzadas s55/s105/s108/s115. | | 1.2.8 · Operativos uso frecuente | 2 | Workflow doc + design system. | ### 1.3 · Material arquitectural vigente pendiente de absorción Documentos arquitecturales históricos con contenido no totalmente absorbido por el núcleo: | Documento | Estado | |---|---| | `lru_bus_architecture.html` (s25) | Base §2.2 y §4 LRU_ARQUITECTURA · referencia transporte | | `lru_analyzer1_architecture_v4.0_s18.html` | Vigente · describe Analyzer1 v4 | | `lru_enlaces_panel.html` | Vigente · mesa de parcheo como metáfora | | `lru_comms_deep_analysis_s32.html` | Vigente · análisis de flujos no absorbido completamente | | `lru_sim1_bridge_architecture.html` | Vigente · 4 capas del bridge, IB_04 | | `lru_analyzer_protocol_platform.html` | Huérfano útil mayor · visión formativa Analyzer fases 5-6 (T-S55-C1) | | `lru_mapa_plataforma_s137.html` (60 KB) | Referencia visual maestra · 3 estratos + 3 dimensiones transversales | | Material pre-Realm v2 (`fase4_signal_model.html` · `ib04_binding_model_s32.html` · `ib04_hardware_model_s32.html` · `aircraft_model_design_s33.html`) | Prehistoria absorbida · archivar cuando C2 se complete | ### 1.4 · Anillo 3 — archivo histórico Creado en s59 en `public/docs-app/v1/doc/archivo/` con 114 ficheros (referencias/29 · handoffs/38 · raíz/47). La trazabilidad git permite reconstruir siempre dónde vivía un documento. Movimientos en `archive-manifest-s59.md`. --- ## 2 · Arquitectura pendiente y subsistemas Punteros a los subsistemas con trabajo arrastrado. El contenido vive en `LRU_ARQUITECTURA` y `LRU_FUNDAMENTOS`. ### 2.1 · Buses y transporte Ver `LRU_ARQUITECTURA` §2.2 (DataPlane), §3.1 (CommsManager), §4 (fronteras F1-F5). ### 2.2 · Bridge e instrumentos IB_04 consolidado desde s37. Ver `LRU_ARQUITECTURA` §6.5. Pendientes: subsistema `test1` sin documentar (T-S55-N5), auditoría residuos IB_03 post-s38 (T-S55-N6). ### 2.3 · Analyzer y protocolos 3 protocolos activos de 9 en roadmap pre-s152 · **s152 amplió a 6 protocolos** (DataPlane integrado como 6º) · **s240 amplió a 7** (`rpc` · plano de mando RPC de la PWA · `protocols/rpc/` · tap multi-canal del `RpcClient`). Ver `LRU_ARQUITECTURA` §3.3. Pendientes: fases 5-6 error injection/exercises (T-S55-C1), métodos `validate`/`getOsiMapping` sin implementación (T-S55-C2), RabbitMQ multi-protocolo sin articulación formal (T-S55-C3). ### 2.4 · Debug1 — subsistema transversal Articulado en s55. **s152 inauguró parcialmente el Debug1 viewer dentro del Analyzer1** (gap mayor desde s55 cerrado parcialmente · T-S55-A2 cerrada parcial). Detalle: `lru_alfiler_dataplane_viewer_s152.md` + `lru_debug1_analysis_s55.md`. ### 2.5 · Simulación SimService operativo. `sim-catalog.ts` migrado en s79 al vocabulario `SensorFaultDef`. C2 fase A SUSPENDIDA hasta cierre T-S67-A1. ### 2.6 · Realm v2 → v3 Schema Realm v2 desplegado en `src/realm/` desde s56. C2 es la integración (suspendida). Rediseño hacia v3 (T-S67-A1) absorbe decisiones s63-s65 + piezas destilado paralelo s79. ### 2.7 · Plataforma estratificada (articulada s137) **3 estratos verticales + 3 dimensiones transversales** articulados en `lru_mapa_plataforma_s137.html` (60 KB · referencia visual maestra). Estrato 1 (núcleo singleton · 12 piezas) + Estrato 2 (superficies hermanas · Sim1/Sim2/Sim3/Sim4/Col4/Debug1/Analyzer1) + Estrato 3 (capas semánticas C1-C11). Dimensiones: Comms (7 adapters) · Analyzer1 (10 protocolos en 5 familias OSI) · Visor (catálogo disperso). Postulado candidato P-N18 sembrado · 1ª articulación · pendiente 2ª aplicación. ### 2.8 · Observatorio de señales (articulado s155/s156/s157) Frente arquitectural mayor articulado en alfileres s155 (`lru_alfiler_observatorio_senales_s155.md` 20.3 KB) + s156 (reformulado de "lujo" a "herramienta diagnóstica preventiva" · `lru_alfiler_observatorio_reformulado_s156.md` 32.7 KB + `lru_observatorio_mapa_fuentes_s156.md` 21.9 KB) + s157 (3 piezas arqueológicas: inventario consumidores + trinidad SignalEngine + geografía desconexión uso real · ~107 KB). **3 dependencias críticas para materialización**: T-S151-N2 reformulada por runtime s157 + clarificación `source` + inventario consumidores completado. Trinidad universal infraestructural identificada: IB_04 (pull) + DataPlaneSpy (subscribe '*' · operativo desde s152) + SignalEngine (procesador). 3 caminos de materialización articulados sin arbitraje firme (Camino A vista nueva Analyzer1 SP6.4 · Camino B superficie nueva Observatorio1 · Camino C destilado articulatorio). --- ## 3 · Lo que no debes olvidar **Externalizado a `LRU_PRINCIPIOS_OPERATIVOS_VIVO.md`** (anillo 1.B.1). La fuente canónica de los principios sigue siendo `LRU_FUNDAMENTOS.md`. Índice de las 4 categorías (detalle en el fichero externo): * **§3.1 · Fundacionales** · P1-P12 con síntesis operativa rápida. * **§3.2 · Arquitecturales** · motor singleton compartido · contratos data+actions · MCP filesystem · cascada fallback 4 niveles · paneles autocontenidos. * **§3.3 · Metodológicas** · disciplinas D1-D5 (`LRU_METODO §3`) · 4 modos de cierre de tensión + 6º candidato (descubrimiento de información correcta · 2 instancias documentadas s126+s133) · disciplina del alfiler s125 (7 aplicaciones acumuladas) · D-s111-1 auditoría empírica · Patrón 3 voz literal. * **§3.4 · Voz y disciplina fundacional** · material residual s74. --- ## 4 · Registro de tensiones ### 4.1 · Convenciones de identificación ID formato `T-S{N}-{C}{n}` donde `S{N}` es sesión de detección · `{C}` es categoría (A arquitectural · M método · C cleanup · T técnica · N nomenclatura · B Atlas · F fundacional · AU auditoría) · `{n}` secuencial. ### 4.2 · Tensiones abiertas **Externalizado a `LRU_TENSIONES_ABIERTAS_VIVO.md`** (anillo 1.B · pieza viva · 77+ tensiones operativas + 2 hallazgos positivos). El MAPA conserva tabla resumen ultra-condensada abajo · detalle en el fichero externo. **Para consultar el detalle**: leer `LRU_TENSIONES_ABIERTAS_VIVO.md`. ### 4.2.bis · Tabla resumen ultra-condensada Snapshot al cierre s181. Triada por prioridad. #### Prioridad alta (8) | ID | Resumen | |---|---| | `T-S165-UNIFICACION-ARBITRAJE` | **Frente activo · paraguas** · AVANZA · per-señal **R0+R1+R2a+R2b hechos** (rename + notify ControlBus + dropdown per-slider en LruBar vía lego `SignalModeSelect` + lote del LruToolbar · Mixer y LruBar comparten signalModes entero) · queda **R3** (quitar Auto/origin + semilla · articulado y diferido · `lru_alfiler_r3_quitar_auto_origin_s181.md` · D-R3-A/B abiertas) + después retirada del gate per-hwObj · absorbe T-S164/T-S163/T-S162/T-S157/T-S161-DOC-1 | | `T-S67-A1` | Rediseñar schema Realm hacia v3 (`ActuatorDef`, `IntelligenceDef`, `GuideDef`...) | | `T-S67-A2` | C2 fase A SUSPENDIDA | | `T-S84-A5` | AvionicsInfrastructureLayer | | `T-S151-N2` | Unificación namespace sensores · cerrada operativamente s160 por absorción arquitectural (5º modo) | | `T-S155-N3` | Observatorio de señales · 4 acepciones articuladas · informado por destilado s158/s160 (acepción 4 cartográfica se reduce con API consultora · acepciones 1+2+3 runtime ortogonales) | | `T-S158-P13-CAND` | Candidato cristalización fundacional 8ª · "catalogación facetada · entidades funcionales como sustrato unificado · N catalogaciones declarativas ortogonales · API consultora uniforme" · 1ª aplicación operativa (s160) + 2ª aplicación articulatoria (s161 Cat.6 con `EdgeFacet`) · pendiente sesión dedicada | | `T-S160-CAT6-CAND` | **Cerrada arquitecturalmente s161** · destilado `lru_destilado_facetas_cat6_enlace_s161.md` con 5 decisiones D-Q1..Q5 + extensión contrato `Facet` con `kind` · pendiente cierre operativo por materialización | #### Prioridad media-alta (3) | ID | Resumen | |---|---| | `T-S117-N2` | Materialización `HardwareProfile extends RealmProfile` con esquema canónico | | `T-S117-N4` | App teléfono como hwObj productor | | `T-S149-MODAL-CANONICO` | Migrar 4 modales backdrop+panel a TechModal canónico | #### Prioridad media (~15) | ID | Resumen | |---|---| | `T-S117-N1/N3` | Materialización `puertoHwObj` 75 sensores HW + BleAdapter ESP32↔navegador | | `T-S122-OSC/densidad` | Coste re-render roots realm denso · system `ble_A92418` con 26 sensores | | `T-S124-1` | Pin/annotations no sincronizadas cross-host | | `T-S125-N1/N2/N3` | SystemsPanel rico aplazado · modelo plano composable · disciplina alfiler formalizar | | `T-S128-N1` | Renumeración coherente del sistema documental | | `T-S134-DOC-1` | Disciplina alfiler s125 · 10 aplicaciones acumuladas tras s159 (Observador1 v1 consumidor inaugural destilado s158) · candidato firme a formalización en `LRU_METODO §7/§8` | | `T-S137-P-N18-CRISTALIZACION` | Postulado candidato plataforma estratificada · pendiente 2ª articulación | | `T-S144-N1` | Lag sistémico cambio simulación · preexistente · no bloqueante | | `T-S149-NINTH-LEGO` | Cristalización canónica Anillo 2 madura · 9+5 aplicaciones acumuladas | | `T-S153-N4` | Bottom panel responsive · cerrada 13/13 en s155 | | `T-S154-N1` | TraceView tokens responsive · cerrada en s155 | | `T-S157-CAND-1` | Desacoplar tick SignalEngine de SignalLab montado | | `T-S157-CAND-2` | 4 modos RouterService como dimensión causal del cruce · vista panorámica | | `T-S84-A2/A3/A4/A6` | Derivación privilegios B2 · KnowledgeModuleDef · TaskDef Part-66 · AmendmentDef↔CaseStudyDef | | `T-S85-A2` | Patrón "tipos+validadores+catálogos por realm específico" | #### Prioridad baja / diferida (~50) Tensiones diferidas vivas: T-S55-N1..N9 + T-S122-X + T-S127-N1/N2/N3 + T-S133-N1..N5 + T-S134-N6..N14 + T-S135-DEUDA-1/2/3/4 + T-S137-VP-* + **T-S179-CHART-FUENTE** (media · Chart lee la autoridad · Camino A hecho · Camino B 4 piezas diferido) + **T-S179-CHAIN-SENALES** (P11 · encadenamiento señal→señal con conversión · absorbe T-S174) + **T-S180-PROSA-MODO** (baja · prosa de comentarios del eje modo aún en "per-sensor") + otras menores. **Detalle completo en `LRU_TENSIONES_ABIERTAS_VIVO.md`**. ### 4.3 · Tensiones resueltas — historial **Archivado**: `lru_tensiones_resueltas_archivo_s128.md` (48 KB · 30 filas pre-s128) + `lru_tensiones_resueltas_archivo_s129.md` (14 KB · 8 filas s128/s129). Cierres posteriores a s129 viven en el fichero vivo con marca de cierre + próxima ronda de archivado cuando acumulen suficientes. ### 4.4 · Notas sobre el registro * Tensiones abiertas viven en `LRU_TENSIONES_ABIERTAS_VIVO.md` · §4.2 del MAPA solo conserva tabla resumen + puntero. * Cuando una tensión pasa a resuelta, se anota marca de cierre en su fila del fichero vivo · ronda de archivado periódica cuando la presión documental lo justifique. * **Cierre positivo por reclasificación**: tensión cerrada por reinterpretación que convierte el problema en diseño legítimo. Se registra con nota explícita. * **6º modo de cierre candidato · cierre como sinónimo / descubrimiento de información correcta** · 2 instancias documentadas (T-S122-2 s126 + bug wheel s133) · si emerge 3ª → formalización en `LRU_METODO §8.1`. --- ## 5 · Handoffs **Régimen s204 (D-s204-D/H)**: el handoff activo es siempre `LRU_HANDOFF_VIVO.md` (regenerado entero en cada cierre · histórico en su git). El registro por-sesión vive en `LRU_BITACORA_SESIONES_VIVO.md` §B (una línea mecánica por cierre · D-s204-B). El corpus de handoffs con sufijo (s55→s203·s204) y `LRU_BITACORA_HANDOFFS_VIVO.md` (congelada · D-s204-C) quedan como archivo de consulta. La tabla mini por-sesión se retira (quedó clavada en s200 · inercia retirada en s204). --- ## 6 · Guía de arranque por tipo de sesión **Externalizado a `LRU_GUIA_ARRANQUE_VIVO.md`** (anillo 1.B.1). | Tipo | Carácter | Documentos del núcleo a leer | Output esperado | |---|---|---|---| | Exploración / Articulación | Articulatoria sin código | MAPA + MISION + FUNDAMENTOS | Destilado anillo 2 candidato | | Cristalización fundacional | Articulación + síntesis canónica | MAPA + 5 canónicos núcleo | Destilado fundacional + tensión F1 abierta | | Implementación de código | Densa de producto | MAPA + tech debt + handoff | Edits src/ + tests + ZIP+PS1 deploy | | Arqueológica / Revisión | Auditoría del corpus | MAPA + corpus a revisar | Hilo argumental o destilado | | Híbrida | Mezcla de los anteriores | MAPA + adaptado al objetivo | Mezcla | **Para detalle**: leer `LRU_GUIA_ARRANQUE_VIVO.md`. --- ## 7 · Cómo se actualiza este documento `LRU_MAPA` se actualiza al cierre de cualquier sesión que: * Lea documentos que no estuvieran catalogados, o cambie estado de catalogación. * Detecte una tensión nueva — se añade a `LRU_TENSIONES_ABIERTAS_VIVO.md` (no aquí). * Resuelva una tensión — se anota marca de cierre en fichero vivo. * Añada algo a "lo que no debes olvidar" — al `LRU_PRINCIPIOS_OPERATIVOS_VIVO.md`. **No se actualiza por:** * Cambios internos a canónicos que no alteren su existencia o puntero. * Detalles de una sesión concreta — eso va en handoff. * Observaciones aisladas no repetidas. * Duplicación de material ya integrado al núcleo. **Disciplina de saneamiento periódico** (s75): cada 10-15 sesiones evaluar si el MAPA acumuló inconsistencias que justifiquen sesión de saneamiento dedicada. Compresión II s157 fue la 2ª gran ronda tras s128. **Política unificada D6 (s129)** formalizada en `LRU_METODO §3`: D6.1 bloque arquitectural unificado (poda+externalización+reescritura iterativa) + D6.2 cierre graduado de bloques de sesión (última cerrada detalle · 4 previas en tabla mini · resto en bitácora externa). --- *LRU Platform · Mapa del proyecto · Documento vivo del núcleo · sincronizado al cierre de s204 · 2026-06-10 · detalle en `LRU_ESTADO.md` + `LRU_HANDOFF_VIVO.md` · histórico de cierres en el git de este fichero (pie convertido a frase única en s204 · D-s204-H · la cola histórica de abajo queda hasta una poda por script)* *[histórico · pendiente de poda · cola s194→s200 y anteriores preservada en el git de este fichero]*