Referencia de Diagnósticos

El lexer llegó al fin de archivo (o de línea, en algunos contextos) antes de encontrar la comilla de cierre de la cadena.

El parser esperaba un token específico (por ejemplo `}`, `)`, identificador, tipo) pero encontró otra cosa. Suele ser una llave, paréntesis o puntuación ausente.

Un token apareció donde la gramática no lo permite — típicamente un símbolo perdido, una palabra clave mal escrita o un separador faltante en la línea anterior.

Un error de parseo que no coincidió con ningún clasificador específico. Lee el mensaje del diagnóstico para la causa precisa.

Se escribió un comentario `<!-- -->` entre `<` y `>`, donde el propio HTML tampoco lo permite. Dentro de la etiqueta, usa los comentarios de Zolo: `//` o `/* */`. En los hijos de un elemento, `<!-- -->` sí funciona.

Equivalente a `TE001`. Emitido por el clasificador heredado cuando el nuevo typeck no adjuntó un código.

Alias heredado para `TE100`.

Alias heredado para `TE101`.

Alias heredado para `TE004`. La variable se declaró con `let`; usa `let mut` para permitir reasignación.

Alias heredado para `TE102`.

Un literal de struct omite uno o más campos obligatorios.

Alias heredado para `TE110`.

El valor retornado no coincide con el tipo de retorno declarado por la función.

Un nombre (función, variable, campo, variante) se declaró dos veces en el mismo ámbito.

Una anotación de tipo se refiere a un tipo que el compilador no puede encontrar.

El valor asignado a un binding `let` no satisface la anotación de tipo declarada.

El valor asignado a un binding `const` no satisface la anotación de tipo declarada.

`const` requiere una expresión constant-foldable. Usa `let` para valores en runtime.

Los bindings `let` son inmutables por defecto. Usa `let mut x = ...` para permitir reasignación, o crea un nuevo binding con shadowing via `let`.

Operadores como `+=`, `-=`, `*=` requieren que ambos lados sean numéricos (o cadenas, para `+=`).

La función declaró un retorno en tupla, pero la sentencia `return` proporciona menos valores.

La función retorna más valores de los que su tipo de retorno único puede contener.

Un literal de array mezcla tipos incompatibles; los arrays son homogéneos.

La aritmética binaria requiere que ambos operandos sean numéricos y (en modo strict) del mismo tipo numérico.

El nombre no está declarado en ningún ámbito envolvente. El compilador adjunta una sugerencia "¿quisiste decir?" cuando existe un nombre similar.

El objetivo de una expresión de llamada no es un tipo invocable.

La struct no declara este campo. Se adjuntan sugerencias "¿quisiste decir?" para nombres similares.

Una anotación de tipo o campo de variante de enum hace referencia a un tipo que el compilador no puede resolver.

El tipo receptor no tiene un método con ese nombre. Verifica la ortografía, los imports y la visibilidad del trait.

Un nombre simple corresponde a un módulo conocido de la biblioteca estándar (`math`, `json`, `http`, `os`, …) que nunca se trajo al ámbito. A diferencia de TE100, el compilador reconoce el nombre e indica exactamente qué línea `use` falta.

Un literal de struct omite un campo que no tiene valor por defecto ni zero-value de respaldo. Todo campo sin default debe proporcionarse explícitamente en la construcción.

Un struct con `@derive(Default)` tiene un campo cuyo tipo no posee zero-value ni default explícito, por lo que no se puede sintetizar ninguna impl de `Default`.

Un campo de struct se escribió sin anotación de tipo, apoyándose en su valor por defecto para inferirlo (`nombre = valor`) — pero el tipo de ese valor es ambiguo (p. ej. `nil`, o una expresión que resuelve a `any`).

El número de argumentos pasados no coincide con la cantidad de parámetros de la función.

El tipo de un argumento no coincide con el tipo del parámetro correspondiente.

Dos o más campos embebidos con `using` declaran un campo con el mismo nombre, por lo que un acceso `.campo` en el struct externo no sabe de cuál embed promoverlo.

Un campo marcado con `using` debe embeber otro struct — son sus campos los que se promueven. Un escalar, o cualquier tipo que no sea una declaración de struct conocida, no tiene campos que promover.

