Referência de Diagnósticos

O lexer chegou ao fim do arquivo (ou da linha, em certos contextos) antes de encontrar a aspa de fechamento da string.

O parser esperava um token específico (por exemplo `}`, `)`, identificador, tipo) mas encontrou outra coisa. Geralmente uma chave, parêntese ou pontuação ausente.

Um token apareceu onde a gramática não permite — tipicamente um símbolo perdido, palavra-chave digitada errada ou separador ausente na linha anterior.

Um erro de parsing que não casou com nenhum classificador específico. Leia a mensagem do diagnóstico para a causa precisa.

Um comentário `<!-- -->` foi escrito entre `<` e `>`, onde o próprio HTML também não permite. Dentro da tag, use os comentários de Zolo: `//` ou `/* */`. Nos filhos de um elemento, `<!-- -->` funciona normalmente.

Equivalente a `TE001`. Emitido pelo classificador legado quando o novo typeck não anexou um código.

Alias legado para `TE100`.

Alias legado para `TE101`.

Alias legado para `TE004`. A variável foi declarada com `let`; use `let mut` para permitir reatribuição.

Alias legado para `TE102`.

Um literal de struct omite um ou mais campos obrigatórios.

Alias legado para `TE110`.

O valor retornado não corresponde ao tipo de retorno declarado pela função.

Um nome (função, variável, campo, variante) foi declarado duas vezes no mesmo escopo.

Uma anotação de tipo se refere a um tipo que o compilador não consegue encontrar.

O valor atribuído a um binding `let` não satisfaz a anotação de tipo declarada.

O valor atribuído a um binding `const` não satisfaz a anotação de tipo declarada.

`const` exige uma expressão constant-foldable. Use `let` para valores de runtime.

Bindings `let` são imutáveis por padrão. Use `let mut x = ...` para permitir reatribuição, ou crie um novo binding com shadowing via `let`.

Operadores como `+=`, `-=`, `*=` exigem que ambos os lados sejam numéricos (ou strings, para `+=`).

A função declarou um retorno em tupla, mas a instrução `return` fornece menos valores.

A função retorna mais valores do que seu tipo de retorno único pode comportar.

Um literal de array mistura tipos incompatíveis; arrays são homogêneos.

Aritmética binária exige que ambos os operandos sejam numéricos e (em modo strict) do mesmo tipo numérico.

O nome não está declarado em nenhum escopo envolvente. O compilador anexa uma sugestão "quis dizer?" quando existe um nome similar.

O alvo de uma expressão de chamada não é um tipo invocável.

A struct não declara este campo. Sugestões "quis dizer?" são anexadas para nomes similares.

Uma anotação de tipo ou campo de variante de enum se refere a um tipo que o compilador não consegue resolver.

O tipo receptor não tem um método com esse nome. Verifique a grafia, os imports e a visibilidade do trait.

Um nome simples corresponde a um módulo conhecido da biblioteca padrão (`math`, `json`, `http`, `os`, …) que nunca foi trazido ao escopo. Diferente do TE100, o compilador reconhece o nome e diz exatamente qual linha `use` está faltando.

Um literal de struct omite um campo que não tem valor padrão nem zero-value de fallback. Todo campo sem default precisa ser fornecido explicitamente na construção.

Um struct com `@derive(Default)` tem um campo cujo tipo não possui zero-value nem default explícito, então nenhuma impl de `Default` pode ser sintetizada.

Um campo de struct foi escrito sem anotação de tipo, contando com o valor padrão para inferi-lo (`nome = valor`) — mas o tipo do padrão é ambíguo (ex.: `nil`, ou uma expressão que resolve para `any`).

O número de argumentos passados não corresponde à quantidade de parâmetros da função.

O tipo de um argumento não corresponde ao tipo do parâmetro correspondente.

Dois ou mais campos embutidos com `using` declaram um campo de mesmo nome, então um acesso `.campo` no struct externo não sabe de qual embed promovê-lo.

Um campo marcado com `using` precisa embutir outro struct — são os campos dele que são promovidos. Um escalar, ou qualquer tipo que não seja uma declaração de struct conhecida, não tem campos a promover.

Um enum optou por discriminantes numéricos (tipo de backing, ou um `= n` explícito) mas é genérico ou tem variante com payload. Discriminantes só fazem sentido para enums planos, com todas as variantes unitárias.

