# LRU_METODO

> Fichero: `LRU_METODO.md` · documento vivo sin sufijo de sesión
> Ubicación canónica: `public/docs-app/v1/doc/LRU_METODO.md`
> Origen: sesión s57 · 2026-04-18 · Manuel & Claude Opus 4.7
> Actualizado s60 (2 reglas de cierre: index + Proyecto) · sincronizado s61 (checklist de sincronización al sobreescribir) · **sincronizado s62** (subsección "Entrega al cierre — patrón ZIP + PS1 autocontenido" materializada en §3 tras ser articulada conversacionalmente en s61 sin llegar al fichero — cerró T-S62-M2) · **sincronizado s64** (subsección "Comandos de lanzamiento al entregar ZIP + PS1" añadida en §3 cierre — dos bloques PS parametrizados con `$env:USERPROFILE\Downloads`, carpeta de descompresión con nombre del ZIP, ficheros extraídos no se borran como copia alternativa de seguimiento, anti-duplicado estricto) · **sincronizado s66** (nota en §12 sobre la recomposición del s65 ejecutada al arrancar s66 + regla operativa derivada) · **sincronizado s76** (nueva §5bis "Disciplina sobre el alcance del proyecto — un proyecto a la vez") · **sincronizado s81** (nueva subsección en §3 "Paquete de cierre unificado con MANIFEST") · **sincronizado s82** (nueva subsección en §3 "Ciclo destilado → código") · **sincronizado s83** (§3 · Ciclo destilado → código actualizada · sub-patrón nuevo "validación empírica del schema con realm regenerado") · **sincronizado s83-v2** (§3 · subsección "Paquete de cierre unificado con MANIFEST" ampliada con soporte DELETE declarativo · formato MANIFEST de 6 campos con `action` como primer campo) · **sincronizado s90** (§5 ampliado en 4 subsecciones · §5.1 convenciones consolidadas pre-s90 · **§5.2 nueva con 4 disciplinas T-S90-A2/A3/A4/A5 cerradas por materialización**: verificación local únicamente en PS1 de deploy · entrega monolítica del cierre · estructura plana-por-categoría dentro del ZIP · empaquetado sin envolvente redundante · **§5.3 nueva con estructura canónica del MANIFEST a partir de s90** · cabecera de 6 líneas con metadata operativa · tabla de operaciones con columna `SOURCE_IN_ZIP` separada de `DESTINATION_REL_PATH` · **§5.4 nueva con disciplina T-S90-A6** · sección obligatoria del handoff con lista exacta de ficheros a subir al Proyecto de Claude diferenciando 4 estados (subir/heredar/retirar/no subir) · las 5 disciplinas emergidas del análisis crítico del propio cierre s90 al detectar problemas reales recurrentes en cierres anteriores · formalizadas y aplicables a TODOS los paquetes y PS1 del proyecto a partir de s90)
> Propósito: establecer cómo se trabaja en el proyecto LRU Platform
> Alcance: disciplina del sistema documental, proceso humano-IA, reglas operativas

---

## Por qué existe este documento

El proyecto LRU Platform lleva muchas sesiones produciendo código, documentos y decisiones. Cada sesión acumula reglas: algunas explícitas en pies de documentos, otras implícitas en conversaciones, otras emergentes en patrones repetidos. Al cabo del tiempo, las reglas están **vivas pero dispersas**. Un Claude nuevo o un colaborador humano que entra al proyecto debe reconstruirlas leyendo mucho, y lo que no reconstruye lo reinventa o lo pierde.

`LRU_METODO` existe para que las reglas vivan en **un solo sitio**, ordenadas, revisables, y citables. No es manual burocrático. Es el acuerdo de cómo se trabaja para que la próxima sesión no pierda lo ganado en la anterior.

Este documento es uno de los cinco del **núcleo vivo** del proyecto. Los otros cuatro son `LRU_MISION`, `LRU_FUNDAMENTOS`, `LRU_ARQUITECTURA` y `LRU_MAPA`. Ningún documento del núcleo lleva sufijo de sesión. Su historia vive en git. Se actualiza sobreescribiéndose cuando hay razón para ello.

---

## 1 · El sistema documental en tres anillos

El proyecto ha acumulado más de 100 documentos a lo largo de su vida. No todos se leen en operación normal, pero todos tienen valor. El sistema se organiza en tres anillos con reglas claras.

### Anillo 1 — Núcleo vivo

Cinco documentos canónicos, sin sufijo de sesión, siempre vigentes. Cualquier persona o Claude que entra al proyecto lee estos cinco y ya sabe de qué va. Si el núcleo crece a seis, el sistema pierde eficacia.

| Documento | Responde a la pregunta |
|---|---|
| `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` | ¿Dónde está cada cosa? ¿Qué tensiones hay abiertas? |
| `LRU_METODO.md` | ¿Cómo se trabaja en este proyecto? *(este documento)* |

**Cada núcleo es autoridad única para su pregunta.** Si dos documentos se contradicen sobre misión, el canónico es `LRU_MISION`. Si se contradicen sobre arquitectura, el canónico es `LRU_ARQUITECTURA`. Sobre método, este.

**Sub-estructura del Anillo 1** (formalizada en s128 al inaugurar derivados operativos vivos):

* **§1.A · Cinco canónicos fundacionales**: los 5 documentos de la tabla anterior. Sin sufijo · siempre vigentes · autoridad única canónica para su pregunta. Se reescriben quirúrgicamente al integrar cristalizaciones fundacionales.

* **§1.B · Derivados operativos vivos navegables**: documentos vivos iterativos sin sufijo, **derivados** del contenido del §1.A pero independientes en navegación · MAYÚSCULAS por convención de capitalización (ver §1.5 abajo) · accesibles vía MCP filesystem · referenciados desde MAPA con puntero. Inaugurada en s128 al ejecutar etapa 1 de externalización navegacional articulada en `lru_externalizacion_navegacional_s128.md` · ampliada en s129 al ejecutar etapas 2 y 3 (palancas M+N+P+P-bis · 4 piezas nuevas).

**Sub-bipartición funcional §1.B** (formalizada en s129 · D-s129-S al ejecutar Propuesta A de reordenamiento de los anillos de arranque):

  * **§1.B.1 · Operativo de arranque · cargado al Project** (Nivel 1 de la cascada de fallback). Piezas que Claude consulta en **cada sesión** o que aportan estado activo del proyecto. Acceso instantáneo desde el contexto al arrancar, sin tool calls.

  * **§1.B.2 · Referencia bajo demanda · accesible vía MCP filesystem** (Nivel 3 de la cascada de fallback). Piezas navegacionales que Claude consulta **ocasionalmente** cuando una sesión específica lo requiere (sesiones de articulación, arqueología, búsqueda histórica). Acceso vía `Filesystem:read_file` cuando se necesite · coste ~2-3 segundos por consulta · trade-off favorable para piezas no usadas en cada sesión.

| Documento §1.B | Sub-categoría | Función | Fuente canónica |
|---|---|---|---|
| `LRU_GUIA_ARRANQUE_VIVO.md` | §1.B.1 | Guía de arranque por tipo de sesión · 5 categorías documentadas | `LRU_METODO` |
| `LRU_PRINCIPIOS_OPERATIVOS_VIVO.md` | §1.B.1 | Principios operativos del proyecto · recordatorios derivados consultables sin abrir múltiples canónicos | `LRU_FUNDAMENTOS` + `LRU_METODO` |
| `LRU_TENSIONES_ABIERTAS_VIVO.md` | §1.B.2 (desde s204 · D-s204-F) | Tensiones operativas activas del proyecto · estado activo consultado en cada cierre · solo-disco, leída vía MCP al arrancar | `LRU_MAPA §4.2` |
| `LRU_CATALOGO_ANILLO2_VIVO.md` | §1.B.2 | Catálogo de destilados Anillo 2 · 51 ítems en 8 sub-categorías · navegación bajo demanda | `LRU_MAPA §1.2` |
| `LRU_BITACORA_SESIONES_VIVO.md` | §1.B.2 | Bitácora de sesiones · **registro vivo por-sesión**: línea mecánica desde s204 (D-s204-B) + histórico condensado s89→s198 · hueco declarado s199→s203 (D-s204-A) | `LRU_ESTADO.md` + `LRU_MAPA` bloques sesión |
| `LRU_BITACORA_HANDOFFS_VIVO.md` | §1.B.2 | Bitácora de handoffs · **congelada en s204 (D-s204-C)** · archivo de consulta del histórico s59→s198 · los handoffs posteriores viven solo como ficheros | `LRU_MAPA §5` |

**Seis propiedades canónicas del §1.B** (detalle en alfiler s128 §3.2):
1. Sin sufijo de sesión
2. Cargado al arrancar via Project (anillo 0) · **solo §1.B.1** · §1.B.2 vive en disco accesible vía MCP
3. Iterativo · reescribible quirúrgicamente al cierre cuando aplique
4. Accesible vía MCP filesystem (todas)
5. Referenciado desde MAPA con puntero + tabla mini
6. Resiliente a fallo de MCP por cascada de cuatro niveles (Project → contraste → MCP → petición a Manuel → continuar avisando · ver alfiler §6 Q2)

**Aplicación de la cascada de fallback a §1.B.1 vs §1.B.2** (formalizada s129):
- **§1.B.1**: operación normal en Nivel 1 (Project) · escala a Nivel 3 (MCP) si Nivel 2 detecta stale.
- **§1.B.2**: operación normal en Nivel 3 (MCP) · escala a Nivel 4 (petición Manuel) si MCP cae · Nivel 5 (continuar avisando) si Manuel no puede subir. Nunca pasa por Nivel 1 salvo que se promueva a §1.B.1 por cambio de uso operativo (transición arbitrada por Manuel).

**Diferencia con §1.A**: los §1.B son **derivados operativos** · su fuente canónica vive en §1.A. Modificar §1.B no afecta canon. Modificar §1.A puede requerir actualización en cascada de §1.B.

**Renumeración coherente del sistema documental queda abierta** como decisión futura (T-S128-N1 candidata · ver alfiler s128 §6 Q1). En s128 se opta por agrupar §1.B dentro del Anillo 1 existente para no romper nomenclatura "anillo 0/1/2/3" del corpus histórico.

**Regla de actualización del núcleo**: se sobreescribe cuando hay aportación sustancial. "Sustancial" significa una de estas tres cosas: cambio de código que modifica cómo se entiende el proyecto, articulación conceptual que aporta vocabulario nuevo, o disciplina operativa nueva que afecta a sesiones futuras. No se sobreescribe por inercia ni por "tocar algo".

### Anillo 2 — Destilados por tema

Documentos que **condensan trabajo profundo sobre un tema específico**. Cuando una sesión lee varias fuentes sobre un tema y extrae hallazgos, el resultado vive aquí. La función del destilado es evitar que la próxima sesión tenga que releer las fuentes originales.

Ejemplos que ya existen (ver `LRU_MAPA`):

* `lru_debug1_analysis_s55.md` — destilado del subsistema Debug1 a partir de 6 fuentes primarias
* `lru_docs_synthesis_s55_bloques_a_b_c.md` — destilado de 10 documentos leídos en s55
* `lru_session_s53_memoir.md` — destilado narrativo del rediseño arquitectural de s53
* `LRU_TECH_DEBT_s{N}.md` — destilado acumulativo de deuda técnica

**Regla de destilados**: cada uno declara su vigencia en el pie (`vigente` · `parcialmente superado` · `superado por X`). Cuando un destilado se supera, se anota en el pie y se apunta al reemplazo, pero **no se mueve al archivo inmediatamente**. Permanece leíble hasta que el MAPA declare que ya nadie lo necesita.

**Los destilados llevan sufijo de sesión** (`_s55`). Esto es deliberado: el destilado refleja el estado de comprensión en un momento concreto. Si el tema evoluciona, el destilado nuevo (`_s62` por ejemplo) coexiste con el viejo hasta que el viejo se archive.

### Anillo 3 — Archivo histórico

Todo lo que ya no se lee en operación normal pero conserva valor histórico o trazabilidad. Vive en `doc/archivo/`. No aparece en el índice principal. Se consulta con intención — nadie empieza una sesión por aquí.

Tipos de material del anillo 3:

* Versiones antiguas de documentos canónicos (ej. 23 versiones antiguas del `LRU_PROJECT_REFERENCE`)
* Bitácora de handoffs de sesiones pasadas
* Versiones antiguas de documentos arquitecturales (ej. `analyzer1_architecture_v1` hasta `v3`, siendo `v4` el vigente)
* Documentos obsoletos declarados (ej. `lru_technical_status.html` — 44 sesiones obsoleto)
* Material fundacional cuyo contenido útil ya vive en otro sitio

### Anillo 0 — Memoria de arranque (articulada en s60)

El proyecto utiliza también un **Proyecto de Claude** (feature de la UI de Anthropic) configurado con los ficheros que deben estar adjuntos al inicio de cualquier sesión futura sin que Manuel tenga que subirlos manualmente. Funcionalmente es un **anillo 0**: no sistema documental, sino memoria de arranque instantáneo para Claude.

El Proyecto contiene **solo piezas estables** (régimen s204 · D-s204-F · partición por frecuencia de cambio):
* `CLAUDE_ARRANQUE.md` — briefing operativo condensado que Claude lee primero.
* Los cinco del núcleo vivo.
* `LRU_GUIA_ARRANQUE_VIVO.md` + `LRU_PRINCIPIOS_OPERATIVOS_VIVO.md`.

Las piezas **por-sesión** (`LRU_ESTADO.md` · `LRU_HANDOFF_VIVO.md` · `LRU_TECH_DEBT_VIVO.md` · `LRU_TENSIONES_ABIERTAS_VIVO.md`) **no se suben al Project**: viven solo en disco y Claude las lee vía MCP al arrancar (el disco es la verdad · staleness imposible por construcción). El Proyecto **no se sincroniza automáticamente con el filesystem**; el único SYNC manual que queda es re-subir una pieza estable cuando una sesión la modifica (ver §3 cierre).

El briefing `CLAUDE_ARRANQUE.md` no es canónico del núcleo de 5 — es pieza operativa complementaria. Vive en `public/docs-app/v1/doc/` como el resto, con autoridad única (no hay copia en el Proyecto: el Proyecto lo adjunta desde ahí).

### Convención de capitalización del nombre de fichero (articulada en s128)

> *"los ficheros que deben estar siempre prioritariamente en el proyecto llevan su nombre en mayúsculas para identificarlos más fácilmente, salvo el index.md"*
>
> — Manuel, s128 · 2026-05-07

**Regla operativa** derivada de la cita gold:

| Capitalización | Aplica a | Criterio mental |
|---|---|---|
| **MAYÚSCULAS** | Anillo 1.A (5 canónicos) + Anillo 1.B (derivados vivos) + Anillo 0 (CLAUDE_ARRANQUE) + vivos por-sesión (LRU_ESTADO · LRU_HANDOFF_VIVO · LRU_TECH_DEBT_VIVO · desde s204) | El nombre persiste sin cambio · es contenido permanente del arranque |
| **minúsculas** | Anillo 2 (destilados con sufijo) + Anillo 3 (archivo · incluye el corpus congelado de handoffs `lru_handoff_sX_sY` y la cadena `LRU_TECH_DEBT_sN`, ambos cerrados en s203/s204) | El nombre cambia con el tiempo · es snapshot transitorio o accesible bajo demanda |
| **Excepción** | `index.md` | Convención web universal · no se renombra |

**Criterio mental para Claude futuro**: ¿el nombre del fichero será el mismo dentro de 10 sesiones? → MAYÚSCULAS · ¿el nombre va a cambiar (sufijo de sesión, transitorio)? → minúsculas · ¿convención externa? → excepción documentada.

**Disciplina aplicada en s128**: las 2 piezas Anillo 1.B inauguradas (`LRU_GUIA_ARRANQUE_VIVO.md` y `LRU_PRINCIPIOS_OPERATIVOS_VIVO.md`) nacen ya con MAYÚSCULAS según esta convención. Documentos pre-s128 con MAYÚSCULAS (5 canónicos · `CLAUDE_ARRANQUE.md` · `LRU_TECH_DEBT_sN.md`) ya cumplían la regla implícitamente desde s56-s60 · la convención formaliza disciplina existente.

---

## 2 · Disciplina del archivo

La carpeta `doc/archivo/` se organiza con mínimo de niveles y crece orgánicamente.

### Estructura inicial

```
doc/archivo/
├── referencias/        ← versiones antiguas del project reference
├── handoffs/           ← bitácora de handoffs
└── (documentos individuales obsoletos al raíz de archivo)
```

Cuando un tema acumula varios documentos archivados (ej. tres versiones antiguas de `analyzer_architecture`), se crea su subcarpeta (`analyzer/`). Mientras el tema tiene uno o dos, viven al raíz de `archivo/`. **No se fabrican subcarpetas anticipadamente**.

### Criterios de archivo

Un documento se mueve al archivo cuando se cumple **al menos una** de estas condiciones:

1. **Obsolescencia explícita declarada**: otro documento lo reemplaza formalmente y lo cita como superado.
2. **Absorción por destilación**: su contenido útil ya vive condensado en un destilado del anillo 2, y nadie necesita el original en operación normal.
3. **Bitácora consumida**: su función era dar contexto entre dos sesiones específicas y ese contexto ya no aplica.

