Add OpenBao runtime secret authority; complete NK-WP-0006/0007/0008

Refine the recursive platform security architecture to make OpenBao the
canonical runtime secret authority, with SOPS/age, K8s Secrets, and the
emergency bundle reframed as bootstrap/delivery/break-glass mechanisms.

- credential-management standard v0.2: add OpenBao runtime authority
  section, rotation rules, and prohibited patterns (OpenBao-as-PDP,
  tenant platform-root)
- platform-identity-security-architecture: mark implemented; add
  flex-auth/Topaz implications, Coulomb onboarding path, and a
  production-readiness checklist
- NK-WP-0004/0005: document bootstrap-to-OpenBao handoff boundary
- NK-WP-0006/0007: status -> done with implementation reviews; add
  recursive platform/tenant split and OpenBao broker/audit role for
  object-storage STS vending
- NK-WP-0008: status -> done; repoint corpus to infospace-bench
- new ADR-0007 (orchestration boundary), ADR-0008 (STS vending
  boundary), and the object-storage STS credential-vending architecture

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

workplans/NK-WP-0006-recursive-platform-identity-security-architecture.md

@@ -4,11 +4,11 @@ type: workplan
 title: Recursive platform identity and security architecture
 domain: netkingdom
 repo: net-kingdom
-status: proposed
+status: done
 owner: Bernd Worsch
 topic_slug: netkingdom
 created: 2026-05-17
-updated: 2026-05-17
+updated: 2026-05-18
 depends_on:
   - NK-WP-0001
   - NK-WP-0004
@@ -27,7 +27,7 @@ accidentally becoming the platform root of trust.
 The workplan turns the recursive insight into operational structure:
 bootstrap plane, platform control plane, tenant plane, IAM Profile,
 flex-auth authorization, Topaz runtime, privacyIDEA MFA/token handling,
-and safe orchestration boundaries.
+OpenBao runtime secret authority, and safe orchestration boundaries.
 
 ## Context
 
@@ -49,7 +49,7 @@ In scope:
 - document the three-plane architecture
 - define platform-root versus tenant authority
 - define how NetKingdom, key-cape, Keycloak, privacyIDEA, flex-auth,
-  Topaz, and Railiance relate
+  Topaz, OpenBao, and Railiance relate
 - define bootstrap-to-runtime trust states
 - update related workplans and ADRs when implementation details become
   concrete
@@ -59,6 +59,7 @@ Out of scope:
 
 - implementing flex-auth adapters
 - deploying Keycloak, key-cape, privacyIDEA, Topaz, or Railiance services
+- deploying OpenBao itself
 - designing customer-specific tenant policy
 - replacing existing Railiance layer ownership
 
@@ -84,7 +85,7 @@ to a stable decision.
 
 ```task
 id: NK-WP-0006-T3
-status: todo
+status: done
 priority: high
 state_hub_task_id: "842ba5a7-5199-490a-8af5-3150388e0d42"
 ```
@@ -94,7 +95,7 @@ scope, audit/explain records, and platform-root guardrails.
 
 ```task
 id: NK-WP-0006-T4
-status: todo
+status: done
 priority: high
 state_hub_task_id: "ce153339-f493-44ed-a2c5-befb578334fe"
 ```
@@ -104,7 +105,7 @@ runtime identity, runtime authorization, tenant onboarding.
 
 ```task
 id: NK-WP-0006-T5
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "6c9a3561-4e63-4acd-87a7-bf0f374fa6b2"
 ```
@@ -114,7 +115,7 @@ audit readiness.
 
 ```task
 id: NK-WP-0006-T6
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "27760e30-f773-4552-97f4-7fbe56507f9e"
 ```
@@ -123,7 +124,7 @@ a dedicated repo. Capture the decision as an ADR before implementation.
 
 ```task
 id: NK-WP-0006-T7
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "f09519ac-cf97-4f8b-8a7b-6ff828bbd8d9"
 ```
@@ -131,6 +132,33 @@ Define production readiness checks for the security platform: MFA state,
 secret rotation state, flex-auth policy state, Topaz health, audit sink,
 and break-glass verification.
 
+## Implementation Review - 2026-05-18
+
+The recursive architecture remains the right framing. The refinement from
+the current stack is that OpenBao is now part of the platform control
+plane as the runtime secret authority. SOPS/age and emergency bundles
+remain bootstrap and recovery mechanisms; they must not become the
+long-lived runtime authority for every workload secret once OpenBao is
+available.
+
+Implemented refinements:
+
+- `docs/platform-identity-security-architecture.md` now includes explicit
+  flex-auth/Topaz implications, Coulomb tenant onboarding, production
+  readiness checks, and OpenBao secret authority boundaries.
+- `docs/adr/ADR-0007-security-orchestration-boundary.md` records that
+  orchestration stays in Railiance playbooks for now; a dedicated repo is
+  deferred until sequencing has a stable, cross-repo product surface.
+- `workplans/NK-WP-0007-object-storage-sts-credential-vending.md` now
+  treats OpenBao as the runtime broker/audit option without letting it
+  replace flex-auth authorization or storage-native STS semantics.
+- `workplans/NK-WP-0004-credential-management-foundation.md`,
+  `workplans/NK-WP-0005-agent-driven-credential-bootstrap.md`, and
+  `canon/standards/credential-management_v0.2.md` now distinguish
+  bootstrap credential handling from the OpenBao runtime-secret handoff.
+
+State Hub task statuses should be synchronized to match this workplan.
+
 ## Acceptance Criteria
 
 - Architecture docs distinguish bootstrap plane, platform control plane,
@@ -138,7 +166,7 @@ and break-glass verification.
 - Coulomb is represented as tenant zero/reference tenant, not platform
   root.
 - The role of NetKingdom, key-cape, Keycloak, privacyIDEA, flex-auth,
-  Topaz, and Railiance is clear.
+  Topaz, OpenBao, and Railiance is clear.
 - Follow-up workplans identify where flex-auth and bootstrap work need to
   adapt.
 - Any future orchestration repo is justified by an ADR before it is