El inspector

Selecciona un nodo y el inspector muestra exactamente los campos que el tipo de ese nodo lee — ni más, ni menos. Los formularios se generan del mismo catálogo que alimenta el linter y el asistente de IA, así que lo que ves es lo que el framework soporta.

Anatomía

Parte	Propósito
Header	Ícono del nodo, label editable, chip de tipo y un menú (duplicar, silenciar, eliminar, copiar JSON del nodo)
Issues	Hallazgos del linter para este nodo, cada uno enlazando el campo que lo causó
Fields	Los parámetros del nodo, agrupados en main y advanced
Run condition	`skip_if_false`, para cada transformación
Worth knowing	Comportamientos que suelen vivir solo en el código fuente del framework
Examples	Snippets válidos para este tipo de nodo
Notes	Anotación libre, nunca compilada

Tipos de campo

El widget sigue la forma JSON que el framework espera:

Widget	Para	Notas
Text	nombres, paths, valores únicos
SQL	condiciones, expresiones, queries	monoespaciado; resalta los placeholders `{param}` y `{{variable}}` que detecta
Number / Toggle	opciones numéricas y booleanas
Select	opciones fijas (`how`, `mode`, `method`)	solo los valores que el framework acepta
Chips	listas ordenadas de strings (`columns`, `by`, `merge_keys`)	pega una lista separada por comas para añadir varias a la vez
Expression rows	mapas ordenados (`agg`, `with_column.columns`)	el orden se preserva porque es significativo
Key/value rows	mapas ordenados (`cast.columns`, `rename.mappings`)	el orden importa para `rename`
JSON	estructuras anidadas (`struct.fields`, `pivot`)	feedback de parseo en vivo bajo el box

Los widgets ordenados existen porque el orden es semántico en el framework: rename aplica los mapeos en secuencia, y with_column.columns deja que una expresión posterior use una columna creada por una anterior.

Fuentes y destinos

Elegir un formato reescribe el formulario a las opciones de ese conector — las que realmente lee, con los defaults del framework precargados. Cambiar el formato descarta opciones que el nuevo no define, así que un config nunca arrastra claves muertas de una elección anterior.

Los destinos añaden:

Write mode, restringido a los modos que ese formato soporta
Partition by, oculto para conectores donde no significa nada
Column projection, un toggle más una lista de chips
Options, incluidos los campos de merge que solo aparecen en modo merge

Validaciones

El nodo de validations tiene su propio formulario: la política on_failure con una explicación de una línea de cada modo, una lista de reglas donde cada regla renderiza sus propios campos, y un destino de report opcional que reutiliza el formulario de output completo.

Condición de ejecución

Cada transformación lleva skip_if_false. El inspector documenta los tres casos en su lugar: un valor vacío salta el paso, una expresión booleana lo salta cuando es falsa, cualquier otra cosa lo ejecuta.

Vale la pena saber

Cada tipo de nodo lleva los gotchas que cuestan tiempo real de depuración:

las entradas de select pasan por F.expr, así que los nombres de columna raros necesitan backticks
union empareja por posición a menos que allow_missing_columns esté activo
group_by.agg recibe expresiones SQL completas con aliases, nunca un mapa
merge necesita una restricción de unicidad en las merge keys
collect dispara una action en el driver, así que va después de un checkpoint

Viven junto al campo al que aplican, que es donde son útiles.

Saltar desde una issue

Las issues en el panel — y el badge en un nodo — enlazan directo al campo que las causó. Studio abre las secciones colapsadas y desplaza el control a la vista, así que un resultado de lint queda a un clic de la corrección.