@andespindola/crow-skills 0.24.0 → 0.26.0

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

@@ -1,6 +1,6 @@
 ---
 name: crow-infra
-description: "Planeje ou altere infra/IaC da plataforma existente com validação, custo e recuperação proporcionais. Não impõe Kubernetes ou multi-cloud."
+description: "Planeje ou altere infra/IaC da plataforma existente com validação, custo e recuperação proporcionais. Entra quando muda o recurso que recebe o artefato; promover um artefato já construído pelo fluxo do repo é de crow-release. Não impõe Kubernetes ou multi-cloud."
 ---
 
 # Workload e infraestrutura
@@ -15,14 +15,15 @@ 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. Confirme também a identidade efetiva com que você vai agir, e não só o alvo: qual principal está resolvido (usuário, role assumida, federação, identidade de workload), a que conta ele pertence e se ele tem a permissão de escrita que o passo exige. Principal federado tipicamente não cria nem altera identidade, e descobrir isso no meio do apply vira erro de permissão diagnosticado como erro de configuração. Faltando a capacidade, pare e nomeie a concessão exata que falta e quem a concede, em vez de tentar variações da mesma operação até uma passar. Identidade que você criar recebe só as ações e os recursos deste trabalho, escopadas na criação: política ampla de conveniência, ou revisão de permissão adiada para o primeiro erro de acesso, é a permissão errada que fica.
+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).
+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. Recurso remoto ou cobrado que você criou para validar — endpoint, cluster gerenciado, GPU, fila, volume, bucket — tem dono e fatura: antes de criá-lo, tenha o caminho de remoção e a ordem que ele exige, porque dependente que o pai não apaga por omissão (componente, política de escala, alarme, volume, snapshot, registro de DNS) sobrevive à remoção do principal e segue cobrando ou bloqueando o nome. Ao terminar, remova e confirme pela leitura do provedor, não pelo retorno do comando de remoção; estado transitório que recusa a remoção é espera, não falha. O que não removeu vai na saída com identificador real, região e o comando que o remove. Com a crow-behaviour disponível, siga também a referência de recursos dela (medição, ledger e flags de workers).
 
 ## Detalhes condicionais
 

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).
 

package/skills/crow-media/references/producao.md

