You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Runtime Host already provides the remote execution, authentication, reconnect, multi-Host Desktop, Host-scoped Settings, and remote Project foundations tracked by #2522. Desktop can now prepare a supported Linux computer through interactive SSH, install an exact Maka CLI release, pair the Client, verify the connection, and continue to remote Project selection.
The managed lifecycle now covers per-Host service inspection and repair, credential maintenance, safe exact-package manual updates, and equivalent Linux systemd and macOS LaunchAgent backends. The remaining work is safe update discovery, unattended policy reconciliation, and the Desktop update-policy surface.
Desired outcome
Desktop should provide one coherent per-computer lifecycle: guided onboarding, service health and repair, credential maintenance, safe updates, and explicit removal or uninstall actions with clear ownership boundaries.
The same management contract must remain usable from CLI and TUI, and must preserve identical update semantics across the Linux and macOS service backends.
Stable boundaries
SSH is the management plane for installation, service control, updates, credentials, and diagnostics. Runtime Host remains the only Session and execution data plane.
The OS service manager owns the persistent process. Runtime Host never overwrites or updates its own executable.
Foreground management actions are explicit, idempotent transactions with durable recovery boundaries. Periodic desired-state reconciliation is reserved for later unattended update policy, where continuous convergence has a concrete product need.
Deployed versions are always exact. Channel names only resolve a desired exact version.
Update policy defaults to manual. Automatic updates must wait for a safe maintenance point and respect storage compatibility.
Credential secrets are delivered once and stored only by the Client credential store. Management UI exposes metadata, rotation, and revocation rather than secrets.
Removing a Desktop profile, uninstalling the remote service, and deleting the State Root are three separate operations.
The default SSH path uses the system OpenSSH client and a loopback Runtime Host listener. Maka does not modify the user's SSH config or implement a second SSH stack.
Delivery plan
Platform-neutral service lifecycle contract and Linux systemd user backend: install, status, start, stop, restart, readiness verification, and clean uninstall while retaining the State Root (feat(cli): manage Linux Runtime Host services #3205)
Each slice should remain independently useful. Update automation must not block initial onboarding, and Desktop UI must not duplicate service or credential authority.
Definition of done
A user can prepare a supported Linux remote computer from Desktop without manually copying a port, Root ID, or credential
Password, host-key, passphrase, and MFA prompts can be completed through the existing bounded interactive SSH surface
Setup is retryable and does not leave duplicate services, profiles, or credentials
Desktop saves a Profile only after the service and authenticated Runtime Host connection have been verified
Users can distinguish removing the computer from Desktop, uninstalling Maka-managed service files, and explicitly deleting all Host data
Manual and automatic updates never silently cross an unsupported storage compatibility boundary
CLI and TUI can use the same machine-readable management contract without adopting Desktop's multi-Host UI
Linux and macOS backends share lifecycle semantics rather than separate product state machines
Non-goals
A federated Runtime Host or cross-Host Session migration
A custom SSH implementation, silent sudo, or automatic installation of Node.js
Opening the Runtime Host listener to the public network by default
Treating uninstall as permission to delete the State Root
A Windows persistent-service backend without a concrete product requirement
A cloud pairing or rendezvous service before local SSH onboarding proves insufficient
简体中文
问题
#2522 已经完成 Runtime Host 的远程执行、认证、重连、Desktop Multi-Host、Host-scoped Settings 与远程 Project 等基础能力。Desktop 现在也可以通过交互式 SSH 准备受支持的 Linux 电脑,安装精确的 Maka CLI release、配对 Client、验证连接,并继续选择远程 Project。
English
Problem
Runtime Host already provides the remote execution, authentication, reconnect, multi-Host Desktop, Host-scoped Settings, and remote Project foundations tracked by #2522. Desktop can now prepare a supported Linux computer through interactive SSH, install an exact Maka CLI release, pair the Client, verify the connection, and continue to remote Project selection.
The managed lifecycle now covers per-Host service inspection and repair, credential maintenance, safe exact-package manual updates, and equivalent Linux systemd and macOS LaunchAgent backends. The remaining work is safe update discovery, unattended policy reconciliation, and the Desktop update-policy surface.
Desired outcome
Desktop should provide one coherent per-computer lifecycle: guided onboarding, service health and repair, credential maintenance, safe updates, and explicit removal or uninstall actions with clear ownership boundaries.
The same management contract must remain usable from CLI and TUI, and must preserve identical update semantics across the Linux and macOS service backends.
Stable boundaries
Delivery plan
manual | fixed | latest | nextpolicy with bounded one-shot reconciliation and Linux/macOS schedulingEach slice should remain independently useful. Update automation must not block initial onboarding, and Desktop UI must not duplicate service or credential authority.
Definition of done
Non-goals
sudo, or automatic installation of Node.js简体中文
问题
#2522 已经完成 Runtime Host 的远程执行、认证、重连、Desktop Multi-Host、Host-scoped Settings 与远程 Project 等基础能力。Desktop 现在也可以通过交互式 SSH 准备受支持的 Linux 电脑,安装精确的 Maka CLI release、配对 Client、验证连接,并继续选择远程 Project。
托管生命周期现已覆盖 per-Host 服务检查与修复、credential 维护、面向精确 package 的安全手动更新,以及语义一致的 Linux systemd 与 macOS LaunchAgent backend。剩余工作是安全更新发现、无人值守策略 reconcile 与 Desktop 更新策略界面。
期望结果
Desktop 应提供一套连贯的 per-computer 生命周期:引导式 onboarding、服务健康与修复、credential 维护、安全更新,以及所有权边界清晰的移除或卸载操作。
同一套管理契约仍须可供 CLI 与 TUI 使用,并在 Linux 与 macOS service backend 上保持一致的更新语义。
稳定边界
交付计划
manual | fixed | latest | next策略、有界的一次性 reconcile 与 Linux/macOS scheduler每个 slice 都应能够独立提供价值。自动更新不能阻塞首次 onboarding,Desktop UI 也不能复制 service 或 credential authority。
完成标准
非目标
sudo,或自动安装 Node.js