# Process future media

Run one Block or an ordered connected sequence on new saved versions after owner review.

The Step workspace can save an owner-confirmed rule for **This step**, or for
**Connected steps** when at least two supported recipe/isolated JavaScript Steps
are connected. Its first primary input must accept media. The same manifest,
semantic roles, context permissions and execution API apply; Block authors do not
add a scheduler or write server code.

Save the project and review automation before activation. A connected review
runs every included package's admission and fixture tests, then a connected
sample. Fixtures are review data: only actual upstream sample outputs fill the
following connected inputs. The preview shows each completed Step. Confirming
pins the full plan, scope, settings and conditions. Changing a downstream Step or
connection invalidates the review, just as changing the starting Block does.
Existing media is skipped at activation; new retained versions in the project,
scene or selected shots become independent durable jobs.

The host supplies each queued primary source and resolves declared secondary
inputs from the saved project. Host image decoding and S3 output storage remain
outside the guest. Each completed Step is retained before the next executes.
`step_results` records the ordered per-placement outputs; `outputs` is the final
Step's output only after the connected job completes. If a later Step fails,
completed results remain previewable and can be explicitly adopted into their
matching placements. They never overwrite every Step with the final output.
Originals and current workflow outputs are preserved until that choice. Teams
editors can use results; only the project owner manages rules. Job history
paginates, and result media loads when expanded.

The rule pins the complete plan digest and pauses for review when the saved
workflow or settings change. Retries verify retained prefix inputs and source
identities before resuming. Ordinary processing does not invoke ComfyUI, local
models, hosted generation or arbitrary dependencies. The existing guest CPU,
heap and JSON limits apply alongside bounded host decoding, storage and job
execution. A one-megapixel decode ceiling is not a guarantee that every decoded
RGBA image fits the guest budget.

Automation requires its database migrations and a configured background worker;
see `docs/BLOCK_AUTOMATIONS.md` for deployment and bounds. Unretained/unsaved
versions and media outside saved project source documents are not discoverable.
SDK Block outputs are excluded from future-input discovery to prevent recursive
processing. A connected job's intermediate outputs are forwarded only inside
that job; they do not create new jobs. Unsaved browser-only changes are not
visible to the worker, and local/blob media must be shared before execution.