@@ -0,0 +1,63 @@
+# Produção de mídia: fonte preservada, operação medida, arquivo final conferido
+
+Leia antes de transformar um arquivo que você não gerou e antes de afirmar que um render ficou pronto. As armadilhas aqui custam qualidade que não volta.
+
+## A fonte é irrecuperável; trate-a como tal
+
+- **Nunca escreva sobre a fonte.** Saída em arquivo novo, fonte intocada, inclusive em "ajuste rápido". Pipeline que sobrescreve perde o único original que existia.
+- **Meça antes de especificar.** Duração, resolução, SAR/DAR, fps e modo (constante ou variável), codec e perfil, profundidade de bits, espaço de cor, canais e taxa de amostragem do áudio, loudness. Especificação escrita sem medir a fonte produz destino que a fonte não alcança.
+- **Cada recodificação perde.** Toda geração em codec com perda degrada, e a perda acumula: cortar, depois recortar, depois concatenar em três passos recodificando dá três gerações. Decida o caminho inteiro antes e recodifique uma vez, no fim.
+- **Operação que não muda pixel nem amostra não recodifica.** Corte, concatenação e troca de container copiam o stream. Recodifique só quando a operação exige: mudar resolução, aspecto, fps, codec, ou aplicar efeito.
+- **Upscale não cria informação.** Ampliar e depois entregar como se fosse captura nativa é alegação falsa sobre o arquivo. Declare o que foi ampliado e a partir de quê.
+
+## Armadilhas da operação sem recodificação
+
+- **Corte com cópia de stream só acerta em keyframe.** O ponto de entrada vai para o keyframe anterior, então o corte pedido e o corte obtido divergem — às vezes por segundos. Se o ponto exato importa, recodifique o trecho; se não importa, cole o ponto obtido no relato em vez de repetir o pedido.
+- **Concatenação com cópia exige parâmetros idênticos.** Mesmo codec, perfil, resolução, fps, e mesmo layout de áudio. Fontes diferentes concatenadas assim produzem arquivo que abre e falha no meio, ou que dessincroniza. Normalize antes, ou recodifique na junção.
+- **Container esconde o problema.** Arquivo que o player local abre pode falhar no destino: perfil de codec não suportado, fps variável, áudio em canal inesperado. Teste no destino real, não só no player do sistema.
+- **Corte não destrutivo quando existir.** Em composição, página ou timeline, recortar por janela de reprodução ou máscara no render mantém a fonte inteira e reversível. Produzir arquivo físico só quando a entrega é o arquivo.
+
+## Áudio
+
+- **Ordem da cadeia importa.** Subtraia antes de somar: filtro corretivo primeiro, nível depois, relação entre faixas depois, caráter e teto no fim. Compressor antes de um corte de graves passa o tempo perseguindo ruído de fundo.
+- **Não se diagnostica o espectro absoluto de uma voz desconhecida.** Fundamental, formante e queda natural no fim da frase variam mais entre duas pessoas do que a maioria dos defeitos. Compare sempre dentro do próprio arquivo: contra o original limpo, se existir, ou contra as pausas — o que se ouve numa pausa é aditivo, e o espectro da pausa é o canal, não a voz. Comparar com média publicada ou com voz sintetizada de controle produz diagnóstico errado. Sem original e sem silêncio utilizável, um defeito tonal estático é indeterminado: diga isso e ofereça as leituras compatíveis, em vez de escolher uma e construir uma cadeia sobre ela.
+- **Música sob voz não se resolve baixando a música.** Abaixar a cama inteira funciona e custa toda a presença dela durante a locução. Ceda à voz as faixas de frequência que ela ocupa e devolva o resto, e faça a cessão seguir o envelope da fala, não uma profundidade fixa — profundidade fixa afina a música também nas pausas.
+- **O processamento vai na faixa que cede, apontando para a que manda.** Faixa processada contra si mesma é defeito, não escolha sutil. Quando há várias falas, aponte para o grupo delas, não para cada clipe: lista de clipes precisa estar exaustivamente certa e envelhece na próxima edição.
+- **Efeito com cauda alonga a faixa.** Reverb e delay fazem o resultado terminar depois da duração nominal. Isso é esperado; reserve a cauda na mixagem em vez de cortá-la.
+- **Mixagem se confere ouvindo o render, não lendo o grafo.** E o que não dá para conferir entra como não verificado.
+
+## Imagem, cor e tratamento
+
+- **Correção se mede e se propõe, não se aplica em silêncio.** Medir exposição, balanço e contraste é evidência; aplicá-los por padrão não é. Uma "correção" que puxa a cena para cinza neutro destrói pôr do sol, neon e qualquer intenção cromática. Mostre a medida e a proposta, com antes e depois, e deixe a decisão com o dono.
+- **Não suba o nível de representação sem necessidade.** Ajuste paramétrico reversível resolve exposição, sombras, contraste e temperatura. Congelar isso numa tabela de cor ou num bitmap achatado é irreversível e some com o parâmetro; use a forma pesada só quando o pedido a exige ou quando o dono forneceu o arquivo.
+- **Transparência e espaço de cor sobrevivem à conversão ou não.** Confira canal alfa, perfil de cor e matiz depois de cada conversão de formato; alfa perdido só aparece sobre fundo diferente do que você testou.
+- **Formato e tamanho casam com o destino.** Entregar no dobro da dimensão de exibição desperdiça, e abaixo dela borra. Nome de arquivo descreve o conteúdo.
+- **Máscara geométrica não substitui recorte real.** Círculo, polígono ou gradiente aproximando a silhueta de um objeto fotográfico lê pior que não recortar.
+
+## Vídeo composto
+
+Uma fonte de verdade para roteiro e storyboard, e tokens para o visual. Não deixe vários especialistas reinventarem a narrativa: quem produz a cena lê o roteiro aprovado, não o reescreve.
+
+Antes de concluir, inspecione: duração por faixa e total, sincronismo de áudio e imagem no começo e no fim, fps e codec do arquivo entregue, loudness, frames pretos ou congelados no corte, legibilidade do texto na menor tela do destino, legenda sincronizada quando houver fala, e área segura. Frame preto no fim e dessincronismo progressivo são os dois defeitos que passam em inspeção por amostragem.
+
+## Mídia longa e saída truncada
+
+Transcrição, análise e descrição de arquivo longo batem em limite de saída da ferramenta e voltam cortadas sem erro. Segmente a entrada, processe por partes com sobreposição nas bordas, remonte e confira que a última fala do arquivo está no resultado. Entregar transcrição truncada como completa é afirmação falsa sobre o arquivo, e é silenciosa.
+
+Arquivo grande se processa por streaming, não carregado inteiro em memória. Pré-dimensione quando a ferramenta tem limite de tamanho, e diga que a entrada foi reduzida.
+
+## Diagrama e artefato revisável
+
+Quando o artefato precisa ser revisado, versionado e corrigido, a fonte em texto (Mermaid, DOT, PlantUML, SVG escrito) vale mais que o bitmap: ela entra em diff e a correção é cirúrgica. Renderize para imagem ou PDF quando o pedido é o arquivo, ou quando o destino não lê a fonte. Entregue a fonte junto do render e diga as suposições que você fez sobre entidades, relações e ordem.
+
+## Proveniência e direitos
+
+- **Cada asset de terceiro registra origem, licença, compatibilidade com o uso e o texto de atribuição exigido.** Imagem encontrada numa busca, pin, feed ou banco de referências não é asset autorizado: ela pode servir como referência de direção e não entra no entregável.
+- **Asset derivado aponta para a fonte.** Recorte, upscale, grade e conversão registram de qual arquivo saíram e com qual comando; sem isso ninguém reproduz nem reverte.
+- **Voz, rosto e identidade de pessoa real exigem consentimento explícito e registrado**, por uso e por peça.
+- **Fonte tipográfica tem licença própria.** Índice de fontes e nome de família não autorizam embutir o arquivo.
+- **Não exija fornecedor.** Escolha entre as ferramentas presentes. Quando o pedido só é alcançável com serviço externo, credencial ou instalação nova, diga o que falta, entregue o artefato possível e pare — não instale, não atualize pacote, não use credencial de outro contexto e não envie conteúdo sensível para um serviço só para completar o preflight.
+
+## Entrega
+
+O relato nomeia cada arquivo final por caminho completo e aberto a partir da raiz do projeto, mais os companheiros (transcrição, manifest, miniatura, derivado otimizado). Nome de arquivo solto não é entrega. Diga o comando que mediu o resultado e o que ele mostrou; "renderizou" sem medida não é evidência, e render que não terminou não se relata como concluído.

package/skills/crow-native-mobile/SKILL.md

@@ -19,7 +19,7 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 2. Implemente o fluxo e estados com trabalho pesado fora da thread de UI e cancelamento/teardown corretos. Não suponha que background execute indefinidamente. Arquivos e trabalhos têm nome único, limpeza e falha com retry limitado.
 3. Trate permissões como escolha do usuário: solicite no momento pertinente ao recurso, respeite negativa e indique retomada explícita; não abra prompts em loop. Isole a decisão de permissão em lógica testável sem dispositivo, cobrindo concedida, negada, negada de vez e revogada depois de concedida.
 4. Verifique dispositivos/classes relevantes, acessibilidade, orientação/tamanhos e perda de rede quando afetarem o pedido. Teste API e persistência como contratos distintos. Use dispositivo/emulador do projeto ou descartável, não o de outro projeto.
