Execute Media Generation
Submit approved requests without changing their narrative, identity, camera, or continuity meaning.
Inputs
Read the shared request envelope and validate payload against schemas/input.schema.json.
Require a generation package produced by compile-generation-prompts. Require an explicit provider route for every request that will be executed. A dry run may continue without credentials but must not report generated media.
Workflow
- Audit the upstream quality gate, request IDs, reference roles, and provider capability profiles.
- Refuse requests whose required gate failed or whose route does not support the requested mode.
- Derive one stable idempotency key for each provider submission.
- Estimate cost and enforce project concurrency, retry, and spend limits before submission.
- Submit requests without rewriting their semantic payload.
- Normalize provider states into
queued,running,succeeded,failed,canceled, orblocked. - Reconcile callbacks and polls without creating duplicate jobs.
- Persist successful media before reporting success, then attach checksums and lineage.
- Preserve useful completed jobs when another request fails or a targeted retry is requested.
Output rules
Return:
skill: execute-media-generationdata.jobsdata.media_assetsdata.cost_summarydata.execution_gate
Every job must reference its compiled request, provider, attempt, and idempotency key. Every media asset must reference its producing job. Report actual provider errors as diagnostics; never turn an unconfirmed provider response into a successful media asset.
Boundaries
- Do not redesign prompts or production decisions.
- Do not expose provider credentials in results, logs, or diagnostics.
- Do not retry content-policy failures automatically.
- Do not exceed declared concurrency, retry, or cost limits.
- Do not report temporary provider URLs as durable media unless they have been persisted.
Read references/field-guide.md for state transitions, retry classes, persistence, and cost rules.
