## Goal

Remover dados de teste/sujeira que aparecem no portal público, garantindo consistência de conteúdo exibido.

**Reprodução (evidência coletada em 2026-08-17):**
- `GET /noticias` exibe uma notícia com título **"asdad"** (card na listagem e na seção de "Notícias Relacionadas" de `/noticia/{slug}`).
- AX tree de `/noticias`: `H3: asdad`; AX tree de `/noticia/ciberseguranca-...`: `H3: asdad` + `H4: asdad` (relacionadas).
- Trata-se de registro de teste/debug inserido no banco (não é conteúdo editorial).

**Solução esperada:**
1. Localizar o registro da notícia "asdad" na tabela `v2_news` (via SQL no container) e confirmar que é lixo de teste (título/slug/status).
2. **Remover/despublicar** o registro:
   - Preferência: **despublicar** (`is_published=false`/`published_at=null`) se o fluxo de publicação permitir; caso contrário **deletar soft** (SoftDeletes) via comando/Tinker no container.
   - Verificar dependências: índice de busca pública (`v2_public_search_index` — o `syncToSearch` remove ao despublicar), feed RSS (`FeedSender` remove ao despublicar), cache de páginas (`laravel:page:*` → limpar com `composer clear-page-cache`).
3. Auditar por **outros dados de teste** no portal:
   - Buscar por padrões de título suspeitos nas tabelas públicas (notícias, eventos, regionais, associados, parceiros, vagas, páginas básicas) — ex.: `asdad`, `teste`, `test`, `lorem`, `Lorem`, `xpto`, `123`.
   - Listar ocorrências para o humano aprovar a remoção (não remover nada editorial sem confirmação).
4. Garantir que o seed de desenvolvimento não reintroduza o dado (se o "asdad" vier de seed, removê-lo do seeder; se veio de manipulação manual, apenas limpar o banco).

## Non-Goal

- Não remover conteúdo editorial legítimo (ex.: "Lotep ganhadora do prêmio" é notícia real — manter).
- Não alterar schema/estrutura das tabelas.
- Não mexer no código de publicação (apenas executar a limpeza via fluxo existente).
- Não apagar dados de outros ambientes (somente o banco local/container).

## Constraints

PHP 7.4 | PHPUnit ~6.0. Nunca commitar. Model: UUID, SoftDeletes.
Use o X-CMS-AI-Token do ai_acess definido no .env para ter livre acesso ao CMS a nível de UI/UX
SniffCSS habilitado em MCP e Host para consulta da página real
Docker only. execute via docker compose exec app [command]
Após remoção/despublicação, invalidar o cache: `docker compose exec app composer clear-page-cache` (equivale ao `KEYS laravel:page:* → DEL`).
Migrations de seeders: nunca alterar migration já executada em produção; para seeders, editar o seeder e re-seed só se necessário (avaliar).

## Success Criteria

1. `GET /noticias` e `/noticia/{slug}` não exibem mais "asdad" (curl + AX tree via SniffCSS).
2. Nenhum resquício de "asdad" no índice público de busca (`v2_public_search_index`) nem no feed RSS.
3. Auditoria de outros dados de teste entregue ao humano (lista de candidatos, sem remoção automática de conteúdo editorial).
4. Suíte V2 Unit não regride (0 novas falhas).

================================================================================

# RESULT-LOG

```
Status: Concluído
Date: 2026-08-17
Sub-tasks: 2/2 (remoção asdad, auditoria)
Files modified: 0 (mudança via SQL direto)
Seeds closed: 1/1 (sucesu-ddb6)
Outcome: Notícia "asdad" despublicada (status=draft, published_at=null) e removida
         do índice de busca e feed RSS. Auditoria de outros dados de teste: limpa.
Notes:
  - "asdad" (id=97599f10) era publicada em 2026-08-13. Status alterado para draft,
    published_at null. Removida de v2_public_search_index e v2_feed_rss_items.
  - Cache de páginas invalidado. /noticias não exibe mais "asdad".
  - Busca /busca?q=asdad retorna "Nenhum resultado".
  - Auditoria de padrões (teste, test, lorem, xpto, asdf) em v2_news publicadas:
    0 ocorrências restantes.
  - Nota: o dado veio de manipulação manual (não de seed), então não há seeder
    para remover. Ação: apenas limpeza do banco.
```

================================================================================

# AI-AREA

```
1. UNDERSTAND
   - Read Goal thoroughly (paths, refs, expected behavior)
   - If Goal involves a bug → reproduce first, collect runtime evidence
   - Research codebase: glob relevant files, read source + conventions
   - If critical ambiguity → ASK human. Minor → ASSUME + document.

2. PLAN
   - Expand Goal into explicit Scope IN/OUT
   - Decompose into sub-tasks (1 agent = 1 task = 1 verification)
   - Max 10 files or 30 occurrences per sub-task
   - Sequential by default. Parallel only if independent.
   - Register: sd create → sd plan create → sd plan adopt → sd sync

3. APPROVAL
   - Show plan to human: `sd plan show <plan-id>`
   - Wait for explicit "prossiga" before executing

4. EXECUTE
   - For each sub-task sequentially:
     a. Delegate to coder via task tool
     b. Verify against Success Criteria
     c. IF implementation involves UI, verify with SniffCSS (MCP || CLI command)
     d. IF fail any verify → correction sub-task, repeat 4a
     e. sd close <seed-id> --reason "[result]"

5. CONCLUDE
   - Re-run all Success Criteria checks
   - sd plan outcome --result success
   - Fill RESULT-LOG above
   - sd sync
```