app.personalos-desktop

PersonalOS Desktop

Tauri 2 shell for PersonalOS on macOS, Windows, and Linux. It composes the canonical Personal Calm design pack, golden journey, privacy center, and offline authority policy with typed goal, productivity, household, and health read models. Household invitation, activation, delegation, and revocation use the same browser-safe runtime constructor as web and mobile; desktop supplies exact native identity, revision, human evidence, timestamp, and opaque IDs.

Safety boundaries

• Only low-risk commands with an explicit undo command may queue offline.
• Consent, sharing, health connection, delegation, rights, deletion, and authority changes require online revalidation.
• Credentials are stored through the operating-system keychain. They are never placed in SQLite or browser storage.
• Local projections are AES-256-GCM encrypted in Rust with subject, projection, and revision-bound additional authenticated data. The encryption key is held by the operating-system keychain.
• Tauri grants only event listen/unlisten and current deep-link reads. There is no shell, process, filesystem, clipboard, arbitrary HTTP, SQL, menu, tray, image, or window-command permission.

The CSP permits inline style attributes because the shared design-system theme runtime applies audited CSS variables through React. Scripts remain self-only with no unsafe-inline or unsafe-eval, and production network access is limited to Tauri IPC.

Runtime composition

The app exports DesktopPersonalOsApp, DesktopPersonalOsApiClient, and bootstrapNativeDesktopHost so the native AuthOS product host can bind an exact subject and provision an OS-keychain credential reference. Credential acquisition is native_authos_only: the webview port can check or remove a reference but cannot receive or store a raw bearer. The canonical client validates server experience/workspace projections, sends full domain commands with their exact idempotency key, and never exposes the bearer token to the webview. Tauri permits only the projection, workspace, domain-command, and exact health-authorization API paths over a compile-time HTTPS origin; localhost HTTP is debug-only.

The clickable Personal Calm journey starts on the next incomplete golden step, uses an accessible design-system action and provider picker, and submits canonical shared-schema commands for household creation, mission and goals, Today planning, habits, check-ins, missed-day recovery, weekly review, coach proposal/activation/inspection/undo/reset, limited household support, and export/deletion. Remote wellbeing connections use the server authorization broker and expose only its validated HTTPS authorization URL; missing and unknown providers are rejected before that broker is contacted. Coach commands derive coach and adaptation revisions from the authenticated workspace instead of trusting hidden or caller-provided values. Per-action drafts survive denial and revision conflicts for recovery. The goals view renders minimized outcome baselines, targets, latest confidence, and correction/removal counts. Its record, correct, and remove actions submit the exact shared metric commands online; corrections reuse the current observation identity and retain prior values in encrypted server state. The privacy view renders the same minimized consent dashboard with localized purpose and downstream-consumer labels, expiry, and lifecycle status. Evidence, receipt identifiers, and subject metadata remain outside the desktop cache. Its action panel can grant the fixed one-year PersonalOS planning scope and revoke only a currently active consent. Both actions remain high-risk, human-required, online-only commands and are never written to the desktop offline queue.

The wellbeing view consumes the shared minimized category summaries: localized category and status, observation/quarantine counts, and an optional latest source-observation timestamp. Raw measurements, provider payloads, credentials, and clinical conclusions never enter the desktop workspace model. The same view renders the optional bounded wellbeing-goal window with localized safe metric, lifecycle, direction, dates, observation count, and uncertain outcome. It states that observations do not establish cause or medical advice; raw targets, values, evidence, and provider fields never enter the local model.

Goal-scoped support is distinct from household membership: the subject selects an active propose_support delegation, current goal, consent, and purpose before the shell constructs the canonical scope digest. Grant, revoke, block, and categorical report commands are high-risk, human-required, online-only actions; the desktop never queues them or widens their proposal-only fields and actions.

The desktop consumes the server-issued PersonalOS presentation projection rather than resolving local roles or preferences. Display-only areas remain usable when legacy projections omit presentation metadata, but every governed mutation then fails closed. When a projection is present, denied areas and referenced components suppress their data, hidden actions disappear, blocked actions are disabled, and approval-required actions remain explicit requests to server authority. Preference and explanation rendering is presentation-only; its local reset preview is reversible and cannot alter action authority.

Low-risk reconnect work is stored as a complete canonical domain command in an AES-GCM sealed v2 outbox. Replay decrypts and revalidates its subject, registry classification, payload digest, expected server revision, and idempotency key, then submits to /v1/domain-commands for fresh server authority. A 202 response is the only acknowledgement. Denial, confirmation, scope, and revision failures remain durably blocked for recovery; authentication/network/service failures remain pending without data loss. The native host shares one encrypted queue between command submission and workspace reads. A browser online event invokes the reconnect port, which replays and revalidates that queue before refreshing the canonical projection; initial load never dispatches queued effects, and concurrent reconnect notifications coalesce into one replay/refresh operation.

The standalone entry loads native-only AuthOS session metadata and verifies its keychain credential reference before composing the canonical workspace and journey ports. Missing, expired, or invalid native identity fails closed; the app never invents a demo identity or silently falls back to local authority. The React host owns one shared Personalization identity boundary and refreshes native AuthOS session metadata when the window regains focus. Exact account, actor, opaque tenant, consent, or sign-out changes discard retiring buffers before the new projection is accepted; loading, reconnect, and retryable errors preserve the current scope. Collection cannot attach without granted consent.

The updater seam is also fail-closed. DesktopUpdatePort reports not_configured until release engineering injects a signed update feed and its public verification key. A local Vite or Cargo build is not signed-installer, store-review, real-device, accessibility-certification, or update-feed evidence.

Commands

bun run --cwd packages/apps/personalos-desktop lint:check
bun run --cwd packages/apps/personalos-desktop clean
bun run --cwd packages/apps/personalos-desktop typecheck
bun run --cwd packages/apps/personalos-desktop test
bun run --cwd packages/apps/personalos-desktop build
bun run --cwd packages/apps/personalos-desktop pack:check
cargo fmt --manifest-path packages/apps/personalos-desktop/src-tauri/Cargo.toml -- --check
cargo check --manifest-path packages/apps/personalos-desktop/src-tauri/Cargo.toml
cargo test --manifest-path packages/apps/personalos-desktop/src-tauri/Cargo.toml