Remove TASKS.md: tracking da v2.0.0 migrou para ampmInsights_V2/

Esta pasta fica congelada como réplica validada, já implementada no
cliente — nenhuma mudança funcional/estrutural a partir de agora. O board
de sprint da v2.0.0 (nova geração) vive em ampmInsights_V2/TASKS.md.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

TASKS.md

@@ -1,77 +0,0 @@
-# Tasks — v1.4.0 (schema overhaul + AI Insight com CVE/pacote/remediação)
-
-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. Substitui a tentativa anterior de
-Kanban via `TB_26AI_TECH_SPRINT_KANBAN` (tabela no ADB) + região App Builder / Claude Artifact.
-
-Contexto/mapeamento de colunas: `../ANALISE_DADOS_v1.4.0_gap_schema.md` (fora deste repo, doc
-interno de planejamento, não client-facing).
-
-Fluxo de trabalho: **validar tudo no ambiente de teste do Antonio primeiro → só depois replicar
-no ambiente do cliente**, com a documentação das duas cópias (`ampmInsights_V1/` interna e
-`ampmInsights_V1_Cliente/`) atualizada ao final de cada tarefa que gerar SQL/doc novo.
-
-## Concluído (sprint anterior, 13/08–14/08)
-
-- [x] `TB_26AI_TECH_SPRINT_KANBAN` criada e populada no ADB (2026-08-12) — **dropada em
-      2026-09-09**, tracking migrou para este arquivo.
-- [x] Tentativa de deploy scriptado de página via SQLcl (`f100_page_11.sql`) — **abandonada**:
-      export de página sozinha depende de componentes (menu/breadcrumb) que só existem no export
-      completo da aplicação. Nenhum dano; transação reverteu sozinha. Não reabrir esse caminho
-      para a Application 100 — a unidade de deploy scriptável confiável continua sendo o export
-      completo (`sql/02_ampminsights_apex_app.sql`).
-
-## Fase 1 — Dados/ETL
-
-- [ ] **09/09 (Qua)** — Fechar DDL v1.4.0 híbrido (colunas Tier-1 tipadas + `RAW_JSON` CLOB) em
-      `TB_26AI_TECH_V2`/`TB_26AI_TECH_CMDB`, script isolado, sem tocar no ambiente atual
-- [ ] **10/09 (Qui)** — 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`)
-- [ ] **11/09 (Sex)** — Pipeline de staging: bucket → `TB_26AI_TECH_V2_STG` via
-      `DBMS_CLOUD.COPY_DATA`
-- [ ] **14/09 (Seg)** — `MERGE` com histórico (`LOAD_BATCH_ID`, `TB_26AI_TECH_V2_HIST`), honrando
-      o campo `state` do Tenable (NEW/ACTIVE/FIXED/RESURFACED)
-- [ ] **15/09 (Ter)** — Teste ponta a ponta com arquivo real mais recente; QA dos campos novos
-      (CVE, solução, pacotes, SO/Classe/Criticidade agora preenchidos)
-
-## Fase 2 — Validação de Inteligência
-
-- [ ] **16/09 (Qua)** — Validar que o AI Insight cita CVE/pacote/remediação de fato (amostra de
-      5-10 ativos)
-- [ ] **17/09 (Qui)** — Rodar geração de insight em lote no ambiente de teste completo; revisão
-      de qualidade
-- [ ] **18/09 (Sex)** — Relatórios visuais (top CVEs/CISA KEV, ativos mais expostos, tendência
-      semanal usando `TB_26AI_TECH_V2_HIST`)
-
-## Fase 3 — Release controlada + Cliente
-
-- [ ] **21/09 (Seg)** — Congelar escopo v1.4.0, gerar zip, validar em ambiente limpo (fluxo já
-      usado nas releases anteriores — ver processo de release do projeto)
-- [ ] **22/09 (Ter)** — Carga real do dado mais recente do cliente no ambiente de teste final;
-      validação visual completa
-- [ ] **23/09 (Qua)** — Material de apresentação (antes/depois: grid vazia vs preenchida, insight
-      com CVE/remediação)
-- [ ] **24/09 (Qui)** — Demo + feedback do cliente (registrado direto neste arquivo)
-- [ ] **25/09 (Sex)** — Consolidar feedback em backlog v1.5.0, atualizar `CHANGELOG.md`/docs
-      (nas duas cópias, `V1` e `V1_Cliente`)
-
-## Pendências separadas (v1.3.0, carga inicial no ambiente do cliente)
-
-Ainda abertas no `CHANGELOG.md` ("[Não lançado]"), não fazem parte do escopo v1.4.0 acima —
-tratar em paralelo quando o ambiente do cliente estiver pronto para a primeira carga real:
-
-- [ ] 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
-- [ ] Repetir a carga no ambiente real do cliente após validação no teste
-
-## Referência disponível, ainda não consultada
-
-`APEX/26AIcomAIDP/20251202 Select AI New Capabilities and Roadmap.pdf` e outros PDFs técnicos de
-Select AI/Vector Database — só abrir se uma decisão específica de RAG/Select AI precisar de
-validação contra o roadmap oficial da Oracle.