Roadmap

s10. F9 — Publicação e camada de IA/GEO

estávelseed-ds-roadmap.md v2.48 · §s10seção 11 de 15s10-f9-publicacao-e-camada-de-ia-geo-fechada-em.md · MD5 0fc9aad9

Título completo no canon: 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)