Decommission forge compatibility pointers

workplans/RAILIANCE-WP-0005-s5-app-release-readiness.md

@@ -19,9 +19,9 @@ state_hub_workstream_id: "685f1c18-33c0-400d-a2b1-e1dae0f27c3e"
 
 The 2026-06-04 review of `SCOPE.md` against the actual repository
 implementation found that `railiance-apps` has moved beyond "Gitea Helm values"
-and now owns the repeatable S5 application release surface: Gitea registry
-enablement, the `vergabe-teilnahme` Helm release, operator guardrails, and
-deployment runbooks.
+and now owns the repeatable S5 application release surface: forge-backed
+artifact consumption, the `vergabe-teilnahme` Helm release, operator
+guardrails, and deployment runbooks.
 
 The 2026-06-05 `railiance-forge` extraction moved canonical registry operating
 docs and registry-retention policy into the new forge layer. This workplan now
@@ -34,7 +34,7 @@ The same review found several gaps:
   tied to the old local `issue-core` build context.
 - First-app lessons are documented, but there is no reusable checklist for the
   next S5 app release.
-- Gitea package storage and app database backup responsibilities need clearer
+- Forge package storage and app database backup responsibilities need clearer
   contracts with platform-layer work.
 - The server-side dry-run workflow does not state its live-cluster/CRD
   prerequisites clearly enough for a future runner.
@@ -57,7 +57,7 @@ It should explain:
 - why this repo exists as the S5 application deployment surface;
 - what problem it solves for operators and source app repos;
 - what it intentionally does not own across S1-S4 boundaries;
-- how Gitea, package registry enablement, `vergabe-teilnahme`, and future S5
+- how forge-owned registry capabilities, `vergabe-teilnahme`, and future S5
   apps fit together;
 - how workplan files relate to State Hub workstreams and task rows.
 
@@ -84,14 +84,15 @@ Focus areas:
 - document the package-registry credential path for private Python package
   installs without committing tokenized index URLs;
 - state when `vergabe-teilnahme/uv.lock` must be regenerated in the source repo;
-- keep `docs/gitea-package-registry.md` focused on the S5 registry endpoint and
-  cross-link source-repo release docs instead of duplicating them.
+- link to forge-owned registry endpoint docs and source-repo release docs
+  instead of duplicating them in S5.
 
 Done when the Railiance operator docs describe the portable image promotion path
 and no active runbook tells an operator to rely on a sibling repo checkout.
 
 Completed on 2026-06-05 by updating `docs/vergabe-teilnahme.md` and replacing
-the local registry docs with compatibility pointers to `railiance-forge`.
+local registry ownership with direct links to `railiance-forge`. The temporary
+compatibility pointers were removed later by `RAILIANCE-WP-0006-T10`.
 
 ---
 
@@ -178,7 +179,7 @@ PR checks or still needs runner/cluster preparation.
 
 ---
 
-## T06 - Define Gitea package registry storage and retention posture
+## T06 - Hand off Gitea package registry storage and retention posture
 
 ```task
 id: RAILIANCE-WP-0005-T06
@@ -187,8 +188,8 @@ priority: medium
 state_hub_task_id: "382ba252-0f54-45fa-8e33-e656f4472341"
 ```
 
-Document the operating posture for Gitea package storage while Gitea remains the
-active forge.
+Document the forge-owned operating posture for Gitea package storage while
+Gitea remains the active forge.
 
 Include:
 
@@ -199,9 +200,8 @@ Include:
 - handoff to platform backup/restore work when package data becomes production
   critical.
 
-Done when registry growth is no longer only a note in
-`docs/gitea-container-registry.md`.
+Done when registry growth is no longer only a note in S5 app docs.
 
 Completed on 2026-06-05 by moving the canonical storage and retention posture
-to `/home/worsch/railiance-forge/docs/initial-operating-contracts.md`; the local
-registry docs are compatibility pointers.
+to `/home/worsch/railiance-forge/docs/initial-operating-contracts.md`; S5 app
+runbooks now cite forge docs directly.

workplans/RAILIANCE-WP-0006-railiance-forge-extraction.md

@@ -4,7 +4,7 @@ type: workplan
 title: "Extract railiance-forge and formalize forge-layer contracts"
 domain: railiance
 repo: railiance-apps
-status: active
+status: finished
 owner: codex
 topic_slug: railiance
 planning_priority: high
@@ -158,8 +158,9 @@ compatibility pointers left in `railiance-apps`. Deploy-capable Gitea
 Helm/SOPS/manifests and Makefile deploy/status targets also moved to
 `railiance-forge` after the review in
 `/home/worsch/railiance-forge/docs/deploy-capable-gitea-move-review.md`.
-`railiance-apps` now keeps compatibility wrappers only. No live deploy, SOPS
-decryption, or Kubernetes apply was run.
+`railiance-apps` temporarily kept compatibility wrappers until
+`RAILIANCE-WP-0006-T10`. No live deploy, SOPS decryption, or Kubernetes apply
+was run.
 
 ---
 
@@ -196,7 +197,7 @@ Done when a new operator can answer "is this S4, S5, or forge?" from the scope
 documents without inspecting historical workplans.
 
 Completed 2026-06-05: `railiance-apps/SCOPE.md` now treats forge as an upstream
-service and keeps only compatibility wrappers for moved Gitea operations.
+service and keeps app release ownership separate from moved Gitea operations.
 `railiance-enablement/SCOPE.md` and `railiance-enablement/INTENT.md` now
 separate reusable S4 workflow templates and paved paths from forge-owned
 runtime, registries, runner substrate, labels, credentials, and artifact
@@ -385,7 +386,7 @@ cycle. Validation passed with `0 error(s), 0 warning(s)`.
 
 ```task
 id: RAILIANCE-WP-0006-T10
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "5bca2a11-453c-4cd0-b86a-7ed269564dfb"
 ```
@@ -404,3 +405,10 @@ Steps:
 
 Done when no active railiance workplan asks operators to modify forge runtime
 state from the wrong repo.
+
+Completed 2026-06-05: removed the app-side Gitea deploy/status compatibility
+wrappers, deleted local registry pointer docs, changed `make check-sops` to
+require an explicit `SOPS_SENTINEL`, refreshed active workplans so package
+registry and token ownership point to `railiance-forge` and source repos,
+archived `RAIL-AP-WP-0001`, and recorded the final source-of-truth decision in
+`docs/forge-source-of-truth-decision.md` and State Hub.

workplans/archived/260605-RAIL-AP-WP-0001-gitea-container-registry.md

@@ -4,11 +4,11 @@ type: workplan
 title: "Enable Gitea Container Registry for Cluster Image Publishing"
 domain: railiance
 repo: railiance-apps
-status: finished
+status: archived
 owner: railiance
 topic_slug: railiance
 created: "2026-05-15"
-updated: "2026-05-19"
+updated: "2026-06-05"
 planning_priority: high
 planning_order: 1
 state_hub_workstream_id: "abd268e6-5af9-45ec-93e0-5ffca0211dd0"

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