coulomb/railiance-master
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs(RMASTER-WP-0025): define universal rapp coverage

Browse source 
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a02b90-83bf-75c2-81c8-aa705414e4d4
This commit is contained in:
codex 2026-08-23 01:38:29 +02:00
parent 2b09639eac
commit 51aa55dcb2
4 changed files with 186 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

33
schemas/README.md
View file

@ -30,6 +30,39 @@ deployable belong to exactly one rapp?* That single check catches stale reef
bindings, unpackaged live workloads, and the workload-count gap at once. It is
what turns this schema from a one-shot lint into a standing control loop.
## Coverage boundary
Every **managed running deployable** needs exactly one authoritative rapp. The
rule applies equally to application services and to operational or tooling
runtimes that participate in controls. A long-lived controller, scheduled
tool, or managed one-shot Job is still a deployable; it is not exempt because
its purpose is operational.
Not every operational subject is a workload. Human access, credential
patterns, broker actions, approval records, one-off commands, and
infrastructure resources retain their native actor, lane, activity, decision,
or resource identity when they are not themselves managed deployables. Do not
create a fake rapp merely to make a consumer join total.
Consumers must preserve three distinct outcomes:
| Outcome | Meaning | Required handling |
|---|---|---|
| `resolved` | Exactly one authoritative rapp claims the managed deployable. | Use its explicit rapp and workload reference. |
| `unknown` | The subject should be a workload, but no unique declaration resolves. | Report migration debt; do not infer identity. |
| `not-applicable` | The subject is explicitly not a workload. | Retain its native non-workload identity. |
A pre-rapp running deployable is therefore migration debt and remains
`unknown` to workload-based controls until declared. Repository names,
namespaces, paths, labels, and apparent ownership are evidence inputs, not
fallback identity rules.
Railiance Master owns this vocabulary and the normative family schemas.
Package owners author their declarations; integration owners may discover,
validate, index, project, and resolve explicit references. They must not create
a parallel generic workload declaration or copy rapp metadata into a second
source of truth.
Rapp bounded context is therefore its own dimension, derived neither from
Forgejo organizations nor from State Hub domains. A repo lives in exactly one
Forgejo org, so `org:repo` is one-to-many, and a many-to-many grouping cannot