yonathan-boop/Claude

antislop-layoutmobile

Anti Slop: Regras para Agentes de Codificação de IA. Habilidade de Layout Mobile

Parte do sistema antislop. Leia junto com antislop.md (o núcleo). Esta habilidade aprofunda o aspecto de layout responsivo: como um layout deve se reorganizar em diferentes tamanhos de tela, do celular ao desktop. Pontos de quebra, escala, grids, overflow, alvos de toque e navegação. Ela referencia regras principais pelo número e nunca as duplica ou renumeriza. Carregue-a quando a tarefa construir ou editar um layout que precisa funcionar em qualquer largura de tela.

Como usar esta habilidade

• Carregue junto com antislop.md sempre que a tarefa for trabalho de layout mobile ou responsivo. O núcleo contém o mecanismo (o teste de propósito, os três níveis, o Portão de Entrega); esta habilidade contém a profundidade de layout mobile.
• Cada entrada tem a mesma forma: Diga (o padrão), Por que (por que é considerado slop), Correção (o que fazer em vez disso), com a regra principal citada como R-XX.
• O princípio por trás desta habilidade: o layout mobile é um layout diferente, não o layout desktop em um tamanho menor. Ele deve se reorganizar: re-empilhar, redimensionar e reordenar com intenção. Cada padrão abaixo é uma forma de um layout falhar em se reorganizar.
• O Portão de Entrega no núcleo permanece o portão. A "Lista de Verificação da Habilidade de Layoutmobile" no final deste arquivo é o suplemento específico para mobile para ser executado junto com ele.

Pontos de Quebra

Layout Apenas para Desktop

• Diga: um estado de layout para cada tela; a visualização mobile é o layout desktop comprimido em um telefone.
• Por que: R-03 exige um layout mobile que seja perfeito, não um pensamento posterior. Uma página que apenas encolhe não tem design mobile algum: cartões que funcionavam lado a lado se sobrepõem e texto destinado a uma tela ampla se aglomera em uma estreita.
• Correção: defina um estado mobile real no ponto de quebra onde o conteúdo para de funcionar. O layout mobile se reorganiza: colunas empilham, tamanhos diminuem e a ordem muda onde o conteúdo precisa. Se a visualização mobile for apenas a visualização desktop em uma largura menor, o layout não está concluído.

Ponto de Quebra Determinado por Lista de Dispositivos

• Diga: pontos de quebra nomeados após larguras de telefone (375px, 414px, 768px) escolhidos porque "esse é o tamanho do iPhone", não porque o conteúdo quebra ali.
• Por que: as larguras dos dispositivos mudam a cada ano e modelo. Um ponto de quebra é um ponto onde o layout para de se sustentar; forçá-lo a corresponder a uma lista de dispositivos faz o layout seguir uma especificação técnica em vez do conteúdo (R-03).
• Correção: coloque pontos de quebra onde o conteúdo realmente quebra: quando uma coluna para de ser legível, quando uma fileira de cartões fica muito estreita. Teste estreitando a janela de visualização e observando onde ela quebra, então defina o ponto de quebra ali.

Mobile Estilizado por Último

• Diga: regras mobile adicionadas como uma substituição tardia: uma longa folha de estilos desktop com uma pequena media query no final corrigindo uma ou duas coisas.
• Por que: um remendo de substituição não é um design mobile. Ele corrige o sintoma que foi relatado e deixa o próximo, e os estilos base permanecem ajustados para uma tela ampla (R-03).
• Correção: trate o mobile como um estado projetado, não uma substituição. Dê à janela de visualização estreita seus próprios tamanhos e empilhamento deliberados, e verifique todo o layout ali, não apenas os pontos corrigidos (R-35).

Layout de Dois Estados

• Diga: um layout com exatamente dois estados: uma única coluna empilhada abaixo de um ponto de quebra e uma grade de múltiplas colunas ampla acima dele, com nada definido entre eles. Uma largura de tablet ou laptop pequeno então herda o estado mais próximo: a pilha de telefone esticada absurdamente, ou a grade desktop comprimida em uma fração de sua tela pretendida.
• Por que: uma página é uma faixa contínua de larguras, e R-03 exige que ela se sustente em todas elas, não apenas em dois pontos de quebra escolhidos. Dois estados deixam toda a banda média da faixa (aproximadamente 600 a 1024 px, onde tablets e laptops pequenos vivem) como um acidente: conteúdo que nem empilha com intenção nem se senta em uma grade que se encaixa. O layout parece projetado apenas em seus dois pontos de amostra e quebrado em todos os lugares entre eles.
• Correção: defina estados reais nas larguras onde o conteúdo para de funcionar e deixe que sejam tantos quantos o conteúdo precisar. Uma reorganização típica tem três estados, não dois: coluna única, depois uma grade de duas colunas quando os cartões ficam muito largos como uma pilha única, então a grade completa de múltiplas colunas apenas quando realmente se encaixa. Verifique arrastando a janela de visualização por toda a faixa, não verificando duas larguras e declarando concluído (R-35).

