Align the lifecycle intent with the accepted engine blueprint.

INTENT.md now describes one enabling library over the store, manifested
as a CLI or a single-stage service. SECRETS-WP-0016 is the implementation
workplan. The accepted layer statute is still v0.8.

Assistant: grok
Assistant-Session: 01a1609f-72b8-7222-9dff-fae300115e42

INTENT.md

@@ -25,19 +25,37 @@ declared_at: "2026-08-29"
 > another repository is not a declaration; this file, in this repository's
 > voice, is.
 >
-> secrets-engine is a **deterministic API over OpenBao** for one modeled
-> concept: the cataloged credential lane and its lifecycle. The same
-> authoritative inputs — catalog entry, access-engine decision record, and
-> OpenBao state — must yield the same plan, apply, delivery, and lifecycle
-> result. That is why this repository is an Engine, not Staff, even though
-> operators and agents invoke it at runtime.
+> secrets-engine is a tool of automation for one capability: the cataloged
+> credential lane and its lifecycle. It encapsulates that work in one
+> consistent interface. The same authoritative inputs — catalog entry,
+> access-engine decision record, and OpenBao state — yield the same plan,
+> apply, delivery, and lifecycle result. That determinism is why this
+> repository is an Engine, not Staff, even though operators and agents invoke
+> it at runtime.
 >
-> **It is not a decision point.** `access-engine` (today `flex-auth`) renders
-> whether authority exists. gate-house authors the doctrine that may reach that
-> decision only as a request claim or a versioned policy rule. OpenBao is
-> Tooling: custody, policy enforcement, leases, and backend audit. This engine
-> materializes an already-rendered decision into scoped OpenBao work. A
-> credential is an artifact of authority, never its source.
+> This shape is gate-house ADR-015 and `ArchitectureBlueprint.md` §2.2,
+> accepted 2026-10-22. The same wording is assembled in proposed
+> `security-layer-model_v0.9` §3.3. The accepted statute and companion remain
+> v0.8 until that successor is adopted. v0.8's PEP obligations still bind.
+>
+> **It enables the capability. It is not access control.** `access-engine`
+> (today `flex-auth`) renders whether authority exists, including whether an
+> operator may start or call an instance. gate-house authors the doctrine that
+> may reach that decision only as a request claim or a versioned policy rule.
+> OpenBao is Tooling: custody, policy enforcement, leases, and backend audit.
+> This engine does not hold those records. Other engines may use OpenBao for
+> other capabilities. This engine materializes an already-rendered decision
+> into scoped OpenBao work. A credential is an artifact of authority, never
+> its source. Holding the credential inside the process does not make this
+> engine a gate on the store.
+>
+> **One library, three manifestations.** The library validates, explains, and
+> plans without the store credential. The CLI is that library in a process. A
+> service is the same process kept running for one stage. At start the process
+> is injected with that stage's OpenBao credential. The credential enables the
+> capability and is not returned to the operator. A use-privilege does not
+> confer it. An operator who may delegate can assign the work to an operator
+> who may use the instance. The assignment transfers neither privilege.
 >
 > **It is PEP-shaped.** Apply, provision, exec delivery, handoff, suspend,
 > deactivate, and destroy cause protected side effects, so the four PEP
@@ -67,9 +85,10 @@ declared_at: "2026-08-29"
 
 ## One-liner
 
-**secrets-engine is the Lifecycle engine for approved credential work: a
-deterministic API that turns an access-engine decision into scoped OpenBao
-custody, delivery, and lifecycle actions across build, test, and production.**
+**secrets-engine enables cataloged credential lifecycle: one deterministic
+library over OpenBao, manifested as a CLI or as a service for a single stage,
+with that stage's credential injected at start and never returned to the
+operator.**
 
 ## Why This Exists
 
@@ -92,7 +111,8 @@ produced avoidable friction:
   responsibility of their own.
 
 This repository exists to capture that complexity once, behind a stable,
-deterministic, and auditable interface.
+deterministic, and auditable interface that is more reliable and more
+efficient than doing the same OpenBao work by hand.
 
 ## The Mission
 
