Commit Graph

10 Commits

Author SHA1 Message Date
26ebdd15b2 docs/13: roteiro completo confirmado (Add Column) + investigação APEX_DATA_LOADING
Consolida tudo confirmado tela a tela nesta sessão:
- Formulário 'Data Profile Column' completo (Column Type, Name, Data
  Type, Length condicional, Selector Type/Selector, Value
  Transformation).
- Tabela final das 11 colunas do CMDB com Data Type/Length exatos, e
  das 22 de vulnerabilidades (incluindo a máscara de timestamp
  confirmada contra FIRST_OBSERVED/LAST_SEEN/RESURFACED_DATE já
  existentes).
- Correção: ATTESTED_FLAG (e os 3 flags de vulnerabilidade) não usam
  Value Transformation - conversão true/false -> 1/0 é manual no
  Excel, mesma regra já documentada no capítulo 10 pra COFRE/SOX/etc.
- Nova nota: investigação do pacote público APEX_DATA_LOADING
  (owner real APEX_240200.WWV_FLOW_DATA_LOADING_API) - só tem
  GET_FILE_PROFILE/LOAD_DATA (executar carga), não serve pra
  criar/editar colunas de um Data Profile. Não reabrir essa via.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-09 20:19:31 -03:00
3604f2f9e0 docs/13: confirma passos 7-10 (cópia, pegadinha do To Name, rename/delete)
Confirmado tela a tela pelo usuário: o campo 'To Name' na tela 'As
Copy' é ignorado (as 3 cópias nascem com nome padrão 'Copy of X',
mesmo a que estava marcada No). Documenta a correção: identificar cada
cópia pelo Target Name na visão em tabela, apagar a indesejada
(Copy of DL_TECH_VULNERABILIDADES, aponta pra TB_26AI_TECH legada,
não TB_26AI_TECH_V2), renomear as outras duas via campo Name/Static ID
+ Apply Changes. Lista final de 5 definições confirmada.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-09 19:32:37 -03:00
8ef36eb1cc Corrige docs/13: roteiro real (Copy), não upload de amostra (inventado)
Confirmado contra prints reais do App Builder: o wizard de criação só
oferece 'From scratch' ou 'As copy of an existing Data Load
Definition' — não existe tela de upload de amostra para autodetectar
colunas, como eu tinha documentado antes sem verificar. Corrige o
roteiro pra seguir exatamente as telas reais (Method -> Application ->
As Copy, renomeando DL_TECH_CMDB_V1 -> DL_TECH_CMDB_V2 e
DL_TECH_VULNERABILIDADE_V2 -> DL_TECH_VULNERABILIDADE_V3 na mesma
tela). Marca explicitamente onde o roteiro ainda não está confirmado
(tela pós-'Copy Data Load Definition') em vez de continuar
adivinhando. Reposiciona os templates/*.xlsx: servem para testar a
carga depois de pronta, não para criar o perfil.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-09 19:23:17 -03:00
0e7d75db27 Passo 3 v2.0.0: templates de amostra + caminho de distribuição sem App Builder pro cliente
- Achado: DL_TECH_CMDB_V1/DL_TECH_VULNERABILIDADE_V2 vivem dentro de
  sql/02_ampminsights_apex_app.sql via wwv_flow_imp_shared (API interna
  de export/import do APEX) — não escrever isso à mão fora de um
  import completo.
- templates/sample_DL_TECH_CMDB_V2.xlsx (27 col.) e
  templates/sample_DL_TECH_VULNERABILIDADE_V3.xlsx (40 col.): arquivos
  de amostra só-cabeçalho pra criar os perfis via upload no wizard do
  APEX, em vez de preencher campo a campo.
- docs/13 reescrito: seção 5 usa o fluxo de upload de amostra; nova
  seção 7 explica que só o desenvolvedor toca em App Builder uma vez,
  e o cliente recebe um export completo novo (mesmo fluxo de release
  já usado sempre) — nunca precisa saber o que é Data Load Definition.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-09 19:12:43 -03:00
df0d775540 Passo 3 v2.0.0: mapeamento de perfis de carga confirmado contra export real
- 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>
2026-09-09 17:30:42 -03:00
530c07cd94 Passo 2 v2.0.0 validado: V_26AI_TECH (81 colunas) e PRC_26AI_TECH VALID
Checkpoint completo confirmado pelo usuário: as 81 colunas da view na
ordem certa, ambos objetos VALID, teste manual retornou linhas (NULL
nos campos novos, esperado sem carga ainda). Registra a pegadinha do
CREATE OR REPLACE VIEW sendo pulado ao rodar statement a statement.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-09 17:12:49 -03:00
f8595435e0 Passo 1 v2.0.0 validado: TB_26AI_TECH_V2 (23) e TB_26AI_TECH_CMDB (12) OK
Checkpoint rodado pelo usuário no ambiente AMPMINSIGHTS confirmou
STATUS = 'OK' nas duas tabelas. TASKS.md marca o item como concluído;
docs/11 troca o aviso de 'em validação' por confirmação.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-09 16:32:18 -03:00
dd40d0a42a Corrige docs/11: query de validação abreviada causava ORA-00903
O capítulo 11 mostrava a query de checkpoint com placeholders '/* ... */'
só ilustrativos, mas com botão 'Copiar' ao lado — usuário copiou e
rodou direto, e 'FROM (/* ver script completo */)' virou subquery
vazia (ORA-00903 invalid table name). Substitui pela query real e
completa, idêntica à de sql/03_v2_ddl_schema_evolution.sql. Os ALTER
TABLE em si rodaram OK, não foi um problema do DDL.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-09 16:30:36 -03:00
561f26608e Docs v2.0.0: capítulos 11 e 12 (evolução de schema + view/procedure)
- docs/11-v2-evolucao-schema.html: documenta o Passo 1
  (sql/03_v2_ddl_schema_evolution.sql) — o quê, por quê, script resumido,
  como rodar, validação, rollback. Callout deixa explícito que ainda está
  em validação, não é procedimento definitivo.
- docs/12-v2-view-procedure.html: documenta o Passo 2
  (sql/04_v2_view_procedure_update.sql), mesmo formato, com dependência
  explícita do capítulo 11.
- Nav lateral (sidebar) atualizada nas 12 páginas do doc set para incluir
  os capítulos novos; pillnav do capítulo 10 ganhou link 'next' para o 11.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-09 15:01:48 -03:00
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