# AI-001 verification — durable AI queue and backpressure

Updated: 2026-08-03

Status: `IMPLEMENTED — NOT VERIFIED`.

## Implemented

- Reuses `UserOperations`, terminal notifications and owner APIs/UI from OPS-001A/B/C.
- Server-side Pro/AI/privacy admission before operation creation.
- Owner/global bounded capacity, stable idempotency and status URL, deadlines, attempt limits and five priority bands.
- Claims only registered AI task types; unknown tasks are left untouched.
- Explicit owner scope, live entitlement/privacy recheck, cancellation monitoring, lease heartbeat, timeout, retry jitter and permanent/retryable failure classification.
- Configurable worker concurrency (default one), capacity/deadline/timeout settings and a default-off deployment switch.
- No raw CV, email, job description or prompt field was added.

## Evidence

- Focused `AiOperationQueueTests|UserOperationStoreTests|OperationsControllerTests`: 17/17.
- Full backend: 581/581.
- Compose config and `git diff --check`: pass with expected unset optional variables/line-ending notices.
- Existing operation tests cover atomic duplicate creation/claim, owner isolation, lease recovery after restart, deadlines, cancellation, retry, transaction rollback and notifications.

## Remaining gates

- AI-003/004 must register real Strategy/CV handlers and return actual 202 responses; no generic create API was exposed because it would bypass task ownership/policy.
- AI-002 added sequential local-first routing, single-model circuit health, provider/reason/model recording and task/prompt fallback gates. AI-003/004 still own producer-specific payload minimization and accounting.
- Browser refresh/double-click/cancel/retry must be repeated against each real producer.
- Worker remains off; MariaDB and production canary/restart/queue telemetry are unavailable.
- The process-local capacity gate assumes one backend replica. Add a database reservation only before multi-replica rollout.