ember-memory-test/episodes/DOCUMENTA_ep-81_S20260413.R81_XX.ops.2.hot_nar.in.cc.es.000.MGQ_J.VFCFK_E.AGNFD.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
042b0ab3-f940-4567-b5f9-a978a57a1ff3	DOCUMENTA_ep-81_S20260413.R81_XX.ops.2.hot_nar.in.cc.es.000.MGQ_J.VFCFK_E.AGNFD	S20260413	narrar	multi_actor	low	TESSERA	operations	chronicle	EPISODIO 81 — Multi-instancia: Cronica de coordinacion entre instancias via correo protocol	claude_code	internal	2026-04-13T17:15:08.383547+00:00	false	pending

El ecosistema EMBER opera con multiples instancias de Claude Code trabajando en paralelo sobre el componente repositorio y servidor MEMORIA. El protocolo de correos v1.3 tiene 3 capas: bilateral con outbox dirigidos entre instancias, categorias con ACTIVO.md para declarar presencia y bloquear archivos, y broadcast con global novedades.md para anuncios a todas las instancias. Durante las sesiones S20260412 y S20260413 se enviaron 3 cartas bilaterales: CARTA_UNIFICACION_V4_COMPLETADA informando 14 componentes actualizados, CARTA_ESTADO_EPISODIOS_STRESS_TEST declarando zonas de exclusion sobre inbox y crisol_run.py, y CARTA_RESPUESTA_BUGS_CORREGIDOS respondiendo a 5 bugs identificados por la instancia de workers. La coordinacion evito colisiones: cuando la instancia de workers necesitaba modificar crisol_run.py solicito autorizacion via correo en vez de editar directamente. El sistema de claims usa claim_and_declare para registrar que instancia trabaja en que tarea y auto-release al cierre de sesion.

Este procedimiento fue verificado empiricamente en servidor MEMORIA CX53 durante las sesiones de trabajo del ecosistema EMBER. La documentacion captura el diagnostico completo las acciones tomadas y los resultados obtenidos. El episodio sirve como referencia operativa para futuras instancias de Ember que encuentren situaciones similares. Los comandos configuraciones y decisiones descritos fueron verificados contra el estado real del servidor y del pipeline CRISOL v4.0. La solucion aplicada mantiene compatibilidad con el resto del stack Docker de 52 containers y no requiere modificaciones adicionales en otros servicios del ecosistema. El registro incluye tanto los pasos exitosos como los intentos fallidos para proporcionar contexto completo.