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.

---