-5. Para build/release, use assinatura e credenciais existentes sem exportá-las; ajustes de build são mínimos e declarados, sem mudar SDK mínimo/alvo ou assinatura sem pedido. Para performance, encaminhe medição à disciplina de validade.
+5. Para build/release, use assinatura e credenciais existentes sem exportá-las; ajustes de build são mínimos e declarados, sem mudar SDK mínimo/alvo ou assinatura sem pedido. Compilar não prova assinatura: um build que compila ainda falha em assinatura, provisioning e entitlements (no iOS, Archive é sinal distinto de Build, e é ele que libera TestFlight e loja). Para release, confirme o artefato assinado no canal real de distribuição, não só a compilação local ou de CI. Para performance, encaminhe medição à disciplina de validade.
 
 Recursos da máquina: um emulador ou simulador por vez, reutilizando o já aberto do projeto; builds Gradle/Xcode com workers reduzidos (`--max-workers`, `-jobs`; por padrão usam todas as CPUs) pelo `maxWorkersPerJob` de `crow-skills resources --json` quando existir. Sob pressão `critical`, não inicie emulador nem build. Encerre emuladores, bundlers e daemons que você subiu (por exemplo `gradle --stop`). 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-observe/SKILL.md

@@ -16,10 +16,14 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 ## Trabalho
 
 1. Defina qual pergunta o sinal deve responder e quem age. Reutilize o provedor existente antes de adicionar SDK ou coletor.
-2. Associe ambiente/release e correlação mínima: propague o ID recebido (ex.: `traceparent` W3C), saneando em vez de descartar. Redija segredos e minimize dados pessoais, preservando IDs operacionais não pessoais. Controle cardinalidade, volume e retenção.
-3. Instrumentar não muda contrato HTTP, validação de entrada nem nomes de alerta/métrica existentes; se for preciso, deixe como proposta (mudança de contrato), salvo pedido explícito. Escolha sinais ligados à experiência: falhas de jornada, latência/filas, saturação e dependências. Diferencie alerta acionável de dashboard informativo.
-4. Verifique captura e roteamento com evento seguro e esperado. Não dispare incidente real nem use dados pessoais para testar.
-5. Entregue alerta/runbook com limiar, responsável, diagnóstico inicial e rollback. Ajuste ruído a partir de evidência observada.
+2. Associe ambiente/release e correlação mínima: propague o ID recebido (ex.: `traceparent` W3C), saneando em vez de descartar. Redija segredos e minimize dados pessoais, preservando IDs operacionais não pessoais. Controle cardinalidade, volume e retenção. Quando o mesmo sinal sai por mais de um destino (span, log, bucket, armazém de dados), a redação vale por destino: desligar conteúdo no trace não desliga o que já é exportado por outro caminho, e cada destino precisa da própria prova. Separe o destino por ambiente: evento de desenvolvimento ou homologação no projeto de produção gasta cota e aciona plantão por engano. Se a leitura do sinal depende de artefato de build (source map, símbolos), publicá-lo faz parte do release ou a pilha chega ilegível.
+3. Instrumentar não muda contrato HTTP, validação de entrada nem nomes de alerta/métrica existentes; se for preciso, deixe como proposta (mudança de contrato), salvo pedido explícito. Escolha sinais ligados à experiência: falhas de jornada, latência/filas, saturação e dependências. Cubra também o caminho de erro não tratado: exceção sem captura, rejeição assíncrona, falha na fronteira do componente de interface e requisição que volta com erro. Código que engole o erro antes do coletor faz o sistema parecer saudável; trate isso como defeito do sinal, com arquivo:linha. Diferencie alerta acionável de dashboard informativo.
+4. Verifique captura e roteamento com evento seguro e esperado. Não dispare incidente real nem use dados pessoais para testar. Ausência de evento não é ausência de falha: coletor que não subiu, identidade sem permissão de escrita no destino, amostragem agressiva ou filtro amplo produzem painel vazio. Prove o caminho ponta a ponta até o destino final e confirme release, ambiente e campos esperados no evento que chegou; sem isso, o sinal é não verificado. Instrumentação nova não pode substituir nem silenciar a existente: depois de instalar, confira que os sinais anteriores continuam chegando.
+5. Entregue alerta/runbook com limiar, responsável, diagnóstico inicial e rollback. Todo alerta nasce ligado a um runbook e a um sinal de usuário; alerta sem ação definida sai, em vez de ser silenciado aos poucos até ninguém olhar. O limiar vem do comportamento medido do serviço e é datado, não de número de catálogo. Agrupe eventos repetidos do mesmo incidente, e trate reabertura de problema já corrigido como alerta próprio. Ajuste ruído a partir de evidência observada.
+
+## Detalhes condicionais
+
+- Leia [cardinalidade.md](references/cardinalidade.md) ao criar ou alterar métrica, rótulo ou campo indexado.
 
 ## Saída e aceite
 

package/skills/crow-observe/references/cardinalidade.md

@@ -0,0 +1,11 @@
+# cardinalidade
+
+Leia ao criar ou alterar métrica, rótulo ou campo indexado.
+
+Cada combinação distinta de valores de rótulo é uma série temporal própria. Rótulo que carrega identificador de usuário, de requisição, de sessão, de pedido, URL crua com parâmetro, mensagem de erro ou endereço de origem multiplica as séries pelo tamanho do tráfego: o custo de ingestão e retenção cresce junto e o backend de métricas cai antes de o painel ficar pronto. A falha aparece como ingestão rejeitada, consulta que expira ou fatura fora de proporção, nunca como erro no código que instrumentou.
+
+Antes de instrumentar, escreva o conjunto de valores possíveis de cada rótulo e confirme que ele é fechado e pequeno: ambiente, release, região, serviço, rota normalizada (o padrão da rota, não o caminho com o id dentro), código de status, resultado. Dado de variação alta pertence a log estruturado ou a atributo de trace, onde a busca é por evento e não por série, e o identificador que liga os dois é o de correlação.
+
+Conteúdo de payload no sinal — corpo de requisição, prompt, resposta, documento — multiplica custo e risco ao mesmo tempo: capture amostra com taxa declarada, redija antes de sair do processo e informe a retenção. Amostragem é parte do contrato do sinal: diga a taxa na saída, porque ela muda o que o alerta consegue detectar.
+
+Ao reduzir cardinalidade de uma métrica existente, o histórico não se converte: a série antiga morre e a nova começa vazia. Isso quebra alerta e painel que dependiam dela. Declare a mudança, o período sem comparação possível e quem precisa saber, em vez de trocar o rótulo em silêncio.