Un enum optó por discriminantes numéricos (tipo de respaldo, o un `= n` explícito) pero es genérico o tiene una variante con payload. Los discriminantes solo tienen sentido para enums planos, con todas las variantes unitarias.

El discriminante de una variante está fuera del rango del tipo de respaldo declarado (`enum E: u8` lo limita a `0..=255`), por lo que no sobreviviría al ida y vuelta de `to_int()`/`from_int()`.

Dos variantes del mismo enum resolvieron al mismo entero — o dos `= n` explícitos colisionan, o un valor autoincrementado cayó sobre uno ya usado.

Bajo `@stable` el autoincremento está prohibido: insertar una variante en el medio renumeraría silenciosamente todas las siguientes, rompiendo la codificación que la anotación promete mantener.

El discriminante `= expr` de una variante o no evaluó a un entero en tiempo de compilación, o no pudo evaluarse como constante de compilación.

Un enum `@flags` es genérico o tiene una variante con payload. `@flags` modela una bitmask sobre un conjunto fijo y plano de variantes unitarias — no hay espacio para parámetros de tipo ni payloads.

Cada variante `@flags` debe ser un bit nuevo (autoincrementado o potencia de dos explícita) o un compuesto nombrado construido solo a partir de bits declarados encima de ella.

El valor de una flag está fuera del rango del tipo de respaldo del enum — las flags en `enum: u8` llegan hasta `255` (bit 7).

Dos flags de un solo bit en el mismo enum `@flags` resolvieron al mismo bit, normalmente porque recibieron el mismo valor explícito.

Un patrón de destructuring — `let Struct { … } = expr`, un `let { … }` anónimo, un patrón de parámetro o una asignación con destructuring de struct — nombra un campo que el struct no tiene.

El bloque `else` puede caer fuera. Si lo hiciera, la ejecución seguiría hacia los bindings del patrón con un valor que NO coincidió, por lo que todo camino por `else` debe retornar, hacer panic, romper o continuar.

El patrón puede no coincidir (patrón de variante de enum, patrón de longitud de array, …) y no tiene cláusula `else`. Sin ella, un valor que no coincide ligaría basura silenciosamente.

Un patrón de struct anónimo necesita saber qué struct desestructura, pero el tipo del valor no resuelve a un struct concreto — normalmente por falta de anotación de tipo.

Un patrón de struct nombrado en posición de parámetro (`fn f(NombreStruct { … }: T)`) nombra un struct distinto al de la anotación de tipo del propio parámetro.

El spread final de un literal de struct (`Struct { ..origen }`) tiene un `origen` que no es struct ni record, por lo que no hay campos que esparcir.

Una asignación con destructuring de tupla (`(a, b, c) = expr`) tiene un número de destinos distinto al número de valores de `expr`.

Los operadores compuestos (`+=`, `-=`, …) no tienen significado por elemento cuando el lado izquierdo es un patrón entero, y el spread `..` no tiene sentido como destino de asignación.

Un argumento nombrado (`f(nombre: valor)`) no coincide con los parámetros declarados de la función llamada — un nombre desconocido o duplicado, un argumento posicional después de uno nombrado, un parámetro intermedio omitido, o una llamada cuya firma no se conoce localmente.

El placeholder `_` solo es válido como argumento directo en la llamada del lado derecho (RHS) de una etapa de pipe `|>`/`?>` (como máximo uno por etapa), o como la cabeza de una cadena de campo/método/índice usada como argumento de llamada (`_.campo`). Un `_` suelto, un segundo `_` en la misma etapa de pipe, o `_` como lado izquierdo de un pipe son todos rechazados.

Se identificó un enum real y declarado para este punto — como base de `EnumName::variante`, o como tipo del valor evaluado por un pattern con atajo `.variante` — pero el nombre de la variante no coincide con ninguna variante declarada. Se incluye una sugerencia "¿quisiste decir?" en el mensaje cuando existe un nombre cercano.

El nombre forma parte del preludio siempre-en-ámbito de la VM, pero el backend native/LLVM no tiene implementación para él. Compilar igual haría que evaluara silenciosamente a `nil` y saliera con 0, así que el build falla.

Chequeo exclusivo de native/LLVM: un identificador simple no resolvió a nada. Sin preludio Lua de respaldo, se convertiría silenciosamente en `nil` en runtime — la clase "un typo se vuelve un no-op silencioso" que esto detecta en tiempo de build.

