# LRU · Principios operativos

**Documento vivo del anillo 1.B.1 · sin sufijo de sesión · cargado por Project al arrancar · accesible vía MCP filesystem**

> Externalizado desde §3 del MAPA en s128 (palanca O · etapa 1 de externalización navegacional articulada en `lru_externalizacion_navegacional_s128.md`). El MAPA conserva índice de 4 categorías + puntero a este fichero. Cualquier modificación a los principios se hace aquí · no en el MAPA. Los principios fundacionales canónicos viven en `LRU_FUNDAMENTOS.md` · este fichero contiene los recordatorios operativos derivados que el proyecto consulta con frecuencia.

---


Lista acumulativa de ideas que se reinventan si no se recuerdan. Cada entrada con puntero al canónico de autoridad. Esta lista crece con el proyecto; no se purga (salvo que una idea deje de ser cierta, en cuyo caso se actualiza con anotación).

**Nota de higiene s75 (ampliada s91 + s99 + s123)**: los 12 postulados fundacionales (P1-P12) **NO se duplican en esta sección**. Están integrados al núcleo con autoridad plena — P1 → `LRU_FUNDAMENTOS §7`, P2 → §8, P3 → §9, P4 y P5 → `LRU_MISION` ("Qué implica"), P6 → `LRU_FUNDAMENTOS §6` (fundacional de primer orden), P7 → §10, P8 → §11 (plano fundacional) + `LRU_MISION` (plano de uso), P9 → `LRU_MISION`, **P10 → `LRU_FUNDAMENTOS §11quater`** (integrado s91 · "El diseño del Realm como espacio de innovación dentro del respeto"), **P11 → `LRU_FUNDAMENTOS §11quinquies`** (integrado s99 · "Disposición evolutiva del diseño estructural del realm específico"), **P12 → `LRU_FUNDAMENTOS §11sexies`** (integrado s123 · "El hardware físico como sustrato del sistema"). La disciplina ética operativa derivada del Postulado 7 vive en `LRU_METODO §6`. Las reglas operativas derivadas de P10 y P11 viven en `LRU_METODO §6bis` y `§6ter`. P12 NO genera regla operativa propia en METODO (replica patrón §11ter). Los destilados `lru_postulados_fundacionales_s67.md`, `lru_postulados_6_7_8_9_s69.md`, `lru_postulado_10_diseno_como_innovacion_s84.md`, `lru_estructura_sectorial_s98.md` y `lru_postulado_12_hardware_fisico_sustrato_s117.md` se preservan como referencia histórica (§1.2.5) — ya no son fuente autoritativa con regla de disputa.

### 3.1 · Fundacionales

1. **El sistema es agnóstico al dominio por diseño.** Capas 0-2 ignoran si es aviación, domótica, industrial, médico. La especialización vive en el Realm (capa 3). → `LRU_ARQUITECTURA` §2.5 y §8 principio 1.

2. **Descripción ≠ encarnación.** El Realm describe un dominio. Una sesión concreta lo encarna con actores específicos, conexiones concretas y un escenario activo. La misma descripción admite muchas encarnaciones (simulación, hardware real, replay, híbrido) sin que el Realm cambie. → `LRU_FUNDAMENTOS` §14.1.

3. **El proyecto es un sistema operativo de señales.** No es un simulador de aviones. Los casos de uso (formación, simulación, mantenimiento, fabricación, certificación, investigación, juego) son aplicaciones. → `LRU_FUNDAMENTOS` §1.

4. **Cinco primitivas, cuatro materiales y un sustrato.** Señal, Conexión, Actor, Escenario (materiales) + Tiempo (sustrato). Todo lo que el sistema es se reduce a combinaciones de estas. → `LRU_FUNDAMENTOS` §2.

5. **Cuatro operaciones.** DECLARAR (Realm), CONECTAR (actor al sistema), OBSERVAR (DataPlane + Sim1 + Debug1 + Analyzer1), INTERVENIR (SimService + ControlBus). Todo lo que el sistema puede hacer. → `LRU_FUNDAMENTOS` §4.