### Criterios de no-archivo

Un documento **permanece al raíz de `/doc/`** aunque sea viejo si:

1. Es anillo 1 (núcleo vivo).
2. Es anillo 2 (destilado vigente).
3. Es operativo de uso frecuente (por ejemplo `lru_docs_workflow`, `lru_design_system`).
4. Contiene material arquitectural vigente que ningún documento canónico ha absorbido aún.

### Política de enlaces al archivar

Cuando un documento se mueve al archivo:

* No queda stub ni redirect en su ubicación original.
* Los enlaces que le apuntaban desde documentos vivos se actualizan a la nueva ruta (`./archivo/...`).
* El movimiento se anota en `LRU_MAPA.md` en la sección correspondiente con una línea tipo *"doc X archivado en archivo/Y — sesión sN, motivo Z"*.

La trazabilidad git permite reconstruir siempre dónde vivía un documento. No se necesita capa manual de redirects.

---

## 3 · Ciclo de sesión

Cada sesión de trabajo sigue un ciclo estable. Esto no es receta rígida, es andamio confiable.

### Inicio

La sesión arranca con contexto mínimo necesario:

* Siempre: los cinco documentos del núcleo vivo (`MISION`, `FUNDAMENTOS`, `ARQUITECTURA`, `MAPA`, `METODO`) — vía Project.
* Las piezas por-sesión leídas desde disco vía MCP (régimen s204 · D-s204-F): `LRU_ESTADO.md` (primero · declara la sesión) + `LRU_HANDOFF_VIVO.md` + `LRU_TECH_DEBT_VIVO.md`.

Con eso se puede trabajar cualquier sesión genérica. Si la sesión tiene objetivo específico (implementación Realm, trabajo sobre Debug1, etc.) se añaden los destilados del anillo 2 relevantes a ese tema. El `LRU_MAPA` sección "Para Claude" indica qué adjuntar según tipo de sesión.

### Durante la sesión

El trabajo puede producir tres tipos de artefactos:

1. **Código**: ficheros `.ts`, `.tsx`, `.css` — se entregan con sufijo de sesión (`Sim1_s57v1.tsx`) y se despliegan vía script PowerShell.
2. **Destilados**: ficheros nuevos del anillo 2 si la sesión lee fuentes profundas. Se escriben con sufijo de sesión.
3. **Actualizaciones del núcleo**: sobreescritura de uno o varios documentos del anillo 1 cuando hay aportación sustancial (ver regla de actualización arriba).

Si durante la sesión se detectan **tensiones** (contradicciones entre documentos, decisiones abiertas, ambigüedades) se nombran y se anotan en `LRU_MAPA` sin resolverse unilateralmente. La resolución es decisión de Manuel en sesión posterior.

### Cierre

Al cerrar, la sesión produce cuatro documentos canónicos como mínimo:

1. **Handoff** (`LRU_HANDOFF_VIVO.md` · regenerado entero al cierre · D-s204-D): qué se hizo, qué quedó abierto, qué leer al arrancar la siguiente sesión. El histórico vive en el git del fichero + la línea mecánica de bitácora (D-s204-B). Desde s204 **no se crean** ficheros `lru_handoff_s{N}_s{N+1}.md` — el corpus con sufijo quedó congelado en `lru_handoff_s203_s204.md` como archivo de consulta.

2. **Tech debt** (`LRU_TECH_DEBT_VIVO.md` · reescrito al cierre · D-s204-E): items nuevos entran, items cerrados **salen** — el histórico de cada item vive en el git del fichero. Sustituye el régimen acumulativo de tachados de la cadena `LRU_TECH_DEBT_s{N}.md`, congelada en s203.

3. **Actualización del MAPA** si la sesión leyó documentación nueva o detectó tensiones. Se sobreescribe `LRU_MAPA.md` (sin sufijo, es canónico vivo).

4. **`LRU_ESTADO.md` regenerado entero** (regla articulada en s203 · D-s203-A/C): snapshot de una pantalla del estado al cierre (sesión cerrada · próxima · handoff activo · último commit · build · tensiones movidas · frente · pendientes-máquina). Se sobreescribe con `Filesystem:write_file`, nunca con `edit_file`. En el mismo cierre se actualiza la **frase única** de las 3 cabeceras (línea 5 del MAPA · línea 5 y pie del CLAUDE_ARRANQUE) a `sincronizado al cierre de s{N}`: desde s203 esas líneas no son log — el detalle de cada cierre vive en ESTADO + handoff, y el histórico en el git de cada fichero.

Si además la sesión produjo aportaciones sustanciales al sistema (código importante, articulación conceptual, disciplina nueva) se actualiza el núcleo que corresponda.

**Línea de bitácora mecánica al cierre** (regla articulada en s204 · D-s204-B): junto al ESTADO, añadir a `LRU_BITACORA_SESIONES_VIVO.md` §B **una sola línea** por la sesión cerrada, copiada de `LRU_ESTADO.md` (qué se hizo · build · tensiones movidas) — sin prosa nueva. La bitácora de handoffs está **congelada desde s204** (D-s204-C) y no se toca al cierre: los handoffs viven como ficheros individuales y el registro por-sesión vive en la bitácora de sesiones + git de `LRU_ESTADO.md`. El backfill s199→s203 murió por declaración (D-s204-A · hueco nombrado en ambas bitácoras).

### Actualización del `index.html` al cierre (regla articulada en s60)

**Si la sesión ha producido o modificado algún documento del raíz de `/doc/`** (nuevo destilado anillo 2, actualización de canónico del núcleo, handoff/tech debt nuevos, archivado ejecutado, promoción/degradación de documentos), **actualizar `public/docs-app/v1/doc/index.html` antes de cerrar** para que enlace lo producido y refleje el estado vigente.

Zonas del index que típicamente requieren cambio:

* Header-comment con historia de sesiones (añadir línea `sN`).
* `<div class="meta">` visible con lista acumulativa.
* Sección "Núcleo vivo" si se actualizó el tag de un canónico.
* Sección "Destilados y canónicos acumulativos" si hay destilado nuevo o cambio de vigencia (ancla tech debt reemplazada, etc.).
* Sección "Handoffs recientes" siempre que hay handoff nuevo (activo nuevo, anterior pasa a pasado).
* Sección "Notas finales" con el párrafo de la sesión cerrada.

**Cuándo NO se actualiza el index:** sesiones de pura lectura exploratoria sin producir documentos al raíz. Ese caso es raro — casi toda sesión cerrada produce al menos handoff + tech debt.

### Sincronización del Proyecto de Claude al cierre (regla articulada en s60)

**Régimen s204 (D-s204-F)**: el Proyecto contiene solo piezas estables; las por-sesión viven solo en disco. Al cierre:

* Si la sesión sobreescribió un canónico del núcleo, el `CLAUDE_ARRANQUE`, la `GUIA` o los `PRINCIPIOS` → reemplazar **solo esos ficheros** en el Proyecto.
* Las piezas por-sesión (`LRU_ESTADO` · `LRU_HANDOFF_VIVO` · `LRU_TECH_DEBT_VIVO` · `LRU_TENSIONES_ABIERTAS_VIVO`) **no se suben nunca** — Claude las lee de disco al arrancar.
* Si la sesión no tocó piezas estables, **no hay SYNC**.

Sin esta sincronización, el Proyecto servirá contexto stale en la próxima sesión y la *regla del núcleo* (§9) dejará de cumplirse aunque los ficheros en disco sí estén al día. El desfase suele manifestarse como Claude afirmando estar en una sesión anterior a la real.

### Checklist de sincronización al sobreescribir un canónico (regla articulada en s61)

Cuando se sobreescribe un canónico del núcleo (`MISION`, `FUNDAMENTOS`, `ARQUITECTURA`, `MAPA`, `METODO`), el contenido principal suele actualizarse bien — pero las zonas que **no están en el foco del cambio** tienden a conservar datos de la sesión anterior. Esto crea incoherencias silenciosas que solo emergen en auditorías posteriores (ver T-S61-M1 en `LRU_MAPA` §5.3, donde se detectaron 8 inercias acumuladas al cierre de s60).

Antes de entregar un canónico sobreescrito, repasar:

1. **Cabecera del documento** — línea `Origen: sesión sX · fecha · actualizado sY` y línea `Precedente:`. Si se sobreescribe en s{N}, añadir `· sincronizado sN · fecha`.
2. **Cabeceras de sección** con patrones tipo *"al cierre de sX"*, *"estado sX"*, *"novedad sX"*, *"al último cierre conocido"*. Buscar explícitamente y actualizar.
3. **Contadores y tablas-resumen**. Comprobar aritmética: si se añadió una tensión y se cerró otra, recalcular. Si se añadió un item al tech debt, propagar al total.
4. **Tablas que listan sesiones** (ej. tabla de estado por sesión en `LRU_MAPA §5.2`). Verificar que la última columna es la sesión actual, no la anterior.
5. **Entradas "se producirá al cierre de sX"** u otras proyecciones a futuro — si la sesión ya pasó, eliminar o reformular.
6. **Referencias cruzadas** a otros canónicos que mencionen número de sesión (ej. *"ver `LRU_METODO` §X sobreescrito en s60"*) — si ese canónico también se sobreescribe, el número puede cambiar.
7. **Pie del documento** — línea final con sesión y fecha.
8. **Coherencia entre documentos del núcleo** sobre contadores compartidos (tensiones, tech debt, destilados vigentes). Si dos canónicos dan cuentas distintas, al menos uno está stale.

Este checklist **no sustituye la revisión del contenido principal** — se aplica *además*, como pasada final antes de entregar.

**Señal de que el checklist funciona**: el próximo Claude que haga auditoría del anillo 0 no encuentra incoherencias nuevas por inercia.

### Paquete de cierre unificado con MANIFEST (articulado en s81, sustituye s61/s62/s64)

Al cierre de sesión, todos los ficheros generados —canónicos modificados, destilados nuevos, handoff, tech debt, código— se entregan en **un único ZIP versionado** con estructura estable, desplegable con un bloque de arranque breve en consola más un PS1 genérico dentro del ZIP que lee un MANIFEST.

Esta regla **sustituye** los patrones previos "Entrega al cierre — ZIP + PS1 autocontenido" (s61/s62) y "Comandos de lanzamiento" (s64). El cambio de fondo: un solo fichero presentado (no dos), PS1 genérico que vale para cualquier sesión (no específico), MANIFEST como fuente única de verdad (no rutas hardcoded en el script).

#### Convención de nombres · número de sesión + versión sincronizados

Cuatro nombres llevan sufijo `-s{N}-v{k}` idéntico:

| Artefacto | Nombre | Ubicación |
|---|---|---|
| ZIP entregado | `lru-s{N}-close-v{k}.zip` | `C:\Users\{user}\Downloads\` |
| Carpeta extraída | `lru-s{N}-close-v{k}\` | `C:\Users\{user}\Downloads\` |
| Script de despliegue | `deploy-s{N}-v{k}.ps1` | Dentro del ZIP al raíz |
| Directorio de backup | `D:\lru-backups\s{N}-v{k}\` | Disco de backups |

**Versión inicial siempre `v1`**. Se incrementa a `v2`, `v3`... en re-entregas de la misma sesión. Versionado obligatorio desde la primera entrega — nunca hay `v0` ni entregas sin versión.

**Por qué los cuatro sincronizados**: si `deploy-s81-v1.ps1` se busca dentro de `lru-s81-close-v2\`, el fallo es inmediato y ruidoso — no hay manera de ejecutar por error el script de otra sesión u otra versión. Aplica principio 7 (*"sin ruptura, aditivo"*) a la mecánica de despliegue.

#### Estructura del paquete

```
lru-s{N}-close-v{k}\
├── MANIFEST.txt              fuente única de verdad
├── deploy-s{N}-v{k}.ps1      PS1 genérico que lee MANIFEST
├── doc\                      canónicos y destilados (si la sesión los produce)
│   └── ... (ficheros .md)
└── cod\                      código (si la sesión lo produce)
    └── ... (ficheros .ts/.tsx)
```

`doc\` y `cod\` son **flexibles**: sesiones solo-documentación generan `doc\` sola, sesiones solo-código generan `cod\` sola. No se crean carpetas vacías por simetría ficticia.

#### El MANIFEST.txt como fuente única de verdad

Formato tabular, una línea por fichero, separador `|`. **Seis campos** (formato s83-v2+):

```
action | origen_en_zip | destino_absoluto | tamano_bytes | sha256 | timestamp_iso8601
```

El campo `action` es el primero porque gobierna cómo el PS1 interpreta el resto de la línea. Valores actuales:

| action | Uso | Campos relevantes |
|---|---|---|
| `COPY` | Desplegar un fichero desde el ZIP al destino | Todos los 6 campos obligatorios |
| `DELETE` | Retirar un fichero del repo (absorción, migración, obsolescencia) | Solo `destino_absoluto` es significativo · `origen`, `tamano`, `sha256`, `timestamp` se escriben como `-` por convención |

**Backward compat con formato v1** (5 campos sin `action`): el PS1 detecta el número de campos por línea. Si son 5, se interpreta como `COPY` implícito. Los MANIFESTs previos a s83-v2 siguen siendo válidos.

Cabecera obligatoria de tres líneas de comentario al inicio (el PS1 las ignora al parsear):
- Línea 1 · identificador del paquete (`# MANIFEST.txt · lru-sN-close-vK · timestamp`)
- Línea 2 · formato (`# Formato: action | origen | destino | tamano | sha256 | timestamp`)
- Línea 3 · resumen (`# N ficheros (X COPY + Y DELETE) · hash agregado: XXXX...` — hash del MANIFEST completo como verificación rápida visual)

Ejemplo con ambas actions:

```
# MANIFEST.txt · lru-s83-close-v2 · 2026-04-23T23:15:00Z
# Formato: action | origen | destino | tamano | sha256 | timestamp
# 20 lineas (19 COPY + 1 DELETE) · hash agregado: a1b2c3d4...
COPY   | doc/LRU_MAPA.md | C:\react\pwa6\public\docs-app\v1\doc\LRU_MAPA.md | 118125 | c0f4... | 2026-04-23T23:00:00Z
COPY   | cod/realm/presentation.ts | C:\react\pwa6\src\realm\presentation.ts | 24555 | 70de... | 2026-04-23T22:53:13Z
DELETE | -               | C:\react\pwa6\src\simulation\quantities.ts       | -      | -      | -
```

El MANIFEST cambia cada sesión; el PS1 no. Mismo PS1 sirve a s81, s82, s83, s83-v2 sustituyendo solo el MANIFEST. El campo `action` nuevo no rompe el PS1 legacy — versiones antiguas del PS1 que esperen 5 campos fallarán ruidosamente en el parseo, lo cual es preferible a deploy silencioso con semántica inconsistente.

#### Disciplina permanente de Downloads · trazabilidad física

