harness + fullsend run: human approval UX for restricted permissions

[ifireball]

What happens

Operators lack a clear flow to signal that restricted work is needed, grant approval, be alerted when approval is missing, and understand when prior approval was invalidated. PR #2548 prototyped label-based UX but was not merged.

What should happen

A documented operator flow covers: requesting restricted permission, granting approval, blocked-state alerts from fullsend run, and invalidation when untrusted input arrives after grant. Exact mechanism (labels, slash commands, etc.) to be decided in #2821.

Blocked on: #2821 (ADR acceptance)

Context

• Epic: #2822
• Closes #470 (with deterministic execution issue in this epic)

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 7:16 AM UTC · Completed 7:17 AM UTC
Commit: e6b1ae3 · View workflow run →

[fullsend-ai-triage]

Triage: Blocked on prerequisite

This issue is blocked on #2821 (ADR for human-gated permission adjustments), which is still open. The issue body explicitly declares this dependency, and #2821 states that implementation work should not start until the ADR is accepted on main.

The prior implementation attempt in PR #2548 (label-gated workflow-change elevation) was closed without merging after the mint was moved into the binary. The design decisions — exact authorization mechanism (labels, slash commands, etc.), layer boundaries, and threat model mitigations — need to be recorded in an accepted ADR before UX work can proceed.

Once #2821 is accepted, this issue will be unblocked and ready for implementation.

Blocked by:

• docs: ADR for human-gated permission adjustments and threat model #2821

---

Labels: Issue is explicitly blocked on #2821 and covers harness UX for restricted permissions, which is a feature request.