Four of these look similar and mean completely different things: no namespaces exist, this namespace declares no keys, your search matched nothing, and you may not see this at all. Rendering one generic "nothing here" for all four is the failure this frame prevents.
Skeleton rows in the table's own column rhythm, so the header does not reflow when definitions land.
| Key | Type | Settable at | Flags | Default |
|---|---|---|---|---|
Nothing has ever registered configuration. This is a setup state, not a failure, and its call to action is documentation, not "retry".
No application has registered a configuration namespace on this platform. Namespaces are declared by an app's manifest, not created by hand in this console.
Distinct from B: the namespace is real, so the fix is with that app, and the screen names it.
It is registered but has published no key definitions. Nothing will appear in the settings editor for this namespace at any scope.
Keys do exist — the filter excluded them. The state must offer to clear the filter, and must never be reachable when the underlying list is genuinely empty (that is B or C).
8 key definitions exist in notifications.
The most important state in this flow. Because the catalog is the only
surface exposing isHidden keys, a partial render here is a disclosure. There is no
"greyed-out table with the rows still in the DOM" — the request is refused and no definition data
reaches the browser at all.
QA asserts on the network response, not on the rendered table: a spec that only checks "no rows visible" passes against a build that fetched every hidden key and hid it with CSS.
Contract. GET /v1/namespaces → PagedNamespaces (state B),
GET /v1/namespaces/{namespace}/keys → PagedKeyDefinitions (states C, D),
FORBIDDEN from ErrorCode (state F). Permit decides; the console reflects.