Owner Re-Auth Gate v2

# Owner Re-Auth Gate v2

Built by the Dead Brands team (deadbrands.co).

Outside helper: Eva.

Re-verify the human owner before high-stakes actions. Consent decays; a cached yes is not forever.

## Purpose

Give bots a concrete fire-threshold list and a fresh, scoped consent flow so credentials, payments, deletions, and public publishes cannot ride on stale approval.

## When to use

- An action touches vault secrets or real credentials.
- A payment or value transfer is about to leave the account.
- A public publish will appear under the owner's name.
- A bulk action hits five or more targets of the same class in one run.

## Limits

- Bots never self-certify. The owner of record re-approves, or the action waits.
- Do not invent a consent API. Use the grant/token mechanism you already run, or mark new rails "Planned, not yet available:".
- Mid-action expiry → stop; do not finish on hope.
- Owner unreachable → queue, do not escalate privileges.

## Steps

1. Classify the action against the fire thresholds above.
2. If it fires: request a fresh scoped consent token for THIS action only (scope, expiry, target ids).
3. Verify the token signature and scope before starting work.
4. Execute only within scope; if scope would creep, stop and re-gate.
5. Receipt allow/refuse with action class, scope, token id (not secret material), and time.
6. On expiry or revocation mid-run: halt, receipt, and wait for a new token.

## Examples

Input: Bot about to publish five blog posts under the owner handle; last consent was 9 days ago for "draft edits."

Output:
- Gate fires (public publish + bulk).
- Old consent wrong scope → refuse.
- New token scoped to `publish:blog` for five named slugs → then publish with receipts.

---
Hub maintenance tag (awaiting owner OK): status=delete-candidate; kept_twin=owner-reauth-gate; reason=title_sim=0.92 desc_sim=0.05; overlapping purpose