coulomb/railiance-platform
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

close first-generation lane and retain rotation residual atomically

Browse source 
Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a126e1-76f8-7643-8cf3-e93336539ade
This commit is contained in:
codex 2026-10-11 18:46:21 +02:00
parent b0e9a1e7a3
commit 93ac156adf
2 changed files with 57 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

20
workplans/RPF-WP-0054-keycape-client-secret-generate-lane.md
View file

@ -4,7 +4,7 @@ type: workplan
title: "Broker lane keycape-client-secret-generate: generate KeyCape client secrets in custody"
domain: financials
repo: railiance-platform
status: active
status: finished
owner: claude-code
created: "2026-10-09"
updated: "2026-10-10"
@ -319,7 +319,7 @@ follow-through step. T06 is done.
```task
id: RPF-WP-0054-T07
status: wait
status: cancel
priority: low
depends_on: [RPF-WP-0054-T05]
state_hub_task_id: "d5f0beb6-54dc-502b-9c13-0cb6892ab87d"
@ -329,3 +329,19 @@ Design `keycape-client-secret-rotate`: `update` with CAS = current version, an
attended window coordinated with ESO refresh and the KeyCape restart, and
rollback to the previous version. Only after one proven first-generation run.
Not part of the mint-secret gate.
## Closure — 2026-10-10
The first-generation lane is complete: T01–T06 record owner contract acceptance,
source implementation, CCR-2026-0040/0043 attended apply, the disposable CAS-0
probe and self-revocation/cleanup receipts, and ops-warden activation at 6414252.
The live proof is `docs/evidence/2026-10-10-keycape-client-secret-generate-probe.json`.
This closes the lane itself; it does not claim the Forgejo reference case is live
or replace its independent MASON-WP-0010 / WARDEN-WP-0044 acceptance.
T07 was explicitly outside this lane's scope (separate, later rotation). It is
cancelled here as transferred, not implemented. The actionable follow-up is
RPF-WP-0055, `flavor: residual`, `origin_ref: RPF-WP-0054`; no demand or risk
promotion is claimed. Rotation requires its own reviewed CAS/update authority,
ESO and KeyCape coordination, verification and rollback.

39
workplans/RPF-WP-0055-keycape-client-secret-rotation-residual.md Normal file
View file

@ -0,0 +1,39 @@
---
id: RPF-WP-0055
type: workplan
title: "KeyCape client-secret rotation after first-generation lane acceptance"
domain: financials
repo: railiance-platform
status: backlog
owner: codex
created: "2026-10-10"
updated: "2026-10-10"
flavor: residual
origin: residual
origin_ref: RPF-WP-0054
depends_on: []
related_repos: [key-cape, net-kingdom, ops-warden]
state_hub_workstream_id: "5517b448-3721-55d8-b80d-d61e5e137089"
---
Transferred from RPF-WP-0054-T07 before closing its first-generation lane.
This is a separately scoped later capability, not a blocker of CAS-0 generation
and not promoted demand. Do not implement unless demand or risk promotes it.
## Design, admit and verify a coordinated rotation lane
```task
id: RPF-WP-0055-T01
status: todo
priority: low
state_hub_task_id: "4b9c94fb-1251-5f12-b227-1d9d999cd8ed"
```
After one proven first-generation case run, design
`keycape-client-secret-rotate`: exact-path `update` with CAS = current version,
an attended window coordinated with ESO refresh and the KeyCape restart, and
rollback to the previous version. Obtain the independent owner contracts and
exact-action authorization before live changes. Verify the replacement in the
consumer, scoped delivery, cleanup/revocation and rollback; publish only
non-secret receipts. The existing create-only grant must not be widened merely
to perform this residual.