O discriminante de uma variante está fora da faixa do tipo de backing declarado (`enum E: u8` limita a `0..=255`), então não sobreviveria ao ida-e-volta de `to_int()`/`from_int()`.

Duas variantes do mesmo enum resolveram para o mesmo inteiro — ou dois `= n` explícitos colidem, ou um valor auto-incrementado caiu em cima de um já usado.

Sob `@stable` o auto-incremento é proibido: inserir uma variante no meio renumeraria silenciosamente todas as seguintes, quebrando a codificação que a anotação promete manter.

O discriminante `= expr` de uma variante ou não avaliou para inteiro em tempo de compilação, ou não pôde ser avaliado como constante de compilação.

Um enum `@flags` é genérico ou tem variante com payload. `@flags` modela uma bitmask sobre um conjunto fixo e plano de variantes unitárias — não há espaço para parâmetros de tipo ou payloads.

Cada variante `@flags` precisa ser um bit novo (auto-incrementado ou potência de dois explícita) ou um composto nomeado construído só a partir de bits declarados acima dela.

O valor de uma flag está fora da faixa do tipo de backing do enum — flags em `enum: u8` param em `255` (bit 7).

Duas flags de bit único no mesmo enum `@flags` resolveram para o mesmo bit, normalmente porque receberam o mesmo valor explícito.

Um padrão de destructuring — `let Struct { … } = expr`, um `let { … }` anônimo, um padrão de parâmetro ou uma atribuição com destructuring de struct — nomeia um campo que o struct não tem.

O bloco `else` pode cair para fora. Se caísse, a execução seguiria para os bindings do padrão com um valor que NÃO casou — por isso todo caminho pelo `else` precisa retornar, panicar, quebrar ou continuar.

O padrão pode não casar (padrão de variante de enum, padrão de tamanho de array, …) e não tem cláusula `else`. Sem ela, um valor que não casa ligaria lixo silenciosamente.

Um padrão de struct anônimo precisa saber qual struct está desestruturando, mas o tipo do valor não resolve para um struct concreto — normalmente por falta de anotação de tipo.

Um padrão de struct nomeado em posição de parâmetro (`fn f(NomeStruct { … }: T)`) nomeia um struct diferente da anotação de tipo do próprio parâmetro.

O spread final de um literal de struct (`Struct { ..origem }`) tem uma `origem` que não é struct nem record, então não há campos a espalhar.

Uma atribuição com destructuring de tupla (`(a, b, c) = expr`) tem um número de alvos diferente do número de valores de `expr`.

Operadores compostos (`+=`, `-=`, …) não têm significado por elemento quando o lado esquerdo é um padrão inteiro, e o spread `..` não faz sentido como alvo de atribuição.

Um argumento nomeado (`f(nome: valor)`) não corresponde aos parâmetros declarados da função chamada — nome desconhecido ou duplicado, um argumento posicional depois de um nomeado, um parâmetro do meio pulado, ou uma chamada cuja assinatura não é conhecida localmente.

O placeholder `_` só é válido como argumento direto na chamada do lado direito (RHS) de um estágio de pipe `|>`/`?>` (no máximo um por estágio), ou como a cabeça de uma cadeia de campo/método/índice usada como argumento de chamada (`_.campo`). Um `_` solto, um segundo `_` no mesmo estágio de pipe, ou `_` como lado esquerdo de um pipe são todos rejeitados.

Um enum real e declarado foi identificado para este ponto — como base de `EnumName::variante`, ou como tipo do valor testado por um pattern com atalho `.variante` — mas o nome da variante não corresponde a nenhuma variante declarada. Uma sugestão "quis dizer?" é incluída na mensagem quando existe um nome próximo.

O nome faz parte do prelúdio sempre-em-escopo da VM, mas o backend native/LLVM não tem implementação para ele. Compilar assim mesmo faria o nome virar `nil` silenciosamente e sair com 0 — por isso o build falha.

Check exclusivo de native/LLVM: um identificador simples não resolveu para nada. Sem prelúdio Lua de fallback, ele viraria `nil` silenciosamente em runtime — a classe "typo vira no-op quieto" que isso pega em tempo de build.

O atalho `.Variante` descobre seu enum a partir do tipo esperado pela posição onde aparece, e esta posição não fornece nada utilizável — nenhum tipo esperado (um `let` sem anotação, um argumento de uma função cuja assinatura não é conhecida), um parâmetro genérico ainda não fixado, ou um tipo que não é um enum. Anote a variável ou escreva a forma qualificada `Enum::Variante`.

