I1015 — A surface with no server behind it is not offered as if it had one

Make the exposure of backend-only surfaces — the API console, live status, runtime reads — follow from availability metadata, and prove both projections behave correctly.

DONE wave 2 · p0 · implementation profile · parallel safe

Part of capability-graph — One capability graph, two projections, and no second inventory of what this repository can do.

Objective

Make the exposure of backend-only surfaces — the API console, live status, runtime reads — follow from availability metadata, and prove both projections behave correctly.

Why

The published site has no server. A link to a runtime console on it is a broken promise, and the usual fix is a check on the page's own address, which is a rule hidden where nobody will find it.

Current state

web::Availability is ServedOnly, PublishedOnly or Both and ProjectionRoute::linkable() answers from it alone. The running-server side is exercised by test/cases/89_web_surface.sh and apps/majordomus-cli/tests/projections.rs. The static side, missing when this was measured on 2026-09-10, is check 18 of scripts/site-check: it reads every route the projection declares served-only from the generated OpenAPI, refuses a published page that links one, and requires each to be named on /docs/api/ as needing a server. The site job runs it on every build. Measured on master b4a781c668, 2026-10-07.

Desired state

Exposure follows from availability metadata alone, and there is a test for each projection that keeps it that way.

Scope

apps/majordomus-cli/src/http/swagger.rs

Out of scope

Any decision made from a hostname, an address or a build flag inside a page
Rendering a dead destination as if it were live

Dependencies

I1004DONE Availability and visibility are metadata, not conditions in a template

What waits on this

Acceptance criteria

A backend-only surface is offered as usable only where a backend is available, decided from metadata
The static build contains no active link to a runtime-only surface
Where mentioning an unavailable surface is useful, it is shown as unavailable rather than omitted silently or linked
Both cases are tested — the static build and a running server with the API present

Validation

bash test/run.sh
scripts/cockpit-probe

Evidence required

availability_drives_exposure
both_projections_tested

Evidence

covers	type	command	result	at commit
availability_drives_exposure	ci	scripts/site-check (check 18), site job of the validate run on master	OK surface: every served-only route is named on /docs/api/ and linked from nowhere: /api/v1 /swagger /mcp /events /cockpit; site-check: 0 failure(s), at b4a781c668	b4a781c
both_projections_tested	ci	bash test/run.sh 89_web_surface (suite-shard 2) and scripts/site-check (site job), validate run on master	ok 89_web_surface for the running server; OK surface for the static build; both at b4a781c668 in one run	b4a781c

Risk

This is the check that quietly rots, because a broken link on a published page fails nothing. The test for it has to run on every build.

Timeline

started: 2026-09-06T17:35:07Z
verified: 2026-10-07T13:30:01Z
completed: 2026-10-07T13:30:04Z

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/I1015.yaml. Read it back with majordomus plan show I1015.