feat: Dev Tools ganha Demo/Seed Data, atalho Swagger e garante ENVIRONMENT correto no deploy #39

Merged

jhony75 merged 3 commits from feature/dev-tools-demo-seed-data into develop 2026-09-08 08:37:20 -03:00

Conversation 0 Commits 3 Files changed 13 +965 -6

jhony75 commented 2026-09-08 04:24:04 -03:00

Owner

Copy link

Demo / Seed Data

Nova seção em Dev Tools (só ENVIRONMENT=development, mesmo gate do test-runner existente): "Gerar dataset de demonstração" cria um conjunto pequeno mas visualmente completo no banco de dev real - 1 suite + 6 cenários, 1 plan + 5 runs cobrindo os 3 status de run e os 7 outcomes de step, 5 achados (severidades/status variados + 2 descrições parecidas pra demonstrar a sugestão de achado parecido), 3 requisitos com cobertura completa/parcial/nenhuma, 4 reports em status diferentes, 3 validações técnicas em níveis de progresso diferentes, e um cenário reexecutado com outcomes diferentes gerando sinal real de flakiness.

Todo registro fica marcado com "[DEMO] " no título/nome (+ tag reservada demo-seed nos taggáveis) - sem tabela nova, sem migration. "Limpar dados de demonstração" localiza e apaga exatamente isso. Gerar é idempotente (no-op se já existe um dataset); Limpar é seguro de chamar mesmo sem nada gerado, e nunca toca dado criado manualmente (coberto em teste: cria manualmente 1 report/achado/requisito, gera+limpa o dataset de demo, confirma que só o [DEMO] some).

Reaproveita as mesmas funções de serviço que os routers reais usam (add_scenario_to_run, add_item_to_validation, get_or_create_tags/get_or_create_manufacturers) em vez de inserir estados que os endpoints de verdade nunca produziriam.

Swagger/OpenAPI

/docs e /openapi.json já vinham habilitados por padrão no FastAPI (confirmado - nenhuma mudança de backend necessária). Adicionado um link "↗ Abrir Swagger / OpenAPI" em Dev Tools, reaproveitando a mesma BASE_URL que o resto do frontend já resolve de VITE_API_URL (funciona igual em dev local e em deploy real). Exposição em produção mantida como está (mesmo basic auth do resto da API via Traefik) - decisão confirmada explicitamente antes de implementar.

Deploy DEV garante ENVIRONMENT=development de verdade

compose.yaml é o mesmo arquivo pros dois ambientes - a diferença entre dev/produção é só qual --env-file o CI passa por branch. O script deploy-remote.sh só validava que o arquivo existia, nunca que o ENVIRONMENT dentro dele batia com o esperado - se o .env.dev remoto (mantido manualmente no servidor) estivesse desatualizado ou sem essa variável, o Compose caía silenciosamente no default production, sem erro nenhum.

Fix: export ENVIRONMENT logo após validar o rótulo (já vindo do argumento que o CI passa por branch) - a variável de processo tem precedência sobre o --env-file na resolução do Compose, então toda invocação de docker compose no script passa a receber o valor certo de forma determinística, sem depender de nenhum arquivo mantido manualmente. Mesmo fix fecha o risco simétrico (um .env de produção com development escrito errado). scripts/test-deploy-remote.sh ganha asserções travando essa garantia.

Verificação

• Backend: 154 testes passando (6 novos), incluindo idempotência, preservação de dados manuais, e verificação programática de que as descrições "parecidas" do seed cruzam o threshold real de similaridade.
• Frontend: 99 testes passando (5 novos), typecheck/lint/build limpos.
• bash scripts/test-deploy-remote.sh passando com as novas asserções de ENVIRONMENT.
• Verificado manualmente no navegador: gerar o dataset e navegar por Library (flakiness real detectada, histórico de versão), Runs (todos os status/outcomes), Issues, Requirements + Traceability (3 buckets de cobertura), Reports (4 status) e Technical Validation (3 níveis) - tudo renderiza igual a dado real. Swagger abre corretamente. Limpar remove tudo (verificado via API) sem afetar dados pré-existentes.

🤖 Gerado com Claude Code

