Sprint 05 — 19/08 a 01/09¶

Foco: Estimativa Humana vs. Estimativa da IA, Correção de Bug Assistida, Módulo Acompanhamento de Equipe e Resiliência do Processamento Assíncrono

O que há de novo¶

Estimativa da IA vs. Estimativa Humana¶

A separação entre o que a IA estima e o que o desenvolvedor estima foi concluída de ponta a ponta. O objetivo é direto: impedir que o número gerado pela IA ancore o julgamento do time e, ao mesmo tempo, dar ao GP visibilidade sobre o desvio entre as duas estimativas.

Campos independentes no Core — a estimativa da IA e a estimativa humana passaram a ocupar campos distintos na task. Uma não é usada como fallback da outra: se o desenvolvedor não estimar, o campo humano fica vazio, e não herda o valor da IA.
Campo em branco na interface de Tasks — a aba de Tasks apresenta o esforço humano em branco, exigindo preenchimento explícito pelo desenvolvedor. A totalização na story soma apenas as estimativas humanas.
Refinamento via chat alinhado — o agente de chat e a aba de Tasks passaram a respeitar a mesma separação, sem divergência entre os dois caminhos de refinamento.
Aba "Acompanhamento" (GP) — nova aba, visível exclusivamente para o GP ao lado de "Gestão", com tabela hierárquica de épico → feature → story → task. Exibe estimativa da IA, estimativa humana, tempo executado e o desvio percentual com sinal e cor (super-faturamento em vermelho/laranja, sub-faturamento em azul, sempre com valor explícito — nunca comunicado apenas por cor). Stories sem estimativa humana aparecem como "Pendente". Há filtro rápido por nome, filtro por faixa de desvio (acima de 50% e de 100%), expandir/recolher tudo e exportação para CSV. As tasks são carregadas sob demanda ao expandir a story. A implementação seguiu o protótipo homologado na sprint anterior.
Backfill do histórico — tasks anteriores à mudança receberam o preenchimento retroativo da estimativa da IA, para que o comparativo não comece vazio.

Correção de Bug Assistida por IA¶

Fechando a feature que ficou pendente de testes na sprint anterior, o ciclo de correção assistida de bugs está disponível:

O command fix_bug roda no ambiente local do desenvolvedor informando o código do bug. O agente carrega o contexto completo do defeito — título, descrição, passos para reproduzir, comportamento esperado e atual, severidade e critérios de aceite —, executa o prompt especializado e conduz a correção diretamente no codebase.
O prompt é carregado dinamicamente pela plataforma no momento da execução; se não estiver publicado, o command falha antes de qualquer execução, com mensagem nomeando o que está faltando, em vez de cair em um erro genérico de "prompt desconhecido".
Bug inexistente ou sem acesso do usuário produz erro descritivo, sem iniciar a execução. Toda execução é autenticada e registrada em observabilidade.
Planos de correção no Portal — o detalhe do bug ganhou a aba "Planos de Correção", análoga à aba de planos das Stories: lista os planos em ordem cronológica decrescente com data/hora, usuário que executou o command e conteúdo renderizado em markdown. A aba é visível a todos os membros do projeto com acesso ao bug, inclusive em modo somente leitura, e o estado vazio orienta o desenvolvedor a executar o fix_bug. Acompanhar o diagnóstico deixa de exigir consulta ao terminal.

Módulo Acompanhamento de Equipe¶

Novo módulo global da plataforma, para que um Gestor de Acompanhamento monte uma equipe ad-hoc e acompanhe o volume de trabalho concluído por pessoa, em todos os projetos.

