Painel Local — Cypress Core

Documenta o painel (painel-local/, npm run painel): o que ele é, pra que serve, e como cada aba funciona. Não confundir com estrategia-de-testes.md (o que a suíte cobre) ou triagem-de-falhas.md (o processo de investigar uma falha) — este documento é sobre a ferramenta, não sobre o produto nem sobre o processo.

O que é

Uma interface web local ("Painel de Controle - Cypress") que reúne, num lugar só, as ações do dia a dia de quem mantém esta suíte: rodar specs sem decorar comando de terminal, ver o relatório da última execução, consultar a documentação do projeto, e transformar uma falha capturada automaticamente em Story/Bug/comentário no Azure DevOps — sem digitar nada à mão duas vezes.

Não é um serviço, não fica no ar sozinho, não roda em produção nem em CI: é um servidor Node comum (painel-local/server.js), escutando só em 127.0.0.1:4737 (nunca na rede), que você sobe quando precisa e fecha quando termina. Não salva nada por conta própria — relê package.json, cypress/e2e/, docs/falhas-pendentes.md e docs/historico-de-falhas.md a cada requisição, e publica no Azure DevOps na hora, sem cache/banco local.

Como rodar

npm run painel

Abre sozinho http://localhost:4737 no navegador padrão.

Aba Dashboard

Primeira aba do painel — visão geral do mês antes de decidir o que rodar. Reorganizada em 04/09/2026 pra seguir a estrutura de um layout de referência que o usuário aprovou (subheader + linha de KPIs + grade de cards + tabela) — mantendo a regra de sempre: todo número aqui é real, calculado a partir de dashboard-execucoes.md e historico-de-falhas.md, sem banco/estado próprio. Onde o layout de referência mostrava algo sem equivalente real no projeto (branch/commit/autor por execução, um painel "Azure Backlog" com sincronização própria, duração média de suíte — nada disso é rastreado hoje), o widget foi trocado por algo que a gente realmente tem, em vez de inventar número.

• Linha de KPIs — Total de testes no mês (com taxa de sucesso), Execuções registradas no mês (linhas de dashboard-execucoes.md), Falhas pendentes de triagem (tamanho de falhas-pendentes.md), Work Items no Azure. Este último é o número de itens ÚNICOS (workItemsUnicosTotal, server.js) — cada número de Work Item conta 1 vez, não importa quantas vezes ele foi vinculado (Criado/Comentado/Vinculado) nem quantos testes apontam pra ele.
• Resultado das execuções do mês (donut) — soma de aprovados x reprovados de toda execução cypress run registrada no mês corrente. Centro mostra a taxa de sucesso (ex.: "91.5% / APROVADOS").
• Módulos com mais reprovações (barras HTML — cor da barra reflete concentração: verde ≤25%, âmbar ≤50%, vermelho acima disso) — reprovações agrupadas por funcionalidade real do Core (Boleto, Conta Corrente, Subconta...), não por tipo de spec/pasta. Um spec cujo nome bate com mais de um módulo (ex.: condominioConfiguracaoBoleto.cy.js, que cita tanto "condominio" quanto "boleto") soma nas duas barras — mais honesto do que forçar um balde só.
• Work Items no Azure DevOps, por tipo (donut) — mesma fonte/total do KPI "Work Items no Azure" acima (workItemsUnicosPorTipo/workItemsUnicosTotal, deduplicado por id, qualquer Ação) — os dois números SEMPRE batem, por construção. Achado real, 04/09/2026: antes esse gráfico usava uma contagem diferente (demandasCriadasPorTipo, só Ação = Criado) e não batia com o KPI — o usuário notou a divergência (3 no gráfico vs 4 no KPI) e pediu pra bater; o gráfico passou a usar a MESMA fonte do KPI (deixou de existir uma métrica separada só pra "criações novas" nesta aba). Cor por tipo reaproveita o mesmo critério visual do card "Work Items recentes" logo ao lado (Bug=vermelho, Task=azul, User Story/Outro=verde).
• Work Items recentes (lista, com rolagem própria) — últimos vínculos publicados pelo painel (tabela "Work Items do Azure DevOps vinculados" de historico-de-falhas.md), mais recente primeiro, cada um linkando pro item real no Azure. Substitui o painel fictício "Azure Backlog" do layout de referência.
• Execuções headless registradas (tabela, com busca por script/spec) — uma linha por cypress run real, direto de dashboard-execucoes.md. Sem colunas de branch/commit/autor (não existem no projeto) — em vez disso mostra script, total/pass/fail e specs com falha.

