Quality Gates
Tauri quality gates must prove three things: the web UI works, the native authority boundary is safe, and the release artifact behaves on the target platform.
Required Gates
| Gate | Proof |
|---|---|
| Frontend static build | Build output path matches build.frontendDist |
| Rust tests | cargo test covers command validation and backend logic |
| IPC tests | Frontend wrapper tests use mocked IPC and assert command names/payloads |
| Capability review | Every permission, scope, window label, remote URL, and asset scope is justified |
| CSP review | CSP allows only the protocols and origins the app actually needs |
| Sidecar review | Binary names, target triples, permissions, args, logs, cleanup, and update path are documented |
| Release build | tauri build created the artifact for the current OS |
| Release smoke | Installed/launched artifact passed a clean-machine or clean-profile smoke test |
| Signing state | OS code signing and updater signing are explicit |
| WebView2 state | Windows install mode and runtime assumption are recorded |
| Mobile state | Android/iOS support is either tested or explicitly out of scope |
Security Review Prompts
Which windows/webviews receive this capability?
Does any window belong to multiple capabilities that merge authority?
Which commands can touch files, shell, network, localhost, or secrets?
Which plugin permissions include scopes or argument validators?
Can untrusted webview input reach a sidecar argument?
Can remote content access Tauri APIs?
Does CSP allow dev-only localhost, unsafe eval, broad HTTPS, or asset wildcards in release?Release Review Prompts
Which OS produced the artifact?
Which OS and architecture ran the artifact?
Was it unsigned, ad-hoc signed, developer signed, notarized, or Store-signed?
Does the updater private key exist only in an approved secret store?
What happens if the updater private key is lost?
How does Windows get WebView2 on a clean machine?
What exact artifact is safe to share with users?Mobile Review Prompts
Which plugins are used on mobile?
Does each plugin document Android support, iOS support, both, or neither?
Which Kotlin or Swift bridge code is required?
Which permissions are requested at runtime?
Was the app tested on emulator, simulator, or physical device?
Does store policy allow the native behavior?Done Means Evidence
| Claim | Minimum evidence |
|---|---|
| Secure command added | Rust validation tests plus capability diff review |
| Sidecar added | Release build includes target-triple binary and tests cover args/output/cleanup |
| Updater enabled | Signed update artifact, reachable endpoint, install test, relaunch test |
| Windows-ready | Installer smoke plus WebView2 install-mode note |
| Mobile-ready | Platform build plus plugin support and device/emulator smoke |
| Store-ready | Store-specific signing, policy, package, and dashboard evidence |
Warning: A dev-server run is not a release gate. It does not prove bundling, signing, sidecars, updater artifacts, WebView2 installation, or platform-specific config overrides.