railiance-platform/SCOPE.md
codex 9f83e426c7 Consolidate platform workplans and assess intent gaps
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a06ecb-456a-71c2-b41e-0755d336e883
2026-09-05 11:14:42 +02:00

8.7 KiB
Raw Blame History

SCOPE

Reviewed 2026-09-05 against repository source, dated operating evidence and adjacent owner contracts. This is a scope assessment, not a fresh live audit. INTENT.md remains the stable aspiration.

Purpose and boundary

Railiance's S3 shared stateful services: database provision and placement, secret custody and delivery, and platform-data backup and recovery behind versioned consumer interfaces. Cache, general object storage and messaging remain demand-led capabilities; their inclusion in INTENT does not mean they are deployed or justify running them without consumers.

S3 owns the service promise, custody and acceptance evidence. A rapp-* repo owns its deployable package; the cluster and host owners supply the runtime. Identity integration means consuming identity claims, not operating an identity or authorization authority. See ADR-0001.

Current evidenced capability

Service Implemented / evidenced Limit and authority
apps-pg CNPG source, per-consumer database ACLs, 20-connection allowances, 15-second timeouts; daily backup, continuous WAL and 30-day retention; 56-second scratch restore and 14/14 boundary probes on 2026-08-20 One instance; restart recovery, no HA or measured latency SLO. Ceiling 3, overflow apps-pg-2 provisionable but demand-gated. S3 owns this CR and its controls.
platform-pg Package-operated CNPG service, governed dynamic credentials, backup/restore evidence, Core Hub admission and private shadow evidence rapp-postgres owns CR/provisioning/restore. S3 owns custody, placement policy and consumer disclosure. Published ceiling 4 declarations, counting the probe; reconcile current occupancy before admission. One instance is not HA.
OpenBao and credential delivery CCR validation, policy/grant boundaries, approved apply interfaces, runtime KV/ESO and short-lived database lanes, ephemeral custody lifecycle Package assets belong to rapp-openbao; custody/policy remains here. Existing helpers are not authority to mint arbitrary credentials. Operator-only access cutover and incident residuals remain open.
Backup storage consumption Governed off-cluster S3 backup destination and credential lane used by CNPG; encrypted upload tooling for other backup consumers Resource procurement belongs to resource-control/reef-storage. This does not establish a general S3 service or deployed MinIO. One successful restore does not establish a recurring recovery guarantee.
Cache / general object storage / messaging Valkey deployment is gated; no supported consumer interface or deployed shared broker/general in-cluster object store is established by this review Demand, reuse, ownership, service contract and recovery design must precede deployment. No engine/provider choice is made here.

Evidence and contracts: consumer interfaces, apps-pg restore, apps-pg isolation, placement, tenancy, and Core Hub capacity admission. The former “apps-pg has no backup” and “both ceilings missing” scope statements were stale. Dated evidence above must not be presented as current health.

Responsibility split

S3 retains Other owner / handoff
Database service placement, custody and acceptance rapp-postgres: package, admission enforcement and restore; consumers: schemas, migrations, workload SLOs and app verification
OpenBao service custody, ACL/role review, approved delivery and revocation proof rapp-openbao: package; key-cape/net-kingdom: issuer, OIDC/MFA, directory/provider reconciliation
Platform acceptance of a credential lane secrets-engine: lifecycle engine; ops-mason: construction coordination through engine APIs; flex-auth/access-engine and approval-engine: decisions and approval consumption
Service health semantics, recovery expectations and evidence production railiance-telemetry: Q2 collection, retention and alert transport; it is not S3's monitoring implementation to build
Platform snapshot/unseal/readiness contribution to an outage railiance-infra: host/reboot; railiance-cluster: Kubernetes/restart; consumer owner: synthetic load and application acceptance
Database/object-store/credential interfaces consumed by the forge railiance-forge: forge backup orchestration, artifact retention and pruning; activity-core: automation execution
Scope accuracy and file-backed source records railiance-master: fleet taxonomy and Q3 placement; repo-manager/State Hub: derived record identity and projection correctness

DNS, host firewall, TLS/ingress primitives, Kubernetes runtime, CI templates, application releases, business logic and identity/authorization decisions are outside S3. Existing Forgejo helpers, ArgoCD bootstrap/application manifests, and OpenBao package compatibility assets are retained migration surfaces, not an expansion of that boundary. Transfer requires an accepting owner and tested replacement entry points; source files are not deleted merely to tidy scope.

Work that closes the intent gaps

The current work index groups six open workplans. The full assessment records every reviewed plan and the consolidation mapping.

Priority Gap Canonical work
First Reported credential exposures need final disposition and dependable operator custody RPF-WP-0027: KeyCape/NetKingdom residual evidence and S3 custody; RPF-WP-0029: provider invalidation and replacement backup recovery
First Private attended OpenBao access remains unproven end to end RPF-WP-0025-T03; keep its window separate from incident/recovery actions
Next Recovery procedures exist, but two cross-owner exercises still lack completion evidence RPF-WP-0015-T02/T03: S3 contribution, with audit-core and S1/S2 executing their own parts
Next Three requested credential lanes have designs but no live acceptance RPF-WP-0035: one queue with separate consumer/issuer/approval gates
Next Numeric availability/recovery promises, evidence freshness, recurring drills, emission and admission drift lack a complete S3 acceptance loop RPF-WP-0036-T02T05
Next Compatibility ownership, stale Hub aliases, and undeployed capability demand need explicit disposition RPF-WP-0036-T06/T07

The ready work in RPF-WP-0036 can proceed while attended operations wait. It must define achievable promises for the existing single-node substrate, not declare HA through documentation. Any stronger availability target needs an S1/S2 dependency and a package-level failover proof. Fleet-wide Q3 ownership is an architecture question; it does not suspend S3's own recovery obligations.

Provided capabilities

type: infrastructure
title: PostgreSQL via CloudNative PG (cnpg)
description: Shared database service and placement policy with apps-pg controls and rapp-postgres package integration. Current evidenced deployments are single-instance; HA is not established.
keywords: [postgresql, postgres, cnpg, cloudnative-pg, operator, database, kubernetes]
type: infrastructure
title: Valkey / Redis-compatible cache
description: Declared shared cache capability, not a supported live service. Deployment stays gated on an accepted consumer and service contract.
keywords: [valkey, redis, cache, shared, session, queue]
type: data
title: Object storage (MinIO / S3-compatible)
description: Governed external S3 backup-storage consumption exists. A general shared object-storage service, including in-cluster MinIO, remains undeployed and demand-gated.
keywords: [minio, s3, object-storage, storage, artifacts, backup]
type: security
title: OpenBao platform secrets service
description: S3 custody, policy and approved runtime credential delivery; package assets belong to rapp-openbao. SOPS/age supports bootstrap custody. New lanes need independent live acceptance.
keywords: [openbao, secrets, vault-compatible, secret-management, dynamic-credentials, audit, kubernetes-auth]

Getting oriented

Read AGENTS.md, INTENT.md, then workplans/README.md. Completed plans are preserved under workplans/archived/; WORK-RECORDS.md is the generated current index (archives omitted). Routine sync follows AGENTS.md. The dated .custodian-brief.md and Hub legacy aliases are not additional authoritative obligations.