# LRU Docs — Índice Documentos del proyecto LRU Platform · organizados por tipo · enlaces relativos planos. **Última sesión cerrada: s250** · **Handoff activo: s250→s251** Ubicación: `public/docs-app/v1/doc/` · **Documento vivo · fuente de verdad MD · HTML derivado** (regenerar con `lru_md_to_html.py`). > Este índice es para **orientarse**, no para recordarlo todo. El detalle por sesión vive en las bitácoras vivas (`LRU_BITACORA_SESIONES_VIVO.md` + `LRU_BITACORA_HANDOFFS_VIVO.md`) y en el git de cada fichero. Reescrito y podado al cierre de s211 (antes arrastraba marcadores de s186 y la estructura de la era s129). --- ## Cómo está organizado **Sistema documental en anillos** (s57-s60 · ampliado s87/s129/s204): - **Anillo 0** — briefing de arranque: `CLAUDE_ARRANQUE.md`. - **Anillo 1.A** — núcleo vivo: 5 canónicos sin sufijo, leer al arrancar. - **Anillo 1.B** — derivados operativos vivos (guía, principios, catálogos, bitácoras). - **Vivos por-sesión (régimen s204)** — estado, handoff, tech-debt y tensiones, sin sufijo, regenerados cada cierre, **solo en disco** (Claude los lee vía MCP al arrancar). - **Anillo 2** — destilados y alfileres con sufijo de sesión (catalogados en `LRU_CATALOGO_ANILLO2_VIVO.md`). - **Anillo 3** — archivo histórico en `archivo/` + git. **Régimen s204 (D-s204)**: lo que cambia cada sesión (estado/handoff/tech-debt/tensiones) vive sin sufijo y solo en disco; las cadenas sufijadas (`LRU_TECH_DEBT_s{N}.md`, `lru_handoff_s{N}_s{N+1}.md`) quedaron **congeladas en s203** como archivo de consulta. El histórico por sesión vive en las bitácoras vivas + git. Disciplina completa en [LRU_METODO.md](LRU_METODO.md). --- ## Anillo 0 · briefing de arranque - [CLAUDE_ARRANQUE.md](CLAUDE_ARRANQUE.md) — **cómo arrancar una sesión**. Tres modos equivalentes (offline/Project · online/boxdin · manual), protocolo de lectura, cascada de fallback y reglas de oro. Documento estructural, no log. --- ## Anillo 1.A · núcleo vivo (5 canónicos) Leer al arrancar. Cada uno responde una pregunta del proyecto. - [LRU_MISION.md](LRU_MISION.md) — **¿Para qué existe?** Tecnología como fuerza causal, el Realm como "resto del mundo", la formación como origen. - [LRU_FUNDAMENTOS.md](LRU_FUNDAMENTOS.md) — **¿De qué está hecho?** 5 primitivas, bucle perceptor-inteligencia-efector, los 12 postulados fundacionales (P1-P12). - [LRU_ARQUITECTURA.md](LRU_ARQUITECTURA.md) — **¿Cómo está construido ahora?** Cuatro capas, servicios paralelos, la Capa 0 (hardware físico) como sustrato. - [LRU_MAPA.md](LRU_MAPA.md) — **¿Dónde está cada cosa?** Índice/registro transversal; el estado reciente lo delega en `LRU_ESTADO.md` (régimen s204). - [LRU_METODO.md](LRU_METODO.md) — **¿Cómo se trabaja?** Sistema documental, ciclo destilado→código, patrones humano-IA, tensiones como disciplina. **Regla del núcleo**: un Claude nuevo con los 5 canónicos + handoff + tech-debt debe poder trabajar útilmente. --- ## Vivos por-sesión (régimen s204 · solo en disco · leídos vía MCP al arrancar) - [LRU_ESTADO.md](LRU_ESTADO.md) — **snapshot del estado · se lee primero**. Declara la sesión actual, qué se hizo, build y tensiones movidas. Regenerado entero cada cierre. Gana a cualquier copia del Project y a la memoria automática. - [LRU_HANDOFF_VIVO.md](LRU_HANDOFF_VIVO.md) — **handoff activo** (s249→s250): qué se hizo y cómo arrancar la siguiente. Regenerado entero cada cierre. - [LRU_TECH_DEBT_VIVO.md](LRU_TECH_DEBT_VIVO.md) — **deuda técnica viva**: items abiertos; los cerrados salen (histórico en git). Autoridad actual de tech-debt. - [LRU_TENSIONES_ABIERTAS_VIVO.md](LRU_TENSIONES_ABIERTAS_VIVO.md) — **tensiones abiertas** (registro deduplicado · 42 vivas + apéndice por triar). Cualquier tensión nueva se anota aquí, no en el MAPA. --- ## Anillo 1.B · derivados operativos vivos Estables, cargados al Project: - [LRU_GUIA_ARRANQUE_VIVO.md](LRU_GUIA_ARRANQUE_VIVO.md) — guía de arranque por tipo de sesión (5 categorías). - [LRU_PRINCIPIOS_OPERATIVOS_VIVO.md](LRU_PRINCIPIOS_OPERATIVOS_VIVO.md) — principios del proyecto (fundacionales / arquitecturales / metodológicos / voz). Derivado de FUNDAMENTOS + METODO. Bajo demanda (vía MCP): - [LRU_CATALOGO_ANILLO2_VIVO.md](LRU_CATALOGO_ANILLO2_VIVO.md) — **catálogo de destilados Anillo 2**. Aquí se cataloga cualquier destilado nuevo, no en este índice. - [LRU_BITACORA_SESIONES_VIVO.md](LRU_BITACORA_SESIONES_VIVO.md) — **bitácora de sesiones**: histórico condensado (s89→s198) + registro mecánico una línea/sesión desde s204. Es el detalle por sesión. - [LRU_BITACORA_HANDOFFS_VIVO.md](LRU_BITACORA_HANDOFFS_VIVO.md) — bitácora de handoffs (congelada en s204; histórico de consulta). - [LRU_FIRMWARE_PUBLICACION_VIVO.md](LRU_FIRMWARE_PUBLICACION_VIVO.md) — **ciclo de publicación de firmware de la flota** (nace s227): bump → build → publicar (`scripts/gen-manifest-s227.ps1` · cerrojos de coherencia) → commit → deploy → flashear. Convención `-.bin` · versión de flota `0..`. --- ## Anillo 2 · destilados y alfileres (sufijados) El catálogo completo y vigente vive en [LRU_CATALOGO_ANILLO2_VIVO.md](LRU_CATALOGO_ANILLO2_VIVO.md). Los `.html` canónicos se regeneran del `.md` con `lru_md_to_html.py`. **Hilo activo (eje OTA v2 / resiliencia / mando unificado / rescate · s226-s249)**: - [lru_diseno_rescate_clasico_s249.md](lru_diseno_rescate_clasico_s249.md) — **diseño del plano de rescate CLÁSICO (D-s249-A→F) · espejo del diseño s245 sobre rpc1cl 0.235.1** · matriz de claves (derivada por dispositivo + maestra de familia `adminble`/`admin_s3` en ventana de botón tipo WPS) · secreto por familia con selección por prefijo · AP lazy total · botón GPIO27 compatibilizado (larga=AP · corta=swid2) · OTA local sobre ota1 + `rescue_pending` · vigilante-péndulo con NET_WDT congelado fuera de NORMAL · utilidad PWA «clave de rescate» ambas familias · D-s249-F: la S3 entra en la ventana maestra (tile + pin físico) · rebanadas Bc0 (HECHA: rpc1cl versionado + git-cl) → Bc1 → Bc2 → Bc3 (su banco absorbe TD-s235-1). - [lru_movil_patrones_hw1_s247.md](lru_movil_patrones_hw1_s247.md) — **patrones móvil/tablet de la PWA (pasada Hw1 · s247)** · las dos palancas (`@media pointer:coarse` + `IS_TOUCH`), mínimos táctiles, maestro-detalle a pantalla completa con `onBack`, paneles colapsables a barra-resumen, tres curas para tablas, mapeo táctil sobre área dibujada, scrollIntoView de la activa · con checklist de pasada para aplicar al resto de páginas de la app · implementaciones de referencia en `Hw1AdminPanel/`. - [lru_rescate_referencia_operativa_s246.md](lru_rescate_referencia_operativa_s246.md) — **rescate y actualización de la S3: referencia operativa (0.246.3)** · el CÓMO del plano de rescate tal como está construido: mapa de decisión por síntoma, portal AP + OTA local + `rescue_pending` + vigilante-péndulo, operación paso a paso desde el móvil, perillas de referencia y **procedimiento de banco P1-P6** (pendiente de ejecutar) · el porqué en el diseño s245. - [lru_diseno_portal_rescate_s245.md](lru_diseno_portal_rescate_s245.md) — **diseño del plano de rescate (frente B) · D-s245-A/B/C · rebanada B1 MATERIALIZADA y validada en banco (0.245.x)** · el portal AP crece de "OTA sin internet" a plano de rescate completo: softAP lazy con clave WPA2 derivada por dispositivo + página de operación (config WiFi/captura/táctil) + portal cautivo + QRs + lru_bar como cadena de comunicaciones · B2 (OTA local) y B3 (vigilante-péndulo) MATERIALIZADOS en s246 (0.246.x · B2 vía (a) validado en banco; resto del banco en la referencia operativa s246 §6). - [lru_dormidos_memoria_s242.md](lru_dormidos_memoria_s242.md) — **los dormidos: presupuesto de DRAM interna, servicios bajo demanda y los 3 anillos de actualización (D-s242)** · patrón servicio-dormido (audio + BLE) · primera OTA HTTPS de la S3 · mapa cuantificado del pool interno. - [lru_estudio_memoria_pines_s3_s241.md](lru_estudio_memoria_pines_s3_s241.md) — estudio de memoria y pines de la S3 (mapa de consumidores de DRAM interna · palancas) + [mapa SVG](lru_mapa_memoria_s3_s241.svg). - [lru_cliente_rpc_pwa_completado_s240.md](lru_cliente_rpc_pwa_completado_s240.md) — cliente RPC de la PWA completado (Candidato D materializado sobre el diseño s239) · [diseño s239](lru_diseno_rpcclient_pwa_s239.md). - [lru_eje_plano_mando_unificado_s237.md](lru_eje_plano_mando_unificado_s237.md) — **destilado del eje s237 · plano de mando unificado: dispatcher común, RPC por BLE y observabilidad** · VIGENTE (código validado en placa) · el firmware S3 pasó de canales de mando (MQTT único) a un dispatcher `lru_cmd_dispatch` del que MQTT, BLE/GATT, UI local y loopback son transportes finos · vocabulario espejo LRU (los built-ins mgos dan 404) · transporte BLE con paridad mOS-RPC-GATT byte a byte · saga DRAM interna (NimBLE a PSRAM · cámara↔BLE en s238) · validado en banco s238 (8 métodos GATT ok · DRAM reposo ~19-20K) con dos lecciones para el cliente RPC PWA: serializar GATT + hablar espejo. Cierra TD-s237-1; abre TD-s238-1. - [lru_analisis_ble_pwa_s236.md](lru_analisis_ble_pwa_s236.md) — **análisis de conectividad BLE PWA↔placa como canal de resiliencia + adopción del patrón RPC como pieza transversal (D-s236-C/D)** · hallazgo: el clásico YA habla RPC por BLE (rpc-gatts desplegado en toda la flota) · modelo «BLE es canal de mando y rescate, no de transferencia masiva» · capas de adopción 0-4 · paridad S3 como frente firme · 8 aprovechamientos del sobre RPC (§7ter) · sec_level 0 = 7º motivo hilo seguridad · acompañado por la PoC de banco [lru_poc_ble_rpc_s236.html](lru_poc_ble_rpc_s236.html) (cliente Web Bluetooth del protocolo mOS-RPC-GATT · pendiente de banco TD-s236-1). - [lru_plan_migracion_broker_s231.md](lru_plan_migracion_broker_s231.md) — **plan de migración del broker MQTT a la máquina `.102`** · materializa la rebanada R2 del alfiler s230 · preparación COMPLETA Y ENSAYADA en s231 (usuarios + espejo 21883 + gemelo wss vía Caddy TLS · ensayos T1-T6 verdes) · **§3bis: checklist ejecutable del cutover** (3 cambios de IP en NAT · empujón a la flota · la `.200` queda de respaldo · rollback en minutos). Frente natural de s232. - [lru_alfiler_resiliencia_comunicaciones_s230.md](lru_alfiler_resiliencia_comunicaciones_s230.md) — **resiliencia y tolerancia a fallos de comunicaciones** · documento VIVO por diseño · **REVISADO en s231: R0 ejecutada, hallazgos H1-H6 en §1bis** (no-failback ambas clases · GATT clásico apagado persistente · PWA sin failover · foto real de brokers · retained+wildcard teórico). Postulado: «ningún fallo único de comunicaciones debe suponer una situación crítica». Fallos F1-F5 × escalera L0-L4 · rebanadas R0 ✔ / R2 casi ✔ / R1-R6 con triggers · umbrella T-S230-RESILIENCIA-COMS. **Hilo del modelo unificado de señales (umbrella T-S183)** — los más consultados: - [lru_alfiler_egress_mesa_s210.md](lru_alfiler_egress_mesa_s210.md) — **eje de actuación / mesa**: las señales en las dos direcciones por la mesa y los legos. Estadificación E0-E7 con punto de no retorno en E4; 5 invariantes, 5 D-abiertas. Contrato del frente vivo en s210-s212. (El término "egress" del alfiler se renombró a "actuación / actuador" en s212.) - [lru_destilado_modelo_unificado_senales_s183.md](lru_destilado_modelo_unificado_senales_s183.md) — destilado raíz del modelo unificado (espacio × tiempo × dirección · mesa de parcheo · Realm como partitura). - [lru_mapa_unificacion_modos_universal_s182.md](lru_mapa_unificacion_modos_universal_s182.md) — mapa de la retirada del modo per-hwObj (eje per-señal). - [lru_postulado_12_hardware_fisico_sustrato_s117.md](lru_postulado_12_hardware_fisico_sustrato_s117.md) — P12 "el hardware físico es sustrato" · integrado al núcleo en s123. **Fundacionales (referencia histórica · ya integrados al núcleo)**: postulados s67/s69 (P1-P9), P10 (s84), P11 (s98), P12 (s117); voz fundacional s74; estructura sectorial s98. Detalle y el resto del corpus, en el catálogo. --- ## Cadenas sufijadas congeladas (archivo · régimen s204) Dejaron de crecer en s203; su autoridad viva son los documentos sin sufijo de arriba. Se conservan en disco + git como archivo de consulta. El resumen por sesión vive en las bitácoras vivas. - **Tech-debt sufijado**: `LRU_TECH_DEBT_s56.md … s203.md` (+ `s208` suelto). Autoridad actual → `LRU_TECH_DEBT_VIVO.md`. - **Handoffs sufijados**: `lru_handoff_s55_s56.md … s203_s204.md`. Autoridad actual → `LRU_HANDOFF_VIVO.md`. --- ## Material arquitectural y de módulos (HTML de referencia) Documentos `.html` históricos, útiles como referencia de subsistemas (contenido no siempre absorbido al núcleo): - **Buses / comms / señales**: [lru_bus_architecture.html](lru_bus_architecture.html) · [lru_comms_deep_analysis_s32.html](lru_comms_deep_analysis_s32.html) · [lru_fase4_signal_model.html](lru_fase4_signal_model.html) - **Mesa de parcheo**: [lru_enlaces_panel.html](lru_enlaces_panel.html) - **Analyzer1**: [lru_analyzer1_architecture_v4.0_s18.html](lru_analyzer1_architecture_v4.0_s18.html) · [lru_analyzer_protocol_platform.html](lru_analyzer_protocol_platform.html) · [lru_analyzer1_referencia_operativa_s152.md](lru_analyzer1_referencia_operativa_s152.md) - **Bridge / IB_04 / aeronave**: [lru_sim1_bridge_architecture.html](lru_sim1_bridge_architecture.html) · [lru_ib04_binding_model_s32.html](lru_ib04_binding_model_s32.html) · [lru_ib04_hardware_model_s32.html](lru_ib04_hardware_model_s32.html) · [lru_aircraft_model_design_s33.html](lru_aircraft_model_design_s33.html) - **Flujo de edición**: [lru_docs_workflow.html](lru_docs_workflow.html) — MD es fuente, HTML derivado (regla s87). Inventarios y schemas tempranos (quantities/units/pfd/sim-catalog s62-s63 · Realm v2 s56-s60) y el resto del corpus histórico viven en disco y en el catálogo. --- *LRU Docs Index · Fuente de verdad MD · HTML derivado · Reescrito y podado al cierre de s211 (2026-06-13) · actualizado al cierre de s249 (2026-08-06 · diseño del plano de rescate clásico s249 añadido al hilo activo · cabecera puesta al día desde s247 · index.html pendiente de regenerar host-side con `lru_md_to_html.py`). El detalle por sesión vive en `LRU_BITACORA_SESIONES_VIVO.md` + `LRU_BITACORA_HANDOFFS_VIVO.md` + git; este índice solo orienta.*