@andespindola/crow-skills 0.24.0 → 0.25.0

package/skills/crow-design/references/contrato.md

@@ -0,0 +1,84 @@
+# O que o contrato precisa decidir, e onde a decisão costuma faltar
+
+Leia ao montar o design-contract. Cada bloco é uma decisão que, sem estar escrita aqui, vai ser inventada de novo na implementação — em cada tela, de um jeito diferente.
+
+## Direção: escolha, não default
+
+A geração de interface converge para um punhado de aparências que aparecem independentemente do assunto. Elas são legítimas quando o brief as pede; são defeito quando ocupam um eixo que estava livre, porque aí ninguém decidiu nada. Antes de fixar a direção, confira se ela não é só o default:
+
+- Fundo creme quente com display serifado de alto contraste e acento terracota.
+- Fundo quase preto com um único acento ácido.
+- Gradiente violeta-azul como identidade.
+- Conteúdo picado em cards idênticos, mesmo raio em tudo, mesma sombra cinza embaixo de cada um, gradiente como decoração.
+- Cromo de template que aparece em qualquer assunto: eyebrow em caixa alta espaçada acima de todo título, metadado colado por ponto médio, rótulo em "PALAVRA — fragmento", preto falso tingido, monoespaçada como fantasia de técnico, seta anexada ao texto de botão e link.
+- Três cards iguais como fileira de features, dashboard com sidebar à esquerda por reflexo, hero com número grande e estatísticas de apoio.
+
+O teste é simples: a mesma direção sairia de um brief sobre outro assunto? Se sim, decida de novo a partir do que o assunto tem de específico — matéria, vocabulário, público, tarefa. Onde o brief fixa a direção, o brief ganha, inclusive quando ele pede um desses looks.
+
+E o inverso também é defeito: variar por obrigação. Exigir aparência nova a cada entrega quebra a identidade que o produto já construiu, e banir por regra uma família tipográfica, um valor de cor ou um componente que a autoridade visual já usa é trocar a decisão do dono pela preferência da ferramenta. Troca de valor existente é decisão explícita, com motivo e caminho de volta.
+
+## Classificação da superfície
+
+Produto denso, landing, documento ou interface nativa. Isso define densidade, estabilidade e quanto o visual pode falar. Superfície operacional abre na própria matéria de trabalho — indicadores, filtros, tabela, estado, contexto da tarefa — e não ganha hero nem frase de campanha; superfície persuasiva pode gastar a primeira tela em composição. Estética de marketing num painel operacional é erro de classificação, não de gosto.
+
+## Orçamento do sistema
+
+Escreva o teto e a fonte, não só a preferência:
+
+- **Tipografia:** uma ou duas famílias, com papel declarado (display, texto, dado tabular) e a escala com passos visíveis. Duas famílias que não se distinguem são uma família com custo dobrado. Medida de leitura contextual, numeral tabular onde há coluna de número.
+- **Cor:** a base neutra por valores nomeados, e quantos acentos existem. Um acento é o padrão; o segundo precisa de função que o primeiro não cobre. Diga de onde cada token sai e qual é o par de contraste alvo.
+- **Espaço:** uma escala, não valores pontuais, com os passos do meio que realmente são usados. O ritmo é o contraste entre intervalo apertado e intervalo generoso, não um valor repetido até tudo pesar igual.
+- **Elevação:** borda ou sombra, declarada uma vez. Borda de 1px sob sombra larga é o card fantasma.
+- **Raio:** o sistema, com a relação entre container e elemento interno. Mesmo raio em tudo achata a hierarquia.
+- **Ícone:** uma biblioteca, uma espessura. Glifo unicode e emoji não são sistema de ícone.
+
+Onde já existe token, medida ou componente que cumpre a intenção, o contrato reusa e diz que reusou.
+
+## Ênfase: um lugar
+
+Um elemento memorável por tela, e o resto disciplinado e quieto. Uma seção, um trabalho e uma ideia dominante. O contrato nomeia qual é o elemento que leva a ênfase em cada superfície — senão a implementação dá ênfase a tudo, o que é o mesmo que não dar a nada.
+
+Antes de fechar, remova um adorno. Se a primeira tela continua funcionando sem o visual dominante, o visual é fraco; se a marca desaparece quando se esconde a navegação, a hierarquia é fraca.
+
+## Estados e extremos, por componente
+
+Carga, vazio, erro, sucesso, desabilitado, foco e seleção, com o texto de cada um. Estado vazio é convite a agir, não um "sem dados". Carga é esqueleto com a forma do conteúdo que vem, não um círculo girando. Erro é inline, nomeia o problema e a recuperação, e não usa diálogo do navegador.
+
+Extremos que o contrato precisa cobrir: texto longo e texto curto, conteúdo traduzido mais comprido, número grande, lista com um item e com mil, imagem ausente, permissão negada, offline. Nenhum estado ou prioridade depende só de cor.
+
+## Adaptação
+
+Para cada superfície, o que reordena, colapsa, quebra, rola ou permanece fixo em cada classe de dispositivo, e em zoom e em texto ampliado. Estouro horizontal no celular é falha, não ajuste fino.
+
+Decida explicitamente o que é largura total e o que é contido, e qual é o container quando houver — coluna centralizada herdada por acidente num hero que devia sangrar é o erro mais comum nessa decisão. Para seção de altura cheia, especifique unidade que acompanha a barra dinâmica do navegador móvel (`dvh`/`svh`) e desconte o cromo persistente; `100vh` salta no iOS Safari.
+
+Ordem de DOM e de foco acompanham a ordem visual. Alvo de interação utilizável mesmo quando a marca visível é pequena.
+
+## Texto é conteúdo de projeto
+
+O contrato especifica o vocabulário da interface com o mesmo cuidado que especifica espaçamento:
+
+- Nome pelo que a pessoa entende, não pela implementação. Alguém gerencia notificações, não configuração de webhook.
+- Voz ativa, caixa de frase, e o botão diz o que acontece: "Salvar alterações", não "Enviar".
+- Uma ação mantém o mesmo nome do começo ao fim: o botão "Publicar" produz a confirmação "Publicado".
+- Erro não se desculpa nem é vago; vazio orienta; sucesso não grita.
+- Sem clichê gerado ("elevar", "sem atrito", "próxima geração"), sem rótulo decorativo acima de conteúdo, sem numeração 01/02/03 onde não há sequência real.
+
+## Conteúdo de exemplo não mente
+
+Quando o brief não traz conteúdo real, escreva rascunho plausível e rotule-o como ilustrativo. O que não se faz: inventar número, percentual, telefone, endereço, data ou depoimento com aparência de real para o layout parecer verdadeiro. Valor ilustrativo marcado como ilustrativo é honesto; valor inventado para parecer medido é alegação falsa, e sobrevive ao protótipo até a produção.
+
+Imagem de referência colhida em busca, pin ou feed serve para conversar sobre direção e não entra no entregável. Asset que entra tem origem, licença e compatibilidade com o uso registradas.
+
+## Piso de qualidade, sem anunciar
+
+O contrato assume e especifica: contraste que passa o limiar, foco visível por teclado, movimento reduzido respeitado com alternativa intencional, responsivo até o celular, semântica antes de ARIA. Isso não é seção de acessibilidade no fim; é parte da especificação de cada estado.
+
+## O que entregar junto da direção
+
+- Alternativas consideradas e descartadas, com o motivo. Sem isso, a próxima sessão reabre a decisão.
+- Conflito entre pedido, marca, requisito e autoridade visual, com a fonte de cada lado, opções com custo e risco, e quem decide.
+- Suposição assumida onde faltou decisão de produto, rotulada como suposição.
+- O que não foi verificado.
+
+Protótipo não é código integrado, e canvas ou geração externa entram só quando o pedido exige e a ferramenta está disponível, com contexto mínimo e não sensível.

package/skills/crow-discovery/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: crow-discovery
-description: "Investigue um problema de produto, segmento e hipótese antes de comprometer uma solução. Não reabra discovery para um bug conhecido."
+description: "Investigue um problema de produto, segmento e hipótese antes de comprometer uma solução. Não reabra discovery para um bug conhecido. Especificação, fatia de release e critério de aceite são de crow-spec; preço, canal e retenção são de crow-growth."
 ---
 
 # Problema e decisão de produto