@@ -124,12 +144,15 @@ privileged production side effect, a successful approval-engine CAS consume
 must precede the OpenBao call (`GH-DEC-2026-003`). Holding an ALLOW is not
 authority to act.
 
-### 2. OpenBao is Tooling; this engine is the API over it
+### 2. OpenBao is Tooling; this engine enables one capability over it
 
-OpenBao remains the vault, policy, lease, and audit backend. secrets-engine
-owns the catalog, validation, delivery, scoped capability handoff, lifecycle
-operations, and the operator/agent/Staff interface to those operations. Staff
-must not hold a direct OpenBao client for work this engine is meant to expose.
+OpenBao remains the vault, policy, lease, and audit backend. Several engines
+may use that store. secrets-engine enables the catalog, validation, delivery,
+scoped capability handoff, and lifecycle operations, and it is the
+operator/agent/Staff interface for that capability. It does not own custody,
+it is not the store's only client, and it does not decide who may use an
+instance. Staff does this capability through the engine rather than by hand.
+Another engine's different capability over OpenBao is outside this intent.
 
 ### 3. Stage-aware privilege
 
@@ -189,14 +212,15 @@ treat silence from `access-engine` as permission.
 secrets-engine is:
 
 - the Lifecycle engine for cataloged credential lanes;
-- a CLI today and a service API for operators, agents, CI, and Staff
-  repositories that must not speak OpenBao;
-- a typed catalog of KV secret lanes, auth-capability lanes, grants, delivery
+- one library for that capability;
+- a CLI, and for one stage that must stay up, a service, both manifestations
+  of that library and both injected with that stage's credential at start;
+- a typed catalog of KV lanes, auth-capability lanes, grants, delivery
   modes, and stage policies;
 - an OpenBao policy/auth-role applier with strict local validation;
-- an exec-time secret delivery and scoped capability handoff helper;
+- an exec-time delivery and scoped capability handoff helper;
 - a PEP at every protected side effect, with a published unreachable-engine
-  stance;
+  stance, consuming access-engine's decision rather than rendering one;
 - the credential interaction surface that ops-warden routes to after a
   decision.
 
@@ -204,9 +228,11 @@ secrets-engine is:
 
 secrets-engine is not:
 
-- a replacement for OpenBao, or the owner of custody;
+- a replacement for OpenBao, the owner of custody, or the only client of that store;
+- access control for OpenBao, or a decider of who may start or call an instance;
 - an identity provider or MFA system;
 - an authorization decision engine, an approval store, or a maturity engine;
+- a second implementation that appears only when the library is manifested as a service;
 - an application-specific secret store;
 - a place to persist raw secret values outside OpenBao;
 - a prompt-time secret injection mechanism for LLMs;
@@ -220,7 +246,7 @@ secrets-engine is not:
 
 | Concern | Primary owner | secrets-engine responsibility |
 | --- | --- | --- |
-| Secret custody, leases, backend audit | OpenBao (Tooling) / railiance-platform | Lifecycle API over least-privilege roles and validated paths. |
+| Secret custody, leases, backend audit | OpenBao (Tooling) / railiance-platform | Enable the lifecycle capability over least-privilege roles and validated paths. Other engines may use the same store for other capabilities. |
 | Authorization decisions | access-engine (`flex-auth`) | Consume a decision record; never render or cache one. |
 | Approval object | approval-engine | Consume an approval as an input claim; never store or mutate it. |
 | Security doctrine | gate-house | Apply doctrine only as it arrives on the decision or in a versioned policy package. |
@@ -248,8 +274,11 @@ The repository should evolve through these phases:
    evidence classified and emitted to audit-core; proposed SSH-CA and secret-use
    surfaces accepted or declined in this repository's own contract, not only in
    other repositories' gap registers.
-6. **Service mode:** expose a deterministic API that ops-warden, agents, CI, and
-   future UI surfaces can use without knowing OpenBao internals.
+6. **Manifestations:** the library stays free of the store credential. The CLI
+   and a kept-running service are that same library in a process injected for
+   one stage. The service is not a second product. Operators, agents, CI, and
+   future UI surfaces call it without knowing OpenBao internals and without
+   receiving the injected credential.
 
 ## Guiding Question