Skip to main content
tuturuuu.com/download lists iOS/TestFlight and Android/Google Play early access, plus verified desktop packages from GitHub Releases. Every distribution is beta and may not be production-ready. Mobile users may need an invitation using their Apple or Google account; installing TestFlight alone does not grant access.

​
Release workflow

.github/workflows/desktop-beta.yaml runs on relevant production pushes or an explicit dispatch from production. Desktop publication is opt-in: keep the repository variable DESKTOP_BETA_ENABLED unset until signing and platform verification are ready. While disabled, the workflow reports coming soon and does not publish; this is a deferred release, not a successful desktop rollout. Set it to true only after completing the prerequisites below. Set repository variable DESKTOP_BETA_PLATFORMS to a comma-separated subset of windows,macos,linux (default: all three). Selected platforms build concurrently. Linux can ship while another platform completes signing setup. The desktop-beta GitHub environment owns the release configuration. Publication can publish the successfully verified selected-platform subset; failed platforms remain unavailable. Present invalid assets block publication rather than being dropped. Missing certificates never permit unsigned Windows or macOS packages. Build inputs contain only allowlisted public URLs, publishable Supabase keys, OAuth client IDs, and feature flags. DESKTOP_PUBLIC_CONFIG is a JSON environment variable, validated by scripts/desktop-deployment/public-config.mjs. Never use a general .env file or a Supabase service-role key as a Dart define. The validator rejects unknown fields and elevated JWTs without logging their values. Signing credentials are available only to their OS-specific packaging step, after Flutter compilation. They are never passed into Turbo, Flutter, a source archive, or an artifact path. Keep source signing material in the dedicated encrypted Infrastructure desktop vault. Desktop jobs use protected environment secrets by default; the explicit vault opt-in obtains only the matching platform’s approved material through its separate desktop OIDC contract. Never use the mobile bundle endpoint or token for desktop jobs. Certificate issuance, rotation, and identity verification remain prerequisites for a real release.

​
Packages and trust

  • Windows: per-user Inno Setup installer with timestamped Authenticode signatures. The installer registers and removes the browser-login callback protocol.
  • macOS: universal Apple silicon/Intel DMG. The app and image are Developer ID signed, notarized, stapled, and assessed. Temporary keychain/P12/API-key files are removed in finally cleanup.
  • Linux: Ubuntu 24.04+ amd64 .deb, containing the Flutter runtime dependencies and desktop protocol registration. Install through a package manager so system dependencies are resolved. GitHub provenance and checksums cover the package.
audit-bundle.mjs scans the built app before packaging for credential files, private-key/token markers, service-role JWTs, and links escaping the bundle. This is an additional check, not a substitute for keeping secrets out of builds. Signing receipts bind the Windows and macOS verification to the package hash, source SHA, and workflow run. Publication rejects extra files, missing selected platforms, or mismatched receipts. Actions artifacts expire after seven days and are intended for CI inspection. Public downloads use persistent GitHub Release assets, which do not require a repository token in the browser. The workflow attests the packages and verifies each signed attestation against the exact source SHA, protected production ref, desktop workflow identity, and GitHub-hosted runner policy before it uploads a draft desktop-v<version>-<run-id> prerelease, then makes the complete selected-platform prerelease visible. It never marks the desktop beta as the repository’s latest stable release or overwrites an existing release tag. A failed draft needs inspection before rerunning; do not replace assets of a published tag. Draft publication resolves the authenticated gh release view database ID and reads the release by REST ID; the release-by-tag endpoint can return 404 for an existing draft. Before making the prerelease visible, the publisher checks the resolved ID, exact expected tag and source SHA, draft/prerelease flags, and the complete owned asset names, upload states, and SHA-256 digests. A lookup or identity mismatch leaves publication blocked. The actual publisher’s mocked-CLI 404 and mismatch regressions run with node --test scripts/desktop-deployment/publish.test.mjs; no release is written by those tests. The download page caches public release metadata for five minutes and sends package downloads directly to GitHub’s CDN. It validates the exact repository, tag format, filenames, uploaded state, positive sizes, and GitHub SHA-256 digests. Each platform uses its latest verified release independently. Unavailable platforms show an honest unavailable state with a web-app alternative; they never produce guessed download URLs.