Papel e cadastro na Área Admin — o papel "Gestor de Acompanhamento" dá acesso ao módulo e a nada além dele. O Administrador da Plataforma concede e revoga o acesso em uma seção própria da Área Admin, escolhendo a pessoa na busca que já retorna usuários da plataforma e o diretório corporativo em uma única consulta — quem ainda não tem registro é cadastrado no momento em que o Gestor é criado, sem recusa por "usuário não encontrado". Cadastro duplicado é rejeitado com mensagem clara; a remoção pede confirmação, deixando explícito que o acesso será revogado, e não altera nenhuma story, hora ou apuração. O formulário informa, no próprio cadastro, que o papel concede visão de produtividade de todos os colaboradores em todos os projetos — o Administrador sabe o alcance do que está concedendo. Administradores acessam o módulo sem precisar do cadastro.
Relatório de entrega por colaborador — uma seção por pessoa da equipe, com quatro indicadores no período escolhido: stories concluídas, horas estimadas, horas executadas e percentual de tempo salvo (com o total em horas como informação secundária). O percentual é calculado sobre os totais do período — soma do tempo salvo dividida pela soma das horas estimadas —, nunca como média dos percentuais das stories, e não é limitado a nenhuma faixa: estouro grande de estimativa aparece como é. Abaixo dos indicadores, a tabela das stories concluídas traz código (com link para o detalhe), título, projeto, início, término, horas estimadas, executadas e o percentual da story, ordenada por término. A definição de tempo salvo é a mesma já usada nas métricas da aba Gestão — os números não divergem.
Nada é omitido em silêncio — story sem estimativa exibe o percentual como indisponível com o motivo acessível, e não 0% nem célula vazia; horas informadas manualmente recebem marcador visível; cada colaborador exibe quantas stories concluídas ficaram fora dos indicadores e por quê; e lista longa informa explicitamente quantas stories foram cortadas. Há nota fixa de que apenas stories concluídas entram no relatório.
Heatmap mensal de horas por dia — calendário mensal por colaborador (colunas = semanas, linhas = segunda a domingo) com cinco faixas de intensidade referenciadas na jornada de expediente configurada no projeto, onde a faixa superior representa "≥ expediente". Dia acima da jornada recebe marcador próprio além da cor mais intensa; dia sem horas usa cor de "sem atividade", visualmente distinta de fim de semana e de dia fora do mês. O detalhe do dia mostra total de horas, quantas stories contribuíram e a divisão por projeto. A navegação entre meses é compartilhada por toda a equipe e bloqueia meses futuros e anteriores ao primeiro mês com dado. Dias são navegáveis por teclado com rótulo acessível, nenhuma informação depende só de cor e o contraste das faixas atende WCAG 2.1 AA. A legenda explica a escala, a faixa "≥ expediente", a nota de que só stories concluídas contam e a apuração em UTC.
Apuração em background e idempotente — as horas executadas de cada story concluída são distribuídas pelos dias em que ela esteve em andamento, respeitando o expediente do projeto. O cálculo é disparado pelo encerramento da story e pelo ajuste manual de horas — nunca quando o Gestor abre a tela, que apenas lê o já apurado. A soma das fatias diárias fecha exatamente com as horas registradas na story, e o total do mês no heatmap fecha com o indicador do relatório. Reprocessar o mesmo encerramento não duplica nem altera as horas. Corrigir responsável, início ou término de uma story já concluída refaz a apuração para o colaborador anterior e para o novo, sem deixar hora atribuída à pessoa errada. O histórico já existente na plataforma foi carregado por execução controlada da equipe — repetível sem alterar o resultado e com relato de fechamento (colaboradores processados, dias apurados, horas distribuídas, stories ignoradas com motivo e horas não atribuídas).
Métricas do projeto no ajuste manual — o ajuste manual de horas executadas passou a atualizar também as métricas do projeto, e não apenas o registro da story, mantendo a aba Gestão coerente com a correção feita.
Stories concluídas sem responsável — o cabeçalho do módulo exibe quantas stories concluídas no período não têm colaborador atribuído, com explicação acessível de que elas não entram em nenhuma seção do relatório nem no heatmap de ninguém. O contador acompanha a troca de período e só aparece quando há ao menos uma — sem badge zerado.
O módulo foi precedido de protótipo navegável homologado. A equipe é uma seleção local do Gestor, guardada no navegador, não uma entidade persistida no servidor.

Resiliência e Desempenho do Processamento Assíncrono¶

O processamento de filas foi separado do atendimento aos usuários e o tratamento de documentos longos ficou previsível — sem reentrega infinita, sem derrubar a conexão com o broker e sem exigir parada geral do serviço para intervenções pontuais.

