Como isto funciona na prática
Sem verniz de página de venda: o ciclo inteiro, o que você precisa conectar, o que a plataforma escreve — e o que ela nunca faz sozinha.
Ainda não existe API pública. Quando existir, a documentação de referência entra nesta página; por ora, ela responde como o produto trabalha.
O ciclo, do pedido ao laudo
Cada requisito percorre o mesmo caminho de nove passos, e cada passo tem dono. O agente valida e atesta; as decisões — aceitar uma ressalva, aceitar a spec, aprovar uma publicação — são sempre de uma pessoa.
- 1 · Requisito escritohumano
- No ClickUp, no Jira, na wiki ou direto na plataforma — do jeito que o time já escreve.
- 2 · Validação contra o códigoagente
- O agente lê o sistema que já existe e devolve ressalvas com evidência em arquivo:linha. É o passo de maior valor: o erro ainda é texto.
- 3 · Ciclo de respostahumano
- O autor aceita e ajusta, ou rebate e mantém. As duas coisas ficam registradas.
- 4 · Geração da specagente
- O requisito fechado vira spec no padrão do projeto, item a item, cada um rastreado ao critério que traduz.
- 5 · Aceite da spechumano
- Por quem vai desenvolver — e nunca por quem escreveu aquela versão do requisito. É a única segregação obrigatória.
- 6 · Desenvolvimentohumano
- A plataforma fica de fora: ela não escreve código de feature.
- 7 · Captura do MRplataforma
- O MR/PR aberto é capturado pelo webhook, sem passo manual.
- 8 · Atestoagente
- Código × requisito × spec, critério a critério, com veredito e evidência. Sem evidência confirmada no commit, o veredito cai para inconclusivo.
- 9 · Publicaçãoplataforma
- O parecer vira comentário no code review — publicado após aprovação, ou automaticamente se a política do projeto mandar.
O que é preciso conectar
Três conexões, todas no cadastro do projeto. Credencial entra cifrada e não volta: nenhuma resposta de API a devolve.
- Fonte de requisito
- ClickUp, Jira ou NextWiki — onde o card já vive. É de lá que o requisito é lido, e é lá que ele continua.
- Repositório git
- GitLab (inclusive self-hosted), GitHub ou Azure DevOps. Acesso de leitura para o mirror, mais o webhook do MR.
- Aviso (opcional)
- Discord ou Telegram, para o time saber quando um atesto termina.
- Uma conta de IA
- A sua própria ou um modelo local. A tela mostra para onde o código vai antes de executar.
O que a plataforma escreve, e onde
Toda escrita externa é uma proposta: o texto exato aparece antes, e alguém aprova — ou uma política do projeto aprova automaticamente, com o motivo registrado. Nada é escrito sem registro.
- Comentário no code review
- O parecer do atesto, como nota. O estado de aprovação do MR/PR nunca é tocado.
- Comentário no card
- Ressalvas e resultado, na ferramenta onde o requisito vive.
- Mensagem no canal
- O aviso de conclusão, com o link.
É a lista inteira.
O que ela nunca faz sozinha
- Escrever código de feature
- Nunca. O Aferiz audita, questiona e propõe; não implementa.
- Commit ou push
- Em nenhuma circunstância — nem com aprovação.
- Aprovar merge
- Aprovar uma proposta publica um comentário; o merge continua sendo das pessoas.
- Pôr regra de padrão em vigor
- Padrão inferido é proposta. A aprovação é humana, regra a regra, sem caminho de auto-aprovação — nem por API, nem por configuração.
- Fechar uma ressalva
- Quem aceita ou rebate é o autor do requisito. Se o agente pudesse fechar o que ele mesmo levantou, o registro deixaria de valer como prova.
- Forçar um veredito
- Quando a evidência não sustenta, a resposta é inconclusivo. Forçar veredito é pior que admitir dúvida.
O que ainda não existe
A honestidade do resto do site vale aqui também.
- API pública e MCP
- Estão especificados e ainda não publicados. A documentação de referência entra nesta página quando existirem.
Quando algo desta lista mudar, muda aqui primeiro.