## Demo / Seed Data Nova seção em Dev Tools (só `ENVIRONMENT=development`, mesmo gate do test-runner existente): **"Gerar dataset de demonstração"** cria um conjunto pequeno mas visualmente completo no banco de dev real - 1 suite + 6 cenários, 1 plan + 5 runs cobrindo os 3 status de run e os 7 outcomes de step, 5 achados (severidades/status variados + 2 descrições parecidas pra demonstrar a sugestão de achado parecido), 3 requisitos com cobertura completa/parcial/nenhuma, 4 reports em status diferentes, 3 validações técnicas em níveis de progresso diferentes, e um cenário reexecutado com outcomes diferentes gerando sinal real de **flakiness**. Todo registro fica marcado com `"[DEMO] "` no título/nome (+ tag reservada `demo-seed` nos taggáveis) - **sem tabela nova, sem migration**. "Limpar dados de demonstração" localiza e apaga exatamente isso. Gerar é idempotente (no-op se já existe um dataset); Limpar é seguro de chamar mesmo sem nada gerado, e nunca toca dado criado manualmente (coberto em teste: cria manualmente 1 report/achado/requisito, gera+limpa o dataset de demo, confirma que só o `[DEMO]` some). Reaproveita as mesmas funções de serviço que os routers reais usam (`add_scenario_to_run`, `add_item_to_validation`, `get_or_create_tags`/`get_or_create_manufacturers`) em vez de inserir estados que os endpoints de verdade nunca produziriam. ## Swagger/OpenAPI `/docs` e `/openapi.json` já vinham habilitados por padrão no FastAPI (confirmado - nenhuma mudança de backend necessária). Adicionado um link "↗ Abrir Swagger / OpenAPI" em Dev Tools, reaproveitando a mesma `BASE_URL` que o resto do frontend já resolve de `VITE_API_URL` (funciona igual em dev local e em deploy real). Exposição em produção mantida como está (mesmo basic auth do resto da API via Traefik) - decisão confirmada explicitamente antes de implementar. ## Deploy DEV garante ENVIRONMENT=development de verdade `compose.yaml` é o mesmo arquivo pros dois ambientes - a diferença entre dev/produção é só qual `--env-file` o CI passa por branch. O script `deploy-remote.sh` só validava que o arquivo existia, nunca que o `ENVIRONMENT` *dentro* dele batia com o esperado - se o `.env.dev` remoto (mantido manualmente no servidor) estivesse desatualizado ou sem essa variável, o Compose caía silenciosamente no default `production`, sem erro nenhum. Fix: `export ENVIRONMENT` logo após validar o rótulo (já vindo do argumento que o CI passa por branch) - a variável de processo tem precedência sobre o `--env-file` na resolução do Compose, então toda invocação de `docker compose` no script passa a receber o valor certo de forma determinística, sem depender de nenhum arquivo mantido manualmente. Mesmo fix fecha o risco simétrico (um `.env` de produção com `development` escrito errado). `scripts/test-deploy-remote.sh` ganha asserções travando essa garantia. ## Verificação - Backend: 154 testes passando (6 novos), incluindo idempotência, preservação de dados manuais, e verificação programática de que as descrições "parecidas" do seed cruzam o threshold real de similaridade. - Frontend: 99 testes passando (5 novos), typecheck/lint/build limpos. - `bash scripts/test-deploy-remote.sh` passando com as novas asserções de `ENVIRONMENT`. - Verificado manualmente no navegador: gerar o dataset e navegar por Library (flakiness real detectada, histórico de versão), Runs (todos os status/outcomes), Issues, Requirements + Traceability (3 buckets de cobertura), Reports (4 status) e Technical Validation (3 níveis) - tudo renderiza igual a dado real. Swagger abre corretamente. Limpar remove tudo (verificado via API) sem afetar dados pré-existentes. 🤖 Gerado com [Claude Code](https://claude.com/claude-code)

jhony75 added 2 commits 2026-09-08 04:24:05 -03:00

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.

jhony75 added 1 commit 2026-09-08 04:39:54 -03:00

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".

jhony75 merged commit ed9808ee74 into develop 2026-09-08 08:37:20 -03:00

jhony75 referenced this pull request from a commit 2026-09-08 08:37:21 -03:00

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

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!39

No description provided.