​
Verification

Local validation stays limited to non-build checks and is admitted through the resource queue:
Run focused Infrastructure route, operator UI and source TypeScript checks when those surfaces change. Do not run bun check, bun setup, app/package builds, or native release builds locally. Require the applicable app and desktop release builds in CI for the exact source commit. prepare-macos.mjs is runner preparation that rewrites Firebase metadata and copies the selected flavor plist; it is not a read-only verification command. Before publishing, verify installation, browser sign-in callbacks, workspace isolation, resizing, and core app flows on each supported OS. A passing macOS build does not prove Windows/Linux runtime compatibility. Linux CI installs the generated package, waits for a visible first-frame window under Xvfb, and checks that a harmless browser callback activation leaves the app running. This smoke check does not prove authenticated sign-in or interactive Polkit updates. Never label missing platform runtime or signing verification as complete. The separate mobile-build-windows.yaml development check runs Flutter setup without an Actions cache. If its Windows job remains in Post Setup Flutter after the artifact upload, inspect the exact job and rerun that workflow on the same commit. The post-job cache upload is not evidence that the build failed.

​
Automatic desktop updates

Published desktop builds include DESKTOP_RELEASE_RUN_ID, supplied directly by desktop-beta.yaml. Development builds and mobile store builds do not run the desktop updater. The version and run ID together distinguish successive beta builds without manually changing Release Please versions. On startup and every six hours, the app checks the public GitHub release list and automatically downloads a newer desktop beta for its platform. Downloads use no account session or repository token. Exact repository URLs, prerelease tags, every present platform asset, byte counts, and GitHub SHA-256 digests are required. Redirects are limited to GitHub’s HTTPS asset hosts. Incomplete downloads never become installable, and cached packages are rehashed before use. After verification, older updater-owned release cache directories are pruned; unrelated files are preserved. When ready, a compact banner offers Install and restart or Install on next launch. Next-launch consent applies only to that exact release and can be cancelled. A failed installation clears the saved choice so startup cannot get stuck retrying it. Offline checks and download failures leave the current app usable and retry on the next check.
  • Windows verifies Authenticode on both the running executable and installer, requires matching certificate subjects, waits for the old process to exit, and runs the per-user Inno installer. A successful installation relaunches the app. The helper rechecks the digest and signatures immediately before running.
  • macOS verifies the signed/notarized disk image, validates the replacement app’s signature and matching Apple team, and stages it on the destination volume before exiting. The helper swaps bundles after exit and keeps the previous app in one updater-owned recovery directory. An unwritable installation directory or running directly from a mounted disk image blocks installation while keeping the app open.
  • Linux asks the operating system’s Polkit agent to authorize a packaged, root-owned helper. It stages and verifies the archive in a root-owned directory, then uses apt-get install to resolve dependencies. An unprivileged detached helper waits for the previous process to exit before relaunching /opt/tuturuuu/tuturuuu. The Flutter process never runs as root. A cancelled elevation prompt leaves the current app open. Linux beta installations require Ubuntu 24.04+ amd64, pkexec, and a desktop Polkit agent.
Before enabling publication, exercise installation and at least one subsequent update on each actual supported OS, including cancelled elevation, damaged packages, next-launch consent, and relaunch. Unit tests for the metadata and transport boundary do not establish native installer success.

​
Current provisioning prerequisites

The existing Infrastructure mobile vault supports Android/iOS bundles and binds its OIDC audience to the mobile store workflow. Its App Store distribution P12 is not a macOS Developer ID certificate, and the desktop workflow cannot use that bundle endpoint under the mobile workflow’s identity. Provision the desktop credentials listed above through the separate desktop vault and protected environment-secret or explicit vault workflow path; do not copy a mobile CI token into desktop jobs or weaken that OIDC policy. A Microsoft Store developer account alone does not supply the Authenticode certificate used by this workflow.

