Qué genera build.rs, y dónde mirarlo

Los tres artefactos

El manifiesto, y cómo se lee

Está en el directorio de compilación, en la parte generada del paquete. No hay una ruta bonita que memorizar; se encuentra buscando por nombre:

cd src-taurifind target -name '*acl-manifests*' -o -name 'capabilities.json' 2>/dev/null | head

Lo que contiene, y es lo que ninguna otra fuente tiene junto:

• Los conjuntos expandidos. core:default aparece como los permisos concretos que agrupa.
• Las capabilities sumadas. Si tres ficheros conceden cosas a la ventana principal, aquí están las tres juntas.
• Las negaciones aplicadas. Si un deny gana desde otro sitio, aquí se ve.
• Y el reparto resuelto por ventana y plataforma.

Es decir: es la respuesta a «qué puede invocar de verdad esta ventana», y las tres causas más confusas del nivel 27.5 —solapes, conjuntos y negaciones— se resuelven mirándolo.

No hay que entenderlo entero ni leerlo a menudo. Hay que saber que existe y encontrarlo en un minuto el día que algo no cuadre.

El esquema, que sí se usa a diario

Éste es el que devuelve todos los días. Con la primera línea de un fichero de capability apuntando a él —nivel 28.1— el editor:

• Autocompleta los identificadores de permiso que existen de verdad, incluidos los de los plugins que tengas instalados y los tuyos.
• Subraya un identificador que no existe, antes de compilar.
• Explica cada permiso al pasar por encima, con la descripción que el plugin —o tú— escribisteis.

Ese último punto es lo que hace que la descripción del nivel 29.2 valga la pena: no es documentación que nadie lee, es lo que aparece en el editor mientras se escribe.

Y el esquema es por plataforma. Hay uno de escritorio y otro de móvil, porque los permisos disponibles no son los mismos. Apuntar al que corresponde es lo que hace que el editor no ofrezca permisos que no existen en tu destino.

El orden de generación

Un detalle que explica un desconcierto frecuente:

Es el argumento a favor de versionar el esquema: un clon nuevo tiene autocompletado desde el primer minuto. El argumento en contra es el ruido en el diff cada vez que un plugin cambia sus permisos, que es poco frecuente.

Cuándo se regenera

Automáticamente, porque build.rs declara sus dependencias de fichero —nivel 6.3, paso 4—. Cambiar un fichero de capability, un permiso propio o la lista del manifiesto provoca una recompilación, y con ella la regeneración de los tres artefactos.

Eso explica el comportamiento del nivel 5.3: tocar un JSON de permisos recompila Rust. Y explica también que no haga falta ningún paso manual: no hay un comando de «regenerar permisos» porque no hace falta.