feat(episode): ASESORA_lexicon-aliases_S20260413.R61_VG.ops.2.hot_ins.in.ex.es.000.MGQ_J.CMCFX_E.DGUCD

Skill: TESSERA | Type: chronicle
Summary: EPISODIO 61 — LEXICON aliases: Curacion de aliases duplicados en lexicon_aliases
This commit is contained in:
Ember 2026-04-14 00:09:24 +00:00
parent a7cb81c05e
commit c73597fab5

View file

@ -0,0 +1,21 @@
---
episode_id: "472deba2-a073-418d-b2f6-07ef9c609fda"
puente_flat: "ASESORA_lexicon-aliases_S20260413.R61_VG.ops.2.hot_ins.in.ex.es.000.MGQ_J.CMCFX_E.DGUCD"
session_code: "S20260413"
acto_dialogico: "instruir"
actor_flujo: "ember_to_user"
criticidad_aegis: "low"
skill_dominante: "TESSERA"
fase_proyecto: "operations"
tipo_semantico: "chronicle"
summary_one_line: "EPISODIO 61 — LEXICON aliases: Curacion de aliases duplicados en lexicon_aliases_v2"
source_type: "claude_code"
trust_boundary: "internal"
created_at: "2026-04-13T17:15:10.443959+00:00"
relectura_tagged: false
forgejo_commit_sha: "pending"
---
La tabla lexicon_aliases_v2 en PostgreSQL mnemo_plex contiene 14269 aliases para 534 entries del LEXICON. Cada entry tiene en promedio 27 aliases con un minimo de 14 y maximo de 38. Los aliases se clasifican en 6 tipos: acceptable (6148) para sinonimos validos en uso normal, search_only (4257) utiles para buscar pero no para escribir, colloquial (3864) de uso informal no apto para documentos formales, deprecated para aliases que ya no aplican, prohibited para terminos vagos que degradan escritura, y legacy para labels anteriores despues de rename. La recomendacion para curar aliases es: verificar que cada entry active tenga al menos 3 aliases de tipo acceptable, eliminar aliases redundantes donde el componente texto aparece como acceptable y search_only, marcar como deprecated los aliases de servicios renombrados, y nunca eliminar aliases de tipo legacy porque permiten resolver referencias historicas. La constraint UNIQUE lexicon_id alias_text previene duplicados exactos pero no detecta duplicados semanticos como Postgres y PostgreSQL que pueden coexistir como aliases separados de la misma entry.
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.