Decommission forge compatibility pointers

workplans/railiance-apps-WP-0004-app-deployment-improvements.md

@@ -9,7 +9,7 @@ owner: railiance
 topic_slug: railiance
 planning_priority: medium
 created: "2026-05-19"
-updated: "2026-05-23"
+updated: "2026-06-05"
 state_hub_workstream_id: "b61a9aca-4e43-4b3d-a48b-999e0fa842cf"
 ---
 
@@ -20,7 +20,7 @@ This workplan collects concrete follow-ups surfaced while shipping
 independent, and can be picked up in isolation when the next S5 app
 lands or when the next operator onboards. Activated on 2026-05-22;
 local railiance-apps guardrails are implemented, with the package
-publication item blocked on Gitea package publish credentials.
+publication item blocked on forge-owned Gitea package publish credentials.
 
 ## I01 — URL-encode DB passwords at Secret-build time
 
@@ -102,15 +102,17 @@ proper wheel with version, and switch the dep to
 `issue-core>=0.2,<0.3` with a normal index URL. The Dockerfile then
 drops the `--build-context` and the build becomes portable.
 
-**Coordination:** depends on Gitea PyPI enablement in `railiance-apps`
-(small Helm values change) and a release pipeline for `issue-core`
-(separate repo).
+**Coordination:** depends on the forge-owned Gitea PyPI endpoint and package
+token posture in `railiance-forge`, plus a release pipeline for `issue-core`
+in its source repo.
 
-**Local progress 2026-05-22.** `helm/gitea-registry-values.yaml` now
-sets `packages.LIMIT_SIZE_PYPI: -1`, and
-`docs/gitea-package-registry.md` documents the Gitea PyPI endpoint plus
-the `issue-core` migration. The remaining release and dependency change
-must happen in the `issue-core` and `vergabe-teilnahme` repos.
+**Local progress 2026-05-22.** `helm/gitea-registry-values.yaml` set
+`packages.LIMIT_SIZE_PYPI: -1` while Gitea was still operated from this repo.
+That registry operating surface has since moved to `railiance-forge`; current
+PyPI endpoint docs live at
+`/home/worsch/railiance-forge/docs/gitea-package-registry.md`. The remaining
+release and dependency change must happen in the `issue-core` and
+`vergabe-teilnahme` repos.
 
 **Cross-repo progress 2026-05-23.** `issue-core` now has a validated
 `make package-check` build and Gitea Actions publish workflow for the
@@ -171,8 +173,9 @@ decrypt a known sentinel would catch this at the first deploy attempt
 rather than at the failing apply.
 
 **Implemented 2026-05-22.** Added `docs/operator-setup.md`,
-`tools/check-sops.sh`, and `make check-sops` using
-`helm/gitea-values.sops.yaml` as the sentinel by default.
+`tools/check-sops.sh`, and `make check-sops`. After the forge extraction,
+`make check-sops` requires an explicit `SOPS_SENTINEL=<encrypted-file>` so this
+repo does not depend on forge-owned Gitea SOPS files.
 
 ---
 
@@ -239,7 +242,8 @@ wraps the pattern.
 ## Notes
 
 - Items were activated on 2026-05-22. Local railiance-apps pieces are
-  complete except I03, which is blocked on Gitea package publish credentials.
+  complete except I03, which is blocked on forge-owned Gitea package publish
+  credentials and source-repo release work.
 - I06 is genuinely cross-repo; the others are local to
   `railiance-apps` or its operator workflow.
 - The first three items (I01, I02, I03) are the highest-leverage