Prepare Gitea move review

docs/deploy-capable-gitea-move-review.md

@@ -0,0 +1,111 @@
+# Deploy-Capable Gitea Move Review
+
+Date: 2026-06-05
+
+Status: ready for operator review. No deploy-capable files have been moved by
+this review, and no live cluster command is authorized by this document.
+
+## Goal
+
+Move current Gitea deployment ownership from `railiance-apps` to
+`railiance-forge` without changing live service state, exposing secrets, or
+breaking operator muscle memory.
+
+## Candidate Inventory
+
+| Current path in `railiance-apps` | Sensitivity | Proposed target | Action |
+|---|---:|---|---|
+| `helm/gitea-values.sops.yaml` | SOPS-encrypted | `railiance-forge/helm/gitea-values.sops.yaml` | Move after confirming SOPS age access still works from the new repo. Do not decrypt into Git. |
+| `helm/gitea-registry-values.yaml` | Non-secret | `railiance-forge/helm/gitea-registry-values.yaml` | Move with the registry docs. |
+| `manifests/gitea-ingress.yaml` | Non-secret | `railiance-forge/manifests/gitea-ingress.yaml` | Move and update ownership labels from `railiance-apps` to `railiance-forge` if desired. |
+| `releases/gitea/values.yaml` | Plaintext legacy/operator values | `railiance-forge/releases/gitea/values.yaml` or archive | Review before moving; it contains old CoulombCore-era chart notes and a placeholder password comment. |
+| `make gitea-deploy` | Deploy-capable | `railiance-forge/Makefile` | Move only after app-side compatibility target is ready. |
+| `make gitea-ingress-deploy` | Deploy-capable | `railiance-forge/Makefile` | Move only after app-side compatibility target is ready. |
+| `make gitea-status` | Read-only | `railiance-forge/Makefile` | Already introduced as read-only target. |
+
+## Proposed Target Layout
+
+```text
+railiance-forge/
+  helm/
+    gitea-values.sops.yaml
+    gitea-registry-values.yaml
+  manifests/
+    gitea-ingress.yaml
+  releases/
+    gitea/
+      values.yaml
+```
+
+Keep deploy-capable commands in the forge `Makefile`:
+
+```make
+gitea-deploy
+gitea-ingress-deploy
+gitea-status
+```
+
+Leave app-side compatibility targets in `railiance-apps` for one transition
+window. They should either print the new command location or delegate to
+`make -C /home/worsch/railiance-forge <target>`.
+
+## Review Gates
+
+- Operator confirms that current Gitea runtime ownership belongs in
+  `railiance-forge`, not S5.
+- `railiance-forge` has the pushed remote and State Hub workplans synced.
+- `sops -d helm/gitea-values.sops.yaml` works from the new path for authorized
+  operators.
+- Helm render validation works from the new repo without committing decrypted
+  values.
+- App-side compatibility pointers exist before old commands disappear.
+- The move is kept separate from any Forgejo migration or cutover.
+
+## Validation Plan
+
+Run these after the files move:
+
+```bash
+git diff --check
+make -C /home/worsch/state-hub fix-consistency REPO=railiance-forge
+make -C /home/worsch/state-hub fix-consistency REPO=railiance-apps
+```
+
+Render without writing decrypted secrets into the repo:
+
+```bash
+helm template gitea gitea-charts/gitea \
+  --namespace default \
+  -f <(sops -d helm/gitea-values.sops.yaml) \
+  -f helm/gitea-registry-values.yaml
+```
+
+Inspect live state without applying changes:
+
+```bash
+make gitea-status
+kubectl diff -f manifests/gitea-ingress.yaml --server-side
+```
+
+## Compatibility Plan
+
+`railiance-apps` should keep short files or targets at the old locations during
+the transition:
+
+- `docs/gitea-container-registry.md` points to forge docs.
+- `docs/gitea-package-registry.md` points to forge docs.
+- `make gitea-status` may delegate to forge.
+- `make gitea-deploy` and `make gitea-ingress-deploy` should either delegate to
+  forge or fail with a clear message that deploy ownership has moved.
+
+## Open Questions
+
+- Should `releases/gitea/values.yaml` move as an active file or be archived as
+  legacy evidence?
+- Should `manifests/gitea-ingress.yaml` labels change from
+  `app.kubernetes.io/part-of: railiance-apps` to `railiance-forge` during the
+  move, or stay stable until the next deploy?
+- Should the SOPS sentinel in forge point at `helm/gitea-values.sops.yaml` once
+  that file moves?
+- What restore-drill evidence is required before package data becomes
+  production-critical?

workplans/FORGE-WP-0002-registry-docs-and-readonly-ops.md

@@ -63,7 +63,7 @@ deploy-capable Helm or Kubernetes apply commands.
 
 ```task
 id: FORGE-WP-0002-T03
-status: todo
+status: done
 priority: high
 state_hub_task_id: "58a8073d-4665-4cf6-a1f8-e4810c7d392d"
 ```
@@ -80,6 +80,8 @@ Review the next candidate move from `railiance-apps`:
 Done when the move plan is specific enough to preserve secret boundaries,
 operator compatibility, and live Gitea stability.
 
+Completed in `docs/deploy-capable-gitea-move-review.md`.
+
 ---
 
 ## T04 - Re-home parent workplan references
@@ -96,3 +98,20 @@ Update `railiance-apps` docs and workplans so registry operation points to
 
 Done when the old app-side registry docs are compatibility pointers instead of
 competing canonical sources.
+
+---
+
+## T05 - Execute reviewed deploy-capable move
+
+```task
+id: FORGE-WP-0002-T05
+status: todo
+priority: high
+state_hub_task_id: "6f6fc3a4-a883-4803-84e7-2700629d397a"
+```
+
+After operator review, move deploy-capable Gitea files and commands into
+`railiance-forge` with app-side compatibility targets.
+
+Done when `railiance-forge` owns Gitea deploy/status/ingress commands and
+`railiance-apps` no longer carries live forge deployment files as S5 scope.