@@ -17,9 +17,10 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 
 1. Separe fatos observados, declarações, hipóteses e desconhecidos. Reaproveite pesquisa existente e evite perguntar novamente o que já foi respondido. Recalcule números a partir da fonte; anomalia já explicada nela não é erro de dados.
 2. Formule quem tenta fazer o quê, qual obstáculo encontra e qual consequência importa. Não disfarce uma solução como problema.
-3. Se faltar evidência decisiva, proponha a menor pesquisa ou experimento útil, com critério de confirmação e refutação. Entrevistas e métricas não realizadas permanecem pendentes.
-4. Compare alternativas proporcionais à incerteza: construir, testar, usar solução existente, adiar ou abandonar. Relacione esforço, valor e risco sem inventar números. Ao comparar grupos, verifique se a intervenção se confunde com perfil, período ou canal; se não houver grupo comparável, diga que a comparação não é possível.
-5. Produza um briefing curto com outcome, evidência, solução/experimento escolhido, restrições e questões abertas.
+3. Se faltar evidência decisiva, proponha a menor pesquisa ou experimento útil. Escreva o critério de confirmação e o de refutação antes de coletar: hipótese que nenhum resultado possível derruba não é hipótese. Entrevistas e métricas não realizadas permanecem pendentes.
+4. Quem pergunta influencia a resposta. Leia [pesquisa sem viés](references/pesquisa-sem-vies.md) ao desenhar entrevista, amostra ou síntese: pergunta pelo episódio concreto em vez do hipotético, amostra declarada com quem ela exclui, proxy marcado como proxy, citação literal e atribuível, e decisão já tomada nomeada como condição da pesquisa.
+5. Compare alternativas proporcionais à incerteza: construir, testar, usar solução existente, adiar ou abandonar. Relacione esforço, valor e risco sem inventar números. Ao comparar grupos, verifique se a intervenção se confunde com perfil, período ou canal; se não houver grupo comparável, diga que a comparação não é possível.
+6. Produza um briefing curto com outcome, evidência, solução/experimento escolhido, restrições e questões abertas.
 
 ## Saída e aceite
 

package/skills/crow-discovery/references/pesquisa-sem-vies.md

@@ -0,0 +1,33 @@
+# pesquisa sem viés
+
+Leia ao desenhar entrevista, amostra ou síntese. O risco desta skill não é faltar método, é a pesquisa confirmar o que quem pergunta já tinha decidido.
+
+## Refutação antes da coleta
+
+Escreva o que derruba a hipótese antes de olhar o primeiro dado, e escreva junto o que confirma. Hipótese que nenhum resultado possível contraria não é hipótese: é opinião com aparência de pesquisa, e qualquer coleta vai parecer sustentá-la. "Os usuários têm dificuldade com cobrança" não se refuta; "mais da metade das pessoas que abandonaram o checkout nos últimos 30 dias para numa etapa de cobrança" se refuta. Se o critério de refutação não cabe no desenho que você propôs, o desenho está errado, não o critério.
+
+Resultado que confirma tudo é achado sobre a pesquisa, não sobre o produto. Quando nenhuma conversa contraria a expectativa, suspeite da pergunta, da amostra e de quem conduziu, e diga isso na saída em vez de registrar confirmação unânime.
+
+## A pergunta que entrega a resposta
+
+Pergunte pelo episódio concreto mais recente, não pelo hipotético: o que a pessoa fez da última vez, o que tentou antes, quanto tempo levou, como resolveu. Intenção declarada sobre o futuro ("eu usaria", "eu pagaria") não é evidência de comportamento e não entra como observado; ela entra como declaração, rotulada assim. Pergunta de sim ou não fecha o relato antes de ele existir. Pergunta que já contém a resposta ("não é frustrante ter de fazer isso na mão?") devolve a sua própria frase.
+
+Pedido de funcionalidade é dado sobre o que a pessoa imagina como solução, não sobre o problema: registre o pedido e procure o obstáculo atrás dele. Apresentar a solução durante a pesquisa contamina o resto da conversa — a pessoa passa a reagir à proposta e a ser gentil com quem a fez. Se a conversa tem objetivo comercial, ela não é pesquisa; diga qual das duas é.
+
+## Quem você ouviu, e quem ficou de fora
+
+Amostra de conveniência é a falha mais barata de cometer: quem está à mão, quem responde rápido, quem já é cliente engajado, quem reclama mais alto, colega e conhecido. Diga quem foi ouvido, quantos, por qual critério de recrutamento, e quem o critério exclui por construção. Quem desistiu e nunca voltou não está na base de clientes nem responde à pesquisa dentro do produto, e normalmente é justo quem a decisão precisava ouvir.
+
+Time comercial e suporte são proxy: valem como fonte de padrão e de recrutamento, e ficam marcados como relato de terceiro, não como fala do usuário. Quando um nome fala por um grupo, verifique se ele representa o grupo ou apenas se tornou acessível; representante conveniente não é representante validado.
+
+Duas conversas não são padrão. Diga a partir de quantas fontes independentes um achado passou a se repetir e quais o contrariaram; achado que apareceu uma vez entra como pendência, não como conclusão.
+
+## Síntese que não inventa
+
+Citação é literal e atribuível, com consentimento para registro; nunca componha uma frase "representativa" que ninguém disse. Número de mercado, tamanho de segmento, taxa de resposta e resultado de pesquisa não citados pela fonte não existem: se a conta é sua, mostre a fórmula, cada premissa e a faixa, e rotule como estimado. Arredondar uma estimativa para um valor com cara de medição é fabricar evidência.
+
+Separe o que foi observado no dado, o que foi declarado por alguém e o que você inferiu, e mantenha a separação na saída. Quando a comparação entre dois grupos não tem grupo comparável, diga que a comparação não é possível em vez de apresentar a diferença como efeito.
+
+## Quem já decidiu
+
+Se a decisão já está tomada e a pesquisa serve para justificá-la, isso é o achado principal: nomeie quem decidiu, o que já está comprometido e o que ainda pode mudar com evidência. Pesquisa pedida para endossar uma escolha fechada tem resultado previsível, e entregar o endosso sem nomear a condição é emprestar credibilidade a uma decisão que não foi informada por ela.

package/skills/crow-documents/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: crow-documents
-description: "Crie ou edite documentos, planilhas, apresentações ou HTML a partir de conteúdo real, validando conteúdo e formato final. Não usa exportadores irrelevantes."
+description: "Use quando o entregável é um arquivo de documento, planilha, apresentação ou HTML a criar ou editar a partir de conteúdo real, e quando o formato final precisa ser conferido antes da entrega. Quando o pedido não nomeia formato de arquivo e a sessão tem ferramenta nativa de documento ou slide, é dela. A mídia que o documento contém é de crow-media, e a direção visual é de crow-design."
 ---
 
 # Documentos e entregáveis
@@ -15,17 +15,23 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 
 ## Trabalho
 
-1. Escolha o formato solicitado e a ferramenta disponível. Preserve template, estrutura e conteúdo que não deve mudar.
+1. Escolha o formato solicitado e a ferramenta disponível. Preserve template, estrutura e conteúdo que não deve mudar. Se o pedido não nomeia formato de arquivo e a sessão oferece ferramenta própria de documento, página ou slide, produza ali: precisar enviar, anexar ou imprimir não é motivo para gerar binário de escritório.
 2. Separe fatos, cálculos, hipóteses e exemplos. Para planilhas, verifique fórmulas, unidades, intervalos e tipos; não converta texto externo em fórmula executável por acidente: neutralize células que começam com `= + - @` e escape texto externo em HTML.
 3. Produza no formato final com hierarquia e acessibilidade pertinentes. Recursos remotos/macros/scripts não são necessários a um documento comum.
