Open RAILIANCE-WP-0015: platform rapp consistency

Survey of the four-axis repo family model against the live cluster and all six
family repos found the concepts sound but unenforced: rapp.yaml has no schema
and has drifted three ways across the three existing rapps, the reef binding
registry lists 1 of 3 live rapps, the rapp population diverged from the
first-wave plan of record, and the model is not in custodian canon so
fix-consistency cannot check it.

Operator decisions recorded in the workplan: grouped-by-bounded-context rapp
granularity, S3 owns only its own rapps and routes schema/canon changes to the
repos that own them, canonize the model now, and build the missing wave-1
user-facing exemplar.

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

WORK-RECORDS.md

@@ -15,6 +15,7 @@
 | workplan | RAILIANCE-WP-0011 | finished | — | workplans/RAILIANCE-WP-0011-reuse-surface-runtime-secrets-openbao-lane.md |
 | workplan | RAILIANCE-WP-0012 | finished | — | workplans/RAILIANCE-WP-0012-rapp-openbao-extraction-boundary.md |
 | workplan | RAILIANCE-WP-0013 | finished | — | workplans/RAILIANCE-WP-0013-forgejo-admin-pat-openbao-cutover.md |
+| workplan | RAILIANCE-WP-0014 | finished | — | workplans/RAILIANCE-WP-0014-credential-change-suite-stabilization.md |
 | task | RAILIANCE-WP-0005-T01 | done | — | workplans/RAILIANCE-WP-0005-credential-request-and-lease-broker.md |
 | task | RAILIANCE-WP-0005-T02 | done | — | workplans/RAILIANCE-WP-0005-credential-request-and-lease-broker.md |
 | task | RAILIANCE-WP-0005-T03 | done | — | workplans/RAILIANCE-WP-0005-credential-request-and-lease-broker.md |
@@ -56,3 +57,7 @@
 | task | RAILIANCE-WP-0013-T02 | done | — | workplans/RAILIANCE-WP-0013-forgejo-admin-pat-openbao-cutover.md |
 | task | RAILIANCE-WP-0013-T03 | done | — | workplans/RAILIANCE-WP-0013-forgejo-admin-pat-openbao-cutover.md |
 | task | RAILIANCE-WP-0013-T04 | done | — | workplans/RAILIANCE-WP-0013-forgejo-admin-pat-openbao-cutover.md |
+| task | RAILIANCE-WP-0014-T01 | done | — | workplans/RAILIANCE-WP-0014-credential-change-suite-stabilization.md |
+| task | RAILIANCE-WP-0014-T02 | done | — | workplans/RAILIANCE-WP-0014-credential-change-suite-stabilization.md |
+| task | RAILIANCE-WP-0014-T03 | done | — | workplans/RAILIANCE-WP-0014-credential-change-suite-stabilization.md |
+| task | RAILIANCE-WP-0014-T04 | done | — | workplans/RAILIANCE-WP-0014-credential-change-suite-stabilization.md |

workplans/RAILIANCE-WP-0014-credential-change-suite-stabilization.md

@@ -12,6 +12,7 @@ updated: "2026-08-11"
 related_repos:
   - rapp-postgres
   - ops-warden
+state_hub_workstream_id: "4dea40b7-43f5-499a-8919-79221623aa79"
 ---
 
 # RAILIANCE-WP-0014 - Credential-change test suite stabilization
@@ -62,6 +63,7 @@ It must not:
 id: RAILIANCE-WP-0014-T01
 status: done
 priority: high
+state_hub_task_id: "18d3358b-2cd6-4fe0-aab6-602f85d8cccd"
 ```
 
 Repair `CCR-2026-0009` (qonto-assistant workload KV read lane) so it validates:
@@ -79,6 +81,7 @@ missing source artifact, it does not advance the lane.
 id: RAILIANCE-WP-0014-T02
 status: done
 priority: high
+state_hub_task_id: "4705a142-4168-41a8-aba0-691d8fc3c6bd"
 ```
 
 Stop the refusal tests depending on live CCR lifecycle state. Add a
@@ -99,6 +102,7 @@ already correct and was left untouched.
 id: RAILIANCE-WP-0014-T03
 status: done
 priority: medium
+state_hub_task_id: "dd34d578-97e5-4c26-aef8-faafc994c387"
 ```
 
 Fix `test_approve_records_comment_but_unconfirmed_claim_still_blocks_apply`,
@@ -112,6 +116,7 @@ test actually wants. The validation rule is correct and unchanged.
 id: RAILIANCE-WP-0014-T04
 status: done
 priority: high
+state_hub_task_id: "457053f2-261f-4c80-92d4-c084e6236e88"
 ```
 
 Confirm acceptance against the requested criteria:

workplans/RAILIANCE-WP-0015-platform-rapp-consistency.md

@@ -0,0 +1,184 @@
+---
+id: RAILIANCE-WP-0015
+type: workplan
+title: "Platform rapp consistency and deployment-management contract"
+domain: financials
+repo: railiance-platform
+status: active
+owner: codex
+topic_slug: railiance
+created: "2026-08-11"
+updated: "2026-08-11"
+related_repos:
+  - railiance-master
+  - the-custodian
+  - reef-railiance
+  - rapp-openbao
+  - rapp-postgres
+---
+
+# RAILIANCE-WP-0015 - 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 `RAILIANCE-WP-0018`/`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: RAILIANCE-WP-0015-T01
+status: todo
+priority: high
+```
+
+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: RAILIANCE-WP-0015-T02
+status: todo
+priority: high
+```
+
+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: RAILIANCE-WP-0015-T03
+status: todo
+priority: medium
+```
+
+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: RAILIANCE-WP-0015-T04
+status: todo
+priority: high
+```
+
+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: RAILIANCE-WP-0015-T05
+status: todo
+priority: medium
+```
+
+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: RAILIANCE-WP-0015-T06
+status: todo
+priority: medium
+```
+
+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
+
+Pending.