Define rapp-openbao boundary

SCOPE.md

@@ -14,7 +14,17 @@ S3 Platform Services layer of the Railiance OAS Stack — owns shared cluster se
 
 ## Core Idea
 
-Railiance is structured as five independent repos per OAS Stack layer. This repo is S3 — the platform services that multiple applications share. The active migration is from Bitnami postgresql-ha (repmgr + pgpool, currently a Gitea subchart in S2) to CloudNative PG (cnpg operator, already deployed in the cnpg-system namespace) as the canonical database operator. Valkey cluster is also in scope for S3 extraction from S2.
+Railiance is structured as five independent repos per OAS Stack layer. This repo
+is S3 - the platform services that multiple applications share. The active
+migration is from Bitnami postgresql-ha (repmgr + pgpool, currently a Gitea
+subchart in S2) to CloudNative PG (cnpg operator, already deployed in the
+cnpg-system namespace) as the canonical database operator. Valkey cluster is
+also in scope for S3 extraction from S2.
+
+OpenBao is a platform capability in this repo, but not every OpenBao-related
+file necessarily belongs in the long-term S3 ownership home. Deployment package
+assets are being separated from custody, policy, and lane governance as part of
+the future `rapp-openbao` extraction.
 
 ---
 
@@ -37,6 +47,7 @@ Railiance is structured as five independent repos per OAS Stack layer. This repo
 - Kubernetes runtime → railiance-cluster (S2)
 - Developer tooling, CI/CD → railiance-enablement (S4)
 - Application deployments → railiance-apps (S5)
+- Standalone workload-package ownership for OpenBao deployment assets -> future `rapp-openbao`, while S3 retains secrets custody and policy
 - No re-configuration of S1/S2 concerns from this repo
 
 ---
@@ -46,6 +57,7 @@ Railiance is structured as five independent repos per OAS Stack layer. This repo
 - Deploying or managing shared services that multiple S5 applications depend on
 - Extracting platform services from application Helm subcharts (boundary enforcement)
 - S2 cluster is operational and platform layer can now be established
+- Defining which OpenBao concerns are workload package assets versus retained platform governance
 
 ---
 
@@ -60,9 +72,10 @@ Railiance is structured as five independent repos per OAS Stack layer. This repo
 ## Current State
 
 - Status: active / emerging
-- Implementation: CloudNative PG operator (cnpg) deployed; `databases` namespace active; Valkey + legacy postgresql-ha extraction from S2 in progress (RAIL-PL-WP-0001)
+- Implementation: CloudNative PG operator (cnpg) deployed; `databases` namespace active; OpenBao is live as the S3 secrets service; Valkey + legacy postgresql-ha extraction from S2 remain in progress
 - Stability: emerging — cnpg deployed but database cluster definitions not yet migrated from S2
-- Usage: will be the shared database and cache layer; currently cnpg-system + databases namespaces are live
+- Usage: shared database, cache, and secrets layer; cnpg-system, databases, and openbao namespaces are live
+- Open work: `RAILIANCE-WP-0012` rapp-openbao extraction boundary (active); `RAILIANCE-WP-0013` Forgejo admin PAT OpenBao consumer cutover (active)
 
 ---
 
@@ -77,7 +90,7 @@ Railiance is structured as five independent repos per OAS Stack layer. This repo
 ## Terminology
 
 - Preferred terms: OAS Stack Level S3, platform services, boundary rule, migration (extracting from S2 subcharts)
-- Potentially confusing terms: "migration" here means moving Helm releases between layers, not database schema migration
+- Potentially confusing terms: "migration" here means moving Helm releases between layers, not database schema migration; `rapp-openbao` would package OpenBao, but it would not own platform custody or policy
 
 ---