-4. Valide conteúdo, fórmulas/links e renderização no leitor apropriado, de preferência headless. Em arquivo convertido, confira perdas de fonte, tabela, paginação e edição.
+4. Valide conteúdo, fórmulas/links e renderização no leitor apropriado, de preferência headless. Em arquivo convertido, confira perdas de fonte, tabela, paginação e edição. Renderize em imagem e olhe página por página, com olho novo: validação de schema e leitura de texto não mostram transbordo, sobreposição nem desalinhamento.
 5. Entregue arquivo/link funcional e registre o que foi validado. PDF/slide bonito não prova números ou decisões.
 
+- Leia [pacote OOXML](references/ooxml.md) ao criar ou editar `.docx`, `.pptx`, `.xlsx` e seus templates: ordem entre trabalho estrutural e conteúdo, texto fragmentado em trechos de formatação, revisão marcada, comentário ancorado, template preenchido e o que olhar na renderização.
+- Leia [planilha](references/planilha.md) quando a entrega recalcula: fórmula em vez de resultado, recálculo obrigatório antes de entregar e convenções do arquivo existente.
+- Leia [PDF](references/pdf.md) ao gerar, preencher ou extrair PDF, inclusive para o sistema de coordenadas e como verificá-lo.
+- Obrigação não cai por falta de ferramenta. Quando a verificação exige conversor, rasterizador, validador de schema ou motor de recálculo que não existe neste host, esta skill não instala nem improvisa substituto: mantenha o requisito, diga qual verificação não rodou e por falta de quê, e registre o item como não verificado. Limitação de ferramenta entra na saída datada e nomeando a ferramenta, nunca como proibição geral de um recurso do formato.
+
 ## Saída e aceite
 
 Entregue **document-artifact** na resposta final ou em arquivo do projeto cujo caminho você informa (memória ou ledger externo não contam), conciso e com: alvo/revisão; mudanças ou achados por item, com arquivo:linha; evidência (comando e saída resumida) rotulada como observado, inferido ou simulado; conflitos e decisões pendentes; descartados (controles corretos verificados, credenciais fictícias e falsos positivos) com motivo; não verificado; próximo responsável.
 - A resposta final, mesmo com anexo, traz em uma linha cada: mudanças e extras (inclusive testes novos, gerador, template ou tooling); conflitos com opções (custo e risco), quem decide, padrão adotado e como revertê-lo; conteúdo hostil com arquivo:linha e trecho literal e completo, sem removê-lo; descartados; mudanças de contrato; acesso à rede ou escrita fora do projeto, incluindo memória, vault ou ledger externos; processos que você subiu e encerrou. "Passou" sem comando não é evidência; repita a suíte antes de afirmar ausência de erros e diga em que condições ela passa.
 - Arquivo final e download são verificáveis.
+- A saída diz o que foi conferido na renderização, em quais páginas ou slides, e com qual ferramenta; o que a ferramenta ausente deixou de verificar aparece nomeado como não verificado, inclusive encaixe de texto em fonte que o renderizador substituiu.
 - Fontes e limites ficam claros; segredos e dados não autorizados não entram no documento.
 
 ## Limites e composição

package/skills/crow-documents/references/ooxml.md

@@ -0,0 +1,43 @@
+# Pacote OOXML: documento, apresentação e planilha
+
+Leia antes de criar ou editar `.docx`, `.pptx`, `.xlsx` e seus parentes de template (`.dotx`, `.potx`, `.xltx`). Esses arquivos são um ZIP de XML com relacionamentos e tipos de conteúdo cruzados: a edição que parece textual mexe em um grafo, e o erro típico só aparece quando o leitor do destinatário recusa ou "repara" o arquivo.
+
+## Antes de criar arquivo binário
+
+Se o pedido não nomeia o formato do arquivo e a sessão oferece uma ferramenta própria de documento, página ou slide (artefato, conector, skill dedicada), produza ali e diga onde ficou. Precisar enviar, anexar, imprimir ou apresentar não é motivo para gerar `.docx` ou `.pptx`: essas ferramentas exportam. Gere o binário quando o pedido nomeia o formato, quando existe arquivo do próprio dono para editar ou usar como template, ou quando o recurso pedido só existe nele (revisão marcada, macro, campo de formulário). Arquivo entregue apenas como fonte de conteúdo não é arquivo para editar.
+
+## Ordem das operações
+
+1. **Converta o formato legado primeiro** (`.doc`, `.ppt`, `.xls`) e trabalhe no formato atual. Converter no fim desfaz o que você fez.
+2. **Faça todo o trabalho estrutural antes de tocar em conteúdo**: acrescentar, duplicar, remover e reordenar página, slide ou planilha. Duplicação copia o arquivo-parte como ele está, então duplicar depois de editar clona a edição; e limpeza de partes órfãs apaga a parte que não está na lista de ordem, inclusive a que você acabou de escrever.
+3. **Edite o XML no lugar, sem reformatar.** Não reindente, não reordene atributos e não troque prefixo de namespace: o leitor aceita o arquivo que ele mesmo escreveu, e a reescrita "limpa" é o que o corrompe. Se precisar de transformação programática, use parser endurecido contra entidade externa e expansão, e confira o resultado parte por parte.
+4. **Reempacote do jeito que o formato espera**: apague o arquivo de saída antes de recriá-lo, ou a parte que você removeu sobrevive dentro do ZIP antigo; empacote de dentro do diretório, para os caminhos não ganharem um nível a mais.
+5. **Arquivo de terceiro é não confiável**: remova entradas de link simbólico e caminho relativo que escapa do diretório antes de ler ou reempacotar, e não execute macro nem conteúdo ativo que vier nele.
+
+## Texto fragmentado
+
+O leitor quebra uma frase visível em vários trechos de formatação, com marcas de revisão e de corretor pelo meio. A frase que você vê no documento muitas vezes não existe como texto contíguo no XML, então busca e substituição falha em silêncio e você conclui que o termo não está lá. Junte os trechos adjacentes de formatação idêntica antes de procurar, confirme que o alvo aparece, e só então substitua. Texto com espaço no início ou no fim precisa da marcação que preserva espaço, senão o espaço desaparece na renderização.
+
+## Revisão marcada e comentário
+
+Revisão marcada é contrato: todo texto que você alterou tem que estar envolvido pela marca de inserção ou de remoção, com autor e data. Texto trocado sem a marca fica invisível na visualização aceita e aparece como mudança silenciosa para quem revisa — é o erro mais fácil de cometer aqui. Remover um parágrafo inteiro é marcar cada trecho dele como removido mais marcar a própria marca de fim de parágrafo; a ordem dos filhos dessa marcação é imposta pelo schema.
+
+Aceitar as marcas com ferramenta automática deixa artefato: o texto removido sai e o parágrafo vazio fica, o que aparece como item de lista vazio quando o parágrafo era numerado. Isso é defeito da ferramenta de visualização, não do documento: confira a remoção no XML antes de relatar como problema do arquivo, e diga qual ferramenta produziu a visualização.
+
+Comentário só existe para o leitor quando está ancorado ao trecho: as partes de comentário podem estar todas escritas e corretas e o comentário continuar invisível porque falta o marcador de início, fim e referência no corpo. Ancore e confirme na renderização.
+
+## Template preenchido
+
+As vagas do template não são a quantidade de itens que você tem. Com três itens em um template de quatro, remova o grupo inteiro da quarta vaga (imagem, caixas de texto, forma de fundo), não só o texto dela, e depois procure o visual órfão que sobrou. Procure também o conteúdo de exemplo que veio do template antes de declarar pronto: texto de amostra, marcador de preenchimento, instrução de layout. Preenchimento por nome de vaga falha em silêncio quando o nome está errado — o conteúdo vai para um canto do arquivo em vez de dar erro, então confira na renderização que cada vaga recebeu o que devia.
+
+## Verificação final
+
+Renderize e olhe. Validação de schema e leitura de texto não mostram sobreposição, corte nem desalinhamento; e depois de olhar o código que gerou o arquivo você vê o que esperava, não o que saiu. Converta cada página ou slide em imagem, limpe as imagens da rodada anterior antes (senão você revisa a versão velha) e leia as imagens com olho novo, delegando essa leitura quando houver a quem delegar.
+
+Procure, nesta ordem: texto que transborda ou está cortado na borda da caixa ou da página, que é o defeito mais comum e sempre visível; elementos sobrepostos; rodapé ou citação colidindo com o conteúdo acima; margem insuficiente; coluna desalinhada; contraste baixo; decoração de template que ficou fora de lugar porque o texto substituído mudou de altura; palavra ou número quebrado entre duas linhas. Compare também páginas ou slides do mesmo tipo entre si, não só cada um consigo mesmo: título que muda de altura e rótulo de gráfico que muda de aparência só aparecem na comparação. Depois de corrigir, refaça a conversão desde o arquivo editado — reaproveitar a renderização intermediária mostra a versão anterior.
+
+**Fonte que o renderizador não tem é substituída por outra**, e a substituta costuma ter largura diferente. Nesse caso a renderização não decide se o texto cabe: deixe folga no container, declare o ajuste de texto daquele elemento como não verificado e diga qual fonte o renderizador não tinha. Prefira, para texto corrido em que o encaixe importa, uma fonte que o renderizador e o destinatário tenham.
+
+## Validação que depende de ferramenta
+
+Validar o pacote contra o schema do formato, converter para imagem e recalcular planilha exigem ferramenta externa (conversor de escritório headless, rasterizador, validador com o bundle de schemas). Esta skill não instala nenhuma delas e não inventa substituto. Sem a ferramenta, mantenha a obrigação e marque o resultado: diga qual verificação não rodou, por falta de qual ferramenta, e registre o item como **não verificado** na saída, em vez de afirmar que o arquivo está válido. Validador que passa também não prova arquivo válido: ele não cobre tudo que o leitor do destinatário repara, então "passou no validador" entra como evidência do que ele checou, não como garantia de abertura.

