# Use one durable production queue for all generated and local work

**Status:** accepted

VideoClaw will converge batch-submit, pool, auto-chain scheduling, fallback rendering, motion-pack execution and Cinema generation onto one durable dependency-aware production queue. Existing commands may remain as front doors, but they compile queue items instead of owning independent submission loops.

The cross-process `LaneQueue` merged in `b979c83` is the transport-arbitration layer beneath this queue, not a competing task queue. The production queue decides *what* work is ready from dependencies, gates, priority and authorization. Immediately before provider submission, a worker acquires the `route:account` lane lease, heartbeats it while the provider job is active, and releases the exact ticket when the job becomes terminal. `LaneQueue` retains its measured capacity, cross-project fairness and SQLite cross-process coordination; the production queue does not reimplement those features.

Every queue item has a deterministic identity, immutable payload hash, task kind, project/unit scope, dependencies, priority, route, cost class, authorization reference, retry policy and append-only attempt history. Workers use bounded leases and heartbeats. Provider acceptance is persisted before another item is submitted. Recovery reconciles provider state before retrying. Paid attempts never auto-resubmit without reusable exact authorization; free/unlimited attempts may use a bounded explicit retry policy. Per-provider and per-account concurrency limits are scheduler inputs, not scattered command defaults.

Before it becomes a queue dependency, the lane primitive must close its null-dedupe and cross-process check/insert race, persist the exact ticket on the attempt, define multi-task payload capacity semantics, and support bounded pruning of terminal tickets. An operator-facing `lane await` must wait on one stable request identity rather than creating tickets while polling.

The queue supports images, video, audio, upscale, download, QC, assembly and delivery tasks so a complete production can pause, resume, drain or recover without reconstructing orchestration from conversation state. We accept the migration cost and a larger central contract to eliminate duplicate-spend risk, inconsistent resume behavior and operational fragmentation.

## Amendment (2026-09-10): front doors that still submit directly, and why

The queue is the home for generated work, but a few operator front doors still reach a provider without it, and this record was silent on them. They are listed here so their existence stops reading as drift:

- `vclaw video produce` / `execute` without `--auto-chain` (including `--scene <i>` and `--approve`, the latter being what the separate `approve` command used to do) — the direct, live-by-default single run. `--dry-run` writes the run contract; dropping it is the authorisation. It has no `--confirm-spend` gate and refuses that flag (and `--execute`) loudly rather than ignoring them.
- `vclaw video render-scenes` — the per-scene fallback ladder (route A, then B, then C on provider rejection), spend-gated by `--confirm-spend`. Its value is the ladder, which the queue expresses as separate tasks, not as one attempt that escalates.
- `vclaw video clone-execute` and `vclaw video create` / `auto` / `iterate` / `run-pipeline --execute` — authoring commands that end in the same direct run.

All of these reach the provider through ONE call, `executeProject` in `src/video/execute.ts`, which is the only direct caller of `submitExecutionPayload` outside the queue worker (`cinema-compatibility-worker.ts`). The in-flight run marker (#482), the `route:account` lane ticket and every produce-side gate therefore cover every door by construction; a test pins that `submitExecutionPayload` keeps exactly those two callers. `flow-r2v` and `motion-overlay --execute` own separate transports (Flow reference-to-video, Omni Flash video-to-video) and are out of this record's scope.

Converging plain `produce` itself onto the queue would change what "run it" means for every operator script and skill; that is a separate ADR-level decision, not implied by this one.