Goal
Run a LastCode server node from the packaged macOS application without keeping the Electron renderer or GPU processes alive.
The server role must preserve the selected LastCode home, environment identity, pairing, projects, and configured connection behavior. It may share a node with an Intel artifact consumer or GUI/controller, but the public implementation does not assume that topology.
Delivered foundations
- PR #56 makes launchd shutdown strict and waits until the prior job is gone.
- PR #57 prevents two macOS server processes from owning the same LastCode state.
- PR #58 validates and prepares an exact packaged LastCode server runtime without activating it.
- PR #114 and PR #115 provide hosted Intel artifact publication independently of deployment activation.
Current boundary
LastCode ships a cross-platform headless serve command and a per-user macOS LaunchAgent foundation. The generic pinned-service installer still needs a LastCode-only artifact source before it is safe as LastCode's native installer, and packaged-runtime preparation is not yet wired into native activation.
A LaunchAgent is login-scoped: it starts after user login and stops at logout. It is not a boot daemon. Concrete service installation, update cadence, role placement, connection endpoints, and rollout state belong to deployment-owned infrastructure.
Phase 1: reversible packaged-server bridge
Install a user LaunchAgent that starts the packaged LastCode server against a selected LastCode home. Use modern launchctl bootstrap and bootout, a service label distinct from the desktop bundle ID, RunAtLoad, KeepAlive, explicit logs, and loopback binding.
Do not use the generic pinned-runtime installer until its artifact source is verifiably LastCode rather than upstream t3.
Phase 2: native LastCode support
Finish integrating the packaged LastCode runtime with the native service command:
- make the pinned runtime source product-aware;
- validate both Intel and Apple Silicon packaged-server nodes;
- preserve state and configured connection behavior through update and rollback; and
- migrate any deployment-owned bridge before native activation without allowing two servers to own one LastCode home.
Acceptance criteria
- Closing a GUI/controller on another or the same node does not stop the packaged server.
- No Electron renderer or GPU process remains.
- The service uses the selected LastCode state, identity, pairing, and projects.
- Starting the graphical app cannot create a second backend against the same state.
RunAtLoad, KeepAlive, lifecycle commands, logs, provider discovery, and login-scoped limitations are documented and tested.- Native install/update validates the immutable packaged runtime before stopping the current service.
- Failed activation restores the prior working service and database state.
- End-to-end acceptance covers Intel and Apple Silicon server nodes.
- Public code and documentation remain topology-neutral; deployment schedules, endpoints, and host assignments stay in private infrastructure.
Goal
Run a LastCode server node from the packaged macOS application without keeping the Electron renderer or GPU processes alive.
The server role must preserve the selected LastCode home, environment identity, pairing, projects, and configured connection behavior. It may share a node with an Intel artifact consumer or GUI/controller, but the public implementation does not assume that topology.
Delivered foundations
Current boundary
LastCode ships a cross-platform headless
servecommand and a per-user macOS LaunchAgent foundation. The generic pinned-service installer still needs a LastCode-only artifact source before it is safe as LastCode's native installer, and packaged-runtime preparation is not yet wired into native activation.A LaunchAgent is login-scoped: it starts after user login and stops at logout. It is not a boot daemon. Concrete service installation, update cadence, role placement, connection endpoints, and rollout state belong to deployment-owned infrastructure.
Phase 1: reversible packaged-server bridge
Install a user LaunchAgent that starts the packaged LastCode server against a selected LastCode home. Use modern
launchctl bootstrapandbootout, a service label distinct from the desktop bundle ID,RunAtLoad,KeepAlive, explicit logs, and loopback binding.Do not use the generic pinned-runtime installer until its artifact source is verifiably LastCode rather than upstream
t3.Phase 2: native LastCode support
Finish integrating the packaged LastCode runtime with the native
servicecommand:Acceptance criteria
RunAtLoad,KeepAlive, lifecycle commands, logs, provider discovery, and login-scoped limitations are documented and tested.