ember-memory-test/episodes/DEPURA_g-1-resuelto-camino-b-confirmado-con-ev_S20260605.R4_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.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
2e85a9af-52b2-4214-9636-9fcac02c27c9	DEPURA_g-1-resuelto-camino-b-confirmado-con-ev_S20260605.R4_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260605.AGENTES_READINESS_PIPELINE	informar	multi_actor	low	TESSERA	operations	design	EPISODIO 4 — PostgreSQL: G-1 RESUELTO → **Camino B confirmado con evidencia del vivo*	claude_code	internal	2026-06-06T06:01:37.099091+00:00	false	pending

G-1 RESUELTO → Camino B confirmado con evidencia del vivo (NO es bug, NO toca prod)

La investigación que pediste está completa. El puente_flat no falta por bug — los dos stores se direccionan distinto por diseño:

Store	Clave de direccionamiento	Evidencia (hard_fact, vivo)
Qdrant	codex_ref (NO puente_flat)	crisol vivo crisol_run.py:436-440 payload usa codex_ref · payload real = 18 keys sin puente_flat
PostgreSQL	puente_flat (PK, NO codex_ref)	crisol vivo :667-701 INSERT + ON CONFLICT (puente_flat) · postgres_query devolvió 3 puente_flat poblados · la columna codex_ref no existe en PG

★ Insight ─────────────────────────────────────

• Arquitectura real: Qdrant↔codex_ref, PostgreSQL↔puente_flat. Son llaves complementarias en stores distintos, no la misma llave en un store.
• El gap NO está en el pipeline — está en la doctrina del skill: lista "PUENTE flat" como 4ª vía sin decir que es un filtro PostgreSQL. El agente la probó en Qdrant (store equivocado) → 0 falso negativo.
• Por esto investigué antes de tocar prod: evité un cambio innecesario al pipeline vivo + backfill de 3644 episodios. El fix real es doc barato, no D-ARCH. ─────────────────────────────────────────────────

El fix de G-1 ahora es barato (doc), no producción

Corregir la imprecisión en la doctrina de las "4 vías" para que cada vía declare su store correcto:

Vía	Store correcto
(a) Semántica	Qdrant
(b) NOMENCLATURA / session_code	Qdrant (payload)
(c) PUENTE flat	PostgreSQL (columna puente_flat) ← antes mal atribuida a Qdrant
(d) parent_response	Qdrant (payload)

Archivos a tocar (doc): skills/mantenimiento-memoria-agent/CLAUDE.md (descripción 4-vías) + templates/INFORME_POST_LABOR_TEMPLATE.md (tabla §3.1) + verificar si rules/multi-store-retrieval.md (MS-2) ya lo dice bien (si sí, solo el skill).

Pregunta esencial (tú decides): ¿aplico ya la clarificación doc de las 4-vías por-store (skill + template, + reviso la regla), cerrando G-1 como Camino B — o lo dejas registrado y seguimos con T-003 cron / T-002 hooks?

Mi inclinación: aplicarlo ya (es barato, cierra el gap correctamente, y deja al agente con una doctrina precisa antes de dejarlo solo con el cron). Pero como toca el skill otra vez (fricción del gate SENTINEL), confirmo contigo antes.

📌 PILA-PENDIENTES (R2) — COMPACT

🟢 Z-007 [R2] G-1 investigado → resuelto = Camino B (dual-store por diseño, evidencia crisol vivo + PG) ✅ 🟡 G-1-fix [R2] clarificar doctrina 4-vías por-store (skill + template + ¿regla?) — barato, pendiente tu OK 🟡 T-007 [R31] commit acotado fixes G-2+G-3 (+ G-1-fix si lo aplico) [pendiente OK] 🟠 T-003 cron A/B · T-002 FASE 3 hooks [pendientes] ❓ — (1: ¿aplico G-1-fix doc ahora + commit, o sigo con T-003/T-002?)