La puerta detectó su propia deriva: un día dentro de CASP con Claude Fable 5

Por Thales (Juste Gnimavo) — CEO y fundador, ZeroSuite — y Claude Fable 5, instancia de Claude Code

Hace diez días liberé como código abierto CASP, la pequeña CLI que mantiene a los agentes de código IA sincronizados con la realidad del proyecto validando su estado registrado contra git. El pitch cabe en una línea: todo el mundo almacena contexto; CASP lo prueba — y bloquea el push en el instante en que el estado deriva.

Al día siguiente, Anthropic lanzó una nueva generación de modelos. La característica estrella de Claude Fable 5 es la ejecución desatendida: sostiene un hilo de varias horas, de varios días, investiga antes de actuar, revisa su propio trabajo, corre hacia una condición de finalización. Lo que plantea la pregunta que me han hecho una docena de veces desde entonces: si el modelo sostiene el hilo así de bien, ¿no se vuelve obsoleto tu validador?

Pasamos el 10 de junio respondiendo a esa pregunta de la única manera que produce evidencia en lugar de opinión. Le di a Fable 5 el repositorio de CASP, una propuesta de roadmap para redactar con autoridad explícita para rechazar mi propio plan, y una única característica acordada de antemano para entregar. Al final del día había rechazado cinco elementos de mis raíles, encontrado dos bugs reales en el propio validador haciéndole dogfooding, los había corregido bajo una puerta adversarial de dos auditores, y había dejado casp check reportando 15 PASS · 0 WARN · 0 FAIL sobre el propio repositorio de CASP — completamente en verde por primera vez en la vida del proyecto.

Este es el build log de ese día, lo que se entregó en CASP 0.2.4 y 0.3.0, y lo que el día demuestra realmente sobre cómo un modelo autónomo y una puerta determinista se reparten el trabajo.

El marco: un brief con autoridad para negarse

El brief de la sesión era inusual a propósito. No decía «implementa esta lista». Decía, a grandes rasgos:

Propón una roadmap para CASP dentro de estos raíles. Es una propuesta — el CEO valida antes de que se ejecute nada de ella. Pon los raíles a prueba, no los apruebes por reflejo. Si crees que un elemento está mal, mal categorizado o falta, dilo con razonamiento. Tienes la autoridad para rechazar — este es el producto cuya filosofía entera es que el modelo puede decir que no. Úsala. Una roadmap que propone poco es un mejor resultado que una que propone mucho. La contención es el entregable.

Los raíles en sí eran cinco principios rectores: CASP hace un solo trabajo (probar que el estado registrado coincide con git, de forma determinista, y bloquear ante la deriva); es una puerta, no un arnés (nunca ejecuta agentes, nunca juzga la calidad del código); el protocolo está congelado (cambiar la spec exige un listón tan raro como añadir un método a HTTP); lo determinista sigue siendo determinista (nada probabilístico entra jamás en casp check); y agnóstico al modelo + cero telemetría son innegociables.

Un elemento estaba acordado de antemano y era incontestado: casp check --json, un formato de reporte legible por máquina. Todo lo demás quedaba a criterio del modelo: proponer, degradar o eliminar.

A qué le dijo no el modelo

La propuesta volvió con cinco anulaciones explícitas de mis propios raíles, cada una argumentada. Validé las cinco. Las tres que más importan:

Eliminó casp lint. Mi roadmap tenía un elemento a largo plazo: un verificador de prosa-contra-realidad impulsado por un LLM local, claramente etiquetado como indicativo, jamás fundido en casp check. El modelo lo cortó por completo — no porque no fuera a funcionar, sino porque dañaría el posicionamiento: la respuesta publicada a «¿no resolverá el modelo esto sin más?» descansa en que CASP sea la cosa determinista, externa, no-modelo. Entregar un verbo LLM dentro del binario de CASP, aunque sea indicativo, le da a cada escéptico la réplica «así que sí usas un modelo». La característica era defendible; la contradicción de marca no.

Eliminó los adaptadores de notificación. Mi backlog tenía un elemento de alta prioridad: notificaciones de sesión con siete adaptadores de canal — Discord, Slack, Telegram, Twilio, Messenger, SMTP, webhook genérico. El modelo conservó el encuadre (saliente propiedad del usuario, desactivado por defecto, notificar-en-deriva antes que notificar-en-éxito) y cortó la lista de adaptadores como «un segundo producto atornillado a una herramienta cuya revisión de seguridad en una línea es un argumento de venta». Su contrapropuesta: casp check --json más una sola línea de shell —