​
Windows Store draft channel

desktop-store-draft.yaml is a manual build. Its default production-only mode produces an unsigned MSIX artifact for the reserved Tuturuuu product (9N7B6VC7RR7W), using the exact Partner Center package name and publisher from windows-store-manifest.xml. Microsoft signs packages distributed through the Store. This job does not upload or submit an app for certification. It signs a separate temporary copy with a runner-local certificate, installs it, verifies the package identity and visible first frame, and exercises a harmless browser callback. The unsigned submission artifact is unchanged; the test package and certificate are removed afterward. WACK runs when the kit and an interactive session are present. A missing kit/session writes an explicit submission-blocked report and fails the submission job, preventing MSIX upload. Only an explicit diagnostic-only run may finish with blocked evidence; it never uploads a submission MSIX. When WACK runs, a failed, missing, or non-passing report fails either mode. Inspect the attached validation reports before submission. The prerequisite policy is covered by store-certification-gate.test.mjs; actual PowerShell execution and WACK remain Windows CI gates, not evidence established by source-policy tests on another OS. For pre-promotion diagnostics, dispatch this workflow on main with diagnostics_only=true. The job uses the separate desktop-diagnostics environment, restricted to the main branch and containing only DESKTOP_PUBLIC_CONFIG. Keep desktop-beta restricted to production; do not copy signing secrets into the diagnostics environment. A branch-policy rejection happens before runner allocation and produces no build or certification logs. It runs the same production-channel build, installed-app smoke, and strict certification checks, but uploads only validation evidence. It never uploads the submission MSIX, submits to Partner Center, or publishes a beta. Main without this explicit input and all other branches are skipped. This permits investigation of certification blockers before production sync; a diagnostics run is not evidence that production or Store distribution changed. Store builds omit DESKTOP_RELEASE_RUN_ID: the Store manages their updates, while the direct EXE installer remains a separate certificate-backed channel. The MSIX package version uses major/minor plus the dedicated workflow run number, with a zero revision required by Store submissions; app display versions remain managed by Release Please. The run number must fit the MSIX 16-bit component. Before submission, validate on Windows with Windows App Certification Kit and verify packaged browser sign-in callbacks, media permissions, file selection, installation, and Store upgrades. Complete truthful listing screenshots, privacy and data declarations, age rating, restricted runFullTrust justification, and reviewer access instructions. The current product is a draft and its Store link must not be advertised as an available download until Microsoft approves it.

​
Linux update trust

Linux beta packages trust the protected GitHub release and its asset digest; they do not carry a separate publisher signature. Compromise of that release authority can compromise an accepted Linux update. Polkit asks for installation consent. The root-owned packaged helper copies the selected archive into a private root-owned staging directory, rechecks its digest and package identity there, and installs it with apt so dependencies are resolved. It never installs the user-writable cache path directly. macOS and Windows additionally require OS publisher signatures.

​
Verify downloaded desktop packages

Every platform package has cryptographically signed GitHub provenance. Verify a package before installing it using GitHub CLI and the exact source SHA recorded in that release’s notes:
Use the downloaded .dmg or .exe path to verify those platforms. The workflow runs the same verification before publication and blocks the whole selected release if any signature, artifact digest, or workflow identity fails. Linux’s signed provenance covers the exact Debian archive; it is not an embedded Debian publisher signature and the current Linux updater does not independently verify provenance. Windows and macOS additionally enforce native publisher trust. Do not describe receipt hashes alone as cryptographic signature verification. Windows direct distribution requires a trusted Authenticode certificate. A Microsoft account or Store registration alone is insufficient. Microsoft Artifact Signing is an alternative managed signing provider: it requires an accessible Azure subscription, completed identity validation, and a certificate profile, plus a narrowly scoped CI workload identity. Its non-exportable signing key is not a PFX to retrieve from an account. Keep Windows unavailable until a supported signing provider is configured and CI verifies the actual installer signature.