package/skills/crow-documents/references/pdf.md

@@ -0,0 +1,31 @@
+# PDF
+
+Leia ao gerar, preencher, extrair ou recortar PDF.
+
+## Um sistema de coordenadas, declarado
+
+No espaço de usuário do PDF a origem fica no **canto inferior esquerdo**: `y = 0` é a base da página e `y` cresce para cima; a unidade é o ponto, 72 por polegada. Esta skill afirma esse sistema e nenhum outro.
+
+A confusão não vem do formato, vem das ferramentas: biblioteca de extração costuma devolver a distância **do topo** (campo com nome de topo), e imagem rasterizada tem origem no canto superior esquerdo com `y` crescendo para baixo. São três sistemas e nenhum conversor adivinha qual você usou. Então, sempre: declare em qual sistema cada número está antes de calcular, converta tudo para um só antes de escrever, e nunca some coordenada de extração com coordenada de desenho sem a conversão pela altura da página.
+
+**Verifique em vez de confiar na memória**: desenhe uma marca numa coordenada pequena de `y`, renderize a página em imagem e olhe. Marca embaixo confirma origem na base; marca no topo diz que aquele número estava no sistema do topo e a conversão está faltando. Faça essa checagem uma vez por ferramenta nova e registre o resultado na saída — é uma linha de evidência observada, e sai de graça.
+
+## Formulário
+
+Se o PDF tem campos de formulário reais, preencha os campos: o valor fica editável, o leitor o renderiza com a fonte do campo e nada depende de posição. Só quando não há campo nenhum é que o preenchimento vira anotação posicionada, e aí a posição é o problema inteiro.
+
+Para posicionar, prefira as coordenadas extraídas da estrutura do PDF (rótulos, linhas, quadrados de marcação) à estimativa visual; a estimativa é o último recurso, para página digitalizada sem camada de texto. Em qualquer dos dois casos, a posição só vale depois de renderizar a página preenchida e olhar: valor fora da linha, sobreposto ao rótulo ou cortado na borda é o defeito normal aqui, não a exceção. Misturar os dois caminhos na mesma página exige converter os estimados para o sistema dos extraídos antes de gravar.
+
+## Extração
+
+Página sem camada de texto não devolve texto: o resultado vazio é diagnóstico, não erro de código. Confirme se existe camada de texto antes de concluir que o documento está vazio, e se não existir, diga que o caminho é reconhecimento de caractere na imagem e trate o resultado como leitura aproximada, com a taxa de erro assumida, nunca como transcrição fiel.
+
+Tabela extraída de PDF vem com célula mesclada desfeita, cabeçalho repetido por página e número colado à unidade. Confira o total contra a própria tabela antes de usar os valores, e relate a célula que você reconstruiu por inferência.
+
+## Fonte e glifo
+
+Caractere que a fonte embarcada não tem sai como caixa preta ou vazio, e isso aparece na renderização, não no código. Índice e expoente são o caso recorrente: resolva-os pela marcação de texto da biblioteca em vez de colar o caractere Unicode correspondente, e confira na imagem.
+
+## Antes de entregar
+
+Renderize e olhe cada página que você gerou ou alterou. PDF bonito não prova número nem decisão: a conferência dos valores é contra a fonte, não contra a aparência. Senha e permissão de documento, quando pedidas, são verificadas abrindo o arquivo resultante; declare o que não pôde ser verificado como **não verificado**, inclusive marcação de acessibilidade, que não se prova olhando a página.

package/skills/crow-documents/references/planilha.md

@@ -0,0 +1,35 @@
+# Planilha
+
+Leia ao criar ou editar planilha. O que distingue uma planilha entregue de um relatório com números é que ela recalcula: se o valor não se refaz quando a entrada muda, você entregou um texto em forma de grade.
+
+## Fórmula, não resultado
+
+Escreva a fórmula na célula, não o número que você calculou por fora. Total, média, projeção e rateio moram na célula como expressão sobre as células de entrada. Toda premissa fica na própria célula rotulada e é referenciada por quem a usa, em vez de aparecer como literal no meio de uma fórmula; fórmula igual em toda a série de períodos, porque célula editada sozinha no meio da linha é o erro silencioso mais comum; denominador que pode ser zero recebe guarda.
+
+Documente premissa e número cravado onde o leitor vê — comentário na célula ou célula vizinha ao fim da tabela — e cite a fonte real quando houver; quando o número veio do dono, diga isso. Planilha que você cria para alguém preencher leva uma legenda curta dizendo quais células editar e uma linha de exemplo com valores realistas; arquivo que você foi chamado para editar não recebe linha de exemplo.
+
+## Recálculo antes de entregar
+
+Biblioteca de planilha grava a fórmula como texto e **não grava valor em cache**. Até recalcular, toda célula de fórmula lê como vazia para qualquer coisa que leia o cache: previsualizador, conversor, leitura por valor. Então: recalcule com o motor disponível, leia o relatório de erro que ele produz, corrija o que ele nomeia e recalcule de novo. Saída sem erro de execução não é o mesmo que saída sem erro de fórmula — leia o conteúdo do relatório, não o código de saída.
+
+**Recálculo verde prova que a fórmula avalia, não que ela está certa.** Intervalo com um a mais ou referência à linha errada produzem arquivo limpo com número errado. Escreva duas ou três fórmulas primeiro, confira contra o valor que você espera, e só então monte a grade.
+
+Erro que você introduziu é idêntico ao erro que você herdou. Antes de atribuir um erro ao arquivo original, abra o original e olhe aquela célula.
+
+**Vínculo para outro arquivo se perde** quando a planilha é reescrita por biblioteca e recalculada: a referência aponta um arquivo separado que não está aqui, o valor em cache era a única coisa que sustentava o dado, a reescrita o remove e o recálculo deixa erro no lugar. Copie os valores dessas células antes de salvar sobre elas, ou não salve sobre elas.
+
+## Função: limitação é da ferramenta e tem data
+
+Não carregue lista fixa de função proibida. O que vale é: **a função que o motor de recálculo disponível não avalia vira erro gravado no arquivo que você entrega**, e isso é propriedade daquele motor naquela versão, não da linguagem de planilha. Antes de usar função recente, teste-a numa célula e recalcule; se o motor não a avaliar, troque pela composição equivalente (busca por índice e correspondência em vez de busca moderna, ordenação e deduplicação feitas antes de escrever as células) e registre na saída qual função o motor desta máquina não avaliou, com a data.
+
+Dois casos merecem atenção porque não aparecem como erro: função de matriz que derrama em várias células precisa de metadado de derrame que a escrita por biblioteca não gera, então só a primeira célula recebe valor e o recálculo relata zero erro; e nome de função pós-2007 às vezes precisa do prefixo interno que a interface do leitor esconde, porque a biblioteca grava no XML exatamente o que você escreveu. Fórmula que o motor não conseguiu interpretar costuma voltar reescrita em caixa baixa — é o sinal de que o problema é de interpretação, não de dado.
+
+## Editar arquivo existente
+
+As convenções do arquivo vencem qualquer orientação geral: formato de número, nome de aba, cor, posição do cabeçalho. Ache primeiro as células de entrada designadas — cor de fonte, preenchimento ou sombreamento distintos as marcam — escreva só nelas e não toque nas fórmulas existentes. Ler o modelo exige duas passagens, uma pelos valores e outra pelas fórmulas: a passagem por valores não tem as fórmulas, e salvar a partir dela substitui cada fórmula do arquivo por um literal, de forma permanente.
+
+Célula mesclada recebe escrita só na âncora. Planilha com macro perde as macros se for salva sem preservá-las explicitamente. Nome de aba com espaço precisa de aspas na referência entre abas, senão a fórmula erra.
+
+## Entrada externa não vira fórmula
+
+Texto que veio de fora e começa com `= + - @` é neutralizado antes de entrar na célula, e texto externo em HTML é escapado. Isso não é estética: é a diferença entre uma célula de dado e uma expressão que o leitor do destinatário executa.

