Log the approver-surface handoff against T01

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 12:48:45 +02:00
parent 5203f46e47
commit 8b8ada6c4a

View file

@ -137,6 +137,25 @@ issuer's `/jwks`, checking `iss`, `aud=approval-engine`, expiry, `sub`,
nowhere in the codebase. Recorded in `docs/keycape-service-registrations.md`.
T01 stays `progress`.
2026-09-09 follow-up: the operator established `informed-decision`
(`INFD-WP-0001`) as the owner of the browser-facing approver surface, closing
the unassigned dependency recorded the previous day. Requirements issued to it
in `docs/approver-surface-requirements.md`: the two routes an approver surface
needs, the hard token claims, error/disposition mapping, and the standing
refusal to expose an inbox listing or a decision. Three items need an owner's
answer rather than an implementation: (A) the human client's specified
`allowedScopes` `[openid, approval:approve]` cannot `GET /v1/approvals/{id}`, so
the surface could submit an entry it was never able to render — we recommend
adding `approval:read` to the human client over reading through a BFF service
client, and this needs a key-cape decision; (B) `assurance` is persisted
verbatim and is the only place `mfaRequired: true` survives into the approval
record, so key-cape and informed-decision owe it a documented shape; (C)
`informed-decision`'s `view_hash` has nowhere to ride into an entry, whose body
is deliberately discarded — v1 correlates by `(approval_id, subject,
approved_at)` via audit-core, and binding the hash into the entry itself would
be a gate-house doctrine question before it is a change here. T01 stays
`progress`; none of these block this repository's half.
## Harden durable storage and migrations
```task