Tracking Issue: deliver a secure PowerContext desktop control center

[Teingi]

Feature description

Define a secure PowerContext desktop control center for personal and team-connected use.

The desktop application should make installation status, local Server lifecycle, Agent integration health, Projects/Workstreams, Handoff inbox, Review, Sources/connectors, context assets, and diagnostics accessible without turning PowerContext into a chat client, IDE, Agent runtime, or multi-Agent orchestrator.

Problem and proposed solution

The web console is growing into a management UI (#1341), while #1383 and the accepted local-service design cover running the Server without a terminal. A desktop product still has distinct responsibilities:

• discover and connect to the local per-user service;
• provide tray/menu-bar status and bounded notifications;
• coordinate release-bound installation and updates from Tracking Issue: manifest-driven installation outside the runtime CLI #1406;
• use OS-native file selection and credential storage;
• surface Handoff delivery, Review, connector, readiness, and recovery events;
• support an authenticated remote Server without exposing tokens to untrusted web content.

The RFC should decide whether the product is a thin native shell around shared web-console modules, a fully native client, or another architecture. Domain operations must continue to use the public Server API; the desktop app must not open the database or reimplement Runtime behavior.

Proposed v1 journey

1. Install PowerContext and the desktop application from immutable release artifacts.
2. Connect to or install the local per-user Server service.
3. Select maintained Agent integrations and inspect their actual capability/health state.
4. Store or import one context item and verify recall status.
5. Receive one Handoff delivery or Review notification and open the exact item.
6. Inspect readiness, recent content-free failures, data location, and recovery guidance.

The first implementation should qualify one desktop operating system end to end before claiming cross-platform support.

Acceptance criteria

• The desktop app uses the public HTTP/API contract and produces the same authorization decisions as CLI, MCP, and web paths.
• Local service install/status/uninstall is delegated to the accepted service-install layer rather than a second supervisor.
• Secrets are stored through the OS credential facility or an explicitly secured fallback; they are never embedded in URLs, logs, crash reports, notifications, or exported settings.
• Remote TLS, certificate, authentication, expiration, and reconnect failures remain distinct and actionable.
• Notifications contain bounded metadata only and do not reveal Memory, Source, Handoff, Prompt, or PreparedContext bodies on the lock screen.
• One supported OS passes install, first run, upgrade, reconnect, offline, Handoff/Review notification, and uninstall acceptance.
• Packaged artifacts are versioned, checksummed, and verified through the release manifest; update rollback and ownership are defined.
• Accessibility, English/Chinese localization, keyboard navigation, and basic small-window behavior are covered.
• Closing the UI does not silently stop a separately installed service or lose pending durable work.

Alternatives considered

• Open the web Dashboard automatically: useful, but does not provide native lifecycle, notifications, keychain, update, or remote-connection behavior.
• Bundle a private database and Runtime into the UI process: duplicates the Server role and makes recovery and multi-client access harder.
• Build a full Agent/chat/IDE application: outside PowerContext's context-runtime boundary.
• Claim Windows/macOS/Linux support from a framework build: packaging is not qualification; each platform needs real install and lifecycle acceptance.

Additional context

Related: #1341, #1383, #1406, #1357, #1395, and #1358.

• I am willing to contribute code, docs, or design feedback.

[knqiufan]

I can follow up on this issue. I'll start by drafting an RFC. My initial idea is to have a shared web management interface + Tauri/Rust system layer + an independent Python server. The Rust part will handle desktop system capabilities, while the existing Python backend will continue to be responsible for Memory, Handoff, retrieval, review, and data storage, among others. The RFC will also compare the selection between Tauri and Electron, clarify the initial scope and target operating systems, and include sections on authentication, notifications, installation, updates, and acceptance criteria.