El atajo `.Variante` obtiene su enum del tipo que espera la posición donde aparece, y esta posición no aporta nada utilizable — ningún tipo esperado (un `let` sin anotación, un argumento de una función cuya firma no se conoce), un parámetro genérico aún sin fijar, o un tipo que no es un enum. Anota la variable o escribe la forma calificada `Enum::Variante`.

El atajo `.Variante` resolvió su enum a partir del tipo esperado por la posición, pero ese enum no tiene ninguna variante con ese nombre. Se incluye una sugerencia "¿quisiste decir?" cuando existe un nombre cercano. La forma de pattern del mismo error reporta `TE133` en lugar de este código.

Un build native/LLVM no logró unir (splice) un módulo de declaración: o una declaración del usuario comienza con el prefijo `__zolo_std_`, reservado por el compilador, o una función alcanzable del módulo de declaración hace referencia a un elemento hermano que el linker no puede llevar al programa final. Cualquiera de los dos casos haría que el build AOT divergiera silenciosamente de la VM.

`<style>` y `<script>` son elementos de texto crudo: su contenido corre literal hasta el `</style>`/`</script>` correspondiente, sin markup anidado y sin interpolación `{expr}`. Llegar al final del archivo antes de ese cierre reporta TE139 en lugar del mensaje genérico "unclosed element" — normalmente una etiqueta de cierre olvidada, o una cadena con forma `</tag` dentro del contenido (por ejemplo, un literal de cadena JS) que cerró el bloque antes de tiempo.

Una recipe del Resource Graph en tiempo de build (`Resource.dir(...).seal()`) no pudo sellarse en su Resource Image inmutable — una ruta ausente o que no es un directorio, un patrón `include` que no coincidió con nada, una ruta que escapa de la raíz del recurso, una colisión de ruta lógica, o un archivo que no se pudo leer mientras se sellaba el snapshot. No existe respaldo hacia el directorio de trabajo en runtime: el build falla en su lugar.

El compilador recibió un valor interno malformado del Resource Graph, o una Resource Image sellada falló sus comprobaciones de integridad — un campo de recipe inválido (`root`, `includes`, `excludes`) o un estado de build corrupto, distinto de las fallas accionables de entrada/sellado de `TE140`.

Un `;` colocado después de la expresión final de un bloque suprime su valor, así que el bloque concluye `void` en vez de producir un resultado. `TE142` se dispara cuando ese void causado por un terminador se usa donde se exige un valor — vinculado a un `let`, pasado como argumento, etcétera.

Una función declara `-> T`, pero un `;` después de su expresión final suprime ese valor, así que el cuerpo concluye `void` en lugar de un `T`. A menos que otro `return expr` proporcione el valor, la función nunca puede satisfacer su propia firma.

El campo declara `get`, pero no `set`; por eso no se permiten asignaciones después de construirlo.

Usar `self.<mismo-campo>` dentro de su propio accesor causaría recursión; usa el nombre contextual `field`.

Un accesor puede heredar o restringir la visibilidad del campo, pero no puede exponer públicamente un campo privado.

`?` propaga el fallo, pero desempaqueta el éxito. Una función que devuelve `Result` u `Option` debe envolver ese éxito explícitamente con `.Ok(...)` o `.Some(...)`.

Un literal `tw"..."` debe ser una lista estática de nombres de clase de Tailwind. Interpolar un valor en él (`tw"bg-{color}-600"`) ocultaría parte del nombre de la clase del escáner de Tailwind en tiempo de build, así que Zolo lo rechaza — elige entre literales completos usando control de flujo común.

El tipado strict requiere que cada `let`/`const` tenga una anotación de tipo explícita.

El tipado strict requiere que cada parámetro de función tenga un tipo explícito.

Un derive estructurado devolvió syntax que no puede insertarse en el destino; el resultado debe ser `Syntax<.Items>` o `Syntax<.Item>`.

Un hole `${value}` recibió un valor sin representación segura en código fuente; inserta un primitivo o un nodo `Syntax<K>`.

`syntax.ident(text)` recibió un texto que no es un único identificador Zolo válido y que no sea palabra reservada.

Un spread `${..values}` recibió algo distinto de una lista o tupla de nodos de syntax de una misma categoría compatible.

Los ítems generados escapan del ámbito de expansión declarado por `@derive_for`, como una función libre no relacionada creada por un derive restringido a impl.

