railiance-master/docs/rapp-first-wave-candidates.md

First-Wave rapp-* Candidates

Date: 2026-07-25

Purpose

Choose and order the first rapp-* candidates for Railiance.

rapp-* repos are for managed workload packaging and scaffolding. They are not new ownership homes. The decision here is therefore not "which repos are important?" but "which workloads already have a strong enough package boundary to become first-class managed wrappers without weakening ownership?"

Selection Criteria

The first-wave candidates should satisfy most of the following:

• stable workload identity
• clear upstream or source workload boundary
• clear Kubernetes package surface already visible in Git
• explicit runtime-secret and dependency handling
• deploy, verify, and recover behavior already described
• low ambiguity between packaging ownership and domain ownership
• good demonstration value for later rapp-* extractions

Assessed Candidates

1. OpenBao from railiance-platform

Assessment: choose first

Why it fits:

• It is a clear third-party upstream product with durable identity.
• The workload already has a substantial Railiance packaging surface: helm/openbao-values.yaml, middleware, UI overlay assets, deploy/verify scripts, and operator runbooks.
• The repo already distinguishes between the OpenBao workload itself and the wider S3 platform policy that consumes it.
• It is important enough to prove that rapp-* is not only for user-facing apps; platform services can also be managed workloads.

What should move into rapp-openbao:

• Helm values and Kubernetes-facing package assets for the OpenBao workload
• UI overlay wrapper assets
• generic deploy, verify, and workload-health runbooks
• workload-specific smoke and recovery expectations

What should remain in railiance-platform:

• the S3 ownership of secrets custody as a platform capability
• workload lane policy, credential approval, and platform-wide access models
• cross-workload secret-delivery conventions consumed by many workloads

Conclusion:

rapp-openbao should be the first rapp-* extraction.

2. Forge workload from railiance-forge

Assessment: defer from first wave

Why it is not first:

• The current live workload is still Gitea on CoulombCore.
• The intended production direction is Forgejo on Railiance01.
• Packaging identity is therefore not stable enough yet: extracting now would either enshrine a temporary Gitea compatibility package or pretend the Forgejo cutover is already complete.
• The runtime and migration story still spans current Gitea operation, future Forgejo deployment, runner substrate, registries, and cutover sequencing.

Decision:

• Do not make the forge workload the first rapp-* extraction.
• Prefer rapp-forgejo as the eventual target package once the production direction is the real operating target.
• Create rapp-gitea only if Railiance discovers it needs a long-lived compatibility wrapper for the current workload rather than a short migration bridge.

What this means:

• railiance-forge keeps runtime ownership for now.
• The forge wrapper should follow after the current Gitea-versus-Forgejo packaging identity stops moving.

Conclusion:

The forge workload is packaging-worthy, but it should not be first-wave rapp-*.

3. User-facing S5 workload from railiance-apps

Assessment: choose vergabe-teilnahme for wave 1

Why vergabe-teilnahme wins the S5 slot:

• It is clearly user-facing and already operates as one named workload package.
• Its release surface is explicit: chart, values, ingress, deployment targets, migration command, smoke checks, and operator runbook.
• Secret handling is clear without being entangled with shared platform semantics: app credentials are consumed from Kubernetes Secrets and the app env secret is locally rebuilt by operator procedure.
• It is simpler and more stable than the current Core Hub / Inter-Hub history and more obviously user-facing than service-style workloads such as reuse-surface.

What should move into rapp-vergabe-teilnahme:

• the chart and workload values
• the ingress and app-specific release runbook
• workload-specific rollout, migration, smoke, and rollback guidance
• workload-specific secret consumption contract

What should remain in railiance-apps:

• S5 ownership of generic application release patterns
• reusable onboarding and operator recipes
• cross-app S5 guardrails that should not be duplicated per workload package

Second-wave S5 note:

• reuse-surface is the strongest follow-on self-built service candidate after vergabe-teilnahme, because it already shows explicit OpenBao-backed runtime secret lanes and a tidy single-workload chart surface.
• core-hub and retired inter-hub should wait because their packaging history is still entangled with cutover and legacy service evolution.

Conclusion:

rapp-vergabe-teilnahme should be the first user-facing S5 rapp-*.

First-Wave Order

The recommended order is:

1. rapp-openbao
2. rapp-vergabe-teilnahme
3. rapp-forgejo after the forge runtime target is stable enough to avoid immediate rename or migration churn

This order is intentional.

• rapp-openbao proves the third-party platform-service wrapper model.
• rapp-vergabe-teilnahme proves the self-built user-facing app wrapper model.
• The forge wrapper then follows with a clearer target identity and after the first two wrappers have established the pattern.

Risks To Watch

• If rapp-openbao absorbs platform-wide policy and credential-governance logic, the wrapper will become a shadow S3 repo.
• If rapp-vergabe-teilnahme absorbs generic S5 onboarding or app recipes, it will weaken railiance-apps as the shared S5 release home.
• If the forge wrapper is extracted too early, Railiance will immediately face a Gitea-versus-Forgejo package rename or parallel-wrapper problem.

Outcome

Railiance now has a concrete first-wave rapp-* sequence:

• first rapp-openbao
• then rapp-vergabe-teilnahme
• then the forge wrapper once the production package identity is stable

That is enough to start repo-local extraction planning without pretending every workload needs its own rapp immediately.