Antonio Sergio Rodrigues Figueiredo
d37140b36b
- sql/03_v2_ddl_schema_evolution.sql: 23 colunas novas em TB_26AI_TECH_V2 + 12 em TB_26AI_TECH_CMDB (Tier-1 de ANALISE_DADOS_v1.4.0_gap_schema.md seções 2.2/3.1), + RAW_JSON CLOB catch-all em cada tabela. 100% ALTER ADD, nenhum DROP, checkpoint de validação embutido. - TASKS.md: registra o fluxo de trabalho (usuário roda/valida cada passo, eu documento) e marca este item como pronto/aguardando execução. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
80 lines
5.0 KiB
Markdown
80 lines
5.0 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)
|
|
|
|
- [ ] **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.
|