6. **Vista de Actor como primitiva operativa.** Sim1, Col4, Debug1, Analyzer1 son templates de vista, no productos distintos. El motor de vistas unificado es horizonte implícito. → `LRU_FUNDAMENTOS` §3.

7. **La sesión multipistas es objeto temporal de primera clase.** 8 tipos de pista, 4 modos de replay, navegación temporal completa. El almacén natural es RabbitMQ Streams. → `LRU_FUNDAMENTOS` §5.

8. **Tres tiempos coexistentes.** Vivo (DataPlane), grabado (sesión multipistas), programado (escenario). El alumno no distingue entre ellos. El viewer externo de Debug1, cuando se materialice, será la primera herramienta que los unifica. → `LRU_FUNDAMENTOS` §2.5 y §5.

9. **La dimensión formativa es origen fundacional y caso de primera clase.** Equivalente en valor a los demás casos de uso, no subordinada. La plataforma es herramienta de aprendizaje. → `LRU_MISION` + `LRU_FUNDAMENTOS` §5. Candidato a principio 11 arquitectural — ver T-S55-C4 en §4.

10. **Postulados fundacionales P1-P12 integrados al núcleo.** Los 12 postulados P1-P12 están integrados al núcleo — ver nota de higiene al inicio de §3. P1-P5 integrados en s68 (1ª cristalización fundacional · destilado s67) · P6-P9 integrados en s70 (2ª cristalización · destilado s69) · voz fundacional + pluralidad de inteligencias integradas en s76 (3ª cristalización · destilado s71) · pluralidad de realms integrada en s89 (5ª cristalización · destilado s85 §2+§10 → `LRU_FUNDAMENTOS §11ter`) · **Postulado 10 integrado en s91** (4ª cristalización · destilado s84 → `LRU_FUNDAMENTOS §11quater "El diseño del Realm como espacio de innovación dentro del respeto"`): *"sobre el acto de construir la plataforma · libertad creadora del diseñador sobre el contenido del Realm · la realidad pone reglas; el proyecto las respeta; el diseño añade"*. Regla operativa derivada en `LRU_METODO §6bis`. **Postulado 11 integrado en s99** (6ª cristalización · destilado s98 → `LRU_FUNDAMENTOS §11quinquies "Disposición evolutiva del diseño estructural del realm específico"`): *"sobre el acto de construir la plataforma · disciplina evolutiva del diseñador sobre la estructura del realm específico · la realidad pone reglas; el proyecto las respeta; el diseño las estructura como puede leerse hoy y reestructurarse cuando llegue"*. Regla operativa derivada en `LRU_METODO §6ter`. **Postulado 12 integrado en s123** (7ª cristalización · destilado s117 → `LRU_FUNDAMENTOS §11sexies "El hardware físico como sustrato del sistema"`): *"el sistema LRU se construye sobre encarnaciones físicas concretas que son sustrato suyo, no aplicación suya sobre hardware externo · tres encarnaciones (microcontroladores con firmware · teléfonos con sensores · banco de pruebas con motor real) coexistiendo bajo arquitectura común que las hace operacionalmente intercambiables"*. P12 NO genera regla operativa propia en METODO (a diferencia de P10/§6bis y P11/§6ter) porque articula propiedad estructural del sustrato no disciplina sobre cómo se construye el Realm · replica patrón §11ter. P10 y P11 forman par fundacional del diseñador del Realm (libertad creadora sobre contenido + disciplina evolutiva sobre estructura · creatividad estructurada como disciplina del diseñador). P12 es postulado transversal que refina P1+P5+P6+P9+§2.3+§11ter+§11bis sin invalidar ninguno. Para trabajo arquitectural sobre Realm v3 (T-S67-A1), los 12 postulados integrados son entrada obligatoria como marco estructural; P10 debe consultarse cuando el trabajo toque diseño del Realm con configuraciones que van más allá de reproducir la realidad regulatoria (marcador estructural `notEqualToReal`); P11 debe consultarse cuando el trabajo toque la forma estructural del schema del realm específico (singleton vs plural, plano vs jerárquico, anti-anticipación de abstracciones · cuatro preguntas de `LRU_METODO §6ter.4`); P12 debe consultarse cuando el trabajo toque hwObj productor de señales (tensiones secundarias T-S117-N1..N6) o cualquier diseño del lado físico del sustrato. Articulación canónica complementaria de s117: *"el sistema LRU es un laboratorio real/virtual de señales"*. **Ninguna cristalización fundacional pendiente al cierre de s123** · cluster mental §11/§11bis/§11ter/§11quater/§11quinquies/§11sexies completo con 6 capas · deuda latente sobre nomenclatura del cluster anotada (séptima cristalización del cluster activaría refactor de nomenclatura latina).