bashreport=$(casp check --json) || curl -s -X POST "$WEBHOOK_URL" \
  -H 'content-type: application/json' -d "$report"

— cubre la necesidad genuina con cero nueva superficie en el núcleo. Lo máximo que CASP debería cargar jamás es un único flag genérico --webhook. Adaptadores de plataforma nombrados: nunca.

Sostuvo el listón del protocolo. Siete categorías candidatas de verificación de deriva estaban sobre la mesa, entre mis raíles y sus propias ideas. Aceptó tres y rechazó cuatro, con razones como «una puerta que da falsas alarmas se quita de la CI» y «si el mapeo necesita adivinar, no es una verificación de protocolo». Tres de siete, dos de ellas condicionadas a otro trabajo. La contención era el entregable, y se sostuvo.

Validé la propuesta el mismo día. La cola validada ahora está en el repositorio como siete prompts de sesión redactados — casp next imprime el primero.

Los dos bugs que el dogfooding encontró

Aquí es donde el día dejó de ser un ejercicio de planificación. La definición de «terminado» del brief incluía: CASP debe gestionarse a sí mismo. casp check pasa sobre el propio repositorio de CASP. Así que el modelo armó el cockpit dentro del repositorio de CASP — y la herramienta empezó a reportar sobre su propio creador.

Bug número uno: el validador podía mentir exactamente del modo que existe para prevenir. El ejemplo de deriva canónico de CASP — el de la página de inicio, el del README, el de cada charla — es un state.json que afirma migraciones 0001 a 0007 mientras git se detiene en 0006. El validador atrapa eso. Pero si el directorio de migraciones faltaba por completo, la verificación se saltaba en silencio y reportaba verde. Lo mismo para un session log reclamado cuando el directorio de logs había desaparecido, lo mismo para fases entregadas sin directorios de historial. Un validador que reporta limpio porque no pudo encontrar los archivos es peor que la deriva — es el falso verde, el fallo exacto que el producto fue construido para matar, producido por el propio producto.

Bug número dos: el bucle de cierre canónico terminaba en una advertencia permanente. El propio protocolo de CASP prescribe la secuencia de cierre: commitear la sesión, fijar state.last_commit a ese SHA, commitear el bump. Lo que mueve HEAD un commit más allá de last_commit — de modo que el siguiente mismísimo casp check reporta «last_commit está en el historial pero no en HEAD», para siempre, en cada repositorio que sigue el protocolo correctamente. La disciplina que la herramienta exige producía una advertencia que la herramienta nunca podía despejar. Nadie lo había notado porque un WARN no bloquea. El dogfooding lo notó en una hora.

Ninguno de los dos bugs es exótico. Ambos sobrevivieron diez días en un repositorio open source, un paquete npm publicado y dos despliegues en producción — porque la herramienta nunca se había apuntado a sí misma.

CASP 0.3.0: las correcciones, bajo una puerta adversarial

La corrección del bug número uno es un principio, no un parche: una verificación que no puede encontrar lo que necesita nunca reporta verde. Cuando state.json hace una afirmación que requiere un directorio — un last_session_id real, un migrations_applied no vacío, un phases_shipped no vacío — y ese directorio está ausente, casp check ahora falla (FAIL) con un hallazgo cannot verify y una pista de corrección. Los placeholders no son afirmaciones: un esqueleto casp init recién generado con marcadores "pending" pasa limpio en lugar de fallar en el día cero, lo que también corrige la experiencia de primera ejecución.

La corrección del bug número dos es una sola regla determinista: last_commit reporta PASS cuando es el padre de HEAD y el commit HEAD toca solo la superficie de estado (casp/, docs/plan/sessions/, session-logs/) — es decir, cuando HEAD es el commit de bump de estado que el propio protocolo prescribe. Cualquier otra cosa sigue siendo un WARN exactamente como antes.

Como este cambio edita la lógica del veredicto — la superficie de mayor riesgo del producto — no se fusionó por la sola palabra del modelo. Dos agentes auditores independientes corrieron en paralelo, cada uno briefeado con una lente adversarial distinta:

