Qualidade

Dois comandos conferem o projeto gerado. slash check confere o conteúdo, o contraste e o SEO, sem gerar o site. slash verify roda, nesta ordem, as bases visuais, o lint (só se o projeto declarar), o typecheck e os testes, o check, o build, as regras de HTML, o peso da página, os testes de navegador e o Lighthouse. Use o check enquanto edita e o verify antes de publicar.

`slash check`

O check não gera o site. Ele lê os textos, o tema e o SEO do projeto e lista o que bloqueia. Sem problemas, responde check ok. Com problemas, imprime uma seção por grupo (conteúdo, contraste ou seo), com uma linha por item, e sai com erro.

uso: slash check [--watch]
[saída: 0]

Conteúdo

O check confere os marcadores de origem dos textos. Veja Tema, textos e seções para o que cada marcador significa.

pendente em <campo>: um pending(...) ainda não foi trocado pelo texto real.
placeholder em <campo>: ficou um valor de modelo no lugar do texto.
fictício em <campo>: libere com slash approve: um fictitious(...) que você ainda não liberou. A linha some quando você roda slash approve.
<campo>: conteúdo fictício não pode ser verified: true: um item fictício marcado como verificado.

O slash approve libera o conteúdo fictício. Para ele, claude(...) e fictitious(...) são a mesma coisa: os dois marcam o valor como fictício. Se ainda houver pending(...) ou placeholder, ele recusa com Há conteúdo pendente; resolva antes de aprovar.

Contraste

O check confere cada tom do tema (light, gray, dark, accent e photo) em nove pares de cores:

texto (fg, muted e soft) sobre o fundo (bg) e sobre o cartão (card), e o texto do botão (bf) sobre o fundo do botão (bb): mínimo de 4,5:1;
borda de campo (inp) e fundo do botão (bb) sobre o fundo (bg): mínimo de 3:1.

Um par abaixo do mínimo sai numa linha como tom accent: muted sobre bg = 3.9:1 (mínimo 4.5:1).

SEO

O check confere os campos de título e descrição de src/data/site.ts, e a descrição da imagem de compartilhamento:

título: de 10 a 60 caracteres;
descrição: de 50 a 160 caracteres;
share.alt: preenchido, sem ficar em branco.

A contagem é por code point, que é cada caractere Unicode. Um emoji simples conta como um, mas um emoji composto, como uma bandeira, conta mais de um. Um título fora da faixa sai como título entre 10 e 60 caracteres (tem 72).

`--watch`

slash check --watch faz a conferência de novo a cada mudança em src/. Ele espera 0,2 s para juntar salvamentos seguidos. Um erro ao ler o projeto aparece no terminal, e o comando continua. Ctrl+C encerra.

`slash verify`

O verify roda as etapas abaixo, na ordem, e para na primeira que falha. Ele imprime uma linha por etapa, com o tempo. Sem falhas, sai com código 0.

Etapa	O que confere	Limite ou regra
bases visuais	que as imagens de referência existem	sem imagens, a etapa falha. Não roda com `--update-baseline`.
lint	o script `lint` do projeto	só roda se o projeto declarar `lint`. A landing não declara.
typecheck + testes	o typecheck e os testes de `src/`	sem limite numérico
check	o mesmo que `slash check`	veja acima
build	a geração do site	sem limite numérico
html	as regras de cada página, o canonical, o idioma, os links internos e o `sitemap.xml`	título e descrição nos tamanhos acima, `og:image`, `alt` e largura e altura das imagens, JSON-LD válido
orçamento	o peso da página	JS comprimido até 15 KB; primeira carga até 300 KB
playwright	os testes de navegador: grade, rolagem, alvos de toque, acessibilidade, regressão visual, consentimento e eventos	veja abaixo
lighthouse	a nota mobile em quatro categorias: `performance`, `accessibility`, `best-practices` e `seo`	cada categoria em 0,95 ou mais

✓ typecheck + testes (<n> s)
✓ check (<n> s)
✓ build (<n> s)
✓ html (<n> s)
✓ orçamento (<n> s)
✓ playwright (<n> s)
✓ lighthouse (<n> s)
[saída: 0]

O Lighthouse roda em modo mobile, na home e em uma rota de cada padrão de página do site. Uma landing tem só a home, então mede /.

A gravação acima mostra só as linhas de etapa, sem os detalhes que mudam de uma execução para outra. Ela foi feita com --update-baseline, por isso não tem a etapa bases visuais.

O verify roda numa cópia da árvore, em .slash/run/. Por isso o bun run dev pode continuar aberto. Ele precisa de um repositório git, e o Chromium do Playwright instalado. Veja Requisitos e instalação.

Playwright

A etapa playwright roda a suíte da landing no Chromium, em cinco larguras: 360, 768, 1024, 1280 e 1440 px. Em cada largura, ela confere:

que os títulos das seções seguem a grade: 12 colunas a partir de 768 px, 4 colunas abaixo disso;
que a página não tem rolagem horizontal;
que links, botões e itens de summary têm pelo menos 44 px de alvo de toque;
que não há violações de acessibilidade WCAG 2.0 nos níveis A e AA, medidas pelo axe;
que a página bate com a base visual, com até 1% dos pixels diferentes. Imagens e vídeos ficam fora da comparação.