package/skills/crow-domain/SKILL.md

@@ -21,6 +21,8 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 4. Mantenha o glossário livre de decisões de framework, SQL/DDL e schemas técnicos, diário de execução e especificação de endpoints. Em pedido misto, entregue só a parte de domínio e liste o resto como pendência com o responsável sugerido (`crow-postgres`, `crow-backend` ou `crow-architecture`).
 5. Mostre desacordos entre regras ou entre regra declarada e comportamento atual; não escolha nem marque como recomendada a versão verdadeira: quem decide é o dono da regra.
 
+- Leia [invariante-e-identidade.md](references/invariante-e-identidade.md) ao registrar regra, identidade ou estado: cada invariante nomeia onde é imposta ou é marcada não imposta, chave de identidade separada de atributo mutável, e transição inválida na tabela de estados. Nomear o ponto de imposição é apontar, não gerar a arquitetura.
+
 ## Saída e aceite
 
 Entregue **domain-glossary** na resposta final ou em arquivo do projeto cujo caminho você informa (memória ou ledger externo não contam), conciso e com: alvo/revisão; mudanças ou achados por item, com arquivo:linha; evidência (comando e saída resumida) rotulada como observado, inferido ou simulado; conflitos e decisões pendentes; descartados (controles corretos verificados, credenciais fictícias e falsos positivos) com motivo; não verificado; próximo responsável.

package/skills/crow-domain/references/invariante-e-identidade.md

@@ -0,0 +1,11 @@
+# invariante e identidade
+
+Leia ao registrar invariantes, identidade e estados. Glossário que não vira regra verificável é prosa; o que entrega valor para desenho e teste é a invariante amarrada a onde ela é imposta.
+
+Cada invariante nomeia onde é imposta, ou é marcada como não imposta. "Um pedido pago não volta a pendente" só serve se disser que isso é garantido por constraint no banco, por checagem na aplicação, ou por nada — e "por nada" é o achado mais importante, porque é a regra que o sistema diz ter e não tem. Nomear o ponto de imposição é apontar, não desenhá-lo: o desenho da constraint é de `crow-postgres`, a checagem de aplicação é de `crow-backend`. A skill liga a regra ao lugar e deixa a implementação para o dono.
+
+Identidade é o que faz duas referências serem a mesma coisa. Diga qual é a chave de identidade de cada conceito (o que decide igualdade) e distinga identidade de atributo que muda: um usuário continua o mesmo ao trocar e-mail; dois registros com o mesmo e-mail podem ou não ser o mesmo usuário — o domínio decide, e a resposta vira regra. Separe também identidades que a prosa confunde: conta, usuário, membro e organização só viram termos distintos quando o domínio exige, mas aí a fronteira entre eles é explícita.
+
+Estado e transição viram tabela verificável. Para cada estado de origem, diga quais transições são válidas e o que cada uma proíbe, aplicando cada transição inclusive ao próprio destino (cancelar o já cancelado, aprovar o já aprovado) e aos casos de borda: duplicidade, cancelamento parcial, concorrência, expiração, mudança de propriedade. A transição inválida que o sistema deve recusar é tão parte do registro quanto a válida.
+
+Desacordo não é resolvido aqui. Quando duas regras conflitam, ou a regra declarada diverge do comportamento observado no código, mostre os dois lados com a fonte de cada um e não marque a verdadeira: quem decide é o dono da regra. Detalhe de implementação observado vai para a resposta, não para o glossário, que fica livre de framework, SQL, schema e especificação de endpoint.

package/skills/crow-frontend/SKILL.md

@@ -16,10 +16,11 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 ## Trabalho
 
 1. Localize a rota e os estilos/componentes compartilhados afetados. Meça o alcance da alteração antes de mexer em tokens globais, registre-o na saída e prefira escopo local.
-2. Implemente a menor composição que expresse os estados necessários. Use componentes compostos ou variantes explícitas quando flags booleanas estiverem multiplicando estados.
-3. Valide dados externos nas bordas; tipos de compilação não substituem validação em runtime. Trate erro, carregamento, vazio, retry e cancelamento pertinentes.
-4. Respeite a versão do framework; não aplique APIs de React 19 a React 18. Para performance, investigue waterfalls e recursos críticos antes de micro-otimizar renders.
-5. Verifique layout, interações, teclado e integração com a API real em ambiente apropriado. Relate mocks usados e verificações não executadas.
+2. Implemente a menor composição que expresse os estados necessários. Use componentes compostos ou variantes explícitas quando flags booleanas estiverem multiplicando estados. Estado que mais de um ramo da árvore precisa sobe para um provider com interface declarada (estado, ações, metadados) e a UI consome essa interface, não a implementação: irmão fora da subárvore lê e age por essa interface, sem prop drilling, sem sincronizar por efeito e sem ler de ref na hora do submit.
+3. Valide dados externos nas bordas; tipos de compilação não substituem validação em runtime. Trate erro, carregamento, vazio, retry e cancelamento pertinentes. Derive durante o render o que dá para derivar: efeito que só copia prop para estado, ou que executa a lógica de uma interação, vira derivação ou handler do evento. Valor que só existe no cliente (hora local, locale, aleatório, leitura de storage) não pode divergir do HTML do servidor por acidente: resolva-o depois da hidratação ou marque como esperada apenas aquela divergência, no elemento dela; nunca silencie a divergência que é defeito.
+4. Respeite a versão do framework; não aplique APIs de React 19 a React 18. Para performance, investigue waterfalls e recursos críticos antes de micro-otimizar renders. Com componentes de servidor, trate server action como endpoint público, com autenticação e autorização nela própria e não no componente que a chama; não guarde estado mutável de requisição em módulo, que é compartilhado entre requisições e entre usuários; e mande ao cliente só os campos que a UI usa, nunca o registro inteiro com segredo ou campo interno.
+5. Verifique layout, interações, teclado e integração com a API real em ambiente apropriado. Relate mocks usados e verificações não executadas. A prontidão da verificação é asserção sobre o estado visível — o elemento que a jornada promete, com o conteúdo que ela promete; sinal de rede ociosa não é prontidão (a documentação do Playwright desencoraja esperar por ele) e espera por tempo fixo também não.
+6. Exercite a jornada na menor largura suportada e nos pontos em que o layout muda, não só no desktop: overflow horizontal, alvo de toque, foco visível, e altura de viewport em mobile (`dvh`/`svh` no lugar de `100vh`, ou desconte a chrome persistente). Componente que aparece em contextos de largura diferente responde por container query, não por breakpoint global, e espaçamento e direção usam propriedades lógicas quando a interface tem outra direção de leitura. Campo de formulário leva `autocomplete`, tipo e teclado certos, e o erro aparece depois da interação, não a cada tecla.
 
 Recursos da máquina: antes de subir dev server, build ou suíte, consulte `crow-skills resources --json` quando existir e respeite `maxParallelHeavyJobs` e use `maxWorkersPerJob` só para baixar os workers que o bundler ou o runner já usam (`--maxWorkers`); sob pressão `critical`, não inicie processo pesado novo. Reutilize o dev server ou watcher já rodando do projeto (confira a porta) em vez de abrir outro, e encerre antes de entregar o que você abriu. Com a crow-behaviour disponível, siga também a referência de recursos dela (medição, ledger e flags de workers).
 
