---
fonte: 01-canonicos/seed-ds-roadmap.md
versao_da_fonte: v2.48
secao: s10
titulo: "F9 — Publicação e camada de IA/GEO ✅ **FECHADA em 2026-09-09 — 10 de 10 bricks**, aberta em 2026-09-05 com o desenho decidido por ele no gate (MANIFESTO §153–§154). Os seis bricks planejados (F9.1 camada de IA · F9.2 registry · F9.3 vitrine · F9.4 pacote GEO · F9.5 skill única · F9.6 mapa de propagação final) mais quatro que nasceram de pedido dele durante a fase (F9.7 roadmap público e entrada de pedidos · F9.8 bases de boas práticas · F9.9 menu lateral · F9.10 conferidor de peça pronta). **O marcador desta linha ficou em 🔵 até 2026-09-09**, com os dez bricks já fechados — a mesma classe de defeito que a v2.42 corrigiu em duas linhas de brick no mesmo dia: marcador de estado é a primeira coisa que alguém lê e a última que alguém lembra de mexer."
sequencia: 11 de 15
bytes_do_corpo: 26356
md5_do_corpo: 0fc9aad951b4414a0b9074ba7bacfa76
gerado_por: 06-validacao/geradores/gen-camada-ia.py
nota: fatia GERADA — o corpo abaixo é byte a byte o trecho do canônico; edite o canônico, nunca esta fatia. Canônico inteiro em https://ds.seed.eng.br/01-canonicos/seed-ds-roadmap.md
---
## F9 — Publicação e camada de IA/GEO ✅ **FECHADA em 2026-09-09 — 10 de 10 bricks**, aberta em 2026-09-05 com o desenho decidido por ele no gate (MANIFESTO §153–§154). Os seis bricks planejados (F9.1 camada de IA · F9.2 registry · F9.3 vitrine · F9.4 pacote GEO · F9.5 skill única · F9.6 mapa de propagação final) mais quatro que nasceram de pedido dele durante a fase (F9.7 roadmap público e entrada de pedidos · F9.8 bases de boas práticas · F9.9 menu lateral · F9.10 conferidor de peça pronta). **O marcador desta linha ficou em 🔵 até 2026-09-09**, com os dez bricks já fechados — a mesma classe de defeito que a v2.42 corrigiu em duas linhas de brick no mesmo dia: marcador de estado é a primeira coisa que alguém lê e a última que alguém lembra de mexer.

> Pré-requisitos já existentes: `llms.txt` + `indice.json` gerados a cada fechamento de brick; 30 specs de peça consumíveis por máquina no §12 do `marca-seed.md`; quatro listas de fotos necessárias como especificação de compra.

> *(Era a "F8" até a renumeração de 2026-08-15 — renumerada aqui na v2.1 por consequência.
> Nada do escopo muda. O repositório já antecipa uma parte: `llms.txt` + `indice.json` na raiz,
> gerados pelo `gen-indice.py` desde 2026-08-22, pela regra canônica IA-primeiro.)*

**Desenho decidido em 2026-09-05 (vereditos verbatim no MANIFESTO §154) — seis bricks, nesta ordem, cada um com gate:**

