Who owns this, what may I do, and where are its docs
The three questions that are not about running code — ownership, permissions and documentation — and where each is answered honestly.
What may I do
Permissions are answered once per request and shown, rather than discovered by pressing a button and reading an error.
Every capability, per environment, with the role binding behind it.
What your token may do →Environments are ranked rather than listed: review environments rank below staging, staging below production, and an environment nobody has ranked ranks production-high on purpose. The failure mode of guessing low is somebody getting a shell in a place nobody decided they should have one, arriving silently on the day the environment is created.
There is a difference between "you may not" and "we could not ask", and it took a while to get right. Failing closed is correct; saying the platform does not permit this when the authorization service was never reached is not. A control whose verdict could not be obtained answers 503, not 403.
Who owns it
Ownership, lifecycle, links and metadata, read from the portal rather than kept a second time here.
The catalog →Deliberately read from the portal: two catalogues disagreeing about who owns a service is worse than one catalogue that is occasionally stale.
Where its documentation is
Every component, and whether it has any.
Component documentation →
This is assembled at request time from two halves:
- The facts — live from the platform: what it is, what type, where it runs, what it depends on, what built it.
- The prose — fetched from the application's own repository, in order:
docs/<component>.md, thendocs/index.md, thendocs/README.md, thenREADME.md.
The page says which candidate it used and lists the ones it tried, so "this component has no documentation" is a fact about the repository rather than a mystery.
It reports a documented/total count as a backlog figure, not a score. The point of naming the number is that somebody can move it.
This replaced a static generator that built per-entity sites on a schedule. The reported symptom was "tech docs are either missing for most projects or broken", and the reason was structural: a static snapshot of a live system is wrong from the moment it is built.
The guides themselves
The pages you are reading ship inside the console image, not fetched from a repository. They document this console's own routes, so they should version with the code that provides them — a guide describing a page this build does not have is worse than no guide.
There is a test that resolves every link in every guide against the router, so a guide naming a renamed route fails the build rather than 404ing for a reader.
The same files are published as a static site at the repository root, rendered by the same renderer, so the two cannot drift.
