ampmInsights/TASKS.md

# 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).
- [ ] **Pronto, aguardando você rodar e validar** — `sql/04_v2_view_procedure_update.sql`:
      `V_26AI_TECH` ganha as 35 colunas novas (aliases `RAW_JSON_TENABLE`/`RAW_JSON_CMDB` pra não
      colidir); `prc_26ai_tech` passa a incluir esses campos no `json_object` enviado ao LLM (só o
      ramo `VUL` foi tocado — ramo `SYS`, prompt, vetorização, log e exceção ficam idênticos ao
      original). **Depende do Passo 1 já ter rodado no mesmo ambiente.**
- [ ] 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

## Backlog futuro — v3.0.0 Agêntico (não iniciado)

Ver [ROADMAP_AGENTICO.md](ROADMAP_AGENTICO.md) — análise de 2026-09-09 a partir de um case
bancário de referência (`DBMS_CLOUD_AI_AGENT`, Property Graph, Knowledge Graph chain) e de um app
pronto da Oracle (Ask Oracle Select AI Chatbot). **Depende do v2.0.0 estar em produção primeiro**
(os agentes/tools consultariam os campos Tier-1 do Passo 1). Um item da análise (separar cálculo
determinístico de narrativa da IA, tipo `fn_analise_carteira_json`) não depende de agentes e pode
entrar como v2.1.0 depois da carga real dos dados.

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