A mesma suíte confere que o GTM só carrega depois que o visitante aceita o consentimento, que os botões de compra e o botão de WhatsApp enviam o evento certo, que as fontes são pré-carregadas, que nenhuma imagem responde com erro, e que os parâmetros de campanha (utm_source, fbclid) chegam aos links de checkout.

Opções

--background: inicia o verify em segundo plano e devolve o terminal na hora. O andamento vai para .slash/verify.log, e o veredito para .slash/verify.json, com ok, as etapas e o tempo de cada uma. Só um verify roda por vez. Se já houver um, o comando diz o pid e recusa.
--if-changed: não roda nada quando a árvore não mudou desde o último verde e está toda commitada. Com --update-baseline, a opção é ignorada e a execução sempre roda. Imprime verify: tree sem mudança desde o último verde. O hook .githooks/pre-push usa essa opção.
--update-baseline: regrava as bases visuais. A seção sobre elas vem mais abaixo.
SLASH_VERIFY_WORKERS: quantos workers o Playwright usa. O padrão é 2, porque cada worker segura um Chromium de cerca de 200 MB. Um valor que não seja um inteiro positivo volta ao padrão.

Bases visuais

As bases visuais são as imagens de referência da regressão visual. Uma landing tem cinco, uma por largura (360, 768, 1024, 1280 e 1440 px). Elas ficam em tests/e2e/landing.spec.ts-snapshots/, com nomes como landing-1280.png. Faça commit delas junto com o projeto. A etapa bases visuais só confere se elas existem: sem elas, o verify para antes do Playwright.

O primeiro uso e a ordem das etapas estão em Primeiro projeto.

Regrave as bases quando você mudar o layout ou o tema de propósito e quiser aceitar a mudança. O comando é slash verify --update-baseline. Ele roda todas as etapas, menos bases visuais. O Playwright grava as imagens novas numa cópia, e elas só voltam ao projeto quando todas as etapas passam. Se alguma falhar, nada é copiado: corrija e rode de novo.

A comparação aceita até 1% dos pixels diferentes, desliga as animações e tira imagens e vídeos da comparação. Assim, trocar uma foto não quebra o teste. Uma mudança de texto ou de cor que altere mais de 1% dos pixels falha. A renderização muda entre sistemas operacionais. Se a diferença aparece só porque você trocou de máquina, regrave as bases nela.

Erros comuns

Onde fica o relatório

No terminal, cada etapa aparece como ✓ ou ✗, com o tempo e, quando há o que dizer, os detalhes indentados abaixo dela. A primeira etapa com ✗ encerra a execução.

Com --background, o andamento fica em .slash/verify.log e o veredito em .slash/verify.json. Quando lint, typecheck, testes, build ou Playwright falham, o detalhe mostra só as últimas 25 linhas da saída da ferramenta, onde costuma estar o motivo. No Lighthouse, a linha de nota abaixo do mínimo traz as auditorias de maior peso.

Os arquivos de resultado do Playwright ficam em .slash/run/test-results/, na cópia que o verify usou. A cópia é refeita a cada execução.

Mensagens comuns

Você vê	O que significa	O que fazer
`Faltam as bases visuais (tests/*/-snapshots/*.png)`	não há imagens de referência no projeto	rode `slash verify --update-baseline`, confira as imagens e faça commit
`typecheck falhou:` ou `testes falharam:`	erro de TypeScript, ou um teste de `src/` que falhou	leia as últimas linhas do detalhe e rode `bun run typecheck` ou `bun test ./src/` na pasta do projeto
`build falhou:`	o build não terminou	leia as últimas linhas e rode `bun run build` para ver o erro inteiro
`dist/index.html não encontrado (o build gerou a página?)`	o build não gerou a home	confira se `bun run build` termina sem erro
`src/site.ts deve exportar site.baseUrl`	falta a URL base que o canonical usa	exporte `site.baseUrl` em `src/site.ts`
`page[0] title-length: O título deve ter entre 10 e 60 caracteres (tem 72).`	uma regra de HTML não passou	o formato é `<seção>[<número>] <regra>: <conserto>`. `page` é a página toda, e o nome de uma seção, como `hero`, aponta o bloco. Troque o texto conforme o conserto
`JS gzip N B excede o limite de 15360 B`	o JavaScript da página passou de 15 KB comprimidos	reduza o JavaScript da página
`primeira carga N B excede o limite de 307200 B`	o que a página carrega de início passou de 300 KB	reduza o CSS, o JavaScript, as fontes pré-carregadas e as imagens com `loading="eager"`
`performance 0,91 (mínimo 0,95); maiores pesos: ...`	uma das quatro categorias (`performance`, `accessibility`, `best-practices` ou `seo`) ficou abaixo de 0,95	corrija a auditoria que a linha cita. A linha lista até três, das de maior peso
`check` com linhas `conteúdo`, `contraste` ou `seo`	o `check` achou algo que bloqueia	veja as seções de `slash check` acima
`verify: o projeto mudou durante a execução; rode de novo para gravar o carimbo`	você mexeu nos arquivos enquanto o `verify` rodava	rode de novo, sem mexer na árvore
`Já existe um verify em andamento (pid N)`	outro `verify` está rodando	espere. O andamento está em `.slash/verify.log`
`... não é um repositório git`	a pasta do projeto não tem git	rode o `verify` dentro de um repositório git

Pronto é quando o verify sai verde depois da última mudança. Veja Fluxo e prazos.