O atalho `.Variante` resolveu seu enum a partir do tipo esperado pela posição, mas esse enum não tem nenhuma variante com esse nome. Uma sugestão "quis dizer?" é incluída quando existe um nome próximo. A forma de pattern do mesmo erro reporta `TE133` em vez deste código.

Um build native/LLVM não conseguiu unir (splice) um módulo de declaração: ou uma declaração do usuário começa com o prefixo `__zolo_std_`, reservado pelo compilador, ou uma função alcançável do módulo de declaração referencia um item irmão que o linker não consegue levar ao programa final. Qualquer um dos casos deixaria o build AOT divergir silenciosamente da VM.

`<style>` e `<script>` são raw text elements: o conteúdo corre verbatim até o `</style>`/`</script>` correspondente, sem markup aninhado e sem interpolação `{expr}`. Chegar ao fim do arquivo antes desse fechamento reporta TE139 em vez da mensagem genérica "unclosed element" — geralmente uma tag de fechamento esquecida, ou uma string no formato `</tag` dentro do conteúdo (por exemplo, um literal de string JS) que fechou o bloco cedo demais.

Uma recipe do Resource Graph em tempo de build (`Resource.dir(...).seal()`) não pôde ser selada em sua Resource Image imutável — um caminho ausente ou que não é diretório, um padrão `include` que não casou com nada, um caminho que escapa da raiz do recurso, uma colisão de caminho lógico, ou um arquivo que não pôde ser lido durante a selagem do snapshot. Não existe fallback para o diretório de trabalho em runtime: o build falha em vez disso.

O compilador recebeu um valor interno malformado do Resource Graph, ou uma Resource Image selada falhou nas checagens de integridade — um campo de recipe inválido (`root`, `includes`, `excludes`) ou estado de build corrompido, diferente das falhas acionáveis de entrada/selagem do `TE140`.

Um `;` colocado depois da expressão final de um bloco suprime seu valor, então o bloco conclui `void` em vez de produzir um resultado. `TE142` dispara quando esse void causado por terminador é usado onde um valor é exigido — vinculado a um `let`, passado como argumento, e assim por diante.

Uma função declara `-> T`, mas um `;` depois de sua expressão final suprime esse valor, então o corpo conclui `void` em vez de um `T`. A menos que outro `return expr` forneça o valor, a função nunca consegue satisfazer a própria assinatura.

O campo declara `get`, mas não `set`; por isso, atribuições após a construção não são permitidas.

Usar `self.<mesmo-campo>` dentro do próprio acessor causaria recursão; use o nome contextual `field`.

Um acessor pode herdar ou restringir a visibilidade do campo, mas não pode expor publicamente um campo privado.

`?` propaga a falha, mas desempacota o sucesso. Uma função que retorna `Result` ou `Option` deve envolver esse sucesso explicitamente com `.Ok(...)` ou `.Some(...)`.

Um literal `tw"..."` precisa ser uma lista estática de nomes de classe Tailwind. Interpolar um valor nele (`tw"bg-{cor}-600"`) esconderia parte do nome da classe do scanner do Tailwind em tempo de build, por isso Zolo rejeita — escolha entre literais completos usando controle de fluxo comum.

A expansão inline exige um corpo Zolo real; declarações nativas e de plugin precisam de um wrapper Zolo.

Use exatamente uma forma: `@inline`, `@inline(always)` ou `@inline(never)`.

Um corpo always-inline não pode expandir a si mesmo recursivamente; use uma dica ou separe o núcleo recursivo.

O contrato always-inline exige um corpo higiênico suportado; simplifique-o ou use `@inline` sem modo.

A tipagem strict exige que todo `let`/`const` tenha uma anotação de tipo explícita.

A tipagem strict exige que todo parâmetro de função tenha um tipo explícito.

Um derive estruturado retornou syntax que não pode ser inserida no destino; o resultado deve ser `Syntax<.Items>` ou `Syntax<.Item>`.

Um hole `${value}` recebeu um valor sem representação segura em código-fonte; insira um primitivo ou um nó `Syntax<K>`.

`syntax.ident(text)` recebeu um texto que não é um único identificador Zolo válido e que não seja palavra reservada.

