Decommission forge compatibility pointers

SCOPE.md

@@ -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 `railiance-forge`
-  boundary instead of owning forge runtime state in S5.
+- consume forge-owned source and registry capabilities 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,15 +55,8 @@ lessons into reusable S5 app release patterns.
 
 ## In Scope
 
-- 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`;
-  - canonical operating docs in `/home/worsch/railiance-forge/docs/`.
+- Consumption of forge-owned source and registry capabilities from S5 app
+  release docs and values, without owning forge runtime configuration.
 - `vergabe-teilnahme` as the first concrete S5 application release:
   - chart in `charts/vergabe-teilnahme/`;
   - values in `helm/vergabe-teilnahme-values.yaml`;
@@ -130,11 +123,13 @@ lessons into reusable S5 app release patterns.
 ## Current State
 
 - Gitea is deployed and operational as the current forge. Its deploy-capable
-  Helm/SOPS/manifests now live in `railiance-forge`; this repo keeps
-  transitional Makefile wrappers only.
+  Helm/SOPS/manifests now live in `railiance-forge`; this repo no longer keeps
+  Gitea deploy/status wrappers or registry pointer docs.
 - 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.
+  registry operating docs live in `railiance-forge`; S5 runbooks link to those
+  docs directly when app releases consume forge artifacts.
+- The final source-of-truth decision for forge ownership is recorded in
+  `docs/forge-source-of-truth-decision.md`.
 - 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.
@@ -152,8 +147,6 @@ lessons into reusable S5 app release patterns.
 
 ## Known Gaps And Opportunities
 
-- 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
@@ -212,8 +205,8 @@ from that file.
   source forge, registry, package registry, runner substrate, and artifact
   evidence belong to `railiance-forge`; this repo consumes those capabilities.
 - Potentially confusing terms:
-  "deployment" here means app release deployment unless a command explicitly
-  delegates to `railiance-forge` for current Gitea operation.
+  "deployment" here means app release deployment. Forge runtime deployment and
+  registry operation belong to `railiance-forge`.
 
 ---
 
@@ -238,7 +231,7 @@ from that file.
 type: infrastructure
 title: S5 application workload deployment
 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]
+keywords: [railiance, s5, registry-consumer, helm, django, vergabe-teilnahme, workload, deployment]
 ```
 
 ```capability
@@ -256,11 +249,12 @@ 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
+5. For Gitea registry work, use the forge-owned docs directly:
    `/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.
+   `/home/worsch/railiance-forge/docs/gitea-package-registry.md`.
 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`.
-7. Run `make check-tools` and `make check-sops` before deploy work.
+7. Run `make check-tools` before deploy work. Run
+   `SOPS_SENTINEL=<encrypted-file> make check-sops` when app release work
+   touches encrypted SOPS files.