Histórico da §46 — seed-componentes.md

Por que esta regra nasce. A LC-11 (MANIFESTO §223.5) deu à ficha de conformidade o item CP-13, que mede no navegador se uma tela de aplicação tem o shell deste §46 (rail de 80 px, topbar de 60 px, main com foco e id, skip link). O que a régua não sabe sozinha é se uma tela DEVE ter shell: pelo SH17, login, site e onboarding vivem fora dele. Ela lia a raiz de consulta do CP27 (app mede · pagina não se aplica) e, quando a raiz era tela ou conteudo — gabarito publicado sem a casca —, dizia NÃO MEDI e pedia --arquetipo a quem roda. Uma IA que só recebe o HTML não tem como declarar. Veredito dele em 2026-09-15 (MANIFESTO §224.1), verbatim: "V-LC11 data-arquetipo: sim".

Por que esta regra nasce agora. Em 2026-09-14 a sessão do ERP construiu a tela "Configurar funil" seguindo o gabarito A18 (§86) — e a tela saiu sem shell: só uma barra superior, sem rail, sem sidebar. Ele reprovou de imediato, verbatim: "tem certeza que as telas sao assim? o quadro aprovado do ERP tem uma rail a esquerda, etc. to achando essa tela muito simplória". Medido depois (MANIFESTO §219): a tela de referência do A18 é publicada SEM a casca (raiz tela, CP28 do seed-composicao.md — "arquétipo que roda SEM shell"), o §86 não cita o §46 uma vez, e nada no canon dizia com todas as letras o que todo mundo da casa sabia: no produto, a casca é o shell e o gabarito é o que vai dentro. Um agente de fora leu o gabarito como decisão de produto. Esta subseção fecha o buraco — e a página /telas/ da vitrine passa a mostrar, por gabarito, se a referência traz a casca e onde ele vive no produto (lido desta tabela e medido no disco pelo gerador).

Aplicado sem pergunta — exposto a veto (regra da casa): as três linhas que decidem o que o canon não dizia — A4 painel, A13 documento e A18 configurações dentro do shell — são aplicação do briefing do §46 e da reprovação dele de 2026-09-14, não decisão nova. Confirmadas por ele em 2026-09-14 (gate F11.1, verbatim: "V-F11.1 tabela SH17: confirmo · V-F11.2 login: aprovo · veto: nenhum", MANIFESTO §220.1) — desde então as três linhas são decisão dele, não aplicação da sessão.

✅ SH-P10 FECHADA em 2026-09-13 — veredito dele, verbatim: "SH-P10: b-tirar-do-rail" (MANIFESTO §209). Aplicado: a barra saiu do rail nos 8 moldes (a da sidebar ficou), SH5 reescrito por região, suítes invertidas para provar a ausência. O registro do achado, como estava: a barra vertical do item ativo do rail: ele a viu como erro; é a marca do SH5. Verbatim dele, na aprovação do shell com material (MANIFESTO §207): "A Rail está com o menu Comercial selecionado, repare no canto esquerdo que tem uma barcação (barra vertical) essa barra nao deveria estar ali, acho que ela vem de outra estruta e é aplicada ali de maneira errada. verifique por favor." Medido: é o ::before de .rail-item[aria-current="page"] — barra branca de 3 px, left: -4px, do topo 8 px à base 8 px do item, encostada na borda interna do rail; não vem de outra estrutura: é a regra SH5 desta seção ("barra lateral de 3px mais peso tipográfico, nunca só fundo colorido"), aplicada ao rail desde o Bloco 6A, invisível até 2026-08-15 (vivia em left: -8px, fora da caixa) e trazida para dentro pelo probe de pixel daquele dia; o gate de 2026-08-15/16 aprovou o shell com ela visível. A mesma barra existe nas outras sete telas com rail (.rail-item.ativo::before nos moldes de chat, detalhe, gantt, lista, quadro, referência e tabela) e a suite-composicao.mjs sonda o PIXEL dela (PX-01/PX-02); a suite-shell.mjs exige a regra (SH5-04). Por que ela lê como resíduo agora: com o material, a pílula clara ganhou volume e a barra ficou separada dela por 4 px de metal — e a pílula clara sobre o rail escuro já sobrevive ao cinza sozinha (é luminância: fronteira 5,31/7,87, SH15-b), com o peso 800 como segundo mecanismo; a barra foi desenhada para a sidebar, onde o ativo é só um fundo quase igual ao papel, e replicada no rail por simetria do SH5. É decisão registrada, logo supersede é dele. Duas saídas, renderizadas em cor e em cinza (folha SH-P10): (a) manter — nada muda; (b) tirar a barra do rail (a da sidebar fica) — o SH5 ganha a redação "no rail, a pílula clara é a marca que sobrevive ao cinza; a barra é da sidebar"; custo medido: 8 moldes (shell + 7 telas), SH5-04 da suite-shell, as sondas PX-01/PX-02 da suite-composicao (que passam a provar a AUSÊNCIA da barra fora da pílula), regeneração byte-idêntica das 8 telas e re-gate por captura — meia sessão. Dono: ele (veredito), depois a sessão. Nada foi mexido até o veredito.

