diff --git a/docs/production-dependency-handoffs.md b/docs/production-dependency-handoffs.md deleted file mode 100644 index fef0633..0000000 --- a/docs/production-dependency-handoffs.md +++ /dev/null @@ -1,124 +0,0 @@ -# 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. diff --git a/workplans/GLAS-WP-0012-first-local-profile-production-proof.md b/workplans/GLAS-WP-0012-first-local-profile-production-proof.md index 0699599..cc02d8b 100644 --- a/workplans/GLAS-WP-0012-first-local-profile-production-proof.md +++ b/workplans/GLAS-WP-0012-first-local-profile-production-proof.md @@ -291,14 +291,3 @@ 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. diff --git a/workplans/GLAS-WP-0015-production-dependency-coordination.md b/workplans/GLAS-WP-0015-production-dependency-coordination.md deleted file mode 100644 index 281e92f..0000000 --- a/workplans/GLAS-WP-0015-production-dependency-coordination.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -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" -state_hub_workstream_id: "94c02b1f-66ed-588d-bdd7-7158107b85fb" ---- - -# 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 -state_hub_task_id: "ddc1a421-079c-52ad-bc0e-591010942205" -``` - -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 -state_hub_task_id: "8903d552-4039-5b80-b589-3743f7751e5f" -``` - -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 -state_hub_task_id: "68fcc1b4-537b-5f5e-afb5-063c44e5e4db" -``` - -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.