the-runtime-supervises-itself — The runtime says what is progressing, waiting or stalled, and repairs only what is safe

One read capability classifies the runtime's work; a bounded repair loop acts only through ensure, recovery, leases and the reaper.

BLOCKED 0 of 2 issues done

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

Problem

The owner asked on 2026-10-17 for a background watchdog that keeps the mesh running, drains tasks and leaves no zombies. The primitives exist one by one (heartbeats, leases, serve ensure, health.report, monitor.stream, scripts/reap-orphans, recover orphans) but nothing composes them into one judgement of what is stuck. Proposed in ADR 0199 (A hub is a declared host service; a working checkout's server stays a client's child); ADR 0200 (Supervision repairs only what is idempotent, owned and verified, and never restarts blindly) (proposed; it carries no authority until the owner accepts it). Sources: chatgpt-majordomus:c288#13.

Outcome

One read capability classifies the runtime's work; a bounded repair loop acts only through ensure, recovery, leases and the reaper.

Current state

Verified on master 707a04c: mesh heartbeat 5 s / expiry 30 s (docs/MESH.md), server.idle_seconds 900 (.ai/repo/policy.yaml), health.report, monitor, scripts/reap-orphans, scripts/liveness-check, majordomus recover orphans; no capability classifies stalled versus waiting.

Desired state

supervision.status (read-only) on every surface; supervision repair under ADR 'supervision repairs only what is idempotent'; OS units only for declared hubs.

Scope

apps/majordomus-cli/src/capability/builtin/health.rs
apps/majordomus-cli/src/capability/builtin/monitor.rs
apps/majordomus-cli/src/lease.rs
scripts/reap-orphans
docs/MONITOR.md

Out of scope

Service units for hubs: I2722
Restarting live sessions or retrying merges
Remote execution on a peer

Acceptance criteria

A stalled execution and a session legitimately waiting for CI are told apart by one read
A repair loop never kills a process it does not own
A repeated repair failure escalates on the board instead of looping

Validation

majordomus plan validate

Risks

A repair that races a peer's own recovery: every action asks ownership again before it acts
Collides with ADR 0003 if it grows into a daemon; it runs inside the existing server

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
I3182	BLOCKED	0	—	One read says which work is progressing, waiting, stalled, failed or orphaned, and on what evidence
I3183	BLOCKED	1	I3182	A safe repair runs once per cause through ensure, recovery, leases and the reaper, and a repeated failure escalates

The graph

the-runtime-supervises-itself dependency graphfrom .ai/repo/project

flowchart LR
    I3182["I3182<br/>One read says which work is progressing, waiting, stalled, failed or orphaned, and on what evidence"]:::blocked
    I3183["I3183<br/>A safe repair runs once per cause through ensure, recovery, leases and the reaper, and a repeated failure escalates"]:::blocked
    I3182 --> I3183
    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-runtime-supervises-itself.yaml. Read it back with majordomus plan show the-runtime-supervises-itself.