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
Scope. Slice 6 of Managed Fleet (#283 — read it first). "Enable Fleet Server" / "Disable Fleet Server": the canonical server as a product-managed system service — vendored binary installed to a stable per-user path, a launchd user unit (start at login, loopback-only bind), fleet token minted at 0600, health probe to finish. Disable tears down cleanly. Extension upgrade swaps the stable-path binary, restarts the service, and re-probes — the version-skew choreography the product owns. HITL: this mutates login items on user machines, so a human reviews before merge.
Acceptance Criteria
After enable, the canonical server is up headless — it starts at login with no editor running — serving the identity route with role canonical.
The unit's exec path is the stable install path (never a versioned extension directory), and an extension upgrade leaves the service running the new binary, healthy, without panel intervention on the server machine.
Disable stops and unloads the unit and returns the machine to standalone with chat working locally.
Enable is atomic: any failure (binary install, token mint, unit load, health probe) rolls back to the previous state with the reason surfaced.
Testing Decisions
Unit tests for the installer steps (templated unit file, atomic write + mode assertions for the token, rollback ordering) with a fake launchd/systemd boundary; a scripted integration check on a sacrificial machine (the author's Mac mini is the first customer) for headless boot + upgrade choreography, run by the human reviewer — the HITL gate.
Key Decisions & Constraints
The service is per-user (launchd gui domain / systemd user unit), never a system daemon; no root anywhere.
Binary install is copy-to-stable-path, so an extension uninstall never strands a running service on a missing binary.
systemd support is designed for (unit template abstraction) but built only when a Linux server appears (parent Scope).
Parent constraints apply; slice-local: the service binds loopback only, enforced by construction and re-asserted by the health probe.
Source
Part of #283 · Design: docs/adr/0005-managed-fleet.md (PR #282) · Blocked by #285 (the server-mode panel attaches via slice 2's path).
Important
Scope. Slice 6 of Managed Fleet (#283 — read it first). "Enable Fleet Server" / "Disable Fleet Server": the canonical server as a product-managed system service — vendored binary installed to a stable per-user path, a launchd user unit (start at login, loopback-only bind), fleet token minted at
0600, health probe to finish. Disable tears down cleanly. Extension upgrade swaps the stable-path binary, restarts the service, and re-probes — the version-skew choreography the product owns. HITL: this mutates login items on user machines, so a human reviews before merge.Acceptance Criteria
canonical.standalonewith chat working locally.Testing Decisions
Unit tests for the installer steps (templated unit file, atomic write + mode assertions for the token, rollback ordering) with a fake launchd/systemd boundary; a scripted integration check on a sacrificial machine (the author's Mac mini is the first customer) for headless boot + upgrade choreography, run by the human reviewer — the HITL gate.
Key Decisions & Constraints
Source
Part of #283 · Design:
docs/adr/0005-managed-fleet.md(PR #282) · Blocked by #285 (the server-mode panel attaches via slice 2's path).