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>

TASKS.md

@@ -36,11 +36,13 @@ teste — a menos que você peça explicitamente o contrário.
       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.**
+- [x] **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.
 - [ ] 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)