Antonio Sergio Rodrigues Figueiredo
df0d775540
- docs/13-v2-perfis-carga.html: mapeamento completo coluna a coluna pra DL_TECH_CMDB_V2 (12 campos) e DL_TECH_VULNERABILIDADE_V3 (23 campos), conferido campo a campo contra um export real (Artefatos/ da V1_Cliente, só linhas AM...) em vez de suposição. - Correções encontradas na conferência: definition.patch_published e definition.vulnerability_published têm prefixo 'definition.' no export real (não estava assim documentado antes); flags booleanos confirmados como texto 'true'/'false' (Tenable) e 'Verdadeiro(a)'/'Falso(a)' (ServiceNow, mesma convenção já usada em SOX/COFRE/TENABLE/SIEM no capítulo 10). - RAW_JSON deliberadamente fora do escopo deste passo — Data Load só carrega colunas mapeadas, não a linha completa; população real de RAW_JSON depende da tabela de staging (próximo item do TASKS.md). - Nav (13 páginas) e pillnav do capítulo 12 atualizados. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
101 lines
6.5 KiB
Markdown
101 lines
6.5 KiB
Markdown
# 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.
|
|
- [ ] **Mapeamento pronto e confirmado contra export real** (ver
|
|
[docs/13-v2-perfis-carga.html](docs/13-v2-perfis-carga.html)) — falta só criar os dois
|
|
perfis de fato no App Builder (não é scriptável, precisa ser feito na UI). `RAW_JSON`
|
|
deliberadamente fora do escopo deste item — depende do item de staging abaixo.
|
|
- [ ] 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.
|