Document scope alignment and warden-sign readiness

SCOPE.md

@@ -28,6 +28,9 @@ evidence.
   workflows.
 - Exec-time delivery to operators, agents, CI jobs, workloads, and ops-bridge
   tasks without printing raw values.
+- Future service/API mode that exposes the same approved planning, delivery,
+  handoff, lifecycle, and evidence semantics to ops-warden, agents, CI,
+  workloads, and UI surfaces without exposing OpenBao internals.
 - ops-warden routing contract for non-SSH credentials and scoped OpenBao
   capabilities.
 - State Hub non-secret evidence and progress integration.
@@ -72,31 +75,37 @@ evidence.
 
 ## Current State
 
-MVP delivered. The Python CLI (`src/secrets_engine/`) proves the
-`whynot-design-npm-publish` KV lane end to end — catalog → decision check →
-policy/AppRole apply → provision → positive/negative verify → exec-time npm
-delivery → ops-warden routing pointer → revoke — verified live against OpenBao
-(`scripts/demo-e2e.sh`, `scripts/npm-publish-demo.sh`). The netkingdom
-maturity-gated publication-scope policy is in place but dormant (netkingdom at
-`maturity-build`), so lanes clamp to repo-scope / `NPM_AUTH_TOKEN`.
+MVP delivered. The Python CLI (`src/secrets_engine/`) supports the core lane
+flow: catalog → decision check → guarded OpenBao policy/AppRole apply →
+provision or handoff → positive/negative verification → safe delivery →
+non-secret route pointers → revoke.
 
-The current source also supports non-KV auth-capability lanes. `SECRETS-WP-0004`
-adds the `warden-sign` catalog lane, exact-path policy guards for
-`ssh/sign/{agt-role,adm-role,atm-role}`, AppRole TTL/use constraints, positive
-and negative capability probes, and a handoff command that writes `role_id` and
-`secret_id` only to mode-0600 files outside Git worktrees. Live apply and
-cross-repo smoke remain pending OpenBao/operator gates.
+The repo supports both stored-value KV lanes and non-KV auth-capability lanes.
+KV lanes cover secrets such as npm publish tokens; auth-capability lanes cover
+narrow OpenBao policy/AppRole grants such as `ssh/sign/<role>` access for
+ops-warden. The maturity-gated publication-scope policy is in place and
+fail-safe: until the broader domain reaches the required maturity, publish lanes
+clamp to the safest repo-scoped token shape.
 
-`SECRETS-WP-0003` has been optimized for the real whynot-design pilot closeout:
-the catalog points at the canonical approved State Hub decision, the old
-slug-named offline decision mirror has been retired, and a non-secret preflight
-plus closeout runbook document the remaining real publish steps. The suite is
-currently green at 59 passed, 2 skipped.
+Current operational status lives in workplans, `.custodian-brief.md`, and
+`history/`; this file should stay stable enough for agents and contributors to
+use as the boundary reference.
 
-Bootstrap workplans `SECRETS-WP-0001` (State Hub integration) and
-`SECRETS-WP-0002` (MVP) are finished. Active: `SECRETS-WP-0003` (real pilot
-close-out) and `SECRETS-WP-0004` (scoped `warden-sign` auth-capability lane for
-ops-warden / FLEX-WP-0007 T4).
+## Hardening Trajectory
+
+The steady-state target is to keep routine secure work low-friction while
+removing bootstrap shortcuts. The hardening path is tracked in
+`docs/hardening-backlog.md` and includes:
+
+- replacing bootstrap token files with OIDC, service auth, or another scoped
+  OpenBao auth path for steady-state stage roles;
+- using response wrapping, short leases, and single-use handoff paths when
+  exec-time delivery does not fit;
+- requiring dual control for production value provisioning beyond approved
+  pilots;
+- making rotation, revocation, and deactivation routine evidenced operations;
+- exposing stabilized CLI semantics through service/API mode only after the
+  underlying decision, delivery, lifecycle, and evidence contracts are proven.
 
 ## How It Fits
 
@@ -111,7 +120,9 @@ sits between approval/identity systems and the OpenBao backend:
   back.
 - **user-engine / key-cape** — own identity and claims that bind consumers.
 - **ops-warden** — routes non-SSH credential needs here (conduit-not-broker) and
-  issues SSH certs itself; secrets-engine mints and custodies the tokens.
+  issues SSH certs itself; secrets-engine orchestrates OpenBao-backed issuance,
+  delivery, handoff, verification, and revocation while OpenBao remains the
+  custody backend.
 - **ops-bridge** — may consume scoped delivery for remote execution but stores no
   secret material.
 - **info-tech-canon** — source of canonical terminology and stage/policy concepts.
@@ -131,6 +142,7 @@ Canonical cross-system boundary: `net-kingdom/docs/secrets-engine-security-infra
 | **npm scope** | the `@`-prefixed npm name (`@whynot`) — distinct from org and repo |
 | **maturity** | `maturity-build/test/prod` package tag; feeds the publication-scope policy |
 | **bootstrap token** | temporary mode-0600 OpenBao token used during setup, revocable, outside repos |
+| **service/API mode** | future stable API surface over proven CLI semantics for approved plans, deliveries, handoffs, lifecycle actions, and evidence |
 
 ## Related / Overlapping
 
@@ -183,3 +195,13 @@ description: Models non-KV grants such as warden-sign as guarded policy/AppRole
   while keeping role-id and secret-id material outside Git and normal logs.
 keywords: [secrets, openbao, approle, auth-capability, warden-sign, ssh-signing, handoff, least-privilege]
 ```
+
+```capability
+type: security
+title: Lifecycle and non-secret evidence
+description: Tracks secret and capability lifecycle actions as explicit, reversible
+  workflow steps: provision, verify, deliver, rotate, revoke, deactivate, and audit.
+  OpenBao keeps custody and audit; secrets-engine records only non-secret decisions,
+  paths, policy names, actors, timestamps, and verification outcomes.
+keywords: [secrets, lifecycle, rotation, revocation, deactivation, audit, evidence, openbao, state-hub]
+```