## Goal
O serviço de ContentRichEditor (V2/Services/ContentRichEditor) está apresentando inconsistencias que precisam se revistas:
1. Ao tentar inserir um hyperlink, no editor funciona bem, no portal final não é registrado esse link como , exibindo apenas o URL bruto
1.1. Idealmente dee transformar em um real, com otimizações de hyperlink like
```html
texto âncora descritivo
```
1.2. Ao pressioanr em "link para conteúdo do portal", surge uma tela escura sobre o modal e sobre a tela, impossibilitando a interação, onde deveria apenas aparecer centralizado verticalmente à view atual do usuário o modal para inerir o link dinâmico, vinculado ao Search Service (V2/Services/Search)
1.2.1. INVESTIGUE utilizando o snifcss-check, e gere dados before e after a correção, com --persiste e --screenshot
1.2.2. Lembre-se que este projeto usa muita profundidade, então, use --depth=12++
1.2.3. O link deve possuir um popover elegante ao lado do elemento para garantir que o usuário seja transparente sobre o destino da URL, com limite de caracteres razoável para não estourar a tela
1.2.4. Deve ser possível definir se o link terá target blank ou target self (acessível, usar nomes amigáveis)
1.3. Reorganize a visualização dos botões e dos modais que surgem como em "inferir link", todos os modais devem respeitar:
1.3.0. Idealmente, todos os botões deveriam estar centralizados ao componente, para ter uma experiênica elegante de writer moderno
1.3.1. Respeitar a cor do CMS e padrão de botões
1.3.2. Respeitar a centralização vertical à view atual do usuárioo
1.3.3. Ser legível e acessível com captura correta do foco do usuário
1.4. O submenu "Inserir" precisa de refatoração em prol de UX:
1.4.1. Os elementos "Inserir imagem" e "linha horizontal" devem também ter na 2ª linha do editor, como acesso rápido
1.4.2. Todos os blocos especiais devem ser removidos (mantenha o código, apenas comente/desative com comentário de rascunho para futuro)
1.4.3. A área de tabela deve ter apenas a opção de "inserir tabela" dentro do subgrupo "estrutura"
1.4.3.1. Os elementos de adicionar coluna e linha à tabela deve ser um menu interativo sobre a tabela
1.4.4. O elemento "Dividir em colunas" precisa de especial atenção, atualmente é impossível digitar na 2ª coluna, além de visualmente no portal isso ser invisível
1.5. O elemento "Inserir imagem" deverá ter atenção especial para que, no portal público, use uma estrutura similar ao (V2/Services/Media/Views/components/picture.blade.php), para servir no portal, SEM INTERVENÇÕES VISUAIS, um elemento Picture altamente otimizado que garnatidamente foi digerido pelo service de Media para múltiplas views otimizadas por viewport
Todas as implementações desse editor devem garantidamente ter as mesmas atualizações, evitando personalizações destrutivas
Módulos de notícia, agenda, trabelhe conosco, conexões, e institucional, todos devem fucionar adequadamente
Todos os ajustes devem ser validados no portal com testes automaizados de não-regreessão, trazendo uma experiência fluida e elegante para o leitor final.
## Success Criteria
1. Logs estruturados em pontos chave
2. Testes rodando sem erros
3. SniffCSS com --depth alto (10+) confirmando UI coerente com o esperado
4. Testes automatizados para garantia de não-regressão
5. Suíte V2 Unit não regride (0 novas falhas)
6. Todos os elementos devem ser espelhados no portal público de maneira otimizada e elegante, garantidamente representando correatmetne o mesmo elemento que foi criado no CMS
6.1. Ex: um link deve surgir como um link real
6.2. Ex: uma divisão em 2 colunas deve ser um subcontainer real com 2 áreas com grid aplicado
6.3. Uma linha horizontal deve ser uma linha semântica e visual
6.4. A tabela deve ser interativa, semântica, com headers e body no portal, e elementos interativos no CMS
6.5. Tudo deve ser corretamente testado também com Playwrith em teste e2e com história de usuário demonstrando a criação de um conteúdo rico explorando todos os elementos e botões
6.6 Teste em especial no módulo "Notícias > criar notícia", é o local de maior foco dessa ferramenta
## Non-Goal
Nenhum botão deve desaparecer, perder ícone ou deixar de funcionar
Nenhum botão deve sair da tela em viewport mais curta, como de mobile (ver via sniffcss)
A hierarquia semântica do CMS NÃO pode ser distinta da hierarquia semântica no conteúdo do portal final
## 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]
================================================================================
# RESULT-LOG
```
Status: PLANNED
Date: 2026-08-18
Plan ID: pl-5061
Epic Seed: sucesu-9a45
Sub-tasks: 0/7
Files modified: 0
Seeds closed: 0/7
Outcome: Em planejamento — aguardando aprovação "prossiga"
Notes:
- Step 1 (sucesu-5302): Link mark — trocar insertContent→setLink, enriquecer LinkRenderer
- Step 2 (sucesu-c854): Search modal — remover overlay, popover preview, toggle target
- Step 3 (sucesu-8183): Toolbar — 2ª linha imagem/HR, comentar blocos, menu tabela flutuante
- Step 4 (sucesu-1922): Colunas — fix 2ª coluna editável + grid portal
- Step 5 (sucesu-0658): Imagem — converter para WebP via Media service
- Step 6 (sucesu-5a97): Testes unit+feature+e2e Playwright
- Step 7 (sucesu-2220): SniffCSS validation depth 10+
- Blockers: step 6 bloqueado por steps 1-5; step 7 bloqueado por step 6
```
================================================================================
# 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 `
- 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 witch SniffCSS (MCP || CLI command)
d. IF fail any verify → correction sub-task, repeat 4a
e. sd close --reason "[result]"
5. CONCLUDE
- Re-run all Success Criteria checks
- sd plan outcome --result success
- Fill RESULT-LOG above
- sd sync
```