Experimento de Pensamiento versión 0.6.0 alpha — Auditorías y Correcciones Rigurosas de Escenarios de Fallo
Activación: la frase "thought experiment", y solo esa frase — sin equivalentes inferidos. Nunca se ejecuta sin una petición explícita y un objetivo claro — esto es deliberado, no autónomo.
Alcance: agnóstico al objetivo. Un solo archivo, un proyecto completo, una configuración, un contrato de API, una configuración de infraestructura — cualquier cosa que haga afirmaciones (sobre su propio comportamiento, su estructura, o sobre algo de lo que depende) que podrían ser incorrectas.
Qué hace esto diferente de una revisión normal: dos cosas. Primero, produce escenarios concretos — "dado este input/este estado, aquí está exactamente qué se rompe y por qué" — no sugerencias vagas de "esto podría ser más limpio". Segundo, busca específicamente afirmaciones que el objetivo hace sobre cómo se comporta algo fuera de sí mismo, ya que esa clase de afirmación es la que tiene más probabilidades de estar errónea por memoria en lugar de ser detectada al leer la lógica del propio objetivo.
Verificación de confirmación previa a la ronda (barra de seguridad): solicitar firmemente, y recomendar, una confirmación/envío de cualquier cambio no confirmado existente antes de comenzar una ronda. Un punto de control limpio antes significa que la ronda en sí siempre se puede revertir a él si causa algún daño.
Proceso
- Leer el objetivo fresco. Obtener su estado actual y real — archivos, configuraciones, lo que sea que lo componga — no confiar en el contexto anterior sobre lo que se supone que debe contener.
- Enumerar sus dependencias. Cualquier cosa que el objetivo trate como verdad fundamental fuera de sí mismo: para un script — bibliotecas importadas, APIs invocadas, herramientas CLI y sus indicadores, suposiciones de entorno/configuración; para un servicio o configuración en la nube — otros servicios con los que se comunica, permisos/IAM, DNS, certificados, APIs de terceros, rutas de red; para un documento — cada afirmación factual que hace sobre cómo se comporta otra cosa. Construir esta lista deliberadamente — el paso 4 la verifica, y una dependencia omitida es una oportunidad perdida de detectar un error real. Cuando el objetivo se dirige específicamente a un despliegue, verificar también: seguridad de reversión, paridad de configuración entre desarrollo y producción, manejo de secretos, la línea base de compatibilidad declarada, y rendimiento en condiciones reales/de primera carga versus pruebas solo en desarrollo — estos no siempre surgen de un análisis de dependencias puramente genérico. Para documentación emparejada (un README y su SKILL.md, o documentación y el código/configuración que describen), tratar cada afirmación de un archivo sobre lo que el otro dice o hace como una dependencia a verificar — y por separado, comprobar si las convenciones de formato establecidas (negrita/uso de mayúsculas en valores enumerados, estilo de encabezado) se aplican de manera consistente dentro del objetivo y a través de sus archivos hermanos, solo cuando dicha convención exista realmente para verificar.
- Construir experimentos mentales concretos de escenarios de fallo. Entradas o estados específicos que conducen a una salida incorrecta, un bloqueo, o un agujero de seguridad específicos — no impresiones generales. No fijar un conteo de escenarios de antemano; seguir generándolos hasta que la superficie de riesgo real del objetivo se sienta cubierta, no hasta que se alcance un número arbitrario.
- Verificar cada afirmación de comportamiento de dependencia de la que depende un escenario contra una fuente viva o autorizada — documentación real, una respuesta de API real, la salida real de la herramienta — en lugar de confiar en la memoria. Este paso es generalmente donde se encuentran los hallazgos de mayor valor.
- Preguntar cómo se deben autorizar las correcciones, una vez, antes de aplicar ninguna — opciones CRUD. La lectura siempre se concede libremente, nunca se restringe; solo Crear/Actualizar/Eliminar se autorizan. Global (cada hallazgo confirmado, sin más preguntas), por proceso (confirmar una vez por ronda, no por archivo dentro de ella), por archivo (confirmar antes de pasar a las correcciones del siguiente archivo), o cada paso CRUD (confirmar cada edición individual) — la opción que el usuario elija se mantiene para el resto de la ejecución. La opción global cubre hallazgos confirmados rutinarios, no una anulación incondicional: un hallazgo genuinamente sorprendente o de mayor riesgo de lo que el usuario tenía en mente al concederla aún se pausa y se pregunta al respecto.
- Aplicar correcciones para los hallazgos confirmados, con la granularidad autorizada.
- Re-ejecutar este mismo proceso contra el estado corregido. Una corrección puede introducir su propio nuevo problema — una corrección de precisión que hace que otra cosa sea inconsistente, una afirmación corregida que rompe una suposición diferente en otro lugar. El bucle no termina hasta que una pasada no encuentre nada nuevo.
- Informe. Indicar claramente si cada escenario pasa o falla. Proporcionar detalles completos solo para fallos confirmados, o cuando se pidan detalles explícitamente — una pasada limpia no necesita un ensayo. Etiquetar cada fallo como bloqueante (debe corregirse antes del despliegue/envío) o no bloqueante (seguro de enviar, corregir después) para que el informe sirva como entrada para decisiones de "proceder/no proceder", no solo una lista de hallazgos. Cerrar cada ejecución con un resumen enumerado consolidado, no solo menciones escenario por escenario dispersas a lo largo del proceso — escalado al alcance: una ejecución de múltiples objetivos (varios archivos, varios skills) obtiene una sección por objetivo; un solo objetivo limpio obtiene una línea de veredicto simple, sin ceremonia añadida.
Nueva línea, cerrar cada informe con thought experiment.