Tracking: deliver personal local Server setup and management in Desktop #2114

Goal

Deliver a complete personal setup path on the first-wave required targets: Windows 11 x64 and macOS Apple Silicon/Intel. A user with network access can install Desktop, prepare a local PowerContext Server without manually installing Python/uv/Git/compiler tools, register/start a personal background service, and complete the first Memory workflow.

Parent and release coordination: #2099. Product decisions: #1899. Architecture direction: RFC #1733, with existing personal-service semantics from RFC #1299 and applicable Desktop boundaries from RFC #1455.

Platform delivery policy

Windows and macOS are release gates. Linux work #2110 / #2111 is owner-driven, optional, and tracked under #1428; its absence does not block this tracker or the Windows/macOS release. Shared interfaces should permit later Linux use without requiring its adapter or qualification to land first. Never advertise an unqualified Linux package as supported.

Sub-issues and review units

• feat(installer): bootstrap a managed local PowerContext runtime #2115 — Managed runtime bootstrap. PR 10-A defines installation resources, plans and recovery records; PR 10-B implements verified environment preparation, install and repair.
• feat(ops): expose structured personal Server lifecycle operations #2116 — Structured service operations. PR 11-A exposes independent noninteractive lifecycle operations; PR 11-B integrates the constrained Desktop native bridge and recovery behavior.
• feat(desktop): guide local Server setup and lifecycle management #2117 — Local setup and management UI. PR 12-A delivers first-run setup; PR 12-B handles interrupted/failed/existing installations; PR 12-C provides subsequent local service management.

Related delivery ownership

• build(desktop): publish Desktop and local runtime installation artifacts #2112 builds/publishes installation resources and Desktop artifacts; feat(installer): bootstrap a managed local PowerContext runtime #2115 consumes resources and prepares the user's machine.
• build(desktop): deliver signed Windows preview packages #2108 and build(desktop): qualify signed and notarized macOS packages #2109 own Windows/macOS package integration, helper signing, and real clean-machine/login/reboot/repair acceptance.
• feat(desktop): integrate Server discovery and operation compatibility #2101 establishes compatibility and identity from actual setup outputs; feat(desktop): complete the connection-to-Scope journey #2103 owns saved/existing-Server connection behavior.
• feat(desktop): establish the shared application layout and navigation #2102 supplies the shared shell and Settings & help location; feat(desktop): guide local Server setup and lifecycle management #2117 owns the local setup and management content.
• feat(desktop): visualize health and processing observations #2105 remains read-only observation and links to management; feat(desktop): complete Memory save, search, and exact-read journeys #2104 verifies the first Memory journey.
• Reuse existing service ownership, locking and stop/recovery semantics from Tracking Issue: local Server availability and service installation #1298 and the current service implementation. Tracking Issue: manifest-driven installation outside the runtime CLI #1406 is closed; use RFC docs(rfc): define usability and agent workflows #1733 for installation/operations direction rather than depending on completion of that retired plan.

Dependencies and execution

Agree on the bootstrap, operation and result contracts first, including existing-installation ownership and resource/version identities. Runtime preparation, service operations, the UI shell, and platform packaging can then proceed against concrete interfaces. UI completion does not require the whole broader Client/daemon or Agent-installation roadmap.

Installation/maintenance tools run independently of the Server. Bootstrap cannot require an already installed system Python. The Server may run in a managed Python environment prepared by the installer; Windows must receive an appropriate pythonw.exe. Reuse or extract the existing service contract rather than creating competing Rust and Python lifecycle semantics.

The accepted setup plan authorizes its required environment changes and readiness probe. Passive page refresh and ordinary Memory actions must not silently perform model/dependency probes.

Acceptance criteria

• Clean standard-user Windows 11 x64 and both named macOS architectures complete local setup with no preinstalled development/runtime tools and no terminal questionnaire.
• The first page offers local setup and existing-Server connection. The existing/remote path never installs or changes a local Server implicitly.
• Use a fixed compatible runtime, SQLite and the user data directory. Basic save/FTS/exact-read requires no model; resolve the Server's default Scope through public operations instead of asking for raw IDs.
• Align local defaults with RFC docs(rfc): define usability and agent workflows #1733: loopback-only personal mode, no manually transferred token, and Dashboard configuration consistent with that mode. Preserve existing user choices and remote authentication. Reconcile the older RFC docs(rfc): propose Tauri desktop control center #1455 default-auth wording in the owning implementation/docs before shipping.
• Plans show resources, locations, service/autostart effects and ownership. Apply revalidates the approved plan; progress reports configuration, registration, process state, readiness and usability separately.
• Download/setup interruption and Desktop termination have durable, inspectable recovery states. Do not claim installation continues after Quit unless the chosen producer actually supports it.
• The OS manages the persistent Server independently of Desktop. Verify explicit stop, restart, login/reboot and no duplicate registration/process; do not adopt unknown listeners.
• Service management remains usable with the Server stopped. A damaged runtime does not prevent independent inspection and supported cleanup/repair of owned registrations.
• Program, configuration and user data lifecycles are separate. Removing Desktop, stopping/removing a service and deleting data are distinct choices; existing data is preserved by default.
• Final Windows/macOS signed/notarized artifacts and pinned installation resources are exercised together. Record package/source/Server/platform identities, ownership, procedure and results.

Non-goals

Automatic Agent installation, a new Client daemon, automatic updates, arbitrary old-database migration/downgrade, universal offline bundles, system/root services, LAN exposure by default, and Linux as a first-wave prerequisite. A blocked existing database requires the supported maintenance workflow, not repeated restart or destructive reinstall.

References

Product scope, RFC #1733, RFC #1299, RFC #1455. Static prototypes establish presentation only, not installation behavior.