coulomb/railiance-master
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs(RMASTER-WP-0020): record operator-only access implementation

Browse source 
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a02b90-83bf-75c2-81c8-aa705414e4d4
This commit is contained in:
codex 2026-08-23 12:59:56 +02:00
parent cce33059c1
commit b6aa19157c
1 changed files with 13 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

13
workplans/RMASTER-WP-0020-openbao-migration-to-reef-railiance.md
View file

@ -327,6 +327,19 @@ operator tunnel replacement is recorded. T09 therefore remains `progress` and
the public-listener retraction acceptance criterion is not met. The platform
owner follow-up is `800eb865-404f-4b2b-9363-94247f2bbdad`.
2026-08-23 implementation: canonical `rapp-openbao` revision `8e5347b` and
`railiance-platform` registrar revision `e8e7119` remove the Ingress from
ordinary deploy source, declare `exposure.posture: operator`, document the
named `openbao-ui-railiance01` tunnel on local port 18200, and add a guarded
Ingress-only retraction with an exact rollback manifest. Server dry-runs pass;
the ClusterIP gateway is Ready; ops-bridge reports the named tunnel healthy;
and the expected overlay is reachable through the loopback URL. The live
public Ingress was deliberately not deleted. T09 remains `progress` pending
admission of the exact loopback callback by KeyCape and the OpenBao role, then
one value-safe attended MFA login. The KeyCape request is State Hub message
`5e56b413-d8ec-4718-b432-2debc40498ca`. None of this authorizes or advances
T08 destructive cleanup.
## Safety constraints
- Never initialize or overwrite either OpenBao instance without verified