I2722 — A hub activates a new version under its service manager, checks its health and rolls back by itself

✕BLOCKED wave 1 · p0 · implementation profile · runs alone

Part of safe-self-update — Every mesh node follows the published release by itself, versions meet safely, and a release's provenance can be checked.

Objective

Make a hub that has installed a newer release restart onto it through its systemd user unit or launchd agent when no session is attached or after a bounded grace, pass a readiness and mesh verify check, and otherwise rename the launcher back, keep serving the previous version and put a rollout failed entry on the board.

Why

ADR 0161. Hubs run unattended (docs/MESH.md, The hubs as services); the launchd agent is the operator's to install and an installer that writes either unit is owed as a typed capability (ADR 0059).

Current state

Updating a hub is a fetch, a build and a service restart by hand; the macOS hub is started by hand.

Desired state

A typed capability writes the hub's systemd user unit or launchd agent from the mesh declaration; after self update installs a newer version the hub restarts onto it under the rules above; the previous versioned tree is kept until the health check passes; a failed version is not retried on that node until a newer one is published.

Scope

• apps/majordomus-cli/src/mesh
• apps/majordomus-cli/src/capability/builtin
• apps/majordomus-cli/src/lease.rs
• share/install
• docs/MESH.md
• test/cases

Out of scope

• Checkout servers' hand-off, which I2163 and I2127 carry

Dependencies

• I2720○READY majordomus self update re-runs the published installer, and never reimplements it

What waits on this

• I3178✕BLOCKED A self update killed at any stage leaves a usable installation
• I3195✕BLOCKED The lundra hub is a declared deployment target served over its tailnet name, and a second device reaches it

Acceptance criteria

• A hub with a newer installed version ends serving it, with no session lost that was attached before the grace
• A version whose readiness or mesh verify fails is rolled back within the grace and the board names node, version and failed check
• The hub service unit is written by a capability, not by hand

Validation

• bin/majordomus plan validate
• MJ_TEST_JOBS=4 bash test/run.sh <the case this issue adds>

Evidence required

• hub_activates_new_version_test
• hub_rolls_back_failed_version_test

Evidence

None recorded. Every token above needs a command or an artifact behind it before this issue can be completed; narrative is refused.

Timeline

started

—

verified

—

completed

—

Those three fields, the evidence above and the state of the dependencies are all the status is made of. There is no status field to disagree with them.

Canonical record: .ai/repo/project/issues/I2722.yaml. Read it back with majordomus plan show I2722.