First-Wave rapp Selection

Context

Railiance wants rapp-* repos to represent managed workload packages rather than new ownership layers.

The current workload surfaces already suggest several candidates:

• OpenBao in railiance-platform
• the forge workload in railiance-forge
• multiple S5 workloads in railiance-apps

But they are not equally ready for first extraction.

Decision

The first-wave rapp-* order is:

1. rapp-openbao
2. rapp-vergabe-teilnahme
3. later rapp-forgejo after the forge runtime target stabilizes

The forge workload is explicitly deferred from the first wave because current Gitea operation and future Forgejo direction are both active realities.

Consequences

Positive

• The first rapp-* extraction proves the third-party platform-service wrapper model.
• The second proves the user-facing self-built app wrapper model.
• The deferred forge wrapper avoids immediate rename churn and packaging ambiguity.

Required Follow-On Work

• Write repo-local extraction work for rapp-openbao.
• Write repo-local extraction work for rapp-vergabe-teilnahme.
• Reassess the forge wrapper when the production package target is no longer split between current Gitea and future Forgejo.

Constraints

• rapp-* repos must stay packaging-focused and must not become shadow ownership repos.
• Shared S3 policy stays in railiance-platform.
• Shared S5 release patterns stay in railiance-apps.

Notes

This ADR chooses sequence, not a mandatory destination for every workload in the ecosystem.