The construction plan proposed an AppRole from a survey written with no OpenBao session. The phase-4 live survey found kubernetes/ auth already enabled on this cluster with four external-secrets-* roles using it, and the founder ruled for it on 2026-08-27. The pod authenticates with its own projected ServiceAccount token, so the lane has no role_id/secret_id to deliver, store, or rotate. Bound to state-hub/state-hub and deliberately not to default, which would grant the lane to every pod in the namespace. Policy and role are built and capability-verified. Entry stays draft: the KV path holds no token until paste_once_provision delivers one, and the ServiceAccount does not exist yet (STATE-WP-0084-T02). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 3377672@bnt-lap001 Assistant-Session: 15463ccf-238f-4e13-b163-93aa25c6d166 |
||
|---|---|---|
| .. | ||
| capabilities | ||
| flex-auth | ||
| generated | ||
| indexes | ||
| policy | ||
| routing | ||
| README.md | ||
Capability Registry
Markdown-first capability index for federation and reuse planning.
Authoring
- Copy a capability entry template (see reuse-surface
templates/capability-entry.template.md). - Add the row to
indexes/capabilities.yaml. - Run
reuse-surface validatefrom a checkout with the CLI installed. - Merge to
mainand verify publish withreuse-surface establish --publish-check.
Federation contract: reuse-surface docs/RegistryFederation.md.