Discovering a missing final attachment after earlier items have already run leaves a mixed batch. I put whole-batch preparation before the first external operation instead of validating and executing each item immediately. Preparation does not establish final success, but it moves problems that can be detected early to a clearer boundary.
Create a preparation boundary that receives the whole list
Workflow preparation checks list shape, count and distinct item identities. The project operations notebook sends the complete list to host preparation, which also rejects duplicate identities and validates every item. A valid first item is not treated as evidence that the rest are ready.
Run calls preparation again before entering its execution loop, rather than depending on a remembered visit to the preparation cell. A library-launched single-item workflow uses another adapter. The whole-list behavior of the project notebook should therefore not be generalized to every execution format without checking its actual entry path.
Distinguish key validation from requiring present values
The low-level item preparer rejects unknown parameter names, merges definition defaults with supplied values and resolves templates. Default use still exists there. It would be inaccurate to say that this function rejects every omitted value; stricter current-input checks at other entry points are a separate contract.
That distinction matters in diagnosis. A misspelled key, an intentionally empty string and a retained default are different conditions. A reassuring prepared label does not establish that every value came from the present human request. Shape validation and value provenance both need attention before interpreting preparation as ready intent.
Check currently selected handles rather than familiar filenames
Preparation collects attachment handles from resolved steps and requires them to belong to the current selected-file context. A previous filename or retained path is insufficient to authorize a new upload. Relevant upload entries embedded in supported media options are checked too.
This establishes neither transfer nor server storage. Files can change after preparation, and actual selection or transmission can fail later. Execution-boundary validation and remote outcome checks still matter. Current material eligibility and completed delivery should remain different states so operators can understand what the preparation screen actually confirmed.
Resolve destination and media rules before dispatch
Preparation sends the resolved starting, tab and navigation addresses through scope checks and invokes supported media-specific validation. Resolving future values early exposes invalid settings before actions begin rather than at the moment a later step tries to use them.
Valid address and input formats still do not establish current authentication or editor state. Pages can change. The prepared result presents project, profile, reference tab and step descriptions for review. Fresh observations and execution conditions remain necessary when actual operations are dispatched; preparation is not a frozen guarantee about the future screen.
Require zero executions even when the second item is invalid
The existing unit test places an unknown parameter in a later item and requires preparation to fail with zero execution calls. Duplicate identities and unselected attachments have the same pre-action expectation. The test is about examining the batch before its earlier operations have already happened.
That evidence uses an execution stub and owned temporary folders in existing test code. This writing sends no new customer material. The shared file journal is also an independent non-executing example. Preparation, persistence and actual external processing need separate evidence to explain which failures were caught before dispatch.
Do not let prepared look like completed
A preparation screen can still make people assume the next button guarantees completion. Showing both the examined items and the fact that execution has not happened is useful. Reducing preventable early errors does not remove the need for later outcome confirmation.
Batch quotations and document delivery in business software have the same concern. Checking the whole set first can reduce partially processed batches, while actual storage and delivery still need item-level records. Preparation exists to explain the conditions for starting, not to declare success before the operation occurs.