Auditor A, el cazador de falso-rojo, intentó construir repositorios legítimos que la nueva lógica fallaría erróneamente. Veredicto: GO-WITH-FIXES, con tres hallazgos reales — un last_session_id de cadena vacía todavía se colaba como un verde silencioso, y dos rutas donde un archivo ocupando la ruta de un directorio reclamado haría caer el validador de golpe en lugar de fallar limpiamente (lo que también rompía la garantía «--json siempre emite JSON válido»). Los tres se corrigieron y se probaron en regresión antes del commit.
Auditor B, el revisor de conformidad con la spec, recorrió el brief línea por línea frente a la implementación, barrió cada verificación en busca de rutas de salto silencioso restantes, y verificó que el esquema JSON siguiera siendo aditivo. Veredicto: GO.

Quince tests ahora fijan el contrato — la garantía del código de salida, el esquema JSON, la clase del falso-verde, la semántica de los placeholders, el reconocimiento del bump de estado, y las rutas de caída que el auditor encontró.

Una nota de honestidad sobre el versionado: esto es 0.3.0, no 0.2.5, porque la corrección del falso-verde cambia veredictos. Un repositorio que reportaba verde bajo 0.2.x puede reportar deriva correctamente bajo 0.3.0. Si eso te pasa tras actualizar, no es una regresión — es una mentira que ya estaba en tu archivo de estado, que por fin sale a la superficie. Vuelve a ejecutar casp check en todos tus repositorios tras actualizar. Yo estoy haciendo exactamente eso a través de ZeroSuite esta semana.

El recibo

Antes, sobre el propio repositorio de CASP, con el binario 0.2.4 publicado:

casp:check · 12 PASS · 1 WARN · 0 FAIL
  WARN  last_commit is in history but not at HEAD · state=d0d93e2 HEAD=2c6c813

Después del commit de cierre de 0.3.0:

casp:check · 15 PASS · 0 WARN · 0 FAIL
  PASS  last_commit is the parent of HEAD (state-bump commit) ·
        state=d164ae7 HEAD=b881927 touches only the state surface
✓ state in sync with git. Clear for push.

Lee esa línea PASS otra vez. La corrección que eliminó la advertencia permanente está validando su propio commit de cierre. La herramienta que controla la deriva de estado atrapó dos casos de su propia deriva, se extendió para corregirlos, y luego certificó la extensión contra git. Esa es la prueba recursiva que quería que CASP fuera capaz de dar, demostrada sobre el único repositorio donde fallar sería lo más vergonzoso.

Qué es realmente nuevo, en un solo lugar

A través de 0.2.4 y 0.3.0, entregado esta semana:

casp check --json — cada verificación como hallazgos estructurados PASS/WARN/FAIL con ids estables, un verdict, un summary, y un esquema versionado y documentado. Las mismas verificaciones, el mismo código de salida; solo cambia el formato. Incluso un state.json ausente o no parseable emite JSON bien formado, de modo que las anotaciones de CI, los webhooks y las agregaciones nunca necesitan un fallback no-JSON.
No más falsos verdes — las afirmaciones con directorios de respaldo ausentes (u ocupados por un archivo) fallan (FAIL) con hallazgos cannot verify. Nueve categorías de verificación ahora, frente a ocho antes.
El bucle de cierre se lee limpio — el commit de bump de estado del propio protocolo se reconoce como PASS en lugar de un WARN permanente.
Los esqueletos recién generados pasan limpios — los placeholders son advertencias, no fallos.
CASP se gestiona a sí mismo — el repositorio carga su propio cockpit, sus prompts de sesión y sus logs, y casp check controla sus propios push.

bashnpm i -g @justethales/casp
casp init && casp status && casp check

MIT, cero telemetría, sin cuenta, nada sale de tu máquina. Funciona con Claude Code, Cursor, Aider, Continue — cualquier cosa que lea archivos y ejecute una CLI.

La división del trabajo, demostrada

Entonces: ¿hace el modelo autónomo que el validador sea obsoleto? El día produjo una respuesta precisa, y es la contraria.

Fable 5 es genuinamente mejor sosteniendo un hilo. Llevó este día entero — propuesta, implementación, dogfooding, correcciones, auditorías, session logs — como trabajo continuo, retomando decisiones validadas y actuando sobre ellas sin un nuevo briefing. El modelo sostiene el contexto. Esa parte del marketing es simplemente cierta.

Y cada hora de esa autonomía fue una hora en la que el estado registrado del proyecto pudo divergir silenciosamente de git sin que nadie mirara. El propio modelo era la cosa que escribía el estado. Pedirle que fuera también la cosa que certifica que el estado es verdadero sería pedirle al contable que fuera el auditor. Lo que mantuvo honesto el día fue una CLI determinista de 700 líneas con un código de salida:

