docs: reconcile Claude readiness with authorization chain proof

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

README.md

@@ -38,8 +38,11 @@ Current constellations include:
   open-weight route, local bwrap sandbox.
 - `harness.agent-dev@1.0.0`: `rein-aharness`, remote agent-dev sandbox.
 
-The two local profiles are currently `blocked` by the missing sand-boxer
-owner-execution/runtime path. The remote profile is `unverified`: it may be
+The two local profiles remain `blocked` pending their combined runtime,
+credential-delivery and provider acceptance. Owner-mediated execution is
+implemented, with separate non-secret boundary, runtime-startup, egress and
+synthetic-credential proofs. Those proofs do not establish a real local model
+run. The remote profile is `unverified`: it may be
 used only as an explicitly labeled proof attempt. No committed profile is
 currently declared `ready`.
 

docs/anthropic-workload-key.md

@@ -127,3 +127,19 @@ approval-engine ActionAuthorization claim endpoint and access-engine Check
 service, then configuration, per-lane approval and positive/negative checks.
 The owner explicitly distinguishes these durable objects from State Hub
 decisions. This update does not activate the route or verify the provider key.
+
+## Authorization-chain proof update — 2026-09-06
+
+Reviewed secrets-engine `f62d3fe` and its evidence note `64aeec9`. The owner
+reports a complete claim → Check → CAS consume → backend integration proof
+against a throwaway OpenBao. Authorization HTTP transport/sequencing is
+stubbed, with wire contracts pinned to flex-auth fixtures. Negative cases
+refuse before the backend. This is integration evidence, not production
+authorization-service deployment or real Anthropic-key delivery.
+
+Remaining live inputs are the consumer PDP and approval service endpoints,
+production service credentials, the deployed policy pin, and each lane's
+`approval.authorization_id`, followed by native-lane access verification.
+SECRETS-WP-0009-T03 remains waiting. The existing custody-only CCR and stored
+key do not supply these authorizations. Glas retains its blocked local profile
+and must still verify pinned Claude startup and the combined real task.

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

@@ -258,3 +258,24 @@ record an unresolved approval/native action-vocabulary and embedded-claim
 digest mismatch for dual-control requests. This is owner integration evidence,
 not successful live activation; SECRETS-WP-0009-T03 remains wait. No new
 activation receipt was found in the Glas inbox. T02 remains waiting.
+
+## 2026-09-06 authorization-chain owner return
+
+Reviewed secrets-engine `f62d3fe` / `64aeec9`. Owner reports claim → Check →
+consume → backend integration against a throwaway OpenBao, including denial,
+unreachable service, invalid claim, missing digest, consume conflict and action
+mismatch refusal before backend access. Authorization transport is stubbed;
+wire shapes use published flex-auth fixtures. Do not describe this as a live
+production service or Anthropic delivery proof.
+
+Owner now identifies deployment/configuration as the remaining live gate:
+consumer PDP service and approval-engine rollout, production service
+credentials, deployed policy pin and per-lane authorization id.
+SECRETS-WP-0009-T03 remains wait. Earlier digest-defect notes are historical;
+use this latest owner return for the integration status. Native lane positive/
+negative access checks, pinned Claude startup, provider scope/budget inputs and
+combined Glas acceptance remain outstanding. T02–T05 stay wait.
+
+Review found no pending local changes or new inbox messages. Corrected stale
+README wording that still called owner execution missing; the implemented
+mechanism and its separate proofs do not change profile readiness.