package/skills/crow-performance/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: crow-performance
-description: "Investigue lentidão e valide otimizações web, API, banco ou nativas com workload controlado. Não reporta ganho com um único antes/depois."
+description: "Investigue lentidão e valide otimizações web, API, banco ou nativas com workload controlado. Entra quando o alvo é latência ou throughput medido e o comportamento está correto; defeito reproduzível, mesmo intermitente, é de crow-debug. Não reporta ganho com um único antes/depois."
 ---
 
 # Otimização com evidência
@@ -15,12 +15,12 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 
 ## Trabalho
 
-1. Diferencie avaliar evidência, medir e otimizar. Avaliação não autoriza medir/alterar/reverter; use só os dados disponíveis e proponha o experimento que falta. Nos modos executáveis autorizados, fixe workload, cache/warmup, concorrência e instrumento e estime o ruído no sistema inalterado.
-2. Use profiler/trace/plano para localizar custo; isso não mede por si o ganho de uma correção. Web: rede/render/bundle; serviço: filas/spans/carga; Postgres: plano/locks/pool; nativo: threads/alocações/lifecycle. Escolha só o ramo pertinente.
-3. Faça a menor alteração testável. Confirme que o mecanismo proposto realmente entrou em efeito.
+1. Diferencie avaliar evidência, medir e otimizar. Avaliação não autoriza medir/alterar/reverter; use só os dados disponíveis e proponha o experimento que falta. Nos modos executáveis autorizados, fixe workload, cache/warmup, concorrência e instrumento e estime o ruído no sistema inalterado. Ruído maior que o efeito esperado é bloqueador de medição: estabilize o ambiente ou declare a mudança não mensurável com este instrumento, antes de alterar qualquer coisa.
+2. Use profiler/trace/plano para localizar custo; isso não mede por si o ganho de uma correção. Antes de escolher o alvo, atribua o tempo por estágio (origem, rede, cache, parse/execução, render; ou aplicação, fila, dependência) e confirme que o custo apontado está no caminho que o usuário espera: topo de perfil fora da jornada é otimização sem efeito percebido. Agregue por código próprio, não por folha de framework, que mostra onde o tempo é gasto e não onde é causado. Número agregado de processo ou requisição inteira serve de sanidade, não de prova. Web: rede/render/bundle; serviço: filas/spans/carga; Postgres: plano/locks/pool; nativo: threads/alocações/lifecycle. Escolha só o ramo pertinente.
+3. Faça a menor alteração testável. Confirme que o mecanismo proposto realmente entrou em efeito. Otimização que adia ou move custo (carga sob demanda, cache, fila, trabalho em segundo plano) não o elimina: meça também o momento em que ele reaparece e o caminho que passou a pagá-lo, não só a condição inicial.
 4. Compare condições alternadas A/B/A/B quando viável; se o baseline deriva, estabilize ou declare o resultado inconclusivo. Latência pede percentis e n, não só média.
-5. Apresente dispersão, custo e possíveis regressões de cauda. Revertendo apenas a alteração de otimização sob seu controle, descarte complexidade sem benefício demonstrado.
-6. Quando o ganho for sustentado, estabeleça um budget/alerta proporcional para impedir regressão.
+5. Apresente dispersão, custo e possíveis regressões de cauda. Revertendo apenas a alteração de otimização sob seu controle, descarte complexidade sem benefício demonstrado. Resultado negativo é resultado: registre na saída a medida que não sustentou o ganho, junto com a reversão, para a próxima tentativa não repetir o caminho.
+6. Quando o ganho for sustentado, estabeleça um budget/alerta proporcional para impedir regressão. O limiar vem da medida que você fez neste alvo, com a condição em que vale (dispositivo, rede, dataset, concorrência); número de catálogo sem essa condição não é budget.
 
 Recursos da máquina: medição pede máquina estável. Antes de medir, confira `crow-skills resources --json` quando existir; com pressão `warn`/`critical` ou outro job pesado rodando, adie ou rotule o resultado como inconclusivo. Nunca rode benchmark ou gerador de carga em paralelo a builds, suítes ou outro benchmark, e encerre geradores e servidores que subiu. 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-performance/references/measurement.md

@@ -1,3 +1,9 @@
 # measurement
 
 Use ao desenhar o experimento. Baseline repetido (comece com pelo menos cinco execuções), carga fixa e warmup separado. Cinco execuções são um início para investigar ruído, não suficiência estatística nem amostra adequada automaticamente a p95/p99. Relate min/mediana/max para recursos e percentis pertinentes com n para latência; informe quando a amostra não sustenta caudas. Para Core Web Vitals de campo, use p75 e distinga campo de laboratório. Controle cache, CPU/rede, temperatura e concorrência. Serviços: gerador que espera cada resposta pode esconder filas (coordinated omission). Na web, não conclua com uma única nota Lighthouse. A₂ longe de A₁ invalida a comparação B. Quando o ambiente não permite controle, rotule a medida como indicativa.
