# BO-003 · Contrato de solicitud y tarea · v1.0
Autor: Sergio Sallavera · 2026-09-08
Recurso: https://sergiosallavera.es/blueprint-asistente-operaciones/
Diseño para piloto. No incluye conexión ni ejecutor. Completar lo pendiente antes de operar.

## Alcance que debe cerrar el equipo
- Tipo de solicitud: [completar]
- Herramienta y espacio de prueba autorizados: [completar]
- Responsable y sustituto con permiso de aprobar: [completar]
- Acción permitida: crear una tarea. Otras acciones quedan fuera del piloto.
- Vigencia de aprobación, plazo de reclamación y política de reintentos: [acordar]
- Idempotencia del destino / consulta por referencia disponible: [verificar]
- Canal interno para incidencias y responsable de reconciliación: [completar]

## Campos del expediente
request_id: identificador estable del evento de origen; no regenerarlo en una entrega repetida.
version: versión del contenido propuesto, incluida la acción y el destino.
state: recibida / falta_contexto / pendiente_aprobacion / aprobada / en_ejecucion /
resultado_incierto / reconciliacion / reintento_autorizado / completada / pausada / cancelada.
payload: título, descripción, destino y responsable de la tarea propuesta.
payload_hash: huella calculada del contenido exacto que se muestra al aprobador.
approval: actor, approved_version, payload_hash, action, target, approved_at, expires_at, status.
operation_key: identificador estable de esa intención aprobada; se conserva en cada reintento.
claim: ejecutor, instante y vencimiento del derecho de ejecución, con reclamación atómica.
attempts: lista de intentos con inicio, fin, operación, respuesta o error y referencia al log.
destination_receipt: identificador y evidencia de la tarea creada; null hasta confirmación.
updated_at y pause_reason: fecha de última transición y motivo de pausa, cuando aplique.

## Reglas de transición
1. Deduplicar la entrada por su identificador de origen en almacenamiento persistente.
2. La IA prepara contenido. Un validador comprueba campos y permisos; no delegarlos al prompt.
3. El responsable aprueba contenido, versión, destino y acción exactos.
4. Cambiar cualquiera de ellos invalida la aprobación. Una aprobación caducada no permite iniciar otra llamada.
5. Antes de la llamada, reclamar mediante operación atómica y comprobar permiso y aprobación vigentes.
6. Persistir la intención antes de producir el efecto externo. Evitar dos ejecutores concurrentes.
7. Guardar recibo del destino para completar; una respuesta perdida no significa que no se ejecutó.
8. Cancelación/pausa impide llamadas posteriores, pero no deshace una petición ya enviada: reconciliar.
9. No recuperar automáticamente una reclamación caducada haciendo otra llamada: investigar su intento.

## Recuperar después de una interrupción
- Leer registro e intentos; comprobar si el destino ya creó la tarea por clave o referencia.
- Si existe: guardar evidencia y completar sin duplicar.
- Si se confirma que no existe: validar aprobación y permisos antes de autorizar reintento.
- Si no se puede saber: pausar para revisión humana. No usar búsqueda ambigua como prueba de ausencia.
- Si la API soporta idempotencia: mantener la misma clave y respetar alcance y caducidad documentados.
- Documentar quién resolvió la incidencia y con qué evidencia.
- No prometer ejecución exactamente una vez entre sistemas sin garantías verificadas del destino.

## Aceptación del piloto
Ejecutar los seis escenarios CSV en un espacio de prueba y adjuntar registros del origen y destino.
No avanzar con duplicados o acciones sin autorización válida. Registrar fallos aunque después se corrijan.
Comparar tiempo humano de recuperación y solicitudes resueltas con el proceso actual.
Decisión: [pendiente] · Evidencia: [pendiente] · Responsable y fecha: [pendiente]