The single-memo review page already fetched and labeled
approval-engine's binding.principal "Requesting party" -- the party
the approval was issued on behalf of, distinct from memo.binding.principal
(the reviewer being bound). The overview/list page fetched the same
live approval record for status but never surfaced this field.
OverviewRow gains requesting_party, populated only when the fetched
binding's digest matches the memo's pinned digest (same trust
condition status already uses); ui.py renders it as "Requested by: ...".
No new approval-engine call or flex-auth scope needed -- the record was
already being read.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: sonnet
Assistant-Process: 169987@bnt-lap001
Assistant-Session: 322ef1ef-9048-4021-8570-b6d6f6347999
The overview now requests the new list action and its rows carry only the
memo id, version, question, live approval status and the person's own
responses without notes. Opening a memo still asks read; every act asks
its own action. The fixture Flex Auth package admits list under a
re-derived pin. Not deployable until flex-auth answers INFD-IN-0008.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 359683@bnt-lap001
Assistant-Session: eebdc939-7a9b-4e50-9d39-c8437e8a14ec
Groups the reviewer's memos (needs attention, open, accepted, declined,
returned, closed, not available) above the manual memo-id form. Server
rendered and escaped; refused rows show only the memo id. The Chromium
harness gains a home-overview check (13 checks pass).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 359683@bnt-lap001
Assistant-Session: eebdc939-7a9b-4e50-9d39-c8437e8a14ec
