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
who executes the successor generation and CAS update under what authority. No
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.