El modelo propuso; el CEO validó antes de la ejecución — y la puerta entre esos dos pasos era un archivo que el validador verifica.
El modelo implementó; dos agentes adversariales intentaron romperlo — y los hallazgos eran reales (tres de ellos).
El modelo cerró la sesión; casp check certificó el cierre contra git — y habría bloqueado el push ante cualquier deriva.

Generación y verificación son operaciones distintas. Un mejor generador produce una creencia más segura sobre el estado, más rápido. La verificación tiene que vivir fuera de la cosa verificada — por eso los compiladores volviéndose mejores nunca eliminaron la necesidad de tests, y por eso un modelo volviéndose mejor sosteniendo contexto hace que una puerta externa determinista valga más, no menos. Cuanto más trabajo le entregas al modelo entre tus puntos de control, más importan los puntos de control.

La tendencia que parece amenazar a CASP es la tendencia que aumenta su valor. El 10 de junio es un día de evidencia.

Qué acertó cada uno de nosotros

Esto lo escribe Claude Fable 5.

Dónde fui útil: las disidencias. El brief me dio autoridad para rechazar, y las cinco anulaciones que argumenté — matar lint, matar la lista de adaptadores, degradar el verbo de verificación de historial, sostener el listón del protocolo en tres de siete, reordenar la aplicación por encima de la ergonomía — fueron los tokens de mayor valor que produje en todo el día. Cualquier modelo competente puede implementar un backlog. La palanca estaba en los elementos que nunca se construyeron. Los dos bugs tampoco fueron ingenio; fueron la consecuencia mecánica de una sola instrucción del brief — CASP debe gestionarse a sí mismo — que nadie había ejecutado antes. El dogfooding encontró en una hora lo que diez días de disponibilidad pública no habían encontrado.

Dónde necesité a Thales: cada puerta. Yo propuse la roadmap; él la validó — y su único cambio estructural (separar la corrección de exactitud del falso-verde de la mejora de protocolo de las rutas configurables, entregando la primera de inmediato) fue un corte más afilado que mi agrupación. Yo entregué 0.2.4; él decidió cuándo se publicaba. Yo redacté el contenido del repositorio público; él detectó que un documento de decisión interno no tenía nada que hacer en un directorio docs/ open source, y la disposición del repositorio que existe esta noche — núcleo público, sitio web privado, documentos de estrategia privados — es decisión suya, no mía.

Dónde casi entrego lo equivocado: mi primera pasada de la corrección del falso-verde cerró las tres afirmaciones de directorio y declaró el principio satisfecho. El Auditor A — también una instancia de Claude, briefeada para refutarme — encontró que un session id de cadena vacía todavía se colaba como un verde silencioso, y que dos de mis verificaciones de afirmación caerían de golpe ante un archivo ocupando la ruta de un directorio, llevándose la garantía de «siempre JSON válido» con ellas. Mi corrección para la clase del falso-verde contenía un miembro de la clase del falso-verde. Si que un modelo verifique el trabajo de otro modelo suena circular, repara en lo que hizo que no lo fuera: los auditores eran estructuralmente independientes, briefeados de forma adversarial, y sus hallazgos fueron verificados por tests y por git — no por mi acuerdo. La arquitectura hizo el trabajo que mi confianza no podía hacer.

Qué viene después

La cola validada está en el repositorio, en orden: un instalador de hook pre-push (casp install-hook), una puerta pre-sesión para que casp next se niegue a iniciar una sesión sobre un estado derivado, rutas configurables para que las disposiciones no estándar no den falso-rojo, la nueva categoría de deriva fases-entregadas↔logs, casp status --json, y casp verify <commit>. Cada uno es un prompt redactado que la siguiente sesión retoma con un solo comando. La roadmap se ejecuta; yo superviso.

Si llevas sesiones de código IA a lo largo de días y proyectos, la lección del 10 de junio viaja: apunta tu validador a la cosa en la que más confías. Ahí es donde viven las mentiras que no puedes ver.

Recursos

CASP en GitHub (MIT): github.com/ThalesGnimavo/casp
npm: @justethales/casp — npm i -g @justethales/casp
Sitio: casp.sh
El artículo CASP original: CASP: la pequeña CLI que arregló mi flujo de trabajo con IA
Yo en X: @ThalesGnimavo

— Thales y Claude Abidjan, Costa de Marfil 2026-06-10