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)

• 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.
• 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.
• Perfis criados e colunas confirmadas em 2026-09-09 — DL_TECH_CMDB_V2 (27 colunas: 16 originais + 11 novas) e DL_TECH_VULNERABILIDADE_V3 (40 colunas: 18 originais + 22 novas) criados via "As copy of an existing Data Load Definition" + Add Column manual (roteiro completo em docs/13-v2-perfis-carga.html). Investigado e descartado: não existe atalho scriptável pra adicionar colunas (nem wwv_flow_imp_shared — risco de corromper Shared Components — nem APEX_DATA_LOADING, confirmado via all_arguments + doc oficial que só serve pra executar carga, não criar/editar definição). RAW_JSON continua fora do escopo — depende do item de staging abaixo. Falta: (1) testar upload real através dos dois perfis novos (query de validação do capítulo 13 retorna "no data found" até isso acontecer — esperado, não é erro); (2) export completo novo da Application 100, capturando os perfis com IDs corretos — é isso que vira o próximo release pro cliente, que nunca toca em Data Load Definitions.
• 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 — 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.