Record the ArgoCD lane as the production change path and plan policy-nexus onboarding.

Founder decision 2026-09-21 (the-custodian/docs/kubernetes-change-gate-decision.md).
RPF-WP-0043 plans, and does not perform, the policy-nexus adoption; it waits on
the founder's go-ahead. Records that this repository cannot show ArgoCD
reconciling on railiance01.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 63291@bnt-lap001
Assistant-Session: 8bd77868-ca68-4f49-bb1e-d539ecc0d703
This commit is contained in:
codex 2026-09-21 14:36:08 +02:00
parent ad88639a53
commit adb5a7249c
4 changed files with 285 additions and 0 deletions

View file

@ -24,6 +24,69 @@ Tenant repos own:
Cluster/runtime ownership remains outside this repo: installing or upgrading
ArgoCD itself belongs with the cluster layer.
## Production Change Path (founder decision, 2026-09-21)
Source: `the-custodian/docs/kubernetes-change-gate-decision.md`. Bernd Worsch,
the founder, decided it exercising `GOVERN @ estate`. Terms follow SecurityCanon
Mode of Authority v0.2.0, which is still a draft.
The `railiance-apps-root` lane in this repository is the change path for
workloads whose ADR-0006 `readiness_state` is `production-approved`. The gate is
a quality gate, not an authorization decision. No PDP sits in this path.
| Target readiness state | Path for a change | `Activation` |
| --- | --- | --- |
| `declared`, `installed`, `verified` | Direct `ADMINISTER @ realm:kubernetes` (ops-mason) | `APPROVED`: founder approval of the construction plan |
| `production-approved` | `CONSTRUCT @` the tenant manifest repository, plus a reviewed Application here; ArgoCD reconciles | `APPROVED` for the change; the merge is the gate |
| `production-approved`, emergency | Direct `ADMINISTER` | `BREAK_GLASS`, recorded, then reconciled back into the repository |
Platform objects that carry no readiness state default to the production tier.
A change through git leaves `external-audited` evidence. A direct apply leaves
only `target-audited` evidence. That difference is why production changes go
through git.
What this means for platform review in this repository:
- A merge to `argocd/applications/` is a live production change. Once the
commit is on `main`, `railiance-apps-root` syncs it with prune and self-heal.
Treat the merge as the `APPROVED` gate, not as a draft.
- A new Application for a workload that is already running is an **adoption**.
Follow the adoption steps in `workplans/RPF-WP-0043-policy-nexus-argocd-onboarding.md`:
manual sync first, a diff, no resources finalizer, and the founder's go-ahead.
- Many platform objects are still changed by direct Make targets:
ClusterSecretStores on railiance01, OpenBao configuration and the bootstrap
itself. Under this decision they default to the production tier. That is a
declared gap (RPF-WP-0043-T05), not conformance.
**Transition.** `rapp-policy-nexus` is `production-approved` but not yet an
Application here. Until 2026-12-21 its changes keep `activation=APPROVED` by
founder plan approval, and each one is recorded as production-tier.
Onboarding is due by 2026-12-21 (RPF-WP-0043).
**Not verified: that ArgoCD syncs on railiance01.** This repository does not
show it, and some records point the other way:
- The only record of ArgoCD's health is the RPF-WP-0022 inbox evidence from
2026-06: "installed and healthy on `railiance01`", with zero Applications.
That is from before the 2026-07-02 naming correction. Until then, "railiance01
cluster" often meant coulombcore.
- The later records in this file and in
`argocd/platform-addons/openbao-secretstore/kustomization.yaml` name the
ArgoCD that runs these Applications "coulombcore ArgoCD". They say the
railiance01 stores are "not managed by coulombcore ArgoCD".
- Every Application uses `destination.server: https://kubernetes.default.svc`,
so it reconciles whichever cluster ArgoCD itself runs in.
- No evidence file in this repository records a sync of `railiance-apps-root`
on railiance01 (92.205.62.239).
Confirming it takes an attended **read-only** check against railiance01, not
coulombcore: check the node IP, the `argocd` namespace, and the `railiance-apps-root`
sync and health status, for example `make argocd-status` with a kubeconfig whose
server is verified to be 92.205.62.239. Record the result as evidence. If ArgoCD
is not running there, the production row has no working path on railiance01
yet. Installing ArgoCD belongs to the cluster layer and needs its own go-ahead
from the founder. This is RPF-WP-0043-T01.
## Bootstrap Layout
```text