# Production dependency handoffs

Prepared 2026-09-06 from GLAS-WP-0012 and the deployed policy-service evidence.
Sent to the seven owners on 2026-09-06 after explicit user authorization.
Receipt IDs are in [production-handoff-receipts.json](production-handoff-receipts.json).
Delivery does not establish owner acceptance or an authority grant.
Glas coordinates acceptance; each owner retains implementation and authorization.
No credential values belong in responses.

## Ready infrastructure

FLEX-WP-0021-T04 deployed flex-auth-secrets-engine revision 1, available 1/1,
with five policy fixtures and positive/negative network probes passing.
Endpoint: http://flex-auth-secrets-engine.flex-auth.svc.cluster.local:8080.
Package: secrets-engine.catalog-lane.lifecycle v1.
Image: sha256:89086c02c74a931068423e70937d03df7850fa0db9c63e70be56b3558f1756af.
Caller-auth is warn. Direct cluster ingress requires namespace secrets-engine
and pod label app.kubernetes.io/name=secrets-engine. A workstation process needs
an explicitly supported owner access path; Service DNS is not workstation
connectivity. Do not turn warn into enforce before caller adoption is proved.

## 1. Tenant alignment — key-cape, approval-engine, secrets-engine, flex-auth

Before materializing credentials, reconcile three existing values:
approval store `platform`, proposed client JWT `tenant:coulomb`, policy tenant
`tenant:platform`. JWT/store comparison is exact. These may identify distinct
layers, but an explicit owner-reviewed mapping is required; spelling similarity
is not a valid mapping.

Return: the exact store tenant, JWT tenant, CheckRequest tenant and any permitted
mapping, with a decision/contract reference and wrong-tenant denial evidence.
No unilateral change to live clients or policy subjects is requested.
Related: KEY-WP-0013-T02, APPROVAL-WP-0002-T01, SECRETS-WP-0009-T03.

## 2. Admit service-client custody — railiance-platform with key-cape

Use key-cape/docs/approval-engine-provisioning-request.yaml, not a new invented
lane. After tenant alignment, admit these proposed exact coordinates:

| Client | OpenBao entry | Secret field | Kubernetes delivery |
|---|---|---|---|
| secrets-engine-approval | platform/workloads/secrets-engine/approval-client | client_secret | sso/keycape-secrets-engine-approval-client, key client-secret |
| approval-engine-operator | platform/workloads/approval-engine/operator-client | client_secret | sso/keycape-approval-engine-operator-client, key client-secret |

Resolve first-provision authority through the custody owner. Do not bootstrap
these via the very production lane whose authorization they enable. Record
admission/CCR ids, field names, reader/writer scope, revocation and delivery
receipts, never values. Supply protected delivery for KeyCape and the intended
client process; a KeyCape-side Secret alone does not provision the consumer.

Return: admitted owner records, protected materialization and exact consumer
bindings, plus negative sibling/read/write tests where applicable. Local
KEY-WP-0013 source registration is not evidence of live provisioning.

## 3. Deploy and prove KeyCape clients — key-cape

KEY-WP-0013-T02: roll out resource-audience support and both registrations with
the approved custody inputs. Live issuer is https://kc.coulomb.social; JWKS
service is keycape.sso.svc.cluster.local:8080/jwks. Verify JWT signature,
resource audience approval-engine, exact agreed tenant, subject, scopes,
principal type and lifetime (15m), plus excessive-scope/wrong-secret denial.
Preserve existing registrations and signing key.

Return immutable image and claim-contract proof references; no tokens. Identify
whether missing human callback registration blocks this service-only phase or
can remain separately tracked. Do not invent a human callback or relax MFA.

## 4. Register approval audit source — audit-core with railiance-platform

AUDIT-WP-0009-T09 / AUDIT-IN-0001 is now on the deployment critical path:
approval-engine production startup requires audit delivery. Its task currently
says low priority and "not blocking" because the producer is not emitting;
please review that dependency against the concrete startup gate.

Register source/sender approval-engine, agreed tenancy, the four event classes,
retention/access/export policy and load-bearing evidence handling. Provision
its token by the approved custody path to approval-engine/approval-engine-audit
key audit-token; add narrowly scoped receiver ingress and receiver config.
Keep user-engine's sender unchanged.

Return: registration/custody references, accepted/duplicate and wrong-token
proof, approved ingress, and the remaining cadence/reconciliation gates
(AUDIT-WP-0009-T04/T06/T09). No sender token in the response.

## 5. Release approval-engine — approval-engine

APPROVAL-WP-0002-T03: build/scan an immutable image for current migrated schema,
render corrected issuer/JWKS and agreed tenant, and validate deployment inputs.
Image preparation can proceed before live credential materialization. Deploy
only when identity and audit requirements pass; retain single-writer PVC and
migration semantics. For first install record no prior DB; for replacement
require verified backup. Prove readiness, restart persistence and restore.

Return deployed base URL, image digest, migration/storage/restart/restore and
audit evidence. Existing manifest endpoint fixes at 06544b0 do not close T03.

## 6. Adopt authorization and activate lane — secrets-engine with flex-auth

SECRETS-WP-0009-T03 / FLEX-WP-0021-T05: consume the deployed policy coordinates
above through a verified caller access path. Confirm exact package/image and
CheckRequest/claim binding against the real service; adopt the caller identity
before authentication enforcement. Configure the approval endpoint and per-lane
authorization id only after the owner service and approval exist.

Then apply the exact data-only read policy/AppRole, verify positive and negative
access and protected owner delivery for glas-claude-agent-dev-anthropic.
Custody CCR-2026-0016 is not a per-action authorization. Do not use a human
runtime token or unsafe-demo. Return activation and scoped delivery receipts.

## 7. Pin combined runtime — sand-boxer with rein-aharness

SAND-WP-0015-T04: pin Claude executable plus the rein Python artifact, prepare
the exact combined sandbox profile and credential-route binding, and prove
startup/private state/egress through the owner path Glas uses. Runtime work
can proceed in parallel with identity/audit deployment.

Resolve the currently different project examples explicitly: the Glas real
acceptance runner uses actor agt/project glas-local-proof; the owner delivery
documentation example uses project glas-harness. Return the reviewed binding
and adapt the fixture/config together; do not broaden the route to all projects.

Return: profile id/revision, host scope, runtime digest/executable paths, exact
consumer tuple, declared egress and denial/cleanup evidence. GLAS-WP-0012 then
reviews version 1.1.0, executes its real artifact proof and promotes only the
proven candidate. Provider workspace scope and spend limit remain operator
inputs; model budget_tokens does not establish a provider spend limit.

## Repository access for owner sessions

Primary owner workspaces: key-cape, railiance-platform, audit-core,
approval-engine, secrets-engine, flex-auth and sand-boxer. Give each owner
read access to glas-harness for this packet and the acceptance contract.
Sand-boxer also needs rein-aharness as a sibling for runtime packaging/startup.
KeyCape/custody/audit preparation and approval-image/runtime preparation can
proceed in parallel; final native activation follows the verified prerequisites.