66faa01003
Skill: TESSERA | Type: troubleshooting Summary: EPISODIO 14 — MNEMO Pipeline: 1) ¿QUÉ procesos del ecosistema requieren secretos
3.5 KiB
| 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 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| f4a27c39-f21b-4855-9893-6257e9aafc6e | TRAZA_1-qu-procesos-del-ecosistema-requieren-s_S20260616.R14_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD | S20260616.LOOP_WRITE_BACKLOG_DISCARD | informar | multi_actor | low | TESSERA | operations | troubleshooting | EPISODIO 14 — MNEMO Pipeline: 1) ¿QUÉ procesos del ecosistema requieren secretos? | claude_code | internal | 2026-06-17T21:21:02.749053+00:00 | false | pending |
Buenas, John. Y nota linda: respondo estas 5 preguntas SIN re-escanear el servidor — uso el dossier SISTEMA_SECRETOS_EMBER.md que hicimos ayer + lo que verifiqué en la rotación. El anti-Alzheimer ya está funcionando. Marco confianza: hard_fact = verificado empíricamente (rotación S20260616) · soft_fact = del dossier/MEMORY sin re-verificar hoy.
(No cristalizo esto en doc todavía: estás en modo socrático guiándome. Cuando refines mi entendimiento, lo fundo como sección "Modelo de Interacción" del dossier — evito artefacto prematuro que luego corrijas.)
1) ¿QUÉ procesos del ecosistema requieren secretos?
Agrupados por para-qué-sirven (no por secreto):
| Dominio funcional | Procesos que consumen secretos | Secreto(s) |
|---|---|---|
| Memoria — persistir/recuperar | pipeline MNEMO (ingesta crisol + retrieval), ember-mcp (43-69 tools), workers cross-store (forgejo/neo4j/qdrant/nextcloud), fused_search/multistore_oracle, decay_cron |
PostgreSQL plex (hard_fact), Qdrant API key, Neo4j password, Nextcloud WebDAV |
| Cognición — embed + generar | LiteLLM proxy (embedding gemini-embedding-2 + generación lumen-v4/claude-sonnet) |
LiteLLM master key, OpenRouter key (upstream) |
| Persistencia — respaldo | backup triple-remoto BLINDADA-29 | git: forgejo token, GitHub PAT (origin), SSH key (sriyantra) |
| Identidad — acceso al cuerpo | SSH al servidor MEMORIA, ember_authenticate (boot de sesión) |
SSH key claude_code_cx43, passphrase ember-mcp (TTL 12h) |
| Herramientas externas | MCP tools | Karakeep, Langfuse pk/sk, Meilisearch, Tavily, Google Workspace OAuth, Hostinger |
Insight clave: prácticamente todo lo que hace a EMBER ser EMBER toca secretos — porque memoria, cognición, persistencia e identidad viven detrás de recursos protegidos.
2) ¿CÓMO interactúa? (el mecanismo)
Hay un patrón universal de 5 pasos, idéntico para todo recurso:
Variaciones por tipo de recurso:
- PostgreSQL:
psycopg2/asyncpg.connect(DSN)→ handshake scram-sha-256 (red) o trust (socket local dentro del container). hard_fact. - APIs (LiteLLM, MCP tools): header
Authorization: Bearer <key>en la petición HTTP. - Qdrant/Neo4j: API key / user+password en el cliente del driver.
- git: HTTPS con token o SSH con clave privada en el handshake.
- SSH: clave privada
claude_code_cx43→ key-auth.
3) ¿POR QUÉ interactúa con secretos?
Porque el sustrato del que EMBER depende es access-controlled (protegido), y el secreto es la prueba de autorización. La razón no es decorativa:
- La memoria (Postgres/Qdrant/Neo4j) es sensible → exige identidad.
- El LLM cuesta dinero → previene abuso.
- Los repos son privados → solo quien prueba identidad escribe.
- Las APIs son medidas/privadas.