the-host-knows-its-runtimes — A host knows every Majordomus runtime it runs, with no project open

A read-only host inventory first, derived from the leases every checkout already writes; a routing answer second. A hub's service is the declared deployment target of the-hub-is-reached-from-any-device, and no host-level resident is built.

BLOCKED 0 of 2 issues done

ready: 0
blocked: 2
active: 0
verify: 0
done: 0
cancelled: 0

Problem

On 2026-10-12 the owner asked for a tiny host-level service that coordinates several Majordomus versions on one machine, keeps the mesh healthy and self-updates. Every server today is one checkout's (ADR 0035); nothing answers for the host, and two versions on one machine are found only by knowing their checkouts. Proposed in ADR 0199 (A hub is a declared host service; a working checkout's server stays a client's child) (proposed; it carries no authority until the owner accepts it). Sources: chatgpt-majordomus:c240#0, chatgpt-majordomus:c240#2, chatgpt-majordomus:c240#5.

Outcome

Current state

Verified: per-repository server listing exists (majordomus server); leases live under each checkout's .ai/local/state; README and ADR 0003 say Majordomus is not a daemon; hubs nevertheless run as a systemd user unit on lundra (docs/MESH.md 'The hubs as services').

Desired state

majordomus runtimes (host scope) answers with no checkout open; side-by-side versions are routed by negotiated capability; a resident exists only by decision.

Scope

apps/majordomus-cli/src/capability/builtin/server.rs
apps/majordomus-cli/src/lease.rs
apps/majordomus-cli/src/mesh/identity.rs
docs/MCP.md

Out of scope

A second discovery, registry or update system (ADR 0050, ADR 0161)
NAT and relays: mesh-connectivity
Packaging as brew services

Acceptance criteria

Host inventory needs no running daemon
Two versions on one host are both listed and an incompatible request is refused with a typed reason

Validation

majordomus plan validate

Risks

Scope creep the 10-07 audit warned about: every slice must be vertically complete and small

Issues

Each one is an execution contract with its own acceptance criteria, validation command and required evidence. The wave column is the layer of the dependency graph it sits in.

issue	status	wave	depends on	title
I3184	BLOCKED	0	—	One command lists every Majordomus runtime of this user on this host, with no checkout open
I3185	BLOCKED	2	I3184, I3177	A request on a host with two Majordomus versions reaches the one whose protocol satisfies it, or is refused with a reason

The graph

the-host-knows-its-runtimes dependency graphfrom .ai/repo/project

flowchart LR
    I3184["I3184<br/>One command lists every Majordomus runtime of this user on this host, with no checkout open"]:::blocked
    I3185["I3185<br/>A request on a host with two Majordomus versions reaches the one whose protocol satisfies it, or is refused with a reason"]:::blocked
    I3184 --> I3185
    classDef done stroke:#16a34a,fill:#dcfce7,color:#14532d,stroke-width:2px
    classDef active stroke:#2563eb,fill:#eff6ff,color:#1e3a8a,stroke-width:2px
    classDef verify stroke:#7c3aed,fill:#f5f3ff,color:#4c1d95,stroke-width:2px
    classDef ready stroke:#0891b2,fill:#ecfeff,color:#164e63,stroke-width:2px
    classDef planned stroke:#0891b2,fill:#ecfeff,color:#164e63,stroke-width:2px
    classDef blocked stroke:#b45309,fill:#fffbeb,color:#78350f,stroke-width:2px
    classDef cancelled stroke:#6b7280,fill:#f9fafb,color:#374151,stroke-width:2px
    classDef superseded stroke:#6b7280,fill:#f9fafb,color:#374151,stroke-width:2px

Linked from this diagram (2)

Canonical record: .ai/repo/project/milestones/the-host-knows-its-runtimes.yaml. Read it back with majordomus plan show the-host-knows-its-runtimes.