Um spread `${..values}` recebeu algo diferente de uma lista ou tupla de nós de syntax de uma mesma categoria compatível.

Os itens gerados escapam do escopo de expansão declarado por `@derive_for`, como uma função livre sem relação criada por um derive restrito a impl.

Uma função `@derive_for` retornou algo diferente dos resultados suportados: `str`, `Syntax<.Items>` ou `Syntax<.Item>`.

Um atributo namespaced do derive contém uma opção desconhecida, duplicada, ausente, não literal ou com tipo incorreto.

Um tipo usa `@derive(T)`, mas nenhum deriver para `T` está disponível no escopo. Zolo nunca ignora isso silenciosamente — um nome digitado incorretamente não pode gerar um programa parcialmente gerado que só falha em runtime. Importe ou declare a função pública que expõe o deriver, exportada por convenção com o mesmo nome da capacidade.

`await` recebeu um valor cujo tipo conhecido não é `Future<T>` nem `Task<T>`. Só esses dois wrappers podem ser suspensos; um valor comum já está disponível e não há o que aguardar.

`yield` só é válido dentro de um generator declarado com `fn*`. Uma função comum ou `async fn` produz um único resultado e não expõe nenhum iterador pull para receber o yield.

Um generator (`fn*`) usou `return valor`. Terminação e itens produzidos são conceitos separados num generator: `return` pode encerrá-lo antes do tempo, mas seu valor nunca é produzido como item do iterador — use `yield` para isso.

Um valor produzido por `yield` não satisfaz o tipo de elemento declarado do generator. Todo `yield` dentro de `fn* ... -> T` precisa produzir um valor atribuível a `T`.

`await` apareceu dentro de um generator `fn*`. Generators assíncronos ainda não têm um contrato de scheduler compartilhado por todos os backends, então Zolo rejeita a combinação em vez de deixar um backend retomá-la com semântica diferente de outro.

`break :label` ou `continue :label` nomeia um loop que não está ativo lexicamente. Labels nunca atravessam fronteira de função/lambda, e uma task `spawn`ada ou um callback agendado com `every`, `after` ou `timeout` inicia sua própria região de controle de fluxo, então não pode saltar para um loop do chamador.

Dois loops aninhados, ativos ao mesmo tempo, declaram o mesmo label. Uma saída rotulada seria ambígua para quem lê, mesmo que a declaração mais interna pudesse ser resolvida mecanicamente.

Um `break` ou `continue` sem label aparece fora de um loop. Essas instruções só podem transferir o controle dentro de um `loop`, `while` ou `for` envolvente.

Um `break` carregando um valor aponta para `while` ou `for`. Só a forma incondicional `loop` é uma expressão que produz valor, então um `break` com valor só é válido nela.

Os valores carregados pelos `break`s alcançáveis não concordam com o tipo de resultado de uma expressão `loop`. Um `break` isolado contribui com `void`, então não pode sair de um loop que deveria produzir um valor não-void.

`timeout duração { ... }` retorna `Result<Any, TimeoutError>`. A falha de timeout é controle de fluxo tipado comum — não é um record sem tipo, e nunca é convertida silenciosamente para o valor de sucesso.

O número de argumentos de tipo fornecidos não corresponde à quantidade de parâmetros do tipo genérico.

Um bound de trait, bloco `impl` ou cláusula `where` faz referência a um trait que o compilador não encontra.

Um `impl Trait for Tipo` não é coerente com a declaração do trait — ou ele adiciona um método que o trait não declara, ou outra implementação já satisfaz o mesmo alvo parametrizado e a mesma instância de trait.

Um método em `impl Trait for Tipo` não corresponde ao trait depois de substituir `Self`, argumentos do trait, tipos associados e parâmetros genéricos do método — tipos/qualificadores de parâmetro, tipo de retorno, bounds genéricos e linhas de efeito fazem parte do contrato.

Uma implementação omite um tipo associado obrigatório, o define mais de uma vez, nomeia um tipo associado que o trait não declara, ou fornece um tipo que falha nos bounds do tipo associado.

Uma implementação escolheu um tipo associado concreto que não satisfaz um bound declarado pelo trait para ele. O diagnóstico nomeia a implementação, o tipo associado projetado e o requisito que falhou — o tipo original é preservado, nunca é ampliado silenciosamente para `Any`.

