Dónde vive cada pieza

Los cinco sitios

Por qué ficheros separados

Es la decisión de forma que más devuelve, y el argumento es de proceso y no técnico:

Un cambio de permisos tiene que verse. Si las capabilities viven dentro de la configuración, ampliar la superficie aparece en el diff como cuatro líneas más dentro de un fichero que también contiene el tamaño de la ventana y el nombre del producto. Nadie lo distingue.

Con ficheros propios, git diff capabilities/ es una pregunta con respuesta: qué ha cambiado de lo que la webview puede pedir. Y esa pregunta es exactamente la que la revisión del nivel 33 hace.

Y se pueden repartir. Un fichero por funcionalidad —o por ventana— hace que el nombre del fichero diga a qué corresponde el permiso, sin tener que leer dentro:

capabilities/├── default.json      lo mínimo, para todas las ventanas├── proyectos.json    lo que la ventana principal necesita para trabajar├── ajustes.json      lo poco que la ventana de ajustes necesita└── movil.json        lo específico de las plataformas móviles

Ese reparto no es solo estético: es lo que hace posible el nivel 28.

Las dos excepciones legítimas

El ámbito del protocolo de recursos va en la configuración. Es la excepción que el nivel 27.1 mencionaba. Ese ámbito no acota un comando sino qué puede servir el motor de la webview directamente, así que pertenece a la sección de seguridad de la configuración y no a una capability. Nivel 31.

La política de contenido, igual. No es un permiso de comando: es una directiva que el motor aplica a la página. Y aunque no sea una capability, es parte de la superficie —el cuarto sumando del nivel 26.3— y hay que contarla al auditar.

Qué hace build.rs con todo

Recuerda el nivel 6.3, ahora con el detalle que importa:

El paso 4 merece atención: un identificador de permiso mal escrito no compila. Es una red que ahorra bastante, y es la razón de que no haga falta ejecutar la aplicación para descubrir que un fichero de capabilities tiene una errata.