Las carpetas versionadas **no se borran tras el deploy**. Quedan en `Downloads\` como trazabilidad física complementaria. Cada sesión acumula su `lru-sN-close-vK\` con PS1, MANIFEST y ficheros desplegados de ese momento exacto. Permite reproducir un despliegue histórico sin depender de git ni de backups.

Esta trazabilidad **no sustituye** los otros sistemas de respaldo (git, `D:\lru-backups\`) — es tercera línea complementaria.

#### Bloque de arranque · en consola, antes del PS1

El despliegue arranca con un **bloque breve que Manuel copia-pega en PowerShell**, mostrado inline en el chat al presentar el ZIP. Manuel ve el código entero, verifica `$session` y `$version`, y lo ejecuta. Es la primera línea de defensa contra errores de entrega.

El bloque:

1. Declara `$session` y `$version` en las dos primeras líneas (visibles, verificables)
2. Resuelve `Downloads\` autónomamente vía `$env:USERPROFILE`
3. Aborta si el ZIP no existe con nombre exacto (error de sesión o versión)
4. Aborta si la carpeta extracción ya existe (evita mezclar despliegues)
5. Extrae el ZIP, ejecuta `Unblock-File` sobre el contenido (resuelve Zone.Identifier)
6. Invoca el PS1 interno (`deploy-s{N}-v{k}.ps1`) desde dentro de la carpeta extraída

#### Disciplina del PS1 genérico

El `deploy-s{N}-v{k}.ps1` vive dentro del ZIP al raíz. Usa `$PSScriptRoot` para localizar MANIFEST, `doc\` y `cod\` como hermanos — nunca rutas absolutas sobre `Downloads\`. El script opera por fases, con comportamiento ramificado según el campo `action` de cada línea del MANIFEST:

1. **Valida precondiciones antes de tocar nada**:
   - **COPY**: el fichero origen existe dentro del ZIP extraído · la carpeta destino absoluta existe en el repo.
   - **DELETE**: la carpeta del destino existe (para backup); si el fichero destino ya no existe, se marca como `SKIP already removed` y continúa sin fallar — **la operación DELETE es idempotente** y no debe fallar en re-deploys.
   - Si cualquier precondición no-idempotente falla, aborta ruidosamente antes de backup.

2. **Fase 1 · Backup** a `D:\lru-backups\s{N}-v{k}\` preservando path relativo desde `C:\react\pwa6\`:
   - **COPY**: copia el destino preexistente (si existe) · `SKIP` si es fichero nuevo que no tenía versión previa.
   - **DELETE**: backup del fichero a retirar es **obligatorio** (no skip) · el backup es la única prueba residual de que el fichero existió. Si el destino ya no existe (idempotencia), se registra `SKIP already removed` y no hay backup.

3. **Fase 2 · Operación**:
   - **COPY**: despliega desde el ZIP al destino · preserva `LastWriteTime` del origen extraído.
   - **DELETE**: `Remove-Item -LiteralPath` sobre el destino. La operación no toca carpetas — solo ficheros (por simplicidad y para evitar borrados amplios por error).

4. **Fase 3 · Verificación** con checks apropiados por acción:
   - **COPY**: 4 checks — presencia en destino, tamaño exacto contra MANIFEST, hash SHA256 exacto contra MANIFEST, preservación de timestamp (destino comparado contra origen extraído · tolerancia de 2 segundos por granularidad del filesystem · `Expand-Archive` puede introducir desfase UTC/local que invalidaría comparación literal con MANIFEST).
   - **DELETE**: 1 check — **ausencia del destino**. `Test-Path` debe devolver `$false`.
   - Todos los checks deben pasar o el script reporta FAIL con detalle por fichero.

Las cuatro reglas permanentes del PS1 de §5 siguen vigentes: ASCII only · `Join-Path` con 2 args · sin paréntesis en strings doble-quoted · sin backtick-n.

**Por qué DELETE declarativo pertenece al paquete** (articulado en s83-v2 tras fricción real con `quantities.ts` absorbido por `presentation.ts` en T2): si el ciclo destilado → código retira un fichero entero del repo, el paquete de cierre debe cerrar el ciclo completo sin tarea manual residual. Dejar el delete como "ejecuta esto después del deploy" viola la propiedad *"deploy como unidad atómica verificada"*: el repo post-deploy difiere del repo post-tarea-manual, y entre ambos hay una ventana donde el código no compila o tiene dos fuentes del mismo símbolo. El DELETE declarativo cierra la ventana.

#### Presentación al cierre

Se presenta **un único fichero**: el `.zip`. El bloque de arranque se muestra **inline en el chat** como código copy-paste (no como fichero). El PS1 interno y los ficheros individuales **no se presentan sueltos** — viven dentro del ZIP como unidad.

Si Manuel necesita revisar un fichero interno antes del deploy, lo pide explícitamente.

#### Plantilla literal del bloque de arranque · canónica copy-pegable (formalizada en s129)

El bloque de arranque vive aquí como **plantilla literal canónica**. Cualquier sesión sustituye `s{N}` y `v{k}` con sus valores reales · el resto del bloque permanece estable. Resuelve `Downloads\` autónomamente vía `$env:USERPROFILE` · ejecuta desde cualquier directorio actual del prompt PowerShell:

```powershell
# Bloque de arranque canónico · pegar en PowerShell desde cualquier directorio
$session = "s{N}"        # Sustituir N por número de sesión (ej: "s129")
$version = "v1"          # Sustituir si es re-entrega v2/v3
$pkg = "lru-$session-close-$version"
$downloads = Join-Path $env:USERPROFILE "Downloads"
$zip = Join-Path $downloads "$pkg.zip"
$dst = Join-Path $downloads $pkg

if (-not (Test-Path -LiteralPath $zip)) {
  Write-Error "ZIP no encontrado: $zip"
  return
}
if (Test-Path -LiteralPath $dst) {
  Write-Error "Carpeta extraccion ya existe: $dst"
  return
}

Expand-Archive -LiteralPath $zip -DestinationPath $dst
Get-ChildItem -LiteralPath $dst -Recurse | Unblock-File
& (Join-Path $dst "deploy-$session-$version.ps1")
```

**Por qué literal aquí**: hasta s128, esta plantilla se reescribía en cada cierre, introduciendo errores cosméticos y de ergonomía. La plantilla canónica vive en METODO desde s129 · cada cierre la copia tal cual · sustituye solo `$session` y `$version`.

#### Orden ejecutivo del cierre operativo · 5 pasos canónicos (formalizado en s129)

Mnemónica: **BACKUP → ZIP → DEPLOY → SYNC → COMMIT**

Cada paso depende del anterior. Saltarse uno viola disciplina T-S90. La secuencia es la que vivía implícita en handoffs §5 desde s90 · canonizada aquí en s129 al detectar el patrón recurrente *"el cierre falla por presentación de ficheros sueltos sin ZIP + olvido de pasos operativos"*.

| Paso | Acción | Destino | Quién | Disciplina |
|---|---|---|---|---|
| **1 · BACKUP** | Backup pre-deploy del estado actual del repo | `D:\lru-backups\s{N}-pre-deploy-{timestamp}\` | Manuel · PowerShell | §5.1 (backup obligatorio antes de desplegar · sin excepciones) |
| **2 · ZIP** | Empaquetado del paquete de cierre por Claude | `C:\Users\manue\Downloads\lru-s{N}-close-v1.zip` | Claude · presentación | §3 estructura plana + §5.2 entrega monolítica + plantilla bloque arranque |
| **3 · DEPLOY** | Ejecutar bloque arranque PowerShell · extrae ZIP + invoca PS1 (3 fases internas) | Repo `C:\react\pwa6\public\docs-app\v1\doc\` + backup `D:\lru-backups\s{N}-v1\` | Manuel · PowerShell | §3 disciplina del PS1 genérico · 3 fases backup/copy/verify |
| **4 · SYNC** | Sincronización del Proyecto de Claude (anillo 0) | UI Anthropic · Project del proyecto | Manuel · UI | §5.4 T-S90-A6 · 4 estados (subir/heredar/retirar/no subir) |
| **5 · COMMIT** | Commit Husky desde PowerShell · git lo absorbe con lint-staged | Repo git · branch `main` | Manuel · PowerShell | D5 contenido obligatorio + lint-staged reformatea durante commit (D-s109-1) |

**Por qué este orden**:

- **BACKUP antes de ZIP**: el backup captura el estado pre-deploy · el ZIP cambia el estado · invertir destruye la red de seguridad.
- **ZIP antes de DEPLOY**: el deploy lee del ZIP extraído · sin ZIP no hay deploy posible.
- **DEPLOY antes de SYNC**: el deploy actualiza el repo · si falla, el Project queda apuntando a contexto inválido. Sync solo cuando deploy verifica OK.
- **SYNC antes de COMMIT**: el Project es la "fuente de arranque" para próxima sesión · debe estar sincronizado antes de que el commit cierre el ciclo. Si commit primero, sync queda como deuda silenciosa.
- **COMMIT al final**: el commit es el sello de "ciclo completo verificado" · solo después de los 4 pasos anteriores con éxito.

**Recordatorio en handoff §5**: la sección "Pendientes operativos del lado de Manuel" del handoff debe replicar los 5 pasos en orden con destinos específicos de la sesión. Ver §5.4 sobre la disciplina T-S90-A6.

#### Qué resuelve esta regla

- *"Se me olvidó descargar uno de los ficheros"* → solo hay uno que descargar
- *"Ejecuté el PS1 de otra sesión"* → nombre versionado bloquea la coincidencia accidental
- *"El PS1 está desincronizado con los ficheros"* → viajan como unidad, imposible
- *"Tengo N PS1 en Downloads y me lío"* → ningún PS1 suelto en Downloads nunca
- *"Quiero reproducir un despliegue histórico"* → la carpeta versionada está intacta en Downloads


### Ciclo destilado → código (formalizado en s82 tras 4 instancias consecutivas · confirmado con 5ª en s83)

Entre s77 y s80 el proyecto aplicó cuatro veces seguidas el mismo flujo para llevar decisiones arquitecturales del destilado al código vivo, sobre artefactos estructuralmente distintos: schema declarativo Zod con extensión de tipo (s77), schema declarativo Zod con reemplazo completo de tipo (s78), catálogo declarativo TypeScript con migración vocabular (s79), motor procedural con estado mutable (s80). El patrón funcionó sin fricción en los cuatro casos. **Se formalizó aquí en s82 como disciplina canónica del proyecto**. **En s83 se ejerció por quinta vez sobre un quinto tipo estructural** — tipos fundacionales v3 con múltiples fuentes autoritativas simultáneas, procesados en plan α de 4 tandas encadenadas (T1 schema, T2 presentation.ts + migración ISA, T3 reclasificación sim-catalog + regeneración realm, T4 motor actuator completo). El patrón escaló a sesiones batch sin fricción: 50/50 tests verde, 5 tensiones cerradas por materialización, 2 reclasificaciones simultáneas del ritual, 2 nuevas tensiones prioridad baja registradas. La disciplina canónica **queda ratificada con 5 instancias**.

La motivación es prevenir el antipatrón "articulación sin ejercicio" — destilados densos que nunca tocan código, o código que se escribe sin leer el destilado autoritativo y diverge silenciosamente. El ciclo fuerza que la propuesta y el código se encuentren bajo revisión humana antes de que se toque el repo.

#### Los 6 pasos obligatorios

1. **Lectura dirigida del destilado autoritativo.** El destilado anillo 2 que articuló el diseño (con regla de disputa activa) se lee completo antes de tocar código. Si el destilado está ausente o es ambiguo, trabajar el destilado primero — no arrancar el ciclo.

2. **Lectura del código vivo** en los ficheros que se van a tocar. No trabajar sobre la versión del código recordada de sesiones anteriores ni sobre la descripción del ARQUITECTURA: leer los ficheros reales del repo en el estado exacto de esta sesión. La divergencia entre "lo que el destilado propone" y "lo que el código ya hace" suele resolver decisiones de diseño sin fricción (ejemplo: shim innecesario en s80 porque el catálogo ya había promovido los genéricos a ciudadanos de primera clase en s79).

3. **Grep preventivo de consumidores** del tipo, schema o función a cambiar, sobre todo `src/`. Neutraliza el riesgo principal del refactor — consumidores no vistos que se rompen por la firma nueva. Si el grep descubre consumidores, entran al scope del ciclo; si no, queda documentado que la cirugía es local.

4. **Propuesta de diff en bloque tipado para aprobación explícita** antes de tocar el repo. El diff se presenta en bloques de código con anotación de por qué cada cambio, y el usuario aprueba o pide ajustes antes de la aplicación. Este paso preserva al humano como filtro consciente y elimina el modo "Claude aplicó 15 cambios y ahora hay que revisarlos a posteriori". No es opcional: saltárselo invita al antipatrón.

5. **Aplicación al workspace editable** (no al repo directo del usuario) con compilación TypeScript strict. El workspace es el scratchpad de Claude (`/home/claude/`). TypeScript strict puede revelar hallazgos colaterales — adaptaciones obligatorias que no estaban en el scope original. Esos hallazgos se nombran explícitamente (ejemplo s77: adaptación de `RealmManifestSchema.superRefine` a `switch(ev.kind)` forzada por TS strict); si son ganancia estructural, se registran como "hallazgo colateral" en el tech debt de la sesión, no como tensión nueva.

6. **Test de smoke con grupos mínimos** ejecutable con `tsx` y versiones exactas del `package.json`. Tres grupos son el mínimo: no-regresión (lo que funcionaba sigue funcionando), feature nuevo (lo que se añade funciona), regresiones deseadas (lo que debía dejar de funcionar ya no funciona). Grupos adicionales según escala del cambio. El test es artefacto histórico de la sesión — no se integra al repo de producción por defecto, pero se preserva en el paquete de cierre como evidencia de cobertura.

#### Sub-patrones derivados

**A · Decisiones de política al inicio con `ask_user_input_v0`** (patrón s78, ampliado s79). Antes de proponer diff, las decisiones que afectan scope, ruptura vs. compatibilidad, o política granular se plantean con opciones discretas y se responden antes de que se toque código. En s79 se encadenaron 11 decisiones interdependientes en fase de diseño sin que Claude inventara una sola. Esto es lo opuesto a "Claude decidió por su cuenta y Manuel lo descubre en la revisión".

**B · Propuesta antes de ejecutar con tabla revisable** (patrón s79). Cuando el cambio implica mapping granular de muchos elementos (en s79: 33 faults clasificados a 1 de 16 kinds), se produce una tabla de clasificación con justificación por elemento antes de escribir la línea de código que aplica el mapping. La tabla se aprueba o se corrige. Elimina invención individual y preserva arbitrio humano a escala granular.

**C · Destilado paralelo de diseño futuro como alternativa a código sin callsite** (patrón s79). Cuando una pieza arquitectural no puede materializarse en la sesión actual porque no tiene callsite todavía (ejemplo s79: `ActuatorDef` sin entidad Realm que la consuma), se produce destilado anillo 2 completo con regla de disputa activa — nunca código muerto en el repo. Honra la disciplina "un proyecto a la vez" (§5bis) sin sacrificar densidad de diseño.

#### Patrón complementario — exploración vs. implementación separadas (confirmado en s81)

No toda sesión debe ejecutar el ciclo. Cuando el trabajo es **decisión arquitectural sin callsite inmediato** (ejemplo s81: decisión sobre `quantities.ts` en Realm v3 sin código a tocar porque `ActuatorDef` precede), la sesión se aísla como **sesión de decisión arquitectural pura**, produce destilado autoritativo con regla de disputa activa, y no toca código. Mezclar decisión y implementación en la misma sesión degrada ambas: la decisión se toma con menos oxígeno, el código se escribe sobre decisión aún caliente.

La decisión de operar en modo "exploración" o "implementación" es explícita al arranque de sesión. Ambos modos son legítimos y necesarios — el ciclo destilado→código presupone que hay destilado autoritativo, que alguien tuvo que producir antes.

#### Ritual de reclasificación post-materialización (5 instancias: s77, s78, s80, y 2 simultáneas en s83)

Cuando un destilado anillo 2 con regla de disputa activa se materializa en código, su estatus pasa de "fuente autoritativa con regla de disputa activa" a **"referencia histórica post-materialización"**. La operación es ligera:

- El destilado no se archiva, no se mueve, no se modifica. Sigue en `public/docs-app/v1/doc/`.
- Solo cambia su clasificación en `LRU_MAPA §1.2.6` (o la sección que cataloga los destilados vigentes).
- Su autoridad operativa la toma el código materializado. El destilado pasa a documentar *por qué* el código es así, no *qué* debería ser el código.

Instancias históricas: s77 reclasificó `lru_scenario_event_extension_s64.md` tras materialización de apply-profile. s78 reclasificó `lru_faultdef_refactor_s65.md` tras materialización del schema. s80 reclasificó `lru_applyfault_mapping_s79.md` tras materialización del dispatcher. **s83 aportó dos instancias simultáneas**: `lru_actuator_model_s79.md` tras materialización de ActuatorDef + motor actuator (T1+T3+T4) y `lru_quantities_decision_s81.md` tras materialización de presentation.ts (T2). Dos reclasificaciones en la misma sesión es precedente nuevo — el patrón escala a sesiones batch con múltiples piezas. El patrón se confirma con cinco instancias — se absorbe dentro de este ciclo en lugar de vivir como subsección separada.

#### Sub-patrón · validación empírica del schema con realm regenerado (formalizado en s86 tras 3 instancias)

Cuando una tanda del ciclo destilado→código regenera un fichero de datos (realm, catálogo), el test de smoke del schema se ejercita **contra ese fichero vivo** en lugar de contra fixtures inline. El patrón cierra el bucle entre declaración (schema) y uso (realm) dentro de la misma sesión.

**Instancias históricas (formalizado como disciplina tras la 3ª)**:

1. **s83 T3** — Regeneración de `a320.realm.ts` al shape s78+s83 permitió ampliar el test T1 con `parseRealm(a320Realm)` en lugar de fixtures inline. El test T1 pasó de 16/16 a 20/20 añadiendo 4 tests G1 que ejercitan validación cruzada del schema contra un realm vivo con 10 ActuatorDef, 6 ActuatorFaultDef, 3 feedbackSensorId válidos. Primera instancia empírica del sub-patrón.

2. **s86 Tanda 1** — Catálogo `ATA_CATALOG` regenerado con 18 chapters parseado uno a uno contra `ATAChapterDefSchema.superRefine` como test G3. El catálogo entero es *"realm regenerado a nivel de catálogo específico"* · cubre los 18 por construcción, no por inspección visual. Segunda instancia aplicada a primer realm específico.

3. **s86 Tanda 2** — `a320.realm.ts` entero parseado contra `RealmManifestSchema` como test G4 **más** validación cruzada de los 10 `taxonomyRef` de actuators contra `ATA_CATALOG`. Tercera instancia combinando validación del schema + integridad referencial cruzada entre base agnóstico y realm específico.

**Ventajas del sub-patrón sobre fixtures inline**:
- **Cobertura realista**: la validación se ejerce sobre estructuras que el proyecto realmente usa, no versiones simplificadas.
- **Test sirve como validación del realm**: si el realm tiene bug, el test falla con mensaje informativo del `superRefine`.
- **Integridad referencial cruzada disponible**: cuando dos capas del sistema (schema + realm específico) deben estar sincronizadas, el test puede detectar desincronizaciones empíricamente.
- **Sub-patrón natural del ciclo**: cuando una tanda regenera un fichero de datos, ejercitar el test del schema contra él cierra el bucle sin coste adicional.

**Cuándo aplicar**: siempre que una tanda del ciclo regenere un realm, un catálogo específico de dominio, o un fichero de configuración del tipo declarativo-de-primera-clase. El coste marginal es mínimo (pocos tests adicionales sobre estructura ya parseada) y el valor de cobertura es alto.

**Cuándo no aplicar**: cuando la tanda no regenera datos sino que solo modifica firmas de función o código procedural. Los fixtures inline siguen siendo apropiados para casos puros de validación de shape del schema.

**Estado: disciplina canónica del proyecto** tras 3 instancias (s83 T3 + s86 Tanda 1 + s86 Tanda 2). Formalizado en s86 con aprobación explícita de Manuel al cierre tras constatar que el coste marginal es despreciable y el valor de cobertura es consistentemente alto.

#### Cuándo NO aplicar el ciclo completo

El ciclo es herramienta, no rito. Hay casos donde aplicarlo entero degrada la sesión por sobrecoste:

- **No hay destilado autoritativo.** Trabajar el destilado primero, en otra sesión o en el modo "exploración" descrito arriba. Arrancar el ciclo sin fuente autoritativa es invitarse a la invención.
- **Cambio puramente mecánico** (rename global, reformatting, cambio de imports). No necesita los 6 pasos — basta el grep preventivo y la aprobación. Sobrecoste explícito.
- **Alcance excede una sesión con confort.** Fragmentar antes de arrancar. El ciclo entero en una pieza grande con contexto insuficiente al cierre invita al fallback `v2_*_aplicacion.md` (sección siguiente), que es aceptable pero no deseable.
- **Dominio aún no probado estructuralmente.** El ciclo está confirmado sobre schema declarativo, catálogo declarativo, y motor procedural con estado. Sobre otros tipos de artefacto (hooks React con efectos, workers, código criptográfico, etc.) el patrón es candidato — no disciplina confirmada. Ejercer con atención al patrón hasta tener 2-3 instancias.

#### Integración con regla del núcleo (§9)

El ciclo no se salta la regla de sincronización al cierre. El destilado reclasificado exige actualizar `LRU_MAPA §1.2.6` (cambio de estatus). El código materializado exige actualizar `LRU_ARQUITECTURA` si tocó inventario de módulos. El cierre de sesión aplica el checklist de `§3 · Sincronización del Proyecto de Claude` igual que cualquier otra sesión.

La formalización de este ciclo no desplaza ninguna de las 7 disciplinas del ciclo de sesión general — las especializa para el tipo de trabajo "llevar destilado autoritativo al código".


### Regeneración entera vs parche localizado — fallback por contexto (articulado en s65, formalizado en s66)

La norma al sobreescribir un canónico es **regenerarlo entero**: permite aplicar el checklist de sincronización de arriba sobre documento completo, detectar inercias, y garantizar coherencia cruzada. Regenerar solo "la zona del cambio" es frágil porque las zonas no-cambiantes son donde la inercia se acumula (T-S61-M1).

Ocurre sin embargo que al final de una sesión larga, con decisiones arquitecturales densas ya tomadas, el contexto disponible puede no alcanzar para regenerar 4 canónicos enteros con garantía. En ese caso:

1. **Se entregan instrucciones de aplicación localizadas** — ficheros tipo `v2_{NOMBRE}_aplicacion.md` que describen, con contexto suficiente para revisión, los parches exactos a aplicar sobre cada canónico. El nombre `v2` indica "segunda versión del documento" — equivalente a la salida de una regeneración entera, pero entregada como diff revisable.
2. **Se documentan los 3 documentos nuevos autocontenidos** (handoff, tech debt, destilado) como ficheros finales — esos no tienen el problema porque son escritura nueva, no sobreescritura.
3. **Se añade una sección `§0 · Tarea pendiente al arrancar` en `CLAUDE_ARRANQUE.md`** marcando la recomposición como prioridad alta para la siguiente sesión. Esa sección es transitoria — se retira cuando la recomposición se ejecuta.
4. **La siguiente sesión arranca con la recomposición como primer bloque**, antes de cualquier trabajo arquitectural nuevo. Si Manuel prefiere posponer para arrancar otra cosa, la §0 permanece hasta que la recomposición se ejecute.
5. **Regla de disputa**: si entre el parche localizado y el destilado de la sesión que los produjo hay ambigüedad, **gana el destilado** — es la fuente autoritativa del diseño.

Este patrón se usó al cierre de s65 y se aplicó en s66. **No es deseable como norma** — es fallback aceptable. La disciplina real sigue siendo regenerar enteros al cierre si el contexto lo permite.

### Code review antes de cerrar

Si la sesión tocó código, antes del cierre se pasa una revisión rápida buscando: bugs, imports rotos, patrones incumplidos, consideración de viewport, posibles leaks de memoria, compatibilidad touch. Los hallazgos se arreglan antes del cierre, no se posponen.

### Dieta documental (formalizada en s94 al cerrar T-S93-DIETA por materialización)

El destilado anillo 2 `lru_dieta_documental_s93.md` propuso 5 ajustes para reducir el peso del núcleo vivo y la fricción al arrancar cada sesión. Manuel arbitró punto por punto en s93 (4 aprobadas + 1 status quo confirmado). La materialización en s94 cierra T-S93-DIETA y deja **5 disciplinas operativas formalizadas** que toda sesión futura debe respetar (las 4 propuestas aprobadas + la disciplina correctiva s89 ratificada por **6ª aplicación** y absorbida en este mismo bloque para coherencia).

**D1 · Solo §8 vive en el MAPA · trazabilidad histórica en git** (P1 aprobada · variante (a)):

El MAPA preserva un único `## 8 · Estado del MAPA al cierre de sN`. Las versiones previas (§8bis · §8ter · etc.) se retiran. Si emerge necesidad de consultar contadores de cierres anteriores, se accede vía `git show HEAD~N:LRU_MAPA.md` o desde el snapshot HTML del cierre correspondiente publicado en boxdin. La trazabilidad existe · solo no se duplica en el documento vivo.

