Tracking: ship Desktop with local Server setup on Windows and macOS #2099

Goal

Deliver an installable Desktop preview for personal users on Windows 11 x64 and macOS Apple Silicon/Intel, including local Server setup and background management, connection to existing Servers, the core Memory journey, and lightweight observation.

Two supported starting points converge on the same qualified connection and exact Scope:

• Set up locally: install Desktop → review a setup plan → provision the managed runtime and personal Server → register/start it with the OS user-session mechanism → validate and activate the actual connection → resolve the default Scope → save, search, read, and copy a memory.
• Connect an existing Server: save a profile → check and explicitly activate it → select an exact authorized Scope → use the same Memory and observation features.

For the personal default, follow RFC #1733: loopback, user-directory SQLite, no manual token or model setup required for the basic workflow, and usable Dashboard access. Preserve existing explicit configuration. Resolve conflicts with older default-auth assumptions in RFC #1455 in the owning implementation/docs PRs; do not invent an anonymous fallback for arbitrary remote Servers.

Parent: #1428. Product UX: #1899. Local setup: #2114. Existing Windows baseline: #1654.

Required delivery checklist

Shared experience

• feat(desktop): integrate Server discovery and operation compatibility #2101 — Discovery, compatibility, identity isolation, and qualification for existing and provisioned Servers.
• feat(desktop): establish the shared application layout and navigation #2102 — Shared four-entry shell and navigation.
• feat(desktop): complete the connection-to-Scope journey #2103 — Existing connection flow, exact Scope selection, and handoff from local setup.
• feat(desktop): complete Memory save, search, and exact-read journeys #2104 — Save/recovery, bounded full-text search, exact revision read, and copy.

Observation

• Tracking: deliver lightweight observation views in Desktop #2100 — Shared observation semantics and integration.
• feat(desktop): visualize health and processing observations #2105 — Runtime state, explicit readiness, and read-only local service facts.
• feat(desktop): visualize current-Scope inventory and usage #2106 — Current-Scope inventory and usage.
• feat(desktop): summarize session requests and copy safe diagnostics #2107 — Bounded session observations and explicit safe diagnostic copying.

Personal local setup

• Tracking: deliver personal local Server setup and management in Desktop #2114 — Coordinate the complete clean-machine local setup and management outcome.
• feat(installer): bootstrap a managed local PowerContext runtime #2115 — Independent bootstrap, managed runtime, setup plan, and repair.
• feat(ops): expose structured personal Server lifecycle operations #2116 — Structured noninteractive operations and constrained native bridge.
• feat(desktop): guide local Server setup and lifecycle management #2117 — Setup, recovery, and Local Server settings UI.

Required platforms and publication

• build(desktop): deliver signed Windows preview packages #2108 — Signed Windows installer, installed workflows, and Task Scheduler qualification.
• build(desktop): qualify signed and notarized macOS packages #2109 — Signed/notarized macOS packages and LaunchAgent qualification on both architectures.
• build(desktop): publish Desktop and local runtime installation artifacts #2112 — Desktop and runtime resource artifacts, explicit platform gates, and verified release publication.

Each implementation issue defines focused PRs, concrete dependencies, and acceptance. A whole UI redesign or the complete installer is not one PR.

Optional Linux work — not a first-wave release gate

• feat(desktop): implement optional Linux native integration #2110 — Linux native integration, credentials, diagnostics, and user-service adaptation.
• build(desktop): package and qualify the optional Ubuntu Desktop preview #2111 — Ubuntu packaging and actual GNOME Wayland/X11 qualification.

Both are children of #1428, outside this tracker's mandatory closure checklist. A contributor with a Linux machine can own and advance them independently. The Windows/macOS preview can ship and this tracker can close while they remain open.

Unselected or unavailable Linux jobs/artifacts must not block required build aggregation, release-candidate assembly, publication, or first-wave acceptance. Release notes and download pages advertise only qualified, actually published targets. Selecting Linux for a later release requires its own complete evidence; optional priority does not lower its quality bar.

Native parent relationships and ownership

Direct children: #2100, #2101, #2108, #2109, #2112, #2114.

• UI feat(desktop): establish the shared application layout and navigation #2102, feat(desktop): complete the connection-to-Scope journey #2103, feat(desktop): complete Memory save, search, and exact-read journeys #2104 remain children of product issue Tracking Issue: define the Desktop product experience #1899 and required outcomes here.
• Observation feat(desktop): visualize health and processing observations #2105, feat(desktop): visualize current-Scope inventory and usage #2106, feat(desktop): summarize session requests and copy safe diagnostics #2107 are children of Tracking: deliver lightweight observation views in Desktop #2100.
• Local setup feat(installer): bootstrap a managed local PowerContext runtime #2115, feat(ops): expose structured personal Server lifecycle operations #2116, feat(desktop): guide local Server setup and lifecycle management #2117 are children of Tracking: deliver personal local Server setup and management in Desktop #2114.
• Linux feat(desktop): implement optional Linux native integration #2110, build(desktop): package and qualify the optional Ubuntu Desktop preview #2111 are children of long-term roadmap Tracking Issue: deliver a secure PowerContext desktop control center #1428, with optional cross-links here.
• Windows build(desktop): deliver signed Windows preview packages #2108 references feat(desktop): deliver a connect-only preview for existing Servers #1654 for its baseline, while this tracker owns its broader local-setup release scope.

