# Phase 3 — Usage and quota enforcement

## Delivered

- Persistent usage ledger in `tenant_usage`.
- Database-backed quota decisions suitable for multiple web nodes.
- App request enforcement in the central gateway with HTTP `429`.
- AI token accounting after each provider response.
- Job accounting when queue calls include a tenant.
- Signed `GET /api/v1/platform/usage` endpoint.
- Usage included in entitlement synchronisation for WordPress.
- English WordPress UI for used, remaining, allowance, and status.

## Metrics

| Metric | Limit |
|---|---|
| `requests` | `requests_per_minute` |
| `ai_tokens` | `ai_tokens_monthly` |
| `jobs` | `monthly_jobs` |

An app-specific limit takes precedence over a tenant-wide limit. Fixed windows
use `window_seconds`; limits without a window use the UTC calendar month.

## Operational notes

Quota decisions lock the effective limit row. PostgreSQL or MySQL therefore
serializes competing workers across physical and virtual servers. SQLite is
supported for isolated tests but is not the intended production control-plane
database.

AI usage is recorded using the provider's exact token total. A future block can
add token reservation and reconciliation before calling the provider, once a
per-operation maximum-token policy is defined.

Storage is intentionally not shown as ledger usage: it requires a point-in-time
filesystem/object-store measurement. Storage measurement and upload-time
enforcement remain a separate storage-layer block.