Record the approval-engine coordination follow-up.

Reconfirm that approval-engine-operator has no presenter and accept the amended CCR-2026-0018 removal. Name the separate create-only informed-decision requester. Keep the Access claim and fractional-time tasks waiting on consumer evidence, and refresh the repository-rename intake check.

Assistant: grok
Assistant-Session: 01a16889-9224-7ec0-bee0-2a46dd3819c4

docs/keycape-service-registrations.md

@@ -137,7 +137,7 @@ Scope by scope, the bundle we originally requested does not describe one actor:
 
 | Scope | Who would present it |
 | --- | --- |
-| `approval:create` | whoever *requests* an approval. Not named anywhere in the estate today; `gate-house` doctrine says which acts need one, but no requester identity has been settled |
+| `approval:create` | `informed-decision-sitting-requester` (create-only, `sub=informed-decision`). It is not `approval-engine-operator`. A human still binds at `/entries` |
 | `approval:approve` | `informed-decision`'s **human** client, per its own registration. A service principal holding this is exactly the question `gate-house` has not ruled on — see the `principal_type` note below |
 | `approval:read` | anything rendering or inspecting an approval |
 | `approval:revoke`, `approval:supersede` | attended lifecycle operations |
@@ -179,13 +179,22 @@ Standing capability with no counterparty is a worse resting state than either
 extreme: it serves no one, and it is the shape found later by someone other
 than its owner.
 
-**Decision, as requesting owner: disable the registration, keep the custody.**
+**Decision, as requesting owner (2026-09-10): disable the registration, keep the custody.**
 Not delete. `CCR-2026-0018` verifier custody stands, so the client remains
 authenticable and restorable the moment a presenter is named; the re-request
 constraint above still applies — narrowed to that presenter, and
 `approval:approve` must not travel with the operational scopes. key-cape
 executes the disablement with railiance-platform as the deployment change.
 
+**Amended 2026-10-23:** still no presenter. `informed-decision-sitting-requester`
+does not present this client. approval-engine accepts the joint removal in
+key-cape message `ffe5aff4` as amended by railiance-platform `RPF-WP-0035-T10`:
+remove the registration, prove `invalid_client`, remove the KeyCape env and the
+operator-client ExternalSecret, then metadata-delete
+`platform/workloads/approval-engine/operator-client`. A later presenter gets a
+new narrowed registration and a fresh secret. `approval:approve` still does not
+travel with operational scopes. approval-engine does not run that window.
+
 The middle option — leaving it standing with a recorded expiry — was rejected
 deliberately. An expiry is a promise to act later on a capability that is
 dangerous now, and the thing it protects against is precisely the case where

intakes/intakes.md

@@ -91,6 +91,6 @@ description: >-
   message: 2523510b-79d6-4123-b550-6386dae4d464.
 closed: '2026-09-30'
 resolution: >-
-  Verified 2026-09-30: no live repository URL/path naming flex-auth found (only a prose mention in a workplan); runtime/product vocabulary retained.
+  Verified 2026-09-30 and again 2026-10-23: no live repository URL or checkout path naming flex-auth. Remaining flex-auth strings are product, runtime, schema and historical prose, which FLEX-DEC-2026-013 keeps. Completion evidence returned on the rename-landed message.
 state_hub_intake_id: "01a0f26c-a0d0-7ad2-a8e2-c9de59c5aabb"
 ```

workplans/APPROVAL-WP-0005-access-claim-fact-contract.md

@@ -9,7 +9,7 @@ flavor: implementation
 owner: codex
 topic_slug: netkingdom
 created: "2026-10-16"
-updated: "2026-10-16"
+updated: "2026-10-23"
 depends_on: []
 state_hub_workstream_id: "777b17de-2c1e-5ce5-aa82-c99e5137e956"
 ---
@@ -41,7 +41,8 @@ request-refresh design requires change; fresh facts are verified out-of-band.
 
 ```task
 id: APPROVAL-WP-0005-T02
-status: todo
+status: wait
+blocked_on: message-from:access-engine
 priority: high
 state_hub_task_id: "3275354d-d781-53cf-aec6-975c0d4a601a"
 ```
@@ -85,3 +86,9 @@ needs authoritative raw source/compiler representation. No numeric restriction,
 digest substitution, foreign review, runtime enable or live proof is invented.
 T02 still owns independent source integration/handoff; existing T01/T05 native
 residual obligations and actual Access conformance/integration remain unchanged.
+
+2026-10-23 handoff: Access still owns the thin reader and conformance under
+FLEX-WP-0024-T06. Owner contract remains `docs/access-claim-fact-reader.md`.
+The 2026-10-16 review `docs/reviews/2026-10-16-access-claim-fact-reader-owner-review.json`
+requested changes and did not accept a native join. No signed claim is added.
+T02 stays open until Access returns conformance evidence.

workplans/APPROVAL-WP-0006-fractional-consumption-time.md

@@ -9,7 +9,7 @@ flavor: implementation
 owner: codex
 topic_slug: netkingdom
 created: "2026-10-16"
-updated: "2026-10-16"
+updated: "2026-10-23"
 depends_on: []
 state_hub_workstream_id: "9b859b2f-f98a-5104-b0d5-72bfdaf56da4"
 ---
@@ -46,6 +46,7 @@ schema migration and preserves old rows/idempotent timestamps exactly.
 ```task
 id: APPROVAL-WP-0006-T02
 status: progress
+blocked_on: message-from:access-engine
 priority: high
 state_hub_task_id: "c689f2b3-461c-5bdb-b6bc-01d756715564"
 ```
@@ -66,3 +67,9 @@ is never renewed. Exact R3 normalized-preapproval/temporal source review covers
 Approval facts only; native freshness120 configuration is not granted. Independent
 integration/publication and actual immediate strict CAS successor remeasurement
 remain pending coordinator/consumer evidence, not a reason to backdate or waive.
+
+2026-10-23 handoff: the source review stays
+`docs/reviews/2026-10-16-fractional-consumption-temporal-approval-owner-review.json`
+(decision approved for the bounded repair only). Access and secrets-engine still
+owe the immediate strict CAS remeasurement on the exact successor pin. T02 stays
+`progress` until that receipt exists.