Una función `@derive_for` devolvió algo distinto de los resultados compatibles: `str`, `Syntax<.Items>` o `Syntax<.Item>`.

Un atributo namespaced del derive contiene una opción desconocida, duplicada, ausente, no literal o con tipo incorrecto.

Un tipo usa `@derive(T)`, pero ningún deriver para `T` está disponible en el ámbito. Zolo nunca lo ignora silenciosamente — un nombre mal escrito no puede producir un programa parcialmente generado que solo falla en runtime. Importa o declara la función pública que expone el deriver, exportada por convención con el mismo nombre que la capacidad.

`await` recibió un valor cuyo tipo conocido no es `Future<T>` ni `Task<T>`. Solo esos dos wrappers pueden suspenderse; un valor común ya está disponible y no tiene nada que esperar.

`yield` solo es válido dentro de un generator declarado con `fn*`. Una función común o `async fn` produce un único resultado y no expone ningún iterador pull donde hacer yield.

Un generator (`fn*`) usó `return valor`. La terminación y los ítems producidos son conceptos separados en un generator: `return` puede detenerlo antes de tiempo, pero su valor nunca se produce como ítem del iterador — usa `yield` para eso.

Un valor producido por `yield` no satisface el tipo de elemento declarado del generator. Todo `yield` dentro de `fn* ... -> T` debe producir un valor asignable a `T`.

`await` apareció dentro de un generator `fn*`. Los generators asíncronos aún no tienen un contrato de scheduler compartido por todos los backends, así que Zolo rechaza la combinación en vez de dejar que un backend la reanude con una semántica distinta a la de otro.

`break :label` o `continue :label` nombra un loop que no está activo léxicamente. Los labels nunca cruzan un límite de función/lambda, y una task `spawn`eada o un callback agendado con `every`, `after` o `timeout` inicia su propia región de control de flujo, por lo que no puede saltar a un loop del llamador.

Dos loops anidados, activos al mismo tiempo, declaran el mismo label. Una salida etiquetada sería ambigua para quien lee, aunque la declaración más interna pudiera resolverse mecánicamente.

Un `break` o `continue` sin label aparece fuera de un loop. Estas sentencias solo pueden transferir el control dentro de un `loop`, `while` o `for` envolvente.

Un `break` que lleva un valor apunta a `while` o `for`. Solo la forma incondicional `loop` es una expresión que produce valor, así que un `break` con valor solo es válido allí.

Los valores que llevan los `break` alcanzables no concuerdan con el tipo de resultado de una expresión `loop`. Un `break` sin valor aporta `void`, así que no puede salir de un loop que debería producir un valor no-void.

`timeout duración { ... }` retorna `Result<Any, TimeoutError>`. El fallo de timeout es control de flujo tipado común — no es un record sin tipo, y nunca se convierte silenciosamente en el valor de éxito.

El número de argumentos de tipo proporcionados no coincide con la cantidad de parámetros del tipo genérico.

Un bound de trait, bloque `impl` o cláusula `where` hace referencia a un trait que el compilador no encuentra.

Un `impl Trait for Tipo` no es coherente con la declaración del trait — o agrega un método que el trait no declara, o otra implementación ya satisface el mismo objetivo parametrizado y la misma instancia de trait.

Un método en `impl Trait for Tipo` no coincide con el trait después de sustituir `Self`, los argumentos del trait, los tipos asociados y los parámetros genéricos del método — los tipos/calificadores de parámetro, el tipo de retorno, los bounds genéricos y las filas de efecto forman parte del contrato.

Una implementación omite un tipo asociado obligatorio, lo define más de una vez, nombra un tipo asociado que el trait no declara, o proporciona un tipo que falla los bounds del tipo asociado.

Una implementación eligió un tipo asociado concreto que no satisface un bound que el trait declaró para él. El diagnóstico nombra la implementación, el tipo asociado proyectado y el requisito que falló — el tipo original se conserva, nunca se amplía silenciosamente a `Any`.

Un trait declara un tipo asociado sin valor por defecto, pero una implementación no lo define, así que el compilador no puede proyectar `Self::Item` (u otro nombre asociado) desde esa implementación.

El tipo concreto implementa el nombre de trait solicitado, pero con argumentos de tipo diferentes. Los witnesses de trait son exactos — implementar `Sink<str>` no prueba `Sink<int>`.

