Copying a project can also copy a future action. If that reservation becomes active immediately, the new workspace may repeat an external submission as soon as its time arrives. I preserved the configuration while marking the copy paused, separating reuse of a setup from renewed authorization to act.
Retain the configuration while changing execution state
Project-job copying creates a new reservation identity for each eligible source record. Procedure, inputs and intended time are carried forward, but status becomes paused. The original run identity and error are cleared, keeping copied configuration separate from evidence of an earlier execution.
The function iterates the source list rather than only queued entries. A previously completed record can therefore become a paused configuration in the copy. An equal reservation count does not mean an equal set of future runnable actions. State and original timing must be read together instead of inferring readiness from the list length.
Do not carry a reservation without a mapped destination
Copy receives a map from source tab identities to new tab identities. If the reserved tab has no mapping, that item is skipped. Mapped records receive the new workspace and tab, including remapping an unassigned profile where necessary. The original tab is not retained as an execution destination inside the new project.
A deliberately shared saved account may keep its profile connection. Equal account identity still does not establish equal document intent or inputs. Reconnecting identifiers is a necessary first step, while understanding the copied business destination requires another review before execution is resumed.
Resume only a paused item whose intended time is still future
The resume transition checks ownership by workspace, requires paused state and refuses a reservation whose time has already passed. A copied past-due action is not pushed into immediate execution by a convenient resume button. Changing its intended time requires a separate deliberate configuration path.
An accepted resume only returns the item to queued. The timer still has to validate context and definition hash before dispatching the actual run. Acknowledging a resume request, starting execution and confirming its outcome are different states. Collapsing all three into one success message would hide the boundary this design is intended to preserve.
Order competing resume and cancellation metadata changes
A lock keyed by reservation identity serializes changes to that record. The long-running program executes outside this metadata lock. Cancellation is allowed only for queued or paused records; changing a list status cannot truthfully reverse an external action already underway. Stopping execution and cancelling a reservation have separate lifetimes.
The project lane also releases only its own ownership token, preventing delayed cleanup from erasing a newer scheduled run. The shared synthetic lane module tests that narrow rule. It does not implement copied reservations or persistent files, and its reuse notes keep that scope explicit.
Check paused copies and removal of the original run identity
The unit scenario allows different projects to finish concurrently while a second reservation in one project remains waiting. It then checks that copies are paused, point to the new tab and retain no original run identity. The application isolation scenario also inspects paused reservation state after project copying.
A separate recovery test opens a previously running record and requires review-needed status with zero dispatch calls. That is a different boundary with the same concern about accidental replay. This writing reads the existing code and evidence; it does not create or cancel actual user reservations or claim new live-service verification.
Choose a default that preserves the next human decision
Someone copying a project may want reference material only, or may intend to change inputs for a different workflow. Assuming the original future action should continue erases those possibilities. Paused preserves a later explicit choice instead of treating structural duplication as renewed intent.
I favor checking destination, inputs, account and time before selectively reactivating the necessary items. Useful automation is not limited to repeating an operation faster. Reusing a configuration without silently inheriting its former execution intent can be the more valuable convenience in real work, especially when an action leaves a lasting external result.