NK-WP-0048: run keycape check-config before any registry patch
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s

keycape-client.py --check-config runs KeyCape's startup checks (key-cape
c528daa) on the live and proposed registry via stdin; apply refuses a
registry KeyCape would refuse at start. Type 1.1 patch names the option.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 736651@bnt-lap001
Assistant-Session: f6189624-fd64-4109-b53e-f8a59ca8a2d8
This commit is contained in:
tegwick 2026-10-10 15:28:05 +02:00
parent 1c2d0c2cf6
commit 35880bbce4
5 changed files with 97 additions and 10 deletions

View file

@ -416,6 +416,20 @@ acknowledgment intake keeps `@1.0` as the record of what was acknowledged.
ops-mason's build and ops-warden's case-ref digest predate this and need a
re-render.
2026-10-10: ops-mason re-rendered the Forgejo case from `@1.1` (message
`22c6bba6`; plan digest `af1f4f81…`, no collisions) and rebuilt the bundle. The
rendered OpenBao objects are identical to 1.0, so the already applied
CCR-2026-0041 stands; 1.1 changes only consumer-side steps. key-cape shipped
`keycape check-config` (c528daa, message `a7b0aeff`): KeyCape's startup checks
without secret values, including the new duplicate-clientId rule.
`keycape-client.py --check-config <binary>` now runs it on the live and the
proposed registry, fed on stdin, and apply refuses a proposed registry that
fails; register-client's entry point names the option (1.1 patch). The deployed
image predates c528daa, so the binary is built from key-cape source for now.
Before the next KeyCape rollout (Forgejo register-client or the CCR-2026-0018
window), the attended operator runs `inspect --check-config` so the live
registry is checked too.
```task
id: NK-WP-0048-T07
status: wait