### 3.2 · Arquitecturales

11. **El DataPlane es la única fuente de verdad en tiempo real.** Todo valor de sensor vivo fluye por él. Los hot paths no usan React Context. React Context queda para estado de UI. → `LRU_ARQUITECTURA` §2.2 y §8 principio 4.

12. **Toda escritura al DataPlane pasa por ControlBus.** Toda gestión de modos pasa por RouterService. No hay escritura libre. → `LRU_ARQUITECTURA` §3.2 y §8 principio 6.

13. **Puerto ≠ canal.** Puerto es nombre físico del hardware (`adc1`). Canal es nombre lógico del instrumento (`aguja_altitud`). `channelMap = Record<canal, puerto>` es el cableado. → `LRU_FUNDAMENTOS` §14.2 y `LRU_ARQUITECTURA` §3.2.

14. **Escenarios (cableado) ≠ scenarios (física).** `EnlacesPanel.Escenarios` = snapshots de cableado swObj↔hwObj. `sim-catalog.scenarios` = definiciones de comportamiento temporal. Son ortogonales. → `LRU_FUNDAMENTOS` §14.3.

15. **Debug1 es subsistema transversal.** Observa las 4 capas. No es cuarto servicio de capa 2. El viewer externo unificado es el gap mayor del proyecto. → `LRU_ARQUITECTURA` §3.4 y §9.1.

16. **El Realm v2 está desplegado pero no integrado.** Schema en `src/realm/` desde s56 (2108 líneas TS). No consumido todavía por runtime — SimService sigue usando `sim-catalog.ts`. C2 es la integración (suspendida por T-S67-A2). → `LRU_ARQUITECTURA` §7.

17. **Las 4 decisiones del Realm v2 (Q1/Q2-ter/Q3/Q4).** No reabrir sin revisar primero el razonamiento original. → `LRU_ARQUITECTURA` §7.2.

18. **El Realm NO hace cálculos; los declara.** Las derivaciones son datos (union discriminada con 6 primitivos + `named`). El motor (SimService) ejecuta. → `LRU_ARQUITECTURA` §7.6.

19. **Un sensor derivado exige entity correspondiente.** Son la misma identidad con dos aspectos. La validación del schema lo fuerza. → `LRU_ARQUITECTURA` §7.

20. **`applyProfile` no muta.** Siempre devuelve nuevo `RealmManifest`. → `LRU_ARQUITECTURA` §7.

21. **Schema Realm v2 es 100% JSON-serializable.** No introducir `Date`, `Map`, `Function` en nuevos campos. → `LRU_ARQUITECTURA` §7.6.

22. **Viewer Debug1 externo está desbloqueado arquitecturalmente.** Las 4 restricciones del schema están cumplidas. No hace falta refactor. → `LRU_ARQUITECTURA` §9.1.

23. **Agnosia del SimService (hallazgo 1 síntesis s55).** El motor de simulación ya es agnóstico al dominio en la práctica. No está articulado como principio explícito todavía. → `lru_docs_synthesis_s55_bloques_a_b_c.md` bloque A.

24. **RabbitMQ ya es gateway multi-protocolo en producción.** Traduce entre MQTT / AMQP / STOMP / Streams. No está articulado formalmente como tal. → T-S55-C3 en §4.