Un valor tipado como union solo puede usarse sin narrowing a través de miembros compartidos por todas las alternativas. Leer un campo o llamar un método que falta en algunas alternativas sería válido para un valor en runtime e inválido para otro.

Un handler de evento dentro de un `@island` contiene una expresión que la reducción del cliente de Verniz no puede representar en JavaScript. El renderizado en el servidor aún produciría el control, pero publicarlo sin su handler crearía un elemento con apariencia interactiva que no hace nada — por eso el build falla en su lugar.

Una asignación apunta a un signal derivado declarado con `let<signal>`. Una cell derivada se define por su inicializador y se recalcula a partir de las cells de origen que lee — no es estado escribible, así que asignarle la dejaría en desacuerdo con su propio grafo de dependencias.

Un `effect` dentro de un `@island` contiene comportamiento que la reducción del cliente de Verniz no puede compilar a JavaScript. A diferencia del renderizado en el servidor, un effect de island no tiene una mitad en el servidor capaz de preservar el comportamiento — si no se emite al cliente, nunca se ejecuta, así que el build se rechaza en vez de descartarlo silenciosamente.

`@(expr)` compila a un puente de custom property de CSS (`var(--…)`), que solo existe en valores de declaración — después del `:`, antes del `;`. En un selector, un nombre de propiedad o el preludio de una at-rule no hay `var()` al que compilar, y hacer splice de texto del usuario ahí es un anti-feature deliberado. Mueve la parte dinámica a un valor, o alterna clases estáticas en el markup.

Un `<style children={expr}>` lleva contenido de runtime que el compilador no puede ver — no puede izarlo ni acotarlo; acotar texto desconocido sería una mentira. Spec §6.1: el contenido dinámico debe optar por `global` explícitamente (`<style global children={…}>`), la única forma de style que sigue siendo un nodo de render.

Un valor de `@()` viaja como custom property de CSS, y solo `str`, `int` y `float` serializan a una. Un valor tipado `bool`, `View`, map, struct o función se rechaza en compilación — en el render se convertiría en basura o desaparecería. Los valores sin tipo (`Any`) quedan en silencio: este error nunca adivina.

`@()` compila a `var(--…)`, y CSS no concatena cadenas en valores comunes — `var(--w)px` es un error de sintaxis que el navegador descarta, no "número más unidad". Escribe `calc(@(x) * 1px)` o interpola la cadena completa (`@(f"{x}px")` — dentro de `@()` estás de vuelta en Zolo). `!important`, `/` y `*` en `calc()` son vecinos sin espacio legales.

`:global(…)` exime a un compound del sello de ámbito hermético. Un wrapper vacío (`:global()`) no exime nada, y uno anidado (`:global(:global(a))`) escapa de un escape — ambos solo pueden ser un error. En un cuerpo `<style global>`, `:global()` ni siquiera es sintaxis Zolo y pasa intacto.

Un `<style>` con ámbito pertenece al fn de componente que lo rodea — el sello de clase del fn es el ámbito de los selectores. En una sentencia de nivel superior o un método de `impl`/`trait` no hay componente, así que no hay ámbito. Añade `global` (un `<style global>` estático fuera de un componente se renderiza en su lugar) o muévelo a un fn de componente. Un cuerpo con `@()` lo reporta incluso con `global`: sus valores necesitan un elemento raíz de componente.

Cada valor de `@()` viaja como custom property de CSS en el elemento raíz del componente (el literal de elemento en posición de cola), heredándose DOM abajo. Un componente que delega toda su vista — sin raíz de elemento propia — no da a los valores dónde viajar. Haz que la cola sea un literal de elemento (un `<div>` envolvente sirve) o quita la interpolación.

Un atributo HTML conocido no es válido para el elemento escrito. Verniz valida las etiquetas nativas contra su tabla DOM versionada; las props de componente siguen pasando por los diagnósticos comunes de argumento nombrado.

Un binding `bind:` de doble vía no es compatible con el elemento, o su tipo de origen conocido es incompatible con la propiedad de DOM destino — por ejemplo, vincular una cell `str` a `bind:checked`, que espera `bool`.

Un atributo de handler de evento nombra un evento que Verniz no reconoce en ese elemento. Los nombres de evento usan la grafía del atributo DOM, como `onclick`, `oninput` y `onchange`.

