[dp-web4]

Refs #366 (the authorization-timing half of its 2026-09-01 reconciliation), #707, #732.

Why

A grant that nobody observes lapses at decided_at + 600 (decided_horizon). #667 moved the start of the claim fuse to the moment of observation. But only a poll or a claimable call records an observation. The re-issue that the deny tells the asker to send does not.

So when the operator approves while the asking session sits idle, two things happen once that session is next prompted:

• its byte-identical re-issue finds nothing to claim;
• it opens a duplicate petition for the operator to rule on again.

Live on 2026-10-21:

UTC
19:24:25	cf54d46850bcdfe0 opened (git apply of GT metadata)
19:43:08	operator approves ("k")
19:53:08	horizon passes, unobserved
20:14:09	identical re-issue → d9b167e12a7283b8 minted
20:14:30	operator approves again; claimed 22 s later

#366's 2026-09-09 census found the same pattern in 26 of 103 approvals over one week.

Change

• EscalationStore::observe_reissue(plugin_id, host_session_id, marker, act, now) observes only rows that belong to this proven asker session and whose marker and act digest equal the incoming act's.
  • It goes through mark_observed's own conjuncts: approved, bar met, unspent, first observation.
  • Re-issuing one act never starts the fuse of another.
  • decided_horizon keeps its outer cap of expires_at + 600.
• tool_gate_escalation_claim calls it right before claim_bound. The session it passes is the derived proven_host_session_id, not the caller's assertion: it comes from the precedence block above the call, which already refuses a mismatched assertion.

What this does not change

• No new authority. A poll from the same seat already revives a lapsed, unspent grant until expires_at + 600 (#667: an unobserved grant whose displayed window has shut is REVIVED by the asker seat's first attributed poll; mark_observed keys on plugin_id, so a reviewing wake arms a sibling's fuse #707). claimable does the same scoped to the session (A co-seat session's poll starts the asker's claim fuse - mark_observed is seat-scoped and the disposition wake is what lights it #732). This makes the re-issue count as the observation it plainly is, scoped more narrowly than either, to one act.
• The host-session binding is no stronger than claimable's. At A1 the session's host_session_id is set at connect and proves nothing about ownership (Guard C; proof of possession is Implement authenticated connect for PRD_ASSURANCE FR-1: principal binding before law, role, vault, or reputation #824). A same-seat caller that can impersonate the asker's host session could already revive the grant through claimable.
• Not covered: the attention half of Escalation approval has no disposition-notification back to the requester (loop-close gap) #366, i.e. waking an idle asker when its ruling lands. That is harness-side. For claude-code on CBP it is now an async Stop hook with asyncRewake, outside this repo. Today it woke the asker on the approval of 84ebc732b022e857, and the re-issue claimed it with no human message.

Tests

• a_reissue_observes_only_its_own_matching_grant (store). None of these observe anything: another session, another act, another marker, another member, or an unnamed act. The asker's re-issue observes only the matching row and leaves a sibling grant of the same session unarmed. After observation, the grant is still not claimable past expires_at + 600.
• the_askers_exact_reissue_claims_a_grant_ruled_while_it_was_idle (real tool_gate_escalation_claim). A grant ruled 900 s ago is claimed by the asker's exact re-issue. A sibling session's re-issue, or the asker's re-issue of a different act, claims nothing and leaves it untouched.
• Sabotage check: both new tests fail with observe_reissue disabled. The handler test fails by coalescing into a fresh pending petition, which is exactly the duplicate.
• Full lib suite: 1255 passed, 0 failed, 2 ignored.

Accountability self-audit

surface: tool_gate_escalation_claim (re-issue path)   act: spend a one-time governance-write approval
S: med/reversible-per-act [construct: one-time grant, act-digest bound (#539)]
R: n/a   W: pass [construct: proven_host_session_id derived from the resolved session; observe_reissue matches plugin+marker+act digest+host session]
O: pass [construct: observe_reissue then claim_bound, both before any side effect; a non-matching call mutates nothing]
A: pass [construct: claim witness unchanged; observed_at is store-only state as before (#850)]
V: present [construct: decided_horizon cap at expires_at + 600; deny/withdraw unchanged]
verdict: PASS

— cbp-claude

🤖 Generated with Claude Code

https://claude.ai/code/session_014LYVQN8U1xqy6U6pbyUDvH

[dp-web4]

Initial review: narrow exact re-issue observation appears consistent with preserving asker-session, marker, act-digest, and expiry caps. Important verification before merge: confirm matching/observation happens only after authenticated session binding, cannot revive a grant past the absolute expiry cap, and cannot mark another ask as observed; include negative tests for those paths. CI is currently running; this is an advisory review rather than unconditional approval.

[dp-web4]

Response to the advisory review. Each point is now covered by a negative test at 60ff8f88.

1. Observation only after the authenticated session binding. In tool_gate_escalation_claim, observe_reissue runs only with proven_host_session_id. That value is derived from the session that resolve_attributed_caller resolved. It sits after the asker/plugin mismatch refusal and the stated-vs-proven host-session refusal, both of which return Err before the call. New arms in the_askers_exact_reissue_claims_a_grant_ruled_while_it_was_idle:

   • An unattributed caller (no session_id) naming the asker's member and exact act claims nothing.
   • The asker's own session asserting another host session is refused (Err).
   • After both, the grant has observed_at: None and consumed_at: None. Only then does the asker's real re-issue claim it.

   Caveat on what (b) proves: it pins the ordering (refuse before observe). It is not an independent check of the binding itself, which is the existing precedence block.

2. No revival past the absolute expiry cap. a_reissue_observes_only_its_own_matching_grant, last arm: a re-issue at expires_at + 600 + 1 is observed (mark_observed doesn't read the clock), but is_claimable is false. decided_horizon() is min(observed_at + 600, expires_at + 600), unchanged by this PR.

3. Cannot mark another ask as observed. Same store test:

   • These observe nothing: another session, another act digest, another marker, another member, an unnamed act.
   • The asker's re-issue observes exactly the matching row.
   • A second approved grant of the same session with a different act stays observed_at: None.

   The handler test adds the sibling-session case through the real claim tool.

Both tests fail with observe_reissue disabled. The full lib suite passed at the previous head (1255/0); the two touched tests pass at 60ff8f88.

— cbp-claude

[dp-web4]

Exact-head re-review at 60ff8f8: earlier advisory concerns addressed with negative regressions for unattributed/mismatched session, unrelated act/marker, and absolute expiry cap. The acknowledged host-session proof limitation is pre-existing and not expanded by this exact-reissue route. All three workflows green and GitHub reports clean. No remaining review blocker; squash merge cleared.