Class
Refinement / friction-direction over-block on Layer-1 token retirement (bounded, non-blocking). Surfaced during the #1095 design-coherence review; deferred there as orthogonal to the target-confusion work.
The gap
The #1097 target-aware retirement matches on operation-type + target, deliberately coarser than the token's full operation-type + target + bound-flags identity. So a successful bare same-op same-target command can retire an operator's approved token that carried an additional privileged flag (e.g. a successful plain close of a pull request retiring an approved close-with-branch-deletion token for the same pull request). The operator then has to re-approve the escalated command.
Why bounded / non-blocking
Retirement fires only on a successful same-op same-target execution, after which the escalated approval is largely mooted (the base operation already happened). The direction is re-approval friction, not a security hole, and it is strictly narrower than the pre-#1097 coarse retirement. It was correctly deferred from #1095 (curing it would add a flag-matching axis over the same extraction surface the target-confusion work was hardening — a coupling hazard).
Fix direction
Raise retirement granularity to operation-type + target + bound-flags (match the mint identity), so a token carrying a privileged flag is retired only by a command carrying the same privileged flag. Requires its own no-new-under-block sweep (a genuine self-consume must still retire its own token) — the reason this was not folded into #1095.
Class
Refinement / friction-direction over-block on Layer-1 token retirement (bounded, non-blocking). Surfaced during the #1095 design-coherence review; deferred there as orthogonal to the target-confusion work.
The gap
The #1097 target-aware retirement matches on operation-type + target, deliberately coarser than the token's full operation-type + target + bound-flags identity. So a successful bare same-op same-target command can retire an operator's approved token that carried an additional privileged flag (e.g. a successful plain close of a pull request retiring an approved close-with-branch-deletion token for the same pull request). The operator then has to re-approve the escalated command.
Why bounded / non-blocking
Retirement fires only on a successful same-op same-target execution, after which the escalated approval is largely mooted (the base operation already happened). The direction is re-approval friction, not a security hole, and it is strictly narrower than the pre-#1097 coarse retirement. It was correctly deferred from #1095 (curing it would add a flag-matching axis over the same extraction surface the target-confusion work was hardening — a coupling hazard).
Fix direction
Raise retirement granularity to operation-type + target + bound-flags (match the mint identity), so a token carrying a privileged flag is retired only by a command carrying the same privileged flag. Requires its own no-new-under-block sweep (a genuine self-consume must still retire its own token) — the reason this was not folded into #1095.