Registra um bug no WiseWork a partir de uma frase escrita do seu jeito. Você descreve o problema; o comando deriva um título curto, organiza o relato e cria o bug no produto.
É registro, não investigação: ele anota o que você observou e não sai lendo o repositório atrás da causa. Encontrar a causa e corrigir é papel do /ww:fix.
Como utilizar
Descreva o bug em palavras — o que acontece, onde e em que cenário. Quanto mais contexto você der, mais completo fica o relato. Se tiver um print ou um log salvo, cite o caminho do arquivo. O comando deriva o título, organiza o que você contou e registra o bug no produto.
Exemplos
/ww:bug:report O botão de login não responde no Chrome
/ww:bug:report A conexão com o banco falha em produção ao salvar pedidos
Na ambiguidade
O título sai da sua descrição. Se não der para dizer o que acontece, o que deveria acontecer, em que tela ou fluxo, se é um bug ou vários, ou qual a prioridade, o comando faz até 4 perguntas objetivas, numa rodada só, antes de gravar.
Notas
Precisa de um produto fixado no projeto. Sem ele, o comando para e indica o /ww:init; se a conexão com o WiseWork não estiver configurada, indica o /ww:config:mcp.
Quando você tropeça em um defeito no meio de outra coisa e quer registrá-lo sem perder o fio do trabalho.
- O comando usa o produto fixado no projeto.
- Lê a sua descrição e deriva um título curto e específico.
- Aproveita o que já está na sessão — a conversa, o erro que acabou de aparecer, os arquivos abertos. Não abre investigação; se você citar um arquivo, uma rota ou o texto do erro, no máximo confere aquele ponto.
- Define a prioridade (baixa, média, alta, crítica ou urgente). Só deduz sozinho quando o relato não deixa dúvida — perda de dados, falha de segurança, produção fora do ar ou fluxo bloqueado para todos pedem crítica ou urgente; defeito cosmético com contorno óbvio fica baixa. Nos demais casos, pergunta.
- Organiza o relato em Contexto, Comportamento atual, Comportamento esperado e, quando já se sabe alguma coisa, Notas técnicas. Os passos para reproduzir entram só se você os tiver descrito.
- Cria o bug no produto, marcado como defeito, com a prioridade definida, a tag
bug e mais algumas da área afetada. O status inicial é a fazer — ou o status equivalente, se o seu produto usar um fluxo de status próprio.
- Se você citou um arquivo local como evidência — um print, um log, uma requisição exportada — e ele existe, anexa o arquivo ao bug. Um texto de erro longo colado na conversa também vira anexo, em vez de inchar o relato.
- Mostra o ticket criado, o título, a prioridade, o status, o produto, os anexos enviados e o link para abrir o bug no WiseWork, quando ele vier na resposta.
O relato fica legível para quem não vai abrir o código. As notas técnicas são pistas — a mensagem de erro, o módulo, a tela, o endereço afetado —, nunca uma causa provável nem uma correção proposta.
- É rápido de propósito. Questão de segundos, sem investigação nenhuma. Achar a causa é trabalho do /ww:fix, na hora de corrigir.
- Não inventa nada. Nem detalhe técnico, nem passos para reproduzir: o que você não contou não é chutado.
- A autoria é sua automaticamente, pelo seu acesso ao WiseWork.
- Prioridade sim, severidade não. O WiseWork não tem campo de severidade: o impacto do bug vai na prioridade, que o comando sempre preenche — deduzida só quando é inequívoca, confirmada com você nos outros casos.
- Só anexa o que você apontou. O comando não sai procurando arquivos. Arquivo com credenciais ou tokens não é enviado, nem arquivo acima de 20 MB — ele avisa na confirmação.
- Não corrige nada. Corrigir é /ww:fix.
- Não cria arquivos locais. O bug vive no WiseWork, não no seu repositório.
- Precisa de um produto fixado. Sem isso o comando para e indica o /ww:init. O produto fixado fica gravado no projeto — você não precisa refixá-lo a cada conversa.
- /ww:fix — para investigar e corrigir o bug registrado
- /ww:task:add — para registrar uma demanda nova em vez de um defeito
