AntonioFigueiredo/ampmInsights
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
24a1c8bb6af7a4cdfc2295ed54b0d568d6de2549
ampmInsights/TASKS.md
Antonio Sergio Rodrigues Figueiredo 24a1c8bb6a Baseline v2.0.0-dev: fork de ampmInsights_V1 
- Copia integral de ampmInsights_V1/ (docs/ + sql/), que o usuário confirma
  ser exatamente o que foi usado para construir e implementar
  ampmInsights_V1_Cliente no cliente.
- Traz docs/10-carga-cmdb-vulnerabilidades.html de V1_Cliente (existia lá,
  faltava em V1 — gap de conteúdo, não só de tom).
- Rebrand mecânico 'Documentação V1' -> 'Documentação V2' nas 10 páginas de
  docs + link de navegação para o capítulo 10 adicionado onde faltava.
- ampmInsights_V1/ e ampmInsights_V1_Cliente/ ficam congelados a partir de
  agora (réplica validada, já implementada no cliente) — todo o trabalho de
  v2.0.0 (schema aditivo: ALTER/MERGE, sem DROP) acontece nesta pasta.
- Adiciona TASKS.md e CHANGELOG.md próprios desta geração.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-09 11:21:14 -03:00

4.4 KiB
Raw Blame History

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.

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)

  • Fechar DDL v2.0.0 híbrido — ALTER TABLE ... ADD (colunas Tier-1 tipadas) + RAW_JSON CLOB catch-all em TB_26AI_TECH_V2/TB_26AI_TECH_CMDB, script isolado e aditivo (sem DROP), referenciando ANALISE_DADOS_v1.4.0_gap_schema.md
  • 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.

Reference in New Issue View Git Blame Copy Permalink