| brick | entrega | decisões dele que governam | custo declarado | estado |
|---|---|---|---|---|
| **F9.1** | **Camada de IA**: `gen-camada-ia.py` fatia os canônicos em um `.md` por § com cabeçalho de procedência; `llms.txt` público com endereços absolutos; `tokens.md` para agentes; `robots.txt` + `sitemap.xml`; contêiner estático na VM atrás do Traefik | superfície = VM ao lado do site (Q1) · domínio `ds.seed.eng.br` (Q2) · robôs de IA todos liberados, treino incluso (Q3) · ordem: IA e registry antes da vitrine (Q5) | 1–2 sessões · 1 clique dele (registro DNS na Cloudflare) | ✅ **FECHADA 2026-09-05** — `https://ds.seed.eng.br` no ar; guarda de produção **9 PASS · 0 FAIL · 0 NÃO MEDI** (283/283 MD5 por HTTPS); MANIFESTO §155–§156 |
| **F9.2** | **Registry shadcn próprio**: tema (cssVars light/dark dos semânticos `--seed-*` + apelidos shadcn, GI1–GI5 do §44) e estilo, publicados na mesma superfície; gate G7 na `paridade-tokens.py`; o ERP instala com um comando | R-Q1 (§159): quem aplica no ERP é a sessão do ERP, por PR; sem veto ao aplicado pelo canon | 2 sessões (feito em 1) | ✅ **FECHADA 2026-09-05** — `https://ds.seed.eng.br/r/` com `@seed/tokens`, `@seed/theme` e `@seed/fontes`; guarda RG 7 PASS em produção; documento de consumo em `/r/LEIA-ME.md` (MANIFESTO §158–§160) |
| **F9.3** | **Vitrine**: início · tokens · componentes (bancadas embutidas) · telas · peças · **Atualizações** (gerada dos changelogs) · **Conteúdo e voz** · **checklist de acessibilidade** | casca = **gerador da casa** (Q4, contra a recomendação Starlight — decisão dele, custo aceito) | 4–5 sessões de casca + 3 de conteúdo; exige biblioteca de Markdown (medido na abertura: 5,5–7 sessões; `markdown-it-py 3.0.0` provada nas 259 fatias) | ✅ **FECHADA 2026-09-06** — veredito dele, verbatim: *"V-F1 (a vitrine): A — aprovada; a F9.3 fecha · Ajustes por página: nenhum · Veto ao aplicado: nenhum"* (MANIFESTO §166). No ar em `https://ds.seed.eng.br` (commit 2bb3898): 325 páginas geradas do canon, bancadas embutidas, paleta em rampas, Atualizações + Atom, busca; guardas de produção VT 12 PASS · CI 9 PASS · RG 7 PASS · GE 5 PASS. A rodada do gate visual (§165) virou canon (marca v5.36, regra da emenda) e guarda transversal (`guarda-grafismo.py`); VT-P4 (publicação incremental) fechada |
| **F9.4** | **Pacote GEO do site institucional**: §47.6 + arquivos prontos (robots na política A, JSON-LD `Organization` + 3 `LocalBusiness` por `subOrganization`, `Service`, `FAQPage` só com FAQ visível, `llms.txt` do site, IndexNow) | o DS entrega; **o projeto do site aplica na etapa 2** (Q6) | 1 sessão | ✅ **FECHADA em 2026-09-09 — o DS entregou o `§47.6` (MK24 a MK28), que é o que faltava; aplicar é do projeto do site.** A remedição confirmou a previsão: o pacote ENCOLHEU, porque o site novo já aplicou boa parte sozinho — `robots.txt` com `Sitemap:`, `llms.txt` de 5 KB, sitemap com 22 URLs, `Organization` em 15 páginas com 3 `subOrganization` e `areaServed` MG/ES/BA, e `Service` em 11 páginas de serviço. **Faltas medidas, entregues ao projeto do site como pendências:** 7 páginas sem JSON-LD nenhum, nenhum `BreadcrumbList`, nenhum robô de IA nomeado no robots e o IndexNow não implantado. ⚠ **E a medição achou o que ninguém tinha olhado: o domínio principal `seed.eng.br` ainda serve o SITE ANTIGO** — sem JSON-LD, sitemap com zero URLs e `llms.txt` devolvendo HTML. Todo o trabalho de camada de máquina do site novo está invisível para o mundo enquanto o domínio não virar; a virada é decisão dele. |
| **F9.5** | **Skills**: substituição das sete `seed-ds-*` (2026-05-13) por **um único pacote** com referências geradas do canon e um só conjunto de assets | Q7: *"(nenhuma) — um único pacote de assets em vez de sete cópias"* — leitura a confirmar no gate da F9.1 (§154) | 1 sessão + 0,25 por modo | ✅ **FECHADA 2026-09-06** — veredito dele, verbatim: *"V-F1 (fechamento): A — aprovada; a F9.5 fecha e as sete podem ser apagadas agora · V-F2 (correções de canon): A — aplicar as quatro na rodada seguinte, sem folha própria; ficam expostas a veto no relatório · Veto ao aplicado: nenhum"* (MANIFESTO §170). Skill `seed-ds` no ar (`10-publicacao/skill/`), instalada, provada em uso 4 de 4; `seed-praticas.md` v0.1 (12º canônico); as sete skills de maio APAGADAS por nome (§170.2), preservado o que só existia nelas em `09-pesquisa/skills-v1-2026-05/`. Fila LC aberta (LC-01…LC-09) + SK-P1 + PR-P1 |
| **F9.6** | **Mapa de propagação final**: supersede das 30 seções do `seed-design-system.html` v1 → §§ do v2; `legado/` aposentado por tabela de remoção; LEIA-ME do v1 atualizado | — | 1 sessão | ✅ **FECHADA em 2026-09-09** — aberta no mesmo dia por ordem dele (*"pode fechar a F9.10 e abrir a F9.6"*). Reconhecimento MEDIDO e registrado no MANIFESTO §197.2, com o mapa em `08-historico/ds-v1-para-consulta/MAPA-DAS-SECOES-V1-PARA-V2.md`: são **29 seções** com identificador (não 30 — a trigésima é o herói de abertura), **22 absorvidas e 7 revogadas**, com **33 de 33 destinos conferidos por existência**. As duas cópias do HTML não são duplicatas (a de `05-html-de-referencia/legado/` tem as migrações de cor do v2; a de `08-historico/` é o original de 2026-07-17, evidência). **Nada de ativo morre:** o v1 tem 24 ícones e o v2 tem 31, com 23 nomes preservados e redesenhados na linguagem de linha, `add` virando `circle-plus` e oito novos do domínio elétrico. Não está publicado (404 medido em produção). Só o `paridade-previews.py` o mede de verdade. **Executada:** a tabela de remoção foi ao gate e ele aprovou (*"pode remover"*); o `seed-design-system.html` e um `.pyc` rastreado saíram, o `marca-seed.md` foi à **v5.43** porque duas linhas dele mandavam "copiar de lá", e a isenção sem objeto do `paridade-previews.py` foi zerada com o motivo escrito. O **LEIA-ME do v1** — último item do brick — foi atualizado: mandava procurar os canônicos do v2 numa pasta do Drive **deletada em 2026-08-26**, descrevia o HTML removido como "em serviço", e abria uma "divergência conhecida" sobre um arquivo que existe desde a fundação. ⚠ E ao conferir as pendências que ele citava: a **`MR-P3`** é de outro assunto e já estava fechada, e a **`GR-P1`** não existe em fila nenhuma — código de pendência citado em prosa, sem conferir a fila, aponta para outra coisa. |
| **F9.7** | **Roadmap público e entrada de pedidos de cobertura** (decisão dele no chat, 2026-09-06, MANIFESTO §169.5): página pública na vitrine com a fila LC (código, título, estado — nunca os textos enviados) e um FORMULÁRIO onde qualquer pessoa cola o pedido que a skill gerou; a skill passa a dizer o link e a embutir um código de referência (versão da skill + data) que filtra o que veio dela do que é spam; no Claude Code a skill preenche e envia, mostrando o texto antes e com a pessoa autorizando cada envio. Receptor: tabela só de inserção no Supabase do site (sem leitura pública, limite por origem, sem CAPTCHA — bloquearia o Claude Code); leitor da sessão do DS transforma o recebido em linhas LC e traz o lote ao gate | perguntas do gate de abertura: campos (e-mail de retorno opcional só com consentimento e prazo — LGPD) · política de spam (o código filtra, não protege) · publicar a fila é publicar prioridade · receptor (Supabase do site × serviço próprio na VM) | ≈ 1,1 sessão medida no Reconhecimento (página 0,3 · receptor 0,4 · skill 0,2 · leitor 0,2) — o roadmap previa 2; a peça do site (RPC `lead_registrar`, tetos SEC-101) derrubou o custo | ✅ **FECHADA em 2026-09-07 — veredito dele no MANIFESTO §180, verbatim: "V-F1 (fechamento): A — aprovada; a F9.7 fecha e a próxima abre pelo Reconhecimento"; veto: nenhum.** Vereditos de abertura §178 (A·A·A·A), construção e provas §179. — receptor B5-01 no Supabase do site (pgTAP 26/26, CI verde, MD5 igual no vivo), `/pedidos/` no ar, skill com `ref:` e `enviar-pedido.py`, leitor `triar-pedidos.py`; três provas reais (PC-2026-0001/0002/0003, triadas como cobaias). Acesso: além da `/skill/`, do início e do roadmap, a `/pedidos/` entrou no RODAPÉ de todas as páginas (pedido dele no fechamento, §180.2) — continua fora do menu superior |
| **F9.8** | **Atualização e ampliação das bases de boas práticas** (pedido dele, 2026-09-06, MANIFESTO §174: *"crie um item no roadmap para podermos pesquisar sobre cada um deles, para atualizá-los (…) e também pesquisar profundamente no mercado se precisa ser criado algum outro tipo de base de conhecimento dessa"*): (1) para CADA uma das 14 seções do `seed-praticas.md` v0.1, pesquisa datada do estado atual (ex.: formatos e áreas seguras do Instagram, LinkedIn, PDF de carrossel; limites de caracteres; práticas de deck e proposta em 2026), comparação com o texto de maio e PROPOSTA de diferença com fontes — vai ao gate; o aprovado entra como versão nova da seção, auditada; (2) levantamento de mercado das bases que FALTAM para os materiais que a SEED produz (candidatas a medir: vídeo curto/Reels, e-mail marketing, anúncios Meta/Google, artigos LinkedIn, apresentação técnica/laudo, sinalização/impresso de campo, acessibilidade em social) — cada uma com custo e frequência de uso; (3) a regra da skill "base primeiro, internet depois" fica provada por teste de uso (pedido de carrossel → cita §3–§5 antes de qualquer busca). Absorve a PR-P1 (o ciclo agendado de revisão proposta) | perguntas do gate: prioridade das 14 · quais bases novas entram · periodicidade do ciclo | ≈ 3 sessões (14 seções × 0,15 · levantamento 0,5 · ciclo/guarda de envelhecimento 0,5) | ✅ **FECHADA em 2026-09-08 — vereditos dele no MANIFESTO §186: V-B1 = A (ordem por uso: social primeiro) · V-B2 = as OITO bases novas, nenhuma cortada · V-B3 = A (ciclo de 6 meses) · veto: nenhum.** E a ordem que mudou o alvo da etapa, verbatim: *"o objetivo aqui é treinar a forma de produzir cada tipo de conteudo, um post do instagram, um reels, um post do tiktoc, um post no linkedin, é entender as regras de postagem e principalmente o que os melhores do mercado (melhores = possuem resultado) estão fazendo para podermos aprender e replicar."* Daí a régua das quatro etiquetas (`[plataforma]` com endereço e data · `[estudo]` só com método, amostra e período · `[observado]` · `[SEED]`). **Custo recalculado: ≈ 7,2 sessões** (3,1 nas 14 auditorias, 3,6 nas 8 bases novas, 0,5 no ciclo) contra as ≈ 3 estimadas antes da ordem. ✅ **FECHADA em 2026-09-08 — as 14 seções importadas auditadas (ondas 1 a 4) E as 8 bases novas do V-B2 escritas (onda 5, MANIFESTO §192): `seed-praticas.md` v1.2, 22 seções, guarda PB com cobertura 22 de 22, primeiro vencimento em 2027-03-08.** As oito novas são §16 documento técnico de engenharia · §17 fotografia de obra · §18 acessibilidade fora da tela · §19 vídeo curto e Reels · §20 e-mail de conteúdo · §21 anúncio pago · §22 artigo e conteúdo longo · §23 sinalização e impresso de campo. Nasce a quinta etiqueta, `[norma]` (lei, resolução, NR e NBR, com edição, órgão e data de leitura), porque as bases novas são governadas por norma e não por plataforma. Dez pendências na fila: `PB-P1` a `PB-P10` |
| **F9.9** | **Menu lateral esquerdo da vitrine com os subtópicos** (pedido dele no chat, 2026-09-07, verbatim: *"adicionar um menu esquerdo no site com os subtopicos, ao invés de ficar no meio, entra como submenu do lado esquedo. estude como fazer para ficar perfeito."*): hoje só as páginas de canon têm sumário lateral (`.lateral`, §28); nas demais páginas (tokens, componentes, telas, peças, skill, pedidos, atualizações) os subtópicos ficam no corpo. Abre pelo Reconhecimento: (1) medir o que cada página tem de subtópicos e onde; (2) ESTUDO de mercado, com fonte e data, de navegação lateral em sites de documentação e design systems (hierarquia, item atual, colapso por seção, rolagem própria, gaveta no celular, acessibilidade WAI-ARIA da navegação e do `aria-current`); (3) desenho com o canon (§28 lista, §36 trilha, §46 shell, CP de composição) e VARIANTES RENDERIZADAS lado a lado no gate (fixo × colapsável × só no desktop com gaveta no celular), medidas a 390/768/1024/1440 px; (4) gerador + guarda VT do item atual e do `aria-current` | perguntas do gate de abertura: qual variante · o que entra no menu (só H2 ou H2+H3) · comportamento no celular | ≈ 1,5 sessão (reconhecimento e estudo 0,5 · variantes e gate 0,5 · implementação e guarda 0,5) | ✅ **FECHADA em 2026-09-07** — aberta pelo Reconhecimento (§181: censo, estudo de mercado de 10 sites, três variantes renderizadas), vereditos dele no §182 (V-A1 = V2 · V-A2 = A · veto nenhum) e construída no §183: a coluna esquerda passa de 288 para **343 das 347 páginas**, com trilho "nesta página" à direita a partir de 1200 px e gaveta fechada no celular; todo H2 do corpo ganha âncora. Guarda nova **VT-14** (343 páginas, 0 defeitos) e dois defeitos achados por régua: o denominador da VT-5 e os 12 índices de canônico sem item atual |
| **F9.10** | **Conferidor de PEÇA PRONTA — contrato CP** (ordem dele, 2026-09-08, depois de outra sessão do Code desenhar a logo à mão num PDF tendo o SVG oficial no próprio pacote da skill; verbatim: *"Se existe uma skill de DS da seed instalada, é primordial usar as regras do DS para tudo, nao tentar inventar algo (…) isso é inadimissivel"*, e *"se as capas ficaram erradas, fico questionando o que mais ele deixou de aplicar na criação"*). O `06-validacao/ferramentas/conferir-peca.py` mede o arquivo entregue em dez itens e emite ficha com placar; a skill passa a exigir a ficha em vez de caixa de marcar, e ganha a ordem obrigatória de tentativa para elemento de marca. | — (ordem direta, sem gate de abertura) | ≈ 1 sessão | ✅ **FECHADA em 2026-09-09 — veredito dele no chat, verbatim: *"pode fechar a F9.10 e abrir a F9.6"* (MANIFESTO §197). DOZE itens** (MANIFESTO §193, §195, §196). Nasceu em 2026-09-08 com dez itens e quatro estados (PASS · FAIL · AVISO · NÃO MEDI), provado nos dois PDF reais como cobaia; quatro defeitos do próprio instrumento achados e corrigidos, e as fontes Montserrat do DS consertadas no nome interno. **A fila CP zerou:** `CP-P1` (piso tipográfico para impresso) fechada pela tabela que ele aprovou — *"pode adotar a tabela acima"* — e virou o §4.8 do `marca-seed.md`; `CP-P2` (ler SVG e HTML) fechada; `CP-P3` (os dois PDF por corrigir) fechada com as peças refeitas; `CP-P4` fechada pelo veredito dele sobre identificador de conta de anúncio, hoje regra no CLAUDE.md do projeto e o AVISO do CP-9b. **Dois itens novos nasceram do mesmo jeito, e o jeito é a lição:** a ficha passou limpa numa peça com defeito que uma pessoa vê em três segundos, e quem viu foi ele — `CP-11` geometria de página (2026-09-08) e `CP-12` folha aproveitada (2026-09-09). O `CP-12` errou no dia em que nasceu, medindo peça de outro projeto (§196.6), e foi corrigido. **O que falta para fechar o brick: o veredito dele.** |