​
Failed platform builds

Platform builds run independently. If one fails, the publication job may still publish the successful platforms after exact run/source/hash receipts and signed provenance verification. A present but incomplete or invalid package blocks publication; missing failed platforms remain unavailable. Cancelled workflows do not publish. The workflow itself remains failed so the platform problem stays visible. macOS signing failures report only a fixed stage name, such as certificate import, artifact signing, notarization, or Gatekeeper assessment. Private command arguments, stdout and stderr remain suppressed. Check the named provider stage without posting credentials or weakening the signing gates.

​
Infrastructure desktop status

The root workspace’s Infrastructure Desktop deployment page shows public production beta workflow jobs and the latest published artifact for each platform. A checksum or release entry is metadata, not independent signature verification. The explicit provenance step is reported only when that step passed in the shown run; artifacts from earlier runs remain separate. Provider configuration stays unknown because private signing credentials are never queried or exposed. Secure management links open the protected GitHub environment, Apple certificates, Microsoft signing resources, and the existing Microsoft Store submission. Windows Store MSIX drafts use the reserved identity and become Microsoft-signed only after certification. They do not make the direct-download EXE signed or available. Regression coverage: Infrastructure desktop status parser and navigation tests.

​
Windows certification diagnostics

A Store draft validation retains the installed executable’s embedded manifest, process/window DPI awareness, and a compact list of non-passing WACK tests in its validation artifact. Missing manifest-tool output is explicitly unavailable. These receipts help distinguish packaging errors from certification-tool warnings; they do not approve a package. The submission gate still requires an overall WACK PASS, plus the existing runtime and publisher review gates. Do not remove Flutter license notices or required plugin functionality merely to hide an informational test. Microsoft documents optional Desktop Bridge tests as informational, but a required DPI warning still needs investigation. The Windows runner manifest declares both the legacy dpiAware value true/pm and modern dpiAwareness value PerMonitorV2. Microsoft documents both manifest declarations: Windows 10 version 1607 and later uses the modern declaration in preference to the legacy one. This preserves PerMonitorV2 while exposing the compatible legacy fallback to older consumers. A diagnostic report can still return overall WARNING: observed optional tests flagged Flutter’s compressed NOTICES.Z and process-launch references in bundled binaries, while the required DPI test could not process the executable despite its extracted PerMonitorV2 manifest and positive installed-process DPI receipt. These are different findings. The dual declaration is a compatibility change, not proof the certification warning is resolved. Require a fresh exact-source Windows build, extracted manifest/runtime DPI checks, and overall WACK PASS before submission. Preserve licenses and legitimate functionality while investigating; do not convert warnings into passing results.

​
Infrastructure desktop signing contract

The separate Infrastructure desktop contract admits only the direct desktop-beta.yaml workflow on production, in the protected desktop-beta environment, with audience tuturuuu-desktop-deployment. Signature, issuer, subject, source SHA, numeric run/attempt, event and GitHub-hosted runner claims are checked before credentials can be considered. Mobile store jobs, main-based diagnostics, pull requests and unexpected reusable workflows are excluded. Windows admits an Authenticode PFX and its password. macOS admits a Developer ID Application P12, its password and signing identity, Apple team, and a separate notarization P8 with App Store Connect key/issuer identifiers. Profile validation rejects missing, duplicate, extra or other-platform resources. Public Flutter configuration is a separate contract and never belongs in a signing bundle. Linux and Store MSIX do not consume this signing bundle. The desktop contract, encrypted storage, operator UI, protected bundle endpoint, and runner hydration are implemented as separate layers. The existing mobile vault is unchanged, and desktop publication remains opt-in. desktopVaultEnabled requires an explicit true; implemented source does not establish provisioning, certificate validity or signed runtime success. desktop-deployment/contract.test.ts and desktop-deployment/oidc.test.ts cover platform isolation and locally signed JWT rejection. Actual protected-workflow OIDC, certificate identity, installation, WACK and update proof remain required.