Un elemento HTML void, como `input`, `img` o `br`, se escribió con hijos o una etiqueta de cierre explícita. Los elementos void nunca pueden tener contenido, así que usa la forma de autocierre.

Una comprobación de accesibilidad de alta confianza: una `<img>` no tiene texto alternativo, o un control interactivo no tiene un nombre que un lector de pantalla pueda anunciar. Solo se dispara cuando la ausencia del nombre es segura — contenido dinámico, `children` o un spread de `HtmlAttrs` aún pueden proporcionarlo en runtime.

Un atributo o role ARIA conocido se usa con una grafía o valor inválido, o un label apunta a un id de elemento que no existe en el markup escrito.

Un destino de `ref` no puede recibir un elemento del navegador. Un `ref` debe ser una cell de origen `DomRef` opcional (`var<signal> nombre: DomRef = nil`) declarada dentro del `@island` que la posee.

Un `{...spread}` es incompatible con su destino. El reenvío dinámico hacia un elemento nativo debe estar tipado como `HtmlAttrs`; un spread de componente debe exponer campos de record estáticamente conocidos para que la comprobación común de props siga activa.

Un modificador de evento (`prevent`, `stop`, `once`, `capture`, `passive`, `self`) es desconocido, está duplicado, o se combina de forma incompatible — `passive` no se puede combinar con `prevent`.

Un contrato de attach no se puede cumplir — el compilador detecta destinos de portal estáticamente vacíos, y el verificador de attach de desarrollo también reporta destinos de portal ausentes, marcadores de island obsoletos, propiedades de binding inválidas y refs que no pertenecen a la island.

Se leyó un miembro de lifecycle como `pending`, `error` o `state` desde una referencia a una función común. Solo una referencia a una función declarada `@action` tiene el tipo nominal `ActionFn<...>` y una lane del lado cliente.

Un código fuera de cualquier `@island` intenta observar el lifecycle de un `ActionFn`. Una referencia de action sigue siendo invocable en el servidor, pero `pending`, `state`, `retry` y el resto del lifecycle observable son capacidades propias del navegador que no pueden cruzar un límite de island o de wire.

Una mutation action solicitó una política desconocida, o una política de sustitución/cancelación como `.Latest`. Una mutation ya aceptada por el servidor puede seguir confirmándose incluso después de que el cliente deja de interesarse por la respuesta, así que cancelar solo la continuación del cliente haría que la UI mintiera sobre el efecto.

Se creó un `.lane()` directamente dentro de un `for` renderizado. Una lane explícita posee estado mutable de lifecycle del cliente, pero una iteración de lista no tiene identidad léxica estable en cuanto se insertan, eliminan o reordenan filas.

Un valor que cruza entre Zolo y el TypeScript del navegador no tiene una representación JSON determinística que el puente Wire acepte — el puente nunca recurre a `any`. Las funciones, closures, handles, `ResourceFs`, claves de map que no son string, y los tipos de usuario sin marcar se quedan en su lado de origen; los structs/enums necesitan `@wire`.

Una declaración marcada `@secret` es alcanzable desde un tipo `@wire` o un contrato de navegador `@action`. Publicarla colocaría un valor privado en una declaración, codec, request, response o bundle de navegador generado — quitar `@secret` solo para silenciar el diagnóstico es inseguro.

Verniz no logró convertir un archivo Markdown/JSON/TOML/YAML escrito en el struct de metadatos declarado por `content.collection` — un campo de frontmatter ausente o mal tipado, una fecha que no parsea, una ruta no portable, o (para `ContentTransform`) un problema de route callback/alias/fallback.

Una función genérica se llamó con un argumento de tipo que no implementa un trait requerido por uno de sus bounds.

Se usa un operador sobre un parámetro de tipo genérico que no lleva el trait bound correspondiente. Sin él, el compilador no puede garantizar que la operación sea válida para todo argumento de tipo posible.

Un bound en la firma de la función nombra un trait que el compilador no conoce.

Se usa un operador sobre un valor de struct/enum concreto cuyo tipo no implementa el trait requerido. Sin él no hay método que impulse el operador y fallaría en runtime.

Las rutas calificadas de trait deben ser `core::<módulo>::<Trait>` o `std::<módulo>::<Trait>`, nombrando un `pub trait` realmente declarado allí — tanto en un bound genérico como en una cabecera de `impl`.

