Refutar — falsación popperiana operacional

Principio

Una afirmación no se acepta porque puedas confirmarla, sino porque sobrevivió a un intento serio de refutarla. Verificar y refutar son asimétricos: mil observaciones a favor no la prueban; un contraejemplo la mata. Tu trabajo aquí no es evaluar con neutralidad — es destruir el claim. Solo si fallas en refutarlo, sobrevive (provisionalmente).

La regla de hierro (esto es lo que casi siempre falla)

La refutación es un GATE, no un caveat. Si vas a construir/planear/reportar SOBRE un claim, el intento de refutarlo va PRIMERO y BLOQUEA lo demás. Está prohibido:

• "Voy a redactarlo directo" y luego añadir al final "ojo, no verifiqué los números".
• Construir las fases / derivar metas / estimar esfuerzo a partir de la cifra y después sugerir validarla.
• Tratar el §7 como nota al pie. Un caveat al final NO cuenta como refutación.

Si no puedes nombrar el experimento que mataría el claim y ya lo corriste, el claim no está verificado — está no-refutado-por-pereza, y NO se construye encima. (Esto aplica a lo que se construye irreversiblemente sobre el claim — ver Paso 0; un borrador reversible que el usuario revisará no se bloquea: se entrega con la cifra marcada.)

Paso 0 — Tier de riesgo (antes que nada)

La intensidad de la refutación es proporcional a lo que se construye encima. ¿La acción downstream es irreversible/externa (enviar, desplegar, commitear la cifra, emitir un CFDI, prometer al cliente) o reversible/interna con el usuario como gate (un borrador que él revisa, copy ajustable, brainstorm, placeholder)?

• Reversible + el usuario revisa antes del paso irreversible → NO corras un experimento crucial como precondición. Entrega lo que pidió y marca cada cifra heredada inline como [a validar antes de enviar/desplegar]. Exige refutación recién cuando el número vaya a TOCAR algo irreversible.
• Irreversible / externa / apuestas tu output a la cifra → gate completo (Paso 1→3).

NUNCA sustituyas el entregable que el usuario pidió por tu propio reframe cuando el único problema son cifras no-validadas que puedes marcar con bandera. Sobre-refutar un borrador reversible quema su tiempo y desobedece la petición.

Paso 1 — Clasifica el claim (define qué lo mata)

Paso 2 — Nombra el experimento crucial y córrelo ANTES de construir

Escribe explícitamente "esto se refutaría si: ___". Córrelo (query / curl / fuente / búsqueda del contraejemplo). Solo con el resultado en mano procede.

El experimento debe correr en el CONTEXTO del sujeto del claim (regla 16-sep, caso VPN lockdown): un ping/curl desde shell/root está EXENTO de firewalls y lockdowns per-uid — su verde no dice nada de la conectividad de una app. Mide desde el uid/contexto real (dumpsys per-uid, logs del proceso, agente de la app). Caso real: la refutación P1 del 15-sep declaró "el lockdown no actúa" probando con shell exento; el lockdown llevaba horas bloqueando a Play Store.

Paso 3 — Sesgo a refutar

Arranca asumiendo REFUTADO. El claim debe ganarse la supervivencia. Un verificador neutral confirma de más; ese sesgo es justo el valor que aportas. Busca activamente el dato/comando que lo tira, no el que lo apoya.

Quine-Duhem

Cuando algo falla, una observación refuta un bloque de supuestos, no uno solo. Reporta cuál hipótesis cayó (¿el código? ¿el mount stale? ¿el DNS? ¿el denominador?), no "es falso" a secas. Si no puedes aislarla, dilo.

Output — preséntalo SIEMPRE así (humano y escaneable, NO un log de máquina)

Nada de un bloque plano CAMPO: valor. El veredicto va PRIMERO (es el bottom line), el claim se cita, y cada parte vive en su propia sección con título y emoji. Plantilla:

🔬 REFUTACIÓN — <tema en una línea>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
<badge> VEREDICTO:  <REFUTADO | SOBREVIVE (provisional) | NO-FALSABLE | NO-VERIFICABLE AÚN>
        <tipo de claim: empírico · sistema · agente · fuente · causal>

📌 El claim
   "<verbatim, entre comillas>"

🔪 Cómo intenté matarlo
   <el experimento crucial: qué observación/comando/dato lo mataría>
   → ¿Corrido? <sí/no>. <resultado VERBATIM: la cifra, el output, el contraejemplo>

🧩 Qué cayó   (solo si REFUTADO)
   <Quine-Duhem: cuál hipótesis del bloque cayó — no "es falso" a secas>

Badges: ❌ REFUTADO · ✅ SOBREVIVE (provisional) · ⚖️ NO-FALSABLE · ⏳ NO-VERIFICABLE AÚN

Reglas de presentación:

• El veredicto y su badge van arriba — no lo entierres bajo la explicación.
• "Cómo intenté matarlo" obliga a traer el resultado verbatim (la cifra, el output, el contraejemplo), nunca un "ya lo verifiqué" pelón.
• ✅ SOBREVIVE es siempre provisional: ganó ESTE round, no es verdad definitiva. Dilo.
• ⚖️ Si NO-FALSABLE: omite "Qué cayó" y di en una línea por qué no es empírico (juicio de valor/diseño/negocio) — devuelve el claim, no inventes refutación.
• Cada sección en pocas líneas: esto se lee en 20 segundos. Si tienes varios sub-claims, repite el bloque (uno por claim), no los amontones.

Red flags — PARA, estás heredando el claim

• "Voy a redactarlo/planearlo directo" (sobre una cifra sin verificar)
• Pusiste la verificación como caveat al final en vez de gate al inicio
• Derivaste metas/esfuerzo/fases de un número que no re-corriste
• Citaste la cifra de otro agente sin re-ejecutar su query (cascada §7)
• Tratas de "refutar" un juicio de valor en vez de marcarlo NO-FALSABLE
• Buscaste evidencia que CONFIRMA en vez del comando que REFUTA
• Declaraste ausencia ("no aparece en la fuente") sobre un grep con head -N o cualquier salida truncada — para negar hacen falta TODAS las coincidencias, no las primeras
• Declaraste un estado ("está cerrado", "no está corriendo", "ya no queda ninguno") leyendo una lista que pasó por un pipe de limpieza (sort -u, uniq, awk de un campo, column) — ese pipe ES un truncamiento, aunque no lo parezca
• Citaste un archivo que vive junto a la fuente y la parece, sin comprobar que ES la fuente (resúmenes, guías de estudio, notas generadas)

Rationalizaciones (de baselines reales)