# Aplicaciones, aceptación y deals

APC-3 convierte una versión publicada de oferta en una aplicación idempotente. El deal resultante conserva snapshots contractuales y une partner, casino, programa y `offer_version` sin confiar en IDs de tenant enviados por el cliente.

## Prerrequisitos

- Partner `active` y membresía owner vigente.
- Programa `published` dentro de una Casino Landing publicada.
- Versión de oferta publicada, vigente y señalada por el snapshot público.

Un partner que no esté `active` puede revisar la oferta, pero no aplicar.

## API partner

1. Resolver oferta y elegibilidad con `GET /api/v1/partner/programs?casino={slug}&offer={code}`.
2. Crear la aplicación con `POST /api/v1/partner/deals`, `accepted_terms: true` e `Idempotency-Key`.
3. Listar y leer mediante `GET /api/v1/partner/deals`.
4. Cancelar un deal propio todavía `submitted` con `PATCH /api/v1/partner/deals/{deal_id}` y `expected_version`.

Repetir la misma clave idempotente y payload devuelve el mismo deal. Reutilizar la clave con otro payload devuelve `409`.

## API casino

- `GET /api/v1/casino/deals` y `GET /api/v1/casino/deals/{deal_id}` son visibles para Casino Admin y Account Manager.
- `PATCH /api/v1/casino/deals/{deal_id}` solo permite mutar a Casino Admin.
- Cada transición exige `expected_version` y un motivo público de 10 a 500 caracteres.

## Lifecycle

`submitted -> provisioning -> active -> suspended -> active`

`rejected`, `cancelled` y `ended` son terminales. Una nueva aplicación solo puede comenzar cuando la anterior es terminal.

## Provisioning

- L0 admite `manual_code`, `promo_code` o `affiliate_id`.
- L1 admite `sub_id` o `affiliate_id`.
- Activar exige un mapping compatible y no secreto.
- Contraseñas, tokens y credenciales de proveedor nunca pertenecen al deal.

## Fronteras

APC-3 no emite links ni recibe eventos. Tracking comienza en APC-4, ingesta en APC-5 y cálculo financiero en APC-6.