**D2 · Compresión de cabecera línea 5 del MAPA** (P2 aprobada · variante (c) · desviación de la recomendación firme original (a)):

La cabecera línea 5 del MAPA mantiene **descripción densa solo para las 3 sesiones más recientes** (sN-2 + sN-1 + sN). Las sesiones más antiguas se comprimen a una línea condensada del tipo *"sincronizado s58→sN-3 (línea condensada por P2(c) en s94 · descripciones densas históricas en handoffs históricos + git del MAPA)"*. Disciplina operativa: en cada cierre, comprimir la entrada de sN-3 antes de añadir la nueva sN.

**D3 · Pies de documentos del núcleo · matizado en s94** (P3 aprobada · desviación arbitrada respecto a la recomendación firme original (a)):

- **Pies estáticos** en `LRU_MAPA`, `LRU_METODO` y `CLAUDE_ARRANQUE`: una sola línea con timestamp del último cierre · sin acumulación. Formato canónico: *"LRU Platform · {nombre} · Documento vivo del núcleo · sincronizado por última vez al cierre de sN · {fecha} · Manuel & Claude Opus 4.7"*.
- **Pies con traza preservada** en `LRU_MISION`, `LRU_FUNDAMENTOS` y `LRU_ARQUITECTURA`: la crónica de **ampliaciones sustantivas** (postulados añadidos, §s nuevas, integraciones de cristalizaciones fundacionales) se conserva porque es información cualitativamente distinta de la sincronización rutinaria. La traza de "qué se ha añadido conceptualmente" tiene valor documental que la traza de "qué se ha sincronizado" no tiene.

**D4 · Handoff operativo · plantilla recortada P5(b)** (P5 aprobada · variante (b)):

El handoff es **operativo, no archivo**. Para auditoría retrospectiva existen MAPA + git + index publicado. La plantilla canónica del handoff a partir de s94 tiene 5 secciones: **§0 + §3 + §4 + §5 + §7** (conservando los números originales del handoff denso · los huecos de numeración son intencionales · facilitan comparación cruzada con la familia histórica de handoffs):

- **§0 · Resumen ejecutivo** · 1-2 párrafos sobre el carácter de la sesión cerrada y el estado al cierre.
- **§3 · Cambios netos sN-1 → sN** · descripción densa de qué se hizo · única pieza autocontenida que captura el delta operativo de la sesión.
- **§4 · Opciones articuladas para sN+1** · 2-3 opciones con coste/beneficio.
- **§5 · Recomendación firme y disposición** · cuál se recomienda y por qué · pushback honesto si la recomendación se ha heredado varias veces sin ejecutar.
- **§7 · Sincronización del Proyecto de Claude para sN+1** · qué subir/heredar/retirar/no subir (T-S90-A6).

Las secciones §1 (estado anillo 0), §2 (estado tensiones), §6 (pendientes menores) **se retiran**: §1 y §2 duplican estado del MAPA · §6 si emerge tensión formal va al MAPA, si no es ruido.

**D5 · Contenido obligatorio del paquete de cierre · disciplina correctiva s89 super-firme** (ratificada por 6ª aplicación · absorbida en s94):

El paquete de cierre publicado al final de cada sesión incluye **siempre los 6 documentos del anillo 0+1 base** (`LRU_MISION` + `LRU_FUNDAMENTOS` + `LRU_ARQUITECTURA` + `LRU_MAPA` + `LRU_METODO` + `CLAUDE_ARRANQUE`) en el MANIFEST · aunque alguno no se haya modificado en la sesión. Razón: el paquete debe ser desplegable como instantánea autocontenida del estado canónico al cierre · evita desfases silenciosos cuando un Claude futuro arranca solo con el paquete de la última sesión sin acceso al historial.

Adicionalmente, el paquete incluye: el `LRU_TECH_DEBT_sN.md` nuevo · el `lru_handoff_sN_sN+1.md` nuevo · cualquier destilado anillo 2 nuevo o reanotado en la sesión · cualquier código modificado en la sesión.

**Estado final**: cualquier sesión sN+1 que arranque solo con el paquete `lru-sN-close-v*.zip` desplegado debe poder operar inmediatamente sin requerir ficheros adicionales más allá de los que ya están en el repo (código existente + canónicos del paquete + handoff + tech debt). El MANIFEST es la fuente única de verdad sobre qué entra · el ZIP es estructurado plano-por-categoría (T-S90-A4).

**D6 · Política unificada de mantenimiento del MAPA** (formalizada en s129 al cerrar D6 candidata por materialización · sembrada en alfiler s128 `lru_externalizacion_navegacional_s128.md` + completada con cierre graduado tras 11 palancas aplicadas en 2 sesiones · 9ª aplicación del ciclo destilado→código · 2ª sobre objeto documental tras T-S93-DIETA s94):

El MAPA mantiene su naturaleza de **índice navegacional con punteros** mediante dos disciplinas complementarias que se ejercen como un mismo bloque arquitectural · **no son operaciones separadas**.

**D6.1 · Bloque arquitectural unificado · poda + externalización + reescritura iterativa** (articulada en alfiler s128):

Las tres operaciones forman misma disciplina · difieren solo en el destino del material:

- **Poda**: el material se condensa o se elimina porque vive ya en otro sitio (git histórico · handoffs · pies documentales). El MAPA pierde peso sin ganar puntero porque el destino canónico ya existía. Aplicado en s128 con palancas A+B+C+E+I (−86 KB).
- **Externalización**: el material se mueve a un fichero del Anillo 1.B nuevo. El MAPA pierde peso y gana puntero · el destino canónico es nuevo y se inaugura en el cierre. Aplicado en s128 con palancas Q+O (−22.6 KB · `LRU_GUIA_ARRANQUE_VIVO.md` + `LRU_PRINCIPIOS_OPERATIVOS_VIVO.md` inaugurados) · ampliado en s129 con palancas M+N+P+P-bis (−83.7 KB · 4 piezas Anillo 1.B nuevas: `LRU_TENSIONES_ABIERTAS_VIVO.md` + `LRU_CATALOGO_ANILLO2_VIVO.md` + `LRU_BITACORA_SESIONES_VIVO.md` + `LRU_BITACORA_HANDOFFS_VIVO.md`).
- **Reescritura iterativa**: el material se actualiza in situ con la información más reciente. Sin movimiento neto de peso · solo refresco. Aplicado al pie del MAPA y a cabecera línea 5 en cada cierre.

**Cuándo aplicar cada operación**:

- Si el destino canónico **ya existe** y el material es duplicación → poda.
- Si el material es navegacional puro y **no tiene destino canónico todavía** → externalización (inaugurar fichero Anillo 1.B).
- Si el material es operativamente vivo y solo está stale → reescritura iterativa.

**D6.2 · Cierre graduado de bloques de sesión** (formalizada en s129):

Los bloques de sesión (`## Última sesión cerrada` + `## Sesión previa sN-1` + ...) son la fuente principal de crecimiento monotónico del MAPA si no se gestionan al cierre. Disciplina:

| Antigüedad | Tratamiento | Tamaño orientativo |
|---|---|---|
| **sN (Última cerrada)** | Detalle completo · narrativa autocontenida | 8-12 KB |
| **sN-1 (anterior)** | Detalle completo · narrativa autocontenida | 8-12 KB |
| **sN-2** | Comprimido a 1-2 párrafos densos | ~1-2 KB |
| **sN-3** | Comprimido a 1 línea condensada | ~0.2 KB |
| **sN-4 y anteriores** | **Mover al fichero vivo** `LRU_BITACORA_SESIONES_VIVO.md` | 0 KB en MAPA |

**Disciplina operativa al cierre de cada sesión sN**:

1. Reescribir `## Última sesión cerrada` con sN (detalle completo).
2. Renombrar el `## Última sesión cerrada` previo a `## Sesión previa sN-1` (sin cambios · ya estaba escrita).
3. Comprimir el bloque `## Sesión previa sN-2` a 1-2 párrafos (manteniendo título + fecha + 1-2 logros principales + tensiones nuevas/cerradas + puntero al handoff).
4. Comprimir el bloque `## Sesión previa sN-3` a 1 línea condensada (`* sN-3 · fecha · 1 frase + puntero handoff`).
5. Mover el bloque `## Sesión previa sN-4` íntegro al fichero vivo `LRU_BITACORA_SESIONES_VIVO.md` (en la posición cronológica correspondiente).

**Coste operativo**: ~5 minutos al cierre de cada sesión. **Beneficio**: tamaño estacionario del bloque de sesiones del MAPA · ~22-25 KB techo en lugar de crecimiento monotónico.

**Anti-anticipación P11**: el patrón se aplica **al cierre · no preventivamente · no retroactivamente más allá de lo necesario**. Si una sesión cierra sin tocar el MAPA materialmente, los bloques se desplazan formalmente sin perder información.

**Aplicación inaugural en s129**: D6.2 aplicada al cierre s129 mismo · s125 comprimida a párrafo · s123 comprimida a línea · s122 y anteriores ya externalizados en palanca P (s125 = sN-2 vista desde s127 que era última escrita · s123 = sN-3 análogamente).

---

## 4 · Convenciones de ficheros

### Cabeceras obligatorias

Cada fichero de código creado o modificado lleva **dos líneas** al inicio:

* Línea 1: path comentado (`// src/path/file.ts`).
* Línea 2: timestamp completo GMT ISO 8601 con segundos (`// 2026-04-18T14:30:00 GMT`).

Para CSS se usa `/* ... */` en ambas líneas. Nunca se omiten minutos o segundos.

### Sufijos de versión

* Ficheros de código en ZIP: sufijo de sesión y versión (`Sim1_s57v1.tsx`).
* Re-entregas en la misma sesión: incrementar la versión (`Sim1_s57v2.tsx`).
* Documentos del anillo 1: sin sufijo.
* Documentos del anillo 2: con sufijo de sesión de producción.
* Documentos del anillo 3: se preserva su sufijo original.

### Terminología canónica

En UI y en documentación que se ofrece al usuario:

* **Telemetría**, no "mqtt". MQTT es el protocolo concreto; telemetría es la función genérica.
* **Instrumentos de simulación** o **simulaciones**, nunca "animations".
* **Hardware** o **dispositivo hardware**, nunca términos propietarios del chip.
* No se mencionan chips específicos ni herramientas de autoría visual sin petición explícita del usuario.

### Presentación de ficheros generados

* Documentos canónicos del anillo 1: se presentan con `present_files` al cierre de sesión para revisión directa.
* Código en ZIP: se entrega con script PowerShell de despliegue (3 fases: backup → copia → verificación SHA256).
* Varios entregables del mismo fichero en una sesión: incrementar versión del ZIP (`lru-s57-metodo-v1.zip`, `v2`...).
* Nunca se reutiliza el mismo nombre de fichero en `present_files` dentro de una sesión.

---

## 4bis · Glosarios canónicos por lego

Sección integrada en s133 al cristalizar el Glosario Canónico Atlas tras emerger problemas serios de nombres en el lego durante el rename P13. Esta sección codifica la disciplina operativa: **cada lego compartido con vocabulario potencialmente ambiguo (dimensiones, ejes, scope) puede tener un glosario canónico aquí**. El Glosario Canónico Atlas es la 1ª instancia. Si emerge un 2º glosario (ej. PanelGrid, SignalLab), considerar elevación a anexo o fichero hermano dedicado.

