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.
• 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 — 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.