25. **Decisiones s63-s65 articuladas y MATERIALIZADAS (s77+s78) + catálogo migrado a vocabulario SensorFaultDef (s79 Bloque A).** `apply-profile` materializado en s77 · `SensorFaultDef`/`ActuatorFaultDef` con 22 kinds + `CruisePatternDef` con 3 types discriminados materializados en s78 · `sim-catalog.ts` migrado en s79 al vocabulario `SensorFaultDef` (16 kinds) sin acoplamiento físico a `src/realm` (declaración local del mismo shape). Bloque 1 del triaje s75 CERRADO · Bloque A del triaje s75 (refactor s79) CERRADO · Bloque B pendiente para s80 (motor `SimService.applyFault`). T-AU72-2 cerrada completa (s78). → §4.3 T-AU72-2 + "Última sesión cerrada" s79.

26. **Cobertura real de `applyFault` es 3/33 (sigue abierto al cierre de s79).** El switch usa `faultId` literal y solo 3 ids del catálogo matchean: `drift`, `stuck` (antes `freeze`), `dead`. Los 30 faults específicos caen en `default`. Se cierra en Bloque B de s80 con dispatcher por kind. → T-AU73-6 en §4.

27. **`applyScenarioOverride` es plantilla probada del patrón `kind`-discriminated.** 5/5 profiles implementados en SimService. El refactor de `applyFault` debe replicar este patrón — **y tiene fuente autoritativa en `lru_applyfault_mapping_s79.md`** producido en s79. → T-AU73-8 en §4 (hallazgo positivo) + destilado s79.

28. **`computeDerived` de SimService es `namedFormulas` registry hardcodeado operativo.** Consume 4 funciones aerodinámicas de `units.ts` (no de quantities.ts). Plantilla para registry de v3. Confirma que `units.ts` contiene el modelo aeronáutico vivo. → T-AU73-9 en §4 (hallazgo positivo).

29. **Seis faults del catálogo son actuator semánticamente pero clasificados como sensor-proxies (T-S79-M1).** Por ausencia de `ActuatorDef` en Realm v2: `eng_ff_stuck`, `prs_valve`, `elc_gen_fail`, `hyd_pump_b`, `fctl_jam`, `fctl_runaway`. Comentario `[ACTUATOR-PROXY]` en `sim-catalog.ts`. Reclasificación a `ActuatorFaultDef` con kind correcto en Bloque 4 de T-S67-A1. Cleanup oportunístico al materializar el cambio arquitectural. → T-S79-M1 en §4.2.

30. **Tres patrones metodológicos consolidados s77+s78+s79** (candidatos firmes a formalizarse en `LRU_METODO §3` tras s80): (a) **ciclo destilado → código** con 3 instancias consecutivas sobre artefactos distintos (schema-extensión s77 · schema-reemplazo s78 · catálogo-migración s79) · flujo de 6 pasos sin fricción. (b) **"Propuesta antes de ejecutar" con tabla revisable** como paso intermedio entre destilado y código · aprobación explícita a escala granular elimina invención individual. (c) **Destilado paralelo de diseño futuro como alternativa a código sin callsite** · honra disciplina "un proyecto a la vez" sin sacrificar densidad de diseño. → "Última sesión cerrada" s79 + ampliación s79 de `CLAUDE_ARRANQUE §7`.

### 3.3 · Metodológicas

31. **Convención de ficheros.** Línea 1 path comentado, línea 2 timestamp GMT ISO 8601 con H:M:S. Nunca omitir minutos o segundos. → `LRU_METODO` §4.

32. **PowerShell de deploy: ASCII only, sin paréntesis en strings doble-quoted, `Join-Path` con 2 args siempre, sin backtick-n, 3 fases (backup → copia → SHA256).** → `LRU_METODO` §5.

33. **Docker Desktop siempre, nunca Docker Engine en WSL2.** Regla innegociable. → `LRU_METODO` §5.

34. **Terminología canónica.** "Telemetría" (no "mqtt" en UI). "Instrumentos de simulación" (nunca "animations"). "Hardware" o "dispositivo hardware" (no términos propietarios). → `LRU_METODO` §4.

35. **Sistema documental en anillos.** Anillo 0 (Proyecto de Claude, memoria de arranque) · Anillo 1 (núcleo vivo, 5 canónicos sin sufijo) · Anillo 2 (destilados con sufijo de sesión) · Anillo 3 (archivo histórico en `doc/archivo/`). → `LRU_METODO §1`.

