update(episode): TRAZA_4-commits-temticos-push-triple-remoto-1_S20260726.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Skill: NONE | Type: troubleshooting
Summary: EPISODIO 1 — MNEMO_PRE_DIGEST: 4 commits temáticos + push triple remoto (1.0,...

episodes/TRAZA_4-commits-temticos-push-triple-remoto-1_S20260726.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md

@@ -16,14 +16,21 @@ relectura_tagged: false
 forgejo_commit_sha: "pending"
 ---
 
-4 commits temáticos + push triple remoto (1.0, verificado) | respaldo_limpieza --APARTADO_A--> scratchpad, 14 archivos preservados, 0 en git (1.0) | verificador --DETECTA--> VIGENTE con mundo intacto y REVALIDAR con hash cambiado, señalando la condición exacta (1.0, E2E real) | condiciones_declarativas --EVITAN--> ejecución de código arbitrario desde documentos (1.0, 2 tests del vector) | otra_instancia --COMMITEO_EN_PARALELO--> 2e57adb0 durante la sesión (1.0, git log)
+Tomé una muestra **5 veces más grande** que la original para que el dato pese más:
-negated_concepts: NO se versionaron los 59 cambios heredados (solo los 11 propios, declarado y reversible); NO se borró el respaldo, se apartó; NO existe aún la regla de fe pública (solo la capa mecánica, orden deliberado); NO se enganchó el materializador ni el verificador a ningún hook; NO se selló ningún documento real todavía
-epistemic_summary: hard_fact = los 4 commits con sus hashes, los 3 push OK, los 14 archivos preservados, 12 tests verdes y la demostración E2E con sus dos resultados opuestos — todo con tool result de este turno. inference = que sellar 2-3 documentos antes de normar es mejor que normar primero; presentado como consejo, no como hecho. Decisión declarada y reversible: se asumió el alcance "solo lo mío" porque la pregunta de R7 quedó sin respuesta explícita, avisando a John de que puede añadirse un cuarto commit. -->
 
-# 🔓 Pre-check de DC-6 hecho — **la grieta quedó cerrada**
+| | Canon vivo (hoy) | Fixture del branch |
+|---|---|---|
+| Puntos leídos | **500** | 100 |
+| `ref` es un número | **490 → 98.0%** | 99 → 99.0% |
+| `ref` es una lista | 10 → 2.0% | 1 → 1.0% |
+| Sin el campo | **0** | 0 |
 
-📄 [PRECHECK_DC6_S20260726.md](docs/PRECHECK_DC6_S20260726.md) · commits `2e57adb0` + `e882ea38` en los 3 remotos ✅
+Misma distribución. **Y el hallazgo del ciclo 4 se confirma en producción:** ese campo es un contador numérico, no la lista que el diseño suponía. Si el writer hubiera escrito una lista encima, habría corrompido el contador en el 98% de los hechos — calladamente. **Un dato nuevo que salió del muestreo grande:** existe un 2% donde ese campo **sí** es una lista. O sea, el canon guarda las dos semánticas bajo el mismo nombre — lo que **refuerza** el diagnóstico original. Verifiqué en el código del branch si eso abría una grieta nueva: **no**. El writer corregido nunca lee ni escribe ese campo, solo acumula en el campo nuevo `ref_paths`, así que le da igual el tipo. El 2% queda cubierto sin una línea más. **Cero escrituras a producción** — todo fue lectura. Y declaré una limitación honesta: los 500 puntos son el primer lote del scroll, no una muestra aleatoria uniforme; sirve para "¿la fixture representa el canon?" (mismo método, comparación entre iguales), no para una estimación poblacional exacta. ## [R16.seccion2.T1] Cómo queda tu dossier de DC-6
 
-## [R16.seccion1.I1] El resultado, en llano
+| Pata | Estado |
-
+|---|---|
-Fui a mirar la memoria de producción con datos de hoy, y **la fixture con la que se probó el writer sí representa la realidad**.
+| El bug del campo `ref` es real | ✅ verificado **y confirmado en producción** |
+| La fixture representa el canon vivo | ✅ **CERRADA hoy** (era la única no verificable) |
+| La corrección es conservadora | ✅ verificada **y probada agnóstica al tipo** |
+| Branch sin merge ni deploy | ✅ intacto |
+| Contador que "prueba" cero escrituras | 🔴 **sigue siendo decorativo** (T-99) |