Escala e Dimensionamento

Tudo do Tamanho Desktop

• Diga: padding, gaps, alturas de herói e tamanhos de cartão transportados inalterados do desktop para o mobile, de modo que cada seção pareça ampliada em um telefone.
• Por que: um elemento dimensionado para uma tela de 1440px domina uma de 375px. O que parece confiante no desktop torna-se superdimensionado no mobile: nada se encaixa, nada respira, e a página parece ter sido projetada para uma tela que não está em mãos (R-03). Espaçamento e tipo devem seguir o ritmo do design (R-05), e esse ritmo tem um registro menor no mobile.
• Correção: dê ao mobile seu próprio passo de tamanho: uma escala de tipo menor, padding de seção mais justo, gaps menores. Mantenha os alvos de toque em seu tamanho mínimo (veja Alvos de Toque), mas encolha todo o resto com intenção no ponto de quebra.

Tipo em Pixels Fixos

• Diga: tamanhos de fonte em px fixos que nunca mudam entre desktop e mobile, de modo que cabeçalhos e texto do corpo permaneçam superdimensionados em um telefone.
• Por que: tipo que não responde à janela de visualização é tipo dimensionado para uma tela. R-03 exige que o layout mobile se sustente, e R-06 exige tipografia que melhore a legibilidade. Um título que abrange toda a largura do telefone ou um tamanho de corpo ajustado para uma linha larga quebra ambos.
• Correção: use tipo fluido (clamp()) para que os tamanhos se ajustem com a janela de visualização, ou defina um passo de tipo menor no ponto de quebra. Verifique o resultado em uma largura estreita (R-35), não apenas na pré-visualização desktop.

Seções de 100vh

• Diga: alturas de hero e seção definidas para 100vh, de modo que uma seção preencha toda a tela do telefone e empurre tudo abaixo da dobra.
• Por que: uma seção de tela cheia projetada para um monitor desktop torna-se uma laje gigante em um telefone, e 100vh inclui o navegador chrome, então transborda a área visível em navegadores mobile. Ela domina o layout em vez de introduzi-lo (R-03).
• Correção: deixe as seções dimensionarem para seu conteúdo (auto), ou use a unidade de janela de visualização dinâmica (dvh) onde uma seção de altura total real for pretendida. Nada abaixo da dobra deve ser um acidente de unidades de janela de visualização.

Padding Vazio Enorme

• Diga: padding de seção em escala desktop (96px, 128px) mantido no mobile, criando grandes lacunas vazias entre seções em um telefone.
• Por que: padding ajustado para uma tela grande transforma-se em espaço vertical desperdiçado em uma pequena. A página rola através do vazio, e o ritmo R-05 exige torna-se um vazio entre cada seção.
• Correção: reduza o padding da seção no ponto de quebra para um registro mobile (aproximadamente metade ou menos), e verifique se a página rola em uma densidade natural em vez de através de desertos de espaço.

Grids e Empilhamento

Colunas Que Não Colapsam

• Diga: uma grade de múltiplas colunas mantém suas colunas lado a lado no mobile, então as colunas encolhem, o texto quebra de forma estranha e os elementos colidem.
• Por que: uma grade é uma promessa sobre quanta largura está disponível. Quando a janela de visualização estreita e a grade não re-empilha, cada coluna fica com uma lasca, o texto torna-se ilegível e os cartões se sobrepõem (R-03). Esta é a falha de colisão: o lado a lado do desktop torna-se o amontoado do mobile.
• Correção: colapse a grade para uma única coluna que se reorganiza no ponto de quebra. Lado a lado torna-se empilhado, e cada item obtém a largura total novamente. Re-verifique em uma largura estreita (R-35).

Grade de Largura Fixa

