railiance-platform/workplans/RPF-WP-0061-self-service-ccr-intake.md

id	type	title	domain	repo	status	owner	created	updated	flavor	origin	origin_ref
RPF-WP-0061	workplan	Self-service CCR intake: clients file and progress CCRs without a platform worker	financials	railiance-platform	proposed	codex	2026-10-18	2026-10-18	implementation	cross-repo	ops-mason daa119e6 / 049afa1f; MASON-IN-0005

Demand: every credential change request today waits on a railiance-platform worker session to allocate the CCR number, copy the client's draft and policy file into this repo, run credential-change.py validate, write the platform owner review and relay the founder command. For routine lanes the worker adds no judgement: ops-mason already produces drafts that pass validate (MASON-WP-0010-T03, MASON-WP-0014), and from MASON-IN-0005 ops-mason can apply workload-kv-read-* policies and external-secrets-* roles itself. The worker has become a relay, and clients stall whenever no platform session runs.

Goal: a client can take a standard CCR from draft to approved and applied using only repo tooling, CI and the State Hub decision flow. Platform judgement is moved into a versioned, reviewed standard lane profile; only requests that fall outside it are routed to a platform worker.

Invariants (unchanged by this plan):

• CCRs remain non-secret repo files in credential-change-requests/; the repo stays authoritative and the hub stays a read model.
• Founder approval is never automated. Bound claims still need confirm-binding against native state before apply.
• Nothing here widens ops-mason-construct or any applier grant; secret-id, token creation and value reads stay with the founder and applier.

Design

1. Submit. The client runs, in a railiance-platform checkout, scripts/credential-change.py submit --bundle <dir> (or make ccr-submit). It copies the CCR and policy file, allocates the next free CCR-YYYY-NNNN from the files on the current main, sets status: proposed, validates, commits on branch ccr/<id>-<slug> and pushes. A push or merge race simply re-allocates; git is the allocator, so no central counter or agent is needed.
2. Platform review as policy-as-code. credential-change.py review-standard <ccr> checks the standard lane profile (registry/ccr-standard-profile.yaml): workload-kv-read; kubernetes auth; exactly one KV path under platform/workloads/<a>/<b> or platform/suppliers/<supplier>/<account>; policy file byte-equal to the generated HCL (read on the data path plus lookup/revoke-self only); ttl and max ttl ≤ 15m; token_no_default_policy: true; one SA in one namespace; no other CCR in proposed|approved|active reading the same path. A pass appends the railiance-platform-owner review comment with the profile version and digest. A fail writes the reasons and marks the CCR needs_platform_review, which sends one hub message to railiance-platform.
3. CI gate. A Forgejo Action on ccr/* branches runs validate, review-standard and the secret scan; only a green branch fast-forwards to main. The client merges its own green branch.
4. Founder decision. submit records a State Hub decision for the CCR (templates exist in decision-templates). The founder resolves it; anyone runs sync-decision to move the file to approved/needs_changes.
5. Apply and evidence. In-profile CCRs are applied by ops-mason under ops-mason-construct, or by the applier, after confirm-binding; record-evidence closes the CCR to active.
6. Platform oversight. Platform owns the profile and reviews changes to it like code. A weekly credential-change.py audit-standard lists every auto-reviewed CCR so a platform session can spot-check after the fact.

T01 — Define the standard lane profile

id: RPF-WP-0061-T01
status: todo
priority: high

Write registry/ccr-standard-profile.yaml from the existing approved ESO lanes (CCR-2026-0033, -0035, -0041, -0050, -0051 shapes). Record which past CCRs would and would not have passed it.

T02 — submit and review-standard subcommands

id: RPF-WP-0061-T02
status: todo
priority: high

Add both subcommands to scripts/credential-change.py with tests covering id allocation, duplicate-path refusal, policy-file mismatch and every profile rule. review-standard never touches OpenBao.

T03 — CI gate on ccr/* branches

id: RPF-WP-0061-T03
status: todo
priority: medium

Forgejo Action running validate, review-standard and the secret scan; confirm which identities may push ccr/* (ops-mason first).

T04 — Hub decision on submit and client-run sync-decision

id: RPF-WP-0061-T04
status: todo
priority: medium

T05 — Client documentation and first self-service CCR

id: RPF-WP-0061-T05
status: todo
priority: medium

Document the flow in docs/credential-change-approval.md and notify ops-mason and ops-warden. Acceptance: one CCR filed, reviewed, approved and applied by a client with no railiance-platform worker session involved.