# Ejemplo: vista que falla junto a otra válida

Patrón del catálogo: "Ejemplo 7: vista que falla sin impedir otra vista válida" — un solo `source`
(`sales.csv`), dos vistas: `good` (funciona) y `broken` (falla a propósito porque su transform
exige una columna `Region` que la fuente no tiene).

No es un ejemplo de "cómo escribir un transform que falla" — es un ejemplo de **aislamiento**: el
runtime debe seguir sirviendo `good` con normalidad aunque `broken` esté rota, y el error de
`broken` debe ser legible, no un stack trace opaco (ver Parser Contract: `debe` fallar con mensaje
claro cuando la entrada no tiene el significado esperado, aunque tenga la forma esperada).

## Qué copiar

- La estructura de `views[]` con dos entradas independientes sobre la misma fuente.
- El patrón del transform roto: valida explícitamente lo que necesita y lanza un `Error` legible
  en vez de fallar de forma opaca (`row.Region` sería `undefined` silenciosamente si no se
  validara antes).

## Qué reemplazar

- La fuente y ambos transforms por el caso real.
- No hace falta que uno de tus transforms falle a propósito en producción — este patrón es
  específicamente para demostrar aislamiento, no una práctica recomendada por sí misma.

## Verificación

```bash
node --test test.mjs
```

`test.mjs` no usa el kit compartido de `examples/lib/example-runner.mjs` porque ese kit asume que todas
las vistas declaradas en `expected/data.json` se ejecutan sin error; aquí una vista falla por
diseño, así que el test valida el aislamiento directamente contra `refreshPackage`.