docket
EnglishEspañol
GitHub

Código abierto · Apache-2.0 · v0.2.0-beta.3

Agentes de código que preguntan antes de publicar.

docket pone a trabajar un equipo chico de agentes de IA sobre tu código. Uno planifica, otro escribe, otro revisa. Cada edición, comando y llamada a una API pasa primero por una compuerta, y lo riesgoso te espera a vos.

EmpezarVer la compuerta
  • Roles
  • Políticas
  • Aprobación humana
  • Auditoría
docket — la compuerta
$ docket policies test pre_tool_call implementer 'git push origin production'
  Result: require_approval
$ docket pod myapp dispatch
→ Dispatching 1 pending task(s) through: lead → implementer → reviewer
  ⋯ tool.ask       tool=bash policy_id=high-risk-deploy
  ⋯ approval.deny  channel=timeout
$ docket audit verify
✓ 6 chained line(s) verified clean.

Casi todas las herramientas le piden al modelo que se porte bien. docket no le pide nada.

Lo de siempre

  • Un prompt dice “nunca publiques a producción” y el modelo decide si hace caso.
  • Un solo agente planifica, escribe y se corrige a sí mismo.
  • Los cambios caen en la rama que tenés abierta.
  • Si algo sale mal, te toca leer un chat interminable.

Con docket

  • git push origin production queda frenado por código hasta que una persona diga que sí.
  • Un Lead planifica, un Implementer escribe, un Reviewer y un Tester validan el resultado.
  • El Implementer trabaja en su propio git worktree. Tu checkout queda limpio.
  • Cada decisión queda en un log encadenado por hash que podés verificar.
01

Un equipo, no un agente suelto.

Cada rol recibe solo las herramientas que su trabajo necesita. Un Reviewer no tiene ninguna herramienta de escritura, así que nadie lo puede convencer de editar.

02

Una compuerta. Sin puerta trasera.

Las herramientas propias y las de MCP pasan por el mismo control antes de ejecutarse. No hay ninguna opción que lo apague.

03

Evidencia, no promesas.

Ejecuciones, trazas, aprobaciones y tokens quedan para consultar después. docket audit verify te dice si alguien tocó el log.

1
compuerta para cada llamada
0
caminos para esquivarla
4
formas de aprobar: CLI, HTTP, MCP, Telegram
120s
de silencio, y la respuesta es no

Cómo funciona

Vos escribís la tarea. El pod hace el resto, en orden.

docket init arma un pod: un equipo chico dedicado a un proyecto. docket pod <id> dispatch le pasa una tarea.

  1. 01LeadPlanifica y delega. Nunca toca código.
  2. 02ImplementerEscribe el cambio en su propio git worktree.
  3. 03VerifyTu comando. Si sale distinto de cero, la tarea falla.
  4. 04ReviewerSolo lectura. Puede devolverlo.
  5. 05TesterPASS o FAIL. Nada en el medio.
  6. 06EvidenciaRegistro de ejecución, traza y auditoría.

Reviewer y Tester son opcionales. Cuando están, su veredicto frena la tarea: no es un consejo que el modelo pueda discutir. Los blueprints adaptan el mismo flujo a investigación, contenido, operaciones o producto.

La compuerta

Elegí un comando. Mirá qué pasa.

Toda acción sigue el mismo camino: política, chequeo de riesgo, una persona si hace falta, presupuesto y recién ahí se ejecuta.

rol: implementergit push origin production
En espera

Lo riesgoso espera a una persona.

Deploys, dinero y secretos son de alto riesgo. La llamada queda en pausa hasta que alguien la aprueba desde la CLI, HTTP, MCP o Telegram. Sin respuesta en 120 segundos, se rechaza.

Pruebas

Salida real. Nada de maquetas.

Capturado de ejecuciones reales contra un modelo local el 2026-09-18. Cada línea es lo que imprimió la CLI.

Salida de terminal: un git push origin production del Implementer queda retenido por la política high-risk-deploy, nadie responde, se rechaza por timeout sin ejecutarse y la cadena de auditoría verifica limpia.
Un push a producción queda retenido, nadie responde, se rechaza sin correr y la auditoría cierra.
Salida de terminal: el workspace propio del Implementer y un git worktree separado en su propia rama, mientras el checkout principal queda limpio.
El cambio del Implementer vive solo en su worktree. Tu rama no se toca.

Tres formas de usarlo

Desde tu terminal, desde tus herramientas o dentro de tu app.

docket

CLI

Armá un pod y despachá tareas sobre tu propio repo. El camino más corto a una ejecución gobernada.

docket harness run

Harness

Un agente, un turno, manejado por otro programa. Nunca espera a una persona: lo que necesite aprobación termina como bloqueado.

docket-runtime

Motor

Pasá las herramientas de tu app por la misma compuerta de política, aprobación y auditoría. Dos dependencias. Se compila desde el código.

Empezar

Tu primera ejecución gobernada.

Instalá, conectalo a un modelo y despachá una tarea. Funciona con modelos locales.

install
brew tap yielab/docket-cli https://github.com/yielab/docket
brew install docket-cli
first run
docket models provider add local http://127.0.0.1:8081/v1 \
  --model local-model --ctx 32768 --max-tokens 4096
docket models preset local

cd ~/code/myapp
docket init
docket pod myapp delegate "Create FIRST_TURN.md containing: governed first turn"
docket pod myapp dispatch

docket runs list
docket trace tail myapp
docket audit verify

Necesita Python 3.11+, Git, Bash y un endpoint compatible con OpenAI que soporte tool calling: en la nube (OpenRouter, Vercel AI Gateway) o local (llama.cpp, vLLM, LM Studio).

Leer la guía completa →

Sin vueltas

Lo que docket no es.

Todos los límites conocidos →
  • No es un dashboard. Expone una API de lectura para que armes o conectes el tuyo.
  • No es un framework de orquestación general. Corre un equipo supervisado por proyecto.
  • No está terminado. Es beta, pensado para un solo operador, y entre versiones puede haber cambios incompatibles.
  • No es una jaula de red. La herramienta fetch tiene lista permitida, pero una shell permitida igual puede salir a la red. Corré el trabajo no confiable dentro de un contenedor.

Ponele una compuerta a tus agentes.

Código abierto bajo Apache-2.0. Leé el código, correlo en tu máquina y revisá cada decisión que tomó.

EmpezarEstrella en GitHub