[ariel-sousa]

Descrição

• Funcionalidade entregue: cadastro e edição de pacotes pela Web (issue Add initial FindMyPacks web application #2). Formulário com 6 campos obrigatórios (código de rastreio, cliente, destino, transportadora, status e data de postagem), com validação no formulário, na API e no banco, criação e edição via API e persistência no PostgreSQL.
• Ciclo 1, ordem de integração A–C–B: esta PR (Pessoa B) só será integrada depois da Listagem/exclusão Web #7 (Pessoa C). A Add initial FindMyPacks web application #1 (Pessoa A) já está no main.

Issue relacionada

• Closes Add initial FindMyPacks web application #2

Motivo da correção (PR adicional)

• Motivo: Não se aplica (PR principal).

Alterações realizadas

• Web (index.html, se PR Web): a Web do projeto é React em frontend/src. Novo componente PackageForm.tsx (formulário, validação e chamadas à API) exibido na tela após o login em App.tsx; estilos acrescentados em styles.css.
• CLI (arquivo da CLI, se PR CLI): Não se aplica (PR Web).
• API (endpoints específicos e logs, quando PR CLI): PackageController (POST /api/web/records e PUT /api/web/records/{id}), PackageRequest (regras de validação), PackageResponse e PackageExceptionHandler (400, 404 e 409). Em RequestIdFilter, as operações passam a se chamar create e update.
• Banco (logs, quando PR CLI): migration V2__create_packages.sql (tabela packages), entidade PackageRecord, PackageRecordRepository e PackageDataAccess, que registra um evento db em cada acesso, inclusive leituras.
• Documentação (README.md): nova seção "Package registration and editing (issue Add initial FindMyPacks web application #2)" com uso da tela, regras de validação, modelo de dados, endpoints, exemplo de requisição, logs e testes.

Infraestrutura e suporte

• Arquivos:
  • backend/src/main/resources/db/migration/V2__create_packages.sql
  • backend/src/test/java/com/findmypacks/records/PackageDataAccessTest.java
  • backend/src/test/java/com/findmypacks/records/PackageApiIntegrationTest.java
  • backend/src/test/java/com/findmypacks/user/AdminUserSeederTest.java
  • frontend/src/PackageForm.test.tsx
• Justificativas:
  • Migration: o projeto usa Flyway e ddl-auto: validate, então a tabela precisa ser criada por uma nova migration, sem alterar a V1.
  • PackageDataAccessTest e PackageApiIntegrationTest: testes unitário e de integração exigidos para a funcionalidade nova (sucesso, falhas, 401 e logs correlacionados).
  • AdminUserSeederTest: cobre os dois ramos do AdminUserSeeder sem depender do banco. Sem ele, a cobertura de 100% falhava quando o administrador já existia no volume do banco.
  • RequestIdFilterTest: cobre os nomes de operação create e update.
  • PackageForm.test.tsx: testes do formulário (Vitest); o front não entra na cobertura obrigatória, mas os testes passam.

Endpoints e logs

• Endpoint(s) Web/CLI adicionados ou alterados: POST /api/web/records (201) e PUT /api/web/records/{id} (200). Respostas de erro: 400 (com fieldErrors), 401, 404 e 409 (código de rastreio duplicado).
• Logs da API e do banco, com request_id correlacionado (quando houver acesso ao banco): o cadastro gera api/create e db/check_tracking_code e insert; a edição gera api/update e db/find_package_by_id, check_tracking_code e update. Todos com o mesmo request_id, validado em PackageApiIntegrationTest.
• Como consultar os logs: docker compose logs app (por exemplo docker compose logs app | grep manual-test-1 usando o header X-Request-Id).

Autenticação (quando aplicável)

• Endpoints protegidos e mecanismo Web/CLI utilizado: ambos os endpoints exigem a sessão do login Web (POST /api/web/login) e o token CSRF (GET /api/web/csrf).
• Verificação de acesso autenticado e rejeição HTTP 401: PackageApiIntegrationTest verifica POST e PUT sem sessão retornando 401 e sem alterar o banco.

Testes unitários e cobertura

• Arquivos de teste criados ou alterados: os listados em "Infraestrutura e suporte".
• Comando para executar os testes via Docker Compose: docker compose --profile test run --build --rm tests
• Resultado da execução e cobertura de linhas de 100% em CLI, API e banco (conforme os arquivos existentes):
  Executei docker compose --profile test run --build --rm tests. Front (Vitest): Test Files 2 passed (2) Tests 12 passed (12). Backend (Maven): Tests run: 39, Failures: 0, Errors: 0, Skipped: 0. All coverage checks have been met.
• Confirmação de que os testes anteriores continuam passando:
  Sim. A suíte completa, com os testes da Add initial FindMyPacks web application #1, passou. Rodei duas vezes seguidas, sem docker compose down -v entre elas, e as duas deram BUILD SUCCESS.

Execução integral via Docker Compose

• Comando para iniciar Web, API e banco: docker compose up --build
• Comando para executar a CLI: docker compose --profile cli up --build cli (CLI existente da Add initial FindMyPacks web application #1; esta PR não a altera)
• Comando para executar testes e cobertura: docker compose --profile test run --build --rm tests
• Confirmação de que nenhuma linguagem, dependência ou ferramenta da aplicação precisa ser instalada no host: confirmado; tudo roda em contêineres (apenas Docker e Docker Compose).

Verificação realizada

• Como foi verificado o funcionamento: [ajustar ao que você fez]
  • Pela tela: envio vazio (erros por campo), cadastro válido, edição do registro salvo, código duplicado e data futura.
  • Pela API: POST (201), repetição (409), PUT (200), id inexistente (404) e chamada sem sessão (401).
  • No banco: SELECT * FROM packages; confirmou o registro persistido e atualizado.
  • Nos logs: eventos api e db com o mesmo request_id para um cadastro e uma edição.