Cada gráfico/lista mostra uma mensagem própria quando não há dado suficiente no mês (em vez de gráfico vazio/quebrado). Botão "🔄 Atualizar Telemetria" relê tudo do zero.

Os 2 donuts (montarDonutHtml(), painel-local/client.js) são SVG puro desenhado à mão, sem lib de gráfico — trocado do Chart.js em 04/09/2026 (sugestão de layout do Stitch: anel com buraco no centro e glow por segmento via drop-shadow na própria cor, não Chart.js/canvas). Chart.js foi removido do projeto inteiro (não sobrou outro uso). Os 4 cartões desta linha (2 donuts + Módulos + Work Items recentes) têm sempre a mesma altura — a do maior — de propósito (pedido do usuário, mesmo dia): .grid-dashboard usa align-items no padrão (stretch), não start.

docs/dashboard-execucoes.md

Tabela alimentada sozinha pelo hook after:run do Cypress (cypress.config.js) — toda execução via cypress run (headless; cypress open não dispara after:run) vira uma linha nova, sucesso ou falha, com data, qual script do package.json foi usado (detectado comparando o conjunto de specs que rodou contra o conjunto que cada cy:run* cobre — não dá pra ler isso do process.argv dentro do processo do Cypress, ele não reflete o comando original do terminal), total/aprovados/reprovados e quais specs tiveram falha. Igual a falhas-pendentes.md: não editar à mão, é fato bruto que o Dashboard consome. Versionado (vai pro git) — é histórico, não cache local.

Aba Execução

Roda specs sem precisar lembrar o comando exato. Reorganizada em 04/09/2026 (a versão anterior — 3 colunas de larguras desiguais, um console sempre aberto do lado espremendo o conteúdo — foi considerada "bagunçada" pelo usuário; esta é a 2ª tentativa, com um mockup interativo aprovado antes de mexer no código de verdade):

