coulomb/ops-warden
4
0
Fork 0
Code Issues Pull requests Projects Releases 2 Packages Wiki Activity Actions
ops-warden/registry
History
tegwick ee94c18938 WARDEN-WP-0033 finished — key-cape accepted the issuance question five days ago 
T04 was the last open task, waiting on key-cape to accept or refuse ownership of
the coding-agent OpenBao issuance identity. They accepted, in KEY-WP-0009-T03,
on 2026-08-23: codex-railiance-platform is published in their
config/service-clients.example.yaml with subject service:codex:railiance-platform,
role coding-agent, scope openbao:login, 15m lifetime, and the service-auth
semantics in docs/openbao-service-auth-contract.md. The split is the one we
routed for — KeyCape issues, railiance-platform binds the OpenBao role, OpenBao
enforces, no secret value in either repo.

We found it by reading their repository. KEY-WP-0009-T04 records replying to
ops-warden; the inbox has zero messages from key-cape, read or unread. The task
sat `wait` on an answer that already existed.

That is T05's own lesson arriving on T04: a blocker is a claim about the world at
a date. So the same pass re-verified the two lanes pointing at key-cape against
their source instead of bumping dates:

- rapp-qonto-keycape-client -> verified: source-read. KEY-WP-0009-T02 did add
  bounded service-auth, but that is client_credentials JWT issuance for OpenBao
  machine login and does not front this client_secret_basic exchange or its
  rotation. Blocker stands, now with evidence rather than memory.
- key-cape-oidc-login -> asked of key-cape today, which the entry had recorded
  as still outstanding since 2026-08-21.

Also cleared the inbox that hid this: 9 stale unread, all superseded by shipped
work, with late closes sent to secrets-engine and llm-connect on the two threads
that had asked ops-warden something and never got an answer.

391 tests pass, ruff clean, boundary coverage 0 uncovered.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 4014535@bnt-lap001
Assistant-Session: d0036016-73e8-4da1-8e47-563e3ab39a3c
2026-08-28 22:00:09 +02:00
..
capabilities docs(WP-0010): sharpen mission to "issue SSH, route the rest" + pointer catalog 2026-06-18 20:44:53 +02:00
flex-auth feat: adopt security zones and explicit workload refs 2026-08-22 15:36:37 +02:00
generated WARDEN-WP-0033 finished — key-cape accepted the issuance question five days ago 2026-08-28 22:00:09 +02:00
indexes WARDEN-WP-0006: NetKingdom stewardship docs and alignment 2026-06-17 08:22:45 +02:00
policy WARDEN-WP-0029: implement plan front door, org posture, desk, freshness 2026-07-18 16:59:37 +02:00
routing WARDEN-WP-0033 finished — key-cape accepted the issuance question five days ago 2026-08-28 22:00:09 +02:00
README.md Add capability registry scaffold (REUSE-WP-0014-T06 B04) 2026-06-16 01:56:08 +02:00

README.md

Capability Registry

Markdown-first capability index for federation and reuse planning.

Authoring

  1. Copy a capability entry template (see reuse-surface templates/capability-entry.template.md).
  2. Add the row to indexes/capabilities.yaml.
  3. Run reuse-surface validate from a checkout with the CLI installed.
  4. Merge to main and verify publish with reuse-surface establish --publish-check.

Federation contract: reuse-surface docs/RegistryFederation.md.