# The action queue

The queue is the product's spine. Anything the Keeper or the system wants you to know —
or wants permission for — becomes a **card**: a headline (90 characters, hard limit in
the schema), one metric line, and actions. Detail sits behind a disclosure. No essays.

## Card types

| Type | What it is | Actions |
|---|---|---|
| `proposal` | The Keeper wants to change spend | Approve · Dismiss · Snooze |
| `insight` | Worth knowing; nothing to approve | Got it · Snooze |
| `alert` | Something broke | View · Snooze |
| `gate_result` | A validation gate passed or failed | View · Log decision |
| `policy_block` | A write the policy engine refused | Why blocked |

## The rules that don't bend

- A proposal **cannot** reach `approved` or `executed` without `resolved_by` — enforced
  by a database CHECK constraint, not application code.
- Approving a spend proposal runs the policy engine: per-product daily caps, network
  walls (some products can never touch Meta — also a DB constraint), and a portfolio
  monthly ceiling. A policy refusal beats an approval, whoever clicked it.
- `resolved_by` is the authenticated account's email. Over MCP, the required `actor`
  field names the human whose decision is being relayed; the audit log records both the
  actor and that the write came via MCP.
- Cards expire (default 72h) so the Keeper never acts on stale analysis; a fresh sweep
  raises a fresh card.

## States

`pending → approved | rejected | snoozed (until) | expired`. Approved and rejected cards
collapse to one-line receipts with who and when. Restore only ever returns a snoozed or
expired card to pending — it can never resolve one.