# SEED engenharia — Roadmap do Design System v2

> **Mapa mestre do rebranding do design system SEED** (iniciado jul/2026). Este arquivo rastreia TODOS os itens do escopo com status, é a fonte de continuidade entre sessões deste projeto, e no futuro alimenta a página de progresso/changelog do site DS. Atualizar a cada bloco/fase concluído.
>
> **Contexto para leitor novo:** a SEED engenharia (HUB de engenharia elétrica — solar, subestações, GMG, projetos, consultoria; MG/ES/BA) está evoluindo seu design system de um manual de marca + HTML de componentes para um sistema completo em 3 camadas (tokens → semânticos → componentes), servindo peças de marketing, papelaria, documentos técnicos de engenharia, e-mail, site institucional e produtos digitais (ERP SEED, chat, futuros). Paleta e logo de 2018 intactos; o rebranding é de aplicação e profundidade. Perfil de produção da empresa: pesado em **gráficos, tabelas e relatórios complexos** — dataviz e densidade de dados são prioridade de primeira classe, não acessório.
>
> **Legenda:** ✅ entregue e aprovado · 🔵 entregue, em aprovação · ⚪ pendente · 🚫 fora do escopo (deliberado)
>
> **Data desta versão:** 2026-09-05 · v2.7
>
> ⚠ **RECONCILIAÇÃO DE ESTADO (v2.1, 2026-08-22) — este arquivo ficou 12 dias atrás do projeto.**
> Duas defasagens distintas, ambas fechadas nesta edição: **(a)** o cabeçalho dizia *v1.9 ·
> 2026-08-09* enquanto o próprio log já registrava a **v2.0 (2026-08-10)** — mesma classe da
> errata de cabeçalho do `seed-tokens.md` v1.20; **(b)** nenhuma edição registrou os fechamentos
> posteriores: **F5 FECHADA 6/6 em 2026-08-11** (a "pendência crítica" da v2.0 foi resolvida no
> dia seguinte a ser escrita), **F6 FECHADA 3/3** (marco v2.0 do ESTADO_ATUAL, 2026-08-13/14),
> a **renumeração de fases de 2026-08-15** (F7 = cobertura; aplicações → F8 — supersede formal
> no §12 do `marca-seed.md`) e toda a frente de 2026-08-15→22. O custo real da defasagem foi
> medido: em 2026-08-22 uma sessão quase reabriu como "próximo brick" a formalização da F5 — um
> trabalho **concluído 11 dias antes**. Regra que fica: **este arquivo é lido na abertura de
> todo brick (CLAUDE.md); se ele contradisser o `ESTADO_ATUAL_SeedDS.md` ou o changelog de
> qualquer canônico, o mais recente vence e a reconciliação deste arquivo precede o uso.**

---

## Arquivos canônicos do sistema (estado atual)

*(Tabela reescrita na v2.1 com as versões vigentes em 2026-08-22 — o detalhe de cada trajetória
vive no changelog do próprio arquivo e no log abaixo. A casa dos arquivos hoje é o repositório
git `seed-design-system` (GitHub `seed-engenharia`), com espelho no Drive
`marca seed/Design System v2/`; o índice de consulta com os 364 arquivos, classe e status é o
`INDICE.md`/`indice.json`/`llms.txt` da raiz, regenerado a cada fechamento.)*

| Arquivo | Versão vigente (2026-08-22) | Papel |
|---|---|---|
| `seed-tokens.md` + `.json` + `.css` | **v1.20 ✅** (§3c categórica estendida `estável` desde a v1.5/v1.6; guarda `paridade-tokens.py`) | Camadas 1–2 (primitivos + semânticos) |
| `marca-seed.md` | **v5.32 ✅** (F8 fechada: §12.1–§12.29 + §12.2-b, 30 specs de peça; moldura ampla v5.30; grafismo com gerador §7.6/§7.7) | Identidade visual canônica |
| `sobreaseed.md` | vivo (permanente; endereços reconciliados 2026-07-17 — GV = Rua Duarte Coelho, 205) | Institucional — fora do rebranding |
| `seed-design-system.html` | v1.0 (legado vivo; morte formal prevista na fase de publicação) | Fonte legada até o site Lovable |
| `seed-componentes.md` | **v1.29 ✅** (F3 7/7 + F6 §46–§48 + F7.2–F7.5 §49–§68 + contratos §69–§82) | Camada 3 (componentes, patterns e contratos) |
| `seed-composicao.md` | **v2.1 ✅ `estável`** (CP1–CP31 todos promovidos em 2026-08-16; 10º canônico) | Contrato de montagem de tela |
| `seed-email.md` | **v0.12 ✅** (F4 FECHADA 6/6; 8º canônico) | Sistema de e-mail (runtime próprio) |
| `seed-dataviz.md` | **v0.20 ✅ (F5 FECHADA 6/6 — DF·DT·DG·DM·DI·DP todos `estável`)** | Data visualization (9º canônico) |
| `mapa-cobertura-ds.md` | **v2.22** (consolidado parcialmente aprovado; D1–D6 decididas; F7.1–F7.5 entregues) | Inventário de cobertura × produto de referência |
| `plano-producao-pecas.md` | vivo (3 ondas — TODAS FECHADAS em 2026-09-04) | Plano de produção das peças (F8) |
| `inventario-pecas-ds.md` | confirmado contra a operação (2026-08-22) | Inventário de peças reais |
| `seed-ds-roadmap.md` | v2.1 (este) | Mapa mestre |
| `ESTADO_ATUAL_SeedDS.md` | v2.1 (2026-08-15) | Fotografia do vigente (padrão delta) |
| Camada de validação (`06-validacao/`) | **MANIFESTO.md (âncora MD5) + ~60 guardas/suites** — o censo vivo delas está no `INDICE.md` | Validação executada (jsdom + render + contraste + guardas de contrato) |

**Erratas abertas (herdadas na v1.8 — nenhuma resolvida nem criada no marco v1.5; a lista abaixo permanece como está):** `seed-feedback-preview.html` e `seed-superficies-preview.html` foram corrigidos pela auditoria render retroativa (hitbox do ⓘ e do +N — specs já mandavam) e viram os canônicos **v0.23b/v0.32b**: as cópias antigas no Drive devem ser substituídas. · ~~`marca-seed.md` v5.0 §12 e §17 citam "Fase 6 (aplicações)" — ler como Fase 7~~ **FECHADA em 2026-08-15 (F7.2), com correção MAIOR que a errata previa:** as quatro menções foram corrigidas para **Fase 8**, não 7. Motivo: em 2026-08-15 a Fase 7 passou a ser COBERTURA (F7.1–F7.7, nascida do `mapa-cobertura-ds.md`) e aplicações desceu para a F8 — a errata envelheceu antes de ser aplicada. Supersede formal escrito na §12 do `marca-seed.md`. · CMYK "U" das cores: a confirmar se surgir impressão fosca crítica. · ~~`sobreaseed.md` referencia o morto `erp-seed-design.md`~~ **FECHADA em 2026-08-15 (F7.2):** a linha de fronteira do §0 passa a apontar para `seed-composicao.md` e `seed-componentes.md`, com supersede formal no próprio arquivo. A menção no HISTÓRICO do `sobreaseed.md` (entrada de 2026-07-17) NÃO foi tocada, pela mesma regra do CP31: o registro conta o que foi declarado naquela data. · **ENCERRADA na v1.9 — errata do `seed-tokens.md` §5 (par info):** a F5 editou o arquivo por outro motivo e, pela regra GI2, a errata foi fechada junto. Correção mais completa que a prevista: 5.79 **é** do azul-700, mas o par SEMÂNTICO real do sistema (`feedback-info-text`) é o **azul-800, que mede 8.57 · AAA** — rótulo, número e veredicto corrigidos de uma vez. · **ENCERRADA na v1.7:** as cópias v0.23b/v0.32b já estão propagadas e ancoradas por MD5 no `validacao/MANIFESTO.md`. · **NOVA (v1.7):** existe em circulação uma `seed-navegacao-preview.html` **v0.37 de 30.804 B** (md5 `66769adcefd46a2da471a608eb729b72`) — é **lixo**, o arquivo defeituoso do marco v1.4. O canônico é a **v0.40, 51.718 B, md5 `98f5a6ce8974c75f0349f13e79314528`**. · **NOVA (v1.7):** a skill `seed-ds-ui` precisa receber a **árvore de decisão NM4** (quando usar glifo do set SEED × quando usar Lucide) e o **mapa de equivalências SEED↔Lucide** — mesmo padrão da pendência GI2 do marco v1.3. · **NOVA (v1.7):** normalizar o esquema de caminho das suites (hoje 4 pastas distintas, misturando `import.meta.url` com caminho absoluto embutido no código) — **adiada de propósito**, porque editá-las agora mudaria o MD5 recém-ancorado no MANIFESTO; fazer numa janela própria, atualizando o manifesto no mesmo movimento. · **NOVA (v1.9):** o `seed-tokens-preview.html` (35.129 B) ainda é o preview da v1.1/v1.2 — não mostra nenhuma escala da §3c; quem quiser ver dataviz usa o `seed-dataviz-tokens-preview.html` v0.2. Atualizar quando o preview de tokens for editado por outro motivo, ou aposentá-lo formalmente quando o site DS da F8 existir. · **NOVA (v1.9):** existem no Drive dois duplicados exatos por MD5 — `seed-email (1).md` (cópia de `seed-email.md`) e `validacao/MANIFESTO (1).md` (cópia de `MANIFESTO.md`); são resíduo de re-download e devem ir para a lixeira, porque arquivo duplicado é candidato a ser editado por engano.

---

## F1 — Tokens ✅ (v1.2)

Rampas tonais 6 famílias (8 canônicos + vermelho funcional) · semânticos light/dark (surface, text, border, action, accent, feedback, chart) · elevação pareada · motion 2 registros + reduced-motion · tipografia (Montserrat + JetBrains Mono) · spacing/radius · auditoria WCAG 14 pares · **v1.2 (2026-08-02): pacote mobile M1–M3** — breakpoints oficiais (Tailwind), tipografia fluida com `clamp()`, `--seed-fs-field-touch` 16px para `pointer: coarse`, rampa dourado corrigida.

