57 lines
1.6 KiB
Markdown
57 lines
1.6 KiB
Markdown
# ADR-0003: First-Wave `rapp-*` Selection
|
|
|
|
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.
|