+
+Case o instrumento com a pergunta: perfil amostrado, flame graph ou trace distribuído respondem onde está o custo; A/B em workload fixo responde se a mudança ajudou; perfil por thread ou por span responde qual estágio; profiler de alocação e snapshot de heap respondem se o gargalo é memória e não CPU. Trocar um pelo outro é a origem mais comum do ganho que não se sustenta.
+
+Em serviço, o nível de carga faz parte da medida: latência a dez requisições por segundo não diz nada sobre duzentas. Declare a concorrência e meça a curva de latência contra vazão, não um ponto. Separe tempo de servidor de tempo de fila: serviço rápido com requisição esperando para ser aceita continua lento para quem chama. Descarte a janela de warmup explicitamente, em vez de diluí-la na média.
+
+Na web, cache frio e cache quente são cenários distintos: relate qual dos dois você mediu e não compare um com o outro. Throttling de CPU e rede tem de ser idêntico entre as execuções, senão você comparou duas máquinas. Nota de ferramenta de laboratório varia muito entre execuções: use a mediana de várias e trate campo (p75 de sessões reais) como o alvo, laboratório como a verificação.

package/skills/crow-platform/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: crow-platform
-description: "Coordene uma plataforma ou iniciativa que atravessa produto, design, engenharia e operação. Não use para um bug ou ajuste isolado."
+description: "Coordene uma plataforma ou iniciativa que atravessa produto, design, engenharia e operação, mapeando as etapas que faltam e o contrato entre elas. Não use para um bug ou ajuste isolado; a coordenação da execução e a delegação são de crow-behaviour."
 ---
 
 # Entrega de plataforma
@@ -16,9 +16,9 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 ## Trabalho
 
 1. Identifique a menor entrega completa e o estado atual: problema aberto, especificação, implementação ou operação. Reutilize decisões válidas; não reinicie fases concluídas.
-2. Liste somente as etapas que faltam, cada uma com id, responsável lógico, entrada, saída, condição de passagem e evidência esperada. Escolha especialistas por intenção, stack e risco, não por palavras isoladas.
+2. Liste somente as etapas que faltam, cada uma com id, responsável lógico, entrada, saída, condição de passagem e evidência esperada. Escolha especialistas por intenção, stack e risco, não por palavras isoladas. Cada etapa nomeia o efeito que ela deve produzir na jornada e como esse efeito será observado depois de entregue; etapa sem efeito observável é candidata a corte, não a execução. Marque o grau de compromisso: etapa cujo escopo ainda depende de decisão ou descoberta pendente entra como não comprometida, com a decisão que a destrava, para o mapa não ser lido como promessa de data. Trabalho habilitador — migração, deprecação, dívida que a fatia exige — é etapa do mapa com dono e evidência, não pressuposto implícito.
 3. Defina um contrato comum entre UI, API e dados antes de separar implementação: operações, códigos de erro e convenções como fuso e unidades. Planeje homologação e recuperação com o desenho, não só depois de terminar o código.
-4. Entregue por fatias verticais: uma jornada atravessa interface, regra, persistência e teste. Paralelize apenas trabalho independente com ownership de arquivos definido.
+4. Entregue por fatias verticais: uma jornada atravessa interface, regra, persistência e teste. O corte está certo quando a fatia é entregável e verificável sozinha: se ela só produz efeito junto com outra, o corte foi por camada disfarçado de fatia e precisa ser refeito. Dependência externa — outro time, fornecedor, API de terceiro, aprovação — vira fronteira de corte, e a fatia que depende dela declara o que avança enquanto ela não chega. Paralelize apenas trabalho independente com ownership de arquivos definido.
 5. Consuma evidências dos especialistas. Reabra uma decisão somente quando a evidência ou o pedido mudar; registre quem decidiu e o impacto nas etapas consumidoras. Contradição entre requisitos aprovados bloqueia as etapas afetadas até o dono decidir; o orquestrador não a resolve.
 
 ## Saída e aceite
@@ -30,7 +30,7 @@ Entregue **delivery-map** na resposta final ou em arquivo do projeto cujo caminh
 
 ## Limites e composição
 
-Não implementa todos os domínios nem impõe stack, cloud, agentes paralelos ou uma cadeia fixa de skills.
+Não implementa todos os domínios nem impõe stack, cloud, agentes paralelos ou uma cadeia fixa de skills. Este mapa é de entrega, não de execução: decompor para executores, delegar, verificar de forma adversária e registrar passos ficam com `crow-behaviour`, e o mapa não duplica esse ciclo nem estima prazo como se fosse evidência.
 
 Altere só o que o pedido e o achado exigem: sem reestilizar, reescrever em outra linguagem, adicionar dependências ou editar docs fora do alvo; documento de outro dono (runbook, política, RACI, decisão registrada) recebe proposta, não edição, salvo pedido explícito; liste e justifique qualquer extra; mudança de contrato (API, schema, formato) e validação mais estrita, que passa a rejeitar o que antes era aceito, ficam como proposta, não implementação, salvo pedido explícito; pedir a correção de um defeito autoriza rejeitar a entrada que o causa, não mais que isso. Não crie branch, commit ou push sem pedido ou política declarada do dono. Use só ferramentas já presentes; não baixe binários nem acesse rede além do alvo autorizado no pedido, prefira contexto isolado ao navegador ou desktop pessoal do usuário e, se faltar ferramenta, declare como não validado. Controles corretos que você verificou, credenciais visivelmente fictícias (fixtures, exemplos) e falsos positivos não são defeito: liste cada um nos descartados, com motivo. Subagentes delegados carregam esta skill; revisores não editam arquivos nem commitam no projeto (exercer a hipótese contra o alvo autorizado não é escrita).
 

package/skills/crow-postgres/SKILL.md

@@ -21,6 +21,9 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 4. Planeje migration compatível com leitores/escritores antigos durante rollout. Faça backfill/índice online só quando suportados e necessários; explicite locks, tempo e recuperação.
 5. Teste constraints, concorrência e negações entre papéis/tenants. Confira restauração e caminho de reversão seguro antes de operações irreversíveis.
 
