develop #42

Merged

jhony75 merged 58 commits from develop into main 2026-09-08 13:58:22 -03:00

Conversation 0 Commits 58 Files changed 276 +32012 -5401

jhony75 commented 2026-09-08 12:43:04 -03:00

Owner

Copy link

Promove develop para main. Principais entregas desde o último sync (PR #23):

• Refactor de UI/UX do frontend (App Shell, Storybook, design system) + fechamento dos gaps do refactor.
• Vocabulário único de outcome (PASS/FAIL/ERROR/BLOCKED/SKIPPED/PENDING/RUNNING) e Automation Discovery.
• IDs estáveis (public_id/external_key), duplicar cenário, failure classification.
• Rastreabilidade Requisito → Cenário → Execução → Achado.
• Controle otimista de edição (If-Unmodified-Since), paginação opt-in, SBOM/scan Trivy no CI.
• Dev Tools: Demo/Seed Data, atalho Swagger, ENVIRONMENT correto garantido no deploy remoto.
• Auditoria e fechamento do pacote backend (outcome vocabulary, failure classification, Automation Discovery, IDs estáveis) — PR #40.
• Passada de estabilização/regressão do frontend novo (sidebar colapsável em mobile, rename de suíte na Library, consistência de Badge de status, limpeza de CSS morto, fix do eslint) — PR #41.

Testado em dev pelo usuário antes desta PR.

Promove `develop` para `main`. Principais entregas desde o último sync (PR #23): - Refactor de UI/UX do frontend (App Shell, Storybook, design system) + fechamento dos gaps do refactor. - Vocabulário único de outcome (PASS/FAIL/ERROR/BLOCKED/SKIPPED/PENDING/RUNNING) e Automation Discovery. - IDs estáveis (`public_id`/`external_key`), duplicar cenário, failure classification. - Rastreabilidade Requisito → Cenário → Execução → Achado. - Controle otimista de edição (If-Unmodified-Since), paginação opt-in, SBOM/scan Trivy no CI. - Dev Tools: Demo/Seed Data, atalho Swagger, `ENVIRONMENT` correto garantido no deploy remoto. - Auditoria e fechamento do pacote backend (outcome vocabulary, failure classification, Automation Discovery, IDs estáveis) — PR #40. - Passada de estabilização/regressão do frontend novo (sidebar colapsável em mobile, rename de suíte na Library, consistência de Badge de status, limpeza de CSS morto, fix do eslint) — PR #41. Testado em dev pelo usuário antes desta PR.

jhony75 added 58 commits 2026-09-08 12:43:04 -03:00

chore: atualizar react-router-dom pra 7.18.3 (corrige 2 advisories moderados) ... 893fd0533b

Faixa vulnerável ia até 7.17.0. Avaliado trocar por TanStack Router e
descartado: o valor dele é inferência de tipo ponta-a-ponta, e o frontend
é 100% JS (zero .ts/.tsx) — sem TypeScript esse ganho não existe, e
reescrever toda a navegação só pra fechar 2 CVEs que um bump resolve não
compensava. API usada (BrowserRouter/Routes/Route/NavLink/useNavigate/
useParams) não mudou entre v6 e v7 — build e testes passam sem alteração
de código.

feat: rollback automático do banco quando o deploy falha (migration interrompida) ... 4933df0bb3

O objetivo é zero contato humano no caso comum: a pipeline vira a guardiã
do status, não a memória de quem fez o deploy. Complementa o rollback de
containers/imagens que já existia.

- deploy-remote.sh: no rollback, restaura o backup do SQLite feito antes
  do deploy (por cima do live db) e remove -wal/-shm da tentativa quebrada
  antes de trocar o arquivo base — sem isso, WAL de um schema mais novo
  aplicado sobre o backup mais antigo corrompe o restore (banco roda em
  journal_mode=wal). Só sobra log de WARNING pedindo intervenção manual se
  o próprio restore falhar.
- DATA_DIR lido direto do env file (sem `source`), com fallback silencioso
  pra fixtures antigas sem essa variável.
- 2 cenários novos em test-deploy-remote.sh (com e sem backup disponível).
- scripts/generate-synthetic-data.py: gera banco sintético de qualquer
  tamanho pra medir esse tipo de operação sem precisar de acesso à VPS.
  RTO medido com ~43 MB (banco de produção real é ~40 MB): drill
  estrutural em 0,66s, restore de arquivo em ~60ms — camada de banco não
  é o gargalo de um rollback real.

feat: Issue vira entidade própria (N:N com Report) + nota geral calculada ... d171004417

Achado deixa de pertencer a um único report: o mesmo defeito reaparecendo
em builds/reports diferentes agora é o mesmo Issue sendo reanexado, não
uma cópia — status (Aberto/Em correção/Verificado/Fechado) e severidade
ficam num lugar só, compartilhados por todo report que o referencia.

- Migration 9f3d2a1c7b44: tabela report_issues (N:N), backfill sem perda
  de dado, origin_report_id como proveniência (não dono).
- API: PUT/DELETE /api/reports/{id}/issues/{issue_id} (anexar/desanexar
  sem duplicar), GET /api/issues (listagem global com filtros), GET
  /api/issues/{id} (detalhe + traceability — reports que o referenciam),
  PATCH /api/issues/{id} (edição, com closed_at automático).
- Report.overall_score deixa de ser preenchido à mão — vira calculado
  (severidade dos achados abertos + status) em compute_overall_score.
- Frontend: telas /achados e /achados/:id, IssuePicker pra anexar achado
  existente em vez de duplicar, nota geral exibida como somente leitura.
- CI: --expect-alembic atualizado pro novo head.

docs: corrigir BACKLOG.md (item de lock Python tinha sumido, react-router não é desta branch) 54add650b0

feat: palavra-chave BDD/Gherkin nos passos de cenário + export .feature ... 72a972528e

Passo de cenário (biblioteca, Report, Run) ganha palavra-chave opcional
(Given/When/Then/And/But). steps continua aceitando string simples
(comportamento antigo) ou {description, keyword} — pode misturar os dois
na mesma lista, sem quebrar quem já manda string.

- gherkin_parser.py (novo, motor genérico): parse_gherkin extrai nome/
  descrição/passos de texto colado em Gherkin (POST /api/scenarios/
  parse-gherkin, botão "Extrair como Gherkin" no fluxo de colar texto que
  já existia); to_feature_text exporta um cenário da biblioteca como
  .feature de verdade (GET /api/scenario-templates/{id}/feature).
- Migration 4c8a1f9d2e63: keyword em test_step_templates e test_run_steps.
- Frontend: seletor de palavra-chave em todo lugar que cria/edita passo
  (ScenarioBuilder, compartilhado por Report/Run/Biblioteca), exibição
  com prefixo da palavra-chave onde já existia leitura, botão .feature na
  Biblioteca.
- Rodar o .feature de verdade (ex.: playwright-bdd) ainda exige escrever
  as step definitions — inerente ao BDD, não dá pra gerar isso a partir
  de texto livre.
- Scenario Outline/Examples (dado parametrizado) deliberadamente fora de
  escopo por ora.

feat: migrar frontend para TypeScript + TanStack Query, adicionar API Playground ... f740066385

Refatoração completa da base do frontend de .jsx/.js pra .tsx/.ts, com tipos
gerados de docs/openapi.json (openapi-typescript) como fonte única de verdade
pro contrato frontend/backend. Busca de dados migrada de useEffect/useState
manual pra @tanstack/react-query em todas as telas, com invalidação explícita
após mutações. CI ganha um passo de typecheck (tsc --noEmit) antes dos testes.

Adiciona também um API Playground (RapiDoc) ao site de documentação, servindo
o mesmo docs/openapi.json já publicado, como alternativa ao Swagger UI/Bruno
pra explorar e testar a API sem subir nada localmente.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Merge pull request 'feat: rollback de deploy, Issue N:N, nota calculada, React Router 7, BDD/Gherkin' (#28) from feature/combined-perf-quality into develop ... bdd63eee96

Reviewed-on: #28

feat: indices em FKs/colunas filtradas + travar dependencias Python ... 7fa5f5947f

SQLite nao indexa chaves estrangeiras automaticamente — adiciona 24 indices
(migration bffe8e3bdf84) nas FKs sem indice e nas colunas mais filtradas em
listagem (Report.status/test_environment/issue_type/build_version,
Issue.status/category/severity, TestRun.status/build_version/test_environment).
Mudanca puramente aditiva, validada com upgrade/downgrade/upgrade, alembic check
(zero drift entre models.py e a migration) e suite completa de testes.

requirements.txt/requirements-dev.txt travados nas versoes exatas ja testadas
(antes >=, resolviam pra qualquer versao nova no build) — builds reproduziveis.
Validado com build limpo da imagem Docker (python:3.12-slim) + subida do
container + GET /api/health.

Usuario nao-root na imagem do backend foi avaliado e adiado — risco de quebrar
a escrita no DATA_DIR em producao sem poder verificar/corrigir a ownership dos
arquivos existentes na VPS a partir daqui; motivo documentado em BACKLOG.md.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Merge pull request 'feat: indices em FKs/colunas filtradas + travar dependencias Python' (#29) from feature/combined-perf-quality into develop ... 5014487a94

Reviewed-on: #29

feat: botao "Rodar testes" em dev (dispara pytest pela UI) ... 2c48711652

Nova tela "Ferramentas de Dev" (/dev-tools) com um botao que dispara a suite
pytest completa e mostra passou/falhou, contagens e saida completa. So aparece
com ENVIRONMENT=development no backend (fail-safe: qualquer outro valor, ou
nao configurado, esconde a rota com 404, sem vazar que existe).

Cada teste da suite usa seu proprio banco SQLite temporario (ver tests/*.py) —
rodar isso pela UI nunca toca no banco de dev/prod de verdade.

Imagem Docker do backend so instala requirements-dev.txt (pytest) quando o
build recebe INSTALL_DEV_DEPS=true (BACKEND_INSTALL_DEV_DEPS=true no .env.dev),
mantendo a imagem de producao enxuta. Validado com build limpo da imagem +
container rodando em modo dev (endpoint disparando a suite real) e em modo
prod (endpoint escondido) + smoke test completo no navegador.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

feat: paginacao opt-in em GET /api/reports, /issues e /runs ... f412c30878

limit/offset opcionais (services/pagination.py) — sem eles, comportamento de
sempre (lista completa, sem envelope); com eles, a lista e fatiada e o total
(antes do corte) vai no header X-Total-Count. 100% retrocompativel: nenhum
consumidor existente precisa mudar. limit vai de 1 a 200 (400 fora da faixa).

Validado com testes automatizados (4 novos, cobrindo os 3 endpoints + limites
invalidos) e manualmente via curl contra dados reais.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

feat: controle otimista de edicao via If-Unmodified-Since ... b82a511aae

PUT /api/reports/{id}, /runs/{id}, /technical-validations/{id} e
PATCH /api/issues/{id} suportam o header HTTP padrao If-Unmodified-Since (RFC
7232) — opt-in, sem quebrar quem nao manda o header (last-write-wins de
sempre). Quem manda e o registro mudou desde entao recebe 412 Precondition
Failed. Os GETs correspondentes mandam Last-Modified de volta.

Issue ganhou updated_at (migration 4ca07fcf36fd, backfill com created_at pras
linhas existentes) — nao tinha essa coluna ainda.

Achado durante a implementacao: Last-Modified/If-Unmodified-Since so tem
resolucao de segundos (padrao HTTP) — comparar direto contra updated_at (que
tem microssegundos) rejeitava toda edicao com 412 mesmo sem conflito real.
Corrigido truncando os dois lados pra segundos antes de comparar.

Frontend ainda nao consome isso (nenhum formulario captura Last-Modified nem
reenvia If-Unmodified-Since) — documentado em BACKLOG.md como proximo passo,
a capacidade ja existe pronta no backend.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

fix: substituir datetime.utcnow() deprecado por time_utils.utcnow_naive() ... 8038d8ca68

datetime.utcnow() esta deprecado desde Python 3.12 (removido numa versao
futura) e gerava 121 DeprecationWarning na suite de testes. Substituido em
todo o backend (models.py, modules/issues, modules/reporting,
modules/eeg_reports/docx_export, scripts/generate-synthetic-data.py) por
time_utils.utcnow_naive() — datetime.now(timezone.utc).replace(tzinfo=None),
que devolve exatamente o mesmo tipo (naive, UTC) que as colunas DateTime do
SQLAlchemy/SQLite sempre esperaram. Mudanca de implementacao, nao de
comportamento nem de schema.

Suite completa (85 testes) roda sem esses warnings agora.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

fix: restaurar import de datetime usado como type hint em docx_export.py ... df4157435e

O commit anterior (8038d8c) removeu "from datetime import datetime" ao trocar
datetime.utcnow() por time_utils.utcnow_naive(), mas o nome datetime ainda era
usado como anotacao de tipo em _data_extenso_pt(dt: datetime) — nao capturado
pelo grep usado pra levantar os usos (so buscava "datetime\." com ponto, nao
pegando anotacoes de tipo puras). Python avalia anotacoes em tempo de definicao
por padrao, entao isso quebrava a importacao do modulo inteiro (NameError),
derrubando a app inteira (qualquer rota que dependa de modules.eeg_reports).

Passou despercebido nos testes locais por causa de bytecode cache
(__pycache__) nao invalidado — confirmado ao reproduzir com cache limpo antes
deste fix (51 failed) e depois (85 passed). Pego pela pipeline de CI (ambiente
limpo, sem cache local) — obrigado por reportar.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Merge pull request 'feat: botao de testes em dev, paginacao, controle otimista, fix datetime.utcnow' (#30) from feature/combined-perf-quality into develop ... 9923c53a7f

Reviewed-on: #30

feat: frontend consome o controle otimista de edicao (If-Unmodified-Since) ... 8969fe9006

ReportDetail, IssueDetail, RunDetail e TechnicalValidationDetail capturam
Last-Modified no GET e reenviam como If-Unmodified-Since no PUT/PATCH de
"Salvar alteracoes" — hook frontend/src/hooks/useLastModified.ts. Um 412
mostra a mensagem do backend com um botao "Recarregar" que refaz o GET
(capturando o Last-Modified novo); depois disso salvar funciona normalmente.

api.ts ganhou ApiError (preserva o status HTTP, antes so a mensagem
sobrevivia) e um onHeaders opcional em RequestOptions pra capturar headers de
resposta sem mudar o tipo de retorno de request() em nenhum outro lugar.

Validado com um teste manual real de conflito (edicao concorrente via curl
enquanto a pagina estava aberta no navegador) — 412 + mensagem + recarregar +
salvar de novo funcionaram ponta a ponta.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

test: cobertura Vitest em formularios/detalhes + telas de listagem restantes ... be86cc80f8

24 novos testes (8 arquivos) cobrindo os formularios de criacao (ReportForm,
RunForm, TechnicalValidationForm — submissao feliz + validacao de campo
obrigatorio) e as telas de detalhe/edicao (ReportDetail, IssueDetail,
RunDetail, TechnicalValidationDetail — carregar, salvar, e o conflito 412 do
controle otimista de edicao visto de ponta a ponta: mensagem exibida, botao
"Recarregar", recuperacao depois de clicar nele), mais as telas de listagem
que ainda nao tinham teste (Issues, Runs, TechnicalValidations).

Helper de teste comum extraido pra frontend/src/test/renderWithProviders.tsx
(era duplicado inline em ReportList.test.tsx), com suporte a rota
parametrizada pros componentes que usam useParams().

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

feat: SBOM + scan de vulnerabilidades (Trivy) no CI ... 6855e5120f

Depois de construir as imagens de backend e frontend (docs fica de fora — nao
serve trafego de aplicacao), o CI roda Trivy:

1. gera SBOM (CycloneDX JSON) — hoje fica nos logs do job, ainda nao publicado
   como artifact baixavel (ver ressalva no BACKLOG.md);
2. escaneia vulnerabilidades e falha o job so em CRITICAL com correcao ja
   publicada (--ignore-unfixed) — HIGH ou CRITICAL sem patch disponivel ficam
   registradas mas nao bloqueiam, ja que nao ha nada acionavel a fazer agora.

Roda antes de "Publish images...", entao uma imagem com CRITICAL corrigivel
nunca chega a ser publicada. Validado localmente simulando o step exato do CI
(mesmas tags, mesmos comandos) contra as duas imagens reais — hoje ambas
passam limpas (backend: 122 componentes no SBOM, frontend: 72, nenhuma
CRITICAL corrigivel).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

fix: remover bind mount de path local no step de SBOM/scan (Trivy) ... 25b062ed93

O CI real (PR #31, run 68) falhou no step novo — nao consegui acessar o log
detalhado (API do Forgejo 15.0.6 nao expõe rota de logs de actions, e a
sessao do navegador nao estava autenticada), entao aplico a correcao mais
provavel com base em como o step estava estruturado.

Causa provavel: -v "$PWD/sbom:/out" monta um path do HOST, resolvido pelo
daemon Docker — mas o job (runs-on: docker) ja roda dentro de um container,
entao o "docker run" do Trivy cria um container IRMAO no daemon do HOST (via
socket compartilhado), nao um filho deste container. $PWD ali e um path
dentro do container do job, que nao existe no host — o bind mount falharia.

Troca --output /out/x.json + bind mount por redirecionamento de stdout
(docker run ... > arquivo.json), que nao depende de resolucao de path entre
containers. Testado localmente: JSON gerado limpo (logs INFO/WARN do Trivy
vao pro stderr, nao contaminam o stdout).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

fix: rodar Trivy como binario nativo em vez de via docker run ... 012db28a69

Log real do CI (PR #31, run 69): Cannot connect to the Docker daemon at
unix:///var/run/docker.sock. Is the docker daemon running? — o container do
job nao expoe um socket Docker de verdade nesse caminho (nem docker,
containerd nem podman testados pelo proprio Trivy), entao um container Trivy
a parte (via docker run -v /var/run/docker.sock:...) nao conseguia inspecionar
as imagens, mesmo com docker build/docker push funcionando normalmente nas
steps anteriores desse mesmo shell.

Corrigido instalando o Trivy como binario nativo (curl | sh do instalador
oficial) e rodando ele direto no shell do job, sem docker run — ele reusa o
mesmo client Docker que ja funciona pras outras steps, sem precisar de socket
algum. Testado num container que replica o cenario (docker CLI + socket real
do host): SBOM e scan de vulnerabilidades funcionam identicos ao esperado.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Merge pull request 'feat: frontend consome optimistic concurrency, cobertura de testes, SBOM/scan' (#31) from feature/combined-perf-quality into develop ... 24a0d75bf2

Reviewed-on: #31

feat: achado verificado exige nota de verificacao (com excecao p/ instabilidade) ... 4ad6e2559d

Status "Verificado" agora exige verification_note (referencia ao reteste, ou
justificativa quando indisponibilidade/instabilidade do ambiente impediu
confirmar via run/step) — verified_without_retest sinaliza esse segundo caso
sem travar o fluxo em infraestrutura de reteste formal. Reabrir o achado limpa
os campos de verificacao. UI em IssueDetail mostra a nota/checkbox quando o
status selecionado e "Verificado".

feat: sugestao de achado parecido ao criar novo achado (so sugere, nunca bloqueia) ... 0fb6d9590e

GET /api/issues/similar compara a descricao digitada com achados existentes
por similaridade de texto (difflib), padrao comum em ferramentas de tracking
(Jira/GitHub/Linear) -- campos estruturados (categoria+severidade+build) nao
capturam paráfrase do mesmo defeito. Frontend sugere anexar em "Novo achado"
sem nunca bloquear a criacao, decisao explicita do usuario.

Documenta em BACKLOG.md a decisao de adiar Issue.category como picklist
curada para o rollout do Authelia (curadoria por admin nao tem enforcement
sem sessao autenticada hoje).

Merge pull request 'feat: achado verificado exige nota de verificacao' (#32) from feature/combined-perf-quality into develop ... a844fc9721

Reviewed-on: #32

feat: rastreabilidade Requisito -> Cenario -> Execucao -> Achado (rumo a X-Ray/TestRail) ... 4414b5ef66

Novo modulo Core modules/traceability: Requirement como entidade livre
(external_url opcional, sem acoplamento a HubSpot/Jira), vinculos N:N manuais
com Issue (direto, independente de Run formal) e com TestScenarioTemplate (no
nivel da biblioteca, nao da instancia de execucao). Historico de execucao vem
de graca via TestRunScenario.template_id/template_version.

GET /api/traceability/matrix: matriz global por padrao, filtro opcional por
build_version/plan_id; linha permanece visivel (status null) quando o filtro
nao bate com nenhuma execucao, pra mostrar a lacuna de cobertura em vez de
escondê-la.

Frontend: /requisitos (CRUD), /requisitos/:id (detalhe com pickers de
vinculo), /rastreabilidade (matriz). Migration 521b1f6452b4 validada
upgrade/downgrade/upgrade + alembic check. 100 testes backend, 47 frontend,
todos passando; verificado ao vivo no navegador end-to-end.

Merge pull request 'feat: rastreabilidade Requisito -> Cenario -> Execucao -> Achado' (#33) from feature/combined-perf-quality into develop ... 16c7458959

Reviewed-on: #33

feat: backlog nao-VPS completo + tags/flakiness rumo a X-Ray/TestRail ... 2ed9334886

- ESLint no frontend (flat config), wirado no CI; desligada a regra nova
  react-hooks/set-state-in-effect (conflita com o padrao proposital de
  useQuery+useEffect->draft local usado em toda tela de detalhe).
- SBOM do Trivy publicado como artifact baixavel do workflow (if: always()).
- Cobertura de CRUD destrutivo/versionamento/concorrencia que estava zerada:
  delete de Plan/Run/RunScenario/scenario alias/ScenarioTemplate direto/item
  de checklist com cascata correta; template referenciado por Run existente
  vira SET NULL sem alterar a copia; edicao nao retroage sobre execucoes ja
  copiadas; historico de versao acumula em ordem; endpoints sem
  If-Unmodified-Since ignoram o header (last-write-wins), nunca 400/412.
- UX: guarda de duplicate-submit (saving/deleting) nos formularios e deletes
  que ficaram de fora do padrao original; os 3 componentes "picker" agora
  aguardam onSelect e mostram erro em vez de fire-and-forget silencioso;
  acoes de "salvar instantaneo" (status de step, item de checklist) capturam
  e mostram erro em vez de falhar em silencio.
- Logs da API viraram JSON estruturado (observability.py). Bug real
  encontrado no processo: alembic/env.py chama fileConfig no init_db(), que
  desabilita todo logger nao listado no alembic.ini -- os logs da API vinham
  sendo silenciados a cada subida do processo. Corrigido reafirmando a
  config depois de init_db(); travado em teste.
- Tags/labels em Issue e TestScenarioTemplate (mesmo vocabulario de Report),
  com filtro em GET /api/issues e contagem em GET /api/tags somando as tres
  entidades. Migration 632765b48860.
- Historico de execucao + sinal de flakiness por cenario da biblioteca
  (GET /api/scenario-templates/{id}/executions) -- mesmo cenario passando e
  falhando entre runs diferentes. Logica de agregacao de status extraida
  pra services/scenario_status.py, compartilhada com a matriz de
  rastreabilidade.
- Import de JUnit XML deixado de fora de proposito -- tem decisoes de
  produto reais em aberto (mapeamento testsuite/testcase, criacao
  automatica de achado, dedup de reimportacao) documentadas no BACKLOG.

119 testes backend, 47 frontend, todos passando; verificado ao vivo no
navegador (tags, filtro por tag, flakiness).

fix: pin upload-artifact a v3 (v4 nao suportado neste runner Forgejo) ... ecdd308a71

O job validate-and-build falhava sempre no ultimo step (publicar SBOM
como artifact) mesmo com todos os checks reais passando: v4+ usa a
Actions Results API, que este runner recusa com "not currently
supported on GHES".

feat: menus de navegacao agrupados com icones (@tabler/icons-react) ... c825bdc08c

Substitui a barra de nav em lista unica (quebrando linha de forma
inconsistente) por menus agrupados com dropdown ("Testes", "Rastreabilidade")
mais icones em todos os itens, incluindo os botoes de acao da Biblioteca
(.feature/Historico/Execucoes).

Merge pull request 'feat: backlog nao-VPS + tags/flakiness rumo a X-Ray/TestRail' (#34) from feature/combined-perf-quality into develop ... 6ac8c7461b

Reviewed-on: #34

refactor: extrai reports/traceability de main.py e adiciona IDs estaveis, duplicar cenario e failure classification ... 6ece5e743f

- main.py cai de ~494 para 76 linhas: vira composition root puro. CRUD de
  Report, relacoes, cenarios/steps, anexos e picklists vao para
  modules/reports/, seguindo o mesmo padrao de eeg_extension de
  modules/reporting/. API HTTP fica byte-identica (validado comparando o
  OpenAPI gerado antes/depois).
- Requirement (+ tabelas de associacao) e os schemas de rastreabilidade saem
  de models.py/schemas.py para modules/traceability/, primeiro domínio a
  quebrar por modulo; models.py/schemas.py reexportam por compatibilidade.
  db_base.py isola Base = declarative_base() pra evitar o import circular que
  isso introduziria (travado em teste de arquitetura novo).
- TestScenarioTemplate ganha public_id (SCN-000481, imutavel) e external_key
  (opcional, editavel, unico) — Requirement -> Cenario, ainda faltava
  identidade estavel pra automacao/API referenciar um cenario sem depender
  do id nem do nome.
- Endpoint de duplicar cenario da biblioteca (copia independente, sem
  historico nem external_key herdada).
- TestRunStep ganha failure_classification (vocabulario fechado, separado do
  outcome), limpo automaticamente quando o step deixa de estar "Falhou".

125 testes de backend passando; migrations testadas com round-trip e contra
o banco de dev real (backfill de public_id confirmado nos dados existentes).

feat: frontend expoe public_id, duplicar cenario e vocabulario de failure_classification ... 176cba61cf

Biblioteca mostra o public_id (SCN-000481) ao lado do nome de cada cenario e
ganha o botao "Duplicar"; api.ts ganha duplicateScenarioTemplate e as
constantes FAILURE_CLASSIFICATIONS/FAILURE_CLASSIFICATION_LABELS (tela em
portugues, valor enviado a API em ingles). Tipos regenerados a partir do
OpenAPI atualizado.

docs: sincroniza arquitetura com o refactor e remove limitacoes ja resolvidas ... d6676031bf

KNOWN_LIMITATIONS.md tinha 3 itens ja resolvidos (paginacao, concorrencia
otimista, testes/lint do frontend) e citava Authelia em vez de Authentik.
ARCHITECTURE.md/MODULAR_ARCHITECTURE.md nao mencionavam modules/traceability/
nem modules/reports/, e documentam agora a convencao de um modules/*/models.py
opcional (db_base.py evitando import circular). README.md tinha referencias
stale a App.jsx/api.js (frontend e TS ha tempo).

feat: vocabulario unico de outcome em ingles + Automation Discovery ... 7937390215

Vocabulario de outcome (TestRunStep.status): migra de 4 strings livres em
portugues (Nao testado/Passou/Falhou/Bloqueado) para um vocabulario fechado
em ingles (schemas.StepOutcome: PENDING/RUNNING/PASS/FAIL/ERROR/BLOCKED/
SKIPPED), compartilhado entre execucao manual e a nova ingestao de automacao.
Migration de dados explicita (nao so troca de string em codigo) + rotulo em
portugues centralizado (STATUS_LABELS_PT) usado em PDF/HTML export.
failure_classification (implementado na rodada anterior) passa a checar o
novo vocabulario; a regra de limpar a classificacao ao sair de FAIL foi
extraida para services/scenario_status.py e compartilhada entre as duas rotas
que editam TestRunStep (modules/reports e modules/test_execution), que antes
podiam divergir. TestRun.status (lifecycle Nao iniciado/Em andamento/
Concluido) fica de fora de proposito - eh o container, nao o outcome de um
resultado.

Automation Discovery (novo modules/automation/): POST /api/automation/runs
recebe um contrato ja normalizado (nunca JUnit/pytest/Playwright direto) e
resolve identidade por (source, external_key) - menor identidade estavel
possivel. Identidade desconhecida vira AutomationDiscovery (UNMAPPED) em vez
de rejeitar o resultado ou criar um TestScenarioTemplate automatico; o
usuario decide depois via map/create-scenario/ignore. Reaproveita
TestRun/TestRunScenario/TestRunStep como definicao/execucao/resultado (um
resultado = um TestRunScenario com um TestRunStep) em vez de estrutura
paralela. Mapear uma discovery faz backfill em lote de template_id nas
execucoes que ja chegaram enquanto UNMAPPED, sem apagar discovery_id (
historico original preservado). TestScenarioTemplate.external_key (unico
globalmente) e AutomationDiscovery.mapped_template_id (escopado por source)
ficam deliberadamente independentes - a ingestao nunca le/escreve
external_key, so o oferece como sugestao ao criar cenario a partir de uma
discovery.

142 testes de backend passando (11 novos de automation, 6 de scenario_status).

feat: frontend usa o vocabulario unico de outcome + classificacao de falha no RunDetail ... c25654469f

STEP_STATUSES/STEP_STATUS_LABELS seguem o novo vocabulario (PENDING/RUNNING/
PASS/FAIL/ERROR/BLOCKED/SKIPPED em ingles, rotulo em portugues na tela).
RunDetail ganha o select de failure_classification (ficava exposto so via API
desde a rodada anterior, sem nenhum jeito de usar pela UI) ao lado do status,
visivel so quando o step esta FAIL.

docs: documenta Automation Discovery e o vocabulario unico de outcome ... d5c40c998e

ARCHITECTURE.md ganha uma secao dedicada explicando a identidade (source +
external_key), por que TestScenarioTemplate.external_key e
AutomationDiscovery.mapped_template_id ficam deliberadamente independentes, e
como UNMAPPED -> MAPPED preserva historico. MODULAR_ARCHITECTURE.md lista
modules/automation/ na estrutura desejada, mesmo padrao de models.py/
schemas.py proprios ja usado em traceability/.

feat: foundations SCSS + App Shell (sidebar) + primeiras primitivas de design system ... 9c8d17262e

Primeiro passo do refactor de UI/UX: infraestrutura + navegacao, sem tocar
telas de dominio ainda.

- styles/tokens + styles/foundations + globals.scss substituem index.css.
  Tokens semanticos novos (--color-bg-page, --color-text-primary, etc.)
  convivem com os nomes antigos (--bg, --ink, --signal...), redefinidos como
  alias 1:1 dos novos - o codigo existente que ainda referencia os nomes
  antigos via style={{}} inline (72+ ocorrencias) continua funcionando sem
  mudanca, migra tela por tela conforme o refactor avanca.
- AppShell/Sidebar substitui o menu horizontal (.topbar/NavDropdown) por uma
  sidebar estavel: Overview / Testing (Library, Plans, Runs) / Quality
  (Issues, Requirements, Traceability) / EEG (Reports, Technical Validation)
  / Analytics / Dev Tools (so em development, mesmo gate de antes). "New
  Report"/"New Run" saem da navegacao global - cada lista ja tem seu proprio
  botao de criar.
- Overview (nova tela): v1 leve, só com dados que ja existem hoje
  (metrics/runs/issues) - 3 KPIs, "precisa de atencao" e "runs recentes".
  Sem grafico novo. Requirement Coverage/Risk Hotspots ficam pra quando o
  backend tiver a agregacao (fora de escopo deste pass).
- Primitivas: Button, Badge, StatusBadge, Card, StatCard (com skeleton de
  loading), PageHeader, EmptyState - cada uma com .tsx/.scss/.test.tsx.

Nenhuma rota mudou, nenhuma funcionalidade foi removida - todos os 17
componentes de tela existentes continuam intactos, so passaram a renderizar
dentro do AppShell em vez do topbar antigo. Verificado manualmente no
navegador (Reports/Overview/Library/Requirements).

71 testes de frontend passando (22 novos), typecheck/lint/build limpos.

feat: adiciona Storybook para documentar componentes de design system ... d5a86f554e

Setup React+Vite (Storybook 10), com addon-a11y (acessibilidade desde o
inicio) e addon-docs. Removi do setup padrao do instalador:

- integracao addon-vitest/@vitest/browser (rodaria as stories como teste via
  Chromium real dentro do `npm test` normal) - risco desnecessario pro CI,
  que nao tem as dependencias de sistema do Chromium headless preparadas;
  Storybook continua funcionando pra visualizar/documentar componentes sem
  isso, só nao testa automaticamente por enquanto.
- addon-mcp e @chromatic-com/storybook - nao usados, dependencia de servico
  externo (Chromatic) sem necessidade concreta agora.
- boilerplate generico de exemplo (src/stories/Button|Header|Page) - trocado
  por stories reais dos componentes que ja existem: StatusBadge (7 outcomes),
  StatCard (default/trend/warning/loading/sem dado), EmptyState (zero
  resultados/com acao/erro/texto longo), Badge, Button, PageHeader, Card.

npm run storybook / npm run build-storybook validados manualmente.

Merge pull request 'feat: backlog tecnico (reports/traceability, IDs estaveis, Automation Discovery)' (#36) from feature/backlog-tecnico-fase1 into develop ... ede25f9fd4

Reviewed-on: #36

feat: RunDetail vira workspace de execucao (progress-first, falhas primeiro) ... 15dc187764

Prioridade B do refactor - transforma o RunDetail de formulario-sempre-aberto
pra workspace de execucao:

- Header: nome do run (leitura), badge de status, "..." com a acao
  destrutiva (excluir run) - antes era um botao solto competindo com o resto.
- Progresso primeiro: "X% completo" + barra + "N / M passos", com contagem
  por outcome (Passou/Falhou/Bloqueado/...) logo abaixo - substitui a antiga
  listagem de metadata como primeira coisa da tela.
- Secao "Falhas" dedicada, só aparece quando ha algo pra triar - mesmo passo
  falho continua tambem na lista completa de cenarios (nao remove
  funcionalidade, so prioriza visualmente).
- Metadata do run (plan/build/ambiente/status/executado por + nome editavel)
  vai pra um painel "Editar detalhes do run" fechado por padrao - edicao
  agora e uma acao explicita, nao o estado inicial da tela.
- Adicionar cenario (biblioteca/HubSpot/avulso) tambem fica atras de um
  toggle "+ Adicionar cenario" em vez de sempre visivel.

Nenhuma funcionalidade foi removida: os mesmos testes de edicao/conflito
continuam passando, so precisaram abrir o painel de detalhes primeiro (esse
e exatamente o comportamento pedido - "edicao acontece explicitamente").

Duas primitivas novas, construidas so agora que uma tela realmente precisou:
- ProgressBar: barra simples com tone brand/danger.
- DropdownMenu: menu "..." pra acao secundaria/destrutiva, fecha ao clicar
  fora (mesmo padrao do antigo NavDropdown).

Corrigido durante a verificacao visual: a sidebar (position:static, esticada
via flex min-height/align-items:stretch) tinha um corte visual real ao rolar
paginas mais altas que a viewport, apesar da altura calculada estar correta
no DOM - troquei para position:sticky (padrao mais robusto pra sidebar de
app shell, também mantém a navegação visível durante o scroll do conteúdo).

80 testes de frontend passando (9 novos), typecheck/lint/build limpos.
Verificado manualmente contra um run real (5 passos, 3 outcomes diferentes)
via API + navegador.

feat: Library vira master/detail em vez de acordeao grande ... 7bff204e50

Prioridade C do refactor - lista compacta a esquerda (suites agrupadas +
"sem suite"), painel de detalhe a direita:

- Linha da lista mostra so nome + versao - public_id, descricao, tags,
  passos, historico e execucoes saem do acordeao expandido e vao pro painel
  de detalhe, organizados em Tabs (Passos/Historico/Execucoes) - grupos
  independentes de informacao, mesmo padrao recomendado pro refactor.
- Acoes destrutivas (excluir suite, excluir cenario) vao pra um menu "..."
  em vez de botao solto competindo com Duplicar/.feature/etc.
- "+ Nova suite" e "+ Novo cenario" ficam atras de toggles em vez de sempre
  visiveis - preparado tambem pro terreno de Shared Steps/Templates futuros
  (o painel de detalhe e o lugar natural pra eles aparecerem depois).
- Duplicar um cenario ou criar um novo agora seleciona automaticamente o
  resultado no painel de detalhe, em vez de só atualizar a lista.

Nenhuma funcionalidade removida: criar suite, criar cenario (em suite ou
avulso), exportar .feature, duplicar, excluir (suite e cenario), historico
de versoes e historico de execucao (com o aviso de instabilidade) - tudo
continua existindo, so reorganizado.

Tabs (novo Core UI): usado aqui pela primeira vez, generico o bastante pra
qualquer tela futura com grupos independentes de conteudo pra mesma entidade.

83 testes de frontend passando (Library.test.tsx reescrito pro novo fluxo
selecionar-depois-ver-detalhe; Tabs.test.tsx novo). Verificado manualmente
no navegador contra a biblioteca real (9 cenarios): selecionar, trocar tabs,
abrir o menu "..." com Duplicar/Excluir.

feat: ReportDetail vira leitura-primeiro com abas e edicao explicita ... ca1a1525b3

Remove o comportamento de mega-form sempre editavel: a tela abre em modo
leitura (Overview/Tests/Findings/Evidence), com edicao dos campos do
report so apos clicar em "Editar". Mesmo padrao ja validado em
RunDetail/Library (PageHeader + DropdownMenu para acoes secundarias,
Tabs para grupos de informacao independentes). Nenhum handler ou
endpoint mudou - so a organizacao da tela.

feat: leitura-primeiro + edicao explicita em Issue/Requirement/TechnicalValidation ... 14f8864224

Aplica o mesmo padrao ja usado em Report/Run/Library aos detalhes de
Achado, Requisito e Validacao Tecnica: os campos proprios da entidade
abrem em modo leitura e so viram formulario apos clicar em "Editar";
Cancelar descarta o rascunho. Gerenciar colecoes relacionadas (cenarios
vinculados, achados vinculados, itens do checklist, evidencias) continua
sempre disponivel, fora do toggle de edicao — mesmo raciocinio ja usado
em ReportDetail.

Extrai o helper ReadField (label/valor no modo leitura) que ate agora
so existia local em ReportDetail, para reuso nas quatro telas.

Acoes destrutivas (Apagar/Excluir) migram para o menu "..." via
DropdownMenu, com "Voltar" removido dos headers — a navegacao ja e
coberta pela Sidebar persistente, mesma decisao tomada em RunDetail e
Library.

PageHeader leve tambem em Traceability e Analytics (Metrics), como
paginas de relatorio/leitura equivalentes ao Overview — sem mudanca de
logica. Analytics ganha StatCard no lugar dos cards de KPI manuais.
Listas puras (Issues, Requirements, Technical Validations) ficam como
estao, consistentes com Runs/Plans/Reports, que tambem nao entraram
neste refactor.

Nenhum handler, endpoint ou contrato de API mudou.

Merge pull request 'feat: refactor de UI/UX (fase 1) - foundations, App Shell, Storybook' (#37) from feature/frontend-ux-refactor-fase1 into develop 1e634bc0fc

feat: fecha gaps do refactor de UI/UX (nav Automation + componentes de severidade/cobertura) ... 21718792e7

Dois itens do escopo original do refactor tinham ficado de fora do PR
anterior (#37):

1. Sidebar ganha o grupo "Automation" com um item desabilitado
   ("Discovery" + badge "Em breve") - so texto/icone, sem link, ate a
   tela de Automation Discovery existir de fato.

2. Tres componentes de design system que so existiam como classes CSS
   legadas (`.pill`, `.scenario-block`) viram componentes reais com
   Storybook:
   - IssueSeverity: badge de severidade de achado (Baixa/Media/Alta).
   - CoverageStatus: status de cobertura de um cenario vinculado a um
     requisito - cobre o outcome normal (via StatusBadge) e o caso
     extra "nunca executado" (nenhuma execucao ainda).
   - ScenarioRow: linha compacta cenario+status+data+acao, usada onde
     um cenario da biblioteca e referenciado por outra entidade.

   Aplicados em Issues/IssueDetail/ReportDetail (IssueSeverity),
   RequirementDetail/Traceability (CoverageStatus), RequirementDetail
   (ScenarioRow) - substituindo o markup ad-hoc equivalente, sem mudar
   nenhum comportamento.

Nenhum handler, endpoint ou contrato de API mudou.

Merge pull request 'feat: fecha gaps do refactor de UI/UX (nav Automation + componentes de severidade/cobertura)' (#38) from feature/design-system-gaps into develop c572adc77e

feat: Dev Tools ganha Demo/Seed Data e atalho pro Swagger/OpenAPI ... 8fdfeef169

Nova seção "Demo / Seed Data" em Dev Tools (só ENVIRONMENT=development, mesmo
gate de _dev_mode_enabled() do test-runner existente): "Gerar dataset de
demonstração" cria um conjunto pequeno mas visualmente completo no banco de
dev real (1 suite + 6 cenarios, 1 plan + 5 runs cobrindo os 3 status de run e
os 7 outcomes de step, 5 achados, 3 requisitos com cobertura completa/parcial/
nenhuma, 4 reports em status diferentes, 3 validacoes tecnicas em niveis de
progresso diferentes, e um cenario reexecutado com outcomes diferentes pra
gerar sinal real de flakiness). Todo registro fica marcado com "[DEMO] " no
titulo/nome (+ tag reservada "demo-seed" nos taggaveis), sem tabela nova nem
migration - "Limpar dados de demonstracao" localiza e apaga exatamente isso.
Gerar é idempotente (no-op se já existe um dataset), Limpar é seguro de
chamar mesmo sem nada gerado.

Reaproveita as mesmas funcoes de servico que os routers reais usam
(add_scenario_to_run, add_item_to_validation, get_or_create_tags/
manufacturers) em vez de inserir estados que os endpoints de verdade nunca
produziriam.

Adiciona tambem um link "Abrir Swagger / OpenAPI" (Swagger UI ja vinha
habilitado por padrao no FastAPI, sem precisar de mudanca no backend) —
usa a mesma BASE_URL que o resto do frontend ja resolve de VITE_API_URL,
funciona igual em dev local e em deploy real.

fix: garante ENVIRONMENT correto no deploy remoto, independente do .env do servidor ... 3d18c91a74

compose.yaml é o mesmo arquivo pros dois ambientes - a unica diferenca entre
dev e producao e qual env file (--env-file) o CI passa pro deploy-remote.sh
por branch. O script so validava que o arquivo existia, nunca que o
ENVIRONMENT *dentro* dele batia com o rotulo esperado: se o .env.dev remoto
(mantido manualmente no servidor, fora do repo) estivesse desatualizado ou
sem essa variavel, o Compose caia silenciosamente no default "production" do
compose.yaml, sem erro nenhum - dependia inteiramente do operador manter esse
arquivo certo.

`export ENVIRONMENT` logo apos a validacao do rotulo (ja vinda do argumento
posicional que o CI passa por branch) promove a variavel pro ambiente do
processo, que tem precedencia sobre o --env-file na resolucao de variaveis do
Compose - toda invocacao de "docker compose" no script (preflight, deploy,
rollback) passa a receber o ENVIRONMENT certo de forma deterministica, sem
mudar compose.yaml nem nenhum contrato de API. Fecha o mesmo risco nos dois
sentidos: um .env.dev sem a variavel nao cai mais em "production" por engano,
e um .env de producao com "development" escrito errado tambem deixa de ter
efeito.

scripts/test-deploy-remote.sh ganha asserções (`ENVIRONMENT=development` /
`ENVIRONMENT=production` no log do docker fake) travando essa garantia em
teste, não só documentando.

test: mock devDemoDataStatus por padrao no teste do DevTools ... 540f456173

Evita o warning "Query data cannot be undefined" do React Query no teste que
so mockava devTestRunnerStatus - o componente sempre chama os dois hooks
(useQuery de status e de demo-data), mesmo no branch "indisponivel".

Merge pull request 'feat: Dev Tools ganha Demo/Seed Data, atalho Swagger e garante ENVIRONMENT correto no deploy' (#39) from feature/dev-tools-demo-seed-data into develop ... ed9808ee74

Reviewed-on: #39

test: cobre 3 gaps de teste da Automation Discovery encontrados em auditoria ... 99992baad8

Revisão do pacote backend (outcome/failure classification/Automation
Discovery/stable IDs) antes da fase de estabilizacao do frontend. Outcome
vocabulary, failure classification e stable IDs (public_id/external_key)
foram auditados e confirmados 100% corretos (migration com backfill,
schemas fechados, nenhuma dependencia residual do vocabulario antigo em
portugues em logica de negocio/frontend/metricas/exports/dados reais do
banco de dev). Automation Discovery tambem teve os 8 requisitos de produto
confirmados no codigo - so faltava cobertura de teste em 3 pontos:

- payload de ingestao com external_key conhecida + desconhecida misturadas
  na mesma requisicao (confirma que uma nao derruba o processamento da
  outra);
- confirmacao negativa de que a ingestao nunca cria um TestScenarioTemplate
  sozinha;
- ciclo de vida completo do status da discovery (criar -> ignorar ->
  reabrir -> mapear) fica dentro do vocabulario fechado UNMAPPED/MAPPED/
  IGNORED.

151 testes de backend passando (3 novos).

ci: re-dispara o pipeline (falha anterior foi timeout de rede baixando o Trivy) 3b8bcd2643

Merge pull request 'test: fecha gaps de cobertura da Automation Discovery encontrados em auditoria' (#40) from feature/close-backend-outcome-automation-audit into develop b280bf03c7

feat: menu lateral vira colapsavel em telas estreitas ... e5278e7836

Em viewport mobile (<=768px) a sidebar ocupava a largura toda e
empurrava o conteudo pra fora da tela, sem nenhum jeito de esconder.
Agora ela vira off-canvas com botao hamburguer e overlay, fechando
sozinha ao navegar.

feat: permite renomear suite direto na Library ... abad9301f0

O menu "..." de cada suite so tinha excluir; nao havia como corrigir o
nome/descricao de uma suite ja criada sem editar no banco.

fix: status de achado usa Badge do design system, nao mais pill cru ... 4ac7b92a4c

ReportDetail e IssueDetail ainda desenhavam o status do achado com
<span class="pill" data-issue-status>, destoando do resto das telas
que ja usam Badge (Report.status, TestRun.status). Segue o mesmo
padrao dos outros badges de status.

chore: remove CSS morto e ignora storybook-static no eslint ... eed085c801

.file-link, .stat-card e .toast nao tem mais nenhum uso no codigo
(auditoria confirmou via grep). O eslint estava lintando
storybook-static/ (saida gerada do build do Storybook) por faltar no
ignore global, gerando 13 erros que nao tinham nada a ver com o app.

Merge pull request 'feat: estabilização/regressão do frontend (item 2 do roadmap)' (#41) from feature/frontend-stabilization-pass into develop ... 5848b6acd2

Reviewed-on: #41

jhony75 merged commit 20adb70b3d into main 2026-09-08 13:58:22 -03:00

jhony75 referenced this pull request from a commit 2026-09-08 13:58:24 -03:00

Merge pull request 'develop' (#42) from develop into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

jhony75/eeg-qa!42

No description provided.