✅ **v1.3 — ENTREGUE na F5 (sub-bloco DT, 2026-08-09), `estável` na §3c:** sequencial `chart-seq-1…7` · `chart-no-data` · divergente `chart-div-neg-3…pos-3` · gauge `gauge-track/value/range-*` · variante `cat-N-stroke` para traço fino. Nenhum hex novo — só stops existentes das rampas do §2.1.

✅ **v1.4 (2026-08-09):** promoção da §3c a `estável` + **reconciliação dos gêmeos** `seed-tokens.json`/`.css`, que estavam em v1.1 e sem nenhum token do pacote mobile v1.2. Guarda permanente nova: `paridade-tokens.py`.

⚪ **Pendente da F1:** revisão dos valores dark pós-uso real no ERP (§7.3) — depende do produto em produção, não do DS.

## F2 — Marca v5.0 ✅

Fundamento 3 princípios · Pantone/CMYK resgatados + errata azul-claro · lei 70/20/10 com 4 esclarecimentos · hierarquia amarelos (accent-highlight) · papel do azul · contraste medido · tipografia 2+1 (Montserrat com camada expressiva 800/900, JetBrains Mono, **Caveat celebratória**; Indie Flower e Neo Tech aposentadas) · logo responsivo + kit favicon spec + matriz de posição · EEny desacoplado com papel social estratégico · Grafismo v2 (linhas, ≤10%) · fotografia real · ilustração linha-primeiro · linguagem editorial · camada física com legibilidade quantitativa de frota · 19 supersedes.

Pendências herdadas: ~~vetores oficiais do Grafismo v2~~ ✅ **ENTREGUE 2026-08-22** (`03-assets/grafismos/` + gerador `gen-detalhe.py`; canon §7.6/§7.7 v5.12) · ⚪ curadoria do banco fotográfico real (operacional) · ⚪ kit favicon executável (F8). *(A marca avançou muito além da v5.0 registrada aqui: v5.13 em 2026-08-22 — dois regimes de grafismo §7.4-b, piso físico 0,25 mm §7.4-c, medida do cartão 90×50 §7.4-d, sangria §7.4-e, MR-P11 §17.6; trajetória no changelog do próprio arquivo.)*

## F3 — Componentes core (7 blocos)

| Bloco | Itens | Status |
|---|---|---|
| 1 · Botões | button (5 variantes + link, 3 tamanhos, 7 estados incl. selected/toggle), icon-button, toggles de ícone puro (padrão M3: glifo contorno↔preenchido + placa + forma; exceção negação de mídia), microcopy de rótulo | ✅ v0.5 (+full-width v0.7) |
| 2 · Formulários | form-field (base anatômica, 9 estados incl. warning, registry de máscaras B5: cpf, cnpj, cpf-cnpj, cep+ViaCEP, tel-br, tel-0800, tel-internacional E.164, moeda, data), input, busca, número/stepper, textarea, select, combobox (ARIA 1.2), checkbox, radio, switch, slider, date picker (régua por natureza da data), upload — **13/13 estáveis** · protocolo de live region §1.13 · fieldset/legend §2.6b · fronteira registrada: **rich-text é componente FUTURO fora deste bloco** (F6 do §6 — texto plano é o escopo; editor é outra classe) | ✅ v0.14 (validado 2026-08-03) |
| 3 · Feedback e status | alerta §15 · banner (2 níveis) §16 · toast §17 · spinner (+Régua de Espera com 3 regimes compostos) §18 · skeleton §19 · progress §20 · badge §21 · chip §22 · tooltip §23 · popover (+tray mobile, +"+N" do W7) §24 · empty state (5 tipos) §25 — taxonomia T1–T5 ("atenção", nunca "alerta" como severidade), nota **1.13-b** (regime discreto × contínuo de anúncio), decisão touch do tooltip (X2), separação tripla badge×chip, EEny proibido em erro/sem-permissão (Z5). **Vínculo CN2:** toasts de background (Q2-erro/U6) gravam na central de notificações (pattern F6) | ✅ **v0.24 (11/11, validado 2026-08-04 — marco v1.0)** |
| 4 · Superfícies | card §26 · divider §27 · lista §28 · accordion §29 · modal §30 · drawer §31 · avatar §32 — régua de 3 degraus fechada; escala de sobreposição 60<65<70<75<80 | ✅ **v0.32 (7/7, marco v1.1 — 2026-08-05)** *(linha sincronizada na v1.5; a v1.4 registrou o fechamento no log mas não nesta tabela)* |
| 5 · Navegação | tabs §34 (TB1–TB8, resolve AC5) · menu/dropdown §35 (MN1–MN8, fronteira semântica de 4 saídas) · breadcrumb §36 · paginação §37 · stepper/wizard §38 (resolve a fronteira do §20; régua dupla ERP×público) · **command palette ⌘K §39 (cumpre o §4.11)** — mais o pattern CN §33 (1ª metade do marco). Fronteira: shell sidebar/topbar = F6, consome este bloco | ✅ **v0.41 (6/6, marco v1.2 — 2026-08-06)** |
| 6 · Dados | tabela §40 (DT1–DT8: nativa nunca grid; 3 densidades com trava touch; sticky com a errata do border-collapse; aria-sort única) · seleção/massa §41 (SL1–SL5: indeterminate ✅, página×dataset, ids estáveis) · toolbar §42 (TD1–TD5: busca composta EUI ✅ + chips) · lista de dados/degradação §43 (LD1–LD5: dl + modo cards com importância de coluna Fiori — densidade ERP→mobile ✅) · guia de integração §44 (GI1–GI5: cadeia primitivos→`--seed-*`→aliases shadcn) — **as 3 pendências herdadas do B2 encerradas** | ✅ **v0.45 (5/5, marco v1.3 — 2026-08-06)** |
| 7 · Iconografia | §45 seção única — guidelines de construção IC1–IC7 (grid 24px, keylines, stroke 2, `currentColor`, escala) + nomenclatura e governança NM1–NM6 (inglês kebab-case conceito-variante, aliases PT-BR consumidos pela busca da ⌘K §39, fronteira SEED×Lucide) + **inventário do set canônico: 28 glifos ativos** (23 do acervo normalizados 40→24 · `substation` aproveitado · `bolt`/`generator` redesenhados na régua · `transformer`/`lightning-rod` novos, fechando os gaps dos pilares Subestações MT e SPDA) + 7 vereditos de governança (renome `add`→`circle-plus` por supersede + 6 aposentadorias por duplicata) | ✅ **v0.47 (1/1, marco v1.4 — 2026-08-07) — FECHA A FASE 3** |

## F4 — Sistema de e-mail ✅ (marco v1.5 — 2026-08-08)

✅ **FASE COMPLETA em 6 sub-blocos `estável`** (arquivo canônico: `seed-email.md` v0.10; delta integral no `CHECKPOINT_v1_5_fase4_email.md`):
**EM** fundamento técnico (15 decisões: hex literal · matriz T1/T2/T3 · dark = sobreviver à inversão · teto 80KB · multipart · HTML puro Cerberus · assets em URL imutável · Resend em `envio.seed.eng.br`) · **EL** layout (600px híbrido · botão VML · preheader · cabeçalho/rodapé canônicos · corpo 16px) · **EC** componentes (severidade com rótulo textual + border-left · tabela de dados semântica · card · lista · contato comercial · ícone raster sob demanda) · **ET** os 3 transacionais do ERP (proposta enviada · fatura processada · alerta de geração esperado×medido×desvio) com **placeholders mustache inventariados = contrato com o ERP** e From `notificacoes@` (ET7) · **EN** newsletter modular (4 módulos) + comercial texto-quase-puro (EN5: ferramenta/cadência de campanha ADIADAS até existir lista) · **EA** assinatura corporativa (logo vertical, ≤8k chars, instalada e provada no Gmail real).
**Infra montada e verificada:** Cloudflare R2 (`assets.seed.eng.br/email/v1/` imutável) · Resend sa-east-1 com DKIM/SPF/MX + DMARC p=none no subdomínio.
**O número do marco: 11 defeitos reais do gate visual do Rafael → 11 correções → 8 famílias de guarda (GV1–GV8) — zero visíveis à automação antes do olho humano.** Regra máxima que nasce: **NADA IMPLÍCITO**. Fica de fora por fronteira declarada: gráfico no alerta (F5) · e-mails de auth do Lovable (EM15) · disparo de campanha (EN5).

## F5 — Data visualization ✅ FECHADA 6/6 (2026-08-11 — marcos v1.8/v1.9 do ESTADO_ATUAL; `seed-dataviz.md` v0.20)

**Arquivo canônico:** `seed-dataviz.md` — o **9º** do sistema. Existe por conflito de regra-mãe: o `seed-componentes.md` manda "componente consome semântico", e o semântico de UI carrega intenção de interface (`action-primary`, `feedback-danger`); a série 2 de um gráfico não é "ação" nem "erro" — é a segunda categoria de um dado, com leis próprias (ordem fixa, diferenciação entre vizinhas, grayscale, isenção normativa). Mesmo precedente do e-mail (EM0) e da iconografia (NM5).

| Sub-bloco | Escopo | Status |
|---|---|---|
| **DF** · Fundamento | 7 decisões estruturais: arquivo próprio (DF1) · consumidor canônico shadcn Chart sobre **Recharts v3** (DF2) · régua de acessibilidade em 4 pisos medidos (DF3) · **grayscale como gate estrutural** (DF4) · régua de validação em 4 camadas (DF5) · fronteiras (DF6) · uma fonte para os tokens (DF7) | ✅ **`estável` (2026-08-09)** |
| **DT** · Tokens de dado | Escalas v1.3 na §3c do `seed-tokens.md`: sequencial · no-data · divergente · gauge · stroke de traço fino | ✅ **`estável` (2026-08-09)** |
| **DG** · Gráficos core | **7 tipos** (barra, empilhada, agrupada, linha, área, pizza, dispersão) + estados skeleton/empty/erro; 13 decisões, mais o redesenho visual DG14–DG17 | ✅ **`estável` (2026-08-09/10)** |
| **DM** · Monitoramento | Bullet graph canônico (gauge circular só por exceção) · sparkline na tabela §40 · gráfico do alerta ET5 (SUPERSEDIDO na v0.13: o e-mail de alerta NÃO leva gráfico) · spec DM1–DM11 no §4b | ✅ **`estável` (2026-08-11 — spec escrita na v0.5, "aprovo" explícito do Rafael)** |
| **DP** · Mapas | Diretriz MG-ES-BA · spec DP1–DP14 (§4d) · malha oficial IBGE 2025 (`mgesba-2025.topo.json`) | ✅ **`estável` (2026-08-11)** |
| **DI** · Impresso/PDF + integração | Grayscale/hachura para laudo e O&M · guia de integração da stack · DI1–DI19 | ✅ **`estável` (2026-08-11 — DI-b fechado por PROVA IMPRESSA FÍSICA)** |