• Diga: grid-template-columns definido em px fixos, ou áreas de grade que não podem se reorganizar, então a grade permanece rígida quando a janela de visualização encolhe.
• Por que: uma faixa de px fixo não se importa com a janela de visualização; ela mantém sua largura e força overflow ou colisão. O layout foi construído para uma tela e não pode mudar de forma (R-03).
• Correção: dimensione faixas com minmax() ou auto-fit e auto-fill para que as colunas encolham e se ajustem com o conteúdo, e defina áreas de grade que colapsam no ponto de quebra. A grade deve ser fluida por padrão, rígida apenas onde um tamanho fixo é deliberado.

Grade Forçada de 12 Colunas

• Diga: uma grade de 12 colunas forçada em conteúdo mobile que precisa de uma ou duas colunas, então os spans parecem arbitrários e a matemática luta contra o layout.
• Por que: um sistema de 12 colunas é para uma tela ampla com muitas colunas de conteúdo. Forçá-lo em um telefone faz cada elemento ser uma fração de uma grade invisível que o usuário nunca vê, e o conteúdo é ajustado à grade em vez da grade ao conteúdo (R-03).
• Correção: deixe as colunas seguirem o conteúdo. No mobile o conteúdo geralmente quer uma coluna, ou duas no máximo; o span de 12 colunas só faz sentido onde o layout genuinamente tem tantas coisas lado a lado.

Overflow

Vazamento de Rolagem Horizontal

• Diga: a página rola lateralmente porque algum elemento é mais largo que a janela de visualização: uma tabela, um bloco de código, uma imagem, uma string longa e ininterrupta.
• Por que: rolagem horizontal é uma promessa quebrada no mobile. O usuário não consegue ver onde a página termina, e o layout visivelmente derrama para fora da tela (R-03). É o slop de overflow mais comum porque o infrator está fora da tela na pré-visualização desktop e passa despercebido até que um telefone o abra.
• Correção: encontre o elemento mais largo que a janela de visualização (uma tabela que precisa de um layout de reorganização ou um contêiner de rolagem, um bloco de código que quebra, imagens com max-width: 100%), então contenha ou reorganize-o. Verifique se a página inteira tem zero rolagem horizontal no alvo mais estreito (R-35).

Recorte Oculto por Overflow

• Diga: overflow: hidden em um contêiner que recorta o conteúdo em larguras estreitas, escondendo texto ou controles em vez de deixá-los caber.
• Por que: recortar é esconder uma falha. Quando um contêiner corta seu conteúdo porque o layout não pode cabê-lo, o usuário perde informações e interação (R-03). O zoom e o ângulo de redimensionamento de texto sobre isso são cobertos por antislop-human.
• Correção: deixe o conteúdo se reorganizar em vez de recortar: permita que o contêiner cresça, envolva seu conteúdo ou colapse-o no ponto de quebra. Recorte apenas onde o corte é a intenção do design (como uma miniatura), nunca onde esconde conteúdo.

Filhos de Largura Fixa

• Diga: filhos de flex ou grade com largura px fixa ou min-width que estouram para fora de seu pai em uma tela estreita.
• Por que: um filho dimensionado em px absolutos não se importa com quanto espaço seu pai tem. No mobile o pai encolhe e o filho permanece largo, então transborda o contêiner e a página (R-03).
• Correção: dimensione filhos com unidades relativas e deixe-os envolver (flex-wrap, larguras fluidas, min-width: 0 em filhos de grade). Um filho deve poder encolher com seu contêiner, não manter um tamanho desktop.

Alvos de Toque

Alvos Subdimensionados

• Diga: botões, links e controles menores que aproximadamente 44 x 44 px, fáceis de acertar no desktop com um cursor, mas difíceis de acertar com um polegar.
• Por que: um cursor desktop tem precisão de pixel; um polegar não. Um alvo que é fino a 16px torna-se um exercício de frustração em um telefone, e falha a promessa de que a interface do usuário é utilizável no mobile (R-03).
• Correção: dê aos alvos interativos uma área de toque mínima de 44 x 44 px, usando padding ou uma caixa de impacto maior mesmo quando o visual é menor. Verifique todo o conjunto de controles em uma largura de telefone (R-35).

Alvos Muito Próximos

• Diga: alvos de 44px agrupados sem gap, então um toque de polegar acerta o errado.
• Por que: o tamanho do alvo importa apenas com o espaçamento do alvo. Dois grandes controles se tocando comportam-se como um grande controle: o usuário não pode selecionar nenhum deles de forma confiável (R-03).
• Correção: deixe um gap claro entre alvos interativos adjacentes, pelo menos alguns px e idealmente o suficiente para que a área de pressão do dedo não se sobreponha. O espaçamento é a outra metade da capacidade de toque.

Interações Apenas por Hover

