Sprint 04 — 12/08 a 18/08¶

Foco: Governança do Ciclo de Vida de Stories e Iterações, Bugs e Melhorias no Backlog, e Isolamento do Chat Especialista por Produto

O que há de novo¶

Encerrar e Descartar Story pelo PO/GP¶

O ciclo de vida de uma story deixa de depender exclusivamente do fluxo do agente. PO e GP agora contam com duas ações manuais no Portal, acessíveis tanto pelo badge no card da iteração quanto pelo chip no detalhe do work item:

Encerrar — conclui a story sem exigir que todas as tasks estejam finalizadas, para casos implementados fora do fluxo do agente ou encerrados por decisão de negócio. Exibe confirmação antes de executar.
Descartar — registra que a story não será implementada, com justificativa obrigatória. O botão de confirmação permanece desabilitado enquanto o campo estiver vazio.

Stories descartadas ganham status próprio ("Descartada", badge cinza escuro), saem automaticamente das listas de planejamento e de alocação em iteração, mas continuam visíveis na aba Itens de Trabalho com o motivo e a data do descarte registrados. O descarte é irreversível e uma story já concluída não pode ser descartada.

Os dois fluxos atualizam o badge em tempo real via SignalR, sem recarregar a página, e cada transição é registrada em auditoria com usuário, status anterior, status novo, origem manual e — no caso do descarte — a justificativa. Erros da API aparecem dentro do próprio modal, que permanece aberto para nova tentativa.

Encerramento Manual de Iteração¶

Na mesma linha, PO e GP passam a encerrar manualmente uma iteração a partir da interface de planejamento, sem depender do estado individual de cada story. O encerramento é permitido a partir de iterações Planejadas ou Em Andamento; stories não concluídas permanecem com seus status atuais — algo que o modal de confirmação deixa explícito antes de executar. A transição é auditada com origem manual e o status da iteração se atualiza na tela sem refresh.

Registro e Gestão de Bugs¶

O Bug passa a ser um tipo próprio de work item no backlog, ao lado de Épicos, Features e Stories. A entrega cobre o ciclo completo:

Registro — formulário com título, descrição do problema, passos para reproduzir, comportamento esperado e atual, severidade (Crítica, Alta, Média, Baixa) e estimativa de horas opcional. O bug nasce com status "Aberto" e aparece no backlog com badge próprio e cor por severidade.
Visualização e atualização — modal de detalhe com todos os campos; o dropdown de status oferece apenas as transições válidas a partir do estado atual (Aberto → Em Análise → Em Desenvolvimento → Aguardando Validação → Resolvido → Fechado, com reabertura permitida a partir de Fechado). Quem não tem permissão de edição vê o bug em modo somente leitura.
Alocação em iteração — bugs com status Aberto ou Em Análise podem ser selecionados em lote no planejamento, com a estimativa de horas somada à capacidade da iteração. Alocar um bug não altera seu status: a transição continua sendo uma decisão manual do time.

Toda criação, edição e transição fica registrada em auditoria com timestamp e usuário responsável.

Registro e Gestão de Melhorias¶

A Melhoria entra como novo tipo de work item no mesmo nível hierárquico da Story, herdando dela todo o ciclo de vida (status de implementação, datas de início e conclusão, estimativa, tempo real e tempo de ciclo). Na prática, isso significa registrar, detalhar, editar e alocar Melhorias em iteração pelos mesmos fluxos já conhecidos das Stories, com badge "Melhoria" distinguindo-as de Stories e Bugs no backlog e na iteração.

Nas métricas do projeto, Melhorias são contabilizadas como categoria própria — sem se somarem à categoria de Stories —, o que permite separar entrega de escopo estratégico de entrega de melhoria contínua. Itens já existentes não foram convertidos: a distinção vale a partir dos novos registros.

Os agentes de manutenção de work items e de Story Mapping também passaram a reconhecer o tipo: pedidos em linguagem natural como "adicione uma melhoria de acessibilidade na feature 2.5" ou "quais melhorias existem no épico 2?" são roteados corretamente, sem ambiguidade com Story ou Bug. A feature foi precedida de protótipo navegável homologado com PO, Desenvolvedor e Designer.

Chat Especialista Restrito e Isolado por Produto¶

Fechando a frente de Produtos do AMS, o chat especialista passou a respeitar o escopo de conhecimento do atendente de ponta a ponta:

As respostas consideram apenas os produtos que o atendente sustenta naquele cliente, mais o acervo não classificado. A restrição vale para o conteúdo usado no raciocínio, não só para o link exibido — o filtro por produto entra na própria consulta de busca semântica.
O escopo é resolvido pela plataforma, a partir do vínculo persistido, e nunca a partir de parâmetro enviado pela tela.
O chat informa o escopo na abertura da conversa, antes da primeira resposta, e cada citação de fonte agora exibe o produto de origem.
Gestor AMS e Admin conversam com o escopo completo do cliente, com indicação explícita desse modo na tela.

Além da restrição por atendente, a conversa pode ser isolada em um único produto: o produto selecionado no Espaço do Cliente acompanha a abertura da conversa e fica registrado nela, exibido de forma permanente durante toda a thread. Trocar de produto no meio da conversa pede confirmação e inicia uma nova conversa — o histórico anterior permanece acessível e não é recontextualizado. Se o produto for inativado ou desvinculado do atendente com a thread aberta, o envio é bloqueado com orientação para iniciar nova conversa. A opção "Todos os meus produtos" mantém o escopo completo do atendente, e clientes sem catálogo de produtos preservam integralmente a experiência anterior.

No MCP Server, o setup de atendimento AMS deixou de pedir o ID técnico do produto: agora lista os produtos do atendente de forma numerada e aceita seleção por número ou por nome (busca parcial e case-insensitive), selecionando automaticamente quando há apenas um produto vinculado.

Backlog Expandido¶

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

Correção de Bug Assistida por IA (F2.7) — prompt de correção e command resolve_bug no MCP Server em validação; na sequência, suporte ao tipo Bug na entidade de Planos e visualização do plano de correção no detalhe do Bug
Estimativa da IA vs. Estimativa Humana (F2.8) — separação dos campos no Core e protótipo da aba "Acompanhamento" em validação; a seguir, campo de esforço humano em branco na aba de Tasks, guard rail para ocultar a estimativa da IA no console e coletar a estimativa do dev, e alinhamento do refinamento via chat com a separação de estimativas
Melhorias na Interface de Seleção e Listagem de Produtos (F13.6) — refinamentos de usabilidade no catálogo de produtos
Reprocessamento da Base de Conhecimento AMS (F14.5) — disparo de reprocessamento no Core, reextração de conteúdo dos documentos e reindexação de documentos e FAQs no Ingest
Endpoints de Consulta de Work Items na API do amIA-Core (F16.7) — exposição dos chamados integrados para consulta