+- Leia [migracao-online.md](references/migracao-online.md) ao mexer em tabela com tráfego: lock forte que trava escrita, índice concorrente, constraint em dois tempos (`NOT VALID` depois `VALIDATE`), expand-contract para mudança incompatível, backfill em lotes, reversão e coordenação de fila.
+- RLS, constraints e roles no banco complementam, não substituem, a autorização da aplicação; a decisão de ator × recurso × ação no servidor é de `crow-backend`.
+
 ## Saída e aceite
 
 Entregue **db-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.

package/skills/crow-postgres/references/migracao-online.md

@@ -0,0 +1,17 @@
+# migração sem janela de inconsistência
+
+Leia ao planejar qualquer migration numa tabela com tráfego. O erro clássico é a migration que trava escrita porque pega lock forte numa tabela grande; os passos abaixo evitam isso e mantêm leitores e escritores antigos funcionando durante o rollout.
+
+Pegue `lock_timeout` baixo em toda migration. Sem ele, um `ALTER TABLE` que precisa de `AccessExclusiveLock` entra na fila atrás do tráfego e, enquanto espera, bloqueia toda query nova que chega depois dele — a tabela congela mesmo antes de o comando rodar. Com `lock_timeout`, a migration falha rápido e você reagenda em vez de derrubar o serviço.
+
+Crie índice sem travar a tabela com `CREATE INDEX CONCURRENTLY`. Ele não pega lock de escrita, mas não roda dentro de transação e, se falhar no meio, deixa um índice inválido para trás: detecte o inválido, derrube-o e refaça. Para reconstruir, `REINDEX CONCURRENTLY`.
+
+Adicione constraint em dois tempos. `ADD CONSTRAINT ... NOT VALID` registra a regra pegando lock só por um instante e já passa a valer para linhas novas; `VALIDATE CONSTRAINT` num comando separado varre as linhas antigas sem bloquear escrita. Vale para `CHECK` e para chave estrangeira. Uma constraint adicionada já validada varre a tabela inteira sob lock forte — é exatamente o que evitar.
+
+Para mudança incompatível (renomear coluna, trocar tipo, estreitar formato), use expand-contract. Adicione o campo novo ao lado do antigo, preencha, faça o código escrever nos dois durante a transição, mova os leitores e só então, numa migration posterior e com autorização própria, remova o antigo. Nunca renomeie ou troque o tipo no lugar enquanto o código em produção ainda lê o nome ou o formato antigo.
+
+Faça backfill em lotes delimitados, cada lote na própria transação curta, com pausa entre eles. Um único `UPDATE` na tabela toda segura lock e gera bloat; o laço em lotes mantém a escrita de produção fluindo. `NOT NULL` numa coluna grande já existente precisa de validação: preencha primeiro, depois imponha, ou use um `CHECK ... NOT VALID` validado à parte.
+
+Toda migration tem caminho de volta explícito, ou é marcada irreversível e autorizada à parte. Confira restauração e reversão antes de qualquer passo destrutivo; teste no ambiente de teste, não em produção.
+
+Em fila de trabalho e coordenação, prefira `FOR UPDATE SKIP LOCKED` para workers pegarem linhas diferentes sem esperar uns aos outros, e advisory lock (`pg_advisory_xact_lock`) para exclusão em nível de aplicação sem criar linha-dummy para travar. Quando duas transações tocam as mesmas linhas, adquira os locks na mesma ordem em todas elas para não gerar deadlock.

package/skills/crow-product-leadership/SKILL.md

@@ -16,10 +16,11 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 ## Trabalho
 
 1. Separe problema de decisão, coordenação e desenvolvimento individual. Use fatos atribuíveis, sem diagnosticar personalidade ou inventar desempenho. Confronte alegações de alinhamento ("já falei com todos") com os registros; divergência é achado.
-2. Mapeie quem decide, quem contribui e quem precisa de contexto. Explicite trade-offs, dependências e desacordos sem escolher pela última mensagem. Diante de restrição de outro dono (freeze, orçamento, política), não a remova nem a ignore: dê pelo menos duas opções com custo e risco e diga quem decide.
+2. Mapeie quem decide, quem contribui, quem aprova ou veta, quem precisa de contexto e quem sofre a consequência sem poder mudá-la. Explicite trade-offs, dependências e desacordos sem escolher pela última mensagem. Diante de restrição de outro dono (freeze, orçamento, política), não a remova nem a ignore: dê pelo menos duas opções com custo e risco e diga quem decide.
 3. Produza o menor artefato útil: decisão, plano de conversa, responsabilidades ou experimento de melhoria (hipótese, métrica, prazo e critério de parada). Reutilize contexto dado, sem workshop obrigatório.
-4. Defina ação, responsável, resultado observável e data/checkpoint se pertinentes. Para feedback de carreira, distinga auto-relato de habilidade demonstrada.
-5. Deixe comunicações externas e mudanças organizacionais como ações pendentes para o dono decidir, separadas do aconselhamento; não as envie.
+4. Defina ação, responsável, resultado observável e data/checkpoint se pertinentes. Registre a decisão com dono, data e o que foi descartado, e mantenha o desacordo no registro com o nome de quem discorda. Para feedback de carreira, distinga auto-relato de habilidade demonstrada.
+5. Leia [decisão e pessoas](references/decisao-e-pessoas.md) ao montar o mapa, ao escrever o registro ou ao tratar desempenho: papel não é pessoa, representante conveniente não é representante validado, prepare o que o outro lado precisa e não só o seu pedido, consenso escrito onde houve divergência é registro falso, e a skill não emite veredito de prontidão sobre ninguém.
+6. Deixe comunicações externas e mudanças organizacionais como ações pendentes para o dono decidir, separadas do aconselhamento; não as envie.
 
 ## Saída e aceite
 