**Fila LC — pedidos de cobertura (nasce na F9.5, MANIFESTO §169.3).** Cada pedido de cobertura que a skill `seed-ds` gera (ou que chega por `contato@seed.eng.br` com o assunto `[DS] pedido de cobertura`) vira uma linha aqui, com código sequencial; resolvido = entrou no canon, ou foi recusado com o motivo escrito. Os nove primeiros vieram dos quatro testes de uso do fechamento da F9.5.

| código | origem | o que falta | onde deveria morar | estado |
|---|---|---|---|---|
| LC-01 | teste de uso, modo texto | contrato de MENSAGEM CURTA 1:1 (WhatsApp, SMS, chat): estrutura, comprimento, emoji neste canal, tratamento, saudação, modelos por evento recorrente | `seed-praticas.md` (seção nova) + `marca-seed.md` §10 para o que virar regra | ⚪ aberta — decisão de negócio dele |
| LC-02 | modo apresentação | spec §12 de APRESENTAÇÃO/DECK (canvas, grade, escala tipográfica de projeção, numeração, templates HTML em `07-pecas/`) + teto de grafismo para 16:9 no §7 | `marca-seed.md` §12 e §7 · `07-pecas/` | ⚪ aberta |
| LC-03 | modo apresentação | divergência: marca §13 manda corpo de slide em cinza-700 `#4D606C`; tokens v1.23 dizem `text.secondary` `#2F5A54` — duas verdades | `marca-seed.md` §13 → citar o token semântico (GI1) | ✅ **aplicada 2026-09-06** (marca v5.38; MANIFESTO §171) |
| LC-04 | modo peça | spec §12 de CARROSSEL de feed (4:5 ou 1:1, contador de slides, sinal de "arraste", continuidade do grafismo entre slides sob a regra da emenda §7.6) | `marca-seed.md` §12 | ⚪ aberta |
| LC-05 | modo código | §1.5: estado pressionado das variantes secondary/outline/ghost (só primary e destructive têm par hover/active); §18: spinner sobre superfície de ação (o token `--seed-action-primary-bg` que ele cita é fantasma) | `seed-componentes.md` §1.5/§1.6/§18 | ⚪ aberta |
| LC-06 | modo código | defeito: o exemplo React do §1.10 usa `--seed-text-on-brand` como tinta do primário — 2,94:1 medido no claro (piso 4,5) | `seed-componentes.md` §1.10 → `--seed-text-on-action-primary` (tokens v1.15) | ✅ **aplicada 2026-09-06** (componentes v1.44 — §1.3, §1.9, §1.10 e §54; §171) |
| LC-07 | modo código | `10-publicacao/ia/tokens.md` não lista `--seed-focus-ring`, `--seed-dur-*`, `--seed-ease-*`, que existem no gêmeo CSS e o §0/§1.9 usam | `gen-camada-ia.py` (emitir também as variáveis só do CSS) | ✅ **aplicada 2026-09-06** (seção nova no `tokens.md`; CI-6 conta as duas; §171) |
| LC-08 | modo peça | marca §10: eyebrow em cinza-500 sobre branco mede 3,39:1 — abaixo do piso 4,5 do §3 | `marca-seed.md` §10 → cinza-600 (4,74:1 medido; "corpo mínimo em fundo claro" do próprio token) | ✅ **aplicada 2026-09-06** (marca v5.38; §171) |
| LC-09 | modo código | divergência menor: o registry aponta `--secondary-foreground` para `--seed-action-secondary-text` (`#006C62`); o §1.6 manda o rótulo do botão secundário em `--seed-button-secondary-text` (`#005048`) — os dois passam AA | `gen-registry.py` ou `seed-componentes.md` §1.6 | ⚪ aberta |
| SK-P1 | V-Q2 dele (§168) | folha de revisão das 7 fichas de soluções (`09-pesquisa/skills-v1-2026-05/solucoes/`) lado a lado; o aprovado vira seção "soluções — escopo padrão" do `sobreaseed.md`; até lá a skill pergunta o escopo | `sobreaseed.md` | ⚪ aguarda a folha (gate próprio) |
| PB-P2 | F9.8, §1 da base (MANIFESTO §187.2) | **medir a zona de segurança da Meta na ferramenta.** A Meta não publica percentual de topo nem de lateral — o único número publicado é 40 % da base, para anúncio de Reels com aviso legal; a zona exata existe como sobreposição amarela no Gerenciador de Anúncios. Enquanto não for medida em tela, os 250 px de topo e os 48 px de lateral da base são convenção da casa, e estão marcados como tal | Gerenciador de Anúncios + `01-canonicos/seed-praticas.md` §1 | ⚪ aberta |
| PB-P3 | F9.8 (MANIFESTO §187.1) | **autorização dele para a sessão consultar a comparação com anunciantes semelhantes** (benchmark de setor) na conta de anúncios da SEED. É LEITURA, não escrita, e é a única fonte de primeira mão de desempenho por tipo de anúncio ao alcance da casa — responde direto ao "melhores = possuem resultado" do §186. A chamada foi bloqueada pelo classificador de permissão em 2026-09-07 e não foi contornada. **AUTORIZADA por ele em 2026-09-07** (regra em `~/.claude/settings.json`, quatro ferramentas de LEITURA liberadas; as que criam anúncio e gastam dinheiro seguem pedindo permissão a cada vez) e medida no mesmo dia: o canal abre, **o dado ainda não vem** — a comparação com anunciantes semelhantes devolve "sem dado para os critérios" em quatro janelas diferentes, e a de leilão devolve a coorte certa (objetivo, evento e tipo de público) com as três classificações em "ainda não disponível", porque os anúncios em veiculação são novos. Reavaliar quando acumularem entrega | conector de anúncios da Meta | 🔵 autorizada, sem dado ainda |
| PB-P4 | F9.8, onda 2 (MANIFESTO §189.7) | **a série do código da proposta comercial.** O formato `SEED-NNNN-AAAA` existe **só** na §9 da base de práticas: nenhum outro canônico do DS o define, e o ERP em construção vai precisar emitir esse número. Pela regra da casa, número de série vem do servidor, com contadora única e o servidor sempre sobrescrevendo o valor recebido — duas implementações da mesma série divergem em silêncio. Até a decisão, o formato da §9 é convenção provisória e não se replica em sistema | `01-canonicos/seed-praticas.md` §9 + ERP SEED | ⚪ aberta |
| PB-P5 | F9.8, onda 3 (MANIFESTO §190.3) | **a base legal do contato frio da SEED, por e-mail e por WhatsApp.** A §11 tratava o assunto em uma linha, só para WhatsApp, chamando de "consentimento" o que é transparência — e não dizia nada sobre e-mail frio, que é o canal principal dos frameworks da §10. Nome e telefone corporativo de pessoa identificada são **dado pessoal** pela **Lei 13.709/2018 (LGPD)**, e a lei exige base legal declarada. A base de práticas **não decide** qual base legal se aplica — não é competência dela, e afirmar errado é pior que omitir. Precisa ser definido por quem tem competência e virar regra da §11. Até lá vale o que não depende de parecer: dizer sempre de onde veio o contato, oferecer saída fácil, não usar lista comprada | `01-canonicos/seed-praticas.md` §11 | ⚪ aberta |
| PB-P6 | F9.8, onda 4 (MANIFESTO §191.4) | **dois canônicos discordam sobre a plataforma em que o ERP é construído.** O `seed-ds-roadmap.md` traz supersede explícito na v2.6 — *"o site institucional é Next.js na VM e o ERP é Vite/TanStack"* — e o `sobreaseed.md`, na linha de 2026 da trajetória, registra *"construção do ERP próprio em andamento (plataforma Lovable)"*. As duas podem ser verdade em momentos diferentes, mas como estão escritas se contradizem, e divergência entre canônicos não se resolve em silêncio. Precisa do veredito dele sobre qual é o estado atual, e aí o arquivo perdedor ganha nota de supersede | `01-canonicos/sobreaseed.md` + `01-canonicos/seed-ds-roadmap.md` + `seed-praticas.md` §14 | ⚪ aberta |
| PB-P1 | F9.8, gate de abertura (MANIFESTO §186.3) | **ligar a base de boas práticas ao desempenho REAL das contas da SEED.** A ordem dele manda aprender com "os melhores = possuem resultado", e a sessão NÃO consegue medir resultado de conta de terceiro (não há acesso a métrica alheia): as seções trazem regra de plataforma datada, estudo com amostra declarada e observação de forma — nunca "isto performa melhor". O resultado que a SEED PODE medir é o dela: exportar o desempenho das contas próprias e, na revisão do ciclo, comparar o que a base manda com o que deu certo em casa | `01-canonicos/seed-praticas.md` + contas da SEED | ⚪ aberta |
| PR-P1 | pergunta dele no chat, 2026-09-06 ("tem alguma forma de deixar automático?") | automação PARCIAL da manutenção do `seed-praticas.md`: (1) guarda de envelhecimento — seção com data além de um prazo (proposta: 6 meses) ou nunca auditada avisa no fechamento de todo brick; (2) ciclo agendado em que uma sessão pesquisa, datado, e devolve uma PROPOSTA de diferença por seção com fontes, que vai ao gate; o veredito continua manual (regra da casa: nada entra no canon sem gate) | `06-validacao/guardas/` + tarefa agendada | ⚪ **absorvida pela F9.8** (2026-09-06) |

*Supersede formal (v2.6):* os itens **"Site DS no Lovable"** e **"validação de pré-renderização do Lovable"** da lista original desta fase saem — o site institucional é Next.js na VM (projeto `seed-site`) e o ERP é Vite/TanStack; a vitrine nasce de gerador da casa (Q4). O resto da lista original (Atualizações, conteúdo e voz, checklist de acessibilidade, registry, llms.txt + tokens.md, GEO, skills, mapa de propagação) está distribuído nos seis bricks acima.

~~⚪ Site DS no Lovable (vitrine pública) · página de Atualizações/changelog · página de conteúdo e voz · checklist de acessibilidade · registry shadcn próprio · `llms.txt` + `tokens.md` para agentes · GEO no site institucional (resposta-primeiro, schema.org Organization/LocalBusiness×3/Service/FAQPage, robots liberando GPTBot/PerplexityBot/ClaudeBot, presença no índice Bing, validação de pré-renderização do Lovable) · retrofit final das skills `seed-ds-*` · **mapa de propagação final** (o que substitui o quê no PK/Drive; morte formal do `seed-design-system.html` v1 com supersede das 30 seções).~~ *(lista original, mantida riscada como história)*