​
Private desktop vault storage

Desktop signing storage is additive and separate from the mobile vault. Windows and macOS have independent draft versions and exact resource names; Linux and Store MSIX drafts do not receive desktop signing bundles. Ordinary authenticated and anonymous database roles cannot read encrypted resources, data keys or token hashes. Service-only administration requires an explicit actor who belongs to the root workspace and has manage_desktop_deployment_vault permission. Each resource is encrypted with AES-GCM and authenticated against its desktop version, platform and resource name. A replacement cannot transplant ciphertext between platforms or versions. Draft writes increment the revision and invalidate readiness; active resource values and encrypted data-key identity are immutable. Validation and activation use the expected revision. Complete resource names are a structural prerequisite, not proof of a valid signing certificate: the server’s certificate and platform readiness checks must succeed before it records a clean validation result. CI tokens contain only a stored hash and bind to a single platform and version. The verified desktop OIDC run and attempt reserve a unique fetch lease before decryption. Completion rechecks current admission, token expiry and revocation, and the active version before any bundle may be returned. A delivered or failed lease cannot replay; a lost response requires a new workflow run attempt. Audit records use fixed event names and contain no credential values or exception text. Both platform environments start disabled. Activating a ready version selects immutable signing material; it does not enable delivery. The operator screen, protected bundle endpoint and optional runner hydration are implemented in the sections below. Environment-secret signing remains the default until DESKTOP_SIGNING_SOURCE=vault is explicitly selected and the independent server admission gates are enabled. None of these source layers establishes certificate trust, artifact signing, notarization or installation proof. Regression coverage: desktop-deployment-vault.sql tests permission boundaries, platform separation, revision invalidation, immutable active bytes, replay and revocation; vault-crypto.test.ts tests tamper and identity binding.

​
Portable certificate readiness

Desktop vault readiness inspects the uploaded PKCS#12 material for one matching private key and certificate, a current validity interval and an explicit code-signing extended key usage. macOS additionally requires the Developer ID Application extension, an exact configured common-name signing identity and a matching team identifier. The notarization key must parse as a PKCS#8 EC P-256 private key. Rejections return fixed codes; passwords, private key bytes and parser errors are never part of a readiness response. Successful responses contain only a certificate fingerprint, expiry and algorithm. These are portable material checks, not operating-system trust-chain or revocation verification, Apple account access, notarization or artifact-signing proof. The protected per-platform signing and verification workflow remains required before publishing a downloadable artifact. The current PKCS#12 parser supports RSA certificate bags; unsupported key/certificate material fails closed instead of being described as ready. Forge documents its PKCS#12 parser and unsupported-key behavior, and Apple documents the Developer ID Application certificate extension. Regression coverage: certificate-readiness.test.ts uses freshly generated synthetic material for key mismatch, missing keys, duplicate matches, validity, code-signing, Developer ID identity/team and notarization-key boundaries.

​
Private desktop administration API

Infrastructure’s desktop administration API requires an authenticated registered satellite actor, explicit root workspace MEMBER membership and the dedicated manage_desktop_deployment_vault permission. Browser mutations additionally require the exact local origin and desktop action header. JSON and multipart uploads enforce actual streamed byte limits, including chunked uploads. Responses expose version/revision/readiness metadata, configured resource names and token identifiers only. Password suffixes, encrypted resources, data keys, plaintext hashes and token hashes are excluded. A newly issued token is returned once to its authorized creator and is never included in state reads. Draft edits use expected revisions and invalidate readiness. Activation repeats time-sensitive portable certificate checks before the atomic revision-fenced activation RPC. Windows and macOS resource names cannot cross platforms. No version operation enables a platform environment. Bundle delivery is independently default-off; the operator UI and protected workflow hydration are implemented separately. These endpoints alone do not establish signed delivery. Regression coverage: desktop access.test.ts, request.test.ts, store.test.ts and mutations.test.ts.

