Delegate Gitea operations to forge

This commit is contained in:
2026-06-05 13:19:12 +02:00
parent 421c09e902
commit a715be6d28
7 changed files with 46 additions and 58 deletions

View File

@@ -123,7 +123,7 @@ indexing and no reliance on `railiance-apps` as its planning home.
```task
id: RAILIANCE-WP-0006-T03
status: in_progress
status: done
priority: high
state_hub_task_id: "57162f50-d1a4-4fb3-b4fa-503939b22450"
```
@@ -153,11 +153,13 @@ Migration rules:
Done when `railiance-apps` no longer owns source-forge deployment config, and
current Gitea operation has an equivalent or better home in `railiance-forge`.
Progress 2026-06-05: canonical registry docs moved to `railiance-forge`, with
Completed 2026-06-05: canonical registry docs moved to `railiance-forge`, with
compatibility pointers left in `railiance-apps`. Deploy-capable Gitea
Helm/SOPS/manifests and Makefile deploy targets still remain here pending a
separate review. That review is now drafted in
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.
---
@@ -193,6 +195,10 @@ In `railiance-enablement`:
Done when a new operator can answer "is this S4, S5, or forge?" from the scope
documents without inspecting historical workplans.
Progress 2026-06-05: `railiance-apps/SCOPE.md` now treats forge as an upstream
service and keeps only compatibility wrappers. `railiance-enablement` still
needs the S4 handoff wording checked after the deploy move.
---
## T05 - Define artifact lifecycle, retention, and provenance policy