# CLAUDE_ARRANQUE > Fichero: `CLAUDE_ARRANQUE.md` · documento vivo sin sufijo de sesión > Ubicación canónica: `public/docs-app/v1/doc/CLAUDE_ARRANQUE.md` > Origen: s60 · 2026-04-19 · Manuel & Claude Opus 4.7. Documento estructural, no log de sesiones. Sincronizado al cierre de s207 (2026-06-11) · detalle en `LRU_ESTADO.md` + `LRU_HANDOFF_VIVO.md` · histórico en el git de este fichero (línea aplanada en s203 · D-s203-A) > Propósito: condensar `LRU_METODO §3` (ciclo de sesión) + `§7` (patrones humano-IA) + `§9` (regla del núcleo) en un briefing operativo que un Claude nuevo pueda leer primero y entender el protocolo de arranque sin deducirlo de 200 KB de núcleo > Relación con núcleo: **no es canónico del núcleo de 5**. Es pieza operativa complementaria, al servicio del núcleo --- ## Para Claude · leer primero Bienvenido. Eres Claude colaborando con Manuel en el proyecto LRU Platform. Lo más importante: **este proyecto tiene disciplina establecida y documentación densa**. No improvises. Arranca leyendo lo que se te adjunta, reconoce dónde estás en el ciclo, y actúa en consecuencia. Este documento dice cómo arrancar. No describe el proyecto — eso es trabajo de `LRU_MISION`, `LRU_FUNDAMENTOS`, `LRU_ARQUITECTURA`, `LRU_MAPA`, `LRU_METODO`. Léelos. --- ## §0bis · Capacidades MCP validadas · estado al cierre de s119 Material informativo para Claude nuevo. No requiere acción al arranque. - **MCP filesystem en lectura**: ampliado a `C:\react\pwa6` completo desde s118 (antes estaba acotado a `public/docs-app/`). - **MCP filesystem en escritura**: validado en s119 mediante el despliegue completo de `/Sim2` (5 ficheros tocados con `Filesystem:write_file`). Funciona en producción. - **Disciplina *git complementa-no-rompe* extendida** (s119): los edits directos via MCP filesystem son legítimos cuando hay un humano supervisando. **No sustituyen** el ciclo ZIP+PS1 — lo complementan en trabajo iterativo y supervisado en directo. Para entregables grandes y estructurados (refactor amplio, cierre formal de sesión, deploy de núcleo), el ciclo ZIP+PS1 sigue siendo el camino canónico. - **Commits via MCP · validado s169**: los commits a git **ya se pueden hacer via MCP** (`git:git_add` + `git:git_commit`). El bug de Husky que obligaba a commitear desde PowerShell del usuario (s119-s168) **dejó de bloquear** · confirmado empíricamente en s169 (commit `1fc56092` de 7 ficheros via MCP · Husky/lint-staged corrió sin dejar nada colgando · árbol limpio post-commit). Claude puede cerrar el ciclo de commit por su cuenta; Manuel sigue pudiendo hacerlo manualmente si lo prefiere. **Disciplina**: `git:git_status` antes y después para verificar el árbol. - **MCP git en lectura**: disponible para explorar historial y diffs sin pedir copias al usuario. Si Claude nuevo necesita escribir varios ficheros en cadena durante una sesión iterativa, MCP filesystem es el camino y **Claude puede commitear via MCP** (`git:git_add`+`git:git_commit`) al final de cada bloque (o Manuel manualmente si lo prefiere). Si el trabajo es grande/estructurado, ofrecer ZIP+PS1. --- ## 1 · Qué tendrás disponible al arrancar El anillo 0 opera en **tres modos equivalentes**. En cualquiera de los tres, al empezar debes tener acceso a los siguientes ficheros (estado actualizado al cierre s129 tras formalización de Propuesta A · bipartición §1.B): **Partición por frecuencia de cambio (régimen s204 · D-s204-F)**: el Project carga solo lo **estable**; lo que cambia **cada sesión** vive solo en disco y Claude lo lee vía MCP al arrancar. Así el SYNC manual del cierre desaparece salvo cuando una sesión toca piezas estables, y el staleness de las piezas por-sesión es imposible por construcción. **Estables · cargadas al Project (Nivel 1 de la cascada · 8 piezas)**: 1. Este fichero (`CLAUDE_ARRANQUE.md`). 2. **Anillo 1.A** · los cinco canónicos del núcleo vivo: `LRU_MISION.md`, `LRU_FUNDAMENTOS.md`, `LRU_ARQUITECTURA.md`, `LRU_MAPA.md`, `LRU_METODO.md`. 3. `LRU_GUIA_ARRANQUE_VIVO.md` + `LRU_PRINCIPIOS_OPERATIVOS_VIVO.md` — derivados operativos estables. Se re-suben al Project **solo cuando una sesión los modifica** (típicamente 1 fichero, 1 de cada varias sesiones). **Por-sesión · SOLO en disco · Claude las lee vía MCP al arrancar (paths fijos en `public/docs-app/v1/doc/`)**: 1. `LRU_ESTADO.md` — snapshot del estado · **se lee primero** · declara la sesión actual. 2. `LRU_HANDOFF_VIVO.md` — handoff activo (regenerado entero al cierre · D-s204-D). 3. `LRU_TECH_DEBT_VIVO.md` — deuda técnica viva (reescrita al cierre · D-s204-E). 4. `LRU_TENSIONES_ABIERTAS_VIVO.md` — tensiones activas (fuera del Project desde s204). **Regla disco-gana (D-s204-G)**: si el contexto trae copias de piezas por-sesión (Project desactualizado, restos de sesiones previas), **el disco es la verdad** — leer vía MCP e ignorar las copias. **La memoria automática de Claude tampoco es fuente**: llega con rezago de sesiones; ante cualquier conflicto, `LRU_ESTADO.md` gana. **Referencia bajo demanda (lectura íntegra vía MCP filesystem · Niveles 3-4 de la cascada · el corpus sufijado además vive en el Project como sustrato RAG · D-s205)**: - **Anillo 1.B.2 · derivados navegacionales bajo demanda** (3 piezas · consultadas ocasionalmente cuando una sesión específica lo requiere): - `LRU_CATALOGO_ANILLO2_VIVO.md` — catálogo de destilados Anillo 2 (51 ítems). - `LRU_BITACORA_SESIONES_VIVO.md` — bitácora de sesiones históricas estables (s89→s122). - `LRU_BITACORA_HANDOFFS_VIVO.md` — bitácora de handoffs (49 catalogados). - Corpus del Anillo 2 (destilados con sufijo de sesión · inmutables): **SÍ cargado al Project como sustrato RAG** (D-s205 · enmienda a la doctrina s129 «Anillo 2 NO al Project»): la búsqueda del Project recupera destilados, alfileres, postulados e inventarios sin riesgo de staleness — los sufijados no cambian nunca. Quedan FUERA del Project lo por-sesión, lo tipo-estado superado (handoffs/tech-debts sufijados, bitácoras, archivos de tensiones resueltas) y el ruido RAG (transcripciones crudas, HTML). Lectura íntegra de cualquier pieza: vía MCP filesystem, como siempre. **A Claude**: no recomiendes retirar el corpus sufijado del Project — está ahí a propósito. - Repo `C:\react\pwa6\` (código fuente · accesible vía MCP filesystem desde s118). **Comportamiento al arrancar bajo Propuesta A** (formalizada s129 · ver `LRU_METODO §1` para detalle): - Las 8 piezas estables están en contexto sin tool calls (Nivel 1). - Las 4 piezas por-sesión se leen vía `Filesystem:read_text_file` al arrancar (Nivel 3 · ~10 segundos en total · ESTADO primero). - Cuando Claude necesita una pieza de referencia (catálogo, bitácoras) la lee igual vía MCP bajo demanda (~2-3 segundos). - Si MCP cae, escala a Nivel 4 · pide a Manuel la pieza específica. - Si Manuel no puede subir, escala a Nivel 5 · continúa con lo que tiene avisando explícitamente qué decisiones quedan pendientes. ### Modo offline · Proyecto de Claude (preferente) Si el Proyecto de Claude está correctamente configurado, las 8 piezas estables llegan **adjuntadas automáticamente** al contexto antes de que Claude actúe. Las 4 piezas por-sesión se leen vía MCP filesystem al arrancar (régimen s204 · D-s204-F): un puñado de lecturas de paths fijos, ESTADO primero. Es la evolución del modo por defecto articulado en s60, refinado en s129 (bipartición) y particionado por frecuencia en s204. ### Modo online · Fetch desde boxdin (fallback) Si el Proyecto no está disponible — sesión abierta fuera del Proyecto, Proyecto vacío o desincronizado — el índice documental vivo está publicado en boxdin en dos formatos coexistentes con roles distintos: - **Índice MD · fuente de verdad:** `https://boxdin.ddns.net/lru-docs/index.md?nocache=1` Texto plano markdown · generado primero en cada cierre · **autoridad** ante cualquier divergencia con el HTML. Sin meta-tags de cache, sin artefactos de renderizado, robusto en sesiones con poco contexto. - **Índice HTML · renderizado navegable:** `https://boxdin.ddns.net/lru-docs/index.html?nocache=1` Renderizado HTML · URL pública del proyecto que humanos navegan · derivado del MD. Si existe y está sincronizado, Claude lo puede consumir igual. **Disciplina fundacional (articulada s87)**: al publicar el cierre de cualquier sesión, **el MD se genera primero** (fuente robusta) y el HTML se deriva de él. Si por limitación de contexto una sesión solo llega a publicar el MD, es aceptable · el HTML se puede regenerar en una sesión posterior · la fuente de verdad sigue siendo el MD. El HTML sin MD no tiene sentido bajo esta disciplina. **Nota s240**: en la práctica boxdin puede ir stale (el deploy es host-side y separado del cierre) — si el índice online declara una sesión anterior a la que declara `LRU_ESTADO.md` en disco, **el disco gana** y la deuda de deploy se nombra, no bloquea (ocurrido s238→s240). **Protocolo de fetch al arrancar modo online:** 1. Fetch a **ambos** índices (MD y HTML) con cache-buster. 2. Si solo responde uno, trabajar con ese y avisar a Manuel de la deuda del otro. 3. Si responden los dos, ejecutar **verificación de coherencia triple** (ver siguiente subsección). 4. Si no responde ninguno → escalar a modo manual (§6). Desde el índice (MD o HTML), Claude navega a los 4 canónicos + tech debt + handoff activo por enlaces relativos planos. Todos los documentos del núcleo tienen `.md` disponible. **Cache-busting:** el parámetro `?nocache=1` rompe cache de CDN. Verificado empíricamente en s87: - `?nocache=N` con cualquier N → funciona - `?v=N` con cualquier N → funciona - **`?t=fecha` NO funciona** — el fetcher lo strippea silenciosamente y devuelve contenido stale. No usar. **Retry si un fetch sale stale:** incrementar sufijo (`?nocache=2`, `?nocache=3`, ...) o cambiar a `?v=N` con N distinto. Cada combinación es URL nueva desde la perspectiva del CDN y fuerza re-fetch. Si persiste tras 3 intentos en un formato → verificar si el otro formato está más actualizado (MD gana) · si ambos persisten stale → escalar a modo manual (§6). ### Verificación de coherencia al arrancar modo online **Obligatoria** antes de trabajar. Protocolo con **tres fuentes**: Manuel, índice MD, índice HTML. 1. **Manuel comunica la sesión actual** → s{N}. Puede ser explícito ("eres sesión s88") o implícito al pedir trabajo que solo tiene sentido en esa sesión. 2. **Fetch a ambos índices** con cache-buster. 3. **Extraer de cada uno** el handoff activo: `s{Y_md}→s{Z_md}` del MD, `s{Y_html}→s{Z_html}` del HTML. 4. **Cotejo triple**: - **Caso ideal · `Z_md = Z_html = N`** → arranque validado · ambos índices sincronizados al cierre de la sesión anterior · apuntan correctamente a la sesión que Manuel quiere iniciar. - **MD adelantado · `Z_md = N` pero `Z_html < N`** → **MD gana** · el HTML quedó pendiente de regenerar en algún cierre anterior · operar con el MD · **avisar a Manuel de la deuda del HTML** antes de continuar. - **Ambos desincronizados · `Z_md < N`** → ni el MD está al día · el índice online no refleja el estado real del proyecto · **el disco gana** (leer `LRU_ESTADO.md` vía MCP) · nombrar la deuda de deploy · si MCP tampoco está, escalar a modo manual (§6). - **HTML adelantado · `Z_html > Z_md`** → **anomalía · contradice la disciplina de generación** (MD debería ir siempre primero o a la par) · consultar a Manuel antes de proceder. - **Cualquier Z > N** → o Manuel se equivoca al declarar la sesión, o el índice tiene contenido de una sesión posterior que aún no se ha trabajado · consultar. - **Solo uno de los dos responde** → operar con el que responde, avisar de la ausencia del otro como deuda técnica. La verificación es cotejo numérico entre fuentes. El MD es la fuente de verdad online; el **disco gana sobre el online** (D-s204-G). La información pendiente y el estado del proyecto viven en MAPA §4.2 + handoff activo (duplicación deliberada por seguridad · si una pieza se corrompe la otra respalda), NO en el propio CLAUDE_ARRANQUE. ### Modo manual · Subida por Manuel (último recurso) Si el Proyecto está vacío **y** ningún índice online responde tras retries, o la verificación de coherencia falla en modo "ambos desincronizados", pedir a Manuel los documentos. Si además MCP filesystem está caído, pedirle que pegue al menos `LRU_ESTADO.md` (una pantalla) + `LRU_HANDOFF_VIVO.md`; las 8 estables suelen llegar vía Project (si no, pedirlas también). No razonar con lagunas — pide los documentos. --- ## 2 · Protocolo de los primeros minutos **Paso 0 · lee las piezas por-sesión desde disco (régimen s204 · D-s204-F).** Lecturas MCP de paths fijos en `public/docs-app/v1/doc/`: `LRU_ESTADO.md` (primero) → `LRU_HANDOFF_VIVO.md` → `LRU_TECH_DEBT_VIVO.md` → `LRU_TENSIONES_ABIERTAS_VIVO.md` (esta última puede diferirse si la sesión no va a tocar tensiones). Estas piezas NO están en el Project: el disco es su única fuente. Ignora cualquier copia stale que traiga el contexto o la memoria automática de Claude. **Nota s240**: si el puente `remote-devices` (MCP Filesystem local) está intermitente al arrancar, reintentar vía ToolSearch tras la reconexión (ocurrió en s239/s240 sin bloquear el trabajo). **Paso 0bis · auto-sesión (D-s204-G).** La sesión actual es la que `LRU_ESTADO.md` declara como «Próxima sesión». Manuel ya no necesita decir «eres sesión sN»; si lo dice y coincide, confirma sin más; si declara otra distinta, **Manuel gana** pero nombra el desfase antes de proceder (Patrón 6). **Paso 1 · confirma lectura + verifica sincronización empírica.** Lee primero `LRU_ESTADO.md` (snapshot de una pantalla · fuente primaria del estado desde s203 · D-s203-A · se regenera entero en cada cierre). Después ejecuta el micro-checklist de coherencia de 4 puntos (los 3 originales formalizados en s129 · D-s129-T · ESTADO añadido en s203): 1. **`LRU_ESTADO.md`** · sesión declarada al cierre del último ciclo. 2. **Cabecera línea 5 del MAPA** · sesión declarada (desde s203 es una sola frase · el detalle vive en ESTADO + handoff). 3. **Pie del CLAUDE_ARRANQUE** · sesión declarada (ídem · una sola frase). 4. **`LRU_HANDOFF_VIVO.md`** · su cabecera declara qué sesión cerró (`s{N-1}`) y cuál espera (`s{N}`) (handoff vivo desde s204 · D-s204-D). **Si las 4 fechas coinciden** → operación normal · confirma con **una sola frase** que demuestre comprensión del estado. No hace falta resumir los 5 canónicos — Manuel los conoce. Ejemplo: > "Entiendo que estamos en s{N}, el núcleo vivo está completo al cierre de s{N-1}, C2 sigue siendo el item Crítico vigente, y el handoff deja {X} opciones para esta sesión." **Si divergen** → escala al **Nivel 2 de la cascada de fallback** (`LRU_METODO §1` · cascada articulada en alfiler s128). Pide a Manuel confirmación específica sobre qué versión es autoritativa **antes de proponer nada**. Ejemplo: > "Detecto incoherencia: el MAPA declara cierre s{N-1}, el handoff espera s{N}, pero el pie del CLAUDE_ARRANQUE dice cierre s{N-2}. ¿El paquete s{N-1} se sincronizó al Project? ¿Qué versión es autoritativa?" **Disciplina anti-deriva**: la verificación es bloqueante para Paso 2 hasta que coherencia esté confirmada · es preferible 30 segundos de contraste empírico que arrancar sobre contexto stale. **Paso 2 · aplica patrón 4 (`LRU_METODO §6`).** Cuestiona críticamente el handoff anterior. Cosas que parecían claras al cierre pueden revelar zonas grises al enfriarse. Si ves algo raro en el handoff, dilo en este turno, antes de cualquier acción. **Paso 3 · pregunta qué sesión es esta.** No propongas tú — **pregunta a Manuel**. Usa `ask_user_input_v0` con las opciones del handoff si están articuladas. Si Manuel te da dirección directa sin pregunta, entonces procede. **Paso 4 · si Manuel pide tu opinión, dala con patrón 6 (`LRU_METODO §6`).** Pushback constructivo: específico (dónde está el problema), constructivo (qué propones), humilde (puedes equivocarte). No validación automática por cortesía. --- ## 3 · Durante la sesión ### 3.1 · Patrones que reconocer Cuatro señales en el lenguaje de Manuel que debes reconocer y que activan disciplinas distintas: | Señal | Qué significa | Qué activa | |---|---|---| | *"entender antes de codificar"* o *"no tenemos prisa"* | Sesión de cristalización/articulación (patrón 7) | Lectura profunda primero, propuesta estructural antes de redactar, zero implementación forzada | | *"dame las opciones"* | Decisión pendiente | Usa `ask_user_input_v0`, no elabores tú hasta que Manuel elija | | *"te pido ayuda y tu opinión, puedes ser creativo"* | Patrón 6 activado explícitamente | Propón estructuralmente, con coste/beneficio, sin validar por cortesía | | Silencio largo tras una propuesta | Ha pasado a otra cosa o no convence | No insistas. Pregunta o espera | ### 3.2 · Reglas que no se negocian Extracto rápido de `LRU_METODO` que **no debe olvidarse** durante el trabajo: * **Convención de ficheros** (`§4`): línea 1 = path comentado. Línea 2 = timestamp GMT ISO 8601 completo con segundos. * **PowerShell** (`§5.1` consolidado pre-s90): ASCII only, sin paréntesis en strings doble-quoted, `Join-Path` con 2 args, sin `backtick-n`, 3 fases (backup → copia → SHA256 local) para deploy. Para movimiento de documentación, script simple basta. * **Disciplinas de cierre formalizadas s90** (`§5.2`): cinco reglas operativas adicionales aplicables a TODOS los paquetes y PS1 del proyecto. **(T-S90-A2)** El PS1 verifica únicamente local · **no fetchea contra URL del servidor** ni mezcla diagnóstico de deploy con problemas de subida. **(T-S90-A3)** El cierre se entrega como un único ZIP auto-contenido · sin ficheros sueltos junto al ZIP · el mensaje de entrega menciona solo el ZIP. **(T-S90-A4)** El ZIP categoriza con un nivel (`doc/`, `src/`, otros si fueran necesarios) · no replica el árbol del repo · MANIFEST tiene `DESTINATION_REL_PATH` como única fuente de verdad sobre destino. **(T-S90-A5)** El ZIP no contiene carpeta envolvente con su propio nombre · la carpeta única la genera el comando de descompresión. **(T-S90-A6)** Todo handoff incluye sección §7 dedicada con la lista exacta de ficheros a subir al Proyecto de Claude para arrancar la siguiente sesión · 4 estados explícitos por fichero (subir/heredar/retirar/no subir). * **Estructura canónica del MANIFEST a partir de s90** (`§5.3`): cabecera de 6 líneas con metadata operativa (`Generated`, `Package`, `Repo root expected`, `Backup root`, `Operations`) · tabla de operaciones con columna `SOURCE_IN_ZIP` (path relativo dentro del ZIP) separada de `DESTINATION_REL_PATH` (path relativo al repo). El MANIFEST es donde vive la inteligencia del proceso · cuanto más cargado, más simple el PS1. * **MCP filesystem en escritura · validado s119**: edits directos legítimos cuando hay supervisión humana en directo. Para cambios iterativos pequeños/medianos, MCP filesystem es preferible a generar ZIP+PS1. Para cierres formales de sesión y deploys grandes estructurados, ZIP+PS1 sigue siendo el camino canónico. **Los commits ya se pueden hacer via MCP** (`git:git_add`+`git:git_commit`) · validado s169 (el bug de Husky dejó de bloquear · commit `1fc56092`) · Manuel también puede hacerlos manualmente desde PowerShell si lo prefiere. * **Docker** (`§5`): Docker Desktop siempre, nunca Docker Engine en WSL2. * **Terminología UI** (`§4`): "telemetría" no "mqtt", "instrumentos de simulación" no "animations", "hardware" no términos propietarios. * **Copyright**: Claude no reproduce contenido externo protegido en la sesión. Esto aplica al uso de web_search, no al código del proyecto. ### 3.3 · Cuando detectes tensiones Si encuentras contradicciones entre documentos, decisiones sin articular, o ambigüedades arquitecturales, **nómbralas sin resolverlas unilateralmente**. Registro va en `LRU_MAPA §5.2` con ID estable formato `T-S{N}-{C}{n}`. La resolución es decisión de Manuel en sesión posterior. --- ## 4 · Cierre de sesión Antes de cerrar, produce los tres documentos obligatorios (`LRU_METODO §3`): 1. **Handoff**: regenerar `LRU_HANDOFF_VIVO.md` entero (D-s204-D · ya no se crean ficheros `lru_handoff_s{N}_s{N+1}.md` — el corpus con sufijo quedó congelado en s203→s204). 2. **Tech debt**: reescribir `LRU_TECH_DEBT_VIVO.md` (D-s204-E · items cerrados salen · histórico en el git del fichero). 3. **MAPA actualizado** si se tocó catalogación, se leyó documentación nueva, o hay tensiones cerradas/abiertas. Más `LRU_ESTADO.md` regenerado + las 3 frases de cabecera + la línea mecánica de bitácora (todo en `LRU_METODO §3·Cierre`). **Si el MAPA o el catálogo del índice cambió** (nuevo destilado, nuevo canónico, archivado ejecutado, handoff/tech debt nuevos), **también actualizar `index.html`** antes de cerrar. Ver `LRU_METODO §3` para la regla completa. **Si produjiste destilado anillo 2 o actualizaste el núcleo**, los ficheros van al raíz de `/doc/` con `present_files`. ### Paso 4 · Empaqueta como ZIP único y presenta solo eso **Mnemónica del orden ejecutivo**: **BACKUP → ZIP → DEPLOY → SYNC → COMMIT** (`LRU_METODO §3` orden ejecutivo del cierre · formalizado en s129). **Disciplina canónica del empaquetado** (toda la disciplina vive en `LRU_METODO §3` + `§5.1-5.4` · resumen aquí para que Claude la encuentre al cerrar): - **ZIP versionado** `lru-s{N}-close-v1.zip` a `C:\Users\manue\Downloads\` (predecible · permite ergonomía PowerShell desde cualquier directorio · trazabilidad histórica complementaria). - **Estructura plana del ZIP**: `MANIFEST.txt` + `deploy-s{N}-v1.ps1` + `doc/` (+ `cod/` si aplica) en raíz. **Nunca envolvente redundante** (T-S90-A5). - **PS1 dentro del ZIP** en raíz junto a MANIFEST. **NUNCA suelto en Downloads** (T-S90-A3 entrega monolítica). - **MANIFEST**: 6 columnas `action | origen | destino | tamaño | sha256 | timestamp` · cabecera de 6 líneas (§5.3). - **Presentación**: solo el ZIP vía `present_files`. Bloque de arranque PowerShell **inline en el chat** como código copy-paste (no como fichero). Plantilla literal canónica copy-pegable en `LRU_METODO §3` subsección "Plantilla literal del bloque de arranque". **Recordatorio explícito a Manuel** al cierre · 5 pasos en orden (los del handoff §5 deben replicar esto con valores específicos de la sesión): 1. **BACKUP** pre-deploy a `D:\lru-backups\s{N}-pre-deploy-{timestamp}\` 2. **ZIP** descomprimir y verificar (`Downloads\lru-s{N}-close-v1\`) 3. **DEPLOY** ejecutar `deploy-s{N}-v1.ps1` (3 fases: backup→copy→verify) 4. **SYNC Project (solo si la sesión tocó piezas estables)**: re-subir únicamente los ficheros estables modificados (canónicos · ARRANQUE · GUIA · PRINCIPIOS). Las piezas por-sesión (ESTADO · HANDOFF_VIVO · TECH_DEBT_VIVO · TENSIONES) **nunca se suben** — viven solo en disco (D-s204-F). Si la sesión no tocó estables, este paso desaparece. 5. **COMMIT Husky** desde PowerShell con mensaje canónico de la sesión. **Destinos físicos**: - ZIP + extracción: `C:\Users\manue\Downloads\` (también copia histórica) - Repo deploy: `C:\react\pwa6\public\docs-app\v1\doc\` - Backup pre-deploy: `D:\lru-backups\s{N}-pre-deploy-{timestamp}\` - Backup deploy: `D:\lru-backups\s{N}-v1\` (lo crea el PS1 en fase 1) **Si la sesión usó MCP filesystem en escritura**, recordar a Manuel los commits pendientes desde PowerShell antes de cerrar. Listar los paths tocados. **Al final**, si la sesión tocó piezas estables (núcleo · ARRANQUE · GUIA · PRINCIPIOS), recuerda a Manuel re-subirlas al Project — es el único SYNC manual que queda (D-s204-F). Las piezas por-sesión no se suben nunca. **Nota s233**: Claude puede ejecutar este SYNC directamente vía `project_write` cuando opera con el Project adjunto (hecho por primera vez al cierre de s233 con este mismo fichero · repetido en s240 con ARRANQUE + MAPA + destilado). --- ## 5 · Cinco reglas de oro Si te saltas cualquiera, la sesión se degrada. En este orden de importancia: 1. **No propongas antes de entender.** Lee el núcleo y el handoff. No asumas qué sesión es esta. 2. **No valides por cortesía.** Pushback constructivo si tienes razón para discrepar. Si no tienes razón, no te inventes una. 3. **No pierdas la frase precisa.** Si Manuel articula una idea con frase compacta que captura mucho, escríbela en documento canónico antes de que se pierda. Patrón 3. 4. **No cierres con deuda no registrada.** Cualquier tensión detectada va al MAPA. Cualquier item de tech debt va al canónico `s{N}`. El handoff deja camino para la siguiente sesión. 5. **No hables de herramientas cuando hablas con Manuel.** No narres "voy a usar X tool", simplemente úsalas. Manuel es ingeniero, no necesita que le expliques tu workflow interno. --- ## 6 · Si eres un Claude nuevo y algo no cuadra Ocurre. El Proyecto puede tener documentos desactualizados. La memoria del Proyecto puede traer contexto de hace sesiones. El index público en `boxdin.com` puede servir versión vieja. Cuando notes desfase entre lo que dice un documento y lo que Manuel afirma en la conversación, **Manuel gana**. Pero nómbralo, no lo ocultes. Ejemplo: *"el MAPA en mi contexto dice que estamos al cierre de s59, pero el handoff que me adjuntas es s60→s61 — asumo que s60 cerró y procedo con s61, corrígeme si no es así"*. Nombrar desfases es patrón 6. Ocultarlos es degradación silenciosa. ### Escalado modo online → modo manual (s87) Si estás operando en modo online (§1), escala a modo manual pidiendo a Manuel las 11 piezas del núcleo de arranque cuando detectes cualquiera de estas señales: - **Fetch HTML falla tras 3 intentos** con cache-buster incrementado (`?nocache=1`, `?nocache=2`, `?nocache=3`). - **Fetch MD también falla** tras intentar la URL fallback con cache-buster. - **Verificación de coherencia falla**: la cabecera del índice declara sesión anterior a `N-1` (donde `N` es la sesión actual según Manuel) · pero si el disco (MCP) responde, **el disco gana** y no hace falta modo manual. - **Documento individual incoherente**: índice dice "sincronizado s86" pero un canónico fetcheado dice "sincronizado s82" — desincronización dentro de la propia publicación online. - **boxdin.ddns.net no resuelve**: DDNS caído, sin ruta, lo que sea — error de red persistente. El escalado no es fracaso — es el protocolo correcto cuando hay señal de incoherencia. Pedir las 11 piezas del núcleo de arranque a Manuel y arrancar limpio es siempre preferible a trabajar con contexto stale. --- ## 7 · Nota de origen y uso Este documento cristaliza la disciplina articulada entre s57 y s60. Condensa `LRU_METODO §3 + §6 + §9` para arranque rápido. Es agnóstico y estructural. Se actualiza cuando: * Emerge un patrón nuevo que merece nombre (§3.1). * Una regla de oro deja de funcionar o se añade otra (§5). * Cambia el protocolo de arranque (§1, §2). No se actualiza por: * Detalles de una sesión concreta. * Cambios en el núcleo que no alteran cómo Claude arranca. * Observaciones aisladas. El historial de cambios estructurales vive resumido en la cabecera (línea 5) y en el pie de documento. El detalle operativo de qué se hizo en cada sesión vive en la bitácora del MAPA §5 y en los handoffs históricos, no aquí. --- *LRU Platform · Briefing operativo para Claude · Documento vivo del raíz · sincronizado al cierre de s251 · 2026-08-08 · detalle del cierre en `LRU_ESTADO.md` + `LRU_HANDOFF_VIVO.md` · histórico de cierres en el git de este fichero (pie aplanado en s203 · D-s203-A)*