• Alerta de falhas pendentes (faixa vermelha no topo, some sozinha quando a fila está vazia) — mesmo falhasPendentesCount que alimenta o KPI "Falhas pendentes" do Dashboard, real, não decorativo.
• Busca + chips "Módulos" no topo — digite ou clique num chip (Boleto, Conta Corrente, Login...) pra preencher a busca sozinho. Filtra scripts do package.json (cy:open/cy:run*) E specs individuais ao mesmo tempo, pelo nome OU pela tag { tags: '@modulo' } do spec — necessário pra achar módulo que só existe como it() dentro de um spec maior (ex.: "Termos Aceite" mora dentro de smoke.cy.js, não tem arquivo próprio). Um script "genérico" (ex.: cy:run:regressao) aparece no resultado se ele cobrir algum spec que bate com o termo — mesmo sem o nome do script bater.
• 3 sub-abas, só uma visível por vez (antes tudo ficava empilhado numa rolagem só):
  • Por demanda — digita o número de uma demanda do Azure DevOps. Duas possibilidades:
    • Vínculo exato: se a demanda já tem teste(s) vinculado(s) (tabela "Work Items do Azure DevOps vinculados" em historico-de-falhas.md), o painel acha e lista, e o botão "▶ Rodar e verificar" roda de verdade e mostra ✅/❌ por teste na mesma tela — essa ação espera o cypress run terminar antes de responder (pode levar alguns minutos), diferente do resto da aba (que só inicia e segue, acompanhando pelo console — ver abaixo).
    • Sem vínculo exato: o painel consulta a demanda real no Azure e tenta achar um módulo conhecido de 2 jeitos, nessa ordem — Tag da demanda primeiro (ex.: "Boleto API", mais confiável, porque alguém marcou de propósito — nem toda demanda tem), e título/descrição como plano B (sinal mais fraco, pode citar a palavra por acaso). Achando por qualquer um dos 2, sugere os specs daquele módulo, deixando claro qual sinal achou. Se nem isso bater, avisa que não achou nada relacionado. Em ambos os casos: só leitura/execução local — não publica nem muda nada no Azure.
  • Scripts — "Scripts gerais" (sem --spec, rodam a suíte inteira) e "Scripts por categoria" (cy:run:smoke, cy:run:sanity...), como antes.
  • Cenários específicos — todo .cy.js de cypress/e2e, agrupado pela estrutura real de pastas do projeto. Specs marcados ⚠️ criam dado real em homologação a cada execução (ver CLAUDE.md, seção "Cuidado com dados reais"). Aparece aqui também "▶ Rodar todos os N" sempre que a busca/um módulo tiver pelo menos 1 resultado — roda TODOS os specs encontrados numa execução só (cypress run --spec com lista separada por vírgula), com o mesmo aviso de "cria dado real" se algum deles criar.
  • As duas abas "Scripts" e "Cenários específicos" mostram a contagem de resultados da busca atual no próprio rótulo da aba (ex.: "Scripts (3)") — como só uma fica visível por vez, sem isso um resultado num painel fechado passaria batido.
