coulomb/approval-engine
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Record the approval-engine coordination follow-up.

Browse source 
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
This commit is contained in:
tegwick 2026-10-23 15:43:26 +02:00
parent a3564edc25
commit a8397abdc7
4 changed files with 29 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

13
docs/keycape-service-registrations.md
View file

@ -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

2
intakes/intakes.md
View file

@ -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"
```

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

@ -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.

9
workplans/APPROVAL-WP-0006-fractional-consumption-time.md
View file

@ -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.