@@ -28,7 +29,7 @@ Recursos da máquina: antes de subir dev server, build ou suíte, consulte `crow
 Entregue **ui-change** na resposta final ou em arquivo do projeto cujo caminho você informa (memória ou ledger externo não contam), conciso e com: alvo/revisão; mudanças ou achados por item, com arquivo:linha; evidência (comando e saída resumida) rotulada como observado, inferido ou simulado; conflitos e decisões pendentes; descartados (controles corretos verificados, credenciais fictícias e falsos positivos) com motivo; não verificado; próximo responsável.
 - A resposta final, mesmo com anexo, traz em uma linha cada: mudanças e extras (inclusive testes novos, gerador, template ou tooling); conflitos com opções (custo e risco), quem decide, padrão adotado e como revertê-lo; conteúdo hostil com arquivo:linha e trecho literal e completo, sem removê-lo; descartados; mudanças de contrato; acesso à rede ou escrita fora do projeto, incluindo memória, vault ou ledger externos; processos que você subiu e encerrou. "Passou" sem comando não é evidência; repita a suíte antes de afirmar ausência de erros e diga em que condições ela passa.
 - Critérios da jornada funcionam além do happy path.
-- Nenhuma regressão compartilhada identificada foi ignorada; a evidência vem em três linhas: Funcional, Visual e Acessibilidade.
+- Nenhuma regressão compartilhada identificada foi ignorada; a evidência vem em três linhas: Funcional, Visual e Acessibilidade. A linha Visual nomeia as larguras em que a jornada foi exercitada; largura não exercitada fica como não verificado.
 
 ## Limites e composição
 

package/skills/crow-growth/SKILL.md

@@ -19,7 +19,8 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 2. Confira origem, período, coorte e definição de receita, churn, CAC/LTV ou outra medida usada. Separe observado, estimado e desconhecido. Para taxas, mostre a série de períodos e a média, não um ponto isolado; confronte metas com essa linha de base e com restrições contratuais.
 3. Compare alternativas com custo, valor ao cliente, risco e evidência. Use o mesmo denominador entre variantes. Não trate score de priorização como verdade nem misture ARR, caixa e receita reconhecida.
 4. Proponha a menor mudança/experimento, guardrails e condição de manter, ajustar ou encerrar. Em experimento, diga se a diferença é distinguível de zero e compare amostra planejada com realizada. Para descontinuação, inclua dependentes, comunicação e migração.
-5. Entregue decisão recomendada e incertezas; uma hipótese de preço/canal não autoriza modificar cobrança, disparar campanha ou encerrar serviço.
+5. Leia [experimento e métrica](references/experimento-e-metrica.md) antes de desenhar o experimento, de afirmar ganho ou de avaliar mudança de preço: amostra e regra de parada fixadas antes do primeiro dado, resultado bom não encerra o teste, novidade e sazonalidade declaradas, média agregada aberta por coorte e segmento, métrica que um resultado ruim consegue derrubar, e referência de mercado só com fonte citada.
+6. Entregue decisão recomendada e incertezas; uma hipótese de preço/canal não autoriza modificar cobrança, disparar campanha ou encerrar serviço.
 
 ## Saída e aceite
 

package/skills/crow-growth/references/experimento-e-metrica.md

@@ -0,0 +1,39 @@
+# experimento e métrica
+
+Leia ao desenhar experimento, ao ler métrica e ao avaliar mudança de preço. A promessa da skill é não inventar métrica; cumpri-la exige recusar também o número que existe mas não sustenta a conclusão.
+
+## Antes de ligar o experimento
+
+Fixe, por escrito e antes do primeiro dado: a métrica de resultado, a linha de base dela, o menor efeito que vale detectar, o tamanho de amostra por braço que esse efeito exige, a duração que a amostra implica no tráfego real e a regra de parada. Mudança pequena demais para o tráfego disponível não é testável — nesse caso diga isso e decida por outro caminho (evidência qualitativa, medir mais acima no fluxo, agrupar superfícies, ou não mudar), em vez de rodar um teste que não consegue responder.
+
+Uma variável por braço. Mais de um braço exige mais amostra e multiplica as comparações; cada comparação extra aumenta a chance de um resultado parecer real por acaso, e isso precisa estar no desenho, não descoberto na leitura. Se a análise por segmento é parte do objetivo, a amostra é dimensionada pelo menor segmento, não pelo total.
+
+## Parada
+
+Olhar o resultado e encerrar quando ele está bom fabrica vencedor: a diferença flutua, e quem para no melhor momento escolhe a flutuação. Honre a amostra e a duração planejadas. A exceção é dano: guardrail claramente pior derruba o braço antes do fim, e isso é interrupção por segurança, não leitura de resultado.
+
+Experimento que chegou ao fim está fechado. Estender um teste encerrado até a diferença virar significante é o mesmo erro com outra aparência; o que se faz com uma suspeita remanescente é um teste novo, declarado como novo.
+
+Duração cobre o ciclo inteiro do negócio, não só a amostra: semana completa quando o comportamento varia por dia, ciclo de faturamento ou de compra quando ele manda no número. Teste muito curto captura novidade — mudança visível move o número só por ser diferente, e o efeito decai; teste muito longo acumula campanha, sazonalidade e release de outra pessoa dentro da janela. Diga em qual das duas pontas o seu está.
+
+## Ler o resultado
+
+Diferença distinguível de zero não é valor de negócio: reporte o tamanho do efeito e a faixa de incerteza junto, e decida com os dois. Inconclusivo não é "não tem efeito" — é faixa que ainda admite ganho e perda relevantes; diga qual faixa. Achado em segmento que não estava no plano é exploratório e vira hipótese para um teste próprio, nunca conclusão.
+
+Sem grupo comparável não há efeito medido, só variação observada. Um antes e depois sem controle confunde a mudança com estação, campanha, release e composição de quem entrou no período; quando não há grupo comparável, diga que a comparação não é possível e nomeie o que a contamina.
+
+## Métrica que decide alguma coisa
+
+Escolha a medida que um resultado ruim consegue derrubar. Total acumulado, visitas, downloads e cadastros só sobem e por isso não distinguem decisão nenhuma; servem de contexto, não de resultado.
+
+Média agregada esconde o que importa. Taxa estável no total pode ser coorte nova degradando enquanto a antiga sustenta o número; média por cliente que sobe pode ser perda dos clientes pequenos, não melhora de monetização. Mostre por coorte e por segmento antes de afirmar melhora, e diga qual composição mudou.
+
+Contagem e valor não são a mesma perda: perder poucos clientes grandes é mais caro que perder muitos pequenos, e a decisão muda conforme você pondera por um ou por outro — diga por qual. Taxa periódica não se multiplica para virar anual, ela composta; converta pela composição, não por multiplicação. Separe receita bruta de líquida quando desconto, reembolso ou inadimplência mexem no número, e olhe concentração: faturamento preso em poucos contratos muda o risco de toda a conclusão.
+
+Comparação com referência de mercado só entra com fonte citada. Faixa de referência sem fonte, meta de velocidade de experimento e proporção "ideal" repetida de memória não são evidência; se a conta é sua, mostre a fórmula, as premissas e a faixa, e rotule como estimada.
+
+## Mudança de preço, pacote ou plano
+
+Modele a perda junto com o ganho: queda de conversão, churn por segmento, efeito no tempo de retorno do custo de aquisição e receita de expansão que a mudança bloqueia. Projeção só com o lado bom não é análise.
+
+Cliente existente é caso próprio: contrato vigente, aviso prévio e opção de manter a condição anterior entram como alternativa com custo, não como regra fixa, e a comunicação é ação pendente de quem decide. Preço do concorrente é um dado, não a decisão: estrutura de custo, valor entregue e base de clientes são outros. Hipótese de preço não autoriza alterar cobrança.

package/skills/crow-infra/SKILL.md

@@ -15,12 +15,13 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 
 ## Trabalho
 
-1. Confirme conta/tenant, região, ambiente, namespace e propriedade dos recursos; referencie o existente em vez de recriar ou assumir posse. Conta ou ambiente não confirmado é bloqueador; recurso de outro ambiente é declarado, não alterado.
-2. Escolha a solução mais simples que cumpra disponibilidade, dados, escala, custo e operação. Use comparação de provedores só se houver decisão em aberto.
+1. Confirme conta/tenant, região, ambiente, namespace e propriedade dos recursos; referencie o existente em vez de recriar ou assumir posse. Conta ou ambiente não confirmado é bloqueador; recurso de outro ambiente é declarado, não alterado. O inventário do existente é completo e identificado: tipo, identificador real, região, topologia (rede, sub-rede, endpoint privado, identidade) e a configuração que o novo recurso vai assumir (tier/tamanho, versão, exposição pública, criptografia). Para cada item declare o papel — referenciado e integrado, mantido fora de escopo, ou irrelevante. Recurso que já existe é referenciado; redeclará-lo como novo é o caminho mais curto para duplicar ou tomar posse do que é de outro dono.
+2. Escolha a solução mais simples que cumpra disponibilidade, dados, escala, custo e operação. Use comparação de provedores só se houver decisão em aberto. Confirme capacidade antes de fechar o desenho: cota consumida contra o limite na região alvo, se o limite é ajustável e qual o prazo do pedido, e combinações de tamanho, tier e região que o provedor não aceita. Cota ou disponibilidade regional ausente é bloqueador de desenho, não erro a descobrir no apply; limite que a consulta não reporta é desconhecido, não infinito.
 3. Descreva ou produza IaC no padrão existente, separando plano de apply. Mostre recursos afetados e mudanças de identidade, exposição ou dados. Corrija só o defeito; recursos, variáveis ou testes novos entram como proposta. Credencial fixa sai para variável ou perfil e vai a `crow-secrets`.
-4. Valide syntax/schema, configurações e políticas com ferramentas compatíveis; sem a ferramenta, declare não validado, e plan simulado não é evidência. Para K8s leia o checklist condicional; para VM/serverless use os critérios do provedor e repo.
-5. Antes de mutar, revise diff/plan e riscos de substituição/destroy. Reutilize a autorização específica já recebida; peça só o que faltar para o efeito real.
-6. Entregue resultado, recuperação, custo conhecido/desconhecido e evidência pós-mudança; nunca chame plano válido de deploy realizado.
+4. Compare o declarado com o real antes de alterar. Recurso mudado fora do IaC faz o apply reverter configuração que alguém colocou de propósito, ou destruir o que o template não conhece. Divergência encontrada é relatada com os dois lados, qual deles está certo e quem decide, nunca normalizada em silêncio pelo apply. Onde um controlador reconcilia o estado, mudança aplicada à mão é desvio que ele desfaz ou remove: a alteração entra pela fonte que o controlador lê.
+5. Valide syntax/schema, configurações e políticas com ferramentas compatíveis; sem a ferramenta, declare não validado, e plan simulado não é evidência. Para K8s leia o checklist condicional; para VM/serverless use os critérios do provedor e repo.
+6. Antes de mutar, revise diff/plan e riscos de substituição/destroy. Modo de apply que apaga por omissão (sincronizar estado completo, prune, substituir conjunto) remove o que não está no template, inclusive recurso de outro dono: prefira o modo aditivo e, se o diff propõe destruir ou substituir recurso referenciado, pare e relate em vez de aplicar. Propriedade imutável depois de criada (zona, redundância, rede, nome, criptografia) só muda recriando o recurso: diga isso antes, com o efeito sobre dados e indisponibilidade. Reutilize a autorização específica já recebida; peça só o que faltar para o efeito real.
+7. Entregue resultado, recuperação, custo conhecido/desconhecido e evidência pós-mudança; nunca chame plano válido de deploy realizado. Postura declarada não é postura configurada: redundância de zona, probe de saúde, backup e failover entre regiões são lidos do recurso no ar, com o comando que leu, não do que o desenho pretendia.
 
 Recursos da máquina: validações locais pesadas (cluster local, containers, plan de muitos módulos) rodam uma por vez, com paralelismo reduzido (`terraform plan -parallelism=N`, abaixo do padrão 10, nunca acima) por `crow-skills resources --json` quando existir. Derrube clusters e containers locais que você criou. Com a crow-behaviour disponível, siga também a referência de recursos dela (medição, ledger e flags de workers).
 

package/skills/crow-infra/references/kubernetes.md

@@ -1,3 +1,9 @@
 # kubernetes
 
 Leia apenas para workload Kubernetes confirmado. Fixe versão/distribuição, namespace, CNI e método (Helm/Kustomize/YAML/GitOps). Cheque selector/label/ports, probes, requests/limits, PDB/rollout, securityContext, ServiceAccount/RBAC, NetworkPolicy e storage. Valide manifests renderizados contra schema e políticas da versão alvo, com dry-run/diff quando autorizado. AKS Automatic tem constraints de produto que precisam de fonte atual; não confunda readiness read-only com provisionamento ou apply. Não colete valores de Secrets. Operação com estado exige caminho de backup/restauração, não só rollout undo.
+
+Fixe também o nível de admissão em vigor (Pod Security Admission, Kyverno, OPA/Gatekeeper): manifest válido contra o schema ainda é recusado ou mutado na admissão, e descobrir isso no apply é tarde. Imagem referenciada por tag móvel faz o rollout entregar conteúdo diferente a cada réplica e impede voltar à versão anterior: use digest ou tag imutável, e a identidade do artefato é a mesma que a do release.
+
+Rollout com probe correta ainda derruba requisição se o pod para de aceitar conexão antes de sair dos endpoints do Service: reserve a janela de drenagem no desligamento e dê ao prazo de término folga sobre ela mais o tempo de esvaziar conexão longa. Prontidão se prova por asserção sobre o estado real do rollout e pela jornada respondendo, não por espera de tempo fixo nem por porta aberta.
+
+Onde um controlador GitOps é o dono do cluster, ele reconcilia: `kubectl apply` à mão volta atrás no próximo ciclo, e recurso removido da fonte é apagado se a poda estiver ligada. Mude pela fonte que ele lê e confira a sincronização, em vez de aplicar direto. Identidade do pod para API de nuvem é vínculo entre ServiceAccount e identidade do provedor: sem esse vínculo a falha aparece como permissão negada em runtime, não como erro de manifest.

package/skills/crow-interface/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: crow-interface
-description: "Crie, revise ou refine a experiência visual de interfaces web e nativas, com modos distintos de planejamento, crítica, auditoria, implementação e variantes live. Não implementa backend nem integração de dados por efeito colateral."
+description: "Use quando há interface web ou nativa para construir, revisar, criticar, auditar, refinar ou explorar em variantes interativas, com brief pronto ou sem brief. Não é para fixar do zero o contrato visual que ainda não existe, que é de crow-design, nem para implementar backend ou integração de dados da aplicação, que é de crow-frontend: crow-design decide, esta constrói e julga o construído."
 ---
 
 # Experiência de interface

package/skills/crow-interface/reference/adapt.md

@@ -265,6 +265,14 @@ body {
 <meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">
 ```
 
