Point app registry docs at railiance-forge

SCOPE.md

@@ -3,15 +3,15 @@
 This file defines what `railiance-apps` owns, when to use it, and where its
 boundaries stop.
 
-Last reviewed: 2026-06-04
+Last reviewed: 2026-06-05
 
 ---
 
 ## One-liner
 
 S5 Workloads & Experience Endpoints for Railiance: application Helm releases,
-Kubernetes workload manifests, registry enablement, and operator runbooks for
-user-facing services such as Gitea and `vergabe-teilnahme`.
+Kubernetes workload manifests, transitional Gitea release configuration, 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;
-- use Gitea as the current forge and package registry until the Forgejo
-  production migration supersedes it.
+- consume the current Gitea/registry surface through the emerging
+  `railiance-forge` boundary while live deploy-capable files are still moving.
 
 The remaining gap is not the absence of intent; it is turning the first-app
 lessons into reusable S5 app release patterns.
@@ -55,15 +55,16 @@ lessons into reusable S5 app release patterns.
 
 ## In Scope
 
-- Gitea as the current S5 forge workload:
+- 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.
-- Gitea package registry enablement and operator documentation:
-  - container registry path and smoke evidence;
-  - Python package registry endpoint and consumer guidance;
-  - registry settings applied as application Helm configuration.
+- App-side registry consumption pointers:
+  - `docs/gitea-container-registry.md`;
+  - `docs/gitea-package-registry.md`;
+  - canonical operating docs in `/home/worsch/railiance-forge/docs/`.
 - `vergabe-teilnahme` as the first concrete S5 application release:
   - chart in `charts/vergabe-teilnahme/`;
   - values in `helm/vergabe-teilnahme-values.yaml`;
@@ -78,8 +79,6 @@ lessons into reusable S5 app release patterns.
   - scripts under `tools/`.
 - S5 app runbooks and recipes in `docs/`, especially:
   - `docs/vergabe-teilnahme.md`;
-  - `docs/gitea-container-registry.md`;
-  - `docs/gitea-package-registry.md`;
   - `docs/django-on-railiance.md`;
   - `docs/operator-setup.md`;
   - `docs/operator-recipes.md`.
@@ -108,7 +107,7 @@ lessons into reusable S5 app release patterns.
 ## Relevant When
 
 - Deploying or upgrading Gitea as the current S5 forge workload.
-- Enabling or verifying Gitea package registry behavior for S5 consumers.
+- Consuming already-published registry artifacts from S5 app releases.
 - Deploying or upgrading `vergabe-teilnahme` on Railiance.
 - Adding another user-facing S5 application release.
 - Debugging app-level Helm values, app ingress, app probes, app secrets, or
@@ -123,8 +122,8 @@ lessons into reusable S5 app release patterns.
 - The work requires platform database provisioning, backup controller setup, or
   shared storage changes.
 - The work is application source-code behavior rather than release wiring.
-- The work is Forgejo production migration design rather than current Gitea
-  operation.
+- The work is forge runtime, registry retention, runner substrate, or Forgejo
+  production migration design rather than S5 app release operation.
 - The work requires secret custody, credential generation, or token storage
   outside approved operator paths.
 
@@ -132,14 +131,12 @@ lessons into reusable S5 app release patterns.
 
 ## Current Implementation Surface
 
-- Gitea is deployed and operational as the current forge. Its S5 Helm values
-  live here, and registry settings are layered through
-  `helm/gitea-registry-values.yaml`.
-- The Gitea container registry path is verified and documented. Package blobs
-  currently land on the Gitea shared PVC, so storage growth and backup/retention
-  posture remain important follow-up concerns.
-- The Gitea Python package registry endpoint is enabled and documented. The
-  `issue-core` migration is still blocked on publishing `issue-core==0.2.0`
+- Gitea is deployed and operational as the current forge. Its deploy-capable
+  Helm/SOPS/manifests still live here during the `railiance-forge` extraction.
+- 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.
+- The `issue-core` migration is still blocked on publishing `issue-core==0.2.0`
   with package credentials in the `issue-core` repo and refreshing the
   `vergabe-teilnahme` lock in its source repo.
 - `vergabe-teilnahme` is represented as a local Helm chart plus values,
@@ -156,11 +153,10 @@ lessons into reusable S5 app release patterns.
 
 ## Known Gaps And Opportunities
 
-- `docs/vergabe-teilnahme.md` still references the old local `issue-core`
-  Docker build-context path in the image promotion section. It needs to be
-  updated after the package registry handoff is fully closed.
-- Gitea package blob storage is operational but not yet tied to an explicit
-  retention, capacity, and restore posture.
+- 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.
 - 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
@@ -208,7 +204,10 @@ from that file.
 
 - `railiance-platform`: shared CNPG clusters, backup primitives, object storage,
   and other platform services consumed by S5 apps.
-- `railiance-enablement`: CI/CD and templates used by S5 releases.
+- `railiance-forge`: current Gitea operation, future Forgejo migration,
+  registries, runners, artifact retention, and forge evidence.
+- `railiance-enablement`: CI/CD templates and developer paved paths used by S5
+  releases.
 - `railiance-cluster`: Kubernetes runtime, ingress controllers, cert-manager,
   and cluster networking.
 - `vergabe-teilnahme`: source Django app, package lock, Dockerfile, and app code.
@@ -221,7 +220,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 Gitea, registry enablement, and the first Django S5 app release.
+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.
 keywords: [railiance, s5, gitea, registry, helm, django, vergabe-teilnahme, workload, deployment]
 ```
 
@@ -240,8 +239,10 @@ keywords: [operator, runbook, sops, cnpg, dry-run, smoke-test, deployment]
 2. Read `INTENT.md` for the stable purpose of the S5 layer.
 3. Read this file for scope and boundaries.
 4. Read the active files in `workplans/`.
-5. For Gitea registry work, start with `docs/gitea-container-registry.md` and
-   `docs/gitea-package-registry.md`.
+5. For Gitea registry work, start with
+   `/home/worsch/railiance-forge/docs/gitea-container-registry.md` and
+   `/home/worsch/railiance-forge/docs/gitea-package-registry.md`; the local
+   files are compatibility pointers.
 6. For `vergabe-teilnahme`, start with `docs/vergabe-teilnahme.md`, then inspect
    `charts/vergabe-teilnahme/`, `helm/vergabe-teilnahme-values.yaml`, and
    `manifests/vergabe-teilnahme-ingress.yaml`.