package/skills/crow-product-leadership/references/decisao-e-pessoas.md

@@ -0,0 +1,35 @@
+# decisão e pessoas
+
+Leia ao mapear quem participa de uma decisão, ao registrá-la e ao tratar desenvolvimento individual. A skill organiza decisão e conversa; ela não exerce autoridade sobre ninguém, e o registro é o que impede que a análise vire veredito.
+
+## Quem participa, em cinco papéis diferentes
+
+Decidir, contribuir e receber contexto não cobrem o mapa. Separe também quem aprova ou veta — segurança, jurídico, compliance, finanças, dono de uma plataforma vizinha — porque aprovador ausente do mapa não desaparece: ele reaparece como bloqueio tarde, quando o custo de voltar é maior. E separe quem sofre a consequência sem ter poder de mudar a decisão: quem opera o fluxo todo dia, quem perde o caminho antigo, quem fica fora do novo requisito. Esse grupo precisa ser ouvido por desenho; porta aberta só atende quem já sabia que tinha vez.
+
+Papel não é pessoa. "Engenharia" não aprova nada; quem aprova é quem tem a decisão sobre capacidade ou sobre o sistema. Nomeie a pessoa ou o cargo com a autoridade real, porque é com ela que a conversa precisa acontecer.
+
+Quando alguém fala por um grupo, verifique se representa o grupo ou apenas se tornou acessível. Representante conveniente devolve a visão dele; representante validado confirmou com quem representa. Diga qual dos dois você tem.
+
+Considere o efeito de segunda ordem: a decisão muda o trabalho de um time, isso muda a experiência de quem depende dele, e aí muda o número que a liderança olha. A cadeia revela participante que o mapa de um nível não mostra.
+
+## Preparar a conversa pelos dois lados
+
+Plano que só organiza o que você quer dizer trata a outra pessoa como plateia. Antes da conversa, separe o que você precisa dela — decisão, aprovação, informação, capacidade, apenas ciência — do que ela provavelmente precisa de você: previsibilidade, influência sobre o desenho, crédito pela contribuição, garantia sobre risco que ela terá de defender. Onde as duas listas se encontram existe caminho de acordo; onde divergem existe negociação a preparar, e dizer isso é mais útil que uma mensagem bem escrita no tom errado.
+
+O esforço é proporcional ao que está em jogo: relação crítica e grupo sem voz recebem plano próprio, o resto recebe a informação. E plano não é permanente — quem estava alinhado muda de posição depois de um trimestre ruim; revise depois de cada marco em vez de tratar o mapa como estado fixo.
+
+## Registro da decisão
+
+A decisão registrada diz o que foi decidido, quem decidiu, em que data, o que foi considerado e descartado, e com qual motivo. Sem data não se sabe qual de dois registros em conflito vale. Sem o descartado, a alternativa volta na reunião seguinte como se fosse nova.
+
+Desacordo entra no registro com o nome de quem discorda e o motivo, ao lado da decisão, e continua lá depois dela. Escrever consenso onde houve divergência é registro falso: apaga a objeção que previa o risco e tira de quem decidiu a informação de que a decisão foi tomada contra uma leitura conhecida. Divergência preservada não é insubordinação registrada, é o custo da decisão visível.
+
+Restrição de outro dono — congelamento, orçamento, política, contrato — não é removida nem ignorada aqui: ela entra como restrição, com ao menos duas opções e o nome de quem pode alterá-la.
+
+## Pessoas
+
+Não emita veredito sobre uma pessoa. Pronto ou não pronto, promovível ou não, forte ou fraco são decisões de quem tem a autoridade e os dados de desempenho, não saída de uma análise de contexto. O que esta skill entrega é o comportamento específico, com o fato atribuível que o sustenta, a data e a fonte, e o que mudaria com qual apoio.
+
+Auto-relato é auto-relato; afirmação de terceiro sobre alguém é atribuída a quem disse, com a data; nenhum dos dois é habilidade demonstrada. Não diagnostique personalidade, motivação interna ou intenção a partir de comportamento observado, e não transforme uma inferência em fato ao repeti-la no artefato. Dado pessoal sensível não entra no registro.
+
+Comunicação externa e mudança organizacional ficam como ação pendente, separadas do aconselhamento, e não são enviadas por você.

package/skills/crow-qa/SKILL.md

@@ -18,7 +18,7 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 1. Defina se o pedido é planejar, escrever ou executar testes. Planejamento não autoriza execução/alteração. Com aceite contraditório, cubra só o que não depende do conflito. Associe requisitos à camada mais barata que observe o comportamento real: unidade, integração, API, contrato, jornada e visual.
 2. Use dependências reais de teste para integração e virtualize terceiros quando necessário. Não mocke a ligação que o teste diz verificar.
 3. Adicione cenários negativos e recuperação pertinentes. Consumer-driven contract testing faz sentido quando há consumidores/provedores independentes, não por ritual.
-4. Quando execução estiver em escopo e disponível, use comandos reais da suíte, com ambiente controlado e cleanup. Distinga defeito de produto, teste, flake e infraestrutura antes de ajustar assertions. Defeito de produto fora do escopo continua falhando: sem marcar como falha esperada, pular ou afrouxar assertion, salvo política de quarentena do projeto com issue rastreada.
+4. Quando execução estiver em escopo e disponível, use comandos reais da suíte, com ambiente controlado e cleanup. Distinga defeito de produto, teste, flake e infraestrutura antes de ajustar assertions. Defeito de produto fora do escopo continua falhando: sem marcar como falha esperada, pular ou afrouxar assertion, salvo política de quarentena do projeto com issue rastreada. Teste intermitente é defeito do teste até prova em contrário: investigue a causa (espera por tempo fixo em vez de condição, estado compartilhado entre testes, dependência de ordem, rede ou terceiro real) em vez de reexecutar até passar. Retry que esconde flake é dívida, não correção, e pode mascarar regressão real; se a política usa rerun, limite-o e registre a flake para conserto, nunca a conte como verde.
 5. Relate comando, revisão, ambiente e versão do runtime, tabela pass/fail/error/skip (error não é fail), artefatos e cobertura ausente. Preserve a política de dados e retenção visual do projeto.
 
 Recursos da máquina: rode primeiro os testes direcionados à mudança e a suíte completa só depois, uma vez; limite os workers que o runner já usa (`--maxWorkers`; `pytest -n` só com xdist já no projeto), sem paralelizar runner serial, ao `maxWorkersPerJob` de `crow-skills resources --json` quando existir. Sob pressão `critical`, não inicie suíte nova e relate o bloqueio. Encerre servidores, bancos e containers de teste que você subiu. 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-release/SKILL.md