• Acordeão, não mais cards em grade (04/09/2026 — o usuário achou os cards antigos "muito feio" e mostrou um layout de referência com esse padrão): cada linha de "Scripts"/"Cenários específicos" e da lista de sugestões "relacionado" em "Por demanda" (ver acima) é 1 acordeão com um botão ▶ — clicar roda de verdade (mesmas rotas /api/rodar//api/rodar-spec de sempre) e expande a própria linha, mostrando o console daquela execução embutido ali — não um resumo estático tipo "1 PASS" (a aba "Execução & Specs" do exemplo era um visualizador de relatório pronto, com dado fictício; a nossa continua sendo o disparador de execução de sempre, só copiando o padrão visual). A borda muda de cor com o estado real: azul rodando, verde sucesso, vermelho falhou. O mesmo spec pode aparecer em 2 listas ao mesmo tempo (ex.: sugerido em "Por demanda" e também listado em "Cenários específicos") — acharChaveLinhaPorTitulo() (client.js) sincroniza TODAS as linhas com a mesma chave juntas, não só uma.
• Faixa de status global, grudada no rodapé — visível em qualquer aba (fica fora de <main> no HTML, não só dentro de Execução & Specs), escondida até a 1ª execução da sessão. Passou por 3 versões no mesmo dia (04/09/2026): 1ª era um console completo (abre/recolhe, botão "Limpar", saída inteira) grudado só dentro da aba Execução; o usuário pediu pra reduzir pra só 1 linha de status, sem abrir/fechar; depois notou que isso deixava execução em lote ("Rodar todos"/"Rodar por demanda", que não aponta pra uma linha só do acordeão) sem nenhum jeito de acompanhar a saída ao vivo — versão atual (3ª): recolhida por padrão (só "Rodando: X" → "Concluído"/"Falhou", com bolinha colorida), mas com um botão "▸ Expandir" que mostra a saída completa sob demanda (clicar de novo recolhe). Nunca abre sozinha (nem quando uma execução começa) — só o usuário decide expandir. Pra execução de 1 script/spec só, a linha correspondente do acordeão já mostra o mesmo conteúdo (ver acima) — expandir aqui também é só redundante, não atrapalha. Cada botão "Rodar" (a "Por demanda", ver acima) roda o comando via spawn no servidor (painel-local/server.js, iniciarExecucao) e transmite stdout/stderr ao vivo via Server-Sent Events (GET /api/execucao/stream) — nunca abre janela cmd separada. Só 1 execução por vez (2º clique enquanto uma está rodando devolve erro 409) — evita 2 cypress run brigando pela mesma mochawesome-report/. A "chave" que liga uma execução em andamento à linha certa do acordeão é o próprio titulo que o servidor já usa (npm run <script> ou o caminho do spec) — client.js (acharChaveLinhaPorTitulo/sincronizarLinhaAoVivo) casa isso contra o data-chave de cada linha renderizada, tolerando o mesmo spec aparecer em 2 listas ao mesmo tempo; digitar na busca no meio de uma execução reconstrói a lista, mas reidrata a linha certa em seguida, sem perder o console dela.
• Botão "⏹ Parar" (mesma barra global, só visível enquanto tem algo rodando) — cancela de verdade a execução, com confirmação antes (irreversível, não retoma de onde parou). No Windows, mata a ÁRVORE inteira de processos (taskkill /pid X /t /f, não só .kill() no processo do spawn — esse é só o cmd.exe que o shell:true cria, matar só ele deixaria o Cypress/ Electron de verdade órfão). Novo status cancelada (bolinha/borda âmbar), diferente de falhou — nenhuma linha nasce em dashboard-execucoes.md pra uma execução cancelada (o after:run do Cypress não dispara numa morte forçada, então não há telemetria "errada" pra filtrar depois). Pausar de verdade (tipo cy.pause(), parar NO MEIO de um passo pra inspecionar) não é possível em modo headless — limitação do próprio Cypress, não dá pra contornar por aqui.

Visual (04/09/2026)

Paleta, tipografia e componentes (topbar, chips, badges, console) adaptados de um design system de referência que o usuário aprovou ("Precision Engineering Dashboard" — zinc scale neutra + azul/verde/âmbar/vermelho só pra estado de execução, fontes Geist/Inter/JetBrains Mono via Google Fonts, raios pequenos 4/6/8px, bordas finas no lugar de sombra). Dois detalhes ficam ao vivo, não decorativos:

• Chip de versões no topbar (CY 13.17.0 · Electron 118 · Node v24.19.0) — só aparece depois da 1ª execução real da sessão; client.js (detectarVersoes) lê essas 3 linhas do próprio console de execução (Cypress sempre imprime isso no início de todo cypress run), nunca um número fixo no HTML que poderia ficar desatualizado.
• Pill "Azure DevOps: conectado/sem conexão" no topbar — chama GET /api/iteracao-atual ao carregar a página; erro (PAT ausente, rede fora) vira o motivo no title do pill.

Badges e status (✅/❌/⚠️/🔗 antigos) viraram um indicador de 6px colorido (.dot, classes dot-verde/dot-amarelo/dot-vermelho/dot-azul/dot-cinza) + texto — mesmo padrão pros 6 lugares que mostram estado (badge "já reportado", badge "demanda aprovada", badge "cria dado real", resultado de teste em "Rodar por demanda", status do console). Ícones decorativos em botões (🔎 busca, 🧹 limpar, 🔄 atualizar, ⛶ tela cheia etc.) não foram trocados — decisão de escopo, não pedido explícito do usuário; dá pra revisitar depois se quiser ir mais longe.

Tema claro/escuro

Botão 🌙/☀️ no cabeçalho alterna o tema — aplicado via atributo data-tema na tag <html> (index.html) e persistido em localStorage. Escuro é o padrão (pedido do usuário, 04/09/2026 — não olha mais prefers-color-scheme do sistema) pra quem nunca trocou antes; quem trocar pra claro tem isso lembrado nas próximas visitas. Toda cor do painel é uma variável CSS que já responde sozinha à troca; a única exceção cuidada à parte são os donuts da aba Dashboard (montarDonutHtml()), cujo glow por segmento precisa de hex literal (não aceita var()) — carregarDashboard() (client.js) escolhe o hex certo por tema via CORES_STATUS, e o botão de tema força um recarregamento do Dashboard ao trocar. Paleta do tema ESCURO recalibrada em 04/09/2026 (sugestão do Stitch, passo de contraste acessível WCAG AA) — só o escuro, o claro continua o "Precision Engineering Dashboard" de antes. O console de execução (ver acima) fica sempre escuro, nos dois temas — de propósito, mesmo padrão de terminal/log que a maioria das ferramentas de dev mantém independente do tema geral do app. Logo do topbar é painel-local/logo_transparent.png (marca gradiente, sem texto) — funciona nos 2 temas sem precisar de variante separada.

Flag "Modo Dev" (topo, visível em toda aba)

Separa execução de desenvolvimento (rodando um spec novo várias vezes, ajustando seletor) de teste válido de verdade — pedido do usuário, 04/09/2026, pra não furar as métricas do Dashboard nem encher a fila de falhas pendentes com ruído de quem está construindo automação.

Um único toggle (🧪 Modo Dev, pill no topbar, persistido em localStorage) — nunca mistura os 2 universos, é sempre um ou outro:

• Ligado: toda execução nova (qualquer botão do painel) nasce marcada dev; Dashboard e Falhas pendentes só mostram o que é dev (fica zerado até você rodar algo nesse modo). Uma barra âmbar fixa no topo da viewport avisa que está ligado, mesmo rolando a página.
• Desligado (padrão): fluxo normal — grava e mostra só real.

Nada nunca deixa de ser gravado — docs/dashboard-execucoes.md (coluna Modo, dev/real) e docs/falhas-pendentes.md (linha **Modo:** dev, omitida quando é real) recebem toda execução sempre; o toggle só decide o que aparece. Ausência da marca (linhas de antes dessa flag existir) conta como real.

Mecanicamente: o servidor do painel e o processo do Cypress são processos SEPARADOS (spawn), sem memória compartilhada — só arquivo em disco e o comando de linha. Por isso o toggle acrescenta --env modoDev=true (ou -- --env modoDev=true pros scripts npm run) no comando spawnado (iniciarExecucao, 4 rotas: /api/rodar, /api/rodar-spec, /api/rodar-varios, /api/demanda/rodar), e cypress.config.js lê config.env.modoDev na hora de gravar cada linha. GET /api/dashboard/GET /api/falhas recebem ?modoDev=true/false refletindo o estado ATUAL do toggle no navegador.

"Work Items no Azure" (KPI, donut, lista publicados) fica de fora de propósito — publicar uma demanda real no Azure é sempre uma ação deliberada, não faz sentido "modo dev" pra isso.

Aba Relatório (Mochawesome)

Mostra o mochawesome-report/ da última execução (gerado por qualquer cypress run disparado na aba Execução) direto num iframe, com botão "🔄 Atualizar" (relê o relatório mais recente) e "⛶ Tela cheia" — útil porque o relatório tem bastante informação por tela e o iframe padrão fica pequeno pra ler confortavelmente. Conteúdo do iframe em si não foi alterado no visual (04/09/2026) — é o relatório real do Mochawesome, fora do controle do painel.

Aba Documentação (HTML)

Mostra o docs/html/ (gerado por npm run docs:build/npm run watch) direto no painel — a mesma documentação que você está lendo agora, sem precisar abrir os arquivos .html à parte. Também tem "🔄 Atualizar" e "⛶ Tela cheia". Mesmo caso da aba Relatório: conteúdo do iframe não mudou no visual.

Aba Azure DevOps

2 sub-abas (mesmo padrão de "Por demanda/Scripts/Cenários específicos" da aba Execução & Specs — adicionado 04/09/2026, pedido do usuário: "sentindo falta de consultar todas as demandas já criadas, não só as mais recentes do Dashboard"):

• Falhas pendentes — lê docs/falhas-pendentes.md (a fila de falhas capturadas automaticamente pelo Cypress, ver triagem-de-falhas.md) num layout mestre-detalhe (reformulado em 04/09/2026, a partir de uma referência visual do usuário — antes era uma pilha de cards empilhados):
  • Fila à esquerda — 1 linha por falha, com indicador de status REAL (nunca severidade inventada): cinza "ainda não reportada", amarelo "já reportada antes" (recorrência), vermelho "demanda já aprovada, mas este teste ainda falha" — os mesmos 2 sinais que o painel já calculava, só reaproveitados aqui como cor. Busca livre (teste/spec/erro) acima da fila — um filtro por módulo real (chips) chegou a existir, mas foi removido a pedido do usuário no mesmo dia ("pode tirar esse filtro").
  • Detalhe à direita — erro completo, screenshot automático quando o arquivo ainda existe em cypress/screenshots/ (rota GET /screenshots/*, mesmo servirDiretorio() do Mochawesome/docs; some sozinho, sem ícone quebrado, se o arquivo já foi sobrescrito por uma execução mais nova do mesmo spec), paginação "‹ N de M ›", e os mesmos 4 botões de sempre — Story nova, Bug (com Story pai opcional), Task (com Story pai opcional) ou comentário num item já existente — sempre com prévia antes de publicar. Um 5º botão, "✕ Ignorar" (09/09/2026, visualmente separado dos 4 de cima — tracejado, cor neutra — pra não parecer mais uma opção de publicação), remove só esta falha da fila sem publicar nada no Azure (ver "Ignorar" abaixo). Depois de publicar (ou ignorar) com sucesso, a fila recarrega sozinha e já mostra a próxima. Botão "🔄 Atualizar" relê a lista do zero (útil depois de rodar mais specs na aba Execução, sem precisar trocar de aba e voltar). Botão "🗑 Ignorar todos" (mesma linha, 09/09/2026) faz o mesmo que "Ignorar", mas pra fila inteira de uma vez — ver abaixo.
• Work Items publicados — lista completa (não só os últimos 8 do card "Work Items recentes" do Dashboard) de toda Story/Bug/Task/comentário já publicado pelo painel, mais recente primeiro, com busca por título/número/tipo/spec e o estado atual de cada item consultado ao vivo na API do Azure (GET /api/work-items, enriquecerVinculosComEstado em server.js — mesmo padrão de enriquecerComEstadoDemanda, já usado pra "Falhas pendentes"; item em Testing/Validation/Deployment/Closed ganha destaque verde). O card "Work Items recentes" do Dashboard ganhou um botão "Ver todos →" que já abre direto nessa sub-aba. Ambas as sub-abas mostram a contagem no próprio rótulo (ex.: "Falhas pendentes (16)").

Callout "Modo Direto" (topo da aba, 04/09/2026): lembra que nada fica salvo localmente e que a publicação vai direto pra API do Azure — o pill "OAuth Token Ativo"/"Sem conexão" ao lado é real, mesma checagem (GET /api/iteracao-atual) que alimenta o pill do topbar.

Categoria do erro (ex.: TIMEOUT, ASSERTION FAILED) antes da data/spec de cada card: não é um campo novo — é tipoDeErro() (client.js) lendo palavras-chave no texto REAL do erro já capturado (nunca um valor à parte que poderia divergir do que está no <pre> abaixo).

Badge "🔗 Já reportado": aparece antes do título de uma falha sempre que aquele MESMO teste (título exato) já virou Story/Bug/Task ou já foi comentado num item existente antes — reconhece sozinho uma recorrência, sem precisar abrir o Azure pra conferir. Funciona lendo uma tabela dedicada em historico-de-falhas.md ("Work Items do Azure DevOps vinculados"), que o próprio painel preenche sozinho toda vez que uma publicação tem sucesso — não precisa (nem deve) editar essa tabela na mão.

Falha sai da fila sozinha ao publicar: assim que Story/Bug/Task/comentário publica com sucesso, o painel também remove aquela entrada de docs/falhas-pendentes.md — a partir daquele momento o teste já tem número de demanda no Azure, não precisa mais ficar pendente ali (regra em CLAUDE.md: um achado que já é bug confirmado do Core, mas ainda sem número de demanda, fica de propósito na fila até esse momento — é diferente de "ainda não foi investigado").

"✕ Ignorar" / "🗑 Ignorar todos" (09/09/2026, pedido do usuário: "precisa ter uma forma de limpar pela tela mesmo"): removem entrada(s) de docs/falhas-pendentes.md sem publicar nada no Azure — diferente de "Falha sai da fila sozinha ao publicar" acima, que só acontece depois de um Story/Bug/Task/comentário real. "Ignorar" tira só a falha aberta no momento (POST /api/falhas/ignorar, reaproveita a mesma removerFalhaPendenteSeExistir() usada pela publicação — mesmo critério de match, título exato do teste); "Ignorar todos" tira a fila inteira do modo (Dev/Real) que está sendo visto (POST /api/falhas/ignorar-todos, removerTodasFalhasPendentes() em server.js) — nunca mistura os 2 universos, mesmo critério da flag "Modo Dev" (ver abaixo). Os 2 pedem confirmação (confirm() do navegador) antes de agir, e nenhum dos 2 cria linha em historico-de-falhas.md nem vínculo na tabela de Work Items — "ignorar" é "não preciso ver isso agora", não "já investiguei/reportei". Se o mesmo teste falhar de novo numa execução futura, a captura automática (cypress/support/e2e.js) registra uma entrada nova sozinha, do zero — nada fica "silenciado pra sempre" por ter sido ignorado antes.

Badge "⚠️ Demanda em 'X' — teste ainda falha": aparece junto do badge acima quando o work item vinculado já está num estado avançado (Testing/Validation/Deployment/Closed) mas o teste continua falhando de verdade — sinal de que a correção pode não ter chegado neste ambiente ainda, ou é regressão. O painel consulta o estado ao vivo na API do Azure toda vez que a aba carrega (não fica só no que foi salvo na hora do vínculo) — se a consulta falhar (PAT ausente, rede fora), simplesmente não mostra o badge, sem quebrar o resto da lista.

Botão "✨ Análise IA" (formulário de Story/Bug/Task/comentário, 09/09/2026): preenche automaticamente Motivo do retorno, Comportamento esperado/encontrado, Passos para reproduzir e Exemplo, chamando o Gemini (POST /api/ia/analisar → scripts/gemini-ia.js) com o teste, o erro e o conteúdo real do spec (lido do disco pelo servidor, nunca inventado). Só preenche os campos — não publica nada sozinho, sempre revisar antes de "✓ Confirmar e publicar". Precisa de cypress.env.json → gemini.apiKey configurada (ver CLAUDE.md pra detalhe do modelo usado e como gerar a key); sem isso, o botão mostra o erro de config e os campos continuam editáveis manualmente como antes. Reverte a decisão de 03/09/2026 de não automatizar — aquela rejeitava especificamente a API da Anthropic, por exigir faturamento separado do Claude Code; o Gemini tem free tier sem cartão. Pedir formatação direto no chat com o Claude Code continua funcionando como alternativa (útil sem a key configurada, ou pra um texto mais elaborado).

Onde fica o código

Reaproveita 100% scripts/azure-devops.js pra tudo que é Azure DevOps — a lógica de autenticação/API mora lá, o painel só é a interface.

Fonte: construído incrementalmente ao longo de 03/09/2026, sessão a sessão, junto com quem usa — ver CLAUDE.md, seção "Manter o painel local em dia", pra decisões descartadas no caminho (ex.: botão de IA paga) e detalhe técnico de cada mecanismo automático.