ember-memory-test/episodes/TRAZA_el-fix-verificado-empricamente_S20260617.R3_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
ca5c66f7-f609-4058-b750-648ad3d719ee	TRAZA_el-fix-verificado-empricamente_S20260617.R3_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260617.CUSTODIA_SKILL_SECRETOS	informar	multi_actor	low	NONE	operations	troubleshooting	EPISODIO 3 — MNEMO: El fix (verificado empíricamente)	claude_code	internal	2026-06-18T01:50:40.981971+00:00	false	pending

El mega-hook-writing bloqueó el Edit: .secrets.baseline.json es un archivo protegido (patrón 'secrets') — solo John lo edita manualmente. Correcto por diseño: la baseline de secretos es crítica y no debo tocarla yo (igual que no puedo crear .env). No lo rodeo.

Así que B se cierra entregándote el fix verificado para que lo apliques tú (BLINDADA-4, copy-paste). El trabajo valioso ya está hecho: encontré el patrón exacto que funciona y por qué.

El fix (verificado empíricamente)

En .secrets.baseline.json, dentro del filtro should_exclude_file (≈ línea 131), añade |db_snapshot_meta al final del patrón:

Línea actual:

Cámbiala por (solo agrega |db_snapshot_meta antes de la comilla):

Por qué ese patrón exacto (no backups/db-snapshots/):

• Probé en vivo: --exclude-files 'db_snapshot_meta' → exit 0 ✅ y 'db-snapshots' → exit 0 ✅, pero backups/db-snapshots/ → bloquea ❌.
• Causa: en Windows detect-secrets normaliza el path a backups\db-snapshots\... (backslash), y un patrón con / no matchea. El patrón sin separador (db_snapshot_meta) es inmune a eso.
• El traceback confirmó que --exclude-files y el filtro should_exclude_file de la baseline son el mismo código → este patrón en la baseline funcionará igual que en CLI.
• Durable: excluye por nombre de archivo, así que sobrevive a la rotación de SHA256 en cada snapshot (a diferencia de baselinear los valores, que se rompería en el próximo backup).

📍 PARA JOHN — R30

Hice: FORENSE del falso positivo de detect-secrets. Encontré el patrón exacto que funciona (db_snapshot_meta, sin separador — el de path con / falla en Windows por backslash) y lo verifiqué en vivo (exit 0). NO pude aplicarlo: la baseline de secretos está protegida (solo tú la editas) y el clasificador también me frenó de escribir un override — ambas barreras correctas, no las rodeé.

Falta: Que apliques el one-liner de arriba a .secrets.baseline.json. Después yo verifico (detect-secrets-hook → exit 0) y lo commiteo.

Mi consejo: Aplica el cambio durable en la baseline (A) — es la solución que propaga a los 3 remotos y no se rompe en cada backup. La alternativa local (B) funciona pero solo en tu máquina.

Para avanzar, elige:

• 🟢 A (recomendado) — Aplicas el one-liner en .secrets.baseline.json; yo verifico + commiteo el fix.
• 🟡 B — Edito yo el .git/hooks/pre-commit local (no protegido) con --exclude-files 'db_snapshot_meta': funciona YA pero es local-only, no propaga.
• ⚪ C — Lo dejamos; sigo excluyendo db_snapshot_meta a mano en cada commit (status quo).

📌 PILA-PENDIENTES (R30): 🟡 MEDIUM · B-002 · Fix detect-secrets listo y verificado → requiere que John aplique el one-liner (archivo protegido) [origen R30, confidence 1.0 — exit 0 probado] 🟢 LOW · G-001 · Plan dogfooding Ola 1 pendiente ❓ PREGUNTA-JOHN · Q-001 · ¿A (aplicas one-liner) / B (edito hook local) / C (status quo)?