Establish Railiance architecture home

docs/adr/ADR-0003-rapp-first-wave-selection.md

@@ -0,0 +1,57 @@
+# 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.