Acompanhe o exemplo do Twitter
Este guia acompanha o bug de exclusão de post no exemplo do Twitter do Panolayer. Você vai ler o problema, seguir sua explicação de volta ao código e entender o resumo de verificação antes de decidir se faz o merge.
Para acompanhar, abra Twitter Clone em Experimente um app de exemplo. Ele abre como twitter-starter. Para a configuração completa e o passo a passo da correção, consulte Corrija seu primeiro bug com o Panolayer. As capturas de tela mostram uma execução registrada; a ordem e as contagens dos seus problemas podem ser diferentes.
Comece em Problemas
Quando você abre um código-fonte, o Panolayer verification engine começa a ser executado. Ele analisa o código até suas funções, símbolos e dependências, monta a arquitetura visual e verifica o código para identificar bugs.
Abra Problemas. Neste exemplo, a execução terminou e o status é Verificação concluída. Os problemas que precisam de investigação aparecem em Precisa de atenção.
Verificação concluída descreve a execução. Isso significa que a execução terminou; leia os resultados para ver se foram encontradas falhas.
Leia o problema de exclusão
O primeiro problema do exemplo reporta que uma condição pode impedir uma exclusão confirmada:
A verificação extra
canDeletepode impedir a exclusão apesar da confirmação do usuário, contrariando o comportamento declarado de exclusão do post atual.
Uma regra é uma expectativa sobre o comportamento de uma função: o que ela deve retornar, qual ação deve executar ou o que outro código espera dela. Aqui, a expectativa diz respeito a excluir o post atual depois que o usuário confirma.
Leia juntos o arquivo, a função, o status e a explicação do problema:
| O que você vê | O que isso indica |
|---|---|
components/Post.tsx | O arquivo que contém a função a investigar. |
handleDelete() | A função cujo comportamento foi verificado. |
| Falhou | O comportamento verificado não atendeu à regra. |
| Severidade 3 · Funcionalidade | A severidade e a categoria do problema ajudam a priorizar a investigação. |
| Detalhes | A explicação e a localização no código-fonte ajudam a entender por que o problema foi reportado. |
Clique em Detalhes. A explicação diz que a função pode retornar antecipadamente quando canDelete é false, antes de concluir a exclusão descrita pela regra. A referência ao código-fonte aponta para o trecho relevante.
Verifique se a regra corresponde ao comportamento pretendido antes de decidir o que mudar. Se a expectativa estiver errada, corrija a regra. Se o código estiver errado, corrija o código. Uma mudança também pode afetar chamadores em outros arquivos, então siga os chamadores afetados mostrados no resultado.
O que significam os status?
Leia o status junto com sua explicação e o código ao qual ele se aplica.
| Resultado | Como interpretar |
|---|---|
| Passou | A regra avaliada passou para o código verificado. Isso descreve essa regra, e não todos os comportamentos possíveis da aplicação. |
| Falhou | A regra avaliada não se confirmou. Leia a explicação e inspecione o código-fonte para decidir o que precisa ser corrigido. |
| Pendente ou em execução | O resultado ainda não está pronto. Aguarde a verificação terminar antes de tirar conclusões. |
| Indisponível | A verificação não pôde ser concluída. Leia a mensagem que a acompanha e resolva o problema reportado antes de verificar novamente. |
| Não verificado | A expectativa não foi avaliada. Não é um resultado de aprovação. |
Se a verificação não puder ser concluída, siga o erro reportado e consulte Resolva problemas de configuração e de agentes.
Corrija o bug e deixe a verificação rodar novamente
Na issue de exclusão, clique em Corrigir e selecione Panolayer Agent. O Panolayer passa o contexto da issue para o agente, então você não precisa escrever um prompt explicando o bug.
O Panolayer Agent é integrado. Você também pode usar outro agente compatível depois de instalá-lo; consulte Agentes compatíveis.
O agente trabalha em seu próprio worktree do Git, mantendo suas edições separadas da sua branch. Acompanhe a tarefa em Meus Agentes ou clique em Abrir no cartão de execução para inspecionar a atividade e as alterações dele.
Conforme o código muda, o Panolayer verifica novamente as funções afetadas e o código conectado, incluindo chamadores em outros arquivos. Isso ajuda a detectar regressões além das linhas que o agente editou.
Uma regressão é um novo problema introduzido pela alteração. Se a verificação detectar uma durante uma correção, o agente pode corrigi-la e rodar a verificação novamente antes de solicitar o merge. Uma tarefa pode, portanto, ter várias execuções de verificação antes de estar pronta para sua revisão.
Leia o resumo da verificação antes de fazer o merge
Quando esta execução termina, o Panolayer mostra O Panolayer Agent está pronto para o merge. A caixa de diálogo resume o que a verificação checou e reparou durante a tarefa.
| Campo do resumo | Esta execução | O que significa |
|---|---|---|
| Falhas reparadas | 1 | O trabalho reparou uma falha que já existia antes do início da tarefa. |
| Regras aprovadas | 14 de 21 | Quatorze regras passaram de 21 no código alterado. Leia isso junto com a mensagem de integridade e a linha separada de falhas pré-existentes. |
| Execuções de verificação | 1 | Uma execução de verificação chegou a um resultado durante este trabalho. Isso conta execuções de verificação, não testes ou regras individuais. |
| Arquivos alterados | 4 | A tarefa alterou quatro arquivos. Revise o conjunto completo de alterações, incluindo testes e arquivos de dependências. |
A mensagem de integridade diz Nenhuma nova falha, aviso ou regra não verificada. Leia essa mensagem junto com as contagens: ela descreve o resultado deste trabalho, enquanto a linha seguinte explica as falhas que permanecem de antes do início dele.
E se aparecer “Regressões detectadas”?
Algumas execuções também mostram Regressões detectadas. Esse campo informa novos problemas que a verificação detectou durante o trabalho, ajudando a mantê-los fora da branch de destino. Leia o resultado mais recente para ver o que ainda precisa de atenção; a contagem descreve as detecções durante o trabalho, não o número de falhas não resolvidas no momento.
Este campo não aparece nesta captura de tela. O exemplo de exclusão mostra uma falha pré-existente reparada; ele não demonstra uma regressão detectada durante a correção.
Why can it be ready to merge when failures remain?
Panolayer compares the result with the baseline: the state of the codebase before the change. This separates problems introduced by the task from problems that were already there.
- A new failure was introduced by the change and needs investigation before you accept the work.
- A pre-existing failure was present before the task started. It can still matter, but this task did not introduce it.
- A repaired failure was present before the task and was fixed during the work.
In the screenshot, the dialog reports 7 pre-existing failures that do not block this merge. The selected deletion issue was repaired, and those other issues remain separate work.
The repository’s issue list and an agent’s verification summary can cover different scopes. The issue list shows what needs attention in the codebase; the merge summary describes the agent’s work against its baseline. An agent’s result can report no new failures while the repository still has pre-existing issues.
You can assign a pre-existing issue as another task using Fix. That gives the agent a specific issue to work on next.
Ready to merge does not mean every issue in the repository is resolved. Read what this task repaired, what it introduced, and what was already there.
Decide what reaches your branch
You control the merge. Before accepting the result:
- Check that the repaired issue matches the bug you asked the agent to fix.
- Read the verification summary, including any new failures, warnings, or checks that could not finish.
- Open Details for more context and inspect the agent’s changed files. Review the relevant tests and run the application when the behavior needs a runtime check.
- Confirm the target branch. Choose Merge into main when you’re satisfied, or Not now to keep reviewing.
Verification gives you evidence for the decision. Read it alongside the code and relevant tests; it does not cover every possible bug.