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
I1502
A server serving code that no longer exists stops calling itself 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
- none
- Behind it in all
0- Evidence
2of2
Moves
plan.transitionWhat it is
- Objective
- Make a running server's own root and health documents carry the identity of the code it is serving, so that a stale server is detectable by the client reading it rather than only by an outside reader holding a newer executable.
- Why
- F1 of the audit's failure table, and the audit names it the single most dangerous class it found, because every measurement anyone takes through such a server is quietly wrong — including measurements of what a development surface lacks. It was measured from both sides in one sitting: `serve status` in a fresh executable reported the primary checkout's server as outdated, with the reason that the executable it was started from has been replaced since, while the same server asked directly at /api/v1/server returned HTTP 200 and standing `ready`, with peers attached to it throughout. The asymmetry is structural: the lease reader in a fresh executable can tell, and the running server's own root document carries no identity to check against.
- Now
- Four of the five servers running during the audit were outdated. A server reports `ready` from its own endpoint regardless of whether its executable still exists on disk, and its root document carries no HEAD, no build identity and no executable fingerprint for a reader to compare. This is the ghost-server class: a server that answers is not a server that is current.
- Wanted
- A client that reads a server's own documents can decide whether that server is current, without holding a second executable. A stale server says so where it is asked, in the same place it says it is ready.
- Done when
- unknown: the record declares no `completion`
- Risk
- Low in mechanism, high in value. The risk worth naming is the opposite one: a check that flags a current server as stale would make every worker ignore the signal, which is worse than not having it.
Acceptance
- A server whose executable has been replaced reports that fact on the endpoint a client asks for its standing
- The check is answerable by a client holding no second executable
- A current server is not reported stale, proved by a fresh start
- Validation
bin/majordomus-cli serve statusbash test/run.sh- Evidence required
stale_server_says_socurrent_server_is_not_flagged- Evidence present
stale_server_says_socurrent_server_is_not_flagged
Scope
- Touches
apps/majordomus-cli/src/serverapps/majordomus-cli/src/capability/builtin/server.rsapps/majordomus-cli/src/capability/builtin/health.rsdocs/COCKPIT.mdtest/cases- Not
Reaping the server register. The fleet listing enumerates every checkout it has ever seen, including long-gone scratch trees under /private/tmp, and nothing reaps it; that is a separate finding and not this issue.Killing or restarting another checkout's server. Several live sessions share this machine.- Depends on
- none
- Priority
- p0
- Profile
- implementation
- Parallel safe
- true
- Owner
- unknown: the record declares no `owner`
The work so far
- Branches
- none
- Merged
- none
- Commits
0- Trunk
- master
- Sessions
- none
- Created
- 2026-09-11
- Updated
- 2026-10-08T10:34:20Z
- Started
- 2026-10-08T10:33:49Z
- Verified
- 2026-10-08T10:34:14Z
- Completed
- 2026-10-08T10:34:20Z
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.