• Diga: menus, revelações e dicas de ferramentas que existem apenas no hover, então um usuário de toque nunca pode abri-los.
• Por que: não há hover em uma tela sensível ao toque. Uma interação que só responde ao hover simplesmente não existe para usuários mobile, e qualquer controle que dependa dele é um beco sem saída (R-03).
• Correção: dê a cada interação apenas por hover um equivalente de toque: um menu que abre no hover também abre no toque, uma revelação também mostra no clique, e elementos interativos mostram feedback :active visível para que um toque seja registrado. Teste usando a interface apenas com toque (R-35).

Navegação Mobile

Nav Que Permanece Desktop

• Diga: a barra superior desktop com sua fileira de links mantida lado a lado no mobile, então os links se aglomeram, envolvem em duas fileiras ou derramam para além da janela de visualização.
• Por que: uma nav desktop é dimensionada para uma tela ampla. Mantida como uma fileira em um telefone, torna-se uma bagunça de links apertados, e é a primeira coisa que um usuário mobile encontra (R-03). Navegação é onde a reorganização importa mais: o usuário precisa encontrar para onde ir antes de poder ir a qualquer lugar.
• Correção: colapse a nav em um padrão mobile no ponto de quebra: uma nav inferior para o punhado de destinos primários, ou um menu para o resto. Os links se reorganizam para fora da fileira, e os destinos primários permanecem a um toque de polegar de distância. Verifique se sustenta em uma largura estreita (R-35).

O Hamburger Nu

• Diga: tudo escondido atrás de um ícone de hamburger sem rótulo e sem dica, então um usuário nunca percebe que o menu existe ou não pode dizer o que ele abre.
• Por que: um hamburger nu assume que o usuário já sabe o que o ícone significa e que um menu se esconde atrás dele. Esse é conhecimento que o usuário mobile pode não ter, e no mobile o menu escondido pode conter o único jeito de navegar pelo aplicativo (R-03).
• Correção: mantenha o menu descobrível: rotule o hamburger ("Menu"), ou mantenha os destinos primários visíveis e esconda apenas os secundários. Se um menu é o único jeito de alcançar algo importante, essa acessibilidade tem que ser óbvia.

Nav Inferior Que Consome Conteúdo

• Diga: uma barra de nav inferior fixa que fica sobre o conteúdo, cobrindo os últimos itens da lista, o botão final ou o formulário que o usuário estava tentando finalizar.
• Por que: espaço na tela no mobile é escasso, e uma nav inferior fixa que se sobrepõe ao conteúdo rouba esse espaço na base, onde as interações mais importantes geralmente vivem (R-03).
• Correção: dê ao conteúdo padding inferior suficiente para compensar a altura da nav, ou use scroll-padding-bottom no elemento de rolagem, e verifique se o último conteúdo interativo não está obstruído. A nav não deve ganhar de comer o próprio layout que serve.

Nav Que Pisca no Carregamento

• Diga: o layout mobile carrega primeiro como desktop (nav lado a lado, grade larga), então pisca para o layout mobile depois que o JavaScript hidrata ou a media query entra em vigor.
• Por que: R-34 exige que nenhum layout visível seja gerado por JavaScript. A piscada é o sintoma perfeito: o usuário vê um layout desktop por um momento e depois ele salta para mobile, então a experiência começa com um flash de layout errado.
• Correção: aplique o layout mobile como o padrão CSS (sem media query, o valor base), depois adicione o layout desktop como um aprimoramento dentro de uma media query. Dessa forma, o layout mobile é o primeiro a renderizar e o desktop é aplicado quando a tela o suporta, sem piscada.

Lista de Verificação da Habilidade de Layoutmobile

Execute esta lista junto com o Portão de Entrega do núcleo.

1. O layout tem pelo menos três estados definidos? (única coluna, intermediário, grade larga) ou quantos estados o conteúdo exigir.
2. Pontos de quebra correspondem a quebras de conteúdo? (não tamanhos de dispositivo ou larguras arbitrárias).
3. O tipo é fluido ou tem um passo mobile menor? (não px fixo da tela grande).
4. O scroll horizontal está zerado na largura alvo mais estreita?
5. Os alvos de toque têm 44x44px ou mais com gap adequado?
6. Nenhuma interação depende de hover sem um equivalente de toque.
7. A nav se reorganiza em um padrão mobile (nav inferior ou menu) sem sobrepor o conteúdo.
8. O layout mobile é o padrão CSS com o layout desktop como um aprimoramento para evitar piscada.