Un `impl Trait for Tipo` carece de uno o más métodos requeridos (los que no tienen cuerpo por defecto). Sin ellos, el despacho de método y operador fallaría en runtime.

Se llamó a un método de colección (`each`, `filter`, `len`, …) directamente sobre un wrapper `Result` u `Option`. Desenvuélvelo primero con `?>`, `?` o `.unwrap()`.

`?.` es encadenamiento null-safe, no desenvolvimiento fallible. Un `Result` u `Option` nunca es `nil`, por lo que el encadenamiento opera sobre el wrapper. Usa `expr ?> .m(...)`, `let v = expr?` o `expr!.m(...)` en su lugar.

`for x in expr` exige que `expr` produzca una secuencia. Zolo itera colecciones nativas y cualquier tipo que implemente `Iterator`/`IntoIterator`; un struct o enum que no implementa ninguno no le da nada al bucle.

Un `match` sobre un tipo cerrado — `bool`, un enum (incluyendo payloads), un optional de payload cerrado, una union cerrada, o tuplas/records de campos cerrados — tiene brazos sin guard que no cubren todos los valores posibles. Un brazo con guard nunca prueba cobertura, porque el guard puede evaluar a `false`.

Un pattern de enum nombra una variante real pero la destructura con la forma de payload incorrecta — las variantes unit, tuple y struct exigen cada una su propia forma de pattern, y la aridad de la tuple o los campos del struct deben concordar con la declaración.

Cada alternativa de un or-pattern (`A(x) | B(x)`) debe introducir los mismos nombres con tipos compatibles, ya que el cuerpo del match corre después de que cualquier alternativa tenga éxito y puede leer el nombre que esa alternativa vinculó.

El postfix `?` y el pipe falible `?>` exigen un valor que pueda fallar — `T?`, `Option<T>` o `Result<T, E>`. Aplicar cualquiera de los dos a un valor estáticamente simple no tiene camino de fallo que propagar.

El postfix `?`/`?>` retorna el `nil`, `Option.None` o `Result.Err` correspondiente desde la función envolvente, y ese fallo debe ser compatible con su tipo de retorno declarado. `Option.None` no es intercambiable con `Result.Err`, y un fallo nilable nunca se envuelve silenciosamente en ninguno de los dos enums.

`?.` y `??` son operadores exclusivos de nil, pero `Option<T>` y `Result<T, E>` son valores de enum envueltos — ninguno de los dos wrappers es `nil` en sí mismo, así que `??` no puede desenvolverlo. Usa el postfix `?`, pattern matching, o un método explícito del wrapper como `unwrap_or`.

`as` solo ejecuta casts conocidos por el compilador — no parsea texto, no calcula truthiness, no serializa datos ni ejecuta una conversión implementada por un tipo de usuario. Usa `parse::<T>()`, `to_string()`, `try_into::<T>()`, o una comparación explícita.

`valor as? T` promete una conversión exacta, comprobada en runtime, pero los tipos de origen y destino no tienen un camino comprobado que preserve el valor — por ejemplo, parsear texto no es un cast. Usa `parse`, `try_into`, o una política de cast numérico.

Un `as` numérico puede estrechar un rango, cambiar el signo, descartar una parte fraccionaria, o redondear un entero demasiado grande para el float de destino. Usa `as?` cuando solo se acepte un valor exacto, o `cast` con una política nombrada de redondeo/overflow cuando la pérdida sea intencional.

Un cast `as` simple desde `Any` no puede probar que el valor en runtime realmente tiene el tipo solicitado, así que Zolo lo rechaza. Usa un cast comprobado (`as?`) o narrowing de flujo (`is`).

`valor as str` mezcla cast con formateo, y sigue disponible solo como puente de migración. Usa `.to_string()` explícitamente, o un codec como `json.encode` al producir un formato de wire.

El valor de origen ya tiene el tipo solicitado, así que `as Tipo` no comunica ninguna intención nueva y no realiza ningún trabajo. Elimina la expresión de cast redundante.

Una política de `cast` numérico solo se aplica a la familia de conversión que nombra — `.wrap` está definida solo para conversión de entero a entero, mientras que `.trunc`/`.floor`/`.ceil`/`.nearest_even` convierten valores de punto flotante. Elige una política compatible, o usa `as?` cuando solo se acepten valores exactos.

