Close CCR drift and high-risk policy gaps

workplans/RPF-WP-0020-ccr-schema-drift.md

@@ -4,11 +4,11 @@ type: workplan
 title: "Close CCR schema drift: one active lane unmigrated, one draft the suite cannot express"
 domain: financials
 repo: railiance-platform
-status: proposed
+status: finished
 owner: codex
 topic_slug: railiance
 created: "2026-08-18"
-updated: "2026-08-18"
+updated: "2026-08-21"
 related:
   - RPF-WP-0014
 origin: residual
@@ -38,22 +38,22 @@ one makes the suite green first.
 
 ## The two problems
 
-**P1 — an active credential lane is unmigrated.**
+**P1 — an active credential lane uses an unrepresented auth mode.**
 `credential-change-requests/CCR-2026-0010-email-connect-transactional.yaml`
-carries `status: active` and `readiness: ready`, and is missing the entire
-`openbao.auth` block: `method`, `mount`, `role`, `policies`, `bound_claims`.
-The validator gained those requirements and this CCR was never brought
-forward.
+carries `status: active` and `readiness: ready`. It has always declared the
+live transitional ESO token Secret, bootstrap script, policy and TTL, but the
+validator understood only OIDC and Kubernetes auth and consequently reported
+the role/bound-claim fields for those modes as missing.
 
 This is the one that matters. A live lane whose declaration does not describe
 how the workload authenticates is a governance gap, not a lint failure — the
 document that is supposed to be the authority on the lane cannot answer the
-first question anyone would ask of it. The lane itself is presumably working,
-which is exactly what makes it easy to leave.
+first question anyone would ask of it. The live lane is working, which is
+exactly what made this representation gap easy to leave.
 
-**P2 — a genuine in-flight draft the suite cannot express.**
+**P2 — a genuine in-flight request the suite could not express.**
 `CCR-2026-0011-scaleway-object-storage-bootstrap.yaml` carries
-`status: apply_pending` and `readiness: waiting-on-ui-replace-of-xxx-placeholders`.
+`status: apply_pending` and an out-of-enum placeholder readiness string.
 It is a founder-bootstrap credential still holding placeholder values, and
 `ops-warden` already tracks it as a draft lane. Its errors include a
 `readiness` value outside the permitted enum, which is the file honestly
@@ -76,7 +76,7 @@ draft and a real gap produce identical output.
 
 ```task
 id: RPF-WP-0020-T01
-status: todo
+status: done
 priority: high
 state_hub_task_id: "3bf8bf9c-ac33-4ce7-8b3f-5b40135b227c"
 ```
@@ -88,9 +88,18 @@ policy file, not by inventing plausible values. If the live configuration and
 the declaration disagree, the live configuration is the fact and the
 disagreement is the finding.
 
+Completed 2026-08-21. Live read-only Kubernetes metadata showed
+`ClusterSecretStore/openbao-email-connect` using
+`external-secrets/openbao-email-connect-eso-token`, limited to namespace
+`email-connect`, and reporting Valid; its ExternalSecret reported
+SecretSynced. The schema now represents this transitional token mode directly,
+requires the ESO policy artifact, Secret reference, bootstrap script, bounded
+TTL and explicit Kubernetes-auth follow-up, and keeps delegated token creation
+out of scope. No Secret value was read.
+
 ```task
 id: RPF-WP-0020-T02
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "12933d69-82a3-470d-b01c-0c40c28a7984"
 ```
@@ -100,9 +109,16 @@ a `status` the validator recognises as not-yet-complete, with the test
 asserting that such files are still well-formed in every other respect. An
 allowlist of filenames would work today and rot on the next draft.
 
+Completed 2026-08-21. Added the non-applyable `in_flight` status. It requires a
+named owner, blocking reason and exact `missing_fields`; only
+`openbao.policy_file` and `openbao.auth` may be declared incomplete, while all
+other CCR structure remains validated. CCR-2026-0011 now uses this state and a
+valid non-resolvable front-door readiness without inventing policy/auth
+metadata or filling credential placeholders.
+
 ```task
 id: RPF-WP-0020-T03
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "da52b518-c6fb-40b8-acb9-c64724ca4eee"
 ```
@@ -111,9 +127,15 @@ requirement was added without migrating existing active CCRs, other repos
 carrying CCRs may have the same gap and no failing test to reveal it. Confirm
 whether the requirement originated here or upstream, and notify accordingly.
 
+Completed 2026-08-21. Git history traces the validator requirement to local
+commit `815b124`; a filesystem-wide declaration search found CCR files and the
+validator/schema implementation only in `railiance-platform`. There is no
+upstream CCR implementation to migrate or notify. The migration obligation is
+now documented locally.
+
 ```task
 id: RPF-WP-0020-T04
-status: todo
+status: done
 priority: low
 state_hub_task_id: "2259ee69-4914-42c4-9175-8c61b2206888"
 ```
@@ -122,6 +144,12 @@ suite passes. Record in `docs/credential-change-approval.md` that a new
 required field obliges a migration pass over existing active CCRs — the
 omission that produced P1.
 
+Completed 2026-08-21. Regression coverage proves the live token-auth shape,
+explicit in-flight omissions, rejection of undeclared omissions, and safe
+status/summary rendering. The approval guide now requires a migration pass over
+all existing CCRs whenever required fields are added or strengthened. The full
+repository test suite passes.
+
 ## Risks
 
 **T01 invents values to make the test pass.** The likeliest failure and the