Arquitectura auditable · Unidad 9 de 9
La ley visible del pipeline de tools
ADR#13 parte de una tesis simple: primero vuelve visible la ley que ya gobierna. ToolRegistry::call() siempre ejecutó resolver, validar, autorizar, confirmar, ejecutar y auditar en ese orden; lo que faltaba era poder verlo sin leer el código fuente. coa:tools inspect construye un InvocationPlan que describe, paso por paso, lo que call() REALMENTE haría con un tool, un canal y un wiring dados — nunca invoca el callback ni muta nada.
Al terminar podrás
- Leer la invocación de un tool como un InvocationPlan inspeccionable, no como once pasos idénticos
- Distinguir Dormant (la regla existe pero no puede dispararse) de Skipped (el subsistema no está conectado)
Entender
ADR#13 parte de una tesis simple: primero vuelve visible la ley que ya gobierna. ToolRegistry::call() siempre ejecutó resolver, validar, autorizar, confirmar, ejecutar y auditar en ese orden; lo que faltaba era poder verlo sin leer el código fuente. coa:tools inspect construye un InvocationPlan que describe, paso por paso, lo que call() REALMENTE haría con un tool, un canal y un wiring dados — nunca invoca el callback ni muta nada.
El plan es el contraparte de solo lectura del modo plan. ctx.mode='plan' es una rama dentro de UNA llamada real: el tool se resuelve, se valida y se detiene antes de ejecutar — sigue siendo una invocación. El InvocationPlan no invoca nada: recorre los pasos de InvocationStepKind y anota su presencia (Active, Conditional, Dormant, Skipped) para esa combinación de tool+canal+wiring, como una radiografía completa del cableado en vez de un ensayo de una sola llamada.
Dormant y Skipped se ven parecidos en la tabla pero significan cosas distintas. Confirm es Dormant para settings_update (mutating:false, sin requiresConfirmation): incluso en telegram, cuyo PolicyGate declara require_confirmation_for_mutating:true, la regla EXISTE pero el propio #[Tool] la vuelve estáticamente imposible de disparar para este tool. Rate limit y Emit executing en cambio son Skipped cuando el host no conectó un rateLimiter o un dispatcher — no es que la regla sea imposible, es que el subsistema simplemente no está cableado; instalarlo basta para que pasen a Active.
La honestidad corta también hacia la auditoría. AUDIT_SOURCE declara qué audita tool.executed/tool.failed — validate-fail, authz-fail, rate-limit, cache-hit, éxito y fallo de execute — y qué NO audita: resolve-miss, plan-mode, confirm, veto. Un inspect que describiera cobertura total sería un modelo aspiracional; ADR#13 exige que el plan describa lo que el runtime EJECUTA de verdad, huecos incluidos.
Ver
Abrir la Radiografía del runtime — pestaña Plan de invocación
Cambia de canal (coa, MCP, POST) y observa cómo Confirm permanece Dormant mientras solo cambia su justificación; Rate limit y Emit executing pasan de Omitido a Activo únicamente cuando el wiring del host los conecta.
Hacer
Ejecuta la práctica en tu checkout y conserva la salida como evidencia.
Verificar
Demuestra que puedes aplicar la unidad. El progreso solo avanza al aprobar la evaluación.
Criterios evaluados
- Explica por qué Confirm marca Dormant y no Activo para un tool con mutating:false, incluso en un canal que exige confirmación para mutaciones.
- Distingue el modo plan — una llamada real que se detiene antes de ejecutar — del InvocationPlan, que no ejecuta ninguna llamada.
- Comprueba que coa:tools inspect nunca fabrica un actor: una invocación anónima muestra el principal en null, no un usuario inventado.
Fuentes primarias
Contenido verificado: 2026-07-16