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.