### 4bis.1 · Glosario Canónico Atlas (1ª instancia · cristalizado s133)

Glosario inequívoco para el lego Atlas (`src/components/atlas/`) y sus consumidores. Origen: rename P13 en s133 descubrió que el modelo `cells[row][col]` con `row`=strip vertical contradecía CSS Grid + HTML Table + percepción visual humana. Cita Manuel s133: *"tenemos problemas serios de conceptos con los nombres de las columnas y las filas"*.

#### §1 · Términos nucleares (P13 candidato a postulado)

**columna (column)**
- Strip vertical visible en pantalla, apilando contenido de arriba a abajo.
- 1ª dimensión del array de datos: `cells[col][row]`
- En código: variables `col`, `colIdx`, `currentColIdx`, `colCount`, `colsRef`, `colObs`
- En CSS: clase `.atlas-col`
- En la matriz visual del Atlas: 5 columnas (A, B, C, D, E en Sim1/Sim3)
- Identificador barquito: letra (A..Z)
- Gesto del usuario: ←→ navega entre columnas

**fila (row)**
- Banda horizontal visible en pantalla, apilando contenido de izquierda a derecha (aunque en el Atlas no se ven varias filas a la vez: una fila está visible a la vez dentro de la columna activa, porque cada celda ocupa el 100% de la altura).
- 2ª dimensión del array: `cells[col][row]`
- En código: `row`, `rowIdx`, `currentRowIdx`, `rowCount`
- En la matriz visual del Atlas: 8 filas (1..8 en Sim1/Sim3)
- Identificador barquito: número (1..N)
- Gesto del usuario: ↑↓ navega entre filas

**celda (cell)**
- Unidad individual identificada inequívocamente por `{col, row}`
- Ocupa 100% del viewport del Atlas (modelo "Stories/Reels")
- Clase CSS: `.atlas-cell`
- ID humano: chip barquito "letra-número" (ej. A-1, B-4)

#### §2 · Contradicciones known-resolved

Estos casos podrían confundir a quien lea el código. Están documentados como contradicciones intencionalmente NO resueltas porque el coste de resolverlas excede el coste de documentarlas:

**CSS Flexbox vocabulary** (sin migración planeada):
- `.atlas { flex-direction: row }` apila columnas horizontalmente. OJO: "row" en flex-direction es vocabulario CSS, NO se refiere a una "fila P13". Es la dirección del eje principal del flexbox.
- `.atlas-col { flex-direction: column }` apila filas verticalmente. OJO: "column" como flex-direction = dirección vertical del eje principal. NO se refiere a una "columna P13".
- Estos nombres son inevitables porque vienen del estándar CSS. Vivir con ellos. Mentalmente: "flex-direction X" = dirección del eje, NO el tipo del elemento.

**Sim2 legacy variables** (no migrado):
- En Sim2 (`src/pages/Sim2/Sim2.tsx`), las variables `row` y `currentItem` se refieren a lo que en P13 sería una columna. Y `tool` o `currentTool` a lo que sería una fila.
- Razón: Sim2 nació antes de P13. El rename no se ha hecho.
- Decisión: no migrar Sim2 hoy. Documentado en handoff s133.
- Si tocas Sim2 y necesitas P13 mental, traduce mentalmente: `Sim2.row ≡ P13.col` · `Sim2.tool ≡ P13.row`

#### §3 · Términos BANNED en código del lego

Las siguientes palabras están **prohibidas** en el código del lego Atlas porque crean ambigüedad o falsos paralelos:

- **"horizontal" / "vertical"** como nombres de variables · ambiguo (¿el eje del scroll? ¿la dimensión del array? ¿la orientación del flex?). Usa `col`/`row` explícitamente.
- **"x" / "y"** como nombres de variables del modelo · confundible con pixel coordinates. Las únicas variables `x`/`y` permitidas son las que se refieren a píxeles del DOM (ej: `scrollLeft`, `scrollTop` ya son explícitos por nombre, no necesitan alias).
- **"index" sin prefijo** (`idx` solo, `i` solo) · ambiguo. Usar `colIdx`, `rowIdx`, `cellIdx`, `cardIdx`.
- **"row" en sentido visual horizontal-banda** (que es lo "natural") cuando el código se refiere realmente a una columna del modelo · en código del LEGO siempre P13. Documentar excepciones de CSS Flexbox por separado (§2).

#### §4 · Reglas R1-R7 de scope y ownership

**R1 · Una clave de localStorage tiene UN owner único**
- El owner declara el formato esperado
- El owner valida al leer (loadCoord verifica typeof number etc.)
- Otros sistemas NO pueden tocar la clave sin pasar por el owner
- Ejemplo: `sim1_atlas_coord` es del Atlas. PanelGrid no la toca.

**R2 · Prefijos no-solapados para sistemas concurrentes**
- Atlas usa prefijo `{storageKey}_atlas_*`
- PanelGrid usa prefijo `sim1-atlas-{cellId}_grid_*`
- Si añades un sistema nuevo, declarar su prefijo aquí.

**R3 · Invalidación cruzada explícita** [PENDIENTE · bug A1 vacío T-S133-N1]
- Si el Atlas cambia de celda activa, NO toca el localStorage del PanelGrid de la celda anterior. Es state legítimamente persistente.
- Pero si se descubre estado corrupto del PanelGrid al activar una celda, el PanelGridProvider debe reseterear al preset default de esa celda, no quedarse en estado intermedio.
- Esta regla queda PENDIENTE de aplicar (es el bug A1 vacío · candidato a frente principal s134).

**R4 · State interno de closures NO se expone como ref externa**
- Variables `let` dentro de un `useEffect` o `useCallback` son del closure · no escapan al exterior
- Si algo de fuera necesita ese state, se exporta vía callback/prop · nunca via ref mutada desde dentro
- Ejemplo: `currentColIdx`/`currentRowIdx` del IO son privados del effect. Solo se notifica vía `updateCoord(coord)`.

**R5 · Refs DOM con elementos potencialmente null**
- `colsRef.current` es `Array<HTMLDivElement | null>` técnicamente
- Siempre filtrar antes de iterar: `cols.filter(c => c != null)`
- Mismo para `cells.forEach`: comprobar `cell != null` si hay posibilidad de array sparse

**R6 · IntersectionObserver puede disparar con valores residuales**
- En mount inicial, el browser puede restaurar scroll o scroll-snap puede desplazar antes de que el JS lo controle
- Solución: flag `isInitialMountRef` (s133 · 800ms) bloquea updates del IO durante los primeros momentos tras mount

**R7 · Service Worker puede servir código viejo**
- Cuando el banner "New content available" aparece, el SW está sirviendo el bundle anterior
- Pulsar el RELOAD del banner es necesario para cargar JS nuevo
- Solo entonces los cambios de código son visibles

#### §5 · Convenciones de nombres en código

**Tipos exportados llevan prefijo del sistema**:
- ✓ `AtlasCoord`, `AtlasCell`, `AtlasFavorite`
- ✓ `Sim1AtlasCellData`, `Sim3Coord` (si Sim3 tiene coord propia)
- ✓ `PanelGridSlot`, `PanelGridPreset`

**Campos de coordenadas SIN prefijo** (los identifica el tipo):
- ✓ `AtlasCoord { col: number; row: number }`
- ✗ `AtlasCoord { aCol: number; aRow: number }` ← redundante
- ✗ `AtlasCoord { x: number; y: number }` ← banned (ver §3)

**Composición cuando coexisten múltiples sistemas**:
- ✓ `state = { atlas: { col, row }, sim3: { col, row } }`
- ✗ `state = { aCol, aRow, s3Col, s3Row }` ← antipattern

**CSS classes y data attrs SÍ prefijan** (espacio global del DOM):
- ✓ `.atlas-cell`, `.atlas-col`, `.pg-row`, `data-atlas-active`

**LocalStorage keys SÍ prefijan** (espacio global del navegador):
- ✓ `sim1_atlas_coord`, `sim1_atlas_favs`, `sim3_atlas_coord`
- ✓ `sim1-atlas-{cellId}_grid_active`, `_grid_custom`

**Iteradores**:
- ✓ `colIdx`, `rowIdx`, `cellIdx`, `cardIdx`
- ✗ `i`, `j`, `idx` (vagos en código del lego)

**Decisión Manuel literal (s133)**: *"prefijos en tipos/CSS/storage · campos limpios · composición para multi-sistema"*

### 4bis.2 · Postulados candidatos articulados (s133 · pendientes integración formal LRU_FUNDAMENTOS)

Los siguientes postulados se articularon en s133 durante la cristalización del Glosario Canónico Atlas y quedan **pendientes de integración formal en `LRU_FUNDAMENTOS`** (sesión del proyecto madre LRU Auditoría):

**P13 · Primacía visual del nombrado** (candidato)
- El código que el usuario percibe visualmente se nombra según la percepción visual humana, no según convenciones técnicas de subsistemas que la contradigan.
- Corolarios: cuando un subsistema técnico (CSS Flexbox, matemática matricial, mockups previos, convenciones legacy de otros componentes) usa "row" o "column" con un significado contrario al visual, el código nuevo se alinea con la convención visual.
- Las contradicciones inevitables del subsistema se documentan explícitamente como "known-resolved" (ver §2 arriba).
- 1ª aplicación canónica: rename del lego Atlas s133.

**P15 · Dos paradigmas complementarios de presentación de contenido** (candidato)
- *"Col4 = explorar catálogo · Atlas = sumergirse en contenido. Un mismo dato puede ser una card en Col4 cuando exploras y una pantalla completa en el Atlas cuando profundizas. Cada paradigma cumple una función distinta · son complementarios, no excluyentes. El modelo de datos es uno · las proyecciones de presentación son varias."* (voz Manuel literal · s133)
- Corolarios: una sola fuente de datos (ej. Firebase / Datos01) · múltiples UIs proyectan ese modelo según el modo cognitivo del usuario (explorador vs inmersivo) · transiciones fluidas entre modos son objetivo de diseño · ambos paradigmas son ciudadanos de primer orden del proyecto reutilizables más allá de Sim1/Col4.
- Materialización pendiente: Fase H · Atlas + Datos01 (frente principal s134).

**Nota sobre P14**: reservado para futura cristalización de "Ownership explícito de scope" si emerge una 2ª aplicación de las reglas R1-R7 (§4 arriba) en otro lego.

## 5 · PowerShell y despliegue

Los scripts de despliegue obedecen reglas inamovibles, nacidas de iteraciones pasadas con errores de encoding y problemas operativos detectados a lo largo de las sesiones:

### 5.1 · Convenciones de escritura del PS1 (consolidadas pre-s90)