There are 18 issues in this delivery plan: three tracking issues and fifteen implementation issues, of which two Linux implementation issues are optional. Completion does not close the broader #1428, #1899, #1896, or #1980 work.

Dependencies and execution order

1. Agree on Tracking Issue: define the Desktop product experience #1899 UX, feat(desktop): integrate Server discovery and operation compatibility #2101 connection/identity interfaces, and feat(installer): bootstrap a managed local PowerContext runtime #2115/feat(ops): expose structured personal Server lifecycle operations #2116 resource, plan, operation, ownership, and durable-status contracts. Reconcile RFC docs(rfc): define usability and agent workflows #1733 personal defaults with docs(rfc): propose Tauri desktop control center #1455 in those owning PRs.
2. build(desktop): publish Desktop and local runtime installation artifacts #2112 defines resource versions/trust/architecture metadata and produces bootstrap/runtime inputs; feat(installer): bootstrap a managed local PowerContext runtime #2115 consumes them. Platform signing owners join early. Build scaffolding can land before final UI.
3. feat(desktop): establish the shared application layout and navigation #2102 shell, feat(desktop): complete the connection-to-Scope journey #2103 existing-connection flow, feat(desktop): complete Memory save, search, and exact-read journeys #2104 Memory, and observation adapters can proceed alongside bootstrap/Ops work. refactor(desktop): replace the custom OpenAPI-to-Rust schema mapping #1896 is a dependency only for specific generated contracts, not blanket closure.
4. feat(desktop): guide local Server setup and lifecycle management #2117 consumes reviewed Installer/Ops interfaces and hands the actual endpoint/installation identity to feat(desktop): integrate Server discovery and operation compatibility #2101/feat(desktop): complete the connection-to-Scope journey #2103. Resolve the Server-created default Scope through the public API; users do not type raw Scope IDs.
5. Windows/macOS platform owners verify the combined runtime, OS integration, UI, and exact signed artifacts. Reuse applicable feat(desktop): add macOS native preview support #2056 evidence; past connect-only checks do not qualify new setup behavior.
6. Publish through build(desktop): publish Desktop and local runtime installation artifacts #2112 only after required Windows and both macOS architecture outcomes are qualified. Linux progresses separately.

First-wave acceptance

• Name feature, Installer/Ops, platform, and release owners; record supported Desktop/Server/OS/WebView versions and architecture-specific evidence.
• On clean network-connected standard-user Windows/macOS machines without preinstalled Python, uv, Git, or a compiler, users install Desktop and complete local setup without a terminal. Managed Python is allowed; the user must not prepare it.
• The reviewed personal default reaches the default Scope and basic save/full-text search/exact-read/copy without model credentials or manual token/ID entry. Existing Server connections remain a first-class path.
• Installer/Ops entry and status/recovery work independently of a live Server and system Python. Damaged managed-runtime handling provides truthful inspect/stop/remove/repair behavior, not an unreachable HTTP-only recovery screen.
• Setup plans disclose downloads, paths, ownership, config changes, background registration and login behavior. Interrupted/failed/repeated operations use durable status and ownership-aware recovery; uncertain operations are not blindly replayed.
• Windows Task Scheduler and macOS LaunchAgent behavior is exercised through actual login/reboot/reconnect and explicit stop/start, including GUI exit. GUI lifecycle does not supervise the background Server.
• Managed runtime, user config/data, and Desktop app have explicit lifetimes. Desktop exit/removal does not silently remove the Server or data; any service removal is a separate explicit operation. Unowned installations are never silently adopted/overwritten.
• Connection/deployment/Principal/Scope transitions isolate private state and late responses. Submitted writes retain original identity and uncertain-result protections.
• Observation pages retain honest coverage/unknown/error semantics; local status is separate from remote health and session HTTP measurements. Readiness probes are explicit; diagnostic copies are allowlisted and previewed.
• English/Chinese, theme, keyboard/focus, real IME, screen reader, high contrast, small windows and scaling pass required platform checks, including setup/recovery.
• Exact final signed Windows and signed/notarized macOS artifacts, including runtime/helper inputs, pass clean install, upgrade/removal, failure/repair, and integrated acceptance. Record source/version/digests/owner/procedure/results; distinguish real execution from mocks.
• Release manifests, CI dependencies and support claims make Linux optional. Missing Linux does not block required publication. No fixture artifact or unqualified platform is presented as released support.
• Map applicable delivery-plan gates to this scope and retain broader outstanding gates.

Release semantics and non-goals

Building a package, uploading an Actions artifact, and publishing a qualified GitHub Release are separate outcomes. Packaging PR merges do not automatically create public installers through Python release automation; #2112 owns the explicit Desktop release path.

This wave includes personal Server setup and management. It does not require Agent/project-binding setup, Client daemon delivery, automatic Server/Desktop updates, arbitrary database migration, offline installers, full asset/history/Review/Handoff workflows, or complete Dashboard observability parity. Linux is optional.

References

• Product scope and PR plan
• Static existing-connection UI prototype
• RFC docs(rfc): define usability and agent workflows #1733, docs(rfc): define local Server service-installation boundaries #1299, docs(rfc): propose Tauri desktop control center #1455; Desktop delivery plan