Consolidate platform workplans and assess intent gaps
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a06ecb-456a-71c2-b41e-0755d336e883
This commit is contained in:
codex
parent
9d958f8e09
commit
9f83e426c7
40 changed files with 2985 additions and 295 deletions
|
|
@ -1,212 +0,0 @@
|
|||
---
|
||||
id: RPF-WP-0009
|
||||
type: workplan
|
||||
title: "Platform rapp consistency and deployment-management contract"
|
||||
domain: financials
|
||||
repo: railiance-platform
|
||||
status: finished
|
||||
owner: codex
|
||||
topic_slug: railiance
|
||||
created: "2026-08-11"
|
||||
updated: "2026-08-13"
|
||||
related_repos:
|
||||
- railiance-master
|
||||
- the-custodian
|
||||
- reef-railiance
|
||||
- rapp-openbao
|
||||
- rapp-postgres
|
||||
state_hub_workstream_id: "cd85bf28-7050-59a7-9af2-a7455b3df0fb"
|
||||
---
|
||||
|
||||
# RPF-WP-0009 - Platform rapp consistency and deployment-management contract
|
||||
|
||||
## Goal
|
||||
|
||||
Bring the platform-owned managed workload packages (`rapp-openbao`,
|
||||
`rapp-postgres`) onto one consistent, verifiable declaration and operations
|
||||
contract, and establish the S3 pattern that later platform-service rapps are cut
|
||||
from.
|
||||
|
||||
This workplan does **not** own the four-axis repo family model. That model lives
|
||||
in `railiance-master/docs/repository-axes.md` and is being promoted to custodian
|
||||
canon separately. S3's job here is to be the first family member that actually
|
||||
conforms, and to supply the platform-service reference shape.
|
||||
|
||||
## Findings that motivate this workplan
|
||||
|
||||
Surveyed 2026-08-11 against the live cluster and all six family repos.
|
||||
|
||||
The concepts are in better shape than their enforcement. The four families are
|
||||
cleanly defined and `RMASTER-WP-0018`/`RMASTER-WP-0019` in `railiance-master` are both
|
||||
`finished`. Nothing, however, validates a declaration file, so the model has
|
||||
been drifting quietly since the first wave.
|
||||
|
||||
1. **The rapp population diverged from the plan of record.** Planned wave 1 was
|
||||
`rapp-openbao` → `rapp-vergabe-teilnahme` → `rapp-forgejo`. Actual is
|
||||
`rapp-openbao`, plus `rapp-postgres` and `rapp-qonto` created ad hoc from
|
||||
immediate need. `rapp-vergabe-teilnahme` was never built, so the
|
||||
*user-facing* wrapper pattern it existed to prove is still unproven while the
|
||||
platform-service pattern has been proven twice.
|
||||
|
||||
2. **`rapp.yaml` has no schema and has drifted three ways.** The bootstrap
|
||||
contract names eight required fields but no shapes. Result: the
|
||||
rollout/smoke/rollback contracts are mutually unreadable (`supported_commands`
|
||||
lists in openbao and postgres versus `default_mode`/`production_gate`,
|
||||
`required:` and `order:` in qonto); only qonto carries `contract_version`,
|
||||
`readiness_state`, `data_classification` and `criticality`; only postgres has
|
||||
`consumer_contract`; `workload_identity.name` is the workload name twice and
|
||||
the repo name once. `rail.yaml` by contrast is consistent — the rail family
|
||||
got a tighter contract than the rapp family.
|
||||
|
||||
3. **The reef binding registry is stale.** `reef-railiance` declares
|
||||
`bound_rapps: [rapp-qonto]` while `rapp-openbao` and `rapp-postgres` both run
|
||||
on Railiance01. The reef's stated purpose is recording what is bound where,
|
||||
and it missed two of three.
|
||||
|
||||
4. **The model is not canon.** Custodian canon has no reef/rail/rapp standard,
|
||||
and `repo-classification-standard_v1.0` does not admit the prefixes — the
|
||||
same root cause as the open C-31 failures on `RAPP-*-WP-` work-record ids.
|
||||
|
||||
5. **Scale gap.** ~17 live non-system workloads, 3 rapps.
|
||||
|
||||
## Decisions taken (2026-08-11, operator-approved)
|
||||
|
||||
- **Granularity: grouped by bounded context.** One rapp per cohesive service
|
||||
group that deploys, versions and rolls back together, not one per deployable.
|
||||
A grouped rapp must declare its member services explicitly — grouping is only
|
||||
legitimate where the members share a rollout and rollback fate.
|
||||
- **Scope split.** S3 owns its own rapps and the platform-service pattern.
|
||||
Schema, validator and family-model changes are routed to `railiance-master`;
|
||||
canon promotion is routed to `the-custodian`. S3 does not author them.
|
||||
- **Canon: promote now**, so `fix-consistency` can validate declarations.
|
||||
- **Wave-1 gap: build `rapp-vergabe-teilnahme`** to prove the user-facing shape
|
||||
before further extraction. That build is `railiance-apps`/master territory,
|
||||
not S3's; this workplan only supplies the platform-service half of the pattern.
|
||||
|
||||
## Boundaries
|
||||
|
||||
This workplan may:
|
||||
|
||||
- change declarations and operations contracts of platform-owned rapps
|
||||
(`rapp-openbao`, `rapp-postgres` — both declare `ownership_repo: railiance-platform`)
|
||||
- define the S3 platform-service rapp reference pattern
|
||||
- define how credential lanes and grant catalog entries bind to a rapp
|
||||
- send proposals to the repos that own the model, schema and canon
|
||||
|
||||
It must not:
|
||||
|
||||
- author the four-axis model, the `rapp.yaml` schema, or canon standards here
|
||||
- edit `reef-railiance`, `rail-*`, or `railiance-master` declarations directly
|
||||
- absorb platform-wide policy into a rapp (the "shadow S3 repo" failure mode
|
||||
named in `rapp-first-wave-candidates.md`)
|
||||
- change any credential gate, grant delivery, or revocation semantic
|
||||
|
||||
## Tasks
|
||||
|
||||
```task
|
||||
id: RPF-WP-0009-T01
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "512adfef-a561-5b60-b4f3-f60e67696ef9"
|
||||
```
|
||||
|
||||
Publish the S3 platform-service rapp pattern as `docs/rapp-platform-service-pattern.md`:
|
||||
the reference `rapp.yaml` shape for a platform service, the ownership split
|
||||
between rapp and S3, the grouped-rapp member declaration rule, and the
|
||||
credential-lane binding. Generalize from the existing
|
||||
`docs/rapp-openbao-boundary.md` and `docs/rapp-postgres-boundary.md` rather than
|
||||
inventing a third boundary vocabulary.
|
||||
|
||||
```task
|
||||
id: RPF-WP-0009-T02
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "29b55ae5-74e2-5110-892c-ebb2b0cbf550"
|
||||
```
|
||||
|
||||
Bring `rapp-openbao/declarations/rapp.yaml` and
|
||||
`rapp-postgres/declarations/rapp.yaml` into a single consistent shape: add
|
||||
`contract_version`, `readiness_state`, `data_classification` and `criticality`
|
||||
(present in `rail.yaml` and in `rapp-qonto`, absent in both platform rapps), fix
|
||||
`workload_identity.name` to be the workload rather than the repo where it drifts,
|
||||
and align the rollout/smoke/rollback contract shape. Coordinate the target shape
|
||||
with the `railiance-master` schema proposal (T04) before editing, so the two do
|
||||
not converge on different answers.
|
||||
|
||||
```task
|
||||
id: RPF-WP-0009-T03
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "53cb32e3-5cdc-5664-b7be-c46828849c56"
|
||||
```
|
||||
|
||||
Correct the reef binding registry: propose to `reef-railiance` that
|
||||
`bound_rapps` include `rapp-openbao` and `rapp-postgres`, with the evidence that
|
||||
both are live on Railiance01. Proposal only — `reef-railiance` owns its
|
||||
declaration. Ask that the binding be derived or checked rather than hand-listed,
|
||||
since a hand-listed registry is what went stale.
|
||||
|
||||
```task
|
||||
id: RPF-WP-0009-T04
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "b157de50-ff34-57aa-800e-d2d79e65a731"
|
||||
```
|
||||
|
||||
Route the schema and validator proposal to `railiance-master`: a
|
||||
`rapp.schema.json` covering the eight required fields plus the four consistency
|
||||
fields, a validator that runs over every family declaration, the grouped-rapp
|
||||
member field, and a refresh of `rapp-first-wave-candidates.md` to reflect what
|
||||
was actually built and the grouped-context wave-2 inventory.
|
||||
|
||||
```task
|
||||
id: RPF-WP-0009-T05
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "57ed22c9-94b9-526d-beb0-0a090eeaac3a"
|
||||
```
|
||||
|
||||
Route the canon promotion proposal to `the-custodian`: a
|
||||
`railiance-repo-families` standard, declaration schemas under `canon/standards/schemas/`,
|
||||
and admission of the `rail-`/`rapp-`/`reef-` prefixes into
|
||||
`repo-classification-standard` and `work-record-types.yaml` — the latter closing
|
||||
the open C-31 failures on multi-segment `RAPP-*-WP-` ids.
|
||||
|
||||
```task
|
||||
id: RPF-WP-0009-T06
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "4423fa37-7e0d-5e2d-ac39-f6b505c60243"
|
||||
```
|
||||
|
||||
Define how a rapp binds to its credential lane: the relationship between
|
||||
`credential-grants/catalog.yaml` entries, CCR lanes, and a rapp's
|
||||
`runtime_dependencies`/`secret_references`, so that a new rapp has one documented
|
||||
way to acquire runtime secrets instead of re-deriving it per package. Must not
|
||||
alter existing gate, delivery or revocation semantics — this documents and binds
|
||||
the existing lane, it does not build a parallel one.
|
||||
|
||||
## Outcome
|
||||
|
||||
Session of 2026-08-11: T01 published the S3 platform-service pattern; T03, T04
|
||||
and T05 routed their proposals to the owning repos (reef-railiance
|
||||
f0f44ce0, railiance-master 04c776c4, the-custodian cc64764a). T02 was
|
||||
held until railiance-master settled the schema.
|
||||
|
||||
Session of 2026-08-13: T02 done. `rapp-openbao` and `rapp-postgres`
|
||||
`declarations/rapp.yaml` now pass `schemas/rapp.schema.json` (contract
|
||||
metadata, `composition`, `bound_reefs: [reef-railiance]`, `commands`,
|
||||
`smoke_contract.required`, `rollback_contract.order`). Live inventory for
|
||||
the T06 coverage check is
|
||||
`docs/evidence/reef-railiance-deployables.json`, refreshable with
|
||||
`scripts/capture-reef-deployables.py`. Family-validator remainder is
|
||||
outside this task: `rapp-qonto` still on the pre-schema shape, three
|
||||
undeclared `rapp-*` engine repos, and `reef-railiance` `bound_rapps`
|
||||
still hand-listed.
|
||||
|
||||
Session of 2026-08-13 (later): T06 done. Binding recipe is
|
||||
`docs/rapp-credential-lane-binding.md`. Standing secrets bind through
|
||||
a CCR `target.rapp` + `secret_references`; short-lived leases bind
|
||||
through grant `rapp_id` (required when the grant id is `rapp-*/…`).
|
||||
Stamped `rapp-postgres` catalog grants and `CCR-2026-0009`. Gate,
|
||||
delivery, and revocation semantics are unchanged. Workplan finished.
|
||||
Loading…
Add table
Add a link
Reference in a new issue