ember-memory-test/episodes/EXPLORA_lexicon-add-entity_S20260413.R62_VG.ops.2.hot_ins.in.ex.es.000.MGQ_J.VMDFK_E.SKNZR.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
cb47350e-b79a-4ae7-a981-1e130a7a5d3d	EXPLORA_lexicon-add-entity_S20260413.R62_VG.ops.2.hot_ins.in.ex.es.000.MGQ_J.VMDFK_E.SKNZR	S20260413	instruir	multi_actor	low	TESSERA	operations	chronicle	EPISODIO 62 — lexicon_add_entity: Procedimiento para agregar entries nuevas al LEXICON	claude_code	internal	2026-04-13T17:15:16.910412+00:00	false	pending

Para agregar una entry nueva al LEXICON se debe cumplir el gate de creacion 2 de 3 criterios: recurrencia la entidad aparece frecuentemente, ambigueedad su ausencia produce confusion, valor estructural permite unir filtrar o relacionar memoria. Los campos minimos antes de pasar a review son preferred_label unico de 2 a 100 caracteres, definition_short de 5 a 200 caracteres, definition_operational de como se usa, domain del ecosistema, entity_type de los 24 tipos validos incluyendo los 11 nuevos v2.1 como verb_iupac aroma_j aroma_e acto fase source criticidad decay trust score flag, ecosystem_specific boolean, al menos 1 alias o justificacion de ausencia, y al menos 1 relacion o justificacion de ausencia. El flujo es: Ember propone como draft, completa campos para review, John aprueba transicion a active. Solo entries active alimentan canonizacion de escritura en TESSERA query expansion y vocabulario. El lexicon_id sigue formato lex-NNN con numeros de 3 a 5 digitos.

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.