Cómo funciona esto en la práctica
Sin barniz de página de venta: el ciclo completo, qué necesitas conectar, qué escribe la plataforma — y qué no hace nunca por su cuenta.
Todavía no existe una API pública. Cuando exista, la documentación de referencia entra en esta página; por ahora, esta página responde cómo trabaja el producto.
El ciclo, del pedido al laudo
Cada requisito recorre el mismo camino de nueve pasos, y cada paso tiene dueño. El agente valida y atesta; las decisiones — aceptar una salvedad, aceptar la spec, aprobar una publicación — son siempre de una persona.
- 1 · Requisito escritohumano
- En ClickUp, Jira, la wiki o directo en la plataforma — como tu equipo ya lo escribe.
- 2 · Validación contra el códigoagente
- El agente lee el sistema que ya tienes y devuelve salvedades con evidencia en archivo:línea. Es el paso de mayor valor: el error todavía es texto.
- 3 · Ciclo de respuestahumano
- El autor acepta y ajusta, o rebate y mantiene. Las dos cosas quedan registradas.
- 4 · Generación de la specagente
- El requisito cerrado se vuelve spec en el formato del proyecto, punto por punto, cada uno trazado al criterio que traduce.
- 5 · Aceptación de la spechumano
- Por quien va a desarrollar — y nunca por quien escribió esa versión del requisito. Es la única segregación obligatoria.
- 6 · Desarrollohumano
- La plataforma se queda afuera: no escribe código de feature.
- 7 · Captura del MRplataforma
- El MR/PR abierto se captura por webhook, sin paso manual.
- 8 · Atestadoagente
- Código × requisito × spec, criterio por criterio, con veredicto y evidencia. Sin evidencia confirmada en el commit, el veredicto baja a no concluyente.
- 9 · Publicaciónplataforma
- El dictamen se vuelve comentario en el code review — publicado tras la aprobación, o automáticamente si la política del proyecto lo indica.
Qué hay que conectar
Tres conexiones, todas en la configuración del proyecto. La credencial entra cifrada y no vuelve: ninguna respuesta de la API la devuelve.
- Fuente del requisito
- ClickUp, Jira o NextWiki — donde la tarjeta ya vive. De ahí se lee el requisito, y ahí se queda.
- Repositorio git
- GitLab (incluido self-hosted), GitHub o Azure DevOps. Acceso de lectura para el mirror, más el webhook del MR.
- Aviso (opcional)
- Discord o Telegram, para que el equipo sepa cuándo termina un atestado.
- Una cuenta de IA
- La tuya propia o un modelo local. La pantalla muestra adónde va tu código antes de ejecutar.
Qué escribe la plataforma, y dónde
Toda escritura externa es una propuesta: el texto exacto aparece antes, y alguien lo aprueba — o una política del proyecto lo aprueba automáticamente, con el motivo registrado. Nada se escribe sin registro.
- Comentario en el code review
- El dictamen del atestado, como nota. El estado de aprobación del MR/PR no se toca nunca.
- Comentario en la tarjeta
- Salvedades y resultado, en la herramienta donde vive el requisito.
- Mensaje en el canal
- El aviso de conclusión, con el enlace.
Esa es la lista completa.
Qué no hace nunca por su cuenta
- Escribir código de feature
- Nunca. Aferiz audita, cuestiona y propone; no implementa.
- Commit o push
- Bajo ninguna circunstancia — ni siquiera con aprobación.
- Aprobar un merge
- Aprobar una propuesta publica un comentario; el merge sigue siendo de las personas.
- Poner en vigor una regla de patrón
- Un patrón inferido es una propuesta. La aprobación es humana, regla por regla, sin camino de autoaprobación — ni por API, ni por configuración.
- Cerrar una salvedad
- Quien acepta o rebate es el autor del requisito. Si el agente pudiera cerrar lo que él mismo levantó, el registro dejaría de valer como prueba.
- Forzar un veredicto
- Cuando la evidencia no alcanza, la respuesta es no concluyente. Forzar un veredicto es peor que admitir la duda.
Qué no existe todavía
La honestidad del resto del sitio también vale aquí.
- API pública y MCP
- Especificados, todavía no publicados. La documentación de referencia entra en esta página cuando existan.
Cuando algo de esta lista cambie, cambia aquí primero.