36. **Regla del núcleo refinada s57.** El núcleo se actualiza con aportación sustancial (código, articulación conceptual, o disciplina operativa nueva). No por inercia. → `LRU_METODO §1`.

37. **Cuestionar el handoff anterior en los primeros minutos.** Releer con ojo crítico suele producir ajustes útiles. Patrón 4 humano-IA. → `LRU_METODO §6` (renumerada tras s70).

38. **Patrón 2 — sobrecarga en el último 30% de sesión.** Cerrar antes de que la calidad baje. El handoff preserva lo pendiente sin pérdida. → `LRU_METODO §6`.

39. **Patrón 3 — la frase precisa es oro.** Cuando Manuel articula una idea con frase compacta, escribirla en documento canónico antes de que se pierda en el chat. → `LRU_METODO §6`.

40. **Patrón 6 — pushback constructivo.** Claude debe decir cuando tiene observación honesta que contradice algo asumido. Específico, constructivo y humilde. → `LRU_METODO §6`.

41. **Patrón 7 — cristalización periódica.** El proyecto alterna acumulación (sesiones normales) con cristalización (s53, s55, s57, s67, s69, s71, s74). La señal es Manuel pidiendo "entender antes de codificar" o "no tenemos prisa". → `LRU_METODO §6`.

42. **Anillo 0 — Proyecto de Claude (articulado s60).** Memoria de arranque instantáneo con `CLAUDE_ARRANQUE` + 5 canónicos + tech debt vigente + handoff activo. No se sincroniza con el filesystem — sincronización manual al cierre de cada sesión. → `LRU_METODO §1 y §3`.

43. **`CLAUDE_ARRANQUE.md` (s60)** — briefing operativo complementario al núcleo. Vive al raíz de `/doc/` sin sufijo. NO es canónico número 6. Se actualiza cuando el protocolo de arranque cambia. → `CLAUDE_ARRANQUE.md` y `LRU_METODO §1`.

44. **Actualizar el index al cierre si se tocó documentación (regla s60).** Si la sesión produjo o modificó documentos del raíz de `/doc/`, `index.html` se actualiza antes de cerrar. → `LRU_METODO §3` cierre.

45. **Sincronizar el Proyecto al cierre (regla s60).** Tech debt vigente y handoff activo cambian cada sesión — deben reemplazarse en el Proyecto de Claude al cierre o la próxima sesión arrancará con contexto stale. → `LRU_METODO §3` cierre.

46. **Entrega al cierre — patrón ZIP + PS1 autocontenido (articulado s62).** Exactamente dos deliverables al cierre: `lru-sN-close.zip` (canonicales + `MANIFEST.txt` con SHA256 en subcarpeta `files/`) y `deploy-sN.ps1` autocontenido. Infraestructura de cierre es efímera y nunca vive en el repo. → `LRU_METODO §3` cierre.

47. **Fallback de regeneración entera vs parche localizado (articulado s65-s66 · aplicado 3 veces).** Si por límites de contexto una sesión no puede regenerar canónicos enteros al cierre, es aceptable entregar instrucciones de aplicación localizadas — pero debe añadirse nota en `CLAUDE_ARRANQUE §0` como tarea pendiente, y la sesión siguiente ejecuta la recomposición como primer bloque. **Aplicado s65→s66, s73→s74, s79→s80** — patrón robusto en sesiones densas de código + destilados + decisiones. Fallback aceptable, no norma. → `LRU_METODO §3` cierre.

48. **Disciplina ética sobre casos reales (articulada s70).** Frontera fundamental: el caso documentado con nombre propio se analiza, la clase de situación técnica se juega. Reglas operativas: citar fuentes oficiales, no atribuir responsabilidades fuera de lo establecido, no usar nombres personales, tratar con la gravedad que corresponde. → `LRU_METODO §6` + `LRU_FUNDAMENTOS §10.6`.

49. **Regla del destilado → núcleo (articulada s70).** *"El destilado propone, el núcleo dispone, Manuel arbitra qué cruza la frontera."* El material articulado en cristalizaciones fundacionales vive primero en destilado con regla de disputa activa; la integración al núcleo es decisión explícita de Manuel, no proceso automático. → `LRU_METODO §6` + `CLAUDE_ARRANQUE §7` ampliación s70.