​
Private desktop operator panel

Root workspace members can continue viewing public desktop deployment metadata. Only the verified Infrastructure satellite actor with explicit MEMBER membership and desktop vault permission sees signing administration. The desktop page uses that actor for permission checks; personal and non-root redirects are preserved. Windows and macOS drafts use empty replacement inputs and configured-name status without saved-value readback. Activation requires current revision readiness and still repeats certificate checks on the server. Operators can explicitly change platform admission with the audited controls described below; the UI never changes the global delivery gate. Newly issued seven-day tokens are masked, shown once, discarded on dismissal or actor/page lifetime changes, and cannot be recovered from state. A definitive permission denial hides retained metadata; revision conflicts reload current state while retaining the operator’s replacement input for retry. The client uses shared Internal API functions and actor-scoped TanStack Query keys. This administration surface does not establish provider provisioning, OS trust, WACK, signing, notarization or protected hydration success. Regression coverage: page-access.test.ts and desktop-vault-client.test.tsx. Private operator writes pass no credential variables into the shared TanStack mutation cache and return no signing token as mutation data. The actor-local operation publishes safe metadata and the one-time token separately; completion and unmount clear the operation reference, and cache errors retain only a fixed status/message. Cache regressions cover pending scalar/file writes, dismissal, conflicts, logout and delayed old-actor completion.

​
Protected desktop signing bundle

Infrastructure exposes a separate machine-only POST /api/v1/desktop-deployment/bundle for Windows and macOS. DESKTOP_DEPLOYMENT_VAULT_ENABLED defaults off and the private platform environment must independently be enabled. Operator activation selects an immutable version; it never changes either admission switch. Metadata distinguishes the global switch from platform admission as two independent badges on each platform, including when only one is enabled, without exposing an enabling control. The operator regression covers all four switch combinations. JSON requests may include media-type parameters such as application/json; charset=utf-8; unrelated media types are rejected before verification or service access. The endpoint verifies the signed fixed desktop GitHub OIDC contract before token lookup or service-client access. A hashed token binds platform and active version; the private reserve RPC binds the verified run, attempt and source SHA. Exact resource names, encrypted identities, fresh portable certificate/P8 readiness and a final live revocation/expiry/version check precede response. Failed or delivered leases cannot be reused, including after a response is lost; a new workflow attempt is required. Signing buffers are wiped on success and failure. This endpoint supplies the optional runner hydrator described below. It does not enable any environment, provision credentials, establish OS trust or prove artifact signing/notarization. Linux and Store MSIX diagnostics do not fetch this bundle. Mobile trust remains independent. Regression coverage lives in the desktop bundle-store.test.ts, bundle route tests and operator admission-badge cases; previous actual lease SQL and signed OIDC tests remain the storage and signature boundaries.

​
Infrastructure vault runner opt-in

Desktop beta signing uses the existing environment secrets by default. An operator can explicitly select DESKTOP_SIGNING_SOURCE=vault as a repository variable and configure separate DESKTOP_WINDOWS_VAULT_CI_TOKEN and DESKTOP_MACOS_VAULT_CI_TOKEN environment secrets. This selects the protected Infrastructure bundle endpoint only for the matching production desktop-beta job after Flutter compilation. It does not enable the server vault or either platform; all existing server admission gates still apply. A rejected or unavailable bundle blocks that platform without falling back to legacy credentials. Linux packaging and Store MSIX diagnostics never request this bundle. The runner imports the same pure signing profile allowlist as Infrastructure, checks schema, platform, resource names, canonical base64, SHA-256 and byte bounds, and passes only matching material to a short-lived signing child. No credential is written to GITHUB_ENV, outputs, public build configuration, or artifact paths. Wire-valid resources must also fit a conservative 30,000-byte whole-child environment budget; oversized certificates/scalars block before signing rather than claiming the 2 MiB storage limit is an OS environment guarantee. Private signer files use a separate owned directory (0700 on macOS; inherited ACLs removed and runner-principal access granted on Windows) while public artifact paths remain unchanged. Normal completion and failures remove that directory. Cancellation force-stops only the still-owned signing process tree before cleanup; POSIX uses one immediate process-group kill, avoiding a delayed kill after the parent exits. JavaScript strings and abrupt runner termination cannot promise memory erasure; the hosted runner lifecycle remains the final boundary. Child output is suppressed and only fixed failure messages are emitted. Bundle requests are not retried because lease consumption deliberately binds one run attempt. Regression coverage: scripts/desktop-deployment/vault-hydrator.test.mjs verifies exact projection/hash/stream bounds, protected runner admission, fixed destination, secret-free child environment, private-directory cleanup and post-compile opt-in. These tests do not prove Windows ACL behavior, real GitHub OIDC, signing trust, notarization, or protected production configuration. The workflow’s actual Node 24 and operating-system jobs remain required delivery evidence. See the Node TypeScript runtime and Windows ACL command contract.

