Tend A11y

Tend A11y — o arauto

Encontre o único problema de acessibilidade, UX ou tom de cópia de maior prioridade no markup deste repositório, corrija-o minimamente, verifique e entregue o diff para revisão. Um problema por execução.

0. Carregar configuração

• Leia .claude/tend/config.yaml. Use skills.a11y (globs proibidos, notes). Esta habilidade não possui módulos de capacidade — pule completamente a verificação de módulos, não há etapa de modules: aqui.
• Sem configuração? Execute no nível core: suposições core SvelteKit + TS, proibições conservadoras embutidas (nunca toque em lockfiles, CI, .env, config). Emita uma vez: "execute tend-onboard para refinar." Continue.

1. Triagem

LEITURA OBRIGATÓRIA references/scan-core.md.

• Estabeleça o conjunto de caminhos proibidos: skills.a11y.off-limits da configuração mais as barreiras embutidas (nunca toque em lockfiles, configuração de CI, .env, configuração do projeto ou lógica de backend/rotas de API — esta habilidade é apenas de apresentação).
• Estabeleça pontos de entrada: arquivos de markup deste repositório — componentes .svelte, rotas +page.svelte / +layout.svelte, ou quaisquer arquivos de template que a stack realmente use. Verifique skills.a11y.notes em busca de um diretório de biblioteca de componentes nomeado (ex.: src/lib/components/ui) — se existir, suas exportações são a lista de alvos "use isto em vez de HTML bruto" para a Fase 2.
• Leia 1–2 componentes existentes antes de escanear para aprender as convenções reais de biblioteca de componentes e de status/carregamento do repositório — você precisa do padrão real em mãos antes de poder chamar um desvio dele de violação.

Critério de conclusão: conjunto de caminhos proibidos conhecido, convenção de biblioteca de componentes (se houver) identificada, globs de pontos de entrada identificados.

2. Escanear — ordem de prioridade, pare no primeiro acerto real

Ordenado do mais valioso (mais silencioso para usuários) primeiro — pare no primeiro acerto real e baseado em evidências:

1. HTML interativo bruto onde existe equivalente na biblioteca de componentes — um <button>/<a>/<input> bruto ao lado de uma exportação Button/Link/Input em outro lugar do repositório.
2. Elementos interativos apenas com ícone ou primariamente com ícone sem nome acessível — sem aria-label, sem texto oculto visualmente, sem fallback title.
3. <img> sem alt — um atributo ausente é a violação; um alt="" intencionalmente vazio em uma imagem decorativa não é.
4. Entradas de formulário sem um rótulo associado — sem label for=, aria-label, ou prop de rótulo da biblioteca de componentes. Audite a contagem renderizada, não apenas o template: entradas geradas dentro de um loop ({#each} ou equivalente) produzem N controles anônimos em tempo de execução.
5. role="button" (ou um onclick simples em um elemento não interativo) sem o manipulador de teclado correspondente — onkeydown para Enter + Espaço. O <button> nativo obtém isso gratuitamente; isso só é acionado na escotilha de escape de elemento bruto.
6. Feedback assíncrono de sucesso/erro/carregamento renderizado como um elemento simples e não anunciado — sem role="alert"/role="status", sem aria-live, e sem nenhum primitivo de banner/toast de biblioteca de componentes existente já usado em outro lugar no repositório.
7. Uma ação destrutiva (excluir/remover/redefinir) sem nenhuma etapa de confirmação antes de entrar em vigor.
8. Violações de tom de cópia, verificadas contra a lista de permissão/negação orientada por configuração (skills.a11y.notes, ou um documento de tom do projeto para o qual ela aponta). Se não houver lista específica do repositório, recorra aos padrões genéricos: um suavizador imperativo como "Por favor" precedendo uma instrução de validação/erro ("Por favor, insira um nome" vs. "Insira um nome"), ou um ponto de exclamação desnecessário em cópia de instrução/confirmação rotineira. Escaneie tanto o texto do markup renderizado quanto strings literais dentro de blocos <script> — cópia atribuída a uma variável, passada para uma chamada de toast/alerta ou definida via .textContent/.innerText vive em blocos de script, não apenas no markup, e uma busca apenas no markup perderá as strings de validação reais.

3. Corrigir — uma alteração atômica

Antes de editar, responda:

1. Isso é genuinamente confuso ou inacessível para um usuário real (leitor de tela, apenas teclado ou alguém lendo o tom) — não uma preferência estilística minha?
2. A correção toca apenas apresentação/cópia — sem lógica, sem backend, sem nova dependência?
3. Já existe um equivalente na biblioteca de componentes para este padrão? Se sim, use-o em vez de fazer a correção manual em HTML bruto (não coloque role="alert" em um <div> bruto se o repositório já tiver um componente de status/banner que o carrega).

Verificação de base: execute o lint/typecheck do repositório (e o conjunto de testes, se rápido) antes de editar — anote quaisquer falhas pré-existentes para não atribuí-las incorretamente depois.

Orçamento de tamanho: ≤50 linhas alteradas para uma correção de markup/estrutura, ≤10 linhas para uma correção puramente de texto de cópia; um componente ou página por execução.

Nunca toque em caminhos proibidos. Se a correção real exigisse tocar em um, pare e relate o motivo em vez de forçá-la em outro lugar.

4. Verificar e apresentar

Execute novamente o lint/typecheck (e testes, se você os executou na etapa 3) — interrompa apenas se sua alteração introduzir uma nova falha; falhas pré-existentes não são suas para corrigir aqui. Mostre o diff. PARE — não confirme, não abra um PR.

NUNCA

• NUNCA sinalize ou corrija mais de um problema por execução Em vez disso: Pare de escanear no primeiro acerto real, corrija-o, apresente-o. Por quê: Diffs de acessibilidade/cópia em lote são difíceis de revisar individualmente e escondem qual correção específica causou uma regressão.

• NUNCA faça uma correção manual em HTML bruto quando um equivalente na biblioteca de componentes já existir Em vez disso: Use o Button/Input/Link/componente de banner de status do próprio repositório. Por quê: Uma correção paralela e isolada cria um segundo padrão inconsistente em vez de convergir para aquele em que o resto do repositório já confia — a próxima auditoria o sinalizará novamente como desvio.

• NUNCA invente uma regra de tom de cópia não baseada em skills.a11y.notes ou em um padrão genérico claramente rotulado Em vez disso: Use a lista de permissão/negação orientada por configuração, ou declare explicitamente que está recorrendo a um padrão genérico. Por quê: Uma regra inventada na hora não é reutilizável nem auditável na próxima execução, e pode contradizer o estilo real da casa do repositório.

• NUNCA escaneie apenas o markup e pule blocos <script> para strings de cópia Em vez disso: Verifique também strings literais dentro de blocos <script> — a cópia de validação e feedback é frequentemente atribuída lá, não escrita diretamente no template. Por quê: A string real voltada ao usuário é frequentemente uma variável interpolada no template; uma busca apenas no markup corresponde ao local da interpolação, não ao texto ofensivo real, e não relata nada para corrigir.

• NUNCA toque em caminhos proibidos ou confirme/abra um PR Em vez disso: Respeite skills.a11y.off-limits mais as barreiras embutidas; pare após apresentar o diff. Por quê: O trabalho desta habilidade termina em "diff verificado, pronto para revisão humana" — confirmar ou tocar em caminhos excluídos remove a porta de revisão da qual todo o fluxo de trabalho depende.

Arquivos

• references/scan-core.md — verificações principais (carregadas na Fase 1)
• evals/ — asserções de avaliação ai-forge