* **Solo ASCII**. Nada de Unicode, acentos, emojis, caracteres especiales. Los mensajes de log y los comentarios también.
* **Sin paréntesis literales dentro de strings con comillas dobles**. Si el string los contiene, se usan comillas simples o se escapan.
* **`Join-Path` con exactamente dos argumentos**. Para tres o más niveles se anida: `Join-Path (Join-Path $a $b) $c`.
* **Sin `backtick-n`** para saltos de línea en strings — causa problemas de encoding en algunas consolas. Se usa cadena literal multi-línea o concatenación.
* **Tres fases estrictas**: backup del estado actual a `D:\lru-backups\`, copia de nuevos ficheros a `C:\react\pwa6\`, verificación SHA256 local en destino contra MANIFEST.
* **El backup antes de desplegar es obligatorio**. Sin excepciones.

### 5.2 · Disciplinas de cierre formalizadas en s90 (T-S90-A2/A3/A4/A5)

Cuatro disciplinas operativas adicionales emergidas del análisis crítico del propio cierre s90 al detectar problemas reales recurrentes en cierres anteriores. Cerradas por materialización en la propia sesión que las articula. Aplican a TODOS los paquetes y PS1 del proyecto a partir de s90.

**T-S90-A2 · Verificación local únicamente en PS1 de deploy**.
El PS1 de deploy verifica que los ficheros copiados al repo local coinciden con el MANIFEST byte a byte. **No verifica nada contra URL del servidor web**. La razón: fetchear contra `boxdin.com/pwa6/docs-app/v1/doc/` (caso del PS1 inicial s90) introduce 5 fuentes de error (encoding HTTP, gzip transparente, BOM, CDN ignorando cache-buster, saltos de línea normalizados) que **no son problema del deploy local**. Mezclar ambas verificaciones confunde diagnóstico: STALE en server podía venir de no-subida, problema de subida, problema de codificación HTTP. La subida al hosting es operación posterior independiente y su verificación, si se hiciera, vive en script aparte.

**T-S90-A3 · Entrega monolítica del cierre**.
El cierre de sesión se entrega como **un único artefacto contenedor**, el ZIP. Todo lo necesario para ejecutar el cierre vive dentro: documentos, MANIFEST, PS1, scripts auxiliares si aplican. **No se entregan ficheros sueltos junto al ZIP**. El mensaje de entrega menciona solo el ZIP, no PS1 sueltos ni adendas. El usuario descomprime una sola vez y todo está donde lo espera el PS1.

**T-S90-A4 · Estructura plana-por-categoría dentro del ZIP**.
El ZIP **no replica el árbol del repo**. Categoriza con un nivel: `doc/` para documentos, `src/` para código, otros si fueran necesarios. MANIFEST y PS1 viven en la raíz del ZIP descomprimido junto a las carpetas-categoría. La columna `DESTINATION_REL_PATH` del MANIFEST es la **única fuente de verdad** sobre dónde aterriza cada fichero al ejecutar el deploy. Inspeccionar el ZIP debe ser trivial: dos carpetas máximo (categoría + raíz). El MANIFEST tiene además columna `SOURCE_IN_ZIP` con el path relativo dentro del ZIP, separada de `DESTINATION_REL_PATH`.

**T-S90-A5 · Empaquetado sin envolvente redundante**.
El ZIP **no contiene una carpeta envolvente con su propio nombre**. La carpeta única la genera el comando de descompresión apuntando a destino `Downloads\<nombre-zip-sin-extensión>\`. Comando de empaquetado correcto: desde dentro del staging directory ejecutar `zip -r ../<nombre-zip>.zip ./*` (no `zip -r <nombre-zip>.zip <staging-dir>/`). Esto evita la doble carpeta `Downloads/lru-sN-close/lru-sN-close/...` que requería doble click para llegar al contenido.

### 5.3 · Estructura canónica del MANIFEST a partir de s90

El MANIFEST es **donde vive la inteligencia del proceso**. El PS1 itera sobre él y aplica operaciones. Cuanto más cargado el MANIFEST, más simple el PS1 y más robusto el cierre.

Estructura mínima de cabecera (6 líneas):

```
LRU Platform - Session sNN - <tipo> <vN>
Generated: YYYY-MM-DD GMT - Manuel and Claude Opus 4.7
Package: lru-sNN-<tipo>-vN
Repo root expected: C:\react\pwa6
Backup root: D:\lru-backups
Operations: N - Total bytes: M
```

Tabla de operaciones con cabecera explícita:

```
OPERATION  SOURCE_IN_ZIP                 DESTINATION_REL_PATH                       SIZE   SHA256
COPY       doc/<fichero>                 public\docs-app\v1\doc\<fichero>           NNNNN  HEX
COPY       src/<fichero>                 src\realm\aviation\<fichero>               NNNNN  HEX
```

Columnas alineadas para lectura humana de un vistazo. Separador espacios. El PS1 parsea la tabla. La columna `OPERATION` es extensible (COPY · DELETE · MOVE · futuras).

### 5.4 · Sección obligatoria del handoff: sincronización del Proyecto de Claude (T-S90-A6)

**T-S90-A6 · Lista explícita de ficheros a subir al Proyecto en cada handoff** (cerrada por materialización en s90):

Todo handoff hacia la siguiente sesión debe incluir una sección dedicada (numerada al final del handoff) con la **lista exacta y operativa** de ficheros que el usuario debe subir al Proyecto de Claude para arrancar la sesión siguiente con el anillo 0 sincronizado.

La sección distingue **4 estados posibles** por fichero:

1. **Subir** (modificados o nuevos en la sesión que cierra) · referencia al paquete del cierre como origen.
2. **Heredar** (sin cambios en la sesión que cierra · ya en el Proyecto desde antes) · listado explícito.
3. **Retirar** (anclas anteriores que el cierre actual ha sustituido) · listado explícito.
4. **No subir** (ficheros del cierre que viven solo en boxdin · `index.md`, `index.html`) · listado explícito.

Esta disciplina cierra una fricción operativa real recurrente: cuando el usuario pregunta al final de una sesión qué subir al Proyecto, si la información no está en el handoff hay que reconstruirla mentalmente con riesgo de error. La sección §7 del handoff la deja consolidada y revisable en frío. Detalle completo del patrón en cada handoff a partir de s90 → ver §7 de cualquier handoff vigente.

### Regla permanente sobre Docker

**Nunca Docker Engine en WSL2**. Siempre Docker Desktop. Esta regla viene de problemas de red persistentes y es innegociable.

### 5.5 · Tests automatizados del schema (formalizado en s92 al cerrar T-S90-A1)

**Pivote sustantivo de la disciplina del proyecto**: hasta s90, el paso 6 del ciclo destilado→código (§3) describía los tests como *"artefacto histórico de la sesión — no se integra al repo de producción por defecto, pero se preserva en el paquete de cierre como evidencia de cobertura"*. Empíricamente esta disciplina dejó el schema sin red de seguridad acumulando 7 instancias del ciclo (s56, s77, s78, s79, s80, s83, s86, s90) sin tests vivos en el repo, riesgo de regresión silenciosa creciente con cada Tanda. **T-S90-A1 cerró este vacío en s92 estableciendo tests automatizados como pieza permanente del repo**.

**Runner canónico**: **Vitest** (ya presente en `devDependencies` desde antes de s90 con `vitest@^1.1.3` · alineado con el bundler Vite del proyecto · separado de Playwright que cubre e2e). El comando es `npm run test:unit` (script ya existente · 0 cambios al `package.json`).

**Convención de path**: `src/**/*.test.ts` · ficheros de test colocados **junto al fichero que testean** (no en carpeta `tests/` separada). Idiomático Vitest. Permite que el test viaje con el módulo en refactors y que los reviewers vean cobertura sin saltar de árbol.

**Configuración mínima** en `vitest.config.ts` raíz del repo:

* `include: ['src/**/*.test.ts']` · solo unit tests bajo `src/`
* `exclude: ['node_modules/**', 'dist/**', 'e2e/**', '.next/**']` · excluye explícitamente el árbol Playwright para que `npm run test:unit` no toque e2e
* `environment: 'node'` · los schemas Zod son puros, no necesitan jsdom
* `globals: false` · imports explícitos `describe/it/expect` (estilo Vitest 1.x · preferido sobre globals tipo Jest para que el código sea autocontenido)

**Cobertura inicial s92** sobre los 4 ficheros del schema · 94 tests pasando:

* `src/realm/validators.test.ts` — 19 tests · superRefines del shape base (sensorIds únicos, disjunción sensor↔actuator, feedbackSensorId, taxonomy refs, profile.extendsRealm, range refine) + ScenarioDef timeline ordenado.
* `src/realm/aviation/ata.test.ts` — 14 tests · 5 superRefines de `ATAChapterDef` + parse del catálogo entero (18 chapters · 4ª instancia del sub-patrón "validación empírica del schema con realm regenerado") + helper `getATAChapter`.
* `src/realm/aviation/roles.test.ts` — 28 tests · 1 superRefine de `AircraftRatingDef` + helpers `findDuplicateIds`/`findInvalidRefs` + 8 tipos del bloque humano + constantes `ROLE_KIND_CANONICAL`/`ROLE_KIND_RESERVED`.
* `src/realm/aviation/manifest.test.ts` — 33 tests · 13 validaciones cruzadas del manifest aviation con fixtures inline (porque a320 aún no llena las 7 colecciones aviation · T-S84-A4 llenado progresivo) + `parseAviationRealm(a320Realm)` (5ª instancia del sub-patrón "validación empírica") con cardinalidades verificadas (19 entities · 10 actuators · 4 sensorFaults · 6 actuatorFaults · 2 scenarios · 2 profiles).

**Disciplina de escritura de tests** consolidada en s92:

1. **Lectura del shape exacto antes de escribir fixtures**. Los fixtures inventados producen tests que pasan o fallan por razones equivocadas. Verificación obligatoria con `grep -n "Schema = z\\.object" <fichero>` y lectura del shape antes de redactar.
2. **Helpers de fixture por tipo** colapsando lo común (ej. `entity(sensorId)`, `role(id, overrides)`) · permite tests legibles y fáciles de extender.
3. **Happy path + error path emparejados** por superRefine. Un test que solo verifica el rechazo no demuestra que el caso válido sigue válido.
4. **Aserciones sobre el mensaje de error** con regex laxo. No acoplar a la redacción exacta del mensaje · solo a las palabras-ancla. Resilencia a refinamientos de copy.
5. **Sub-patrón "validación empírica del schema con realm regenerado"** (formalizado §3 sub-patrón) sigue plenamente operativo en este apartado: los tests se ejercitan contra `ATA_CATALOG` y `a320Realm` reales, no solo contra fixtures.

**Relación con paso 6 del ciclo destilado→código** (§3): el paso 6 ya no produce *"test de smoke con grupos mínimos preservado en el ZIP"* como artefacto histórico. **A partir de s92, el paso 6 produce tests vivos en `src/**/*.test.ts` que viajan con el código**. Cada Tanda futura del ciclo (Tandas 2-4 de T-S84-A8 entre otras) **debe extender la batería**, no escribir tests aparte que se pierdan al cierre.

**Hallazgo positivo · 0 cambios al `package.json`**: el repo ya tenía `vitest@^1.1.3` en devDependencies y el script `"test:unit": "vitest"` desde sesión anterior. T-S90-A1 reveló que la infraestructura existía pero nadie la había ejercitado. La materialización de s92 consistió en escribir tests, no en configurar runner.

---

## 5bis · Disciplina sobre el alcance del proyecto — un proyecto a la vez

La sesión s74 articuló explícitamente una disciplina fundacional sobre cómo se decide **qué pertenece al proyecto presente y qué no**. La disciplina explica retroactivamente decisiones ya tomadas (la eliminación del horizonte LRM del núcleo en s70) y da criterio para decisiones futuras sobre horizontes, extensiones y proyectos sucesores.

### 5bis.1 · La regla articulada

> *"Quise eliminar el concepto LRM porque es nombre de proyecto, y 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."* — Manuel, s74

**Los proyectos van de uno en uno.** Es principio, no preferencia estilística.

### 5bis.2 · Por qué es disciplina fundacional

El proyecto presente y el proyecto futuro **compiten por el mismo recurso escaso**: la atención sostenida de quien lo construye. Si el futuro entra en la conversación del presente como presente, el presente no se construye. La razón no es pereza ni falta de ambición — es economía cognitiva del construir: los cimientos requieren atención entera, y la atención entera no es divisible.

Por eso horizontes como el LRM (la reconstrucción del proyecto sobre FPGA, articulada por Manuel en s69 y s74), aunque coherentes con todo lo articulado y valiosos como visión, **no pueden vivir en el núcleo del proyecto actual**. Su gravedad conceptual desplazaría la atención necesaria para los cimientos del presente.

### 5bis.3 · Secuenciación, no abandono

La disciplina no descarta lo que queda fuera. Manuel añade:

> *"Cuando tengamos este abordaremos el siguiente."* — Manuel, s74

El proyecto sucesor vendrá, pero cuando venga será **otro proyecto con su propia disciplina**, su propio arranque y su propio núcleo — no continuación difusa del actual. La secuenciación es legítima; la superposición no.

### 5bis.4 · Dónde vive lo que no pertenece al núcleo

La disciplina no es "no pensar en el futuro". Es "no mezclarlo con el presente en el mismo sitio". El sistema documental del proyecto provee el lugar correcto para cada cosa:

- **Núcleo (anillo 1)** — solo el proyecto presente. Lo que el mapa del proyecto actual necesita para ser operativo.
- **Destilados (anillo 2)** — pueden preservar articulaciones sobre horizontes sucesores con densidad completa, con regla de disputa activa sobre el material que contienen, pero **sin cruzar al núcleo** hasta que el proyecto presente esté construido.
- **Archivo (anillo 3)** — sesiones pasadas donde el material emergió, preservadas como memoria histórica.

Un ejemplo vivo de esta disciplina operando: el horizonte LRM está preservado con densidad completa en `lru_voz_fundacional_s74.md §6` y en `lru_postulados_6_7_8_9_s69.md §5.3`, ambos en anillo 2. Ninguna mención cruza al núcleo por diseño.

### 5bis.5 · Implicación operativa para sesiones futuras

Cuando una sesión articule un horizonte, extensión, proyecto sucesor o visión que trascienda el alcance actual:

1. **Preservar con densidad completa** en destilado anillo 2 — citas literales, contexto, razones.
2. **No integrar al núcleo** aunque sea coherente con lo ya articulado.
3. **Nombrar explícitamente la decisión** de no cruzar la frontera y documentarla como tal (patrón s70 con el LRM).
4. **Dejar trazabilidad** de dónde vive el material preservado para recuperación futura.

### 5bis.6 · Relación con la regla operativa s70

Esta disciplina es el **fundamento** de la regla operativa articulada en s70: *"el destilado propone, el núcleo dispone, Manuel arbitra qué cruza la frontera"*. La regla operativa existe porque esta disciplina existe. El arbitraje de Manuel sobre qué cruza la frontera aplica esta disciplina caso por caso: material sobre el proyecto presente puede cruzar si aporta; material sobre proyectos sucesores no cruza aunque sea excelente, por disciplina del alcance.

### 5bis.7 · Relación con el método de trabajo del proyecto

Esta disciplina del alcance no es una regla impuesta externamente — es **lectura consistente con el modelo del círculo incremental** (§7 patrón 7 y `LRU_MAPA` sobre la dinámica del proyecto). El círculo gira con el material del proyecto presente, acumulando densidad. Cada vuelta añade capa al proyecto actual, no al proyecto siguiente. La disciplina "un proyecto a la vez" es la forma concreta en que el círculo protege su propia coherencia.

---

## 6 · Disciplina ética sobre material de casos reales

Cuando el proyecto trabaja con accidentes, incidentes o eventos reales documentados (ciudadanos de primera clase del modelo según `LRU_FUNDAMENTOS §10`), aplica disciplina ética explícita. Esta sección codifica esa disciplina como regla operativa del proyecto, no como convención implícita ni preferencia de estilo.

### 6.1 · Frontera fundamental — caso con nombre se analiza, situación técnica se juega

**El caso real documentado con nombre propio se analiza; la clase de situación técnica que lo ilustra se juega.**

Operativamente:

* **Casos con identidad histórica** (AF447, Tenerife, Sioux City, Asiana 214, Chernóbil, Bhopal, equivalentes en cualquier dominio) se consumen **solo en modos de análisis retrospectivo y simulación parcial en el punto de bifurcación con comparación histórica**. No hay retry con scoring sobre ellos. No hay competición. No hay trivialización lúdica. La banalización es inaceptable.
* **Las situaciones técnicas similares** se modelan como escenarios jugables plenamente, **desvinculadas de la identidad histórica**. El escenario jugable puede citar como fuente de inspiración al caso real con respeto, sin reclamar su identidad.

> *"El modo juego libre con retry y scoring se usa con mesura y solo cuando la distancia histórica y el tipo de caso lo permiten, no deben asociarse a accidentes con nombre propio solo a situaciones similares. De otra forma efectivamente es poco ético."* — Manuel, s69

### 6.2 · Reglas operativas derivadas

Cuando se trabaja con casos reales en cualquier sesión del proyecto:

* **Citar fuentes oficiales** — informes finales de la autoridad competente (NTSB, BEA, AAIB, JTSB, equivalentes nacionales; sus análogos en otros dominios). No especular sobre causas no establecidas en investigación oficial.
* **No atribuir responsabilidades individuales más allá de lo que el informe oficial estableció**. La investigación de accidentes en sectores maduros distingue causa próxima, condiciones latentes y fallos sistémicos — el material didáctico debe respetar esa distinción y no reducir a "culpa del piloto" lo que el informe articuló como cadena multi-nivel.
* **Tratar con la gravedad que corresponde** a eventos con víctimas. La voz del proyecto es respetuosa con la realidad material del caso, incluso cuando el material se usa para enseñar.
* **No usar nombres de personas implicadas más allá de los que el informe oficial nombra como tal** (típicamente solo roles: comandante, primer oficial, controlador). La pedagogía no exige identificación personal y la evita por defecto.

### 6.3 · Cómo se aplica en el modelo

El tipo `CaseStudyDef` del Realm v3 (trabajo arquitectural pendiente, T-S67-A1) debe poder declarar:

* **Modo de consumo permitido**: `analysis-only` (caso con identidad), `playable-with-attribution` (situación con cita de inspiración respetuosa), `fully-playable` (situación técnica desvinculada de identidad histórica).
* **Fuente oficial declarada** como referencia obligatoria del caso.
* **Lecciones extraídas** según el informe oficial, no según interpretaciones del autor del realm.

Hasta que el schema lo soporte de forma estructurada, la disciplina se ejecuta a mano por quien produce el material — instructor, autor de escenarios, autor de realm.

### 6.4 · Ámbito de aplicación

Esta disciplina aplica a **todo el proyecto**: producción de Realms y sus escenarios, redacción de documentación, generación de material didáctico, comunicación pública, documentación técnica que cite casos. No es disciplina solo del runtime — es disciplina del proyecto entero.

Se actualiza si emergen frontera nuevas (otros sectores con casos sensibles distintos del aeronáutico — sanidad, nuclear, defensa, infraestructura crítica — pueden requerir matices propios). La sección §6.1 establece la regla canónica; las subsecciones siguientes pueden ampliarse sin tocarla.

---

## 6bis · Disciplina honesta sobre configuraciones simuladas

Sección integrada en s91 desde el destilado fundacional `lru_postulado_10_diseno_como_innovacion_s84.md §1.3` como regla operativa derivada del **Postulado 10** (cristalizado s84, integrado al núcleo s91 como `LRU_FUNDAMENTOS §11quater`). Cerró T-S84-F1.

Mientras §6 establece disciplina ética sobre **material de casos reales** (cómo se trata lo que sucedió en el mundo), esta §6bis establece disciplina honesta sobre **configuraciones declaradas en el Realm que se apartan de la realidad regulatoria** (cómo se nombra lo que el diseñador del Realm añade al modelo del mundo). Son disciplinas paralelas sobre clases de material distintas. Ambas operan simultáneamente.

### 6bis.1 · La regla canónica

> **Cuando el corpus regulatorio no contempla una relación que el uso formativo o exploratorio necesita, el Realm la declara con un marcador estructural explícito y ninguna ambigüedad sobre su naturaleza. La plataforma no enmascara la diferencia entre lo real y lo innovado — la nombra.**

Esta es la regla canónica del Postulado 10 en su dimensión operativa. Aplicable a todo el proyecto: diseño del Realm, producción de schemas, documentación de tipos, comunicación con usuarios finales.

### 6bis.2 · El marcador estructural explícito como propiedad de diseño no negociable

Cualquier configuración que el Realm declare fuera de la realidad regulatoria debe ser identificable como tal **en el schema mismo**, no como nota humana en comentarios ni como convención implícita.

La primera materialización de este marcador en el schema (s84) es el campo literal `notEqualToReal: true` del tipo `SimulatedContextDef` — **literal type obligatorio en TypeScript** (no `boolean`). Un `SimulatedContextDef` que no declare este campo no se valida — el schema fuerza que el diseñador nombre explícitamente la diferencia entre lo real y lo innovado. La segunda materialización es el campo opcional `notEqualToReal?: true` de `OrganizationApprovalDef` para aprobaciones hipotéticas.

Cualquier futuro tipo del schema puede honrar esta disciplina con marcadores análogos cuando la innovación de diseño lo justifique. La regla aplica universalmente: **cuando se declare configuración fuera de la realidad regulatoria, marcador estructural explícito**.

### 6bis.3 · Tres planos de honra de la disciplina

La disciplina se ejecuta en tres planos del proyecto, cada uno con su forma concreta:

**Plano del schema.** Tipos del Realm que admiten configuraciones P10-marcadas incluyen marcadores explícitos en el schema mismo, validados por Zod. Sin marcador estructural, no hay configuración P10 válida. Coherente con el invariante del Realm "datos puros, no ejecuta": el marcador es declarativo, no comportamental.

**Plano del editor del Realm.** Cuando se construyan los editores del Realm (Realm editor, Viewmap editor, Scenario editor mencionados en `LRU_FUNDAMENTOS §3.4`), el editor debe **reconocer y mostrar visualmente los marcadores P10**. Un `SimulatedContextDef` en el editor aparece con badge visual identificando configuración simulada que no equivale a real. El usuario del editor (diseñador del Realm) tiene feedback visual de cuándo está dentro del marco regulatorio y cuándo está innovando. La transparencia es ergonomía de diseño: la plataforma no esconde la diferencia, la hace visible al diseñador en su herramienta de trabajo.

**Plano del usuario final.** Cuando se ejecuten sesiones formativas sobre Realms que contengan configuraciones P10-marcadas, los usuarios finales (alumnos, instructores, observadores) deben tener feedback claro. Un alumno que opera en un `SimulatedContextDef` debe saber que está aprendiendo en contexto simulado equivalente, no en contexto real legalmente certificado. La transparencia es ética operativa derivada del postulado.

### 6bis.4 · Disciplina activa para sesiones futuras de diseño

Cualquier nuevo tipo del schema, cualquier nuevo campo, cualquier nueva relación se evalúa también bajo la pregunta:

> *"¿este diseño contempla configuraciones innovadoras además de las reales? Si la respuesta es no por defecto, ¿se nombra explícitamente? Si la respuesta es sí, ¿se proporciona marcador estructural?"*

Esta pregunta es entrada obligatoria al diseño de tipos del schema. No invade el diseño normal — lo amplía con un eje adicional de evaluación que evita perpetuar la ambigüedad implícita entre lo real y lo innovado.

### 6bis.5 · Relación con §6 (disciplina ética sobre casos reales) y con §5bis (un proyecto a la vez)

§6 y §6bis son **dos disciplinas distintas sobre dos clases de material distintas** que pueden coexistir en el mismo Realm sin solaparse:

- §6 trata sobre **material de casos reales documentados** — accidentes, incidentes, situaciones que sucedieron en el mundo real y que entran al Realm como `CaseStudyDef` (tipo previsto en T-S67-A1). Disciplina: caso con nombre se analiza; situación técnica se juega.
- §6bis trata sobre **configuraciones declaradas en el Realm que se apartan de la realidad regulatoria** — contextos formativos, aprobaciones hipotéticas, relaciones organizativas innovadoras. Disciplina: marcador estructural explícito, sin ambigüedad sobre la naturaleza.

Un mismo Realm puede contener casos reales bajo §6 (un accidente como `CaseStudyDef`) y configuraciones innovadas bajo §6bis (un contexto formativo Part-145 simulado en una organización Part-147). Ambos materiales tienen disciplinas propias que no se mezclan.

§6bis es además coherente con `LRU_METODO §5bis` *"un proyecto a la vez"* (cristalizado s74, integrado s76) y con el patrón complementario *"exploración vs implementación separadas"* (consolidado s81): la disciplina de hilos transversales que P10 articula en su dimensión metodológica (`LRU_FUNDAMENTOS §11quater.4`) es ejercicio del mismo principio — el diseñador tiene libertad de ver y nombrar estructuras transversales que la mirada por dominio no captura, y libertad de tratarlas con rigor cuando maduran sin forzar resolución prematura.

### 6bis.6 · Ámbito de aplicación

Esta disciplina aplica a **todo el proyecto** desde el momento de su integración s91: schemas existentes ya materializados (`SimulatedContextDef` de Tanda 2 de T-S84-A8 será la primera materialización en código del marcador `notEqualToReal: true` literal), schemas futuros (cualquier tipo nuevo del Realm v3 evaluado bajo la pregunta de §6bis.4), editores del Realm cuando se construyan, comunicación con usuarios finales en sesiones formativas. No es disciplina solo del schema — es disciplina del proyecto entero en su dimensión de diseño.

---

## 6ter · Disciplina evolutiva del diseño estructural

Sección integrada en s99 desde el destilado fundacional `lru_estructura_sectorial_s98.md §1.4` como regla operativa derivada del **Postulado 11** (cristalizado s98, integrado al núcleo s99 como `LRU_FUNDAMENTOS §11quinquies`). Cerró T-S97-F1.

Mientras §6bis establece disciplina honesta sobre **configuraciones declaradas en el Realm que se apartan de la realidad regulatoria** (cómo se nombra lo que el diseñador del Realm añade al modelo del mundo · derivada de P10), esta §6ter establece disciplina evolutiva sobre **la forma estructural que el schema del realm específico tiene** (cómo se elige conscientemente entre estructura plana y estructura jerárquica · derivada de P11). Son disciplinas paralelas sobre dos clases de decisiones distintas. Ambas operan simultáneamente.

### 6ter.1 · La regla canónica

> **Cuando el diseño estructural de un realm específico abra alternativa entre estructura plana visible y estructura jerárquica anticipatoria, el realm declara la estructura plana hasta que necesidad material concreta dispare reestructuración. La complejidad estructural se gana, no se anticipa.**

Esta es la regla canónica del Postulado 11 en su dimensión operativa. Aplicable a todo el diseño del schema del realm específico: tipos nuevos, campos nuevos, relaciones entre tipos, abstracciones candidatas.

### 6ter.2 · La legibilidad presente como propiedad de diseño no negociable

Cualquier abstracción que el realm específico declare debe estar justificada por **al menos un caso material de uso**, no por anticipación a casos futuros. La legibilidad presente — la capacidad de un Claude o humano nuevo de leer la estructura del schema sin descender por jerarquías especulativas — es propiedad de diseño no negociable.

La primera materialización empírica de esta regla en el schema (s97) es la decisión de declarar `AviationProfile` y `AircraftProfile` como tipos hermanos planos en lugar de unificarlos bajo `SectorProfile` abstracto. La abstracción `SectorProfile` no se hizo porque solo existía un sector (aviation) materializado · sin material de un segundo sector que validara qué es genuinamente común, abstraer habría sido especulación. La estructura plana es legible · se reestructurará cuando necesidad real lo dispare.

Cualquier futuro tipo del schema puede honrar esta disciplina con decisiones análogas. La regla aplica universalmente: **cuando se proponga jerarquía o abstracción, exigir disparador real concreto · si no lo hay, declarar plano**.

### 6ter.3 · Tres planos de honra de la disciplina

La disciplina se ejecuta en tres planos del proyecto, cada uno con su forma concreta:

**Plano del schema.** Tipos del realm específico se estructuran como hermanos planos por defecto. Las jerarquías se declaran solo cuando hay disparador material concreto (caso de uso real, no anticipación). Coherente con el invariante del Realm "datos puros, no ejecuta": la estructura plana es declarativa y legible directamente.

**Plano del editor del Realm.** Cuando se construyan los editores del Realm, el editor debe **mostrar la estructura sectorial visualmente como hermanos planos** (no como árboles jerárquicos por defecto). Un sector con singleton+plurales se ve como dos zonas hermanas en el editor, no como árbol con la singleton en raíz y los plurales como hijos. La transparencia es ergonomía de diseño: la estructura del schema se hace visible al diseñador en su herramienta de trabajo.

**Plano del refactor futuro.** Cuando llegue el segundo sector y emerja necesidad genuina de abstracción, la separación estructural explícita entre singleton y plurales facilita el refactor: lo que está en un singleton del sector es candidato a campo de la abstracción · lo que está en plurales del sector es candidato a subtipo específico. La disciplina presente es ergonomía del refactor futuro.

### 6ter.4 · Cuatro preguntas operativas para sesiones futuras de diseño

Cualquier nuevo sector que se materialice, cualquier nuevo tipo del schema dentro de un realm específico, cualquier decisión sobre forma estructural se evalúa bajo cuatro preguntas:

1. **¿Qué se comparte entre las instancias de este sector?** Lo compartido es candidato a singleton del sector.
2. **¿Qué diverge entre las instancias de este sector?** Lo divergente es candidato a plural.
3. **¿La estructura propuesta es legible directamente sin descender por jerarquías?** Si requiere descender más de un nivel para ver el material, replantear como plana o nombrar explícitamente la jerarquía como decisión consciente con disparador real.
4. **¿La estructura propuesta tiene anotación de frontera explícita para refactor futuro?** Si mezcla en un mismo tipo material que probablemente divergirá entre sectores, separar estructuralmente para que la frontera quede nombrada en código.

Estas cuatro preguntas son entrada obligatoria al diseño estructural de tipos del realm específico. No invaden el diseño normal — lo amplían con un eje adicional de evaluación que evita perpetuar abstracciones especulativas.

### 6ter.5 · Anti-anticipación como disciplina principal

P11 establece **anti-anticipación** como disciplina principal: no abstraer `SectorProfile` (ni cualquier otra abstracción análoga sobre realms específicos) hasta que existan al menos dos sectores materializados con suficiente material para identificar qué es genuinamente común vs qué es específico.

La señal de que la abstracción es legítima sería: dos sectores materializados con material denso · campos que aparecen idénticos por nombre y estructura en ambos profiles del sector · refactor de dos a tres sectores que resulta costoso por duplicación de campos comunes. Antes de esa señal, anticipar la abstracción viola P11.

Coherente con `LRU_METODO §5bis` *"un proyecto a la vez"* y con el patrón complementario *"exploración vs implementación separadas"*: la abstracción estructural también puede ser sesión dedicada cuando emerja necesidad real, no se fuerza en caliente sobre material de un solo sector.

### 6ter.6 · Relación con §6bis (P10) y con §6 (casos reales)

§6, §6bis y §6ter son **tres disciplinas distintas sobre tres clases de material distintas** que pueden coexistir en el mismo Realm sin solaparse:

- §6 trata sobre **material de casos reales documentados** (Postulado 7) — disciplina ética sobre cómo se trata lo que sucedió en el mundo real.
- §6bis trata sobre **configuraciones declaradas en el Realm que se apartan de la realidad regulatoria** (Postulado 10) — disciplina honesta sobre cómo se nombra lo que el diseñador añade al modelo del mundo.
- §6ter trata sobre **la forma estructural del schema del realm específico** (Postulado 11) — disciplina evolutiva sobre cómo se elige conscientemente entre estructura plana y jerárquica.

Las tres son disciplinas del diseñador del Realm en planos distintos: §6 sobre el material que entra al Realm desde el mundo real · §6bis sobre el contenido que el diseñador añade · §6ter sobre la forma que el schema del realm específico tiene. Las tres operan simultáneamente y se invocan según el plano de la decisión.

§6bis y §6ter son las dos disciplinas operativas del **par fundacional del diseñador** (P10 + P11). La libertad creadora de P10 sin la disciplina evolutiva de P11 sería caos creativo; la disciplina evolutiva de P11 sin la libertad creadora de P10 sería rigidez sin innovación. Juntas articulan **creatividad estructurada como disciplina del diseñador del Realm**.

### 6ter.7 · Ámbito de aplicación

Esta disciplina aplica a **todo el proyecto** desde el momento de su integración s99: schemas existentes ya materializados (el pattern singleton+plural de aviation s97 será la primera materialización en código del principio P11), schemas futuros de realms específicos (cualquier sector nuevo evaluado bajo las cuatro preguntas de §6ter.4), editores del Realm cuando se construyan, refactor futuro cuando llegue el segundo sector. No es disciplina solo del schema — es disciplina del proyecto entero en su dimensión de diseño estructural.

---

## 7 · Patrones humano-IA detectados

Lo que sigue son observaciones empíricas sobre cómo funciona bien la colaboración entre Manuel y Claude en este proyecto. No son reglas rígidas, son guía.

### Patrón 1 — Entender antes de codificar

El proyecto produce mejor código cuando la comprensión arquitectural está clara. Las sesiones donde se codifica sin entender acaban generando refactor posterior. Cuando emerge una duda arquitectural durante una sesión de implementación, **parar y articular** es inversión, no retraso.

### Patrón 2 — Sobrecarga en el último 30% de sesión

Las sesiones largas tienden a degradarse en calidad hacia el final. El contexto acumulado pesa. La solución es **cerrar antes de que la calidad baje**, aunque queden tareas. El handoff preserva lo pendiente para la sesión siguiente sin pérdida.

### Patrón 3 — La frase precisa es oro

Manuel tiende a articular ideas con frases compactas que capturan mucho. *"Los instrumentos de medida son los ojos virtuales..."*, *"Las señales son los ladrillos, las comunicaciones lo que los une, el sim es el que monitoriza"*, *"El Realm es el resto del mundo que le falta a cada actor"*. Cuando emerge una frase así, **debe quedar escrita en documento canónico** en poco tiempo. Si solo vive en el chat, se pierde.

**Sub-principio sobre transcripción de voz literal** (articulado en s98 por corrección de Manuel). Cuando se transcriba voz literal de Manuel para preservarla en destilado o canónico — citas s71, s84, s97 D1 u otras — la voz se preserva en **intención, vocabulario, ritmo y construcciones sintácticas reconocibles**. Los **errores tipográficos triviales** (ortografía, acentuación, puntuación obvia) **se corrigen** porque son ruido sin valor articulatorio. Las ideas prevalecen; la transcripción accidental no las representa. Coherente con principio s74 §5 *"los nombres como instrumentales · convenciones operativas, no sustantivos esenciales"* extendido aquí a la forma superficial de la transcripción: *forma superficial es instrumental · ideas son esenciales*. Aplicado retrospectivamente en s98 a las 3 citas s97 D1 preservadas en `lru_estructura_sectorial_s98.md §1.1` con 7 ediciones quirúrgicas tipo `str_replace` que pulieron errores ortográficos sin alterar voz.

### Patrón 4 — Cuestionar el handoff anterior

Al arranque de una sesión, conviene cuestionar críticamente el handoff que dejó la anterior. Cosas que parecían claras al cierre a veces revelan zonas grises al enfriarse. Releer el handoff con ojo crítico suele producir ajustes útiles en los primeros 10 minutos.

### Patrón 5 — La documentación previa es activo arquitectural

El proyecto produce documentación arquitectural densa cuando la prioriza (s7, s18, s22, s25, s32, s53, s55). Tiende a abandonarla cuando entra en fase de ejecución intensa. Los documentos viejos **no se releen espontáneamente** aunque sigan vigentes. El resultado: se reinventan ideas que ya existen documentadas.

Esto es caro. La contramedida es la disciplina del `LRU_MAPA` sección "Lo que no debes olvidar": cada sesión que lee documentación añade a esa lista las ideas que no deben perderse. Releer el MAPA al arrancar sesión nueva rompe el patrón de reinvención.

### Patrón 6 — Pushback constructivo

Cuando Claude tiene una observación honesta que contradice algo asumido, **debe decirla**. La colaboración no mejora si Claude acepta todo sin fricción. Manuel ha pedido explícitamente que Claude discrepe cuando tenga razones. El pushback debe ser específico (dónde veo el problema), constructivo (qué propongo) y humilde (puede que me equivoque).

### Patrón 7 — Cristalización periódica

El proyecto alterna ciclos de acumulación (sesiones normales donde se añade sin destilar) con momentos de cristalización (s53 refundó la arquitectura, s55 articuló los gaps, s57 articula las primitivas y reorganiza la documentación). Ambos ritmos son necesarios. **La señal de cristalización** es Manuel pidiendo "entender antes de codificar" o "no tenemos prisa". Cuando esa señal aparece, la sesión no debe forzar implementación.

---

## 7bis · Patrones operativos para diagnóstico de bugs (cristalizados en s133)

Sección integrada en s133 al sembrar 2 sub-patrones nuevos durante el diagnóstico del bug wheel ficticio en Sim3. Aplicables a cualquier componente con persistencia o con cambios de estado silenciosos. Esperan 2ª instancia para formalización como reglas canónicas.

### 7bis.1 · "Bug ficticio por persistencia residual de sesiones de test" (1ª instancia · s133)

**Patrón observado**: cuando un componente persiste estado en localStorage y los tests de sesión acumulan coords/configuraciones/estado, el siguiente arranque puede parecer "bug nuevo" cuando solo es continuidad correcta de la persistencia.

**Síntoma típico**: al recargar la página, el componente se comporta "extraño" desde el primer gesto del usuario. Lo que parece "salto múltiple", "respuesta incorrecta" o "estado roto" puede ser simplemente arrancar desde el último estado persistido (que es correcto pero distinto del esperado).

**Regla operativa propuesta**: al diagnosticar bugs en componentes con persistencia, **SIEMPRE el primer paso es script atomic de limpieza + test desde estado limpio**. Sin esto, se entra en loops de diagnóstico falso aplicando fixes que no arreglan nada (porque no hay nada que arreglar).

**Script atomic canónico** (adaptar prefijo según componente):
```javascript
Object.keys(localStorage).filter(k => k.startsWith('PREFIJO_')).forEach(k => localStorage.removeItem(k));
location.reload();
```

**Coste de no aplicarla en s133**: 5 turnos de iteración de diagnóstico falso aplicando Opción A (lastWheelT=Date.now()) y subiendo timeout isInitialMountRef de 800ms a 2000ms · ninguna arregló porque no había bug.

**Estado**: T-S133-N3 abierta · esperar 2ª instancia para formalización.

### 7bis.2 · "Instrumentación con stack traces revela origen de cambios silenciosos" (1ª instancia · s133)

**Patrón observado**: cuando una variable cambia sin causa aparente en logs convencionales, los stack traces capturados en el setter centralizado revelan el callstack exacto que disparó el cambio.

**Técnica**: en lugar de `console.log('value=', value)`, usar:
```javascript
console.log('[setterName]', {
  value,
  ts: Date.now(),
  stack: new Error().stack?.split('\n').slice(2, 7).join('\n'),
});
```

**Casos donde aplicar**:
- Race conditions entre handlers de eventos
- IO disparos asíncronos (IntersectionObserver, ResizeObserver, MutationObserver)
- Callbacks indirectos a través de refs externalizadas
- Refs mutadas desde múltiples sitios

**Aplicación en s133**: `[updateCoord]` con stack reveló que el cardObs IO post-wheel disparaba updates de rebote desde `IntersectionObserver.root (línea 261)` que no eran visibles en logs convencionales. Esto desbloqueó el diagnóstico que llevó a descubrir que el bug era ficticio (persistencia residual).

**Después de usar**: retirar los logs al cierre · son herramienta de diagnóstico, no código permanente.

**Estado**: T-S133-N4 abierta · esperar 2ª instancia para formalización.

### 7bis.3 · Relación con D-s111-1 (auditoría empírica antes de tocar)

Estos dos sub-patrones son **complementos operativos de D-s111-1**:
- D-s111-1 dice "audita antes de aplicar fix"
- 7bis.1 dice "limpia persistencia antes de auditar"
- 7bis.2 dice "instrumenta antes de inferir causa"

Aplicar 7bis.1 + 7bis.2 + D-s111-1 en este orden previene fixes especulativos en componentes con persistencia o con cambios de estado silenciosos. En s133, violar D-s111-1 sin aplicar primero 7bis.1+7bis.2 costó 5 turnos de iteración antes de descubrir que el bug era ficticio.

## 8 · Tensiones abiertas como disciplina

El proyecto ha aprendido a **nombrar tensiones sin resolverlas**. Esto es una forma de honestidad arquitectural: reconocer que hay decisiones pendientes, articularlas con claridad, y dejarlas visibles hasta que haya contexto para resolverlas bien.

Las tensiones abiertas viven en `LRU_MAPA.md` sección correspondiente. Cada una tiene:

* **Descripción** de la tensión (qué dice un lado vs otro, o qué está sin decidir)
* **Ubicación** (dónde aparece la discrepancia)
* **Resolución probable** (si se intuye una salida) o **decisión pendiente** (si no)
* **Sesión de detección**

Una tensión se cierra explícitamente cuando se resuelve: se actualiza la entrada a "resuelta en sesión sN — decisión: X".

### 8.1 · Los cuatro modos de cierre de tensión (formalizado en s99)

El proyecto cierra tensiones de cuatro modos distintos. Los tres primeros se ejercieron consistentemente desde sesiones tempranas; el cuarto se nombró formalmente en s99 al cerrar T-S97-F1 con la integración del Postulado 11, tras emerger durante el cierre retroactivo de T-S71-A2 (27 sesiones diferida) en s98 (`lru_estructura_sectorial_s98.md §9`).

**Modo 1 · Cierre por materialización.** La tensión se cierra cuando lo articulado en destilado o decisión arquitectural se ejecuta efectivamente en código. La materialización es prueba operativa de que la articulación era suficiente y resuelve la tensión. Sub-patrón firme tras 3+ instancias (T-S83-A1 + T-S92-T1 + T-S93-DIETA + otras). Es el modo más frecuente del proyecto.

**Modo 2 · Cierre por integración al núcleo.** La tensión se cierra cuando material fundacional (postulado, principio, disciplina) cruza del anillo 2 (destilado) al anillo 1 (núcleo vivo) tras sesión dedicada de integración. La integración es prueba conceptual de que el material es estable y merece autoridad canónica. 8 aplicaciones acumuladas: P1-P5 (s67→s68) · P6-P9 (s69→s70) · voz fundacional (s74→s76) · pluralidad de realms T-S85-F1 (s85→s89) · P10 T-S84-F1 (s84→s91) · P11 T-S97-F1 (s98→s99 · sexta cristalización fundacional).

**Modo 3 · Cierre negativo por ausencia de disparador.** La tensión se cierra cuando se constata que **no ha emergido en N sesiones** a pesar de haber estado registrada y vigilada. La ausencia de disparador es prueba de que la tensión no era operativa para el proyecto en su estado actual · cierre honesto en lugar de mantener registrada deuda inerte. 4 instancias en s93 (T-S69-A1, T-S69-A3, T-S74-A3, T-S74-A5).

**Modo 4 · Cierre tardío con reconocimiento de continuidad** (formalizado en s99). La tensión se cierra cuando una sesión presente articula cristalización fundacional o decisión arquitectural que **continúa o realiza material previamente diferido** durante muchas sesiones. La cristalización tardía es prueba de que el material precedente era estructural pero su articulación no había madurado · el cierre honra el recorrido del círculo incremental sin pérdida de la continuidad histórica. 1ª aplicación en s98-s99 con T-S71-A1/A2 cerradas tras 27 sesiones diferidas, materializadas tácitamente en T-S84-A8 entre s90 y s97, articuladas formalmente en `lru_estructura_sectorial_s98.md`.

### 8.2 · Anotación de continuidad para el modo 4

Cuando una sesión cierre tensión por modo 4, el cierre formal en `LRU_MAPA §4.3` incluye **anotación explícita de continuidad** con tres campos canónicos:

| Campo | Contenido |
|---|---|
| **Estado de cierre** | Variante específica del modo 4 según el caso concreto: *"cerrada por materialización tácita s{X}-s{Y} + cristalización tardía s{N}"* (cuando la materialización ocurrió en código durante el periodo y la cristalización articula el principio en s{N}) · *"cerrada por absorción superpuesta en T-{nuevo} + materialización s{X}-s{Y}"* (cuando otra tensión absorbió el material) · variantes según el modo concreto. |
| **Material precedente preservado** | Cita literal del destilado original o decisión que articuló la tensión, conservada para anclar el recorrido del círculo. La cita preserva voz reconocible (Patrón 3) sin re-articular el material. |
| **Sesión que reconoce el cierre** | s{N} con línea explícita de reconocimiento del recorrido completo: qué sesión articuló originalmente, qué sesiones materializaron tácitamente, qué sesión cristaliza retroactivamente, qué sesión cierra formalmente. |

El coste de esta anotación es ~10-15 líneas adicionales en `LRU_MAPA §4.3` por cierre tardío reconocido. Probablemente 1-2 sesiones por año del proyecto producen este tipo de cierre. El beneficio es estructural: cierre del agujero metodológico, memoria estructural del círculo incremental articulado en `lru_voz_fundacional_s74.md §9`, protección contra que sesiones futuras reabran ejes ya articulados sin saberlo, honestidad epistémica sobre la naturaleza no-lineal del desarrollo del proyecto.

### 8.3 · Disciplina activa para sesiones futuras

Cuando una sesión presente articule cristalización fundacional o decisión arquitectural sustancial, evaluar si **continúa o realiza material previamente diferido** registrado en `LRU_MAPA §4.2`. Si la respuesta es sí, ejecutar cierre formal por modo 4 con anotación de continuidad de los tres campos canónicos. La pregunta es entrada obligatoria al trabajo de cierre de tensiones cuando hay material previo en el corpus que el trabajo presente realiza sin haberlo nombrado explícitamente.

---

## 9 · Reglas sobre la memoria entre sesiones

### La memoria de Claude no es ficheros

Cada sesión de Claude empieza sin recuerdo activo de las anteriores. La memoria del proyecto vive en:

* Los cinco documentos del núcleo (estado actual)
* El handoff de la sesión anterior (puntero a pendientes)
* El tech debt vigente (deuda acumulada)
* Los destilados del anillo 2 (conocimiento profundo por tema)
* El archivo (trazabilidad histórica, consultable cuando hay motivo)
* **El Proyecto de Claude (anillo 0)**, donde viven las versiones que se adjuntan automáticamente al arrancar: `CLAUDE_ARRANQUE.md` + los 5 canónicos + tech debt vigente + handoff activo

**Cuando algo importante se articula en una sesión, debe quedar escrito antes de cerrar.** Si no, se pierde.

### Regla del núcleo

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, significa que los documentos del núcleo están incompletos o desactualizados.

### Regla del mapa

Si un tema arquitectural importante **no aparece** en `LRU_MAPA`, se introduce en él. El MAPA es el único documento que se puede dar por "completo" en cuanto a cobertura temática. Los demás del núcleo apuntan a profundidades concretas; el MAPA garantiza que se sabe dónde mirar.

---

## 10 · Cómo se actualiza este documento

`LRU_METODO` se actualiza cuando:

* Se detecta un **patrón humano-IA** repetible que merece regla (se añade a sección 6)
* Se establece una **disciplina operativa** nueva (se añade a la sección correspondiente)
* Una regla **deja de funcionar** (se modifica o se retira con anotación)
* El **sistema de anillos** cambia estructuralmente

**No se actualiza por**:

* Detalles de una sesión concreta (eso va en handoff)
* Observaciones aisladas no repetidas (esperar a que sean patrón)
* Reglas muy específicas de un componente (van en documento dedicado del anillo 2)

---

## 11 · Pendientes del método

Temas que Manuel identificó como arrastrados durante bastante tiempo, que merecen entrar aquí cuando se trabajen con profundidad, pero que **no son urgentes ni prioritarios** y por tanto no se articulan todavía:

* **Firebase** — reglas sobre cuándo se usa, qué tipo de datos viven ahí, patrones de lectura/escritura, colecciones activas, reglas de seguridad (`firebase/firestore.rules`), política de fallback local.
* **Testing** — disciplina de tests. Qué se testea, qué no, patrones de Playwright e2e (`e2e/`), cuándo se añade test con código nuevo, cuándo es opcional.
* **Deploy a producción** — más allá del despliegue local ZIP+PS, cómo y cuándo se publica al servidor productivo, convenciones del `.htaccess`, rutas de build, PWA y service worker.
* **Inicios de sesión con otro Claude** — patrones para arrancar limpiamente una conversación nueva con otro modelo o instancia, qué adjuntar, cómo transferir contexto sin pérdida, diferencias de comportamiento entre modelos.

Cada uno se añadirá a la sección que corresponda (convenciones, ciclo, patrones, despliegue) cuando una sesión los trabaje con contexto suficiente. Mientras tanto, **esta lista es la memoria** de que existen.

---

## 12 · Nota de origen

Este documento es parte de la refundación documental producida en sesión **s57** (2026-04-18). La sesión tomó la decisión de reorganizar el sistema documental del proyecto en tres anillos con un núcleo vivo de cinco documentos canónicos. `LRU_METODO` fue el primero de los cinco en producirse, por disciplina: primero establecer las reglas, después escribir los demás documentos con ellas activas.

La disciplina de los tres anillos, los criterios de archivo, los patrones humano-IA, y las reglas operativas vienen de trabajo acumulado a lo largo de decenas de sesiones — especialmente s53 (refundación arquitectural), s54 (auditoría documental), s55 (articulación de gaps y mapa curado), y s57 (sistema de anillos).

**Ampliación s60** (2026-04-19): articulado el anillo 0 (Proyecto de Claude como memoria de arranque), regla de actualización del `index.html` al cierre, regla de sincronización del Proyecto al cierre, y producido `CLAUDE_ARRANQUE.md` como briefing operativo complementario al núcleo.

**Ampliación s61** (2026-04-19): añadido el *checklist de sincronización al sobreescribir un canónico* en §3 cierre, como profilaxis contra la inercia de escritura detectada en auditoría T-S61-M1 (8 incoherencias en el anillo 0 al cierre de s60, todas causadas por zonas no-cambiantes del documento que conservaban datos de sesiones anteriores). Es disciplina operativa nueva: afecta a todas las sesiones futuras que sobreescriban un canónico.

**Ampliación s64** (2026-04-20): añadida la subsección *"Comandos de lanzamiento al entregar ZIP + PS1"* en §3 cierre. Formaliza los dos bloques PowerShell que Claude entrega siempre al cierre junto al ZIP y al PS1: descompresión del ZIP en `$env:USERPROFILE\Downloads\<nombre-zip-sin-extensión>\` con anti-duplicado estricto, y ejecución del deploy. Los ficheros extraídos no se borran — quedan como copia alternativa para seguimiento y recuperación manual. Disciplina aplicada ya al propio cierre de s64. Cierra una fricción operativa recurrente (reconstruir los comandos de memoria cada cierre).

**Ampliación s66** (2026-04-20): añadida la subsección *"Regeneración entera vs parche localizado — fallback por contexto"* en §3 cierre. Formaliza el patrón usado al cierre de s65 (y aplicado en s66) cuando el contexto de cierre no alcanza para regenerar canónicos enteros: entrega de parches localizados tipo `v2_*_aplicacion.md`, nota transitoria en §0 de `CLAUDE_ARRANQUE.md` como tarea pendiente, ejecución de la recomposición como primer bloque de la siguiente sesión, y regla de disputa (gana el destilado). No es norma — es fallback aceptable. La disciplina real sigue siendo regenerar enteros al cierre.

**Ampliación s70** (2026-04-21): añadida la sección §6 *"Disciplina ética sobre material de casos reales"* como regla operativa del proyecto, derivada del §2.8 del Postulado 7 articulado en s69 e integrado al núcleo en s70 (`LRU_FUNDAMENTOS §10.6` lo nombra; este documento codifica la disciplina operativa). Las secciones §§6-11 vigentes hasta s70 (Patrones humano-IA, Tensiones, Memoria, Actualización, Pendientes, Nota de origen) se renumeran a §§7-12 con sus referencias internas actualizadas. La frontera ética canónica — **caso con nombre se analiza, situación técnica se juega** — es la regla operativa principal; las reglas operativas derivadas (citar fuentes oficiales, no atribuir responsabilidades fuera de lo establecido por investigación oficial, no usar nombres personales más allá de los oficiales, tratar con la gravedad que corresponde) son consecuencias de aplicarla.

**Ampliación s133** (2026-05-11): añadida la sección §4bis *"Glosarios canónicos por lego"* con el Glosario Canónico Atlas como 1ª instancia (5 sub-secciones: términos nucleares · contradicciones known-resolved · términos banned · reglas R1-R7 de scope y ownership · convenciones de nombres en código), tras emerger en s133 problemas serios de nombres durante el rename P13 del lego Atlas. Cita Manuel s133: *"tenemos problemas serios de conceptos con los nombres de las columnas y las filas"*. El Glosario codifica disciplina operativa para legos compartidos con vocabulario potencialmente ambiguo. Articulados también dos postulados candidatos (P13 · Primacía visual del nombrado · P15 · Dos paradigmas complementarios de presentación de contenido) pendientes de integración formal en `LRU_FUNDAMENTOS` (sesión del proyecto madre LRU Auditoría). Añadida también la sección §7bis *"Patrones operativos para diagnóstico de bugs"* con 2 sub-patrones nuevos (7bis.1 bug ficticio por persistencia residual · 7bis.2 instrumentación con stack traces) cristalizados durante el diagnóstico del bug wheel ficticio en Sim3. Las secciones §§8-12 vigentes hasta s133 conservan su numeración (§4bis y §7bis son inserciones laterales sin renumeración cascade).

El `COLLABORATION_NOTES.md` original y su versión `v2_s54` quedan como material fuente. Su contenido vivo se absorbe aquí; los documentos originales permanecen por trazabilidad hasta que una sesión posterior decida archivarlos.

---

*sincronizado s204 · 2ª pasada · handoff y tech debt pasan a vivos sin sufijo: `LRU_HANDOFF_VIVO.md` regenerado entero (D-s204-D) + `LRU_TECH_DEBT_VIVO.md` reescrito, items cerrados salen (D-s204-E) · partición del Project por frecuencia de cambio (D-s204-F: estables al Project · por-sesión solo-disco leídas vía MCP · SYNC manual solo al tocar estables) · auto-sesión desde ESTADO + regla disco-gana + memoria de Claude no es fuente (D-s204-G) · Anillo 0, §3·Inicio, §3·Cierre, §3·SYNC y tabla de capitalización actualizados*

*sincronizado s204 · 2026-06-10 · §3·Cierre gana la regla de línea de bitácora mecánica (D-s204-B) + congelación de la bitácora de handoffs (D-s204-C) + backfill s199→s203 muerto por declaración (D-s204-A) · tabla §1.B actualizada · nota: el pie no recogió la sync s203 (§3·Cierre punto 4 · ESTADO) — inercia reparada aquí*

*LRU Platform · Método de trabajo · Documento vivo del núcleo · sincronizado por última vez al cierre de s133 · 2026-05-11 · Manuel & Claude Opus 4.7 · §4bis nueva *"Glosarios canónicos por lego"* con Glosario Canónico Atlas como 1ª instancia (5 sub-secciones) cristalizado en s133 durante rename P13 del lego Atlas · §7bis nueva *"Patrones operativos para diagnóstico de bugs"* con 2 sub-patrones cristalizados (bug ficticio por persistencia residual + instrumentación con stack traces) · 2 postulados candidatos articulados pendientes integración formal LRU_FUNDAMENTOS (P13 Primacía visual del nombrado · P15 Dos paradigmas complementarios de presentación de contenido) · §§8-12 conservan numeración (§4bis/§7bis son inserciones laterales)*

*[Pie histórico de sincronización s129]: sincronizado por última vez al cierre de s129 · 2026-05-07 · Manuel & Claude Opus 4.7 · §1 ampliado con sub-bipartición funcional §1.B.1/§1.B.2 (operativo cargado al Project · referencia bajo demanda vía MCP) formalizada en s129 (Propuesta A · D-s129-S) reflejando con honestidad la realidad post-ampliación de 2 a 6 piezas Anillo 1.B + §3 ampliado con D6 política unificada de mantenimiento del MAPA (D6.1 bloque arquitectural unificado + D6.2 cierre graduado de bloques de sesión) cerrando D6 candidata por materialización (9ª aplicación del ciclo destilado→código · 2ª sobre objeto documental tras T-S93-DIETA s94) + §3 ampliado con plantilla literal canónica copy-pegable del bloque de arranque PowerShell + §3 ampliado con orden ejecutivo del cierre operativo en 5 pasos canónicos (mnemónica BACKUP→ZIP→DEPLOY→SYNC→COMMIT) formalizando la secuencia que vivía implícita en handoffs §5 desde s90 · 6 piezas anillo 1.B materializadas al cierre s129 (3 §1.B.1: GUIA + PRINCIPIOS + TENSIONES_ABIERTAS · 3 §1.B.2: CATALOGO_ANILLO2 + BITACORA_SESIONES + BITACORA_HANDOFFS) · disciplina articulada en alfiler `lru_externalizacion_navegacional_s128.md` con etapas 2 y 3 ejecutadas en s129 · renumeración coherente del sistema documental queda abierta como T-S128-N1 candidata · título "tres anillos" preservado como deuda anotada hasta sesión dedicada de refactor taxonómico*