I1004 — Availability and visibility are metadata, not conditions in a template
Model where a capability is available — always, only in a static build, only with a running backend, only when authenticated, only at build time — and whether it is public or internal, so that every surface derives its behaviour from that rather than from its own conditionals.
DONE wave 1 · p0 · implementation profile · parallel safe
Objective
Model where a capability is available — always, only in a static build, only with a running backend, only when authenticated, only at build time — and whether it is public or internal, so that every surface derives its behaviour from that rather than from its own conditionals.
Why
The published site and the running server are genuinely different environments. Without this metadata every template grows its own idea of what works where, and the site ends up offering a link to something no server is behind.
Current state
The Cockpit is served by the running process. The site is generated. Nothing states which capability means anything in which environment.
Desired state
Availability and visibility are fields of the model, every projection reads them, and no template decides for itself.
Scope
- apps/majordomus-cli/src/capability/model.rs
Out of scope
- Any decision made from a hostname, a URL or a build-time flag inside a template
- An internal capability being silently invisible without saying it is internal
Dependencies
What waits on this
- I1005DONE The graph is a generated artifact with a schema and no unsafe field
- I1009READY Every menu in this repository comes from one derivation
- I1015ACTIVE A surface with no server behind it is not offered as if it had one
Acceptance criteria
- Availability distinguishes at least what is always true, what requires the running backend, what is a build-time snapshot and what requires authentication
- Visibility distinguishes public and developer-facing capabilities from ones deliberately marked internal
- Every existing capability, route and surface is classified, and an unclassified one is a validation failure rather than a default
- No projection decides availability from anything other than this metadata
Validation
- cargo test --workspace --all-features
- majordomus generate --check
Evidence required
- availability_modelled
- no_template_conditions
Evidence
| covers | type | command | result | at commit |
|---|---|---|---|---|
| availability_modelled | test | cargo test --test availability and cargo test --lib capability::model (apps/majordomus-cli) | Availability draws four environments apart — always, runtime, build_time, authenticated — and Visibility three — public, developer, internal; every capability of the built registry carries both, equal to the classification of what it declares, and the registry refuses one that disagrees; the fields reach docs/generated/openapi.json, docs/generated/registry.json and site/data/registry/registry.json through generate, so a projection reads a field | 5e297b1 |
| no_template_conditions | test | cargo test --test availability no_projection_decides_availability_from_where_it_is_served | no line under apps/majordomus-cli/src or share/cockpit/src reads the serving address and compares it; the check reads lines rather than files, because its first run flagged a documentation URL in about.rs, which is a link and not a verdict | 5e297b1 |
Risk
A default of always-available makes the model useless and the classification invisible. Absence has to be a failure.
Timeline
- started
- 2026-09-06T16:22:51Z
- verified
- —
- completed
- 2026-09-06T16:54:53Z
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/I1004.yaml. Read it back with majordomus plan show I1004.