docs: prepare actionable production dependency handoffs

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0726e-5232-73f2-aaca-2c05ceb62efb

docs/production-dependency-handoffs.md

@@ -0,0 +1,124 @@
+# Production dependency handoffs
+
+Prepared 2026-09-06 from GLAS-WP-0012 and the deployed policy-service evidence.
+These are reviewable owner requests, not delivered messages or authority grants.
+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.

workplans/GLAS-WP-0012-first-local-profile-production-proof.md

@@ -291,3 +291,14 @@ Approval-engine remains undeployed: live KeyCape clients and audit sender are
 absent, the tenant contract needs alignment, and a release digest is required.
 Corrected its stale issuer/JWKS deployment inputs. No production credential
 lane or real Claude run was activated; T02 remains wait.
+
+## Production dependency coordination
+
+GLAS-WP-0015 now tracks exact owner handoffs and return receipts from Glas.
+The requests in docs/production-dependency-handoffs.md reuse existing owner
+work: tenant agreement and client custody, KeyCape rollout, audit source
+onboarding, approval release, native lane activation and pinned combined
+runtime. Image/runtime preparation can proceed in parallel. The runner's
+project glas-local-proof must be reconciled with the owner route example's
+project glas-harness before the exact delivery binding is selected. No owner
+messages have been sent by this coordination work yet. T02 remains wait.

workplans/GLAS-WP-0015-production-dependency-coordination.md

@@ -0,0 +1,60 @@
+---
+id: GLAS-WP-0015
+type: workplan
+title: "Drive owner returns for the first production Glas profile"
+domain: infotech
+repo: glas-harness
+status: active
+owner: codex
+topic_slug: production-dependency-coordination
+created: "2026-09-06"
+updated: "2026-09-06"
+---
+
+# Production dependency coordination
+
+GLAS-WP-0012 remains the real-profile acceptance workplan. This plan owns only
+concrete handoffs and receipt tracking from Glas; it does not duplicate owner
+implementation tasks or authorize credential access. User requested driving
+the dependencies from this repo after the policy-service production rollout.
+
+## Prepare exact owner requests
+
+```task
+id: GLAS-WP-0015-T01
+status: done
+priority: high
+```
+
+Reviewed KEY-WP-0013, its existing provisioning packet, AUDIT-WP-0009-T09,
+APPROVAL-WP-0002, FLEX-WP-0021, SECRETS-WP-0009 and SAND-WP-0015. Prepared
+seven concrete requests in docs/production-dependency-handoffs.md. Includes
+live PDP coordinates, custody paths, tenant mismatch, audit startup critical
+path, independent image/runtime preparation, and proof project binding mismatch.
+
+## Deliver and track owner handoffs
+
+```task
+id: GLAS-WP-0015-T02
+status: wait
+priority: high
+```
+
+Requests are prepared but not sent. Obtain explicit authorization to send
+State Hub coordination messages, then send deduplicated threaded handoffs to
+named owners and record actual receipt ids. Never mark delivery from file
+creation alone. A sent message is not accepted work or implementation evidence.
+
+## Review owner returns against the acceptance gates
+
+```task
+id: GLAS-WP-0015-T03
+status: wait
+priority: high
+```
+
+Track tenant agreement, client custody/identity, audit onboarding, approval
+release, native activation and runtime binding against the linked owner tasks.
+Check revisions and positive/negative evidence; feed verified returns into
+GLAS-WP-0012-T02. Keep unfulfilled owner work live, and do not close this plan
+while actionable requests lack an owning record or acknowledged disposition.