API Shipped · contrato en movimiento

La misma superficie que usa la consola

No hay una segunda implementación detrás de la consola o de la CLI: las dos hablan con ésta. Lo cual también significa que se mueve cuando se mueve el producto, y esta página tiene cuidado con lo que promete.

Lo que es estable

POST /v1/<tenant>/<repo>/tasks
{ "title": "una línea", "requested_by": "tu@ejemplo.com" }

• Un board es un par. Cada ruta va acotada por path — /v1/<tenant>/<repo>/… — y un board es ese par, nada más.
• El intake es una línea. Un título aterriza en Triage. Una petición sin acotar no es trabajo en marcha, aquí como en todas partes.
• El estado lo cambia el gate. La ruta de scoping rechaza un campo state, así que nada puede arrancar trabajo escribiéndolo de lado.

Lo que sigue moviéndose

La referencia completa de payloads está registrada y sin escribir, y ese orden es deliberado y no un descuido del backlog: las formas siguen moviéndose, y documentar un contrato en movimiento produce documentación que miente. Lo que existe está marcado como pendiente; lo de arriba es lo que ha aguantado.

Si vas a construir sobre esto ahora, el handshake de versión es lo primero que conviene cablear: a un cliente desactualizado se le dice en una línea, en lugar de que lo descubra más tarde como un desacuerdo de reglas.

Dónde se detiene

• No es el camino del enforcement. El hook nunca llama a la red para decidir, así que una caída de la API no puede abrir una zone — nunca estuvo en el camino de la denegación.
• No puede calcular tu diff. Un close necesita un change manifest de la máquina donde está la rama — cycle verify --close lo construye allí, y la API solo lo recibe.

Las rutas tal y como están se documentan en la referencia de la API(en inglés). Para casi todo, la CLI y el servidor MCP son el camino más corto.