Um trait declara um tipo associado sem default, mas uma implementação não o define, então o compilador não consegue projetar `Self::Item` (ou outro nome associado) a partir dessa implementação.

O tipo concreto implementa o nome de trait solicitado, mas com argumentos de tipo diferentes. Witnesses de trait são exatas — implementar `Sink<str>` não prova `Sink<int>`.

Um valor tipado como union só pode ser usado sem narrowing através de membros compartilhados por todas as alternativas. Ler um campo ou chamar um método que falta em algumas alternativas seria válido para um valor em runtime e inválido para outro.

Um handler de evento dentro de um `@island` contém uma expressão que a redução do cliente do Verniz não consegue representar em JavaScript. A renderização no servidor ainda produziria o controle, mas publicá-lo sem o handler criaria um elemento com aparência interativa que não faz nada — por isso o build falha em vez disso.

Uma atribuição tem como alvo um signal derivado declarado com `let<signal>`. Uma cell derivada é definida pelo seu inicializador e recalculada a partir das cells de origem que lê — não é estado gravável, então atribuir a ela a deixaria em desacordo com seu próprio grafo de dependências.

Um `effect` dentro de um `@island` contém comportamento que a redução do cliente do Verniz não consegue compilar para JavaScript. Diferente da renderização no servidor, um effect de island não tem uma metade no servidor capaz de preservar o comportamento — se não for emitido para o cliente, ele nunca roda, então o build é rejeitado em vez de descartá-lo silenciosamente.

`@(expr)` compila para uma ponte de custom property de CSS (`var(--…)`), que só existe em valores de declaração — depois do `:`, antes do `;`. Em seletor, nome de propriedade ou prelúdio de at-rule não há `var()` para a ponte compilar, e splice de texto do usuário ali é anti-feature deliberada. Mova a parte dinâmica para um valor, ou alterne classes estáticas no markup.

Um `<style children={expr}>` carrega conteúdo de runtime que o compilador não enxerga — não dá para içar nem escopar; escopar texto desconhecido seria mentira. Spec §6.1: conteúdo dinâmico precisa optar por `global` explicitamente (`<style global children={…}>`), a única forma de style que continua sendo nó de render.

Um valor de `@()` viaja como custom property de CSS, e só `str`, `int` e `float` serializam para uma. Valor tipado `bool`, `View`, map, struct ou função é rejeitado em compilação — no render viraria lixo ou sumiria. Valores sem tipo (`Any`) ficam em silêncio: este erro nunca chuta.

`@()` compila para `var(--…)`, e CSS não concatena strings em valores comuns — `var(--w)px` é erro de sintaxe que o browser descarta, não "número mais unidade". Escreva `calc(@(x) * 1px)` ou interpole a string inteira (`@(f"{x}px")` — dentro de `@()` você está de volta em Zolo). `!important`, `/` e `*` em `calc()` são vizinhos sem espaço legais.

`:global(…)` isenta um compound do carimbo de escopo hermético. Um wrapper vazio (`:global()`) não isenta nada, e um aninhado (`:global(:global(a))`) escapa de um escape — os dois só podem ser engano. Num corpo `<style global>`, `:global()` nem é sintaxe Zolo e passa intacto.

Um `<style>` escopado pertence ao fn de componente que o cerca — o carimbo de classe do fn é o escopo dos seletores. Em statement top-level ou método de `impl`/`trait` não há componente, logo não há escopo. Adicione `global` (um `<style global>` estático fora de componente renderiza no lugar) ou mova para um fn de componente. Corpo com `@()` reporta isso mesmo com `global`: os valores precisam de um elemento-raiz de componente.

Todo valor de `@()` viaja como custom property de CSS no elemento-raiz do componente (o literal de elemento em posição de cauda), herdando DOM abaixo. Um componente que delega a view inteira — sem raiz de elemento própria — não dá onde os valores andarem. Faça a cauda ser um literal de elemento (um `<div>` de embrulho serve) ou remova a interpolação.

Um atributo HTML conhecido não é válido para o elemento escrito. Verniz valida tags nativas contra sua tabela DOM versionada; props de componente continuam passando pelos diagnósticos comuns de argumento nomeado.

Um binding `bind:` de mão dupla não é suportado no elemento, ou seu tipo de origem conhecido é incompatível com a propriedade de DOM alvo — por exemplo, vincular uma cell `str` a `bind:checked`, que espera `bool`.