Ordem de produção executada: DF → DT → DG → DM → DI → DP.

~~**Pendência crítica de estado (2026-08-10):** DG14–DG17, a paleta estendida e a spec do DM
existem apenas nos previews do Drive.~~ **RESOLVIDA em 2026-08-11, no dia seguinte** — o lote de
formalização foi executado por inteiro: `seed-tokens.md` §3c **v1.5** (categórica estendida,
magenta+violeta, supersede da restrição "nenhum hex novo") promovida a `estável` na **v1.6** com
gêmeos na mesma edição e `paridade-tokens.py` de guarda · `seed-dataviz.md` **v0.5** (supersede
DG11→DG14, emendas DG15–DG17, spec DM1–DM11 escrita) · `suite-dataviz-dm.mjs` criada. *(Esta
linha só foi reconciliada aqui na v2.1, 2026-08-22 — o arquivo ficou 12 dias afirmando como
crítica uma pendência já morta; ver a nota de reconciliação do cabeçalho.)*

**Fronteiras declaradas (DF6):** dashboard/layout de painel = **F6** (a F5 entrega a peça, não o painel) · tempo real/websocket/persistência = **produto** (Lovable/Supabase) · BI exploratório ad-hoc = fora de escopo (revisável) · **gráfico em e-mail = PNG @2x hospedado no R2**, porque o runtime de e-mail não roda JS (herda EM5 e EM11).

**Réguas que a fase acrescenta ao sistema:** **(1)** o **cinza é reservado a "sem dado"** em qualquer gráfico SEED — nenhuma escala de valor pode usá-lo, e a distinção "gerou pouco × não reportou" nunca depende de cor (hachura obrigatória). Nasceu do gate do Rafael (ver log v1.9). · **(2)** **paleta categórica estendida**: a marca tem só 3
matizes livres para dado, então o dataviz ganha matizes próprios (magenta, violeta) que **nunca
aparecem em UI** — padrão IBM Carbon/GitLab; nenhuma família de matiz repete antes da 6ª posição, e
nenhum gráfico multi-série pareia tons da mesma família. · **(3)** **vida vem de renderização, não de
cor**: zero contorno, canto arredondado, curva monótona, gradiente, palco mínimo e destaque×contexto
(DG14–DG17) — a hipótese de que "mais cor = mais vida" foi testada contra 7 telas de referência e
**refutada**: os gráficos da referência são quase monocromáticos.

## F6 — Patterns de produto e marketing ✅ FECHADA 3/3 (marco v2.0 — 2026-08-13/14; consolidação do shell no marco v2.1 — 2026-08-15)

✅ **6A Shell · 6B Página institucional · 6C Painel (§48 `estável`, PN1–PN54).** O marco v2.0 foi
de MAGNITUDE: a **âncora visual deixou de ser escura** (o azul saiu; entrou `turquesa-400`
`#11B0A0`, e o conflito com o §3.5 do `marca-seed.md` desapareceu em vez de superseder a marca), a
tinta de texto foi para a família turquesa e chegou aos 20 previews por esteira nova
(`tokens_bloco.py` + `paridade-previews.py` + `reinjeta-tokens.py`). O marco v2.1 consolidou o
shell em cadeia de gates (CP-P3 executada; rail vira PEÇA; nasce a `seed-tela-referencia.html`;
veredito dele: *"tudo 100%"*). **Remanescentes registrados no backlog D do `ESTADO_ATUAL` v2.1:**
6D do Painel (dependências FS/SS/FF/SF — PN42–PN45 reservados) · e-mail fora da tinta nova (duas
verdades de tinta, risco R2 do checkpoint v2.0). *(O §49 Painel de detalhe, que o backlog v2.1
listava como pendente, foi entregue `estável` na F7.3 em 2026-08-16 — PD1–PD19.)*

**Escopo original da fase, para referência histórica:**

⚪→✅ **Central de notificações (CN1–CN4, decidida no marco v1.0 · 2026-08-04):** pattern de composição — sino (icon-button §1) + badge §21 (dot default; contador só com valor de decisão; vermelho via consolidação V5 só p/ erro crítico não-lido) + popover→tray §24 como painel rápido + lista com severidades T1–T5, lida/não-lida por peso tipográfico (Fiori), timestamp, navegar-à-fonte + empty §25 "Tudo em dia". Régua editorial: só o que o usuário RESOLVE; nunca marketing. Persistência/tempo-real/preferências = produto (Lovable/Supabase), fora do DS. **Dependência dura: drawer (Bloco 4) para o painel "ver todas".**

✅ **Produto:** shell de navegação entregue no 6A (§46) e consolidado no marco v2.1; painel no 6C
(§48). O que a fase listava e NÃO entrou nela migrou com fronteira declarada: login/autenticação,
onboarding, busca global e configurações são os arquétipos A17–A20 da **F7.6** (mapa de cobertura
§8); rich-text segue componente futuro.
✅ **IA/chat:** entregue como **§55 chat `estável`** na F7.3 (2026-08-16), com o composer e o
botão dividido §54.
✅ **Marketing/institucional:** entregue no **6B — página institucional** (§47, contrato de
página com camada de máquina MK; publicação/descoberta fica na fase de publicação).

## F7 — COBERTURA (F7.1–F7.7) ✅ **FECHADA 2026-08-24 — 7 de 7** (F7.1 a F7.5 em 2026-08-15/17 · F7.6 em 2026-08-22/23 · F7.7 em 2026-08-23/24)

> **Renumeração de 2026-08-15, registrada aqui na v2.1:** a Fase 7 passou a ser a fase de
> **cobertura** — nascida do `mapa-cobertura-ds.md` (o inventário de tudo que um DS de ERP
> precisa prever, medido no produto de referência) — e **aplicações desceu para a F8**.
> Supersede formal no §12 do `marca-seed.md`. A fonte de verdade do detalhe é o **§8 do
> `mapa-cobertura-ds.md`** (etapas, entregas e bloqueios); resumo do estado:

