diff --git a/TASKS.md b/TASKS.md
index df76c1f..afeda17 100644
--- a/TASKS.md
+++ b/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)
diff --git a/docs/12-v2-view-procedure.html b/docs/12-v2-view-procedure.html
index baa909c..f2ea438 100644
--- a/docs/12-v2-view-procedure.html
+++ b/docs/12-v2-view-procedure.html
@@ -41,9 +41,13 @@
     <h1>Expondo os dados novos ao AI Insight</h1>
     <p class="lede">Ter as colunas novas na tabela não basta — <code>V_26AI_TECH</code> e o <code>json_object</code> de <code>prc_26ai_tech</code> precisam repassar esses campos até o LLM. Este é o passo que faz isso.</p>
 
-<div class="callout warning">
-  <div class="callout-title">Status: em validação, ainda não roda em produção</div>
-  <p>Documenta um passo já implementado (<code>sql/04_v2_view_procedure_update.sql</code>), mas ainda não confirmado em nenhum ambiente. Depende do <a href="11-v2-evolucao-schema.html">capítulo 11</a> já ter sido aplicado e validado no mesmo ambiente.</p>
+<div class="callout info">
+  <div class="callout-title">Status: validado em 2026-09-09</div>
+  <p>Compilação confirmada (<code>V_26AI_TECH</code>/<code>PRC_26AI_TECH</code> <code>VALID</code>)
+  e as 81 colunas da view checadas uma a uma. Dica de quem já passou por isso: se você rodar o
+  script statement a statement (não como "Run Script"), não pule o bloco do
+  <code>CREATE OR REPLACE VIEW</code> — ele é grande e fica fácil ir direto pro
+  <code>CREATE OR REPLACE PROCEDURE</code> sem notar.</p>
 </div>
 
 <h2>1. Por que este passo é separado do anterior</h2>