Um atributo de handler de evento nomeia um evento que Verniz não reconhece nesse elemento. Nomes de evento usam a grafia do atributo DOM, como `onclick`, `oninput` e `onchange`.

Um elemento HTML void, como `input`, `img` ou `br`, foi escrito com filhos ou uma tag de fechamento explícita. Elementos void nunca podem ter conteúdo, então use a forma self-closing.

Uma checagem de acessibilidade de alta confiança: uma `<img>` não tem texto alternativo, ou um controle interativo não tem nome que um leitor de tela consiga anunciar. Só dispara quando a ausência do nome é certa — conteúdo dinâmico, `children` ou um spread de `HtmlAttrs` ainda podem fornecê-lo em runtime.

Um atributo ou role ARIA conhecido é usado com grafia ou valor inválido, ou um label tem como alvo um id de elemento que não existe no markup escrito.

Um alvo de `ref` não consegue receber um elemento do browser. Um `ref` precisa ser uma cell de origem `DomRef` opcional (`var<signal> nome: DomRef = nil`) declarada dentro do `@island` que a possui.

Um `{...spread}` é incompatível com seu alvo. O encaminhamento dinâmico para um elemento nativo precisa ser tipado `HtmlAttrs`; um spread de componente precisa expor campos de record estaticamente conhecidos para que a checagem comum de props continue ativa.

Um modificador de evento (`prevent`, `stop`, `once`, `capture`, `passive`, `self`) é desconhecido, duplicado, ou combinado de forma incompatível — `passive` não pode ser combinado com `prevent`.

Um contrato de attach não pode ser cumprido — o compilador pega alvos de portal estaticamente vazios, e o verificador de attach de desenvolvimento também reporta alvos de portal ausentes, marcadores de island obsoletos, propriedades de binding inválidas e refs que não pertencem à island.

Um membro de lifecycle como `pending`, `error` ou `state` foi lido a partir de uma referência de função comum. Só uma referência a uma função declarada `@action` tem o tipo nominal `ActionFn<...>` e uma lane do lado cliente.

Um código fora de qualquer `@island` tenta observar o lifecycle de um `ActionFn`. Uma referência de action continua chamável no servidor, mas `pending`, `state`, `retry` e o resto do lifecycle observável são capacidades do browser que não conseguem cruzar uma fronteira de island ou de wire.

Uma mutation action solicitou uma política desconhecida, ou uma política de substituição/cancelamento como `.Latest`. Uma mutation já aceita pelo servidor ainda pode ser confirmada mesmo depois que o cliente deixa de se importar com a resposta, então cancelar só a continuação do cliente faria a UI mentir sobre o efeito.

Uma `.lane()` foi criada diretamente dentro de um `for` renderizado. Uma lane explícita possui estado mutável de lifecycle do cliente, mas uma iteração de lista não tem identidade lexical estável assim que linhas são inseridas, removidas ou reordenadas.

Um valor que cruza entre Zolo e o TypeScript do browser não tem representação JSON determinística que a ponte Wire aceite — a ponte nunca recorre a `any`. Funções, closures, handles, `ResourceFs`, chaves de map que não são string, e tipos do usuário sem marcação ficam do seu lado de origem; structs/enums precisam de `@wire`.

Uma declaração marcada `@secret` é alcançável a partir de um tipo `@wire` ou de um contrato de browser `@action`. Publicá-la colocaria um valor privado numa declaração, codec, request, response ou bundle de browser gerado — remover `@secret` só para silenciar o diagnóstico é inseguro.

Verniz não conseguiu transformar um arquivo Markdown/JSON/TOML/YAML escrito no struct de metadados declarado por `content.collection` — um campo de frontmatter ausente ou com tipo errado, uma data que não parseia, um caminho não portável, ou (para `ContentTransform`) um problema de route callback/alias/fallback.

Uma função genérica foi chamada com um argumento de tipo que não implementa um trait exigido por um de seus bounds.

Um operador é usado sobre um parâmetro de tipo genérico que não carrega o trait bound correspondente. Sem ele, o compilador não garante que a operação vale para todo argumento de tipo possível.

Um bound na assinatura da função nomeia um trait que o compilador não conhece.

Um operador é usado sobre um valor de struct/enum concreto cujo tipo não implementa o trait exigido. Sem ele não há método para dirigir o operador, e quebraria em runtime.

