Por qué declarar tus propios comandos

Lo que está concedido hoy

La fila que decide es la segunda: con la vista previa del nivel 28.5, quitarle el conjunto base fue la única forma de que no pudiera invocar nada. Si esa ventana hubiera necesitado invocar un comando tuyo y ninguno más, no habría manera de expresarlo.

Qué cambia al declararlo

Con el manifiesto del nivel 6.3, cada comando pasa a tener su propio permiso:

// build.rsuse tauri_build::{Attributes, AppManifest};fn main() {    tauri_build::try_build(        Attributes::new().app_manifest(            AppManifest::new().commands(&[                "cargar_proyecto",                "guardar_proyecto",                "listar_proyectos",                "sincronizar_catalogo",            ]),        ),    )    .expect("no se pudo construir el manifiesto de la aplicación");}

Y a partir de ahí, una capability tiene que concederlos:

{  "identifier": "principal",  "windows": ["main"],  "permissions": [    "core:default",    "allow-cargar-proyecto",    "allow-guardar-proyecto",    "allow-listar-proyectos"    // sincronizar_catalogo NO está: solo la ventana de sincronización lo necesita  ]}

Cuatro cosas cambian a la vez:

Un comando sin conceder no se puede invocar, aunque exista y esté registrado. Se puede repartir por ventana, igual que los de los plugins. Añadir un comando ya no amplía la superficie por sí solo: hay que concederlo, y eso aparece en el diff. Y la superficie está en un sitio: el directorio de capabilities, sin tener que sumar la lista del manejador aparte.

El coste, que es menor de lo que parece

Tres objeciones habituales y lo que valen:

«Hay que mantener dos listas.» Cierto a medias: la lista de build.rs y la del manejador. Y el desajuste no compila — declarar un comando que no existe rompe la compilación—, así que es un desajuste que dura segundos. La lista contraria —un comando registrado y no declarado— sí es silenciosa, y se caza con la prueba negativa del nivel 28.4.

«Cada comando nuevo son tres sitios.» Registro, declaración y concesión. Es un sitio más que ahora, y ese sitio es precisamente el que hace que ampliar la superficie sea una decisión visible. Es el diseño, no la torpeza — el mismo argumento del nivel 8.3.

«Con veinte comandos es mucha ceremonia.» Los veinte se escriben una vez. Y hay una alternativa intermedia: declarar solo los que importan —los que tocan disco, red, procesos o credenciales— y dejar el resto en bloque. No es tan limpio y recorta la mayor parte del riesgo con una fracción del trabajo.

Los tres casos en que es obligatorio

Por qué casi nadie lo hace

Merece decirlo porque explica el estado de la mayoría de los proyectos: no es el valor por defecto, no falla nada sin ello, y no aparece en las guías de inicio. Un proyecto que nunca lo declara funciona perfectamente y tiene la superficie de sus comandos abierta en bloque sin que nada lo señale.

Es exactamente la asimetría del nivel 26.5 — conceder es fácil y no lo revisa nadie— aplicada al valor por defecto del framework. Y la corrección es la misma: hacerlo cuando el proyecto es pequeño, que es cuando cuesta una tarde en vez de una semana.