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

Answer who presents approval-engine-operator: nobody

Browse source 
railiance-platform asked and declined to guess, which was right — this
registration carries the widest scope set of the pair. Nothing in this
repo obtains an OAuth token; it only verifies them. Scope by scope the
bundle describes no single actor: approve now belongs to
informed-decision's human client, emit is redundant against the server's
own heartbeat, and no requester identity was ever settled for create.

Cancel CCR-2026-0020 as an owner decision rather than leave it in_flight,
keep verifier custody CCR-2026-0018, and record that a future presenter
gets a narrowed registration — approve must not travel with the
operational scopes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HyybaE7DUXrWYrhbnESCTe

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1275879@bnt-lap001
Assistant-Session: eb464208-f821-41b2-bc5a-a6c33d92a8ad
This commit is contained in:
tegwick 2026-09-09 23:17:43 +02:00
parent fec4eaeb1b
commit 849c75bb09
2 changed files with 68 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

20
workplans/APPROVAL-WP-0002-production-readiness-and-consumer-adoption.md
View file

@ -184,6 +184,26 @@ is accepted rather than refused. T01 remains `progress`: what is left is
key-cape owning the registrations, credential custody from railiance-platform,
and the open scope question (A) above — none of them reachable from here.
2026-09-09 (third): `railiance-platform` (`RPF-WP-0035-T06`) asked who presents
`approval-engine-operator` and refused to guess — correctly, since it carries
the widest scope set of the pair. The answer is that nobody does. Nothing in
this repository obtains an OAuth token: the engine only verifies them, its one
outbound credential is the mounted `audit-token` for audit-core delivery, and
`pep.py` is a consumer-side helper for PEPs that present their own. Scope by
scope the bundle does not describe a single actor — `approval:approve` now
belongs to `informed-decision`'s human client, `approval:emit` is redundant
because the server emits its own heartbeat with no token, and no requester
identity has ever been settled for `approval:create`. It was a convenience
bundle written when this repo assumed a lifecycle operator would exist.
Answered (b): cancel `CCR-2026-0020` as an owner decision rather than leave it
`in_flight`; verifier custody `CCR-2026-0018` is unaffected and stays correct.
Recorded in `docs/keycape-service-registrations.md`, with the rule that a future
presenter gets a registration narrowed to its own scopes and that
`approval:approve` must not travel with the operational scopes — schema v4 makes
a service bind legible, but legibility is not permission, and the should-it
question remains gate-house's. `secrets-engine-approval` is unaffected: it has a
real presenter and is the client that unblocks T05. T01 stays `progress`.
## Harden durable storage and migrations
```task