Nota de histórico — a regra acima é a VIGENTE. A exceção nomeada do rail foi SUPERSEDIDA no gate de 2026-08-15 ("um bloco montado como os outros, todos independentes, igual o ClickUp"): supersede SUP-1, 2026-08-14; fecha a errata E-CF-03 — o cabeçalho desta seção dizia "SH1–SH14" com a tabela terminando em SH15.

(Estado: estável desde 2026-08-11, por "aprovo" explícito do Rafael após o gate visual sobre o preview v0.1. Quatro camadas cumpridas: suite-shell.mjs 68 PASS · 0 FAIL — prova de que as guardas são reais: contra um preview com 5 defeitos deliberados, reprova em 8; render-shell.mjs em Chrome real 18 PASS · 0 FAIL; contraste-shell.py 32 PASS · 0 FAIL após as correções que a própria medição exigiu; e o gate visual humano. Pendência que o bloco levou consigo: SH-P1, que é da camada de tokens, não do shell — fechada em 2026-08-14 pelos gêmeos v1.12 (border-interactive; fechamento completo na própria pendência, acima).)

Base (3 rodadas encadeadas, 2026-08-11): R1 canon interno — o §33 como molde de pattern F6; o Bloco 5 inteiro como insumo (o shell não inventa, arruma); MN1 (as quatro saídas semânticas) e MN6 (comando indisponível fica visível), que o SH6 precisa distinguir; DW1 (os dois regimes do drawer) e CN6 (o precedente de standard); a escala de sobreposição 60<65<70<75<80; o §40 (densidade compacta medida em 33px). R2 mercado e stack — componente Sidebar oficial do shadcn/ui, que é o consumidor real do Lovable, com SidebarProvider e os três modos offcanvas/icon/none; blocos de sidebar colapsável com Collapsible do Radix e threading por border-l; prática consolidada de SaaS enterprise (topo para contexto global, lateral para navegação primária, porque as duas camadas fazem trabalhos diferentes e param de disputar espaço); SAP Fiori launchpad shell bar (logo, back, título, busca corporativa, notificações, Me Area). R3 normas e fora-do-circuito — ARIA11/W3C sobre landmark repetido exigindo nome único; MDN sobre role="navigation"; aria-current="page" como critério AAA de baixo custo; o corpus de acessibilidade de SPA (foco preso na navegação após troca de rota é o defeito nº 1, e o alvo do foco não pode ser landmark, link nem botão); Material Design navigation rail (3–7 destinos, posicionado abaixo da top bar). Consolidado aprovado pelo Rafael em 2026-08-11.

PENDÊNCIA SH-P1 — buraco na camada semântica, achado por este bloco. Nenhum token semântico de borda passa 3:1 contra surface-raised no tema claro: border-default mede 1,49 e border-strong 2,53. O campo de busca precisa de contorno que o identifique como componente (1.4.11), e a única saída medida foi consumir o primitivo cinza-500 (3,38 no claro · 4,50 no escuro). Isso é empréstimo declarado, não regra nova — e viola a lei "componente consome semântico". A correção certa é um token semântico novo na camada 2, e ela não pertence a este bloco: mexer nos três gêmeos por causa do shell seria decidir a camada de tokens dentro de um pattern. Fecha quando a camada 2 for editada por outro motivo, pela regra GI2.

---