Serviço próprio para o processamento de mensagens, isolado da API que atende os usuários: carga de processamento e disponibilidade da aplicação deixaram de competir.
Mensagens que falham repetidamente são encerradas em vez de voltarem indefinidamente para a fila.
Extração de documentos sem derrubar a conexão com a fila e sem prender a mensagem após a conclusão — dois sintomas que antes exigiam intervenção manual.
Limite de tempo por documento: uma extração que trava não bloqueia mais o restante da fila.
Documentos com muitas imagens ficaram drasticamente mais rápidos. A análise de imagens passou a rodar em lotes, com paralelismo configurável por ambiente (sem alteração de código) e tratamento específico de limite de requisições do provedor, evitando throttling. A transcrição de imagem passou a usar o modelo mais rápido e econômico adequado à tarefa, reservando o modelo de maior capacidade para o resumo e a inferência final de metadados. O consumo de memória agora é proporcional ao lote em processamento, não ao documento inteiro. O documento de referência que levava cerca de 1 hora foi medido antes e depois, com tempo significativamente menor e sem regressão na qualidade do conteúdo extraído.

Cadastro de Documento por Texto Colado¶

A área de novo documento passou a oferecer a escolha entre "Upload de Arquivo" e "Colar Texto". No modo texto, o formulário pede Produto (quando o cliente tem catálogo, listando apenas os produtos do atendente), Título, Tipo de Documento e Conteúdo, e oculta o seletor de arquivo. Campo obrigatório em branco gera erro inline e bloqueia o envio.

A partir do envio, o caminho é o mesmo do upload: o documento aparece na listagem com o chip "Aguardando Extração", o agente gera o resumo exclusivamente a partir do texto informado — sem ler nenhum arquivo externo — e o documento segue para "Aguardando Aprovação", com atualização em tempo real na tela e o painel de detalhes exibindo título, tipo, conteúdo gerado e conteúdo completo. Falha na geração do resumo é registrada e o documento exibe o chip "Falhou". Texto que já está disponível digitalmente entra na base de conhecimento sem a fricção de virar arquivo primeiro. Documento cadastrado manualmente

Filtro de Itens Concluídos na Iteração¶

O botão "ocultar itens implementados" da área de iteração passou a ocultar também os bugs com status "Resolvido", e não apenas stories e melhorias "Implementadas". A visão filtrada limpa todos os itens já finalizados, independentemente do tipo; bugs em andamento continuam visíveis e desativar o filtro restaura tudo. A preferência do filtro continua preservada entre navegações.

Backlog Expandido¶

Trabalho em andamento e planejado para as próximas sprints:

Exibição do Cargo do Colaborador no Relatório (F7.7) — em desenvolvimento; complementa a seção por colaborador do Acompanhamento de Equipe
Reindexação de FAQs (F14.5) — exclusão dos fragmentos antigos e geração dos novos para FAQs, fechando o reprocessamento da base de conhecimento
Melhorias na Interface de Seleção e Listagem de Produtos (F13.6) — refinamentos de usabilidade no catálogo de produtos
Ocultar Stories Descartadas e Encerradas no Backlog de Planejamento (F7.3) — alinha a aba de Planejamento ao comportamento já entregue nas listas de alocação
Board Executivo e Consolidação de Métricas (F7.6) — vínculo de cliente no cadastro do projeto, consolidação de métricas por dia/iteração/mês, indicadores executivos e delivery por quarter, cycle time consolidado, throughput e velocity por iteração, burndown e distribuição por categoria da sprint atual, painel de AMS (causa raiz, severidade, incidente/defeito e origem do bug por cliente), linha do tempo mensal, status e ciclo de vida do projeto, ciclo de roadmap e exportação do backlog para CSV
Módulo de Concepção (F2.9) — amadurecimento de uma ideia em conversa com o Facilitador, ciente do que já existe no projeto, com publicação como backlog ou descarte, chat de trabalho com histórico íntegro e navegação nos dois sentidos entre Concepção e Backlog
LLM Gateway (Épico 17) — endpoint de mensagens como proxy com suporte síncrono e streaming, cadastro e motor de políticas de acesso por usuário/grupo com identidade extraída do token, auditoria por requisição, proteção contra abuso e falhas transitórias, e provisionamento em AKS com pipeline de CI/CD e rollback automatizado