kew approve / kew deny

Release or deny a needs-approval hold — including remotely, without a terminal.

kew approve --issue N [--reason "..."]   # release the hold (records approval_granted)
kew deny    --issue N [--reason "..."]   # deny: remove the hold, park the issue

Both record an audited decision (approval_granted / approval_declined) with the actor (KEW_ACTOR, else the OS user), the reason, and the original estimate, then: - approve → flips needs-approval → ready (the scheduler picks it up); - deny → removes needs-approval only (parks the issue; never closes it).

Both are idempotent (keyed on the label) and fail loudly (exit 2) if the run-store db is absent — a release that can't be audited must not silently succeed.

Remote approval (no terminal)

With .github/workflows/approval.yml installed, a governor approves from a phone by commenting on the held issue:

/approve looks fine, ship it
/deny too expensive for this change

The workflow authorizes the commenter (must have repo write access; optionally an [approval] approvers allowlist) and runs kew approve/kew deny on the self-hosted runner. Security: there is no token, link, or public endpoint — the trust anchor is GitHub's own auth + write-access, gated at the workflow job level so an unauthorized comment never reaches the runner.

Delivery

kew report --notify POSTs the spend report to the configured [alerting] webhook_url (Slack-compatible). When a dispatch is held, kew also comments the /approve·/deny instructions on the issue (and webhooks them) unless [alerting] notify_on_hold = false.