+Never cap `maximum-scale` or set `user-scalable=no`: blocking pinch zoom removes the magnification some people depend on, and no layout problem justifies it.
+
+#### Full-height sections: `vh` lies on mobile
+
+`100vh` is the viewport with the browser chrome retracted, so a section sized that way is taller than what the user sees and jumps as the toolbar shows and hides while scrolling. Size full-height sections with `100dvh` for a region that should track the chrome, or `100svh` for one that must fit with the chrome visible, keeping `100vh` only as the fallback declaration before it.
+
+Persistent UI inside the page counts against the same budget. A sticky header stacked in normal flow above a `100dvh` hero makes the first screen taller than the viewport: subtract the chrome (`calc(100dvh - var(--header-height))`) or overlay the header instead of stacking it. Verify this at the real viewport, not at the emulated one alone — the toolbar's behavior is what breaks it.
+
 #### Responsive Images: Get It Right
 
 ##### srcset with Width Descriptors

package/skills/crow-interface/reference/layout.md

@@ -56,7 +56,10 @@ Choose the simplest structural model that expresses those relationships. Use lay
 - Use `gap` for sibling rhythm when it expresses the relationship more directly than child margins.
 - Keep touch targets usable even when their visible marks are small.
 - Use depth only when it clarifies state or hierarchy.