Caminhos qualificados de trait precisam ser `core::<módulo>::<Trait>` ou `std::<módulo>::<Trait>`, nomeando um `pub trait` realmente declarado ali — tanto em bound genérico quanto em cabeçalho de `impl`.

Um `impl Trait for Tipo` está sem um ou mais métodos obrigatórios (os que não têm corpo padrão). Sem eles, o despacho de método e operador quebraria em runtime.

Um método de coleção (`each`, `filter`, `len`, …) foi chamado diretamente sobre um wrapper `Result` ou `Option`. Desembrulhe-o primeiro com `?>`, `?` ou `.unwrap()`.

`?.` é encadeamento null-safe, não desembrulhamento falível. Um `Result` ou `Option` nunca é `nil`, então o encadeamento opera sobre o wrapper. Use `expr ?> .m(...)`, `let v = expr?` ou `expr!.m(...)` em vez disso.

`for x in expr` exige que `expr` produza uma sequência. Zolo itera coleções nativas e qualquer tipo que implemente `Iterator`/`IntoIterator`; um struct ou enum que não implementa nenhum dos dois não dá nada ao laço.

Um `match` sobre um tipo fechado — `bool`, um enum (incluindo payloads), um optional de payload fechado, uma union fechada, ou tuplas/records de campos fechados — tem braços sem guard que não cobrem todos os valores possíveis. Um braço com guard nunca prova cobertura, porque o guard pode avaliar para `false`.

Um pattern de enum nomeia uma variante real mas a desestrutura com a forma de payload errada — variantes unit, tuple e struct exigem cada uma sua própria forma de pattern, e a aridade da tuple ou os campos do struct precisam concordar com a declaração.

Toda alternativa de um or-pattern (`A(x) | B(x)`) precisa introduzir os mesmos nomes com tipos compatíveis, já que o corpo do match roda depois que qualquer alternativa der certo e pode ler o nome que ela vinculou.

O postfix `?` e o pipe falível `?>` exigem um valor que pode falhar — `T?`, `Option<T>` ou `Result<T, E>`. Aplicar qualquer um deles a um valor estaticamente simples não tem caminho de falha para propagar.

O postfix `?`/`?>` retorna o `nil`, `Option.None` ou `Result.Err` correspondente a partir da função envolvente, e essa falha precisa ser compatível com o tipo de retorno declarado. `Option.None` não é intercambiável com `Result.Err`, e uma falha nilable nunca é embrulhada silenciosamente em nenhum dos dois enums.

`?.` e `??` são operadores exclusivos de nil, mas `Option<T>` e `Result<T, E>` são valores de enum embrulhados — nenhum dos dois wrappers é `nil` em si, então `??` não consegue desembrulhá-lo. Use o postfix `?`, pattern matching, ou um método explícito do wrapper como `unwrap_or`.

`as` só executa casts conhecidos pelo compilador — não faz parsing de texto, não calcula truthiness, não serializa dados nem executa uma conversão implementada por um tipo do usuário. Use `parse::<T>()`, `to_string()`, `try_into::<T>()`, ou uma comparação explícita.

`valor as? T` promete uma conversão exata, checada em runtime, mas os tipos de origem e destino não têm um caminho checado que preserve o valor — por exemplo, fazer parsing de texto não é cast. Use `parse`, `try_into`, ou uma política de cast numérico.

Um `as` numérico pode estreitar um range, mudar o sinal, descartar uma parte fracionária, ou arredondar um inteiro grande demais para o float de destino. Use `as?` quando só um valor exato for aceitável, ou `cast` com uma política nomeada de arredondamento/overflow quando a perda for intencional.

Um cast `as` simples a partir de `Any` não consegue provar que o valor em runtime realmente tem o tipo solicitado, então Zolo rejeita. Use um cast checado (`as?`) ou narrowing de fluxo (`is`).

`valor as str` mistura cast com formatação, e continua disponível apenas como ponte de migração. Use `.to_string()` explicitamente, ou um codec como `json.encode` ao produzir um formato de wire.

O valor de origem já tem o tipo solicitado, então `as Tipo` não comunica nenhuma intenção nova e não executa trabalho algum. Remova a expressão de cast redundante.

