# SEED Design System v2 — Composição de tela · `seed-composicao.md`

> **Versão:** v2.1 · **Data:** 2026-08-16 · **Estado:** **`estável` — TODAS as decisões, incluindo CP25–CP31.** Promoção autorizada pelo Rafael em 2026-08-16 ("aprovo") após o gate visual sobre as SEIS telas do projeto (`tela-shell`, `tela-referencia`, `tela-tabela`, `tela-lista`, `tela-chat`, `tela-detalhe`). O gate encontrou dois defeitos reais que as cinco camadas automatizadas não pegaram — a lista de fundo acompanhando a navegação dentro do modal e a topbar sem degrau por contêiner —, ambos consertados e transformados em guarda permanente antes da promoção. Entra nesta edição, junto, a **LEI DE ESCALA DE FIGURA** (§7c), que existia como guarda (`suite-escala-figura.mjs`, 87 · 0) e não existia como lei escrita: a dívida A-P2 aberta na v8.4 do MANIFESTO fecha aqui, pela via declarada — *entra no canônico na promoção* — gate visual do Rafael
> aprovado em 2026-08-14 sobre o `seed-composicao-preview.html` v0.1 (cinco vereditos, G1–G5,
> registrados no §11), após camada de render em Chrome real (10 verificações · 0 achados:
> marcador invariante entre temas conferido em cor renderizada, calha medida em 12px, anel na
> sombra com border 0, zero overflow a 360px, console limpo).
>
> **12º canônico do sistema.** Vive na raiz de `Design System v2/` no Google Drive, ancorado
> por MD5 no `validacao/MANIFESTO.md`. Nasceu da Fase 2 do trabalho de composição de tela,
> sobre os insumos do `confronto-referencias-ds.md` v1.0 (Fase 1, aprovada em 2026-08-14).
>
> **Papel deste arquivo:** ele é dono das **regras de montagem de tela** — a camada que faltava
> entre "componente" e "página". Referencia componentes (`seed-componentes.md`), tokens
> (`seed-tokens.md`) e marca (`marca-seed.md`) **sem nunca duplicar valores** — a mesma relação
> que o `seed-dataviz.md` tem com a camada de tokens (DF7: *"uma fonte, referência sem
> duplicação"*). Onde este arquivo cita um número de contraste, o número foi **medido nesta
> edição** contra os hex do `seed-tokens.css` v1.9 (fórmula WCAG 2.1 de luminância relativa),
> ou vem citado com a fonte.

---

## 0. Para quem nunca viu este projeto

A **SEED engenharia** é uma empresa de engenharia elétrica (MG, ES e BA — solar fotovoltaica,
subestações de média tensão, grupos geradores, projetos e consultoria). O **SEED Design System
v2** ("o DS") é o sistema de design canônico de todos os produtos da empresa: ERP, site
institucional, aplicativos, e-mail, documentos técnicos e material físico. Três camadas:
**primitivos** (hex, pixel) → **semânticos** (papel: `surface-raised`, `text-primary`) →
**componentes** (botão, tabela, painel).

Até esta fase, o DS tinha **componentes** (§1–§45 do `seed-componentes.md`) e **patterns de
página** (§46 Shell, §47 Página institucional, §48 Painel). O que não tinha era o **contrato de
montagem**: como as peças de uma aplicação se dispõem umas em relação às outras — quem é fundo,
quem é peça, qual folga, o que encosta na borda. A ausência foi medida duas vezes (gate do
Rafael de 2026-08-14 sobre o shell: *"blocos colados"*; e o §48 declarando superfície por
arquétipo de forma dispersa, sem lei que ligue). **Este arquivo é essa camada.**

**Premissas estruturais herdadas, que valem em toda linha abaixo:** paridade mobile total (pior
caso de teste **360px** — todo arquétipo declara o comportamento abaixo de 600px ou está
incompleto) · dataviz e densidade de dados como prioridade de primeira classe · paleta 2018 e
logo intactos · nenhum token novo sem medição · supersede formal obrigatório.

**Vocabulário mínimo:** *canvas* = o fundo sobre o qual as peças pousam · *peça* = o cartão que
carrega conteúdo · *calha* = a folga entre peças · *degrau/stop* = posição numa rampa tonal ·
*gate visual* = o Rafael abrindo o artefato num browser real, camada que nenhuma suíte
substitui.

---

## 1. A lei de origem — CP1 (o SH16 vira lei · executa o SUP-1 do confronto)

> **CP1 — CONTRATO DE MONTAGEM DE TELA: A TELA É UM CANVAS COM PEÇAS SOBRE ELE.**
> A tela é um **canvas**, não um fundo branco: `surface-subtle`. Toda peça é
> `surface-raised`, com **`radius-lg`** e separação do canvas pelo **par sombra+anel**
> (CP17 — o anel de 1px vive na declaração de sombra, na tinta do papel `border-subtle`),
> e **flutua sobre o canvas com calha `sp-3`**. **Nada encosta em nada.** Exceções são
> **nomeadas por arquétipo** (§3) — nunca implícitas.

**Origem (fato, gate do Rafael em 2026-08-14):** *"no ClickUp cada caixa é montada
separadamente na tela; da forma que você apresentou são blocos colados."* Medido nas capturas:
varredura vertical no ClickUp dá card branco → borda 1px `#E4E4E4` → **14 a 15px** de canvas
`#F9F9F9` → borda do card seguinte. No nosso shell da época, a varredura horizontal dava
`#006C62` → `#FFFFFF` **em um pixel**. Nenhum token novo — é consumo: `surface-subtle` é o
canvas, `surface-raised` a peça, `radius-lg` o raio, `sp-3` a calha.

**A primeira exceção nomeada, herdada do SH16 original:** **âncoras de navegação** (o rail)
encostam na borda da janela e vão de topo a base, sem raio externo — são âncora, não peça
sobre o canvas. É assim na referência medida.

> **⛔ SUPERSEDE DESTA EXCEÇÃO (gate visual do Rafael, 2026-08-15, sobre o preview v0.3 do
> shell):** *"a barra esquerda não seria com cantos arredondados? a apresentação dela seria de
> forma descolada, como uma barra flutuante, um bloco montado como os outros — todos
> independentes, igual o ClickUp usa."* **A exceção morre: o rail é PEÇA sobre o canvas como as
> demais** — `radius-lg`, calha `sp-3` nos quatro lados, flutuante. O CP1 fica SEM exceções
> nomeadas por ora ("exceções são nomeadas por arquétipo" permanece como mecanismo). Fato vs.
> inferência, declarado: a redação original dizia "é assim na referência medida" com base na
> varredura das capturas; o veredito do gate diz que a apresentação do ClickUp é de blocos
> independentes — **o gate do Rafael é a instância que decide marca e apresentação, e o
> supersede vale pelo veredito, não por re-medição**. Diferença de mecanismo declarada com o
> número: o rail-peça NÃO leva o anel/borda das peças brancas — as brancas precisam do 1px
> porque medem **1,21** contra o canvas; o gradiente do rail mede **5,82/8,62** (claro) e
> **2,70/1,82** (escuro) contra o canvas — a própria cor é a fronteira, e um traço claro sobre
> superfície escura seria ruído. Executado no shell no preview **v0.4** (MANIFESTO v7.1), onde
> a mudança também expôs e corrigiu um defeito latente: a barra branca do item ativo desenhava
> **fora do box do rail** desde o SH15-b (probe de pixel: x=-3 com o box em x=0; `overflow`
> clipa o eixo x junto) — corrigida para a borda interna e provada em cor renderizada
> (`rgb(255,255,255)` no pixel).

**Proveniência e supersede (SUP-1 do confronto, executado aqui):** o texto do SH16 vivia em
comentário CSS de três artefatos (`seed-shell-preview.html` l.136–153, `validacao/gen-shell.py`,
`validacao/shell-template.html`) e no MANIFESTO v6.5, ausente de todo canônico de lei (errata
E-CF-01 do confronto). Passa a ser lei **aqui**, com o §46 do `seed-componentes.md` v0.65
referenciando. *Alternativa descartada:* mantê-lo como SH16 dentro do §46 — o contrato não é
regra do shell, é regra do sistema; o shell é apenas onde ele foi descoberto, e mantê-lo lá
garantiria que o site e o e-mail nunca o encontrassem.

**Uma palavra da redação original morre aqui (supersede interno, motivado por medição):** o
SH16 dizia *"borda `border-subtle` de 1px"*. A separação passa a ser o **par sombra+anel**
(CP17). O 1px e a tinta são os mesmos — muda o **mecanismo**: o anel entra na declaração de
sombra (`0 0 0 1px`) e o slot `border` fica livre para estado. Motivo medido nesta edição:
`border-subtle` `#E3EBF0` mede **1,11** contra o canvas `surface-subtle` `#F2F6F9` e **1,21**
contra a peça branca — **a borda sozinha nunca foi a separação**; quem separa é o par. É o
mesmo achado do C15-c do ClickUp (borda a 1,23, visível só por causa da sombra) e é o que o
PN21a já fazia dentro do painel.

---

## 2. Vocabulário mínimo de blocos — CP2

> **CP2 — SETE TIPOS DE BLOCO. Toda tela da SEED se monta a partir deles; um elemento que
> não é nenhum dos sete não existe no contrato e é drift por definição.**
>
> **⚠ SUPERSEDE do CP2 v1.x ("SEIS TIPOS") — decisão do Rafael em 2026-08-15 (F7.1, consolidado
> aprovado com "aprovo").** O fechamento em seis foi verificado contra o que existia então: os
> três estudos, os três patterns e os 45 componentes. O **mapa de cobertura** (`mapa-cobertura-ds.md`
> v0.3) confrontou o vocabulário contra os arquétipos que o DS ainda **não** tinha — e três
> estruturas não se descreviam com os seis. Duas viram exceção nomeada (abaixo do quadro) e uma
> exigiu tipo novo: a **trilha**. *Fato vs. inferência declarado:* o racional original não estava
> errado para o escopo medido; ficou incompleto quando o escopo cresceu (D5: o DS serve qualquer
> produto SEED — site, app, ERP, chat —, não só o ERP).

| Tipo | Definição | O que admite dentro | O que ele NUNCA é |
|---|---|---|---|
| **Canvas** | O fundo da tela ou de uma região. `surface-subtle` por padrão; variantes nomeadas por arquétipo (leitura = `surface-page` sem peça; mapa = superfície de terceiro) | Peças, réguas e faixas pousam sobre ele. Canvas de ferramenta livre pode levar fundo pontilhado (§3, arquétipo vazio) | Acionável ou selecionável — *"sempre que o contêiner for acionável, ele precisa ser a superfície, não o fundo"* (C33, custo declarado) |
| **Peça** | O cartão que carrega conteúdo: bloco do painel, cartão de formulário, a tabela inteira (não a linha), o cartão de solução do site | Componentes dos §1–§45 e blocos de dado do DG/DM/DP. Peça compõe-se de componentes; nunca de outra peça (peça dentro de peça é o agrupador do feed — exceção nomeada C33) | Colada em outra peça (CP1) ou na borda da janela (exceto arquétipos com exceção nomeada) |
| **Âncora de navegação** | Chrome estrutural que ancora a tela: rail, topbar. Encosta na borda, atravessa a dimensão inteira, sem raio externo | Itens de navegação (SH3), zonas da topbar (SH10) | Peça sobre o canvas · portadora de conteúdo (o título da tela vive no conteúdo — SH10) |
| **Régua** | Elemento fino que mede ou situa: régua de tempo (PN48), cabeçalho fixo de tabela (DT6), barra de pílulas/toolbar (§42), trilha (§36) | Rótulos, pílulas, contadores | Decorativa — régua que não mede o que a faixa desenha é o defeito do PN48 pré-correção |
| **Faixa** | Seção horizontal full-bleed que empilha verticalmente: as faixas da página institucional (§47), o hero (MK13/PN21c), a faixa de modelos do hub | Conteúdo em coluna central; uma faixa pode conter peças | Sobreposta a outra faixa · aninhada |
| **Trilha** *(tipo novo — F1/2026-08-15)* | **Agrupador vertical transparente**: a coluna do quadro/Kanban, a raia do gantt, a faixa de pessoa da carga de trabalho. Não tem superfície própria — nem fundo, nem raio, nem separação; o que se vê são as PEÇAS dentro dela e o rótulo com contador (C26) no topo | Peças (cartões) empilhadas com calha declarada pelo arquétipo; cabeçalho com rótulo + contador; alvo de soltura (CP30) | **Peça** — trilha não se separa do canvas porque não é superfície; chamar de peça esvaziaria a definição de peça · **Canvas** — não é fundo de tela, é agrupador dentro dele · Portadora de fundo cromático (o croma vem das peças, CP19) |
| **Sobreposição** | O que flutua acima da tela na escala 60<65<70<75<80 (§31.2): modal, drawer, toast, popover, tooltip | O que a spec de cada um admite (MD5: nenhum componente nasce dentro do modal) | Empilhada fora da escala · usada como layout permanente |

*Racional do fechamento em sete:* os três estudos de referência, os patterns nossos e os 45
componentes se descreviam com seis; o **mapa de cobertura** acrescentou os arquétipos ausentes
(quadro/Kanban, carga, chat, busca, configurações, autenticação, documento, feed) e só a coluna
de agrupamento vertical exigiu tipo novo. *Alternativa descartada:* vocabulário aberto ("cada
arquétipo nomeia os seus") — reproduziria a dispersão que esta fase existe para matar.
*Alternativa descartada para a trilha:* declará-la exceção dentro de "peça" — rejeitada porque
peça é definida por SE SEPARAR do canvas, e a trilha não se separa de nada.

**As DUAS exceções nomeadas do CP2, escritas — exceção não declarada vira suposição de alguém
depois:**

> **CP2-a — CANVAS INTERATIVO.** O quadro do CP2 diz que canvas *nunca* é acionável. Há um caso
> em que é: **canvas de ferramenta livre** (mapa operável, área de desenho), onde clicar/arrastar
> no fundo É a interação. Condições, todas obrigatórias: (1) o canvas declara papel e nome
> acessível; (2) toda ação disponível por clique no fundo tem **caminho equivalente por teclado e
> por ponteiro único** (CP30); (3) o fundo não carrega informação que só a cor transmita.
> *Fato que motiva:* o mapa já vive assim no §48 (PN51–PN54) sem regra escrita — a exceção
> existia na prática e não no contrato, que é a definição de drift.

> **CP2-b — SUPERFÍCIE INVERTIDA (C33).** O padrão é peça clara sobre canvas mais escuro. No
> **feed/atividade** a hierarquia inverte: o agrupador consome `surface-sunken` e os itens
> internos são as peças claras. **Condição de admissão, medida:** a inversão só vale quando o
> **item é acionável e o agrupador NÃO é** — *"sempre que o contêiner for acionável ou
> selecionável"*, volta o caso base (C33). O agrupador invertido **não leva sombra**: o delta de
> superfície agrupa, não separa.

---

## 3. Contrato de montagem por arquétipo — CP3 a CP12

> **CP3 — O CONTRATO É DECLARADO POR ARQUÉTIPO, NÃO UMA VEZ NO NÍVEL DO SISTEMA.**
> Fato que motiva (confronto §2-e): nossa superfície era declarada uma vez, indexada por
> classe de componente (`seed-tokens.md` §2.6/§2.8 — chip, card, modal), e o ClickUp, medido
> em nove arquétipos, usa **sete raios e cinco tratamentos de elevação** variando por tela:
> *"impossível de derivar de um token só (…) o contrato precisa ser declarado por arquétipo."*
> O CP1 é o **caso base**; cada linha abaixo declara onde ele vale integral e onde a exceção
> é nomeada. **Arquétipo sem a coluna `<600px` preenchida está incompleto por definição.**

**Cobertura da tabela — o número, e a correção de um erro meu.** A v2.0 leva a tabela de **11
para 23 gabaritos**. O `mapa-cobertura-ds.md` v0.1 afirmou que a tabela tinha "6 linhas
preenchidas": **está errado, e a correção fica registrada aqui** — a contagem veio de leitura
parcial da seção, não de contagem. O que era verdade é a conclusão: faltavam gabaritos, e os que
faltavam eram justamente os arquétipos que o DS nunca escreveu. Os dois ausentes que
permanecem — whiteboard e mapa mental — estão **fora do escopo por decisão** (D5, 2026-08-15).

| Arquétipo | Canvas | Peça | Raio | Separação | Calha | Encosta na borda | **<600px** |
|---|---|---|---|---|---|---|---|
| **Shell** (§46) | `surface-subtle` | região de conteúdo | `radius-lg` | par sombra+anel (CP17) | `sp-3` | **rail e topbar** (âncoras, exceção nomeada do CP1) | rail+sidebar → **drawer modal único** (SH12); topbar permanece |
| **Painel — visão geral** (§48) | o canvas do shell | bloco da grade PN1 (larguras 4/6/8/12) | `radius-lg` | PN21a (sombra premium: duas difusas + anel 1px) | `sp-3` (herda CP1) | nada | grade → **1 coluna**; lentes mantêm régua de dois níveis com px derivado da largura (PN41d, funciona *"em 1180px e em 390px"*) |
| **Lista/tabela** (§40–§43) | `surface-subtle` | **a tabela inteira** (toolbar §42 + tabela §40 + paginação, num cartão) — a **linha** é conteúdo interno: raio 0, calha 0, separação por borda de linha | `radius-lg` no cartão | par sombra+anel no cartão; borda de linha dentro | `sp-3` entre cartão e vizinhos | nada | wrapper de rolagem (fallback universal LD2-a) ou **modo cards opt-in** (LD2-b, colunas `low` somem — LD3); densidade trava ≥44px (DT2); toolbar empilha (TD1) |
| **Formulário** (Bloco 2) | `surface-subtle` | **um** cartão de formulário, coluna única | `radius-lg` | par sombra+anel | `sp-3` | nada | CTA de fluxo **full-width** (§1.4); campos a 16px em `pointer: coarse` (§0.8) |
| **Detalhe de registro** *(contrato aqui; conteúdo é o §49, pendência PN-P3)* | a tela de origem, sob véu | **três vestes por tarefa**: modal §30 (tarefa curta/confirmação) · drawer standard §31/SH13 (inspecionar sem sair da lista) · página cheia (edição longa — vira arquétipo formulário) | `radius-xl` no modal (§30.2 usa 12 herdando card; xl quando o conteúdo tem 3 zonas — decisão de gate) | `shadow-overlay`; backdrop **decorativo declarado** (MD3) | margem mínima `sp-6` do modal à janela | nada | modal de tarefa → **tela cheia** (MD4); drawer → **largura total** (DW2); confirmações seguem centradas |
| **Hub** *(novo — C18, adotado como TEMPLATE, ver CP14)* | `surface-subtle` | cartões da faixa de modelos (card §26) + o cartão-coleção (arquétipo lista) | `radius-lg` | par sombra+anel | `sp-3` | nada | faixa de modelos vira rolagem horizontal com fade; coleção segue o arquétipo lista |
| **Documento/leitura** *(exceção nomeada — C25)* | **`surface-page`, SEM peça**: canvas chapado, sem raio, sem anel, sem sombra | não há — o texto pousa direto | — | — | — | o canvas É a tela | coluna única nata; medida de linha vale igual |
| **Página institucional** (§47) | a própria página (branca) — **faixas**, não peças soltas | blocos MK13–MK22 como faixas full-bleed com conteúdo em coluna central; cards de solução (MK16) são peças dentro da faixa | `radius-lg` nos cards | par sombra+anel nos cards | `sp-3` dentro da faixa | as faixas (full-bleed por natureza) | nasce mobile-first (decisão de escopo do §47); zoom NUNCA bloqueado (MK4); orçamento de peso MK12 |
| **Feed/timeline** *(exceção nomeada — C33 → PN20)* | `surface-subtle` | **hierarquia INVERTIDA**: o agrupador de período consome `surface-sunken` (mais escuro) e os **eventos internos** são as peças claras | `radius-lg` no agrupador | agrupador **sem sombra** (o delta de superfície agrupa; *"funciona como agrupamento periférico, não como separação"* — C33) | `sp-2` entre eventos dentro do grupo | nada | empilha 1 coluna; datas em mono permanecem (PN20) |
| **Mapa** *(exceção nomeada — canvas de terceiro)* | **a superfície do mapa** (modo cobertura = malha IBGE do §4d; modo operação = tiles PN51) | cartões flutuantes sobre o mapa **SEM SOMBRA** — *"cartão branco sobre mapa colorido não precisa de sombra; o contraste de conteúdo já separa"* (fato medido, confronto §4.25-iv, validando o §2.8: elevação é par, e aqui o par não é necessário) | `radius-lg` | anel 1px apenas | `sp-3` da borda do mapa | o mapa (edge-to-edge por natureza) | alternativa textual É conteúdo, sempre presente (PN54); fallback declarado (PN53) |
| **Quadro/Kanban** *(gabarito novo — F7.1)* | o canvas do shell (`surface-subtle`) | **só o cartão** é peça; a coluna é **TRILHA** (transparente, sem raio, sem fundo) com cabeçalho de rótulo + contador (C26) | `radius-lg` no cartão; **zero** na trilha | par sombra+anel no cartão; a trilha **não se separa** | `sp-2` vertical entre cartões · `sp-3` entre trilhas | nada | trilhas viram **rolagem horizontal com snap**, uma visível por vez; alternativa sem arraste obrigatória (CP30) |
| **Calendário** *(gabarito novo — F7.1)* | o canvas do shell | a **grade** é régua (mede tempo); o **bloco de evento** é peça mínima | `radius-md` no evento | evento **sem sombra**: separação por `outline` na cor do canvas (a referência usa branco — MEDIDO) | **zero** entre eventos (encostados por natureza: tempo é contínuo) | a grade | mês → **agenda em lista** (o mês não colapsa: vira outro arquétipo) |
| **Gantt / linha do tempo** *(gabarito novo — F7.1)* | canvas dividido em **dois painéis** (lista à esquerda, faixa à direita) unidos por **relação de split** (CP29) | a **barra** é peça mínima; a **raia por responsável** é TRILHA; a régua de tempo é régua (PN48, dois níveis) | `radius-md` na barra | barra sem sombra; anel 1px de baixa opacidade | zero na faixa; `sp-2` entre raias | a régua (fixa no topo) | painel de lista **colapsa primeiro**; a faixa mantém a régua de dois níveis (PN41d); dependências viram lista textual |
| **Carga de trabalho / capacidade** *(gabarito novo — F7.1)* | o canvas do shell | a **faixa de pessoa** é TRILHA; a **célula de capacidade** é peça mínima | `radius-md` na célula | célula com anel 1px; sem sombra | zero entre células (matriz é contínua) | a régua de período | matriz **não reflui** (exceção de 1.4.10: layout bidimensional necessário — CP28); rolagem em dois eixos declarada |
| **Equipe / diretório de pessoas** *(gabarito novo — F7.1)* | o canvas do shell | **cartão por pessoa** | `radius-lg` | par sombra+anel | `sp-3` uniforme | nada | grade → 1 coluna; o dado de capacidade dentro do cartão vira linha |
| **Busca / resultados** *(gabarito novo — F7.1)* | `surface-subtle` | a **lista de resultados inteira** é peça (herda o arquétipo lista); os **filtros** são régua | `radius-lg` na peça | par sombra+anel | `sp-3` | nada | filtros viram gaveta; resultado com **realce do termo** permanece (nunca só cor) |
| **Configurações / preferências** *(gabarito novo — F7.1)* | `surface-subtle` | **navegação lateral de seções** (peça) + **cartão por grupo de opções** (peça) | `radius-lg` | par sombra+anel | `sp-3` | nada | lateral vira **abas** ou lista de entrada → detalhe (nunca some) |
| **Autenticação** *(gabarito novo — F7.1)* | `surface-page` ou faixa de marca (âncora cromática CP19 permitida aqui) | **um** cartão centrado, coluna única, largura máxima 420px | `radius-lg` | par sombra+anel | `sp-6` da borda | nada | cartão vira **largura total** com calha mínima; nada de rolagem horizontal |
| **Onboarding / primeiro uso** *(gabarito novo — F7.1)* | herda o canvas do arquétipo que ainda não tem dado | o vazio de **primeiro-uso** (§25/Z1) ocupando o slot da peça ausente | herda o slot | herda o slot | herda o slot | nada | ilustração colapsa antes do texto (§25.4-7) |
| **Chat / mensageria** *(gabarito novo — F7.1 · escopo D5: app próprio, fora do ERP)* | `surface-subtle`; a **lista de conversas** é peça irmã do painel de mensagens, unidas por relação de split (CP29) | a **mensagem** é peça mínima; o **agrupador por dia** é TRILHA horizontal com rótulo centrado | `radius-lg` na mensagem, com **um canto reduzido** no lado do autor (assinatura de direção) | mensagem própria: superfície de marca; mensagem alheia: `surface-raised` com anel — nunca sombra (volume de peças é alto: sombra multiplicada vira ruído, lição CD1) | `sp-2` entre mensagens do mesmo autor · `sp-4` entre blocos de autor | o campo de composição (encosta na base) | lista de conversas → **tela anterior** (padrão lista→detalhe); o campo de composição NUNCA colapsa |
| **Impresso / PDF** *(gabarito já `estável` — DI, §4c do dataviz; entra na tabela por completude)* | a folha (modo claro forçado) | o bloco de conteúdo, **atômico** (`break-inside: avoid`) | herda a tela | **borda física 1px**; sombra e gradiente **proibidos** (não sobrevivem à impressão — CP20) | margem de folha | a folha | não se aplica (a folha tem largura fixa) |
| **E-mail** *(gabarito já `estável` — `seed-email.md`; entra por completude)* | fundo do cliente de e-mail (fora do nosso controle) | a **tabela-container** de largura fixa (600px), centrada | raio simulado por imagem/borda; **sem** `radius` confiável | borda 1px; **hex literal inline** (cliente de e-mail não tem custom property — EM*) | espaçadores de linha | o container | empilha em coluna única; largura fluida até 600px |
| **Vazio** (§25, agora **seis** tipos — SUP-3 aplicado) | o canvas do arquétipo que esvaziou | o vazio **ocupa o slot da peça que ele substitui** — régua de escala Z3 (linha/tile → card → página); componente de página NUNCA em célula | herda o slot | herda o slot | herda o slot | nada | ilustração colapsa antes do texto (§25.4-7); bifurcação empilha os dois cartões |

**Notas de arquétipo que não cabem na tabela:**

- **Detalhe — por que três vestes e não uma (decisão CP-Q3 do gate):** a régua já existia
  espalhada — MD2 (modal só para decisão obrigatória/tarefa curta), SH13 (drawer standard para
  inspecionar sem perder a lista), DW4 (form longo prefere drawer). O arquétipo a consolida. O
  ClickUp usa **um** modal de `1192×738` para tudo — e o custo é o MD2 invertido: treina fechar
  por reflexo. O **conteúdo** do detalhe (quais zonas, o que mostra) permanece reservado ao §49
  (PN-P3) — este arquivo declara só a montagem. *Alternativa descartada:* esperar o §49 — o
  contrato nasceria furado no arquétipo mais usado do produto de referência.
- **Documento/leitura — a medida de linha entra no contrato:** texto corrido usa o registro de
  leitura já canônico (`marca-seed.md` §4.1: Light/Regular, line-height 1.65) em coluna de
  **largura máxima 660px** — o valor medido na referência (C25), dentro da faixa tipográfica
  clássica de 45–75 caracteres para corpo 16px. O pedido de *"aproveitar a tela"* numa
  viewport larga **deve ser recusado**: medida de linha longa destrói leitura (custo declarado
  do C25). Onde o texto não é para ler linearmente (descrição curta, comentário, célula), o
  registro é o de interface e este arquétipo **não se aplica**.
- **Feed — quando a inversão é errada:** *"sempre que o contêiner for acionável ou
  selecionável"* (C33). Agrupador clicável → volta ao caso base.
- **Vazio — o sexto tipo (bifurcação, C36/SUP-3):** cartões em `radius-xl`, **exatamente duas
  ações, as duas primárias** (exceção declarada à Z2). A ilustração continua `aria-hidden` e a
  descrição de uma frase carrega a diferença entre as opções em texto (resolução Z4/Z5) — sem
  isso, leitor de tela escolhe às cegas. Canvas de ferramenta livre sob a bifurcação pode levar
  o fundo pontilhado do C36 (*"comunica 'isto é um canvas livre'; custa uma linha de CSS"*).
  Quando 90% escolheriam a mesma opção, bifurcar é errado — aplica-se o padrão e oferece-se a
  troca depois.

---

## 4. Como um template se declara — CP13 e CP14

> **CP13 — A GRAMÁTICA DO TEMPLATE.** Um template é a instância nomeada de um arquétipo, e se
> declara com exatamente cinco campos. Um produto novo tem de conseguir montar a tela lendo
> **só** a declaração. **Slot não declarado não existe: peça fora de slot é drift.**

1. **Nome** do template.
2. **Arquétipo base** (§3) — o contrato de montagem vem dele; o template não redeclara raio,
   calha nem separação.
3. **Slots** — cada um com: nome · **tipos de bloco admitidos** (CP2) e componentes/blocos de
   dado aceitos · **obrigatório ou opcional** · **cardinalidade** · **comportamento <600px**.
4. **Exceções nomeadas** ao contrato do arquétipo — se não há, o campo diz "nenhuma".
5. **O que o template NÃO decide** — conteúdo, copy, quais registros existem: fronteira de
   produto, declarada para não virar suposição.

*Precedente interno exato:* o **DG1** do `seed-dataviz.md` — o `<figure>` de cinco partes
(título, descrição, fallback, legenda, área) com obrigatoriedade declarada (*"sem as cinco,
não é gráfico canônico"*) é a primeira declaração de slots do DS, e funciona há três
sub-blocos. O CP13 generaliza o formato. *Alternativa descartada:* template como screenshot
anotado — não é verificável por suíte nem lível por produto.

> **CP14 — O PRIMEIRO TEMPLATE DECLARADO: `hub-de-tipo`** *(adota o C18 do confronto com as
> travas que o próprio estudo exige)*.
>
> **Arquétipo base:** shell + lista/tabela. **Slots:**
>
> | Slot | Bloco/componentes admitidos | Obrig. | Card. | <600px |
> |---|---|---|---|---|
> | Título + ação primária | faixa; `h1` real + botão §1 (máx. 1 primário) | sim | 1 | empilha; botão full-width |
> | Faixa de modelos | faixa; cards §26 com ícone §45 | não | 0–1 | rolagem horizontal com fade |
> | Filtros | régua; toolbar §42 | não | 0–1 | empilha (TD1) |
> | Coleção | peça; tabela §40 **ou** cards LD2 | sim | 1 | regimes LD2 |
> | Vazio | vazio §25, tipo conforme a causa (Z1) | quando a coleção esvazia | 1 | herda §25 |
>
> **Exceções ao arquétipo:** nenhuma. **O template NÃO decide:** quais tipos ganham hub, o
> conteúdo dos modelos, as colunas da coleção.
>
> **As duas travas, obrigatórias porque o estudo mediu o custo de não tê-las:** **(a) a
> dimensão dominante do tipo é coluna obrigatória e declarada por instância** — *"um hub de
> contratos quer valor e vencimento em destaque"*; colunas idênticas para tipos diferentes
> significam que nenhum tipo tem a coluna que importa, e num ERP de engenharia quase todo tipo
> tem dimensão dominante própria. Sem a declaração, o gabarito vira camisa de força e o hub é
> **recusado** para aquele tipo. **(b) Microcópia flexionada por tipo** — o defeito medido do
> ClickUp (*"Marque um Painéis com estrela"*, *"3 pessoa sem tarefas"*) é concatenação de
> fragmento com variável não flexionada; a instância declara gênero e plural do tipo.

---

## 5. Densidade e ordem de colapso — CP15 e CP16

> **CP15 — A ESCADA DE COLAPSO CANÔNICA.** A ordem em que a tela cede, declarada até 360px.
> **Contraexemplo declarado (fato — `estudo-clickup-completo.md` §11.2):** a ordem do ClickUp
> termina em *"nada mais colapsa, tudo comprime"*; o rail de 64px persiste até 560px,
> `(pointer: coarse)` nunca é verdadeiro e o mobile é delegado a app nativo. **Nossa premissa
> é paridade mobile total — o ClickUp aqui é contraexemplo, não referência, e nenhum arquétipo
> nosso pode citá-lo como precedente de responsivo.**

**Princípio da ordem (o que cede primeiro):**
1º **navegação persistente vira sob-demanda** (some da tela, não do produto) →
2º **colunas e metadados de baixa importância somem, por decisão editorial declarada** (nunca
por acidente) →
3º **rótulos migram para junto do dado** (nunca somem) →
4º **densidade afrouxa** (alvos crescem, nunca encolhem).

**A escada, por faixa de viewport:**

| Faixa | O que cede | Fonte |
|---|---|---|
| **≥1024px** | composição plena | — |
| **<1024px** | sidebar contextual: níveis 2+ em flyout | SH4-c |
| **<640px** | rail+sidebar → **drawer modal único** · modal de tarefa → **tela cheia** · popover denso → **tray** · tabela → rolagem do wrapper ou **cards** (colunas `low` somem; rótulos migram via `data-label`) · toolbar **empilha** · densidade trava **≥44px** · CTA de fluxo **full-width** · grade do painel → **1 coluna** | SH12 · MD4 · Y4 · LD2/LD3/LD4 · TD1 · DT2 · §1.4 · PN1 |
| **≤360px** *(pior caso declarado, tokens §2.9)* | tudo acima já aplicado + zoom das lentes se declara em **unidades visíveis com px derivado da largura** (funciona *"em 1180px e em 390px"*) + campos a 16px em `pointer: coarse` | PN41d · §0.8 |

> **CP16 — O QUE NUNCA COLAPSA.** Em qualquer largura até 360px: **a calha** (*"nada encosta
> em nada"* é invariante — a escada remove blocos e afrouxa densidade, nunca remove a folga) ·
> **o alvo de toque ≥44px** · **o fallback textual** (DG1, PN54 — é conteúdo, não enfeite) ·
> **o formulário único** da página de serviço (MK8/MK21) · **o zoom do usuário** (MK4: proibido
> bloquear, sem caso legítimo) · **o caminho alternativo de ponteiro único** (PN23, SC 2.5.7).
> *Racional:* cada item desta lista é uma conformidade ou uma decisão medida; colapsá-los não
> economiza tela — quebra o produto.

**Densidade (quantos blocos):** a grade do painel (PN1: larguras 4/6/8/12) implica **no máximo
três peças por linha**; a **regra do um** (§1.12) vale por tela: um `h1`, um primário por
contexto, **uma âncora de ênfase por página** (§3.5-c/S11-b), um protagonista tipográfico
(CP18). Os tetos quantitativos de massa visual estão no CP21.

**Guarda de método herdada (regra da matriz do DP, mais geral que o DP):** *"simular uma
dimensão só vale se a simulação dirigir as MESMAS regras que a realidade dirige."* Se um
arquétipo adotar container query (C22), a camada de render precisa redimensionar o
**container**, não a janela — senão a suíte vira verde-e-errada, a classe de defeito que
originou o MANIFESTO.

---

## 6. Apresentabilidade como regra de composição — CP17 a CP21

*A conversão de "vida visual vem de render, não de cor isolada" (lei das Fases 5–6) em
contrato verificável.*

> **CP17 — SEPARAÇÃO POR PAR SOMBRA+ANEL (PN21a generalizado) — e o fecho de metade da
> SH-P1.** Toda peça se separa do canvas pelo par: sombra difusa + **anel de 1px na mesma
> declaração** (`0 0 0 1px`, tinta do papel `border-subtle`). O anel é o que separa quando a
> difusa é sutil; **o slot `border` fica livre para estado**.
>
> **Medido nesta edição:** `border-subtle` contra `surface-subtle` = **1,11** · contra a peça
> branca = **1,21**. A borda semântica sozinha **nunca** cumpriu a separação — quem cumpria
> era o par, sem que isso fosse lei (o mesmo mecanismo `elevation-border-N` do ClickUp, cuja
> borda mede 1,23 e *"existe visualmente só por causa do par com a sombra"*).
>
> **Veredito do gate (2026-08-14, G1):** aprovado — os dois mecanismos leram bem ao olho, e a
escolha do Rafael foi o par sombra+anel. **O contrato mantém UM mecanismo só** (par sombra+anel);
a borda semântica sozinha não fica como alternativa — dois mecanismos de separação convivendo
seria reintroduzir a dispersão que este arquivo mata. *(A abertura do Rafael a usar os dois "em
situações diferentes" fica registrada; se um arquétipo futuro precisar do segundo mecanismo, é
exceção nomeada no §3, nunca escolha livre.)*

**Consequência declarada para a pendência SH-P1** (§46.2: nenhum token semântico de borda
> passa 3:1 contra `surface-raised` no claro): a metade "separação de peça" da pendência
> **deixa de existir** — separação não é mais tarefa de borda. Fica aberta a metade original e
> menor: **fronteira de componente interativo** (SC 1.4.11 — o campo de busca), que segue com
> o empréstimo declarado do primitivo `cinza-500` até a camada 2 ser editada por outro motivo
> (regra GI2, pendência PN-P5). *Alternativa descartada:* criar o token de borda agora —
> mexeria nos três gêmeos por causa de um pattern, exatamente o que a SH-P1 já recusou.
>
> **✅ A metade restante FECHOU em 2026-08-14, exatamente pelo gatilho previsto:** a camada 2
> foi editada pela CP-P3 (gêmeos v1.11) e o Rafael mandou fechar na mesma janela — nasce
> `--seed-border-interactive` nos gêmeos **v1.12** (`cinza-500` promovido a semântico, mesmo
> valor renderizado, ≥3,0 medido nas seis superfícies dos dois temas). A SH-P1/PN-P5 está
> **integralmente fechada**: separação de peça pelo CP17, fronteira interativa pelo v1.12.

> **CP18 — UM PROTAGONISTA TIPOGRÁFICO POR PÁGINA.** Toda página declara um protagonista, com
> a amplitude declarada pelo arquétipo — no painel a amplitude hero/micro-rótulo é **6,1×
> medida** (PN21f/PN13); na página institucional o protagonista é o `h1` do hero (MK13); no
> documento, o título da coluna de leitura. Página sem protagonista lê chapada; página com
> dois, disputada. *Fonte: PN21f, generalizado — era a pendência P3/P5 do `estudo-viver-de-ia.md`,
> resolvida "dentro do §48, não generalizada" — generaliza aqui.*

> **CP19 — RITMO NEUTRO↔CROMÁTICO E A ÂNCORA ÚNICA.** A cor vem dos **dados**, não do chrome
> (fato: 67,2% de branco puro medido nas telas do ClickUp, contra 67,7% nas nossas — a
> vitalidade deles não vem de mais cor). As peças alternam massa neutra e acento cromático
> (P4 do estudo Viver de IA), e a página inteira tem **uma** âncora de ênfase (§3.5-c de
> `marca-seed.md`, S11-b: a âncora é **cromática** — `turquesa-400` —, não "escura").

> **CP20 — GRADIENTE: A REGRA E A EXCEÇÃO DE CHROME (executa a condição do SUP-4).** O PN21b
> permanece integral para **superfície de conteúdo**: *véu radial de luz é a única forma de
> gradiente — nunca gradiente de cor*, teto de alfa por substrato (claro ≤ .07 · escuro ≤ .16).
> **Chrome de aplicação é exceção declarada:** o rail admite gradiente linear de cor entre
> **dois degraus adjacentes da rampa da marca**, desde que a tinta passe **nos dois extremos**,
> não na média. **A condição do SUP-4 está satisfeita por medição nesta edição:** branco sobre
> `turquesa-700` `#006C62` = **6,32** · sobre `turquesa-800` `#005048` = **9,37** — os dois
> extremos passam o piso de texto normal (4,5). O gradiente `turquesa-700 → turquesa-800` está
> **ADOTADO** (gate de 2026-08-14, veredito G2: *"gradiente é mais bonito"*) **e EXECUTADO na
> CP-P3, na mesma data:** o rail do shell consome o semântico próprio `--seed-rail-background`
> (gêmeos v1.11), e os overlays de estado do SUP-6 (`--seed-chrome-overlay-hover/-active`) foram
> medidos **em composição** sobre os dois extremos (4,88/6,82 e 4,68/6,50). *(Redação anterior
> deste trecho, superada: "está admitido; a adoção visual no rail é decisão do gate (o rail hoje
> é `turquesa-700` chapado)" — verdadeira quando escrita, falsa após a regeneração.)*
> Custos herdados do C13, vigentes: o gradiente precisa de semântico próprio
> (`--seed-rail-background`), senão o tema escuro vira regra manual (o ClickUp escreveu 22
> regras à mão por não fazer isso); em superfície com scroll o gradiente "anda"; impressão e
> alto contraste o descartam; abaixo de ~200px de altura não é percebido. *Regra viva:
> "gradiente é acabamento de SUPERFÍCIE — jamais em superfície de DADO" (P1).*

> **CP21 — TETOS DE COMPOSIÇÃO (as três medidas do PN-P6 viram lei de composição):** massa
> escura **≤32% da primeira dobra** · hero **≤35% da altura** · a página lê branca
> (**luminância média ≥248**). São decisões declaradas e já exercidas por inspeção no gate do
> painel; **a guarda automatizada segue pendente** (candidata natural a uma sexta camada de
> validação, de composição — dívida de instrumento, não de regra).

---

## 7. Cor em composição — CP22 a CP24 *(decisões de MARCA — **`estável`**, gate visual aprovado em 2026-08-14: G3 e G4)*

> **CP22 — REGRA DE ADMISSÃO DE COR DE ENTIDADE (executa o SUP-5, na forma que a decisão Q1
> escolheu: PALETA FECHADA com tinta declarada por cor, verificável em teste estático).**
> Cor de entidade (área do ERP, cliente, categoria) só é admitida se passar **4,5:1** com uma
> das **duas tintas declaradas**: `entity-ink-dark` = `cinza-900` `#242E34` · `entity-ink-light`
> = branco. A verificação acontece **na definição da paleta**, nunca em render.
>
> **Medição desta edição (todas as 6 famílias × 10 stops, 60 pares × 2 tintas):** o resultado
> é uma lei limpa de rampa —
>
> | Faixa de stop | Tinta admitida | Pior par medido |
> |---|---|---|
> | **50–400** (todas as famílias) | `cinza-900` | 5,03 (vermelho-400) — todos ≥4,5 ✓ |
> | **500** (todas as famílias) | **NENHUMA** — zona de cruzamento de luminância | 4,30 (turquesa-500 × cinza-900) e 4,30 (vermelho-500 × branco) — ambos <4,5 |
> | **600–900** (todas as famílias) | branco | 4,60 (turquesa-600) — todos ≥4,5 ✓ |
>
> **O stop 500 de qualquer família é inadmissível como fundo de entidade, por medição.** É a
> mesma zona (~L 0,18 relativa) que o estudo declarou instável. *Precedente interno:* a regra
> do amarelo (*"`#FAD61D` → SEMPRE texto escuro"*, `marca-seed.md` §3.6) já era uma declaração
> de tinta-por-cor; esta regra a generaliza. *Alternativa descartada (era o desenho hex-livre
> do SUP-5):* cálculo de luminância em render + portão no cadastro — custo em render, texto
> mudando entre chips vizinhos, e instabilidade na zona de cruzamento; com paleta fechada, o
> próprio estudo manda a tabela estática. **Registrado também em `marca-seed.md` v5.2 §3.6-b**
> (é lei de marca: decide o que pode ser cor da SEED).

> **CP23 — A PALETA DE ENTIDADE: SEIS POSIÇÕES** *(`estável` — gate visual aprovado em 2026-08-14, G3)*.
>
> | Posição | Fundo | Tinta declarada | Medido |
> |---|---|---|---|
> | E1 | `turquesa-400` `#11B0A0` | `entity-ink-dark` | **5,11** |
> | E2 | `dourado-400` `#D49400` | `entity-ink-dark` | **5,30** |
> | E3 | `azul-400` `#01B3E0` | `entity-ink-dark` | **5,63** |
> | E4 | `turquesa-800` `#005048` | `entity-ink-light` | **9,37** |
> | E5 | `azul-700` `#006783` | `entity-ink-light` | **6,43** |
> | E6 | `dourado-700` `#7B5500` | `entity-ink-light` | **6,68** |
>
> Três famílias × dois registros (vivo-com-tinta-escura · profundo-com-tinta-branca) — a
> distinção entre vizinhos vem de matiz E claridade, a mesma lógica do espalhamento da
> categórica. **Exclusões, cada uma com o porquê:** magenta e violeta (lei (e) da §3c:
> *"exclusivos de dado — aparecerem em UI é defeito"*) · **vermelho** (semântica reservada de
> perigo/feedback — entidade vermelha leria como erro permanente) · **amarelo** (acento
> oficial de marca, §3.4; e a proibição *"nunca amarelo e dourado na mesma peça"* colidiria
> sempre que duas entidades aparecessem lado a lado) · **turquesa-600** (é o `action-primary`
> — entidade vestida de botão primário) · **cinza** (é o neutro do C19: estado sem carga não
> recebe croma). **Acima de 6 entidades: repete-se a cor e distingue-se pelo GLIFO** — o
> quadrado de entidade leva glifo, não letra (decisão registrada no MANIFESTO v6.4, mantida) —
> **nunca nasce uma sétima cor.**

> **CP24 — MARCADOR DE "AGORA": `turquesa-600`, FIXO NOS DOIS TEMAS** *(`estável` — gate
> visual aprovado em 2026-08-14, G4; adota o contrato de quatro peças do C16, com a cor
> decidida por medição — e a invariância entre temas foi conferida em COR RENDERIZADA na
> camada de render, não só declarada)*.
> As quatro peças (pílula de horário · linha · ponto de junção · círculo no dia) e a espessura
> por lente (1px no gantt denso, 3px no calendário) entram como contrato; **a cor é
> `turquesa-600` `#098475`, o mesmo hex nos dois temas** — medido nesta edição contra as cinco
> superfícies canônicas: página clara **4,60** · sutil clara **4,23** · página escura **4,05**
> · sutil escura **3,72** · peça escura **3,31** — todos ≥3,0 (non-text, SC 1.4.11), com um
> único hex.
>
> **Correção declarada de uma decisão do gate desta fase:** a resposta às perguntas do
> confronto dizia `turquesa-400`; medido, o `turquesa-400` dá **2,71** contra superfície clara
> e **reprova**. A medição mudou a decisão — é para isso que a regra "todo par novo é medido
> antes de entrar na spec" existe. **Vermelho segue descartado** (num painel de O&M vermelho é
> falha; *"um usuário pode ler 'agora' como 'erro'"* — C16) e **amarelo também** (§3.4: acento
> de marca não é cor de trabalho). O marcador **não conta** como a âncora de ênfase do §3.5-c:
> é hairline, não superfície. Em telas sobre o passado (relatório histórico, fechamento de
> mês), o marcador **não aparece** — marcar o agora ali é ruído (C16).
>
> **Com esta decisão, a classe "INVARIANTE DE TEMA" ganha nome e três membros declarados**
> (era o achado do C14): **SH15** (chrome do rail) · **DG12** (tinta sobre dado) · **CP24**
> (marcador de agora). A classe existe porque nos três casos o objeto contrastado não inverte
> com o tema. O `action-primary` **NÃO** entra na classe — fixá-lo derrubaria o par dark
> `turquesa-300`+`turquesa-900` a 7,39 (AAA) por um par não medido (veredito do confronto,
> mantido).

---

## 7b. Primitivos de layout — CP25 *(camada nova, F5/2026-08-15)*

> **CP25 — CINCO PRIMITIVOS MECÂNICOS, ABAIXO DOS BLOCOS. Todo espaçamento entre elementos é
> responsabilidade de um primitivo declarado; nenhum componente resolve o próprio layout externo.**

**O problema que motiva, com o fato.** O DS tinha blocos (o QUE a coisa é: peça, régua, faixa) e
componentes (§1–§45), e **nada entre eles** — então cada preview resolvia espaçamento no CSS
local. Consequência medida na CP-P4 (2026-08-15): onze artefatos, onze soluções diferentes para
o mesmo problema de empilhar coisas. O canon converge nesta camada: *Every Layout* (primitivo =
"uma responsabilidade estrutural só"), **Atlassian Primitives** (Box/Inline/Stack, com a regra
*"toda decisão de layout precisa ter um dono explícito"*) e o **W3C Design System** (Box, Center,
Cluster, Frame, Sidebar, Switcher). Nenhum deles inventa layout novo — todos **nomeiam o dono**.

| Primitivo | Responsabilidade única | Parâmetro | Onde já existe hoje sem nome |
|---|---|---|---|
| **pilha** | empilhar verticalmente com ritmo constante | escala `sp-*` | conteúdo de cartão, corpo de formulário, lista de mensagens |
| **linha** | dispor horizontalmente com alinhamento e sem quebra | `sp-*` + alinhamento | zonas da topbar, ações do rodapé de cartão, cabeçalho de peça |
| **cacho** | dispor horizontalmente **permitindo quebra** | `sp-*` | chips de filtro aplicado (§42), tags, avatares agrupados |
| **caixa** | dar respiro interno e superfície a um conteúdo | padding + superfície | o interior de toda peça |
| **lateral** | dois painéis lado a lado que **empilham quando o espaço acaba**, sem media query | largura do painel lateral + limite de quebra | shell (rail+conteúdo), gantt, chat, configurações |

**Regras do CP25, todas verificáveis:**
1. **Um primitivo tem uma responsabilidade.** `pilha` não alinha horizontalmente; `caixa` não
   espaça filhos entre si.
2. **Espaçamento vive no pai, nunca no filho.** Componente não declara `margin` externo — a
   regra do "owl" (`* + *`) do canon: quem separa é o contexto, e assim não sobra margem no
   primeiro nem no último item.
3. **Primitivos compõem-se; blocos não mudam.** Uma peça é um bloco; por dentro ela é `caixa` +
   `pilha`. O vocabulário de sete blocos (CP2) **não muda** — o CP25 é a camada de baixo.
4. **`lateral` é a única forma canônica de dois painéis** — proibido resolver com media query
   (CP27/CP28).

*Alternativa descartada:* seguir sem a camada, documentando espaçamento caso a caso — é
exatamente o estado que produziu onze soluções para um problema. *Custo declarado:* mais uma
camada para manter e para ensinar; o ganho é que **layout deixa de ser opinião local**.

**Nomes em português** por coerência com o resto do canônico (todo conteúdo técnico do projeto é
PT-BR). No código, a skill `seed-ds-ui` mapeia para as classes utilitárias da stack — o nome do
DS é o contrato; o nome da implementação é detalhe dela.

---

## 7c. Responsivo em DUAS camadas — CP26, CP27 e CP28 *(F7–F9/2026-08-15)*

> **CP26 — GABARITO É A INSTÂNCIA NOMEADA DE UM ARQUÉTIPO, E É O QUE SE ENTREGA AO PRODUTO.**
> A tabela do §3 declara o contrato; um **gabarito** é aquele contrato preenchido com blocos,
> primitivos e componentes concretos — a "página pronta para começar" (o equivalente aos
> *blueprints* do Salesforce Lightning). Todo gabarito nasce com: canvas, peças, contêineres
> nomeados (CP27), ordem de colapso (CP15) e estados não-felizes (§25) declarados. **Gabarito sem
> a coluna `<600px` e sem estado vazio está incompleto por definição.**

> **CP27 — CONTAINER QUERY NOMEADA GOVERNA A DENSIDADE. Todo bloco que muda de forma por espaço
> declara `container-name` de uma lista fechada; container anônimo é drift.**
>
> **Fato que motiva, MEDIDO no produto de referência:** mais de **60 container queries**,
> quase todas nomeadas, contra 54 media queries — e a barra de ferramentas de visualização
> sozinha tem **sete pontos de quebra do próprio container**. A consequência foi escrita no
> estudo: *simulação de dimensão de render só conta se disparar as mesmas regras da realidade —
> container queries, não media queries.* Um componente que consulta a janela quebra ao ser posto
> numa gaveta de 300px, e **nenhuma suíte que redimensiona a janela vê isso**.
>
> **Lista fechada de contêineres nomeados** (cresce por supersede, nunca por improviso):
> `app` (shell) · **`tela`** (raiz de arquétipo que roda SEM shell) · **`pagina`** (raiz de
> página pública/institucional) · `conteudo` (região principal) · `peca` (qualquer cartão) ·
> `trilha` · `regua` (toolbar/régua de tempo) · `painel-lateral` (sidebar/gaveta) · `celula`
> (célula de grade/tabela) · `faixa` (seção da página institucional).
>
> **SUPERSEDE de 2026-08-24 (F7.7-P3, veredito dele: *"sigo sua recomendação"*): a lista vai de
> OITO para DEZ nomes.** Entram `tela` e `pagina`, e o motivo é que eles nomeiam um nível que a
> lista não tinha: **a raiz de consulta de um arquétipo que não vive dentro do shell.** As seis
> telas da F7.6 (autenticação, onboarding, busca, configurações, atividade, documento) declaram
> a raiz no `body`, porque ali não existe `app` — e o `banco-dataviz-dp` faz o mesmo no contexto
> de página. Chamar isso de `app` seria mentir sobre o nível; deixar anônimo é o drift que este
> CP proíbe.
>
> **Como o buraco foi achado, e por que ele durou nove dias:** a `suite-container` media esta lei
> em DUAS telas (as da F7.2), enquanto a lei vale para o acervo inteiro desde a F7.1. A guarda
> nova `guarda-container-nome.mjs` (F7.7-P3) varre tudo — telas e bancadas — e achou **nove
> artefatos com nome fora da lista** na primeira execução. *Instrumento que mede parte do acervo
> declara conformidade de parte do acervo.*
>
> **Duas abreviações foram RENOMEADAS no mesmo veredito, e não admitidas:** `pn` (interior do
> painel → **`conteudo`**, que é o que ele é) e `pag` (raiz da tela do site → **`pagina`**, o nome
> inteiro). Abreviação de três letras não é vocabulário: ninguém lê `@container pn` e sabe do que
> se trata. *Nome de contêiner é contrato de leitura, não economia de bytes.* Os dois artefatos
> são gerados, então a troca foi feita nos moldes e regerada — nunca no artefato (§14.4).
>
> **Stack:** Tailwind v4 traz container query nativa (`@container/nome`), sem plugin — a skill
> `seed-ds-ui` recebe o mapeamento junto da pendência NM4.

> **CP28 — O VIEWPORT GOVERNA O REFLOW, E ESSA FRONTEIRA É NORMATIVA.**
> **Achado que corrige o CP27 antes de ele virar erro:** o SC **1.4.10 Reflow (AA)** é medido
> contra o **viewport** — 320 CSS px de largura, ou 400% de zoom numa janela de 1280px. Container
> query **não prova reflow**: um componente pode reagir lindamente ao seu contêiner enquanto a
> página inteira força rolagem em dois eixos. Portanto:
>
> | Camada | Instrumento | O que decide | Como se prova |
> |---|---|---|---|
> | **Densidade** | container query nomeada (CP27) | forma do bloco no espaço que ele ocupa | redimensionar o **contêiner** e medir |
> | **Reflow** | media query + zoom | colapso da tela, ordem do CP15, coluna única | janela a **320px** e **400% de zoom** em 1280px |
>
> **Exceções de reflow, declaradas** (a norma as prevê: "conteúdo que exige layout bidimensional"):
> **tabela de dados**, **mapa**, **gantt** e **matriz de capacidade** podem rolar em dois eixos —
> e cada um **declara isso no seu gabarito**, com alternativa de leitura (a alternativa textual do
> mapa, PN54, é o precedente).
>
> *Alternativa descartada:* migrar tudo para container query e aposentar as media queries —
> descartada por **medição de norma**: perderíamos a prova de 1.4.10, que é AA e vale para
> qualquer produto SEED.

---

## 7d. Relações de composição e arraste — CP29 e CP30 *(F4 e F12/2026-08-15)*

> **CP29 — RELAÇÃO DE COMPOSIÇÃO: o que acontece ENTRE dois blocos também é contrato.**
> O CP2 nomeia os tipos; o CP29 nomeia as **relações permitidas**, porque três casos reais não
> são bloco nenhum — são vínculos:
>
> | Relação | O que é | Regra |
> |---|---|---|
> | **split com resizer** | dois blocos irmãos que dividem o espaço, com divisor arrastável de **1px** (área de toque ≥24px, invisível) | posição **persiste** por gabarito; teclado move com setas (CP30); abaixo do limite de quebra vira `lateral` empilhada |
> | **peça em peça** | proibida no caso base (CP2); permitida só no feed invertido (CP2-b) e no cartão-coleção do hub | a peça interna **não repete** a separação da externa (CD5: contorno dentro de contorno) |
> | **trilha em canvas** | a trilha só existe dentro de um canvas, nunca solta nem dentro de peça | o croma vem das peças, nunca do fundo da trilha (CP19) |

> **CP31 — BANCADA E TELA SÃO ARTEFATOS DE CLASSES DIFERENTES, E O NOME DECLARA QUAL É QUAL.**
> *(F11/2026-08-15 — decisão do Rafael; executa a renomeação e fecha a dívida P1 de caminhos.)*
>
> | Classe | Prefixo | O que é | O que mede | Quem julga |
> |---|---|---|---|---|
> | **Bancada** | `banco-*.html` | catálogo: o MESMO componente repetido em todos os estados, fora de contexto de uso | comportamento, ARIA, estados, contraste de par | as suítes (jsdom + render) |
> | **Tela** | `tela-*.html` | caso de uso montado: dados plausíveis, cada componente **uma vez**, no papel dele | composição — calha, raio, separação, densidade por contêiner | o **gate visual humano** + `suite-composicao` |
>
> **Fato que motiva.** Os dois viviam sob o mesmo nome (`*-preview.html`), e a confusão custou
> caro: em 2026-08-15 o julgamento *"estamos arcaicos?"* foi feito sobre uma bancada, e só foi
> respondido quando nasceu a primeira **tela** composta. Nome que não distingue classe de
> artefato produz avaliação da coisa errada. **Régua de uso:** pergunta sobre COMPORTAMENTO de um
> componente → bancada; pergunta sobre se a TELA está boa → tela.
>
> **TABELA DE EQUIVALÊNCIA — executada em 2026-08-15 (F7.1 movimento 2).** Ela existe porque
> a renomeação **não reescreve registro datado**: o MANIFESTO ancorou `seed-shell-preview.html`
> porque o arquivo se chamava assim naquela data, e os `marcos/` são imutáveis por método. Trocar
> o nome lá faria a âncora descrever um passado que não existiu. **Referência operacional foi
> reescrita (39 arquivos, 79 ocorrências em `.mjs`/`.py`/`.html`); registro histórico ficou
> intacto, e esta tabela é a ponte entre os dois.**
>
> | Nome antigo | Nome novo | Classe |
> |---|---|---|
> | `seed-painel-preview.html` | `tela-painel.html` | tela |
> | `seed-shell-preview.html` | `tela-shell.html` | tela |
> | `seed-site-preview.html` | `tela-site.html` | tela |
> | `seed-tela-referencia.html` | `tela-referencia.html` | tela |
> | `seed-cn-preview.html` | `banco-cn.html` | bancada |
> | `seed-componentes-preview.html` | `banco-componentes.html` | bancada |
> | `seed-composicao-preview.html` | `banco-composicao.html` | bancada |
> | `seed-dados-preview.html` | `banco-dados.html` | bancada |
> | `seed-dataviz-graficos-preview.html` | `banco-dataviz-dg.html` | bancada |
> | `seed-dataviz-monitoramento-preview.html` | `banco-dataviz-dm.html` | bancada |
> | `seed-dataviz-dp-preview.html` | `banco-dataviz-dp.html` | bancada |
> | `seed-dataviz-di-preview.html` | `banco-dataviz-di.html` | bancada |
> | `seed-dataviz-tokens-preview.html` | `banco-dataviz-tokens.html` | bancada |
> | `seed-feedback-preview.html` | `banco-feedback.html` | bancada |
> | `seed-formfield-preview.html` | `banco-formfield.html` | bancada |
> | `seed-icones-preview.html` | `banco-icones.html` | bancada |
> | `seed-navegacao-preview.html` | `banco-navegacao.html` | bancada |
> | `seed-superficies-preview.html` | `banco-superficies.html` | bancada |
> | `seed-tokens-preview.html` | `banco-tokens.html` | bancada |
>
> **Fora do mapa, com o porquê:** `seed-dataviz-di-prova-impressa.html` (prova física, nem
> bancada nem tela) · `seed-design-system.html` (legado do site DS v1) · `reconstrucao-dm.html`
> (artefato de investigação) · e-mails (`et-`/`en-`/`ea-`/`seed-email-*`, outra classe) ·
> moldes `*-template.html` (insumo de gerador, não artefato final).
>
> **Contrato de caminho, único para as duas classes** (fecha a P1, aberta desde o marco v1.4 e
> cobrada duas vezes na sessão de 2026-08-15): toda suíte aceita `process.argv[2]` **ou** resolve
> `../<nome>` **relativo ao próprio arquivo** — nunca pelo diretório de trabalho, nunca com
> caminho de máquina embutido.

> **CP30 — TODA OPERAÇÃO DE ARRASTE TEM TRÊS CAMINHOS. Norma, não preferência.**
> **SC 2.5.7 Dragging Movements (AA, WCAG 2.2):** toda funcionalidade operada por arraste tem de
> ser alcançável **por ponteiro único sem arrastar**. A regra já existia no §48 (PN33, *"onde o
> item cai é o valor do campo"*) e valia só para o painel; a partir daqui vale para o sistema:
>
> 1. **Arraste** — o caminho rico, opcional para quem prefere.
> 2. **Ponteiro único** — "mover para…" em menu, ou tocar-e-colocar. Não é o mesmo que teclado:
>    a norma exige **os dois**, porque há quem não use teclado nem consiga arrastar.
> 3. **Teclado** — pegar/mover/soltar com Espaço-setas-Esc, **e** anúncio do resultado em live
>    region (posição nova falada, não só desenhada).
>
> **Alvo de soltura:** borda tracejada, **nunca** cor saturada (C20) — o alvo tem de sobreviver
> ao grayscale. Onde o arraste for essencial e não houver alternativa possível, a exceção é
> **nomeada no gabarito**, com o porquê; a norma admite, o silêncio não.

---

## 7e. Escala de figura — CP32 *(F7.3/2026-08-16 · a lei que já tinha guarda antes de ter texto)*

> **CP32 — DENSIDADE DE DADO NÃO É FUNÇÃO DA LARGURA DA TELA.** Uma figura de dado (gráfico,
> mapa, diagrama) renderiza **na escala em que foi projetada**: *1 unidade de `viewBox` = 1px*.
> Para ocupar mais espaço, alarga-se a **ÁREA DE PLOTAGEM** — mais coordenadas dentro do
> `viewBox` —, **nunca o desenho inteiro**. Tela maior mostra **mais dado**, jamais **dado maior**.

**Por que esta lei existe, com o número que a produziu.** O `banco-dataviz-dm.html` declarava
`viewBox="0 0 500 202"` com `svg{width:100%}` dentro de um cartão de aproximadamente 1080px:
fator de escala real **2,16×**. O browser escala a tipografia junto, e o resultado medido foi
banda do bullet 18 unidades → **39px**, rótulo da usina 11 → **24px**, valor 11 → **24px**,
rótulo de eixo 10 → **22px**. O gráfico lia como pôster. E o efeito era progressivo: quanto maior
a tela, maior o desenho — o inverso do contrato de um monitor de dado.

**Em unidades de `viewBox` estava tudo certo**, e é por isso que nenhuma auditoria de token, de
contraste ou de composição via alguma coisa: **nenhum instrumento media o FATOR DE ESCALA entre
coordenada e pixel**. O gate visual do Rafael encontrou em segundos aquilo que cinco camadas
automatizadas atravessaram. A guarda `suite-escala-figura.mjs` (87 verificações) nasceu dessa
lacuna.

**Corolário — PICTOGRAMA NÃO É FIGURA DE DADO.** Ícone em botão, rail, chip ou rótulo escala junto
com o texto, de propósito: ele é tipografia, não plotagem. O corte operacional usado pelo
propagador é `viewBox` ≤ 120 unidades **ou** estar dentro de um controle.

**Dois corolários que vieram de defeitos medidos na mesma família:**

1. **Texto dentro de SVG NÃO recebe papel tipográfico.** Lá a unidade é a do `viewBox`; aplicar
   `--seed-txt-*-size` a um `<text>` mistura duas réguas.
2. **Papel de TÍTULO nunca entra no `body`.** Vira herança global e o peso 700 vaza para dentro do
   SVG — empurrou um rótulo de eixo para 532px num `viewBox` de 500.

**Como esta lei chegou aqui.** Ela vigorava desde 2026-08-15 e existia apenas como cabeçalho de
script e como registro no MANIFESTO (dívida **A-P2**, aberta na v8.4). O caminho de entrada estava
declarado: *o `seed-composicao.md` está sob gate; a lei entra nele na promoção*. A promoção veio em
2026-08-16, e ela entra junto. **Guarda sem lei escrita é guarda que ninguém sabe por que existe** —
e é a primeira a ser desligada quando incomoda.

**Relação com CP27 e CP28, que não se confundem:** o CP27 diz que **densidade responde ao
contêiner** e o CP28 que **reflow responde à viewport**. O CP32 é o terceiro eixo: **a figura de
dado não responde a nenhum dos dois em ESCALA** — ela responde em ÁREA. Ganhar largura significa
ganhar coordenada, nunca ganhar tamanho.

---

## 8. Supersedes formais — emitidos e recebidos por este arquivo

| # | O que morre | O que passa a valer | Onde |
|---|---|---|---|
| SUP-1 | SH16 como comentário CSS de artefatos, ausente de canônico | **CP1** — lei deste arquivo; o §46 referencia | aqui, §1 |
| interno | A redação do SH16 *"borda `border-subtle` de 1px"* como separação | Separação pelo **par sombra+anel** (anel 1px na declaração de sombra; slot border livre para estado). Motivo medido: 1,11/1,21 | CP1 + CP17 |
| SUP-2 | §32: *"Fora do DS: presença/status online"* | Presença é DENTRO do DS (C2 já implementado consumindo só escalas existentes; regra do ouro, anel obrigatório) | aplicado em `seed-componentes.md` v0.65 §32 |
| SUP-3 | §25.1 com cinco tipos; Z2 "até 2 ações" universal | **Seis tipos** (+ Bifurcação); na bifurcação, 2 ações é obrigação e ambas primárias | aplicado em `seed-componentes.md` v0.65 §25 |
| SUP-4 | PN21b lido como proibição universal de gradiente de cor | PN21b vale para superfície de **conteúdo**; **chrome é exceção declarada**, com os dois extremos medidos (6,32 / 9,37 — condição satisfeita) | CP20; adoção visual pendente de gate |
| SUP-5 | Ausência de regra de admissão de cor | **CP22** — tabela medida por paleta fechada (forma escolhida pela decisão Q1) | aqui + `marca-seed.md` v5.2 §3.6-b · `rascunho` |
| SUP-6 | — (rampa alpha) | **GATILHO DISPAROU no gate de 2026-08-14** (o gradiente de chrome foi adotado, G2) — **resolvido em escopo mínimo:** dois tokens de overlay de chrome (hover/ativo, alpha sobre a rampa da marca) na próxima edição dos gêmeos, dentro da CP-P3. A rampa completa do C27 segue adiada, porque o CP20 proíbe gradiente fora do chrome | CP20 · CP-P3 |
| interno | A exceção nomeada do CP1: *"âncoras de navegação (o rail) encostam na borda e vão de topo a base, sem raio"* | **O rail é PEÇA sobre o canvas como as demais** (radius-lg · calha sp-3 · flutuante · sem borda, com o porquê medido) — veredito do gate visual de 2026-08-15 (*"um bloco montado como os outros, todos independentes, igual o ClickUp"*). O CP1 fica sem exceções nomeadas | CP1 (supersede anexado) |
| **SUP-7** *(F1)* | CP2 com **seis** tipos de bloco | **Sete tipos** — entra a **trilha** (agrupador vertical transparente), mais as exceções nomeadas CP2-a (canvas interativo) e CP2-b (superfície invertida). Motivo: o mapa de cobertura confrontou o vocabulário contra os arquétipos ausentes e três estruturas não se descreviam | aqui, §2 |
| **SUP-8** *(F5)* | Ausência de camada entre bloco e componente — cada artefato resolvia o próprio espaçamento (11 soluções medidas na CP-P4) | **CP25** — cinco primitivos mecânicos (pilha · linha · cacho · caixa · lateral), com espaçamento no pai e uma responsabilidade por primitivo | aqui, §7b |
| **SUP-9** *(F7/F8)* | Responsivo resolvido por media query em todo o DS (só o shell tinha `@container`) | **Duas camadas com fronteira normativa**: container query nomeada governa densidade (CP27), viewport governa reflow 1.4.10 (CP28), com as exceções bidimensionais declaradas por gabarito | aqui, §7c |
| **SUP-10** *(F12)* | Lei de arraste existindo só no §48 (PN33) | **CP30** — três caminhos obrigatórios (arraste · ponteiro único · teclado com anúncio) para qualquer arraste do sistema, SC 2.5.7 AA | aqui, §7d |
| **SUP-11** *(F11)* | `*-preview.html` nomeando duas classes distintas de artefato | **CP31** — `banco-*` (catálogo de estados) e `tela-*` (caso de uso montado), com contrato de caminho único que fecha a dívida P1 | aqui, §7d |

---

## 9. Erratas achadas nesta fase

> **E-CP-01 — O C1 implementado no shell consome a escala errada, e uma posição dela reprova
> a admissão.** Fato: `validacao/gen-shell.py` (l.79–82) implementa a identidade por entidade
> consumindo `seed-chart-cat-1…6`. Dois defeitos: **(a)** viola a lei (e) da §3c/§4.6 do
> dataviz — *"magenta e violeta são exclusivos de dado: aparecerem em UI é defeito, e a suite
> não os aceita fora de contexto `chart-*`"* — as posições cat-3 e cat-5 são exatamente esses
> matizes; **(b)** o `cat-1` (`turquesa-500` `#00A192`) mede **3,22** com branco e **4,30**
> com `cinza-900` — reprova a admissão do CP22 com as duas tintas (é um stop 500, a zona
> inadmissível). **Correção:** quando o shell for regenerado por outro motivo (regra GI2), o
> C1 passa a consumir a paleta de entidade do CP23 — condicionado ao gate do CP23. Gravidade
> alta: é a mesma classe do E-CF-02 (implementado em artefato, contrariando o canônico).
>
> **✅ FECHADA em 2026-08-14, na CP-P3 (MANIFESTO v6.8), exatamente pela via prevista:** o
> shell foi regenerado (gradiente do CP20 + overlays do SUP-6) e, na mesma regeneração, o C1
> passou à paleta do CP23 com **tinta por posição** (`--seed-entity-N` + `--seed-entity-N-ink`,
> gêmeos v1.11) — o quadrado segue com **glifo**, decisão do MANIFESTO v6.4 mantida. Os seis
> pares remedidos na entrada da spec: 5,11 · 5,30 · 5,63 · 9,37 · 6,43 · 6,68, todos ≥4,5.

---

## 10. O que esta fase NÃO cobre

- **O conteúdo do arquétipo detalhe** — zonas, campos, comportamento interno: é o **§49**
  (pendência PN-P3). Aqui só a montagem.
- **Gantt profissional** (PN42–PN45, bloco 6D) e qualquer regra de dependência visual.
- **E-mail**: runtime sem CSS variable, com leis próprias (`seed-email.md`, fronteira do
  `seed-tokens.md` §6). O contrato de montagem NÃO se aplica a e-mail.
- **Impresso**: o DI é dono (`seed-dataviz.md` §4c). O CP20 registra apenas que gradiente não
  sobrevive à impressão.
- **Guarda automatizada dos tetos CP21** e **suíte própria de composição** — nenhum preview
  novo nasceu nesta fase; o contrato é exercido pelos previews existentes (shell, site,
  painel). Pendência **CP-P1**: instrumentar CP1/CP15/CP21 como camada de composição.

  > **✅ CP-P1 FECHADA em 2026-08-15** (MANIFESTO v7.4, aprovação na v7.5 — veredito do
  > Rafael, verbatim: *"se as pendências já foram sanadas, sim. aprovo."*). O que fechou é a
  > CP-P1 **na definição do backlog do marco v2.1**, que a estreitou para o que a cobaia
  > exercita: gerador próprio da `seed-tela-referencia.html` (provado por fidelidade
  > byte-perfeita — a saída reproduz o MD5 `142a02a8…` do gate) + `suite-composicao.mjs`
  > (33 testes de render, dois temas: calha `sp-3` real em bounding box, `radius-lg` nas
  > peças, rail sem borda, chip pintado = token do tema, mono no dado/PN21d, e a barra do
  > ativo SONDADA EM PIXEL — a guarda candidata do MANIFESTO §33, provada contra três
  > defeitos plantados, incluindo o `left:-8px` histórico). **Supersede da redação acima,
  > declarado:** a frase original desta seção pedia "CP1/CP15/CP21"; o **residual não entra
  > no fechamento** — CP15 (colapso) não é exercitável na cobaia (tela estática desktop, por
  > estatuto) e os tetos do CP21 já têm item próprio no backlog do `ESTADO_ATUAL` ("três
  > medidas de composição sem guarda automatizada", prioridade baixa, origem v2.0) — o
  > residual vive lá, não aqui.
- **A aplicação do CP17 nos artefatos existentes** — os previews que hoje separam por borda
  continuam válidos visualmente (o 1px é o mesmo); a migração de mecanismo entra no retrofit
  PN-P7. Pendência **CP-P2**.

  > **✅ CP-P2 FECHADA em 2026-08-15** (MANIFESTO v7.6 entrega, v7.7 aprova — veredito do
  > Rafael, verbatim: *"aprovo"*, com as duas perguntas do pacote respondidas na mesma
  > mensagem). O que fechou, definido por **inventário MEDIDO** (42 HTML no repositório, não
  > "~40"): as DUAS telas que separavam peça por borda migraram para o par do CP17 —
  > `seed-tela-referencia.html` v0.2 (regra `.peca`; na mesma regeneração a GI2 dos 3 tokens
  > órfãos fechou: 38 nomes, `shadow-raised` ganhou consumo real pela própria migração) e
  > `seed-shell-preview.html` v0.6 (`.coluna` + `.sidebar`). A `suite-composicao.mjs` foi a
  > **v2** junto (RAIL-02 passou a medir o par no box-shadow computado + slot border zerado,
  > provada contra mutante: peça devolvida à borda antiga reprova nos dois temas). Painel e
  > site já eram conformes (PN21a e faixas); os retroativos de EMPRÉSTIMO (classe PN-P7)
  > fecharam no mesmo pacote: painel v0.10 e site v0.2 consumindo `--seed-border-interactive`,
  > com **prova em pixel de invisibilidade** (0,06% e 0,00% de diferença — promoção de
  > expressão, não de cor). **Fronteira do fechamento, declarada:** os previews de COMPONENTE
  > ficaram fora porque o CD1 (§26 do `seed-componentes.md`) declarava card outlined como
  > default sem supersede do CP17 — conflito latente ACHADO pelo inventário; o Rafael decidiu
  > pela opção A ("o que vai prevalecer é o que construímos agora") e o **supersede parcial do
  > CD1 está anexado no §26.1 (`seed-componentes.md` v0.69)**; o retrofit desses previews é a
  > pendência nova **CP-P4** (MANIFESTO v7.7), fora deste fechamento de propósito — a ordem é
  > decisão→artefato, nunca o inverso.
- **A regeneração do shell** com as três decisões do gate — gradiente do rail (CP20, com os dois
  tokens de overlay de chrome nos gêmeos), paleta de entidade no C1 (CP23, fecha a E-CP-01) e
  conferência do marcador onde o shell o consumir (CP24). Pendência **CP-P3** — uma regeneração,
  três correções, com suíte e render re-executados e MANIFESTO reancorado no mesmo pacote.
- **A coluna de estado do `estudo-viver-de-ia.md` §5** (decisão Q5) — pacote de errata
  separado, não este.
- **Reenvio das seis cópias defasadas ao Project Knowledge** (decisão Q6) — a regra "o zip é a
  fonte" está escrita no MANIFESTO v6.6; o reenvio é ação de propagação do Rafael.

---

### 10-b. O que a v2.0 (F7.1) NÃO faz — fronteiras da fundação

- **Não executa a renomeação dos artefatos.** O CP31 declara a lei; renomear os arquivos e
  reancorar caminhos e MD5 é o **segundo movimento da F7.1**, com leitura de volta por hash.
  Enquanto não executado, os nomes `*-preview.html` seguem válidos e **defasados da lei** —
  estado declarado, não esquecido.
- **Não implementa os primitivos.** O CP25 define o contrato; a implementação (CSS/utilitários +
  mapeamento na skill `seed-ds-ui`) entra com o primeiro gabarito que os consumir (F7.2).
- **Não converte os artefatos existentes para container query.** O CP27 vale para o que nasce a
  partir daqui; a conversão do acervo é retrofit próprio, com a guarda de contêiner (F9) como
  pré-requisito — medir antes de converter.
- **Não escreve o CONTEÚDO dos gabaritos novos.** A tabela do §3 declara a montagem; o que cada
  tela mostra é das fases seguintes (F7.2 em diante). Um gabarito na tabela **não** significa
  tela pronta.
- **Não decide os arquétipos fora de escopo:** whiteboard e mapa mental permanecem fora (D5).

---

## 11. Registro do documento

| Campo | Valor |
|---|---|
| Arquivo | `seed-composicao.md` |
| Versão | **v2.0 — A FUNDAÇÃO** · 2026-08-15. Primeira edição que **amplia o sistema** em vez de refinar: CP2 vai de 6 a 7 tipos (SUP-7), nasce a camada de primitivos (SUP-8, CP25), o responsivo passa a ter duas camadas com fronteira normativa (SUP-9, CP26–CP28), arraste vira lei do sistema (SUP-10, CP30), relações de composição ganham contrato (CP29) e bancada×tela viram classes nomeadas (SUP-11, CP31). A tabela do §3 vai de **11 para 23 gabaritos**. Origem: consolidado da **F7.1** aprovado pelo Rafael em 2026-08-15 ("aprovo"), após 3 rodadas de pesquisa e o `mapa-cobertura-ds.md` v0.3. Histórico: v1.6 fechou a CP-P2 e a errata de cabeçalho; v1.5 fechou a CP-P1; v1.4 mudou o rail para peça; v1.0–v1.3 nasceram e consolidaram a Fase 2. |
| Estado | **`estável`** — gate visual do Rafael em 2026-08-14 sobre o preview v0.1. Vereditos, verbatim do gate: **G1** par sombra+anel escolhido ("nos dois fica ótimo, mas se tiver que escolher, seria par sombra+anel") — contrato mantém UM mecanismo · **G2** gradiente ADOTADO ("gradiente é mais bonito") — dispara o gatilho do SUP-6, resolvido em escopo mínimo (CP-P3) · **G3** paleta de entidade aprovada · **G4** `turquesa-600` aprovado · **G5** bifurcação ok. Camada de render prévia ao gate: 10 verificações · 0 achados |
| Decisões | **CP1–CP31** (CP4–CP12 são as linhas da tabela do §3, hoje com 23 gabaritos). Novas na v2.0: CP25 primitivos · CP26 gabarito · CP27 container query nomeada · CP28 viewport e reflow · CP29 relações · CP30 arraste · CP31 bancada×tela |
| Origem | Fase 2 sobre o `confronto-referencias-ds.md` v1.0; decisões Q1–Q8 e vereditos SUP-1…6 delegados pelo Rafael em 2026-08-14 ("Você decide então") — Q1 paleta fechada · Q2 corrigida por medição no CP24 · Q3 detalhe entra (montagem) · Q4 `cor.py` adiado · Q5 pacote separado · Q6 regra no MANIFESTO · Q7 ancorar os três estudos · Q8 este arquivo |
| Pesquisa desta edição | 3 rodadas encadeadas (2026-08-15): **R1 canon de layout** — Every Layout (primitivo = uma responsabilidade; o "owl" `* + *`), Atlassian Primitives (*"toda decisão de layout precisa de dono explícito"*), W3C Design System (sidebar sem media query), Brad Frost (page layouts no DS), Salesforce Lightning (**blueprints**: páginas inteiras, não só componentes) · **R2 stack/mercado** — Tailwind v4 com container query nativa `@container/nome` (sem plugin desde a v4; `@container-size` na v4.3), e a orientação convergente de **manter media query para decisão de página** · **R3 normas** — SC 1.4.10 Reflow (320px / 400% em 1280px; exceção explícita para conteúdo bidimensional: tabelas, mapas, diagramas) e SC 2.5.7 Dragging Movements (alternativa de ponteiro único **além** do teclado; alvo de soltura que sobreviva ao grayscale) |
| Medições novas desta edição | admissão de cor (120 pares, §7) · gradiente de chrome (2 pares) · marcador de agora (10 pares) · par borda×canvas do CP17 (2 pares) — fórmula WCAG 2.1 sobre os hex do `seed-tokens.css` v1.9 |
| Leitura N3 desta fase | `seed-dataviz.md`: DF4 · DF7 · DG1 · DG12 · DG14–17 · DM4 · DM7 · DM10 · DP12 · matriz DP · §5 · §6 — `seed-componentes.md`: §0 · §16 · §19 · §21 · §25 · §30 · §40–§43 · §46.1–46.2 · §47 íntegro · §48.4 · §48.6 · §48.7 · §48.9 |
| Erratas | E-CP-01 — **fechada em 2026-08-14 (CP-P3, MANIFESTO v6.8)**; registro histórico mantido no §9 com o fechamento anexado |
| Pendências abertas | **CP-P4** (retrofit dos previews de componente sob o supersede parcial do CD1 — nasceu no fechamento da CP-P2; registrada no MANIFESTO v7.7). **CP-P2 FECHADA em 2026-08-15** (MANIFESTO v7.6/v7.7): tela v0.2 + shell v0.6 no par do CP17 com suíte v2 provada contra mutante; painel v0.10 + site v0.2 no semântico `border-interactive` com prova em pixel (0,06%/0,00%); fechamento completo no §10. **CP-P1 FECHADA em 2026-08-15** (MANIFESTO v7.4 entrega, v7.5 aprova): gerador da tela de referência provado byte-perfeito contra a âncora do gate + suíte de composição 33·0 com guarda de pixel da barra, provada contra 3 defeitos plantados; supersede de escopo no §10. **CP-P3 FECHADA em 2026-08-14** (MANIFESTO v6.8): shell regenerado (preview v0.2) com gradiente do CP20 via `--seed-rail-background`, overlays do SUP-6 medidos em composição, e C1 na paleta CP23 com tinta por posição — gêmeos a v1.11, cinco camadas verdes (suíte 68·0 · render 18·0 · contraste 45·0 · paridade-tokens 52·0 · invariância do gradiente provada em cor renderizada) |