​
Audited platform admission control

The Infrastructure desktop administration API accepts enable_delivery and disable_delivery for Windows and macOS. Both require same-origin operator mutation admission, explicit root MEMBER membership, the desktop vault permission, and the current environmentRevision. Enabling also names the active version and its validated revision; the server decrypts and verifies the exact profile, fresh certificate validity, and macOS P8 material before issuing its short-lived internal receipt. Browser credentials or readiness receipts cannot authorize enabling. Disabling needs no credential inspection, so unavailable or expired material does not prevent an operator from stopping delivery. Version activation still does not enable a platform. No operation changes DESKTOP_DEPLOYMENT_VAULT_ENABLED, which remains an independent global default-off gate. Each successful platform control writes an actor audit event and advances the environment revision. Bundle reservation captures that revision; final delivery rejects older reservations after disable, re-enable, or active-version changes. Pre-migration leases with revision -1 cannot deliver. The existing token, environment, then lease lock order remains intact. During additive-schema rollout, metadata reports a missing revision as null; clients must reload a real revision before offering a control. Source availability does not establish activation, OS trust, signing, provisioning, or publication proof. Server-page fixtures mock the current getDesktopPageAccess boundary and return its admitted actor and management permission. Do not mock a superseded root guard or suppress server-only globally to make page tests import. page.test.tsx covers access-before-metadata ordering and member-versus-manager controls; page-access.test.ts independently covers the real satellite actor, root membership and permission checks. Regression coverage: desktop-deployment-admission.sql exercises permission, CAS, freshness, disable/re-enable and legacy-lease denial; admission.test.ts and request.test.ts cover credential-free disable, trusted receipts, fresh material, sanitized failures, and strict browser inputs. The operator panel offers a confirmation before enabling platform admission. It requires the environment’s real revision and matching validated active version; missing rollout metadata, stale actor refreshes, or an in-flight mutation disable controls. Disable remains available without active credentials and while the global gate is off. Both controls use the actor-local mutation boundary, reload on revision conflicts, and discard late results after actor changes. A changed environment revision or active version dismisses an old confirmation. The independent gate badges remain visible for all four global/platform combinations. desktop-vault-client.test.tsx exercises real QueryClient confirmation, CAS, credential-free disable, concurrent dispatch, and actor-ABA publication.

​
Private macOS signing failure diagnostics

The macOS signer captures child output privately. Failed codesign commands publish only an allowlisted category, artifact kind and bounded numeric exit status, alongside the fixed signing stage. Categories cover keychain access, identity availability, certificate trust, unsigned components, bundle format, resource metadata and timestamp availability; unmatched output is unknown. Paths, signing identities, command arguments, raw output and private inputs never become public error details. This classification preserves failure, cleanup, strict signature/team verification and required notarization gates. It improves next-run diagnosis without establishing or repairing the original signing cause. Regression coverage includes real failing child processes, private-output suppression and failure cleanup in sign-macos.test.mjs, plus the finite classification contract in codesign-diagnostic.test.mjs.