- **F7.1 Fundação de composição** ✅ (2026-08-15 — `seed-composicao.md` v2.0; CP25–CP31 promovidos a `estável` na v2.1 em 2026-08-16)
- **F7.2 Telas de dado** ✅ (2026-08-15 — `tela-tabela` + `tela-lista` + §50–§53)
- **F7.3 Registro** ✅ com exceção nomeada (§49 detalhe · §54 · §55 chat · §56; **A6 formulário BLOQUEADO** — instância de referência indisponível)
- **F7.4 Fluxo de trabalho** ✅ com exceção nomeada (§57 quadro · §58 gantt; **A15 carga de trabalho BLOQUEADO** — sem instância no modo somente-leitura)
- **F7.5 Entrada e seletores** ✅ fila fechada no alcançável (nove bancadas §59–§68 `estável`; **C5 e C8 BLOQUEADOS** pela PS-P2)
- **F7.6 Bordas do sistema** ✅ **ENTREGUE 2026-08-22/23 (6/6, dois dias de gates encadeados)** — A19 autenticação (§83, fecha a CD-P5) · A20 onboarding (§84) · A17 busca (§85) · A18 configurações (§86) · A14 feed (§87) · A13 documento (§88); consolidado aprovado (P1–P5) + volta de leitura dirigida (`09-pesquisa/leitura-f76-bordas.md`) + retroativo HV1 + 6 suítes (101·0)
- **F7.7 Instrumentação e rigor** ✅ **ENTREGUE 2026-08-24 — P1 a P6, 6 de 6.** Com ela **a F7 (COBERTURA) FECHA INTEIRA: F7.1 a F7.7**
  - **P1 · o PORTE** ✅ — a camada de validação voltou a rodar nesta máquina. Diagnóstico da abertura:
    das 55 suítes só as 6 da F7.6 rodavam (21 presas a um Chrome de Linux, o resto com caminhos da
    pasta plana do Cowork). Nasce o contrato `ambiente.mjs` e o `PLACAR.md` como linha de base
    (**1.127 PASS · 0 FAIL** nas 17 jsdom antigas; 20 geradores provados por regeneração
    byte-idêntica). Fecha a pendência dos **caminhos nus** e a **AU-P1**
  - **P2 · módulo de cor** ✅ — `cor.py`/`cor.mjs` (gêmeos, 20·0 cada, paridade medida) fecham a
    lacuna `color(srgb …/α)` declarada no §12.5 do estudo; 13 scripts migrados com saída idêntica.
    De carona, a **DP-P7** fechou na opção B dele (o coropleto passou a desenhar a fronteira do DP4)
  - **P3 · rigor de cor e de contêiner** ✅ — a **C31 ganha a perna de COR** (ΔE76 calibrado contra o
    precedente do §7.5 da marca) e nasce a **guarda da lei do CP27 no acervo**, que achou 9 artefatos
    com nome fora da lista fechada → **CP27 vai de 8 para 10 nomes por supersede** (CN-P1 fechada)
  - **P4 · microcópia** ✅ — nasce a **§89 do `seed-componentes.md`** (MC1–MC18) por cinco decisões
    dele, sobre rodada de 12 fontes. A §89.3 (registro verbal em pt-BR) é a parte que só fonte
    brasileira resolvia. Guarda automatizada fica como **MC-P2**
  - **P5 · offline, conflito e virtualização** ✅ **ENTREGUE 2026-08-24 (cinco decisões dele)** — nascem a **§90 (OF1–OF9)**, a **§91 (CE1–CE8)** e a **§92 (LL1–LL6)** do `seed-componentes.md` v1.37, e as três linhas ❌ AUSENTE do §6.1 do mapa fecham. O §92 **fecha a BU-P1**. Achados que viraram lei: offline nunca se declara por flag · **trava exclusiva só para objeto que gera documento com ART** · paginação por achabilidade, não por desempenho —
    os três estados que seguem ausentes no §6.1. Evidência em
    `09-pesquisa/leitura-f77-estados-ausentes.md`; o limiar da lista longa foi **MEDIDO em cobaia**
    (`06-validacao/ferramentas/mede-lista-longa.mjs`) porque a lista mais longa do acervo tem 38 itens
    e não exercita o problema: **2.000 linhas** é onde um layout forçado (222–395 ms) estoura o
    orçamento de INP de 200 ms. A previsão escrita antes foi **derrubada** — contenção nativa rende
    5,87×–25,47× em blocos e **nada** em tabela — e ⭐ a régua óbvia mente pela terceira vez
    (`getComputedStyle` devolve `auto` nas duas estruturas), então **esta regra não tem conferência
    por declaração**: pendência **LL-P1**. **52º defeito** no caminho. **5 decisões** na folha
  - **P6 · limpeza dos 31 gastos** ✅ **ENTREGUE 2026-08-24** — ele leu os 5 trechos, pediu a remoção (*"pode seguir com sua recomendação, nao considero nada ali grave"*) e os **31 arquivos saíram** (537 KB), por nome, nunca por curinga. O git é a lixeira. **A F7.7 FECHA, E COM ELA A F7 INTEIRA** —
    `06-validacao/TABELA-REMOCAO.md`, gerada (31 arquivos · 537 KB), **nada removido**. Nasce a
    contraprova `06-validacao/ferramentas/audita-remocao.py`, que troca a pergunta errada ("quem cita
    este arquivo?") pela certa ("o que morre com ele?"): **28 LIVRES · 3 PRESOS**, e os 3 caem na
    conferência à mão porque o MANIFESTO guarda o verbatim em forma MAIS COMPLETA que a cópia. De
    carona, dois achados: **a marca de "travado" do índice morreu em silêncio no porte** (a expressão
    lia o caminho da pasta plana; todos os 31 saíam como não-travados) e as 5 citações canônicas dos
    gastos **já estão órfãs hoje**. **1 decisão** na folha

*(A frente de 2026-08-16→22 — contratos de qualidade §69–§82 do `seed-componentes.md`, grafismo
como componente, piso físico em mm, sangria, censo/INDICE — correu transversal à F7; trajetória
nos changelogs de `seed-componentes.md` v1.14→v1.29, `marca-seed.md` v5.2→v5.13 e
`mapa-cobertura-ds.md` §22.8→§22.25.)*

## F8 — Aplicações ✅ **FECHADA 2026-09-04 — TRÊS ONDAS, 30 specs de peça no `marca-seed.md` §12** (histórico das ondas abaixo) — 🔵 **era EM CURSO — a ONDA 1 FECHOU em 2026-08-25, 6 de 6 (7 peças): 1.1 placa de obra ✅ · 1.2 timbrado A4 ✅ · 1.3 proposta comercial ✅ · 1.4 envelope ✅ · 1.5 pasta A4 ✅ · 1.6 assinatura de e-mail ✅ · comprovante de ponto ✅ (fora da lista, por norma). Specs em `marca-seed.md` §12.1 a §12.8 (v5.15); relato e os dois defeitos de instrumento que a onda pagou no MANIFESTO §122. **A ONDA 2 FECHOU em 2026-08-26, 9 de 9 — e entregou DEZ peças** (veredito dele, verbatim: *"1. todos aprovados"*): 2.1 laudo/relatório técnico ✅ · 2.2 memorial descritivo ✅ · 2.3 checklist de comissionamento ✅ · 2.4 selo de prancha ✅ · 2.5 folha de rosto de ART + diário de obra ✅ · 2.6 caderno as-built ✅ · 2.7 crachá ✅ · 2.8 etiqueta de equipamento + selo de revisão ✅ · 2.9 família de sinalização NR-10 ✅, **mais a §12.20 placa de quadro e a §12.21 cartela de dispositivo, que NÃO ESTAVAM NO PLANO** — nasceram de defeito achado durante a própria onda (`SN-P13`/`PQ-P2`). Specs em `marca-seed.md` §12.11 a §12.21 (v5.21). **Além do plano das ondas, entraram também:** §12.9 cartão de visita e §12.10 proposta do SEED Plus. **Total aprovado na F8: 21 specs de peça.**
>
> ✅ **A ONDA 3 FECHOU em 2026-09-04 — e com ela a F8.** > **Onda 1** fechou em 2026-08-25 (6/6 + comprovante de ponto; §12.1–§12.8) · **Onda 2** em 2026-08-26 (9/9, dez peças; §12.11–§12.21) · fora das ondas §12.9 cartão e §12.10 SEED Plus · **Onda 3 em 2026-09-04 (7 de 7; o item 3.4 saiu do DS em 27/08 por ser serviço):** 3.1 frota ✅ (§12.22) · 3.2 uniforme/EPI ✅ (§12.23) · 3.3 one-pagers ×5 ✅ (§12.24) · 3.5 roll-up + totem ✅ (§12.25) · 3.6 favicon/avatares ✅ (§12.26) · 3.7 placa de instalação concluída ✅ (§12.27) · 3.8 portfólio ✅ (§12.28) + brinde = agenda ✅ (§12.29) — mais duas regras de família nascidas na onda: **moldura ampla** (§12.2, v5.30, +24,6% de área útil) e **marca d'água de contorno** (§12.2-b). Seis rodadas de gate (MANIFESTO §136–§142), 28/08 → 04/09. Entregável extra: quatro listas de fotos necessárias (frota, one-pagers, roll-up, portfólio) — a curadoria fotográfica (§17.2) passa a ter especificação de compra.
> **O que segue aberto na F8, nomeado:** capas de rede social (`FV-P1`), raster do kit de favicon quando houver site (`FV-P2`), tela de consulta do ponto (`PT-P2`) e arquétipo do diário (`AD-P7`) — os dois últimos são produção de ERP, não de DS.
> ⚠ Correção desta edição: a v2.2 dizia "8 itens ≈ 16 peças" incluindo o 3.4 — o plano já o havia retirado em 27/08 (v5.29 da marca). Registrado aqui porque é a terceira vez que este arquivo fica atrás do projeto (v2.1: 12 dias; v2.2: 5 dias; agora: o próprio fechamento).

> ⭐ **2026-08-24 — as três primeiras peças existem em ARQUIVO**, com gerador, mock renderizado e regeneração byte-idêntica: `07-pecas/placa-obra/` (dois tamanhos) · `07-pecas/timbrado-a4/` (mock + limpo, **área útil 170 × 205 mm a partir de (20, 44)**, que é o que a proposta herda) · `07-pecas/comprovante-ponto/` (bobina 80 mm + A4, Portaria MTP 671/2021). Specs em `marca-seed.md` v5.14, §12.1 a §12.4. Nasceram os dois instrumentos que faltavam à camada de peça: `render-peca.mjs` (prova visual por instrumento, duas cargas idênticas) e `guarda-peca-token.mjs` (**18 PASS · 0 FAIL** — a peça prova que consome token MEDINDO no navegador). **A proposta (1.3) não foi desenhada de propósito:** o plano fixa 1.2 antes de 1.3, e desenhá-la antes do timbrado gateado seria construir sobre fundação não aprovada.

> **Era a "F7" até 2026-08-15** (ver renumeração acima). O plano operacional é o
> **`plano-producao-pecas.md`** (3 ondas, entregável padrão = MOCK, arquivo de produção sob
> demanda — marca v5.11); o inventário foi **confirmado contra a operação real** em 2026-08-22
> (as 20 peças de papelaria/campo existem; só o layout de frota nasce do zero). Estado
> 2026-08-22: **grafismo ✅** (vetores oficiais + `gen-detalhe.py`, fecha a pendência da marca
> v5.0) · **cartão de visita ✅** (90×50 mm, piso 0,25 mm, sangria 3 mm — §7.4 da marca) ·
> **MR-P11 resolvida** (v5.13 §17.6: amarelo de marca fora de peça instalada em ambiente com
> sinalização de segurança) · **insumos da Onda 1 respondidos** (placa de obra = template com
> campos da Lei 5.194/66; timbrado com os dados do `sobreaseed.md` §1; proposta com briefing
> registrado + obrigação de pesquisa profunda de modelos antes de desenhar).
>
> **2026-08-24 — a obrigação de pesquisa do item 1.3 está CUMPRIDA:**
> `09-pesquisa/pesquisa-modelo-proposta.md`. Nenhum desenho foi feito, e de propósito — o plano fixa
> **1.2 antes de 1.3** (a proposta nasce do cabeçalho e da área útil do timbrado). O achado que muda
> o estado dos campos: **quase todo o briefing dele é exigência do CDC Art. 40** (orçamento prévio
> discriminando mão de obra, materiais e equipamentos, condições de pagamento **e as datas de início
> e término**), logo aqueles campos deixam de ser "seções propostas" e passam a ser **campos
> obrigatórios com fonte normativa** — como a placa de obra nasceu com os campos da Lei 5.194/66. ⭐ E
> a pesquisa achou o que o briefing NÃO tinha: **o campo de PRAZO**. Mais o §1º (validade de 10 dias
> salvo estipulação em contrário) e o §3º, que dá peso jurídico ao campo de itens exclusos. **2
> decisões** esperam veredito: técnica × comercial separadas, e a validade impressa.

| Família | Itens | Notas |
|---|---|---|
| Comercial | proposta (retrofit skill), apresentação institucional, one-pager/capability por pilar, **case study**, catálogo de serviços | skills `seed-ds-proposta`/`-slide` recebem retrofit |
| Técnico-documental | laudo/relatório técnico, memorial descritivo, **relatório mensal O&M**, checklist de vistoria, template de orçamento | a família mais SEED; tabelas e gráficos pesados — depende de F5 |
| Papelaria | cartão, timbrado, envelope, pasta, **crachá** | herdados 2018, redesenho linguagem v5 |
| Física | uniforme, frota, fachada, placa de obra, totem/banner, brindes básicos | regras já na marca §12 |
| Social/digital | post, carrossel, story, capas (retrofit skills), **kit de vídeo** (lower-thirds, vinheta, capa Reels), kit favicon, avatares | skills `seed-ds-post`/`-carrossel` recebem retrofit |
| Interna | comunicado interno, deck onboarding colaborador, certificado, **fundo de videochamada**, wallpapers | camada que rebrandings esquecem |
| Grafismo | ✅ **ENTREGUE 2026-08-22** — vetores oficiais em `03-assets/grafismos/` (textura, divisor, marcador), fonte de verdade no gerador `gen-detalhe.py` | fechou a pendência da marca v5.0; canon §7.6/§7.7 v5.12 |

## F9 — Publicação e camada de IA/GEO 🔵 **EM CURSO desde 2026-09-05 — desenho decidido por ele no gate de abertura (MANIFESTO §153–§154); F9.1 aberta**

> 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 | — | 2 sessões | ⚪ **PRÓXIMA** |
| **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 | ⚪ |
| **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 | ⚪ |
| **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 | ⚪ |
| **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 | ⚪ |

*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)*

