coulomb/key-cape
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Record the two ops-warden catalog corrections

Browse source 
Accepted ownership of lane key-cape-oidc-login, which their catalog has carried
as asked-and-waiting since 2026-08-28 -- they were blocked on us. Reported the
rapp-qonto-keycape-client blocker as stale against its own source-read date, and
asked for it to be narrowed to the two custody steps rather than cleared, since
the exchange and the step-3 verification now exist but successor generation and
the CAS write deliberately do not.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016uV8zoCKpA1WRAxsKRYbdH

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1182213@bnt-lap001
Assistant-Session: 966597b9-ae61-46a4-8b9e-1594ab3ec4ad
This commit is contained in:
tegwick 2026-09-08 14:49:01 +02:00
parent 2a8735173b
commit 471465df22
1 changed files with 23 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

23
workplans/KEY-WP-0014-native-credential-lane-handoff.md
View file

@ -136,3 +136,26 @@ Steps 1-3 remain custody's and are deliberately not automated. Task stays `wait`
on exactly two answers: which option ops-warden takes for the login proxy, and on exactly two answers: which option ops-warden takes for the login proxy, and
who executes the successor generation and CAS update under what authority. No who executes the successor generation and CAS update under what authority. No
route changed. route changed.
Both catalog corrections were sent, receipts readable via
`GET /messages/?from_agent=key-cape`:
- `12f1bdfa-b240-414b-aa49-128a4d2acf20` — accepts ownership of lane
`key-cape-oidc-login`, answering the WARDEN-WP-0033-T04 follow-up they have
carried as `asked-and-waiting` since 2026-08-28. States the boundary the lane's
`fetch_command` crosses: key-cape owns browser authentication and the identity
token; the `netkingdom` auth mount, `role=<domain>` mapping, token store and
enforcement of the resulting OpenBao token are not ours. Supplies the source
paths they need to move the lane to `verified: source-read`, and records our
revised, lower estimate of the consumer risk — a pointer lane under ADR-0001
retires nothing when `keycape login` runs alongside it — while asking them to
correct us if the catalog understates its consumers.
- `08d42f47-8e19-4976-98f5-dd259e7b1225` — reports lane
`rapp-qonto-keycape-client`'s blocker as stale against its 2026-08-28
source-read, since `keycape service-token` is the native `client_secret_basic`
exchange it records as absent and `keycape verify-client` is its rotation step 3
verbatim. Asks them to **narrow** it to steps 1-2 rather than clear it, with
proposed replacement text, and notes `rotation.automatable: true` is now
half-true and should say so precisely rather than be flipped either way.
Neither message asks for a route change and neither was one.