O que você precisa fazer hoje?

Fonte de dados

Os dados vêm da API do GitLab. O gerador busca issues abertas e fechadas (o status "Done" do fluxo interno nem sempre fecha a issue no GitLab), pagina os resultados de 100 em 100 e remove duplicadas por iid. Os tickets seguem a numeração POB, também referenciada no Jira para rastreamento complementar do projeto.

Hierarquia de tarefas (pai/filho)

A hierarquia é montada por convenção de título, não pela API de relações do GitLab: um item POB-879.1 é considerado filho de POB-879 (o item raiz, só com o número, sem sufixo). Tarefas filhas aparecem indentadas, com "↳", logo abaixo do pai.

Classificação por etapa

A etapa é definida principalmente pela due_date da issue, não pelo nome do milestone. O nome do milestone só entra como reserva quando não há data de entrega:

Princípio de manutenção: sempre que a data já está disponível na própria issue, o gerador usa comparação direta em vez de depender de chamadas extras à API — essa simplicidade foi uma escolha deliberada depois de testar uma versão anterior baseada em eventos de label, considerada complexa demais.

"Entregas da semana"

Uma tarefa entra como entrega da semana quando o due_date cai dentro do período informado no formulário — comparação simples de datas, sem consultar a API de eventos de label. Essas tarefas ganham destaque visual: faixa verde e selo "✦ Esta semana".

Status de Desenvolvimento (o que a Nyx está fazendo)

Conclusão é sempre definida por state === 'closed', workflow::Done ou client::Done — nunca pelo prazo vencido. Um due_date no passado não significa que a tarefa foi concluída.

Status de Aprovação (o que o cliente vê)

Processos internos da Nyx não são expostos ao cliente — a tarefa é "Pendente" até que uma label client:: indique o contrário, ou até ser concluída.

O que fica de fora do relatório

• Qualquer item (pai ou filho) com a label não relatório.
• workflow::new sem milestone atribuído — tarefa ainda não triada/aprovada, não deve ser vista pelo cliente.

Inconsistência de nomenclatura de labels

A maioria das labels segue o padrão categoria::Valor. Exceção conhecida: a label de informação pendente do cliente usa dois pontos simples com espaço, client: Informations, em vez de client::Informations. A detecção é case-insensitive e aceita as duas variações. Regra prática: sempre validar a string exata de uma label nova contra um ticket real antes de codificar (ticket de teste usado historicamente: POB-929).

Destaques visuais

• Gerência: label client::gerência → borda/fundo âmbar e selo "⭐ Gerência".
• Bugs: label type::Bug → selo vermelho "Bug".
• Escopo extra: tarefas sem milestone (Manutenção) → selo "ESCOPO EXTRA".
• Aguardando informações: label client: Informations → selo laranja "⚠ Aguardando informações do cliente".

Agrupamento e ordenação

As tarefas são agrupadas por funcionalidade via label ft(...) (ex.: ft(associados)), numa ordem fixa — labels fora dessa lista vão pro final. Dentro de cada grupo, ordena por due_date e, em empate, pelo número do ticket POB. A numeração sequencial (#1, #2...) é recalculada por tabela no momento em que o relatório é gerado.

Princípios gerais de manutenção

• Simplicidade sobre complexidade: usar dados já presentes na issue em vez de chamadas extras à API sempre que possível.
• Sempre validar a string exata de uma label nova contra um ticket real antes de criar regra baseada nela.
• Separação client-facing vs. interno: labels de workflow não devem vazar pra coluna Aprovação, salvo exceções documentadas.
• Mudanças de regra de negócio significativas devem ser confirmadas com um dev sênior antes de implementar, e documentadas para o time.

Identificação e título

Cada tarefa usa o prefixo POB-xxx (numeração sequencial atribuída depois na ferramenta de gestão de tarefas) e é sempre escrita em português do Brasil. O título segue o formato [Área/Funcionalidade] — [Mudança específica], curto e descritivo, sem jargão técnico desnecessário — por exemplo, "Publicações — Exibição de múltiplos autores no card de listagem".

Princípios gerais (valem pra qualquer tipo de tarefa)

• O quê, não como: descreve o comportamento e resultado esperado, não a implementação técnica. A escolha da solução (configuração de CSS, Drupal, etc.) é do time de desenvolvimento.
• Precisão de escopo: deixa claro o que está dentro e fora do escopo — ex: "busca aplica-se a todo o conteúdo exclusivo do perfil, não apenas a um painel específico".
• Pendências ficam registradas na própria tarefa: quando falta confirmação do cliente ou do design, isso vira um bloco de alerta explícito — nunca é presumido ou omitido.
• Referência cruzada: tarefas relacionadas são citadas pelo ID POB-xxx pra manter rastreabilidade.
• Dependência de design como bloqueio: se a tarefa depende de atualização no Figma ou decisão do time de design, isso é sinalizado como pré-requisito, nunca implícito.
• Linguagem do time: evita termos que o time não usa — por exemplo, "submenu lateral" em vez de "flyout".

Estrutura — Tarefa normal

Contexto (cenário atual e por que a mudança é necessária) → Comportamento esperado (lista) → Critérios de aceite (checklist) → Pendências, se houver.

Estrutura — Bug

Contexto (onde ocorre, desde quando, impacto no cliente) → Comportamento atual (com defeito) → Comportamento esperado → Passos para reproduzir (numerados) → Ambiente/Evidências (navegador, perfil testado, print) → Critérios de aceite → Pendências, se houver.

Diferenças entre os dois tipos

Regra de ouro: nunca inventar informação que não foi fornecida. Se faltar um dado necessário — público-alvo de teste, comportamento visual não especificado, decisão de design — isso vira pendência registrada, citando quem precisa confirmar (design, cliente ou dev sênior) quando for possível inferir.