### 3.4 · Voz y disciplina fundacional (integradas en s76 · material residual preservado)

Los items 50, 51 y 52 cristalizados en s74 y articulados en `lru_voz_fundacional_s74.md` **quedaron integrados al núcleo en s76 (bloques 1 y 2 de E.2)**. La imagen compuesta del proyecto vive con autoridad operativa en `LRU_MISION "Por qué este proyecto, ahora"` y la disciplina "un proyecto a la vez" vive en `LRU_METODO §5bis`. El destilado se reclasifica de "pendiente de integración" a "referencia histórica post-integración" — sigue preservando 23 citas literales de Manuel. El item 52 (Atlas del Proyecto) permanece como pieza documental permanente del anillo 2 por diseño (no cruza al anillo 1 — ver decisión s74).

50. **La imagen compuesta del proyecto — seis elementos estructurales · INTEGRADA s76.** El proyecto LRU está construyendo, en el momento histórico en que la tecnología y los medios lo permiten por primera vez, la primera infraestructura técnica donde las cuatro clases de inteligencia — cognitiva humana, enlatada normativa, física inamovible y emergente por uso — pueden acoplarse bidireccionalmente en tiempo real sobre un sustrato computable común, con continuidad total entre el plano virtual y el plano físico, y con disposición arquitectural para que ese sustrato mismo sea reconfigurable desde el software. → autoridad operativa: `LRU_MISION "Por qué este proyecto, ahora"` · referencia histórica: `lru_voz_fundacional_s74.md §§1-3`.

51. **Disciplina "un proyecto a la vez" como principio fundacional del método · INTEGRADA s76.** Articulada por Manuel en s74: *"Los proyectos van de uno en uno. Si estamos pensando en el siguiente, abandonamos este. Hay que crear primero los cimientos, y cuando tengamos este abordaremos el siguiente."* **El núcleo protege la unicidad del proyecto presente frente a la dispersión del futuro.** → autoridad operativa: `LRU_METODO §5bis` · referencia histórica: `lru_voz_fundacional_s74.md §4`.

52. **El Atlas del Proyecto — documento visual maestro del anillo 2, permanente.** Pieza documental nueva fundada en s74 que clasifica, organiza y preserva los diagramas de las múltiples arquitecturas del proyecto. El Atlas **no cruza al anillo 1 por diseño** — complementa el índice textual del MAPA con índice visual del proyecto. → `lru_atlas_proyecto_meta_s74.md` + T-S74-A4 activa.

53. **Pluralidad de inteligencias coexistiendo + distinción entidades funcionales/declarativas + nivel 0 físico como sustrato epistémico · INTEGRADAS s76.** Material del destilado principal s71 integrado al núcleo con autoridad operativa. → autoridad operativa: `LRU_FUNDAMENTOS §6.7 + §11bis` · referencia histórica: `lru_estructuras_subyacentes_s71.md`.

54. **Máquinas de estados como sintaxis del enlatado + dos clases de inteligencia enlatada · INTEGRADAS s76.** Material del addendum s69 integrado con decisión pieza-por-pieza de T-S74-A8. → autoridad operativa: `LRU_FUNDAMENTOS §8.5 + §11bis.5` · referencia histórica + piezas preservadas: `lru_postulados_6_7_8_9_addendum_s69.md`.

---

---

*LRU Platform · Principios operativos · documento vivo del anillo 1.B.1 · producido en s128 al ejecutar palanca O etapa 1 de externalización navegacional · contenido íntegro de §3 del MAPA al cierre de s127 (sin compresión · sin reformulación · preservación de la voz documental original Patrón 3) · 4 subsecciones (3.1 fundacionales · 3.2 arquitecturales · 3.3 metodológicas · 3.4 voz y disciplina fundacional integradas en s76 con material residual preservado) · iterativo · se actualiza al integrar cristalizaciones fundacionales nuevas o disciplinas operativas nuevas · referenciado desde MAPA con puntero + índice mínimo de las 4 categorías en §3 · sub-categoría refinada en s129 al formalizar bipartición §1.B.1/§1.B.2 (Propuesta A · D-s129-S)*