I1031 — A served surface says which checkout it is serving
Make every surface a process serves name the repository it is serving — its root and its identity — so that a reader can tell at a glance whether the answers in front of them come from the tree they are working in.
READY wave 0 · p1 · implementation profile · parallel safe
Ready. Every dependency is done, so majordomus plan start I1031 will be accepted.
Objective
Make every surface a process serves name the repository it is serving — its root and its identity — so that a reader can tell at a glance whether the answers in front of them come from the tree they are working in.
Why
This cost a real hour. A browser held a Swagger page from a server that had exited, its requests failed with a message blaming CORS, and the live server on another port turned out to be serving a scratchpad worktree of a different session entirely — so even the document being read was that other tree's, including a sentence about the routes that this tree had already corrected. Nothing on the page said which checkout answered it. Several sessions share one machine and each may bind its own server; a surface that does not name its tree invites exactly this conclusion, that the tool is broken, when the tool is fine and the address is wrong.
Current state
The home page lists the surfaces, the version and a repository identifier, and `/api/v1/repository` will name the root if asked. The Swagger shell and the served document name neither. A stale page fails with a transport error that names CORS before it names a closed socket.
Desired state
Every served surface carries the repository root and identity it is answering for, close enough to the content that a reader sees it without asking for it.
Scope
- apps/majordomus-cli/src/http/router.rs
Out of scope
- Publishing an absolute developer path to anything but a loopback surface
- A second identity beside the one the repository model already holds
- Changing what any surface serves; this changes only what it says about itself
Dependencies
None. This issue is a root of the graph.
Acceptance criteria
- The home page names the repository root and identity the process is serving, not only the surfaces it exposes
- The interactive API shell names the same root, so a page fetched from one server cannot be mistaken for another's
- The identity comes from the repository model rather than from a second inspection
- No surface names the repository's location on the host: the identity says which checkout answered, never where it sits, and a test proves no served or published output carries an absolute path
- The behaviour is exercised by a test that serves two roots and proves each surface names its own
Validation
- cargo test --workspace --all-features
- bash test/run.sh
Evidence required
- identity_on_surfaces
- published_carries_no_path
Evidence
None recorded. Every token above needs a command or an artifact behind it before this issue can be completed; narrative is refused.
Risk
The obvious fix — printing the root — is the one to refuse: it would leak the host's directory layout to whoever can reach the socket, and the incident is solved by saying which checkout answered, not where it lives.
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/I1031.yaml. Read it back with majordomus plan show I1031.