56368d5517
Cada renovacao que sai do orgao vira ciclo observado (protocolo -> emissao); a mediana por orgao/tipo estica o prazo de inicio de renovacao quando o orgao esta comprovadamente mais lento que o catalogo. O catalogo e piso legal: os 120 dias da LO nunca encolhem. Campos aditivos effectiveLeadDays/observed no upcoming e nos alertas; GET /compliance/lead-times; seed deterministico. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
60 lines
3.4 KiB
Markdown
60 lines
3.4 KiB
Markdown
# Histórico de mudanças com IA
|
|
|
|
Registro das alterações feitas neste repositório com apoio de IA (Claude), incluindo tempo aproximado.
|
|
Ordem cronológica — **mais recente no topo**.
|
|
|
|
## Formato de entrada
|
|
|
|
```
|
|
### YYYY-MM-DD HH:MM — Título curto
|
|
|
|
- **Tempo:** ~X min
|
|
- **Prompt:** resumo do pedido
|
|
- **Mudanças:** o que foi feito
|
|
- **Artefatos:** branch, PR #, commit hash
|
|
```
|
|
|
|
---
|
|
|
|
### 2026-08-07 02:45 — Prazo de renovação dinâmico por órgão (Onda 1.2)
|
|
|
|
- **Tempo:** ~30 min
|
|
- **Prompt:** substituir o lead fixo do catálogo pelo tempo real observado de emissão por órgão na
|
|
carteira (v0 do plano de IA — estatística descritiva, sem ML).
|
|
- **Mudanças:** entity + migration `renewal_cycle` (gravada automaticamente quando um save zera um
|
|
protocolo; descarta intervalos implausíveis); `LeadTimeService` (mediana/p90 por tipo e por
|
|
órgão; `effectiveLeadDays = max(catálogo, mediana+15)` com amostra ≥ 3 — catálogo é piso);
|
|
`GET /compliance/lead-times`; campos aditivos `effectiveLeadDays`/`observed` no upcoming e no
|
|
alerts/preview, com o degrau `lead` da régua usando o prazo dinâmico; seed determinístico
|
|
`seed-demo-cycles.ts`; 16 testes novos (54 no total, 7 suites). CHANGELOG 1.1.0.
|
|
- **Artefatos:** branch `feat/dynamic-lead-times` (worktree `documentos/documents-service-lead`)
|
|
|
|
### 2026-08-07 — Criação do serviço (espelho do routines)
|
|
|
|
- **Tempo:** ~60 min
|
|
- **Prompt:** criar o microserviço `documents` para a feature Documentos e Licenças do painel,
|
|
espelhando o `routines` (padrões, storage, infra), com catálogo por UF, documentos com versões,
|
|
conformidade, análise de upload e régua de alertas.
|
|
- **Mudanças:**
|
|
- Esqueleto NestJS 10 + Fastify + TypeORM copiado do `routines` (main/app/ormconfig/
|
|
interceptor/tenant DTOs/storage/mocks de teste idênticos, nomes adaptados, prefixo `DOC`).
|
|
- Módulos: `catalog` (tipos + override por UF aplicado na leitura), `document` (obrigação única
|
|
por tipo/loja com unique no banco; renovação = versão nova + protocolo zerado; upload
|
|
multipart com campos antes do arquivo e checagem de `truncated`, igual às fotos de Rotinas),
|
|
`compliance` (score ponderado — porte fiel do `buildComplianceSummary` do painel),
|
|
`alerts` (régua lead/30/15/7/1/vencido; protocolado não alerta; envio real é v1.2).
|
|
- Regra de status em `status.util.ts` — porte fiel do `resolveStatus` da simulação do painel;
|
|
datas comparadas em meio-dia UTC para não depender de fuso/horário de verão.
|
|
- Análise plugável: interface `DocumentAnalyzer` + `KeywordAnalyzer` (v1); OCR/LLM troca o
|
|
provider `DOCUMENT_ANALYZER` sem tocar controller/service.
|
|
- Migration única: DDL + seed dos 15 tipos (cópia exata do catálogo do frontend, inserts
|
|
parametrizados por causa dos acentos) + 3 overrides de exemplo (AVCB SP/GO, LO SP).
|
|
- 38 testes (status, score, analyzer, save/renovação/protocolo/tenant, régua). Desvio
|
|
consciente do jest.config do routines: `storage/**` fora da cobertura (testar seria mockar o
|
|
SDK do GCS; controllers e interceptors já ficavam fora no original).
|
|
- Infra: Dockerfile, k8s/hml (deployment com cloudsql-proxy, service, ingress com
|
|
`proxy-body-size: 12m` para PDFs), cloudbuild/cd.yml adaptados.
|
|
- **Verificação:** `yarn build` limpo; `yarn test` 6 suites / 38 testes verdes, cobertura
|
|
98,5% stmts / 80,4% branches (mínimos 73/65).
|
|
- **Artefatos:** repo novo, branch master, commit inicial.
|