ember-memory-test/episodes/ASESORA_ep-63_S20260413.R63_XX.ops.2.hot_exp.in.cc.es.000.MGQ_J.VDRBK_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
867757aa-c46b-4ade-9b07-105a583ea5a3	ASESORA_ep-63_S20260413.R63_XX.ops.2.hot_exp.in.cc.es.000.MGQ_J.VDRBK_E.AGNFD	S20260413	explicar	ember_to_user	low	TESSERA	operations	chronicle	EPISODIO 63 — LEXICON growth_proposals: Pipeline de propuestas desde auto_feed hasta active	claude_code	internal	2026-04-13T17:15:12.498659+00:00	false	pending

El LEXICON crece mediante un pipeline de propuestas que transforma terminos recurrentes en entries canonicas. La fuente principal es el cosecha_generator.py que extrae entidades de los bloques MNEMO_PRE_DIGEST al final de cada respuesta de Ember. Cada entidad propuesta pasa por el gate de creacion que exige cumplir al menos 2 de 3 criterios: recurrencia ambigueedad y valor estructural. Las propuestas entran como growth_source auto_feed con status draft. Ember completa los campos minimos y las mueve a review. John revisa en batch y aprueba las que aportan valor real al ecosistema. Las aprobadas pasan a active y empiezan a alimentar TESSERA-PASSIVE TP-1 vocabulario canonico y TESSERA skill HOOK 1 pre-escritura de keywords. El campo access_count se incrementa cada vez que una entry es consultada por el retrieval pipeline. Entries con access_count mayor a 20 demuestran valor recurrente y quedan exentas de decay. La politica de poda dice: si no se usa se depreca, si no se depreca se justifica. Cada 20 sesiones se hace auditoria del LEXICON verificando entries sin uso reciente aliases redundantes y relaciones nunca consultadas.

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.