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

- [x] **Concluído e validado em 2026-09-09** — `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). Rodado pelo
      usuário no ambiente `AMPMINSIGHTS` via Database Actions; checkpoint de validação confirmou
      `STATUS = 'OK'` nas duas tabelas (23 e 12 colunas, exatamente o esperado). Nota: a primeira
      tentativa de checkpoint deu `ORA-00903` por um trecho abreviado/ilustrativo em
      `docs/11-v2-evolucao-schema.html` (já corrigido, commit `dd40d0a`) — os `ALTER TABLE` em si
      nunca tiveram problema.
- [x] **Concluído e validado em 2026-09-09** — `sql/04_v2_view_procedure_update.sql`:
      `V_26AI_TECH` com as 81 colunas confirmadas na ordem certa (46 originais + 35 novas,
      `RAW_JSON_TENABLE`/`RAW_JSON_CMDB` sem colidir); `prc_26ai_tech` `VALID`. Pegadinha
      encontrada: rodando statement a statement no Database Actions, o `CREATE OR REPLACE VIEW`
      (bloco grande) foi pulado na primeira passada — o checkpoint de compilação deu `VALID`
      porque a view *antiga* (46 colunas) já era válida antes. Resolvido rodando o bloco
      explicitamente; segunda checagem confirmou as 81 colunas.
- [ ] **Em andamento, roteiro sendo confirmado tela a tela** (ver
      [docs/13-v2-perfis-carga.html](docs/13-v2-perfis-carga.html)) — mapeamento de colunas
      pronto; passo a passo real do App Builder confirmado até "Copy Data Load Definition"
      (método = cópia de `DL_TECH_CMDB_V1`/`DL_TECH_VULNERABILIDADE_V2`, renomeadas pra
      `DL_TECH_CMDB_V2`/`DL_TECH_VULNERABILIDADE_V3` — **não** "upload de amostra", isso foi um
      chute meu já corrigido). Falta confirmar a tela seguinte (adicionar as colunas novas na
      cópia) antes de completar o roteiro. Depois de pronto: exportar a Application 100 de novo
      (captura os perfis com IDs corretos) — o cliente só importa esse export, nunca toca em Data
      Load Definitions. **Achado importante:** essas definições vivem dentro de
      `sql/02_ampminsights_apex_app.sql` via API interna do APEX (`wwv_flow_imp_shared`) — não
      escrever isso à mão fora de um import completo, risco de corromper os Shared Components.
      `RAW_JSON` deliberadamente fora do escopo deste item — depende do item de staging abaixo.
      Os `templates/*.xlsx` servem pra testar a carga depois de pronta, não pra criar o perfil.
- [ ] 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.