Date: 2026-07-25 Status: Accepted

## 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.