## Fora do escopo — exclusões deliberadas (revisáveis)

🚫 Sonic branding (sem canal que justifique) · 🚫 internacionalização (PT-BR only até a operação pedir) · 🚫 motion graphics avançado/animação 3D de logo (kit de vídeo básico cobre) · 🚫 merchandising complexo · 🚫 tema white-label/multi-marca (a SEED tem uma tese, um tema).

## Método de qualidade da F3 (nasceu das críticas do Rafael no Bloco 1; ampliado no Bloco 2)

Todo componente com variantes/estados passa pelos **7 testes** (`seed-componentes.md` §1.12): container ≥3:1 medido · escada de MECANISMOS (nunca só tom) · aperto de olhos/grayscale · teste do par · regra do um · teste do estado atual ("teste WebEx") · **teste do polegar** (360px com teclado aberto — entrou no v0.7 com a premissa mobile). E: **token de componente que referencia primitivo declara par light/dark obrigatório** (bug real pego no dark do Bloco 1: ghost estava em 2.7:1). **Ampliado no Bloco 3 (2026-08-04):** as suites da validação executada viram ARTEFATO PERMANENTE em `Design System v2/validacao/` (5 suites DOM + contraste.py — 166 testes; regressão dos próximos blocos é re-execução, não reescrita) · **duas lições permanentes:** a suite valida comportamento, NÃO geometria — a validação visual do Rafael é o gate complementar (bug real: overlays sem posicionamento ancorado passaram na suite); e asserções sobre live regions exigem flush de microtask entre atualizações síncronas (mutations coalescem) · regra de preview: **nenhum botão morto** — todo CTA de demo responde. **Novo no Bloco 2 (2026-08-03): validação executada** — além da validação visual do Rafael, o preview passa por suite automatizada (DOM headless + contraste WCAG em script) antes da promoção a estável; a primeira rodada (63 testes) pegou 5 bugs de implementação que a leitura de spec não pegaria (parser inexistente no slider pareado, `aria-invalid` com valor vazio via `toggleAttribute`, canais de live region fundidos na busca, `role="alert"` ausente no switch e no upload).

## Decisões estruturais que governam tudo (referência rápida)

Uma fonte de verdade: tokens v1.x alimentam site DS, produtos, skills e peças · componentes consomem semânticos, nunca hex · dark mode nativo · WCAG 2.2 AA piso · **paridade mobile/app é premissa de primeira classe (2026-08-02): nenhum bloco nasce desktop-first — haverá apps, e o uso mobile supera o desktop; breakpoints e tipografia fluida nos tokens v1.2, teste do polegar no método** · lei 70/20/10 · ação primária sempre turquesa/verde, nunca azul · vermelho é funcional, proibido em marca · Caveat só em display celebratório · nada é deletado antes do substituto existir com supersede documentado · **este projeto (PK) é a casa permanente dos trabalhos da SEED daqui pra frente** — decisão de 2026-07-31.

## Log