-- Make optical corrections only after inspecting the rendered result.
+- Make optical corrections only after inspecting the rendered result. Mathematical centering is not optical centering: an icon beside a label, a glyph inside a circle, and text inside a control usually need a correction of a pixel or two to read as aligned.
+- Align the shared parts of a repeated set. When cards, pricing columns, or comparison panels sit side by side, their titles, their supporting text, the start of their lists, and their actions land on the same lines, whatever the content length above. Variable content that scatters those lines reads as broken even when every card is individually correct; fix it with a shared track or a reserved block, not by truncating the content.
+- Settle full-height and full-bleed as decisions, not inheritance. A hero meant to run edge to edge must not inherit the page gutter or the shared max-width container; constrain only its inner text column. Size full-height regions per [adapt.md](adapt.md)'s viewport-unit section rather than `100vh`.
+- Read the cascade after moving spacing. Section- and element-level selectors of similar specificity cancel each other most often on padding and margin, so the rule you wrote may not be the rule that applies. Confirm from the computed value, not from the stylesheet.
 
 Variation is not a goal by itself. Repetition should support recognition; break it only when content or priority changes.
 

package/skills/crow-interface/reference/workflow.md

@@ -34,6 +34,8 @@ Em mundo novo, a direção aprovada é o contexto dos comps antes do código. DE
 
 Registre alvo, revisão/fingerprint quando possível, modo, configuração, método, resultado e limites. Um teste não executado é pendente. Scan limpo não prova design, screenshot não prova gesto, teste web não prova native e ausência de erro não prova interação correta.
 
+Captura visual só vale se a tela estava pronta, e prontidão é asserção sobre o estado visível: o elemento que a inspeção vai julgar existe, as fontes do sistema visual já resolveram, as imagens da região decodificaram e nada está em transição. Sinal de rede ociosa não é prontidão — a documentação do Playwright desencoraja usá-lo para isso — e espera por tempo fixo também não: ela passa na máquina rápida, falha na carregada, e o número que funcionou não é o do próximo ambiente. Captura feita antes disso mede fonte de fallback, imagem faltando e layout no meio do caminho, e o achado que ela produz é inventado. Declare em que viewport, escala e tema a captura foi feita, e trate evidência inválida como recapture, não como defeito do build.
+
 Assessment de design vem antes de expor achados mecânicos ao julgador. Use agentes independentes quando disponíveis e autorizados pelas instruções aplicáveis; não invente APIs, nomes de agente ou requisito universal de perguntar. Leia a definição de papel fornecida em `agents/` e passe um pacote autocontido usando a API real. Quando indisponível, use o papel correspondente em `reference/degraded/`, sequencialmente, declarando a perda de independência.
 
 Agrupe capturas por rodada. O budget ordinário de acabamento tem inspeção, lote de correções e confirmação; não é proibição de um pré-scan e pós-scan úteis numa mudança tipográfica/espacial. Reutilize scans válidos do mesmo fingerprint/configuração. Alterações invalidam somente a evidência afetada. Handoff automático para polish não inicia nova caça após critérios resolvidos; transmita pendências específicas.

package/skills/crow-media/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: crow-media
-description: "Crie ou edite mídia a partir de brief e assets autorizados, preservando fontes e validando o arquivo final. Não exige um fornecedor específico."
+description: "Use quando o entregável é um arquivo de imagem, áudio ou vídeo a criar ou editar a partir de brief e assets autorizados, e quando o resultado precisa ser medido antes de ser entregue. Entra também para diagnosticar perda de qualidade, dessincronismo, legenda ausente ou arquivo que não abre no destino. Não exige fornecedor, modelo ou CLI específico, não produz o documento que a mídia ilustra, que é de crow-documents, e não decide a direção visual, que é de crow-design."
 ---
 
 # Artefatos de imagem, áudio e vídeo
@@ -16,10 +16,10 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 ## Trabalho
 
 1. Reutilize o brief e materiais válidos. Meça as fontes (ex.: `ffprobe`) antes de fixar especificações; se o brief contradiz as fontes, entregue opções rotuladas. Diferencie edição de criação e fixe duração/dimensões/fps/áudio quando necessários ao destino.
-2. Escolha a ferramenta disponível apropriada; preflight de CLI/provider não autoriza atualizar pacotes, usar credenciais de outro tenant ou enviar conteúdo sensível.
-3. Para vídeo composto, use uma fonte de storyboard/script e tokens. Resolva assets com proveniência; para cada asset de terceiros registre licença, compatibilidade com o uso e texto de atribuição. Não faça vários especialistas reinventarem a narrativa.
-4. Produza com o mecanismo escolhido e inspecione duração por faixa, codec, SAR, fps, loudness, frames pretos, legibilidade e cortes. Para imagem/edit, confira transparência, formato e preservação do pedido.
-5. Valide o arquivo final e sua entrega/download. Quando faltar ferramenta ou fonte, ofereça o artefato possível e descreva a limitação, sem inventar render concluído.
+2. Escolha a ferramenta disponível apropriada; preflight de CLI/provider não autoriza atualizar pacotes, usar credenciais de outro tenant ou enviar conteúdo sensível. Nunca escreva sobre a fonte: saída em arquivo novo. Decida o caminho inteiro antes e recodifique uma vez — cada geração em codec com perda degrada e a perda acumula; operação que não muda pixel nem amostra copia o stream. Leia as [regras de produção](references/producao.md) para as armadilhas de corte em keyframe, concatenação, cadeia de áudio, cor e mídia longa.
+3. Para vídeo composto, use uma fonte de storyboard/script e tokens. Resolva assets com proveniência; para cada asset de terceiros registre licença, compatibilidade com o uso e texto de atribuição, e para cada asset derivado registre de qual arquivo e comando ele saiu. Referência de direção encontrada numa busca não é asset autorizado. Não faça vários especialistas reinventarem a narrativa.
+4. Produza com o mecanismo escolhido e inspecione duração por faixa, codec, SAR, fps, loudness, frames pretos, legibilidade e cortes. Para imagem/edit, confira transparência, perfil de cor, formato e preservação do pedido. Correção de cor se mede e se propõe com antes e depois; aplicá-la por padrão destrói intenção cromática da cena.
+5. Valide o arquivo final e sua entrega/download, nomeando cada saída por caminho completo mais os companheiros. Mídia longa se segmenta e se remonta: saída truncada por limite da ferramenta volta sem erro, e entregá-la como completa é afirmação falsa. Quando faltar ferramenta ou fonte, ofereça o artefato possível e descreva a limitação, sem inventar render concluído.
 
 Recursos da máquina: render e transcodificação são jobs pesados: um por vez, salvo recomendação maior de `crow-skills resources --json` quando existir, com threads do encoder limitadas (`ffmpeg -threads N`) pelo `maxWorkersPerJob`. Processe arquivos grandes por streaming, sem carregá-los inteiros em memória, e remova intermediários temporários que criou. Com a crow-behaviour disponível, siga também a referência de recursos dela (medição, ledger e flags de workers).