Jarbas DEV: o agente de IA que resolve o card do começo ao fim

Você descreve a demanda em uma conversa. O Jarbas CARD faz perguntas, lê a documentação do seu sistema para identificar quais módulos e repositórios estão envolvidos, classifica a demanda (bug, funcionalidade, customização, ideia, melhoria, hotfix ou dívida técnica) e calcula a Temperatura, uma prioridade objetiva a partir de impacto e alcance. Logs e mensagens de erro são preservados palavra por palavra.

O que você vê: O card proposto, ainda no chat, com prints anexados e a justificativa da prioridade.

Humano no comando: Você dá o "ok". Sem ele, nada é criado no board.

Se der errado: Se faltar informação, ele pergunta de novo. Se você não confirmar, o card não existe.

Antes de alguém programar, o Jarbas QA reproduz o cenário de verdade no sistema. Print ou vídeo no card não contam como prova. Ele escreve um teste automatizado que falha com o comportamento atual e o deixa pronto para o desenvolvimento continuar a partir dali.

O que você vê: O card marcado como reproduzido, com o teste anexado. Ou parado, com o motivo escrito.

Se der errado: Se o QA não consegue reproduzir, o card não avança e a pessoa responsável é avisada.

O Jarbas DEV analisa o impacto da mudança, monta o plano e trabalha em uma cópia isolada do repositório. Ele só considera o trabalho pronto quando o teste que falhava passa a funcionar, faz o próprio code review e abre um Pull Request por repositório tocado. Em funcionalidades de tela, ele começa por um protótipo visual no sistema real e espera sua aprovação antes de codar. Ao terminar, documenta o que aprendeu sobre o sistema.

O que você vê: O protótipo para aprovar e, depois, o Pull Request com um resumo em linguagem de negócio: impactos, riscos, premissas, segurança e evidências.

Humano no comando: Você aprova o protótipo visual. Mudanças de banco de dados vão para um DBA humano.

Se der errado: Se qualquer verificação falhar, o card fica em desenvolvimento e o responsável é avisado.

Com o Pull Request aberto, o Jarbas QA volta: reexecuta os testes da etapa 2 e a suíte completa do produto, explora fluxos relacionados e revisa as evidências visuais. Aprovado, o card segue para revisão humana. Reprovado, volta ao desenvolvimento com a lista de defeitos encontrados.

O que você vê: Um parecer no card: aprovado, ou reprovado com o que precisa mudar.

Se der errado: Depois de 4 reprovações seguidas, os dois agentes param e uma pessoa assume a decisão.

Um revisor humano lê o Pull Request. Comentários gerais e comentários linha a linha voltam para o Jarbas DEV como uma nova rodada de trabalho, em português. Se a integração contínua quebrar, o Jarbas corrige e envia de novo, sem que alguém precise pedir.

O que você vê: A conversa no Pull Request, com as respostas e os ajustes feitos.

Humano no comando: Revisor humano obrigatório. Nada é mesclado sem uma pessoa aprovar.

Se der errado: Depois de 10 falhas seguidas na integração contínua, o Jarbas para e pede intervenção humana.

Assim que o Pull Request é aberto, a esteira publica um ambiente de homologação exclusivo para ele. A versão nova fica disponível para quem precisa validar, sem misturar com outras demandas e sem mexer no que está em produção.

O que você vê: Um endereço de homologação exclusivo daquele Pull Request.

Humano no comando: O dono do produto valida no ambiente, com calma e com dados de teste.

Se der errado: Se o ambiente não sobe, o Jarbas investiga a esteira e corrige antes de avisar você.

Com sua aprovação, o Pull Request é mesclado e a nova versão vai para produção ao lado da anterior, com verificação de saúde antes de receber tráfego. O sistema não sai do ar. Se você reprovar, suas observações voltam ao Jarbas QA e ao Jarbas DEV como uma nova rodada.

O que você vê: A nova versão no ar e o card movido para "Liberado em Produção".

Humano no comando: A decisão final é sua.

Se der errado: Se a verificação de saúde falhar, a versão nova nem recebe tráfego. A anterior continua servindo.