Uma política de `cast` numérico só se aplica à família de conversão que ela nomeia — `.wrap` é definida só para conversão inteiro-para-inteiro, enquanto `.trunc`/`.floor`/`.ceil`/`.nearest_even` convertem valores de ponto flutuante. Escolha uma política compatível, ou use `as?` quando só valores exatos forem aceitos.

`into::<T>()` exige um `impl From<Origem> for T` direto, e `try_into::<T>()` exige um `impl TryFrom<Origem> for T` direto. Zolo nunca inventa uma cadeia de conversão passando por um tipo intermediário — implemente o trait correspondente, ou chame o construtor pretendido explicitamente.

O `parse::<T>()` genérico é uma operação de texto: o receptor precisa ser `str` ou `bytes`, e `T` precisa ser um dos tipos numéricos suportados pelo parser do core. Use um decoder específico de domínio (como `json.decode`) para dados estruturados.

`unsafe bitcast::<T>(valor)` reinterpreta os bits da representação em vez de fazer uma conversão numérica ou de domínio, então os dois tipos precisam ser tipos numéricos de largura fixa com exatamente a mesma quantidade de bits. Use `as?`, `cast::<T>(política)`, `into` ou `try_into` para de fato mudar o valor.

Um `impl From<S>`/`TryFrom<S>` só é legal no pacote que possui o tipo de origem `S` ou o tipo de destino — caso contrário, dois pacotes sem relação poderiam definir significados concorrentes para a mesma conversão. Zolo também rejeita implementações sobrepostas e nunca busca cadeias de conversão como `A -> B -> C`.

`as?` e `is` só conseguem sondar uma categoria primitiva ou o nome declarado de um tipo do usuário (tipos genéricos pelo nome-base). Uma forma estrutural como `[int]`, `{str: int}`, um record, uma tupla, uma união ou `T?` não tem testemunha em runtime: sonde a categoria (`as? array`, `is map`) ou decodifique o valor com `@derive(Deserialize)` para validar os elementos.

Um tagged template `tag"…"` não é sintaxe especial — ele se reduz a uma chamada comum a uma função chamada `tag`, e nenhuma função com esse nome está em escopo.

`parallel { … }` roda cada statement de topo como sua própria task concorrente, então todo statement do bloco precisa ser uma expressão que possa virar uma.

Uma função executa um efeito (`!io`, `!net`, `!fs`, ...) que não declarou em sua assinatura.

Um efeito foi executado mas nenhum bloco `handle` envolvente o trata.

Um bloco `handle` tenta tratar uma operação que o efeito não declarou.

Um bloco `handle` está sem a implementação de uma das operações declaradas pelo efeito.

O handler referencia um nome de operação que não existe no efeito.

Uma assinatura de função ou handler faz referência a um efeito que o compilador não encontra.

Uma chamada `perform` ou operação de handler não corresponde à assinatura declarada do efeito.

`handle … with <handler_valor>` usa um handler-valor que cobre só parte das operações do efeito. O erro aparece no `with` e nomeia as operações faltantes.

Uma chamada `perform Efeito::op(…)` passou um argumento cujo tipo não corresponde ao tipo do parâmetro declarado da operação.

A forma resumida do TE800: em vez de reportar cada `perform`, junta todos os efeitos que a função de fronteira realmente precisa e reporta todos na assinatura.

Um parâmetro genérico é usado tanto como parâmetro de tipo quanto como cauda de variável de linha numa cláusula `with` (`{Fs | e}`). Um mesmo nome não pode significar um tipo e um conjunto de efeitos extras ao mesmo tempo.

Um `perform` mira uma operação declarada `multi` (retomável mais de uma vez). Continuações multi-shot hoje são exclusivas da VM.

O parâmetro de tipo de um efeito genérico não resolveu num `perform` — nem os tipos dos argumentos nem um `with Efeito<Concreto>` deram um tipo concreto.

`h` precisa ser algo cujo tipo seja `handler<…>`. Se resolver para outra coisa, não há conjunto de braços para despachar as operações realizadas.

Um parâmetro tipado como função simples (`fn(...) -> T`, sem cláusula `with`) promete pureza — nada do que roda nele realiza um efeito que o chamador já não conheça. Passar ali uma função que ela própria exige um efeito deixa esse efeito escapar totalmente não declarado, a mesma classe de vazamento que `TE802` bloqueia na direção comum de chamada.

Uma invariante de runtime que o compilador emitiu código para verificar (por exemplo, bounds, divisão por zero em const eval) foi violada.