O ticket do início ao fim

O agente pode criar tickets filhos para repartir uma missão em tarefas independentes. Cada filho tem o seu cartão, a sua descrição, o seu agente e o seu resultado. O pai pode continuar o seu próprio trabalho, acompanhar os filhos e transmitir-lhes instruções; retoma a síntese quando os resultados chegam.

A descrição do filho deve ser autónoma: objetivo, âmbito, restrições e critérios de sucesso. A divisão está limitada a três níveis e cinco filhos não concluídos por pai. Um filho concluído não fecha o pai: este verifica os resultados e conclui a sua própria missão.

Um ticket de seguimento conserva um trabalho distinto descoberto pelo caminho. Uma dependência exprime um pré-requisito: pode apontar para um ticket já existente sem o tornar filho. Por exemplo, a documentação pode esperar pela entrega de uma funcionalidade, enquanto dois filhos, frontend e API, trabalham em paralelo. Uma ação reservada a uma pessoa pode ser representada por um ticket User Actions quando esse plugin está ativo.

O rótulo numerado identifica o ticket. O título resume o resultado esperado e a descrição fornece o contexto. A prioridade é low, medium, high ou critical. As etiquetas (tags) facilitam a classificação e os projetos afetados indicam os repositórios a consultar.

Os oito tipos são feature, bug, refactor, doc, test, ia, session e user-action. Este último representa uma ação humana e aparece quando o módulo User Actions está ativo.

Os seis estados exatos são todo, in_progress, working, pending, done e failed. in_progress abrange a assunção do ticket, working uma execução ativa e pending uma espera explícita.

Faz duplo clique num cartão do Mission Control. O detalhe abre-se como um separador do deck: mantém-no ao lado do editor, do terminal ou de outro ticket sem perder o contexto.

A descrição é a instrução principal lida pelo agente. Fornece o contexto e o problema observado, formula critérios de aceitação verificáveis e indica o que fica fora do âmbito. Acrescenta os caminhos ou comandos úteis sem impor uma solução quando só o resultado importa.

Uma boa descrição permite saber o que deve mudar, como verificar o sucesso e o que deve ficar intacto.

Um ticket verificável descreve o problema atual, o resultado esperado, o âmbito, as exclusões e critérios observáveis acompanhados de comandos. Eis um exemplo fictício e anonimizado, sem dados de clientes nem sintaxe de especificação imposta.

Num repositório Git de demonstração com Node.js 22 ou mais recente, verifica que os dois caminhos abaixo estão livres. Cria um ticket no Mission Control, introduz o título, o tipo e a prioridade nos respetivos campos e copia o resto para a descrição. Para o teu projeto real, adapta os caminhos, os pré-requisitos e os comandos antes de lançar o agente.

Título: Normalizar os espaços de um rótulo
Tipo: feature
Prioridade: low
Projeto: o repositório de demonstração aberto no Singularity
Dependências: nenhuma

Problema atual
Este repositório Git de demonstração não tem função de normalização.
Um rótulo introduzido com espaços supérfluos seria mantido tal como está.

Resultado esperado
Criar uma função normalizeLabel(text) exportada a partir de
src/normalize-label.mjs: remover os espaços em branco no início e no fim
e substituir cada sequência de espaços em branco (espaços, tabulações,
quebras de linha) por um único espaço. Manter maiúsculas e acentos.

Âmbito
Criar src/normalize-label.mjs e test/normalize-label.test.mjs.
Usar Node.js 22 ou mais recente, node:test e node:assert/strict.
As entradas são apenas cadeias. Nenhuma dependência a instalar.

Exclusões
Sem interface, base de dados, chamada de rede, alteração dos
ficheiros existentes, tratamento de outros tipos nem publicação.

Critérios de aceitação
1. "  Bonjour   équipe  " passa a "Bonjour équipe".
2. "" e uma cadeia composta por espaços em branco passam a "".
3. Tabulações e quebras de linha entre duas palavras passam a
   um espaço; "Équipe A" mantém-se "Équipe A".
4. Os testes automatizados cobrem cada um destes casos e passam.
5. O diff final contém apenas os dois ficheiros do âmbito.

Verificação a partir da raiz do repositório
node --version
node --check src/normalize-label.mjs
node --test test/normalize-label.test.mjs
git diff --check

Relatório esperado
Indicar os comandos executados, os resultados e os ficheiros criados.
Se um comando falhar, conservar o erro e explicar a limitação.
Rever os dois ficheiros no separador Review e verificar o âmbito
antes da integração; um comando bem-sucedido não valida todo o diff.

Os critérios 1 a 4 verificam-se com os testes; o critério 5 verifica-se no diff do separador Review. Os comandos acima devem ser executados pelo agente depois de criar os ficheiros; este exemplo não pretende relatar uma execução real.

Larga um ficheiro ou uma imagem no formulário de criação, ou utiliza o botão de adicionar. Imagens, PDF e textos podem ser pré-visualizados no detalhe. Durante a execução, o Singularity expõe a respetiva lista ao agente, que os pode ler através do gateway de sessão ou com o caminho local fornecido.

Utiliza exemplos mínimos e anonimizados: nenhuma captura deve revelar segredos nem o conteúdo de um ticket real.

O campo Blocked by liga o ticket aos seus pré-requisitos. Só é lançado quando estes estão concluídos e, se tiverem produzido um worktree, integrados.

Um ticket complexo pode ser dividido em filhos. O pai conserva as ligações e pode continuar a trabalhar. Quando espera pelos filhos, passa a pending e depois retoma para sintetizar os resultados.

Um prazo indica a data-alvo sem lançar o trabalho. O agendamento programa uma execução recorrente diária ou semanal à hora escolhida. Podes iniciar a primeira ocorrência de imediato e depois suspender, retomar ou eliminar o agendamento.

O fio conserva as tentativas, mensagens e respostas do agente. Escreve para precisar o pedido durante uma execução. Se o agente fizer uma pergunta bloqueante, o ticket passa a pending: a tua resposta regressa à mesma sessão com o respetivo contexto.

Num ticket done ou failed, uma nova mensagem ou o relançamento inicia uma nova tentativa sem apagar o histórico.

O relatório final explica o que foi entregue, as verificações efetuadas e as eventuais limitações. Permanece no detalhe e alimenta a revisão quando está ativada.

A resolução curta é uma frase sem Markdown com menos de 120 caracteres, apresentada a negrito no cartão concluído para que a coluna Done possa ser lida num relance.