# Tasks — ampmInsights V2 (v2.0.0)

Board de sprint deste projeto. Fonte da verdade é este arquivo, versionado neste repo — cada
tarefa concluída vira um commit dedicado marcando o checkbox junto da mudança real, então
`git log`/`git blame` funcionam como histórico de status.

## Fluxo de trabalho (confirmado 2026-09-09)

Para cada item abaixo: eu preparo o script/passo documentado → **você roda no seu ambiente e
valida** → você traz o resultado (cole aqui/no chat) → eu marco o checkbox e sigo para o próximo.
Eu não executo nada em banco/console — nem no ambiente congelado, nem em um futuro ambiente de
teste — a menos que você peça explicitamente o contrário.

## Ponto de partida

- **Origem:** fork de `ampmInsights_V1/` (2026-09-09), com `docs/10-carga-cmdb-vulnerabilidades.html`
  trazido de `ampmInsights_V1_Cliente/` (existia lá, faltava em V1) e toda a marca "Documentação V1"
  atualizada para "V2" nas 10 páginas de docs.
- **`ampmInsights_V1/` e `ampmInsights_V1_Cliente/` ficam congelados** — são a réplica validada e
  já implementada no cliente. Nenhuma mudança neles a partir de agora; todo o trabalho de v2.0.0
  acontece só nesta pasta.
- **Nenhum ambiente (ADB) é tocado até haver um ambiente de teste dedicado à v2.** Até lá, este
  ciclo produz apenas SQL (como arquivo, não executado) + documentação passo a passo.
- **Decisão de deploy (2026-09-09):** a v2.0.0 chega ao schema existente por **evolução aditiva**
  (ALTER TABLE / novas tabelas de staging e histórico / MERGE) — nunca por DROP+recriação. Motivo
  explícito do usuário: um DROP passaria impressão negativa entre Oracle e cliente; releases
  incrementais são o caminho profissional.

## Fase 1 — Dados/ETL (design + script, sem executar)

- [ ] **Pronto, aguardando você rodar e validar** — `sql/03_v2_ddl_schema_evolution.sql`: DDL
      híbrido (`ALTER TABLE ... ADD`, 23 colunas em `TB_26AI_TECH_V2` + 12 em `TB_26AI_TECH_CMDB`,
      incluindo `RAW_JSON` CLOB catch-all em cada uma), 100% aditivo (sem DROP), com checkpoint de
      validação embutido no próprio script. **Pendência antes de rodar:** decidir em qual ambiente
      (o atual está marcado como intocável — ver seção "Ponto de partida" acima).
- [ ] Atualizar `V_26AI_TECH` + `json_object` de `PRC_26AI_TECH` para expor os campos novos ao LLM
- [ ] Novos perfis de carga (`DL_TECH_VULNERABILIDADE_V3`, `DL_TECH_CMDB_V2`)
- [ ] Pipeline de staging: bucket → `TB_26AI_TECH_V2_STG` via `DBMS_CLOUD.COPY_DATA` (tabela nova,
      não mexe nas existentes)
- [ ] `MERGE` com histórico (`LOAD_BATCH_ID`, `TB_26AI_TECH_V2_HIST` — tabela nova), honrando o
      campo `state` do Tenable (NEW/ACTIVE/FIXED/RESURFACED)
- [ ] Documentar passo a passo de cada script acima em `docs/` (novo capítulo `11-schema-v2.html`
      ou extensão do `10-carga`, a decidir ao chegar lá)

## Fase 2 — Validação (só quando houver ambiente dedicado)

- [ ] Provisionar/receber acesso a um ambiente de teste **que não seja a réplica validada atual**
- [ ] Aplicar o DDL/ETL da Fase 1 nesse ambiente; QA dos campos novos
- [ ] Validar que o AI Insight cita CVE/pacote/remediação de fato (amostra de 5-10 ativos)
- [ ] Rodar geração de insight em lote; revisão de qualidade
- [ ] Relatórios visuais (top CVEs/CISA KEV, ativos mais expostos, tendência semanal via `_HIST`)

## Fase 3 — Release controlada (v2.0.0 como novo release, não como rebuild)

- [ ] Congelar escopo v2.0.0, gerar zip, validar em ambiente limpo
- [ ] Aplicar a release **de forma aditiva** no ambiente do cliente (sem downtime, sem DROP)
- [ ] Material de apresentação (antes/depois: grid vazia vs preenchida, insight com CVE/remediação)
- [ ] Demo + feedback do cliente (registrado direto neste arquivo)
- [ ] Consolidar feedback em backlog v2.1.0, atualizar `CHANGELOG.md`/docs

## Pendências separadas (v1.3.0, carga inicial no ambiente do cliente)

Herdadas de `ampmInsights_V1_Cliente/CHANGELOG.md` ("[Não lançado]") — não fazem parte do escopo
v2.0.0, ficam registradas aqui só para não perder o rastro; tratar quando fizer sentido:

- [ ] Confirmar upload de `DL_TECH_CMDB_V1_AMPM.xlsx` no ambiente de teste (esperado: 109 linhas)
- [ ] Confirmar upload de `DL_TECH_VULNERABILIDADE_V2_AMPM.xlsx` (esperado: 1.724 linhas)
- [ ] Validar visualmente que só aparecem nomes padrão `AM...` na tela "Insigths sobre
      Vulnerabilidades"
- [ ] Decidir sobre `AMPMOCIVWNSP01#DUP` / `AMPMOCIVWNSP02#DUP` (sufixo `#DUP` do ServiceNow)
- [ ] Confirmar fonte de dados para `É_VIRTUAL`, `APPLIANCE`, `EDR` (em branco hoje)
- [ ] Confirmar se `amprotrib` e `aampmocivlfgap02` são ativos AMPM reais

## Gap encontrado ao criar a V2 (não resolvido, só registrado)

`docs/08-glossario-roadmap.html` afirma que "este pacote V1 corresponde ao **Level Zero**" da
jornada Agentic AI do parceiro V8 Solution (`Jornada_AgenticAI.pptx`). Não sei se a V2 deveria
virar "Level 1" dessa jornada — não li o pptx e não vou presumir a numeração. Revisar com o
usuário antes de editar esse parágrafo.