| Versão | Data | Mudança |
|---|---|---|
| 2.7 | 2026-09-05 | **F9.1 FECHADA — a camada de IA está no ar em `https://ds.seed.eng.br`** (MANIFESTO §155–§156): 11 canônicos inteiros + 259 fatias por § com procedência + tokens.md + índices + robots (todos os robôs de IA liberados) + sitemap; provado por HTTPS: 283/283 arquivos com MD5 igual ao disco, 274/274 `.md` como text/markdown. Receita em `deploy/`; sequência de fechamento de brick ganha o `gen-camada-ia.py` e a guarda (CLAUDE.md). Próximo: F9.2 registry shadcn. |
| 2.6 | 2026-09-05 | **F9: desenho DECIDIDO por ele no gate de abertura (MANIFESTO §154) — sete respostas, seis bricks.** Superfície = VM ao lado do site, `ds.seed.eng.br`, robôs de IA todos liberados, casca da vitrine por gerador da casa (contra a recomendação Starlight; custo aceito), ordem IA → registry → vitrine → GEO → skills → mapa, GEO entregue como pacote ao projeto do site, skills substituídas por um pacote único (leitura a confirmar). Supersede formal dos itens "Lovable" desta fase. **F9.1 aberta.** |
| 2.5 | 2026-09-05 | **F9 ABERTA pelo Reconhecimento (MANIFESTO §153).** Medido antes de desenhar: o `llms.txt` existe mas o repositório é privado (nenhum agente de fora alcança); o `seed-componentes.md` tem ≈ 313 mil tokens (não cabe em agente — a camada de IA precisa fatiar por §); o site institucional **não é mais Lovable** (Next.js na VM, projeto próprio) e não tem JSON-LD nem robots para IA; o ERP tem **0** tokens `--seed-*` (tema shadcn padrão); as 7 skills `seed-ds-*` são de 2026-05-13 (18 tokens contra 293). Desenho proposto em seis bricks (F9.1 camada de IA · F9.2 registry shadcn · F9.3 vitrine · F9.4 pacote GEO do site · F9.5 skills · F9.6 mapa de propagação) e sete perguntas com custo no gate. Os itens "Lovable" deste § ficam como estavam até o veredito dele — supersede candidato registrado no §153.2. |
| 2.4 | 2026-09-05 | **Entre a F8 e a F9: a fila de pendências resolvida por ordem dele antes de abrir a fase** (`marca-seed.md` v5.33, MANIFESTO §144–§146): PI-P1 e SN-P10 fechadas por veredito, FV-P2 executada, FV-P1/FV-P3 (capas de rede, §12.30) e FV-P4 (destaques do Instagram, §12.31) produzidas e decididas; nasce FV-P5 (glifos). F9 continua PRÓXIMA — e agora com a camada de rede social pronta para publicar. |
| 2.3 | 2026-09-04 | **F8 FECHADA — a Onda 3 fecha 7 de 7 em seis rodadas de gate (MANIFESTO §136–§142), e o §12 do `marca-seed.md` vai a 30 specs (v5.32: §12.22–§12.29 + §12.2-b).** O que a onda deixou de regra além das peças: tipografia do contato (§138.1), regra do formato veículo, regra geral do bolso, moldura ampla (v5.30), marca d'água de contorno (E1 aplicada, P3 oficial). Corrigido: "8 itens ≈ 16 peças" → 7 itens (3.4 saiu em 27/08). **Próximo: F9 — publicação e camada de IA/GEO.** Regra que fica reafirmada: este arquivo se atualiza NO FECHAMENTO da onda — esta edição é o próprio fechamento. |
| 2.2 | 2026-08-27 | **O MAPA MESTRE VOLTOU A FICAR PARA TRÁS — 5 dias desta vez, achado ao ele perguntar *"quanto falta pra finalizarmos o DS?"*.** ⭐⭐ **Essa pergunta se responde LENDO ESTE ARQUIVO**, e ele ainda dizia *"Próximo: Onda 2"* com a **Onda 2 aprovada em 2026-08-26** (*"1. todos aprovados"*, dez peças, `marca-seed.md` §12.11–§12.21). É a **segunda ocorrência da mesma defasagem** — a v2.1 nasceu justamente de o arquivo estar 12 dias atrás. **A diferença: em 2026-08-22 a defasagem foi descoberta quando quase custou trabalho refeito; agora foi descoberta ao tentar RESPONDER com ela.** Esta edição registra: F8 com a Onda 2 fechada 9/9 (10 peças, duas fora do plano, nascidas de defeito achado na própria onda) + §12.9/§12.10 fora das ondas = **21 specs de peça aprovadas**; e a **Onda 3 destravada, 8 itens ≈ 16 peças, aguardando só a palavra dele**. **RÉGUA QUE FICA: o estado do projeto se responde do arquivo, e por isso o arquivo se atualiza no fechamento de cada onda — não quando alguém pergunta.** |
| 2.1 | 2026-08-22 | **RECONCILIAÇÃO DE ESTADO — o mapa mestre estava 12 dias e duas fases atrás do projeto, e o custo apareceu: uma sessão quase reabriu como "próximo brick" a formalização da F5, concluída 11 dias antes.** O que esta edição corrige, tudo ancorado em documento existente (nenhuma decisão nova): **(a)** errata de cabeçalho — dizia *v1.9 · 2026-08-09* com o log já em v2.0; **(b)** **F5 → FECHADA 6/6** (2026-08-11; `seed-dataviz.md` v0.20; marcos v1.8/v1.9 do `ESTADO_ATUAL`; a "pendência crítica" da v2.0 foi resolvida NO DIA SEGUINTE a ser escrita — §3c v1.5/v1.6 + gêmeos + spec DM1–DM11 + suite do DM — e este arquivo nunca registrou); **(c)** **F6 → FECHADA 3/3** (marco v2.0, 2026-08-13/14: âncora vira turquesa; marco v2.1, 2026-08-15: shell consolidado, *"tudo 100%"*); **(d)** **renumeração de fases de 2026-08-15 aplicada**: F7 = COBERTURA (F7.1–F7.7 do `mapa-cobertura-ds.md`, com F7.1–F7.5 entregues), aplicações = F8, publicação/IA-GEO = F9 — supersede formal no §12 do `marca-seed.md`, que até hoje apontava para uma errata deste arquivo que ficou superada; **(e)** tabela de canônicos reescrita com as versões vigentes (tokens v1.20 · marca v5.13 · componentes v1.29 · composicao v2.1 · email v0.12 · dataviz v0.20 · mapa-cobertura v2.22), incluindo os canônicos que nasceram depois da v2.0 e nunca entraram nela; **(f)** estado da F8 registrado (grafismo ✅ 2026-08-22 · cartão ✅ · MR-P11 resolvida v5.13 · insumos da Onda 1 respondidos). **Regra que a reconciliação deixa no cabeçalho: se este arquivo contradisser o `ESTADO_ATUAL` ou o changelog de um canônico, o mais recente vence e a reconciliação precede o uso.** A causa raiz é a mesma classe do defeito do marco v1.4 (afirmado, nunca lido de volta): os fechamentos de fase atualizaram checkpoint, ESTADO_ATUAL e canônicos, mas nenhum rito exigia voltar AQUI — e o arquivo que o CLAUDE.md manda ler primeiro era o único que ninguém mantinha. |
| 2.0 | 2026-08-10 | **MARCO v1.7 — o sub-bloco DG (gráficos core) fecha `estável` com 13 decisões, e o sistema ganha uma PALETA CATEGÓRICA ESTENDIDA e um redesenho visual inteiro (DG14–DG17).** O DG cobre **sete tipos** — barra, empilhada, agrupada, linha, área, pizza, dispersão — mais os três estados herdados do Bloco 3. Duas emendas aconteceram *durante* a produção: a **barra empilhada** foi puxada para dentro do escopo a pedido do Rafael (caso real: consumo por posto tarifário), trazendo junto a **agrupada** como saída obrigatória; e o **DG13 (textura)** nasceu do gate. Âncoras da spec: **DG1** — todo gráfico é um invólucro de 5 partes com **fallback textual sempre presente**, porque a auditoria pública de 2024 do shadcn Charts reprovou a biblioteca em 1.1.1 (sem alternativa textual) e 1.3.1 (legenda sem relação codificada): acessibilidade de gráfico **não se delega à lib** · **DG2** — um tab-stop + setas, com o gap do VoiceOver **declarado e não resolvido** (o Recharts contorna com `role="application"`, que o VO não suporta), logo o teclado é enriquecimento e quem garante o acesso é a tabela · **DG4** — eixo zero é regra dura **assimétrica**: barra e área sempre do zero porque comprimento e área codificam valor por geometria; linha pode truncar sob três condições, e a SEED **precisa** disso (PR de usina e tensão de rede variam pouco e importam muito) · **DG5** — pizza com 8 travas, incluindo a regra dos 5 p.p. e o corte do dado ordinal · **DG10** — empilhada com teto de **4 segmentos** (aperto deliberado sobre os 5 do mercado, por motivo interno: acima disso a paleta pareia matizes da mesma família, e segmento preenchido não carrega tracejado para desambiguar). **O MARCO TEM QUATRO FATOS DE MÉTODO, TODOS NASCIDOS NO GATE VISUAL E NENHUM ANTECIPÁVEL PELA PESQUISA.** *(1) Instrumento errado, medição certa.* O portão de grayscale media **razão de contraste WCAG** entre séries convertidas para cinza e reprovava o modo claro (`cat-1` × `cat-3` = 1,22) — exatamente onde o gate humano lia bem. A razão de contraste foi calibrada para **texto sobre fundo**, não para faixas grandes adjacentes separadas por contorno; a métrica correta é o **espalhamento de claridade** (claro espalha 20 pontos; escuro comprime em 4, com duas séries idênticas). O piso de 6 pontos ficou declarado no código como **calibrado pelo gate, não derivado de norma** — e quando tentei generalizá-lo para as bandas finas do DM, o gate reprovou de novo: **um piso vale só no contexto em que foi medido.** *(2) A paleta da marca tem teto físico.* Medindo o matiz de todos os primitivos: para dado existem **3 matizes livres** (turquesa ~170°, dourado/amarelo ~36–50° — mesma família —, azul ~197°), porque vermelho e cinza são reservados. A restrição **"nenhum hex novo"** que eu mesmo propus no DT provou-se apertada demais e **vai a supersede**. Seguindo o padrão IBM Carbon/GitLab (paleta de dataviz separada da marca), nasceram **2 matizes exclusivos de dado, que nunca aparecem em UI**: magenta 332° e violeta 268°, calibrados na claridade das âncoras SEED. Sequência final: **turquesa → dourado → magenta → azul → violeta → azul-800**, cobrindo 5 famílias, com a regra de que **nenhuma família repete antes da 6ª posição** e **nenhum gráfico multi-série pareia tons da mesma família** — esta última nasceu do Rafael apontar que a linha dupla e o gráfico do ET5 tinham ficado turquesa × turquesa. *(3) Vida não vem de cor, vem de renderização.* O Rafael trouxe 7 telas de um produto de referência e pediu análise antes de qualquer execução. O achado **contrariou minha própria hipótese**: os gráficos da referência são **quase monocromáticos** e mesmo assim parecem vivos. O que separava era a renderização — daí **DG14** (zero contorno; separação de segmentos por **vão de 2px**, geometria em vez de contraste; `cat-1` claro → turquesa-500 para passar 3:1 sozinho), **DG15** (canto arredondado em todo retângulo de dado; **curva monótona**, nunca spline genérica, que inventa picos inexistentes; gradiente 22%→0), **DG16** (palco mínimo: ≤3 gridlines hairline, sem linha de eixo, número protagonista com micro-caps mono e variação em pílula) e **DG17** (destaque×contexto). **O DG11 — contorno `cinza-900`, que eu havia criado por medição poucos dias antes — foi superado por completo:** era ele que dava o ar de relatório antigo. A acessibilidade foi preservada por outros mecanismos, todos medidos, e o **DG13 permanece**: a paleta estendida melhora o colorido, não revoga a textura. *(4) A matriz de render se CRUZA, não se amostra.* Havia 4 cenários cobrindo `claro+grayscale` e `escuro`, mas **nunca a combinação** `escuro+grayscale` — e era ali que morava o defeito que o Rafael achou (todas as séries colapsando no mesmo cinza). Amostrar combinações dá **sensação** de cobertura. A matriz passou a cruzar tema × grayscale × largura, e o render mede propriedades **resolvidas pelo navegador** — o `fill` efetivo após a cascata, e o `getBBox` de todo texto SVG contra os limites do `viewBox` (um rótulo terminava em x=509 num viewBox de 500 e era cortado em silêncio). **Sub-bloco DM (monitoramento) — preview aprovado, spec ainda NÃO escrita:** **DM1** o medidor canônico é o **bullet graph**, com gauge circular só por exceção declarada (a literatura é unânime: ângulo é pior que comprimento para comparar, e o ERP compara muitas usinas) · **DM3** **inversão de papéis** — as bandas de faixa viram **intensidades de cinza** e quem carrega a severidade é a **barra de valor**; motivo medido: as três faixas coloridas ficavam a **1 ponto** de claridade entre si no claro e **0** no escuro, diferindo quase só por matiz, exatamente o que Few previu ao mandar codificar faixas em intensidades e não em matizes · **DM4** `role="meter"` com o rótulo **fora** do elemento, porque descendente de meter é apresentacional · **DM5/DM6** sparkline sem eixo, `aria-hidden`, com a célula vizinha carregando o número · **DM8** o gráfico do alerta **fecha o slot ET5** aberto na F4. **Hierarquia de traço (3 níveis: dado 2px · estrutura 1px · apoio 0,5px) com `vector-effect: non-scaling-stroke` obrigatório** — medido, as escalas dos SVG iam de **0,66× a 12,4×**, então o mesmo `stroke-width="1"` renderizava entre meio pixel e doze: espessura era subproduto do contêiner, não decisão de design. **Validação do marco:** jsdom do DG **163 PASS · 0 FAIL** · `contraste-dg.py` 32 PASS · 0 FAIL · 14 MITIGADO · 4 ISENTO (com a distinção explícita entre "falha" e "falha prevista e resolvida por outro mecanismo", porque misturar as duas apaga o sinal) · render puppeteer **6 cenários cruzados** por preview. **PENDÊNCIA CRÍTICA:** DG14–DG17, a paleta estendida e a spec do DM **existem apenas nos previews do Drive** — o lote de formalização (§3c v1.5 + gêmeos + `seed-dataviz.md` + suite do DM) é o próximo trabalho, antes de DP e DI. **Esta versão NÃO fecha fase e NÃO gera CHECKPOINT.** |
| 1.9 | 2026-08-09 | **MARCO v1.6 — A FASE 5 (DATA VISUALIZATION) ABRE, e seus dois primeiros sub-blocos já são `estável`: DF (fundamento) e DT (tokens de dado).** Nasce o **9º arquivo canônico, `seed-dataviz.md` v0.3**, pela mesma classe de conflito que criou o `seed-email.md` na F4: **cor de dado não é cor de UI.** O semântico de UI carrega intenção de interface — a série 2 de um gráfico não é "ação" nem "erro", é a segunda categoria de um dado, e obedece a leis que a UI não tem (ordem fixa, diferenciação perceptual entre vizinhas, comportamento sob grayscale, e uma isenção normativa que nenhum componente de UI possui: o WCAG 1.4.11 isenta explicitamente heatmap). Hospedar isso no `seed-componentes.md` — que já tem 341 KB — contaminaria a regra-mãe do arquivo. **O que o DF fixou em 7 decisões:** o canônico é **agnóstico de biblioteca**, mas o consumidor canônico web é o **Chart do shadcn/ui sobre Recharts v3** (a stack real do Lovable), com o detalhe técnico de que no v3 a referência é `var(--chart-N)` direto, sem o wrapper `hsl()` antigo · **régua de 4 pisos, todos medidos por script**: 1.4.1 (cor nunca é o único portador), 1.4.11 (3:1, com isenção declarada e *condicionada* para a escala sequencial), 1.4.3 (rótulo/eixo/legenda ≥4.5:1) e 1.1.1 (todo gráfico tem fallback textual) · **grayscale vira gate ESTRUTURAL, não teste opcional** — todo preview da fase carrega modo P&B acionável, o que serve de uma vez o "aperto de olhos" do método e o impresso da F7 (laudo e O&M saem em P&B), evitando uma fase inteira de gráficos que não degradam. **O FATO DE MÉTODO DO MARCO SÃO DOIS, E OS DOIS SÃO SOBRE DETECTORES.** *(1) O gate humano achou de novo o que a automação não podia achar.* O DT foi ao gate com três camadas automatizadas verdes; o Rafael olhou o preview e perguntou se a escala inicial "era pra ser toda em cinza mesmo". Os stops 50/100 da rampa turquesa têm chroma tão baixo que **perdem o matiz em tela** — e cinza, em dataviz, significa "sem dado": valor baixo e ausência de medição eram ambíguos. As três camadas mediam **razões de contraste**, não **percepção de matiz**; nenhuma delas poderia ter visto. Correção estrutural aprovada sobre preview comparativo: a rampa desloca um stop (**100→900 light / 800→100 dark**) e nasce o token **`chart-no-data`** — cinza **exclusivo** de "sem medição", **sempre hachurado**, de modo que a distinção "gerou pouco × não reportou" nunca dependa de cor (1.4.1, grayscale e impresso de graça). *Alternativa descartada:* manter 50→800 e resolver só pela regra do no-data — rejeitada porque a leitura-cinza permaneceria na tela. *(2) Uma regra sem detector não é uma regra.* A promoção obrigou a abrir os arquivos gêmeos de token e a medição mostrou que `seed-tokens.json` e `seed-tokens.css` declaravam **v1.1** e não continham **nenhum** token do pacote mobile **v1.2** — zero ocorrências de `breakpoint`, `safe-area`, `fs-field-touch` e `clamp`. A defasagem era de **duas versões**, e a própria pendência §7.0 do `seed-tokens.md` a descrevia como sendo de uma. Causa raiz: a regra "os três arquivos formam uma unidade" existia desde a v1.0 **sem nenhum detector** — ler o `.md` não revela nada sobre o conteúdo dos gêmeos, e o `.md` é justamente onde a versão dos três é declarada; a fonte da afirmação e o objeto da afirmação nunca se encontravam. Mesma classe do defeito de propagação do marco v1.4. **Correção estrutural: nasce `validacao/paridade-tokens.py`** (G1 não-regressão · G2 paridade json↔css · G3 cobertura nominal em light e dark), **43 PASS · 0 FAIL** — e ela **reprovou a primeira tentativa de regeneração**, que reescrevia o CSS a partir do JSON e no caminho renomeou `--seed-sp-*` para `--seed-space-*`, perdeu o composto `--seed-focus-ring` (que só existe no CSS) e serializou sombras, famílias e beziers como estrutura DTCG. A entrega passou a ser por **edição cirúrgica** do arquivo anterior. **Lição transferível: regeneração total a partir de um modelo incompleto perde token em silêncio; preservar bytes é mais seguro do que reconstruir e conferir.** **Terceiro fato, de propagação:** o Rafael anexou o repositório inteiro em zip, o que permitiu a **primeira leitura de volta COMPLETA contra a âncora do MANIFESTO — 27 de 27 artefatos batem byte a byte**, e permitiu fechar a pendência **P4** (os artefatos de e-mail do marco v1.5 nunca tinham sido ancorados). O `MANIFESTO.md` vai a **v1.2** com 21 linhas novas. **Aprendizado de ferramenta da fase:** a camada de render da F5 usa **puppeteer** (viewport + `fullPage`), **nunca** o CLI `--screenshot` do Chrome — medido: o CLI truncou a renderização à direita e simulou um overflow inexistente (`scrollWidth` real 360, zero elementos estourando). **Erratas encerradas neste marco:** a do `seed-tokens.md` §5 (par info), aberta desde 2026-08-04 — pela regra GI2, a F5 editou o arquivo por outro motivo e a errata foi fechada junto, com correção mais completa que a prevista (o par semântico real é azul-800 = 8.57 AAA, não uma simples troca de rótulo). **Validação do marco:** `contraste-dataviz.py` **29 PASS · 3 FAIL** (os 3 são documentados e esperados — o *fill* cat-1/cat-2/cat-5 em traço fino, que é a razão de existir da variante `cat-N-stroke`) · `paridade-tokens.py` **43/0** · jsdom do DT **14/14** · 4 renders puppeteer inspecionados · cruzamento §3c × gêmeos **26/26**. **Esta versão NÃO fecha fase e por isso NÃO gera CHECKPOINT** — o padrão delta reserva o checkpoint imutável para fechamento de bloco/fase, e a F5 tem 4 sub-blocos ainda não escritos; o vigente está no `ESTADO_ATUAL_SeedDS.md` v1.6. **Próximo: sub-bloco DG (gráficos core) — barra, linha, área, pizza-com-regras, dispersão + skeleton/empty/erro, no rito de 3 rodadas encadeadas → consolidado → aprovo → lote autônomo.** |
| 1.8 | 2026-08-08 | **MARCO v1.5 — A FASE 4 (SISTEMA DE E-MAIL) FECHA COMPLETA, 6/6 SUB-BLOCOS `estável`, EM ~36 HORAS DE ABERTURA A FECHAMENTO.** Nasce o **8º arquivo canônico, `seed-email.md` v0.10**, porque e-mail é OUTRO RUNTIME: consome hex literal (`var()` é morto em Gmail/Outlook), layout por tabela, PNG com cor assada — hospedar isso no `seed-componentes.md` contaminaria a regra-mãe "componente consome semântico". Infraestrutura REAL montada e verificada na própria fase: Cloudflare R2 servindo `assets.seed.eng.br/email/v1/` (caminho imutável) e Resend verificado em `envio.seed.eng.br` (São Paulo) com DKIM/SPF/MX + DMARC. Entregues: template-base v0.4 · preview de componentes v0.3 · **3 transacionais do ERP** (proposta · fatura · alerta esperado×medido×desvio) com **inventário de placeholders mustache como contrato formal com o ERP** · newsletter modular v3.2 (4 módulos removíveis) · comercial texto-quase-puro · assinatura corporativa v0.2 **instalada e provada no Gmail real do diretor**. **O FATO DE MÉTODO DO MARCO: 11 defeitos reais encontrados pelo gate visual do Rafael, 11 corrigidos, 8 famílias de teste-guarda permanentes (GV1–GV8) — e NENHUM dos 11 era visível às verificações automatizadas.** A previsão da abertura (em e-mail o gate humano é a camada determinante) confirmou-se com números: a suíte estática é o piso, o olho é o juiz. Destaques do ciclo: o defeito 9 (faixas cinza no Outlook) levou TRÊS hipóteses até o veredito — **qualquer row-spacer com `&nbsp;` fantasmagoriza em zoom ≠100% no motor Word; espaçamento vertical canônico passa a ser padding/margin** — com direito a uma reclassificação prematura de Claude derrubada pelo print seguinte do Rafael (registrada, não apagada); o defeito 10 foi **erro de ferramenta do próprio produtor** (uma linha "no-op" destruiu 9 `</p>` e a suíte passou verde — nasceu o GV7 de balanceamento); o defeito 11 fundou a classe **"artefato composto desatualizado"** (o comercial embutia a assinatura antiga após o supersede do logo — nasceu o GV8 com a lista viva de assets aposentados). Decisão de fechamento do Rafael ("aprovo b"): row-spacers do acervo promovido ficam como **tolerância monitorada** (retrofit só quando um template for editado por outro motivo). Protocolos permanentes novos: **print de e-mail encaminhado não é evidência de gate** (encaminhar descarta head e VML) · API key de teste é descartável (Read-Host + revogação) · matriz de gate mínima = Gmail web + Gmail Android dark forçado + Outlook 2024 clássico. Placar: **312 PASS / 0 FAIL** em 14 arquivos · contraste 14 pares/0 reprovações · 9+ evidências de recebimento direto. Backlog que a fase deixa: rodapé com endereço real antes do 1º envio a cliente · trilha de campanha (EN5, aguarda lista) · DKIM Workspace/DMARC raiz (TI da SEED) · EM14 provisória. Delta no `CHECKPOINT_v1_5_fase4_email.md`; vigente no `ESTADO_ATUAL_SeedDS.md` v1.5. **Próximo: escolha de fase do Rafael (F5 dataviz — recomendada; o alerta de geração já reservou o slot de gráfico · F6 patterns · F8).** |
| 1.7 | 2026-08-07 | **MARCO v1.4 — A FASE 3 FECHA: 7 DE 7 BLOCOS.** Com a promoção do §45 Iconografia (`seed-componentes.md` v0.47), a camada de componentes do SEED Design System v2 está completa: **44 componentes + 2 patterns (`§33` Central de Notificações e `§39` command palette ⌘K), todos `estável`.** **O arco dos 7 blocos, para quem lê isto sem ter visto nada:** *(1) Botões* fundou o vocabulário e, junto com a primeira crítica visual do Rafael, fundou o **método de qualidade** que governou tudo o que veio depois. *(2) Formulários* entregou 13 itens e as regras transversais que nenhum bloco seguinte precisou reabrir — protocolo de live region (§1.13), registry de máscaras BR, `aria-invalid` explícito, paridade mobile como premissa estrutural. *(3) Feedback e status* trouxe a taxonomia de severidade em PT-BR e a **Régua de Espera** com seus 3 regimes compostos, e foi onde nasceu a lição que se provou permanente: *a suite valida comportamento; geometria e percepção são território do gate humano.* *(4) Superfícies* fechou a régua de 3 degraus (tooltip → popover → modal) e formalizou a escala de sobreposição 60<65<70<75<80 depois de um bug real de empilhamento pego no gate. *(5) Navegação* foi o bloco de virada: nasceu a **camada de render em Chrome headless**, foi autorizado o **modo lote autônomo**, e as duas erratas do gate viraram régua permanente (*o wizard sempre termina em ação terminal nomeada*; *token consumido sem definição é bug de build*), cada uma com detector nas duas camadas. *(6) Dados* — tabela, seleção, toolbar, degradação responsiva e o guia de integração — encerrou as 3 pendências herdadas do Bloco 2 e foi o **primeiro bloco cujos dois gates humanos passaram sem errata**, porque os detectores criados no Bloco 5 pegaram as reincidências sozinhos. *(7) Iconografia* fecha o arco pelo começo: normalizou o acervo herdado do HTML v1 numa régua única (28 glifos ativos), fechou por desenho os gaps dos pilares Subestações MT e SPDA (`transformer`, `lightning-rod`) e amarrou o set ao consumo real da stack via NM4 (SEED × Lucide). **MAS O FATO DE MÉTODO DESTE MARCO NÃO É A ICONOGRAFIA — É UM DEFEITO DE PROPAGAÇÃO NO BLOCO 5.** Em 2026-08-06 22:54 o `seed-navegacao-preview.html` **v0.40** foi sobrescrito no repositório do Drive por uma cópia de trabalho defasada, a **v0.37**. Passou despercebido porque a propagação era *afirmada* e nunca *lida de volta*. Consequências medidas: a suite de navegação rodou **58/58 em vez de 90** (verde, e errada) e a `suite-render` **abortou** no bloco R8 com `TypeError` procurando `#cp-dialog`. Uma conferência por **tamanho de arquivo** aprovou **21 de 21 arquivos** enquanto um era a versão errada. O v0.40 sobreviveu **por acaso**, na pasta de downloads dos cards de entrega, e foi resgatado de lá. **Dois artefatos de validação foram perdidos em definitivo e RECONSTRUÍDOS a partir da spec** (`suite-navegacao.mjs` de 90 testes e `contraste-navegacao.py`) — e o placar que eles produzem é declarado em todos os documentos como **evidência NOVA de 2026-08-07**, não como o "90/90" histórico do marco v1.2, que não é reproduzível. **Mudanças estruturais que ficam:** (a) nasce **`validacao/MANIFESTO.md`** — âncora por **MD5** de todo artefato canônico (nome · versão · bytes · hash · consumidor · placar) e a **REGRA DE PROPAGAÇÃO: todo artefato salvo é verificado por LEITURA DE VOLTA, nunca por afirmação de que foi salvo**; (b) **o conector do Google Drive deixa de ser transporte de artefato de regressão** — base64 reemitido corrompeu silenciosamente 3 vezes num único arquivo (um byte extra, duas trocas de caractere Unicode); anexo em zip vira o padrão; (c) **ERRATA-NAV-01** — os guardas `TB-24`/`MN-25` ("nenhum botão morto") desconheciam os 12 botões de 5C/5D/5E; a lista de exclusão foi estendida **sem enfraquecer o guarda**, porque cada um dos 12 ganhou teste de liveness dedicado; (d) correção de documentação: a `suite-render.mjs` consome **cinco** previews, não quatro. **Validação do marco, ancorada por MD5 e não por tamanho: 445 verdes jsdom + 43 verificações render / 0 achados + 4 scripts de contraste no gate WCAG.** Gate visual do Rafael aprovado em 2026-08-07. Delta no `CHECKPOINT_v1_4_bloco7_iconografia.md`; vigente no `ESTADO_ATUAL_SeedDS.md` v1.4. **Próximo: a F3 está fechada — a fase seguinte é escolha do Rafael (F4 e-mail · F5 dataviz · F6 patterns · F8 publicação/GEO).** |
| 1.6 | 2026-08-06 | **Marco v1.3 fechado — Bloco 6 (Dados) completo 5/5** (`seed-componentes.md` v0.45; 43 componentes + patterns CN/⌘K). Produzido em 2 lotes do modo autônomo (6A+6B · 6C+6D+6E). **Fato novo do marco: os dois gates humanos passaram SEM errata — primeira vez na F3** — a camada render pegou os 2 bugs reais do bloco (sticky×border-collapse, guarda DT-13; piso da densidade compacta) ANTES do gate, e os detectores do v1.2 (token fantasma NV, whitelists) pegaram as reincidências sozinhos. Pendências históricas encerradas: indeterminate (B2→SL2) · busca composta EUI (B2→TD1) · densidade ERP→mobile (B2→DT2/LD2). Coerência org: skill `seed-ds-ui` lida no GI — cadeia de tokens formalizada (GI1) + pendência de alinhamento da skill registrada (GI2). Validação: 420 jsdom + 38 render. Delta no `CHECKPOINT_v1_3_bloco6.md`; vigente no `ESTADO_ATUAL_SeedDS.md` v1.3. Próximo: **Bloco 7 (Iconografia) fecha a Fase 3.** |
| 1.5 | 2026-08-06 | **Marco v1.2 fechado — DUPLO: CN §33 + Bloco 5 (Navegação) completo 6/6** (`seed-componentes.md` v0.41; 38 componentes + pattern CN estáveis). Trajetória v0.33→v0.41 num único dia. **Mudanças estruturais do marco:** (a) **modo lote autônomo autorizado** — produção contínua de sub-blocos com parada só em ponto de decisão genuíno; interação do Rafael comprimida a 3 momentos por lote; piloto 5C+5D+5E validado (2 erratas de gate, ambas com detector permanente); (b) **camada de validação NOVA: `suite-render.mjs`** (Chrome headless real no ambiente) — geometria, recorte de foco, alvos de toque, overflow 360, empilhamento por pixel, tokens fantasma e screenshots automáticos; auditoria retroativa dos 4 previews gerou os canônicos v0.23b/v0.32b (2 erratas reais de implementação, classe da v0.13); (c) réguas permanentes novas: menu aberto nunca sobrevive à saída do foco · anel de foco interno em container com overflow · wizard termina em ação terminal nomeada · token consumido sem definição = bug de build (detectores nas 2 camadas). Pendências encerradas: AC5, fronteira do §20, promessa do §4.11, DW1. Validação acumulada: **381 verdes jsdom + 32 verificações render**. Delta no `CHECKPOINT_v1_2_cn_bloco5.md`; vigente no `ESTADO_ATUAL_SeedDS.md` v1.2. Próximo: Bloco 6 (Dados — tabela, marco próprio). |
| 1.4 | 2026-08-05 | **Marco v1.1 fechado — Bloco 4 (Superfícies) completo 7/7** (`seed-componentes.md` v0.32; preview v0.32; suite F 80 testes; 246 verdes acumulados). Régua de 3 degraus fechada (§23.1→§30); escala de sobreposição formalizada; drawer §31 destrava a spec da CN (F6) — backlog promovido a alta. 2 ciclos de crítica no gate visual (empilhamento H; +N/light-dismiss I) com emendas formais e testes-guarda. Delta completo no `CHECKPOINT_v1_1_bloco4_superficies.md` (Drive/marcos); vigente no `ESTADO_ATUAL_SeedDS.md` v1.1. Próximo (v1.2 duplo, escolha do Rafael): spec da CN primeiro, Bloco 5 na sequência. |
| 1.3 | 2026-08-04 | **Bloco 3 (Feedback e status) fechado: 11/11 estáveis** em `seed-componentes.md` v0.24 (trajetória v0.15→v0.24 num único dia; 5 sub-blocos com 3 rodadas encadeadas cada + verificações primárias GOV.UK/Material; 166 testes de suite + ~40 pares medidos; 4 ciclos de crítica visual → emendas R3-b/R3-c/X6-b/botão-morto; nota 1.13-b). **Adotado o padrão delta de fechamento: marco v1.0** (CHECKPOINT_v1_0 + ESTADO_ATUAL_SeedDS criados). **Central de notificações decidida (CN1–CN4)** e registrada no F6 com dependência do drawer (B4). Suites de validação viram artefato em `/validacao`. Pendência nova: errata de rótulo no `seed-tokens.md` §5 (azul-700→azul-800 no par 5.79) a corrigir quando o arquivo for editado. Pontas encaminhadas: stepper→B5 (nota na linha), skeleton/empty de dataviz→F5, telemetria do delay de 1s→F4. *(Correção de sincronização em 2026-08-04: cabeçalho e tabela de canônicos desta versão haviam ficado com os valores da v1.2 — data/versão, linha do `seed-componentes.md` e linha deste arquivo atualizados; nenhuma mudança de conteúdo.)* |
| 1.2 | 2026-08-03 | **Bloco 2 (Formulários) fechado: 13/13 estáveis** em `seed-componentes.md` v0.24. Trajetória: v0.6–v0.12 (specs dos 13 itens em 3+ rodadas encadeadas cada, decisões B1–B6, C1–C5, D1–D9, E1–E9, F1–F6, G1–G7, H1–H8, I1–I6, J1–J6, K1–K6, L1–L6, M1–M6, N1–N7) → v0.13 (errata da validação executada: 5 bugs de implementação corrigidos + emenda D4-b + regra do `aria-invalid` explícito + nota L1-b) → v0.14 (promoção dos §8–§14 após validação do Rafael em 2026-08-03). Registrados: paridade mobile como premissa estrutural, ⌘K/command palette como pattern do Bloco 5/6, pendências do Bloco 6 (densidade ERP→mobile, busca composta EUI, indeterminate), rich-text como componente futuro (F6), 7º teste (polegar) e a prática de validação executada no método. Tokens: F1 atualizada para v1.2 entregue (pacote mobile) e escalas de dataviz renumeradas para v1.3. Errata aberta nova: referência morta no `sobreaseed.md`. |
| 1.1 | 2026-07-31 | Bloco 1 (Botão) aprovado em v0.5 após 5 iterações dirigidas por crítica: escada de mecanismos medida (containers 1.07→≥3:1), estado selected com sinais visuais M3, correção do dark (pares de componente), método dos 6 testes formalizado. |
| 1.0 | 2026-07-31 | Criação, após auditoria de inventário (checklists da indústria + colateral corporativo) que expandiu o escopo de ~55 para ~95 itens: F3 de 4→7 blocos, adições em F4–F8, exclusões deliberadas formalizadas. |