railiance-forge/workplans/archived/260702-FORGE-WP-0002-registry-docs-and-readonly-ops.md

---
id: FORGE-WP-0002
type: workplan
title: "Canonical registry docs and read-only forge operations"
domain: financials
repo: railiance-forge
status: finished
owner: codex
topic_slug: railiance
planning_priority: high
created: "2026-06-05"
updated: "2026-06-05"
state_hub_workstream_id: "00c57adc-b8e6-46d6-a963-d6847646a6b0"
---

> **Terminology note:** Historical text in this archived workplan may use the legacy term "workstream". The fleet term is **workplan** (`canon/standards/workplan-terminology-fleet_v0.1.md`).

# Canonical registry docs and read-only forge operations

## Context

The `railiance-forge` remote now exists and the repository is synced with
State Hub. The first safe extraction step is to move registry operating
knowledge and read-only inspection targets before moving deploy-capable Gitea
configuration from `railiance-apps`.

## T01 - Adopt canonical Gitea registry docs

```task
id: FORGE-WP-0002-T01
status: done
priority: high
state_hub_task_id: "16fa09f4-f8fe-4d73-a9b1-7611bbf13dc9"
```

Move canonical container and Python package registry operation notes into
`railiance-forge/docs/`, leaving compatibility pointers in `railiance-apps`.

Done when operators can find registry endpoints, credential handling, package
publish/install recipes, and current storage notes in this repo.

---

## T02 - Add read-only operator targets

```task
id: FORGE-WP-0002-T02
status: done
priority: high
state_hub_task_id: "977af707-e455-4669-aeb5-62ccf31a8d55"
```

Add a forge-side `Makefile` with:

- `make registry-docs`;
- `make check-tools`;
- `make gitea-status`.

Done when the new repo can inspect current Gitea state without owning
deploy-capable Helm or Kubernetes apply commands.

---

## T03 - Prepare deploy-capable Gitea move review

```task
id: FORGE-WP-0002-T03
status: done
priority: high
state_hub_task_id: "58a8073d-4665-4cf6-a1f8-e4810c7d392d"
```

Review the next candidate move from `railiance-apps`:

- `helm/gitea-values.sops.yaml`;
- `helm/gitea-registry-values.yaml`;
- `manifests/gitea-ingress.yaml`;
- `releases/gitea/values.yaml`;
- `make gitea-deploy`;
- `make gitea-ingress-deploy`.

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

```task
id: FORGE-WP-0002-T04
status: done
priority: medium
state_hub_task_id: "bc0daafa-0b01-479b-9f46-79c6d8fe1c0e"
```

Update `railiance-apps` docs and workplans so registry operation points to
`railiance-forge`, while app release runbooks stay in S5.

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: done
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.

Completed on 2026-06-05. The Gitea SOPS values, registry overlay, ingress
manifest, legacy release values, and deploy/status Makefile targets now live in
`railiance-forge`. `railiance-apps` keeps compatibility wrappers only. No live
deploy, SOPS decryption, or Kubernetes apply was run.