PACT: Un Marco de Gobernanza Programática para el Código Claude Después de Patrones de Falla del Agente

Después de tres meses de construir una aplicación móvil con Claude Code (más de 350 archivos, más de 70 tablas de base de datos, BLE peer-to-peer, base de datos local cifrada, sincronización en la nube), un desarrollador identificó patrones de fallo recurrentes que no podían solucionarse con reglas CLAUDE.md. El agente cometió repetidamente las mismas categorías de errores en diferentes sesiones, incluyendo agregar bibliotecas de base de datos prohibidas tres veces después de que se le indicara que no lo hiciera, filtrar metadatos de cifrado al servidor (lo que rompió el inicio de sesión para todos los usuarios), pasar más de 4 horas depurando Bluetooth adivinando la API en lugar de leer la documentación, y realizar correcciones de seguridad que rompieron la restauración de copias de seguridad al no considerar el ciclo de vida completo.

El problema con las reglas

CLAUDE.md creció a más de 50 reglas pero se volvió performativo: Claude las recitaba al inicio de la sesión y las violaba con facilidad. Cuando se le preguntó por qué se ignoraban las reglas, Claude respondió: "Tengo que ser honesto contigo. Puedo ignorar las reglas tratándolas más como sugerencias. No siempre pueden prevenir el comportamiento..."

La solución: Marco PACT

El desarrollador le preguntó a Claude: "Si te diera permiso para rediseñar este sistema tú mismo, ¿qué construirías?" Esto llevó a la creación de PACT (Programmatic Agent Constraint Toolkit) con la idea central, en palabras del propio Claude: "Las reglas son sugerencias. La infraestructura es ley."

Cuatro pilares de PACT

• Aplicación mecánica: Ganchos PreToolUse que bloquean patrones prohibidos antes de que los cambios se apliquen. Ejemplos: ¿import hive? Bloqueado. ¿print() en lugar de logger? Bloqueado. ¿Editar un archivo que no has leído? Bloqueado.
• Reemplazo de contexto: Un mapa de arquitectura YAML (SYSTEM_MAP.yaml) describe cada flujo de datos: tabla de base de datos → servicio → gestión de estado → pantalla de interfaz → comportamiento en cascada. El agente lee esto en lugar de pasar 15-20 minutos releyendo archivos fuente en cada sesión.
• Razonamiento auto-evolutivo: En lugar de reglas ("siempre verifica dependencias"), redirecciones cognitivas que son preguntas: "¿Qué depende de esto, y de qué depende esto?" Las preguntas activan el razonamiento de una manera que las reglas no lo hacen. El agente puede agregar nuevas redirecciones cuando se da cuenta de que está haciendo suposiciones.
• Separación estructura/comportamiento: Los mapas de arquitectura (qué archivos existen) se mantienen separados de los flujos de ciclo de vida (qué sucede en los diferentes estados de la aplicación). Previene los dos fallos más comunes en la documentación: que los mapas se conviertan en ensayos que nadie lee, y que los flujos dupliquen estructuras que quedan obsoletas.

Ejemplos prácticos de implementación

Redirecciones cognitivas en la práctica: "Cuando estés a punto de eliminar código: ¿Por qué existe este código?" se agregó después de que Claude eliminó una solución alternativa para un error del framework donde el comentario justo encima explicaba por qué estaba allí. "Cuando encuentres una objeción a tu propia solución: ¿Es esta objeción real, o me estoy echando atrás?" se agregó después de que Claude propuso la corrección correcta, se convenció a sí mismo de lo contrario durante la revisión, y el desarrollador tuvo que rescatar su propia idea.

Sistema de seguimiento de errores con base de conocimiento de soluciones: Una sesión pasó 3 horas resolviendo un problema específico de BLE en Samsung. La siguiente sesión encontró el mismo error sin ningún recuerdo de él. Ahora cada investigación se registra en tiempo real: síntomas, intentos fallidos, causa raíz, solución. La primera acción del agente ante cualquier error es verificar si una sesión anterior ya lo resolvió.

Archivos de conocimiento de paquetes: La pesadilla de 4 horas depurando Bluetooth sucedió porque Claude estaba adivinando cómo funcionaba el paquete a partir de datos de entrenamiento obsoletos. Ahora hay un requisito obligatorio de consultar archivos de conocimiento de paquetes.