`into::<T>()` exige un `impl From<Origen> for T` directo, y `try_into::<T>()` exige un `impl TryFrom<Origen> for T` directo. Zolo nunca inventa una cadena de conversión pasando por un tipo intermedio — implementa el trait correspondiente, o llama al constructor pretendido explícitamente.

El `parse::<T>()` genérico es una operación de texto: el receptor debe ser `str` o `bytes`, y `T` debe ser uno de los tipos numéricos soportados por el parser del core. Usa un decoder específico del dominio (como `json.decode`) para datos estructurados.

`unsafe bitcast::<T>(valor)` reinterpreta los bits de la representación en lugar de hacer una conversión numérica o de dominio, así que ambos tipos deben ser tipos numéricos de ancho fijo con exactamente la misma cantidad de bits. Usa `as?`, `cast::<T>(política)`, `into` o `try_into` para cambiar el valor de verdad.

Un `impl From<S>`/`TryFrom<S>` solo es legal en el paquete que posee el tipo de origen `S` o el tipo de destino — de lo contrario, dos paquetes sin relación podrían definir significados en competencia para la misma conversión. Zolo también rechaza implementaciones superpuestas y nunca busca cadenas de conversión como `A -> B -> C`.

`as?` e `is` solo pueden sondear una categoría primitiva o el nombre declarado de un tipo de usuario (los tipos genéricos por su nombre base). Una forma estructural como `[int]`, `{str: int}`, un record, una tupla, una unión o `T?` no tiene testigo en tiempo de ejecución: sondea la categoría (`as? array`, `is map`) o decodifica el valor con `@derive(Deserialize)` para validar sus elementos.

Un tagged template `tag"…"` no es sintaxis especial — se reduce a una llamada normal a una función llamada `tag`, y no hay ninguna función con ese nombre en el ámbito.

`parallel { … }` ejecuta cada sentencia de nivel superior como su propia tarea concurrente, por lo que toda sentencia del bloque debe ser una expresión que pueda convertirse en una.

Una función ejecuta un efecto (`!io`, `!net`, `!fs`, ...) que no declaró en su firma.

Se ejecutó un efecto pero ningún bloque `handle` envolvente lo maneja.

Un bloque `handle` intenta manejar una operación que el efecto no declaró.

Un bloque `handle` no implementa una de las operaciones declaradas por el efecto.

El handler hace referencia a un nombre de operación que no existe en el efecto.

Una firma de función o handler hace referencia a un efecto que el compilador no encuentra.

Una llamada `perform` u operación de handler no coincide con la firma declarada del efecto.

`handle … with <handler_valor>` usa un handler-valor que cubre solo parte de las operaciones del efecto. El error aparece en el `with` y nombra las operaciones faltantes.

Una llamada `perform Efecto::op(…)` pasó un argumento cuyo tipo no coincide con el tipo del parámetro declarado de la operación.

La forma resumida de TE800: en lugar de reportar cada `perform`, reúne todos los efectos que la función de frontera realmente necesita y los reporta en la firma.

Un parámetro genérico se usa a la vez como parámetro de tipo y como cola de variable de fila en una cláusula `with` (`{Fs | e}`). Un mismo nombre no puede significar un tipo y un conjunto de efectos extra a la vez.

Un `perform` apunta a una operación declarada `multi` (reanudable más de una vez). Las continuaciones multi-shot hoy son exclusivas de la VM.

El parámetro de tipo de un efecto genérico no resolvió en un `perform` — ni los tipos de los argumentos ni un `with Efecto<Concreto>` dieron un tipo concreto.

`h` debe ser algo cuyo tipo sea `handler<…>`. Si resuelve a otra cosa, no hay conjunto de brazos al que despachar las operaciones realizadas.

Un parámetro tipado como función simple (`fn(...) -> T`, sin cláusula `with`) promete pureza — nada de lo que corre en ella realiza un efecto que el llamador ya no conozca. Pasar allí una función que ella misma exige un efecto deja que ese efecto escape completamente sin declarar, la misma clase de fuga que `TE802` bloquea en la dirección común de llamada.

Una invariante de runtime que el compilador emitió código para verificar (por ejemplo, bounds, división por cero en const eval) fue violada.