A snapshot: read at commit 707a04c7ce8 on 2026-10-18T00:06:01Z by majordomus 0.29.0. Nothing on this page is read again. See it live
I2157
Ready means ready: a lost lease, a degraded layer or a failing mesh is not reported ready
Where it stands
devtask.issue- Readiness
- complete completion is recorded and every required evidence token is present
- Status
- DONE
- Can start
- not now
- Milestone
- Milestone status
- ACTIVE
- Wave
0- Waiting on
- none
- Holds back
- Behind it in all
1- Evidence
2of2
Moves
plan.transitionWhat it is
- Objective
- Fold lease loss and a degraded index into readiness with a named reason, add a mesh check to health.report, and make majordomus doctor report the runtime or say that it does not.
- Why
- Readiness (apps/majordomus-cli/src/capability/builtin/health.rs:214, GET /api/v1/ready) checks a non-empty registry and that the code is not replaced; a degraded index stays ready:true with layer: warn, and mesh state and lease loss are absent: was_lost() reaches only GET / through LEASEHOLDER_KEY (apps/majordomus-cli/src/http/router.rs:710). health.report (apps/majordomus-cli/src/capability/builtin/health.rs:299) has no mesh and no policy-allowed dimension; mesh health lives only in mesh.status, mesh doctor and mesh verify. Running, ready, mesh-healthy and degraded are split across /live, /ready, server.standing_at (apps/majordomus-cli/src/capability/builtin/server.rs:403), MeshStatus, index::State::Degraded (apps/majordomus-cli/src/index.rs:34) and LinkState::Degraded (apps/majordomus-cli/src/mesh/cooperation.rs:265). The top-level majordomus doctor is a governance doctor (lib/doctor.sh:53-77) that checks nothing about the server, the lease or the mesh, which its name suggests it does. Baseline audit of 2026-10-09 at master 1fb8d6be44, failure gap 10 and premise 4.
- Now
- A server that lost its lease, or serves a degraded index, answers /api/v1/ready with ready true.
- Wanted
- GET /api/v1/ready answers ready false after a lease loss, with reasons naming lease_lost (and stale, as before); a degraded layer is listed as layer_degraded and stays ready, which docs/MCP.md says; health.report carries a mesh check that applies mesh doctor's runtime verdict (doctor::runtime_verdict) in a process whose server decided the mesh, and reports unknown elsewhere. The deferred part, majordomus doctor reporting the runtime or saying that it checks governance only, is I2707.
- Done when
- unknown: the record declares no `completion`
- Risk
- unknown: the record declares no `risk`
Acceptance
- A server that lost its lease answers /api/v1/ready with ready false and the reason lease_lost
- A degraded index is reported on /api/v1/ready with its reason, and docs/MCP.md says whether that is ready
- health.report carries a mesh check whose status follows mesh doctor's verdict when the mesh is enabled
- Validation
bin/majordomus plan validatecargo test --test health_server --test lease_lost- Evidence required
ready_false_on_lease_loss_testhealth_mesh_check_test- Evidence present
ready_false_on_lease_loss_testhealth_mesh_check_test
Scope
- Touches
apps/majordomus-cli/src/capability/builtin/health.rsapps/majordomus-cli/src/http/router.rsapps/majordomus-cli/src/lease.rsapps/majordomus-cli/src/mesh/doctor.rslib/doctor.shapps/majordomus-cli/tests/health_server.rsdocs/MCP.md- Not
- unknown: the record declares no `non_scope`
- Depends on
- none
- Priority
- p1
- Profile
- implementation
- Parallel safe
- false
- Owner
- unknown: the record declares no `owner`
The work so far
- Branches
- none
- Merged
- none
- Commits
0- Trunk
- master
- Sessions
- none
- Created
- 2026-10-09
- Updated
- 2026-10-14T12:16:39Z
- Started
- 2026-10-14T12:15:59Z
- Verified
- unknown: the record declares no `verified_at`
- Completed
- 2026-10-14T12:16:39Z
Synchronisation
- Adapter
scripts/github-sync- Repository
- unknown: the derived plan's header carries no repository
- External issue
- unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it
- State there
- unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it
Findings
Nothing is wrong with these records.