Delegate Gitea operations to forge

SCOPE.md

@@ -10,8 +10,8 @@ Last reviewed: 2026-06-05
 ## One-liner
 
 S5 Workloads & Experience Endpoints for Railiance: application Helm releases,
-Kubernetes workload manifests, transitional Gitea release configuration, and
-operator runbooks for user-facing services such as `vergabe-teilnahme`.
+Kubernetes workload manifests, app deployment guardrails, and operator runbooks
+for user-facing services such as `vergabe-teilnahme`.
 
 ---
 
@@ -45,8 +45,8 @@ intent, the current implementation is aligned around:
 - keep application release concerns in S5 while respecting S1-S4 ownership;
 - provide enough runbook and guardrail coverage that the next app does not
   rediscover the same deployment traps;
-- consume the current Gitea/registry surface through the emerging
-  `railiance-forge` boundary while live deploy-capable files are still moving.
+- consume the current Gitea/registry surface through the `railiance-forge`
+  boundary instead of owning forge runtime state in S5.
 
 The remaining gap is not the absence of intent; it is turning the first-app
 lessons into reusable S5 app release patterns.
@@ -55,12 +55,11 @@ lessons into reusable S5 app release patterns.
 
 ## In Scope
 
-- Gitea as a transitional S5-managed workload until `railiance-forge` completes
-  the deploy-capable migration:
-  - Helm release values in `helm/gitea-values.sops.yaml`;
-  - non-secret registry overlay in `helm/gitea-registry-values.yaml`;
-  - ingress manifest in `manifests/gitea-ingress.yaml`;
-  - `make gitea-deploy`, `make gitea-status`, and related operator checks.
+- Transitional Gitea compatibility wrappers:
+  - `make gitea-deploy`;
+  - `make gitea-ingress-deploy`;
+  - `make gitea-status`;
+  - each delegates to `/home/worsch/railiance-forge`.
 - App-side registry consumption pointers:
   - `docs/gitea-container-registry.md`;
   - `docs/gitea-package-registry.md`;
@@ -106,7 +105,6 @@ lessons into reusable S5 app release patterns.
 
 ## Relevant When
 
-- Deploying or upgrading Gitea as the current S5 forge workload.
 - Consuming already-published registry artifacts from S5 app releases.
 - Deploying or upgrading `vergabe-teilnahme` on Railiance.
 - Adding another user-facing S5 application release.
@@ -132,7 +130,8 @@ lessons into reusable S5 app release patterns.
 ## Current Implementation Surface
 
 - Gitea is deployed and operational as the current forge. Its deploy-capable
-  Helm/SOPS/manifests still live here during the `railiance-forge` extraction.
+  Helm/SOPS/manifests now live in `railiance-forge`; this repo keeps
+  transitional Makefile wrappers only.
 - The Gitea container and Python package registry paths are verified. Canonical
   registry operating docs now live in `railiance-forge`; app-side files here are
   compatibility pointers.
@@ -153,10 +152,8 @@ lessons into reusable S5 app release patterns.
 
 ## Known Gaps And Opportunities
 
-- Deploy-capable Gitea Helm/SOPS/manifests still need to move to
-  `railiance-forge` after review.
-- S5 app docs should continue shedding forge-runtime details and linking to
-  forge-owned operating contracts.
+- S5 app docs should continue shedding residual forge-runtime details and link
+  to forge-owned operating contracts.
 - The first-app lessons from `vergabe-teilnahme` are documented, but there is
   no reusable "new S5 app release checklist" yet.
 - The manifest dry-run workflow assumes access to a representative cluster and
@@ -220,7 +217,7 @@ from that file.
 ```capability
 type: infrastructure
 title: S5 application workload deployment
-description: Deploy and operate user-facing Railiance applications as Helm releases and Kubernetes manifests, including transitional Gitea deployment files and the first Django S5 app release.
+description: Deploy and operate user-facing Railiance applications as Helm releases and Kubernetes manifests, including app release guardrails and the first Django S5 app release.
 keywords: [railiance, s5, gitea, registry, helm, django, vergabe-teilnahme, workload, deployment]
 ```