@@ -16,14 +16,19 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 ## Trabalho
 
 1. Defina o modo pedido: preparar, avaliar ou executar. Nos dois primeiros, produza plano/evidência sem deploy; no último, identifique ambiente, fluxo Git/pipeline, artefato e identidade. Reutilize autorização específica existente; não amplie para outro ambiente. Autorização relatada por terceiro é relato, não aprovação.
-2. Confira os gates aplicáveis e resultados reais. Teste, SAST, dependências e budget são requisitos por risco, não comandos universais. Se um gate falha por causa trivial e reversível no escopo (como versão desalinhada), corrija e rode de novo.
-3. Planeje compatibilidade de migration/config/consumidores e ordenação do rollout. Para mudança destrutiva, nomeie os consumidores afetados e a ordem expand/contract, e valide backup e restauração antes do ponto irreversível.
-4. Somente no modo executar, com gates satisfeitos e ferramenta disponível, use o mecanismo existente, artefato identificado e credenciais externas ao código. Gate pendente bloqueia a promoção ao ambiente que ele protege, não a homologação autorizada: execute o que for seguro e reversível. No modo executar autorizado, commit, tag, push e acesso ao destino e ao pipeline fazem parte do pedido; correção de gate entra como commit próprio, citado na saída.
-5. Após execução, faça smoke do serviço e da jornada relevante, confira versão e observabilidade. Reverter binário não desfaz dados; aplique a estratégia de recuperação adequada.
-6. Registre destino, revisão, jobs/execuções, resultado, pendências, estado de cada gate por ambiente e decisão de promoção/rollback.
+2. Confira os gates aplicáveis e resultados reais. Teste, SAST, dependências e budget são requisitos por risco, não comandos universais. Se um gate falha por causa trivial e reversível no escopo (como versão desalinhada), corrija e rode de novo. Evidência de gate vale para a revisão em que foi colhida: se o alvo mudou depois, o gate volta a pendente em vez de ser reaproveitado. Antes dos gates, confira se o artefato é publicável no destino: ponto de entrada, build reproduzível, configuração que o destino precisa receber e dependência de serviço que só existe na máquina local (banco em `localhost`, arquivo fora do artefato, variável só no ambiente de quem desenvolve) são bloqueadores de deploy, não detalhes de execução.
+3. Planeje compatibilidade de migration/config/consumidores e ordenação do rollout. Para mudança destrutiva, nomeie os consumidores afetados e a ordem expand/contract, e valide backup e restauração antes do ponto irreversível. Leia a referência de transição quando houver migração de schema, dados, formato, protocolo ou contrato.
+4. Somente no modo executar, com gates satisfeitos e ferramenta disponível, use o mecanismo existente, artefato identificado e credenciais externas ao código. Gate pendente bloqueia a promoção ao ambiente que ele protege, não a homologação autorizada: execute o que for seguro e reversível. No modo executar autorizado, commit, tag, push e acesso ao destino e ao pipeline fazem parte do pedido; correção de gate entra como commit próprio, citado na saída. Mudança de configuração remota, flag ou catálogo de experimento é promoção: muda comportamento em produção sem passar pelo artefato, então pede o mesmo destino confirmado, a mesma autorização, histórico de versão e caminho de volta. Flag sem default seguro no cliente transforma indisponibilidade da configuração em indisponibilidade do produto.
+5. Antes de promover, determine se o destino tem caminho de volta: revisão imutável com desvio de tráfego volta em minutos; destino que não guarda a versão anterior só recupera para frente, e isso muda o risco aceitável e precisa estar dito no plano, com o tempo estimado de recuperação. Voltar por um ciclo completo de pipeline é o caminho lento: não o apresente como o mecanismo de rollback quando existir desvio de tráfego ou revisão anterior ativa.
+6. Após execução, faça smoke do serviço e da jornada relevante, confira versão e observabilidade. Prova de publicação é asserção sobre o destino: a versão que o destino reporta (registry, endpoint de versão, revisão ativa, digest do artefato) tem de ser a que você publicou. Job verde, log de upload, espera por tempo fixo e porta aberta não provam que a versão certa está no ar nem que a aplicação está pronta. Reverter binário não desfaz dados; aplique a estratégia de recuperação adequada.
+7. Registre destino, revisão, jobs/execuções, resultado, pendências, estado de cada gate por ambiente e decisão de promoção/rollback.
 
 Recursos da máquina: gates locais (build, suíte, empacotamento) rodam em sequência, com workers limitados por `crow-skills resources --json` quando existir; não repita localmente o que o CI do repo já prova. Sob pressão `critical`, não inicie build local e relate o bloqueio. Encerre processos e containers que subiu para o smoke. Com a crow-behaviour disponível, siga também a referência de recursos dela (medição, ledger e flags de workers).
 
+## Detalhes condicionais
+
+- Leia [transicao.md](references/transicao.md) para migração de schema, dados, formato, protocolo, configuração ou dependência.
+
 ## Saída e aceite
 
 Entregue **release-evidence** 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.