# 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?