ember-memory-test/episodes/TRAZA_nota-sobre-la-otra-instancia_S20260807.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md

episode_id	puente_flat	session_code	acto_dialogico	actor_flujo	criticidad_aegis	skill_dominante	fase_proyecto	tipo_semantico	summary_one_line	source_type	trust_boundary	created_at	relectura_tagged	forgejo_commit_sha
c9d3a7fc-ca63-49ec-a1f0-083502ce6670	TRAZA_nota-sobre-la-otra-instancia_S20260807.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260807.COTEJO_ARCHIVOS_SERVIDOR	informar	multi_actor	low	NONE	operations	troubleshooting	EPISODIO 1 — HANDOFF_PROMPT.md: Nota sobre la otra instancia	claude_code	internal	2026-08-08T06:34:48.699064+00:00	false	pending

Hasta que reinicies esa sesión, tu Claude Code del móvil seguirá creyendo que BLINDADA-17 bloquea y que hay que consultar un directorio que no existe. No maté los procesos: es tu sesión y podrías tener trabajo en vuelo.

Nota sobre la otra instancia

Mientras trabajaba, la instancia S20260808.PIPELINE_MEMORIA_REEVAL commiteó cuatro veces en el mismo repositorio. Su trabajo y el mío no se tocaron (archivos disjuntos), y ahora los tres remotos y tu HEAD coinciden en 63191a32, que desciende de mi commit. Todo consistente.

—

Hice: rescate de 17 archivos irrecuperables commiteado y empujado a los 3 remotos · doctrina del móvil actualizada y verificada por hash · baseline de secretos corregida quirúrgicamente.

Falta: reiniciar la sesión del móvil (solo tú), y tres cosas del informe que no entraron en la opción A.

Mi consejo: reinicia mobile-rc cuando puedas —el móvil es hoy el único punto donde una decisión puede salir mal por leer reglas falsas— y déjame versionar los 3 scripts del cron, que es la otra pérdida posible de verdad.

Para avanzar, elige:

• 🟢 A (recomendado) — Bajo a git los 3 scripts del cron sin versionar (retrieval_gate.py, chequeo_diario_pipeline.py, health_check_cron.sh).
• 🟡 B — Tapo el agujero del hook mega-hook-server-sync.py para que los archivos escritos por generadores también suban.
• ⚪ C — Paramos aquí; cierro sesión con STATE y HANDOFF actualizados.

Rescate completo y verificado. Te dejo el resultado.

Eran 6, no 3 — y el error también era mío

Al medir en vez de heredar la cifra, la lista creció al doble. El agente del cotejo dijo 3 porque su patrón solo capturaba rutas absolutas y perdía los scripts que el cron invoca tras un cd. Mi primera pasada repitió el mismo punto ciego, lo detecté al revisar y volví a medir. La corrección quedó escrita en el commit, no enterrada.

Los seis, ahora en scripts/server-side-pipeline/cron/ y verificados byte a byte contra el original:

Script	Cadencia	Qué hace
crisol_cron.sh	cada hora	dispara el crisol — el escritor único de Qdrant y Neo4j
health_check_cron.sh	cada 5 min	el chequeo más frecuente del sistema
retrieval_gate.py	diario 6am	gate de retrieval R-5
chequeo_diario_pipeline.py	diario	chequeo del pipeline de memoria
trivy_scan.sh	semanal	escaneo de vulnerabilidades
podcast-cron.sh	semanal	generación del podcast

El más grave era el primero: el disparador del pipeline de memoria completo vivía sin una sola copia en git.